分类目录: 架构设计

基于Dlib、Flask和Sqlite的人脸检测和识别服务

这个十一原定的计划取消了,没有做好备份计划,也就不打算出远门了,关在家里,把一直都想做的一个本地化的人脸识别服务整了一下。提供人脸分析的开源服务似乎很多年都没有大的变化了,一直都是Dlib和OpenCV,对比了一下,Dlib更容易使用。一直没有正经写过Python代码,翻出N年前买的Python编程书,边翻书Google、边写代码。基本的代码流程比较简单,Dlib官方也有例子,很容易运行起来,但是要服务化,要做人脸比对,并且是增量的人脸比对和识别,并不容易。说做就做,最终整个服务形成如下架构。

架构图:
image

代码和部署使用方法在如下git工程:http://git.codefine.site:3000/Shentar/facerec

首先需要将探测的过的“人脸”存储起来,然后能输入一张人脸返回与该人脸近似的所有人脸,这样客户端好做人脸归集。很快做好了一个初步的框架:使用Flask提供REST接口接收照片,在响应中返回人脸的特征标识,使用SHA256对人脸68点位的描述向量进行HASH,返回给客户端。同时将HASH值和实际的token存储到Sqlite。第一天大概就完工了这个功能。

运行起来,发现单纯的Flask不能并发,第二个请求会报错,一次只能接受和处理一个请求。于是又按照网上的经验,使用Gunicorn和Gevent来做多线程的方案,因为习惯了单进程多线程的方式,多线程访问Sqlite需要加锁,按照通用的做法,使用一个队列来管理Sqlite实例。继续验证,发现多线程并不能加速Detect的效率,貌似Dlib不支持多线程加速。调整为多进程,四个CPU都能运用起来。

1d2dd2b5bcde40b6a563996821d84843

终于找到了一个能将这个3.2GHZ的四核CPU跑满的业务了 ^_^

Architecture: x86_64
CPU op-mode(s):                  32-bit, 64-bit
Byte Order:                      Little Endian
Address sizes:                   39 bits physical, 48 bits virtual
CPU(s):                          4
On-line CPU(s) list:             0-3
Thread(s) per core:              2
Core(s) per socket:              2
Socket(s):                       1
NUMA node(s):                    1
Vendor ID:                       GenuineIntel
CPU family:                      6
Model:                           94
Model name:                      Intel(R) Core(TM) i3-6100T CPU @ 3.20GHz

人脸检测的效果还不错,错误率的话,自己家用是够了。特别是在侧脸检测上面,比较准确。在人脸比对方面,错误率就要高一些了,反复验证,发现0.36的比对阀值比较合适。侧脸虽然检测率高,但是在比对上面,只用通用的拟合范数,结果会表现为差异很大。因此这里应该是需要有定制化的比对实现,只做部分比对。这块需要深入到人脸检测技术内部,去分析128D的特征值向量的每一个值,短时间内没办法去研究透了。

由于采用了多进程,因此没法共用一个Sqlite运行时实例,强行并发读写访问会导致数据库错乱,不得不又做了一个服务来封装Sqlite,多个检测进程输出的人脸特征值都发给该服务来顺序存储,同时也返回给客户端。两个服务之间同样采用REST接口交互。

准备大规模上量,将jAlbum目前使用的线上人脸识别服务切换到这个本地服务上面,又发现检测时长非常高,一张4M的图片,大概需要几秒的时间,并且还有些非常小的区块被检测到了。对于检测慢的问题,考虑降低输入的照片的像素,图片减小后,长宽的像素点都相应减少了,但是人脸的特征点并不会损失太多。因此先对图片进行降低像素和尺寸,识别完成后,对识别到的人脸在照片上的位置也要相应做缩放,对比了一下,原始大小检测和缩放后检测,再对结果做相反的缩放,最终结果误差不大,但是这样能极大提速。对于非人脸和质量不高的人脸被检测到的问题,做了一些粗浅的限制,人脸长宽必须大于100的阀值才认为是正常的人脸。Dlib应该有正统的输出人脸的质量的参数,查了很久,没有找到合适的方法,就只能先这样吧。在比对方面,还有一些重要的概念,没有弄明白,如人脸对齐、年龄、性别检测等,不清楚我的代码里面是否已经有调用已经做了这块。

具体的处理代码:

data = np.frombuffer(data, np.uint8) 
if data is None: 
    raise Exception('image is required.') 

zoom_ratio = 1 
if data.size > 6 * 1024 * 1024: 
    img = cv2.imdecode(data, cv2.IMREAD_REDUCED_COLOR_4) 
    zoom_ratio = 4 
elif data.size > 4 * 1024 * 124: 
    img = cv2.imdecode(data, cv2.IMREAD_REDUCED_COLOR_2) 
    zoom_ratio = 2 
else: 
    img = cv2.imdecode(data, cv2.IMREAD_COLOR) 

faces = [] 
dets = detector(img, 1)

总的来说,开源项目,适合做一下Demo,如果要尽善尽美,那么就要深入到源码,有针对性的去优化检测和比对模型。作为个人的实验和家用还是很不错的。至少在快速编程和服务化这方面。

| 1 分2 分3 分4 分5 分 (5.00- 2票) Loading ... Loading ... | 同时归档在:WEB网络, 数码硬件, 移动互联, 软件应用 | 标签: , , , , , |

一致哈希(Consistent Hashing)简介

一致哈希 是一种特殊的哈希算法。在使用一致哈希算法后,哈希表槽位数(大小)的改变平均只需要对 K/n个关键字重新映射,其中 K是关键字的数量n是槽位数量。然而在传统的哈希表中,添加或删除一个槽位的几乎需要对所有关键字进行重新映射。一致哈希的算法最早在如下论文中被提出:

一致哈希在分布式计存储架构中无处不在。是被证明的可以解决经典哈希视图发生变化时,数据搬迁尽可能少的算法。最早是在分布式缓存中提出,参考如下文档,这里提供原文的下载链接:《Consistent Hashing and Random Trees: Distributed Caching Protocols for Relieving Hot Spots on the World Wide Web》

阅读全文 »

| 1 分2 分3 分4 分5 分 (5.00- 4票) Loading ... Loading ... | 同时归档在:存储技术, 算法数据结构 | 标签: , , |

PostgreSQL 9.5 架构图及外存图

转自阿里云栖社区:链接。点击图片查看原图。

阅读全文 »

| 1 分2 分3 分4 分5 分 (5.00- 1票) Loading ... Loading ... | 同时归档在:存储技术, 数据库 | 标签: |

微信朋友圈技术之道

讲师简介

陈明,微信高级工程师、朋友圈负责人,2012年加入微信后台团队,负责微信后台核心服务的研发,包括朋友圈、即时通信、基础设施等。他获得清华大学计算机系学士和博士学位,研究方向是分布式系统。在加入微信前,他在腾讯搜索和微软亚洲研究院工作多年,内容包括搜索架构与分布式存储等。

概述

截止到2015年7月,微信每月活跃用户约5.49亿,朋友圈每天的发表量(包括赞和评论)超过10亿,浏览量超过100亿。得益于4G网络的发展,以上数据仍有很快的增长,而且相对于PC互联网时代,移动互联网时代的峰值要来得更加凶猛。比如,2015年元月的流量到了平时的2倍,而峰值则达到了平时峰值的2倍,相当于平时正常流量的5倍,这对整个系统的考验是很残酷的。本次分享将简单介绍微信后台团队的开发模式、微信朋友圈的架构以及在性能上的一些工作,供各位参考。

阅读全文 »

| 1 分2 分3 分4 分5 分 (4.73- 15票) Loading ... Loading ... | 归档目录:架构设计 | 标签: |

[转]图解分布式一致性协议Paxos

转载自:loop in codes

Paxos协议/算法是分布式系统中比较重要的协议,它有多重要呢?
<分布式系统的事务处理>

Google Chubby的作者Mike Burrows说过这个世界上只有一种一致性算法,那就是Paxos,其它的算法都是残次品。

<大规模分布式存储系统>

理解了这两个分布式协议之后(Paxos/2PC),学习其他分布式协议会变得相当容易。

学习Paxos算法有两部分:a) 算法的原理/证明;b) 算法的理解/运作。

阅读全文 »

| 1 分2 分3 分4 分5 分 (4.92- 12票) Loading ... Loading ... | 同时归档在:云计算/云存储, 算法数据结构 | 标签: , |

Intel芯片架构和指令集演化

从芯片架构谈系统优化

下载地址:《从芯片架构盘系统优化》

| 1 分2 分3 分4 分5 分 (5.00- 10票) Loading ... Loading ... | 同时归档在:数码硬件 | 标签: , , , , , , , , , , |

[转]MIPS、ARM、X86三大架构

转载自:中关村在线

 

费浙平:RISC领域ARM不是唯一

近两三年,随着手机,平板等智能移动平台的兴起,一个鲜为大众所知的平台逐渐的呈现在了世人的面前。这就是诸如像iPhone 4手机和XOOM平板设备所使用的RISC(精简指令集系统)平台。随着RISC技术的不断进步,这些精简指令系统的设计者也从幕后走到了台前,成为了电子爱好者们了解的对象。不久前,笔者有幸与RISC领域中的专业人士进行了一次深度的交流,从他那里了解到了不少鲜为人知的关于RISC领域的故事。今天笔者通过对这次交流的整理,为大家讲述一名RISC系统技术市场经理眼中的嵌入式系统发展未来。

阅读全文 »

| 1 分2 分3 分4 分5 分 (4.89- 9票) Loading ... Loading ... | 同时归档在:数码硬件 | 标签: , , , , , , |

OpenStack Swift源码导读之——可插拔的后端设备实现

Swift作为一个存储的具体实现出现在OpenStack中,与Cinder的定位有差别,这导致Swift的兼容并包性不够强。必须基于XFS文件系统来存储数据?显然Swift也希望能将数据存储到更多的后端设备中,这样Swift可以与具体的XFS文件系统解耦,作为独立的存储软件存在。这能使得Swift存储的构建更加灵活,同时也能吸引更多的存储厂商投入到其怀抱中。

Swift提供了一种简单机制来实现后端存储设备的pluggable——可插拔的后端。这篇文章想探讨一下该机制。在亚特兰大峰会上面,这一特性是Swift的热门话题之一,对于亚特兰大OpenStack峰会涉及Swift的话题这里有汇总:链接

阅读全文 »

| 1 分2 分3 分4 分5 分 (5.00- 12票) Loading ... Loading ... | 同时归档在:Swift, 云计算/云存储 | 标签: , , , , , |

[转]处理器微结构史话

转载自:破布的博客

【注:这是经过小幅修改扩充的版本,刊登在中科院计算所计算机体系结构国家重点实验室的内刊《体系结构国重快讯》上,与《弯曲评论》上已刊登的版本小有不同,带来阅读不便表示抱歉。】

1945 年8月6日与9日,广岛和长崎两座日本本土城市先后在惊天动地的原子弹爆炸中被毁灭,核武器由此首次步入公众视野。全世界都被那两朵巨大蘑菇云的威力所震 慑。这两道重击也直接摧毁了日本最后的抵抗意志,一周后的8月15日,日本宣布无条件投降,在人类历史上写下最惨痛一页的第二次世界大战终于结束。核武器 横绝古今沛然莫御的威力,使得它成为战后制衡国际局势的一大王牌,对它的研究和制造在战后仍然未曾停息。而我们这一系列连载故事的主角,盈盈栖息于指尖之 上,不过毫厘见方的微型处理器,和这两朵摧枯拉朽的蘑菇云其实有着千丝万缕的联系。

Atomic_bombing_of_Japan 
(图注:两次原子弹爆炸的照片,来自维基百科。)

阅读全文 »

| 1 分2 分3 分4 分5 分 (5.00- 11票) Loading ... Loading ... | 同时归档在:奇趣见闻, 数码硬件 | 标签: , , , , |

OpenStack Swift源码导读之——业务整体架构和Proxy进程

OpenStack的源码分析在网上已经非常多了,针对各个部分的解读亦是非常详尽。这里我根据自己的理解把之前读过的Swift源码的一些要点记录一下,希望给需要的同学能带来一些帮助。

一、Swift的整体框架图

Swift代码树

阅读全文 »

| 1 分2 分3 分4 分5 分 (4.61- 23票) Loading ... Loading ... | 同时归档在:Swift, 云计算/云存储 | 标签: , , , , |
返回顶部