硕鼠的博客站

范路的博客主站,时而会发些东西。

Posts Tagged ‘云计算’

人脸识别API和人脸识别应用

Face API logo 今天在http://openpk.org 上的 #盛大云计算大赛# 创意投递中,看到了一个非常有趣的创意,叫做Face-API。其实前几天 @孤云大兵 同学提交创意“明星脸”时还有人在评论“这个技术门槛不低,要如何实现相关技术”的问题?当时孤云大兵表示准备去看一看论文,找一些相关的算法,不料今天就有人直接送服务上门了,真是无巧不成书。

• Face-API的介绍

Face-API是基于云主机提供的一套实现人脸识别服务的开放API。

Face-API的工作方式是这样的:首先,调用这套API的应用要将照片上传到云端;然后Face-API会在云端进行人脸检测,即使是合影,只要人脸所占像素达到了识别的标准,就会被一一检测出来;检测到人脸之后,根据五官的角度和比例来判定人脸在照片中的角度;最后一件事情就是进行人脸聚合,计算机是无法判定哪张脸属于哪个人的,它能做的仅仅是将同一个人的人脸聚集在一起。

Face-API将聚合的信息发送给调用它的应用,然后就会删除上传到服务器的照片,仅仅保留下聚合之后的人脸特征信息。当下次该应用再传输照片上来的时候,只需要和留存的人脸特征信息库进行比对,就可以知道这些新照片中哪些人脸以前曾经被识别和聚类过,并再次进行聚类。

到此为止,计算机能做的事情已经结束,操作权再次交回用户手中。也就是说,用户要自己将识别出来的聚类与具体的人关联起来,以及进行少量识别结果的校对。在这个人工参与环节之后,才算是完成了人脸识别的完整过程。

在此之后,应用还应该将用户反馈的信息(尤其是如不同聚类其实是同一个人、或某个聚类中有个别照片有误)反馈给Face-API服务器,以便服务器对算法进行校正,以提高今后继续识别的精确性。

当然,这并不是一个完全的训练过程。比如一个儿童,随着年龄的增长,其相貌变化是很大的,就算是人隔上几年看到一个儿童也不一定能够认出来,对于计算机系统来说,能够做的也就是记住“这是某某人,那也是某某人”,足矣。

上面解释的是最基本的服务流程,真正使用起来还要略微复杂一些。Face-API除了能够提供基本的人脸检测功能之外,还准备提供相似度比较、性别判定及年龄判定等,以后应该还会不断添加新功能进来。

• Face-API的用户隐私保护

如果需要进行人脸检测,就必须要上传照片。但是对于Face-API来说,系统并不知道这些照片上的人具体是谁,只是会进行人脸聚集。应用不断地传照片上来,Face-API服务器只能知道这次传上来的照片中有某个人脸和以前传上来的某个很像。

当用户将某张照片与某个人进行关联之后,这个数据并不会上传到Face-API服务器。对于Face-API来说,某一个聚类的照片,所指向的那个用户永远都是一个唯一的随机数,而不是某一个现实中存在的具体的人。

用户上传的照片,在识别之后会被删除,Face-API服务器上只保存人脸的一些特征信息,并不会长期保存用户的原始上传照片。比如一个照片流式的应用,本身就会要求用户上传照片,那么只需要在应用的服务器收到用户的照片之后,传送一份到Face-API服务器进行人脸检测和识别,应用可以保存用户的通讯录或照片中那个人的具体信息,但是这些东西Face-API的服务器上都不会保存。

在Face-API的接口上,允许应用对照片进一步进行用户标识,也就是说应用可以告诉Face-API服务器,哪些照片是属于一个用户的,而哪些是属于另外一个用户的。在Face-API的服务器端,将实现严格的用户数据隔离,一个用户的照片,只会和这个用户自己的照片进行比较和聚类,在比较和聚类的过程中,不同用户的照片是隔离的,这就在最大程度上保证了用户隐私的保护。

• Face-API和云计算和移动互联网

人脸识别技术在PC端已经有一些案例了,比如苹果的iMovie和Google的Picasa都带有人脸识别功能。但是,在移动互联网应用方面、在移动设备上,人脸识别运算(特别是最后的人脸聚类运算)所消耗的运算资源和内存资源都是不被允许的。移动设备本身的局限性导致了这个计算无法在本地完成,所以只能交给服务器去完成。

对于人脸识别类的应用来说,识别和比对的运算量是很大的,Face-API完全可以在用户请求比较少的时候,使用很少的服务器计算资源,也就是说使用一个配置较低的服务器来支撑日常的API调度和低请求量的人脸识别和比对计算需求,而在有大量照片需要比对的时候,同时使用很多服务器进行并行运算。

这种工作模式在传统的IDC机房中问题很大,但是有了弹性的云计算环境之后,事情就变得容易多了。

Face-API可以将数据存放在集群的NoSQL数据库中,然后将计算服务器的镜像也存储下来。在需要大规模运算的时候,只要调用云服务API,使用事先准备好的镜像使用1分钟时间部署出所需要的运算服务器,然后通过云计算API启动这些服务器,之后就可以自动调度服务器和NoSQL数据集群中提取所需处理的任务和数据进行高性能的运算。

运算结束之后,或者说是在运算请求量降低,不再需要那么多服务器进行并行运算之后,将并行运算服务器上的数据重新写回NoSQL集群中,然后自动执行关机脚本。调度服务器再通过云计算服务API将这些多余的服务器退掉。

值得一提的是,这次为盛大云计算大赛提供支撑的盛大云服务,是按照小时计费的。

人脸识别技术普及后的SNS

长远来看,人脸识别技术并不仅仅是一种简单的计算机智能模式识别技术,更将是一种对人与人之间的关系将带来深远影响的技术变革。

近年来非常火爆的SNS,也就是社会化网络服务,本身就是基于真实的人际关系建立起来的(比如Facebook),由此可见标识个人身份的照片对于SNS是多么重要。如果计算机能够相对准确地对这些照片和身份之间进行一个自动的标识和关联,那么SNS上肯定会出现很多完全不同的、很酷的甚至我们现在还无法想象的应用和服务模式。

人脸识别技术给SNS带来的改变,肯定不会比LBS小。

每一项技术,通常是首先出现在实验室中,然后再尝试将其产品化,在这个过程中新的模式将不断涌现。比如GPS(全球卫星定位系统)最初完全是为了军事目的被发明出来,民用化之后除了进行定位和导航外,很长一段时间并没有新模式出现。突然有一天,人们发现可以提供很多基于位置的服务,一种全新的应用模式就诞生了。

这不是技术创新,而是应用模式创新。人脸识别技术目前也处在这样一个阶段,技术基本成型但缺乏创新的应用模式。这个过程不是单纯靠实验室里面的科学家就可以完成的,而必须集思广益,靠整个社会的智慧来推动。

相信随着Face-API服务的上线,会不断有新的应用涌现,让我们来共同期待吧。

骑士时代的回归

现在这个时代,是云计算的时代,是AppStore的时代。我们看到,又一个骑士的时代回归了。
首先解释一下我认为的骑士是什么。骑士就是那些能够独立解决问题的,可以独当一面的个人英雄。最早的软件工程师,都是骑士。他们一个人或很少几个人就能够完成一个让大家惊叹的软件产品。
曾经有一段时间,大家普遍认为,骑士时代已经一去不复返了,以后的软件开发将变得越来越工程化,都是大兵团作战,是大团队,甚至是跨越全球多个地区的团队,团结一致,按照统一的规范和流程,开发完成的。甚至还出现了软件蓝领这种绝对是炮灰级的软件程序员。当时我们都相信,软件开发行业已经彻底告别作坊式的生产,那些个人英雄的年代已经一去不复返了,再也不会有那种少数几个人开发出来的,让人惊叹的软件了。软件行业将彻底的进入一个工厂化生产的时代。
工厂化的时代,确实是到来了。但是工厂从来也没有将骑士或小作坊彻底替代掉,那些骑士隐居在了工厂里,也有一些做着自由职业者。这些骑士们一直都存在着,有时候甚至让人想起那句麦克阿瑟将军的名言“老兵永远不死,只是慢慢的被人遗忘”。

让我们一起来看看工厂化到底为我们带来了什么吧?一个事物肯定是有两个不同的方面,有好的一面,肯定也有不被人喜欢的一面。好的部分,这里就不说了,大家可以去看看那些大公司的宣传广告。这里不做研究。
首先讲一个故事:我记得在我上大学的时候,一个老师到日本的软件企业里面去实习,结果发现里面使用的很多算法很笨,于是就询问他的日本主管,“我有更好的算法,是否可 以替换呢?”,他的主管回答道:“我也知道这种方法很笨,但是我们的规范要求我们这样去做,我们所有的程序员都能够理解这种算法,你的算法可能确实比现在用的更好,但是那会造成其他程序员的理解困难的,现在毕竟不是你一人在写软件,需要大家协同工作,所以我们只能使用一种最能够被大家所接受的算法。”

  • 工程化的软件开发过程管理,为了协调大量的工人向着一个统一的目标前进,就必须要有一套规则,一套所有人都认可并遵守的规则。所有参与这一工程的工人,就像是机器上的一个齿轮、一颗螺丝钉一样,只要处理好自己手头的工作就好了。这就导致了,对于一个软件项目来说,那些辅助的人员,也就是维持这套体系平滑运转所需的人,有可能比真正的编程人员还要多出不少。每一个员工都不需要了解软件整体从宏观到微观的所有架构和实施细节,他们只需要在自己所负责的地方进行创新就好了。甚至有人还为此将参与同一个项目的人员分成三六九等,分为蓝领、白领甚至是金领。让不同的人完成相同或相近的工作,最后的结果是什么呢?工作完成的速度绝不会比最慢的那个家伙快。流水线上的熟练工人,一点离开了他所熟悉的岗位,就变成了彻底的废物。每一个人进入新岗位,都需要进行复杂的培训。
  • 为了代码的可重用,开发设计了大量的框架和架构。这些东西,确实有一定的用处,那就是能够让程序对于复杂逻辑的描述,更加趋近于自然语言,更加清晰易懂。框架之所以被使用,主要是因为要把不同角色的工作边界清晰的区分开。设计各类工程实施过程的基本准则就在于:每一个工人、工种、工序之间,边界清晰;尽可能在每一个环节,都能够对上一个环节所产生的中间结果进行验证。再有就是代码块之间尽量实现松耦合,可以独立的修改其中任意一个模块,不会出现牵一发而动全身的情况。框架和架构唯一无法解决的问题,就是提高运行效率,任何框架和架构的使用,都会不可避免的导致软件的运行效率下降。
  • 高投入,就可以完成好作品,在工厂化时代,软件的规模居然是用人月这种单位来进行计算的。最终也就导致了,大家像埃及的奴隶那样去建造金字塔,投入的人力越多,建造出来的金字塔也就越宏伟。大家不需要去设计什么,软件完全是按照规模来衡量价值的。你造金字塔,我也造金字塔,形状都一样,差别仅仅在于个头大小有些差异。在这个阶段,我们以电视游戏机这个行业为例进行分析,高成本、高投入,完全可以弥补游戏性设计方面的不足。同时代的游戏机中,任天堂的Wii绝对是游戏性最强的,但是Sony和Microsoft却用巨大的投入,高分辨率的精美画面弥补了他们游戏性方面的差距,最终也得以在这个市场上分到了一杯羹。
  • 科学彻底取代了艺术,成为了软件工程中的主流。我这里所说的科学,指的是经过总结和归纳,可以反复重现的过程;艺术则恰恰相反,指的是那些偶然得到的创意和灵感,是不可重现的。软件的工厂化生产,是无法容忍大量的艺术手段存在的,而一款让人惊叹的软件,却又一定要有一些艺术性的东西在里面。这恐怕就是工厂化软件生产的最大悲哀了吧。

软件生产工厂化之后,把人变成螺丝钉的管理;为了重用和大型团队协作,而不得不牺牲性能,使用那些最终拯救了巨型服务器产业的复杂庞大的框架和规范;用金钱代替创造,最终甚至可以用钱来达到甚至超越创意所能达到效果的做法;以及那些投入巨大的成本,完全用科学的方法实现出来的缺乏艺术感的软件。所有的这一切我都不是很喜欢,但是随着软件所需解决的问题越来越复杂,好像这成为了未来软件产业发展的必然趋势,软件生产将变得越来越工程化、工厂化,越来越无法被一个或很少的几个人来完成。

这个时候,产生了一种完全具有颠覆性的东西,那就是云计算。云计算不是一种技术,在技术上它没有什么革命性的创新。也很难形容云计算到底是什么,所以我在前面写的是一种完全具有颠覆性的东西。如果一定要说的话,我个人认为,云计算就是:“一种社会公共资源的重新分配和个人或小团体更加容易获取这些资源的方式。是社会分工进一步的细化,劳动生产力进一步提升的标志。”。

说得在通俗一点,云计算就是虚拟化。把原来那些属于大型企业或机构的资源,那些完成某些需求,所必须的资源,虚拟化到云端去。比如:一个公司,需要一套可伸缩的服务器架构,能够随时随地的适应用户访问的需要。以前,他们只能自己购买服务器,在用户增加的时候,再添加服务器,如果用户减少,就让服务器资源浪费掉。现在,这个公司可以将其所需的服务器虚拟化到云端去,在他们的用户不是很多的时候,只需要向云服务平台申请少量的服务资源,在用户量增加的时候,可以从云计算服务平台中平滑的得到更多的资源,如果用户数量再次下降,他们所需使用的云服务资源自然也就随之下降了。在云服务介入之后,他们所需支付的费用,仅仅是为他们购买那些真正使用掉的云服务资源。可以虚拟化的东西很多,比如一个公司里面总要有人事管理,要有各种行政、IT、财务、仓储和物流等等和公司主营业务相关性不高的业务,这些东西都可以被虚拟化到云端去,由专业的公司来提供专业的服务。这样的话,一个公司,不论规模大小,都可以更加专注在自己的主营业务上。哪怕只有一个人,也可以使用运服务平台所提供的社会资源,来完成那些以前只有大公司才能完成的任务。

云计算使得骑士们又有了用武之地。以前完成复杂软件,必须要使用大型的团队。现在,那些团队所积存下来的代码,可以被他人所使用。那些复杂的开发过程管理系统,被虚拟化到了云端。甚至一些个人绝对无法完成大型复杂应用系统,本身就变成了云计算的服务平台,使得那些需要类似功能的个人或团队,可以非常简单方便的直接调用这些系统。举个例子,对于网络游戏来说,客户认证系统、续费充值系统、计费系统、客服系统都是不可或缺的,建立这些系统,并使其良好的运作,是需要投入大量成本的。一个小团队,甚至是一个人,有可能能够使用越来越丰富、越来越方便的中间代码库或资源库,开发出一款网络游戏来,但是他们很难自己建立起能够让游戏顺畅为玩家提供服务的整个体系架构。在云时代,这种问题是怎么解决的呢?虚拟化,把所有这些服务,虚拟化到云端去。盛大在线,就提供了这么一套云计算的服务平台,可以为所有想开发游戏类应用的团队,提供用户认证、续费、计费和客服等服务。当然,这套平台并不仅仅是为了游戏类应用服务的,其他有类似需要的应用,也可以使用这套服务体系。有了越来越丰富、完善的云服务架构平台之后,一个人,或少数几个人创造出优秀软件这件事情,又成为了可能。骑士们在漫天的云霞中,又回到了我们的身边。

AppStore为骑士的生存提供了广大的舞台。AppStore最早是苹果为其IPhone手机所准备的应用销售云服务平台。至少就我个人的了解,情况应该是这个样子的,是否还有其他说法,本文不做研究。本系列文章都不做研究,只谈想法。这种方式,将软件的发布、下载、更新、付费购买等过程,虚拟化到了云端。并将单个软件的价格降低,使得很多需要或自认为需要这些软件的人,可以很方便的得到他们所需要的内容。AppStore是一个革命性的东西,这也就导致了,后来的Google为其Android手机所建立的Market,MeeGo平台,甚至是Ubuntu平台上,都开始出现了类似于AppStore的体系架构。具体AppStore的介绍和关于AppStore的一些想法,以后会在别的博文中再做诠释。这里只讲AppStore和骑士的故事。AppStore或Android的Market中,大量软件的本身的规模并不大,不论是苹果还是Google,为了能够让个人或小团队快速的在其平台上开发出应用来,都下足了功夫,尽量将平台搭建的更加简单方便。由于AppStore所面向的客户平台,大多是手机。在这种运算能力受到极大限制的地方,大型团队也很难找到施展的地方。所以,可以说AppStore是专为骑士们所准备的舞台。现在能够在AppStore上看到的应用,其结构和逻辑都是非常简单的,所需运算等资源通常都不是很多。这些软件的优劣,主要是由创意而不是投入多少来决定的。所以,我们已经看到了很多令人感到惊叹的软件,在AppStore中不断的涌现。而且,我相信,AppStore中还会不断的涌现出更多的,令人惊叹的软件的。我要说,AppStore是骑士的舞台,并不仅仅是因为,AppStore上的软件大多是由小团队或个人来完成的,而是在这些软件中能够更好的体现效能高于重用、创意重新替代金钱,艺术高于科学这些骑士时代的软件理念。

新的骑士时代与传统的骑士时代的比较。骑士时代的重新降临,并不是历史的倒退,而是历史螺旋性的前进过程。现在的骑士,不再是以前的骑士了,他们的工作方式、使用的工具、产出结果都有了根本性改变。他们大多还是独自在工作,但是现在的骑士们,可以很方便的和分布在全世界的松散团队进行合作。可以使用虚拟化到云端的开发过程管理系统,使用大量的成系统的中间代码库或资源库。现在的骑士们,可以比他们的前辈们更加轻松的开发出更绚丽的应用。可以使用前面工厂化时代所遗留下来的所有知识和技能的积累,可以使用部分工厂化的管理方式来进行小团队的管理,可以使用云计算服务平台,来为其用户提供低成本的网络服务。当然,骑士终究还是骑士,现在的骑士们虽然拥有了比他们的前辈更加先进、更加丰富的武器装备,但是毋庸置疑,他们还是骑士。独自面对各种困难,靠着坚韧的意志和天马行空的想象力,在比较低成本的体系架构下,完成那些他们的前辈不可能完成的任务。生产出比那些工厂里面生产出来的东西更加高效、更加有创造力、也更让人感到惊叹的作品。他们更加注重软件的容量和效能,而不是团队协作和代码重用。新的骑士,是和他们的先辈们截然不同的一群人,但归根结底,他们还是骑士,并将使用骑士的方式,战斗下去。

工厂不会消失,他们将和骑士并存。就像工厂时代,骑士没有消失一样,骑士时代,工厂也不会消失的。甚至会比原来的工厂时代,得到更加迅猛的发展。新的工厂,需要为骑士们打造更加精良的装备,为他们提供更加广阔的舞台。新的骑士时代,必然是一个工厂与骑士并存的时代。

最后,让我们一起来迎接全新的骑士时代吧!为骑士欢呼!

Blogged with the Flock Browser

今天早晨,我们对云计算平台上交的第一份作品进行了验证。得到的结论是:我们所收到的第一份作品,是一份有效的作品。
这个童鞋使用的是Java,基本功能都实现了,所有的脚本,都可以顺利的被解析和执行。
他把所有的脚本保存在服务器的一个特定的目录下,然后分别通过web的方式去进行调用,在输入参数之后,得到了正确的结果。
源代码还没有认真的看,想来应该相差不是很远吧。如果没有其他童鞋继续上传作品的话,我们就不需要再去看代码了,可以直接把一等奖发给这位先来的童鞋了。
当然,还是希望能够有更多的童鞋提交更多的作品,毕竟要发的奖项还有很多。而且,现在有两道题目了,如果有人同时完成了两个题目,那么肯定比我们这位童鞋,更有机会得到大奖。
我们正在为所有能够提交有效作品的童鞋们准备一份入围奖品,现在是按照100份来准备的,希望大家能够踊跃的参与。

Blogged with the Flock Browser

截止到目前为止,已经有一份作品上传到牛人技术大赛的网站(http://ic.sdo.com)上了。我们正在处理这份作品。好几个评委都在看。
可能是部署环境和部署方式的描述写的不是很清晰,所以还需要沟通一下。看看应该如何重现这位童鞋的作品。也就是现在作品还比较少,我们还有时间对每一份作品,进行逐个的沟通。
我们也从此看出了,好的文档,是多么重要了。而且,现在的童鞋,就和原来我们自己刚刚走出校门的时候差不错,写程序不怕,写文档,却千难万难。要知道,有的时候,文档比程序本身还要重要。
总之,现在已经有人开始提交作品了,请其他童鞋,也可以开始提交了,趁着现在作品还不多,早些提交上来,您的作品会得到更认真的对待的。
最后,预祝所有参加本次比赛的朋友们,都可以得到好成绩。当然,希望第一位提交作品的童鞋能够获奖,后面的童鞋,也还是很有机会的。

让我们一起来体验云计算吧

今年年初的时候,一位领导布置了一个任务给我,那就是出一道题目,在盛大高校节上,考一下那些参赛的同学。
当时的想法是,云计算是现在非常热门的技术,想必也是同学们比较关注的方向吧。但是,云计算的服务平台,大多是掌握在一些大公司的手中,普通的同学可能使用过一些云计算的服务,对于服务平台来说,大多比较陌生。正好可以趁此机会,让同学们可以和云计算的一些底层服务进行一次亲密的接触。
对于像盛大这样拥有超过四万台服务器的集团公司来说,再也没有什么是比云计算和云服务再合适的发展方向了,盛大也在努力的打造符合中国娱乐市场需要的云计算服务平台。盛大举办高校节的根本目的还是为了网罗人才,网罗那些对于盛大未来发展有所帮助的人才。结合盛大的发展方向,那么出一道云计算相关的题目,就是再正常不过的事情了。
有了上面这些背景和考量之后,我就开始为了出一道什么样的题目而苦恼了。毕竟,让同学们能够感受云计算的技术、云计算的商业模式、以及云计算的基础精神,而且还要考虑到同学们的经济基础,以及不能占用同学们太多的课余时间,所有这些前提放在一起,都要考虑和兼顾到,确实是非常困难的。
现在所常说的云计算,实际上是分为三个层次的。也就是基础架构虚拟化、平台虚拟化和软件服务虚拟化。
基础架构虚拟化,就是将存储、网络、运算能力等基础设施,虚拟化到云服务平台上去,用户通常是以远程虚拟机的方式来访问这些资源的。还有一些提供基础的存储服务,使用者可以通过云存储的接口直接进行数据的存储操作。对于这类系统来说,如果让同学们自己来搭建,难度实在是有些大,而且更关键的是工作量巨大,测试困难。所以,最终放弃了在这个层面选题的打算。
软件服务虚拟化,是将原来一些由各个公司自己采购,自己运维管理的一些软件或服务系统,虚拟化到云服务平台上去。这部
个层次倒是很适合同学们来实现,而且同学们如果能够实现这种应用,也是最能体现成就感的。但是考虑到软件和服务虚拟化本身就是在云计算中边界最模糊的一部分,这部分作品的差异性会很大。这个层次的应用是否成功,策划和运营要比技术重要得多。毕竟这是一个技术大赛,所以最终也放弃了在这个层次选题的打算。
平台虚拟化,也就是将一部分软件服务中间架构虚拟化到云平台上。用户可以在这个虚拟化平台上继续封装自己的应用,再为更广大的用户群体服务。实际上,这次技术大赛的另外一个主办方,盛大在线,就是提出了这样的一个云服务平台。他们已经把云计算平台搭建完成,需要大家在这个名为盛大开放平台的云服务平台上搭建自己的应用。这部分,边界清晰,主要考察技术能力,所需的人力物力成本也不是很高,所以最终决定在这个地方下手,出一道题目。
我最终选择的题目是云计算脚本虚拟机,可以让用户上传一些脚本,运用云计算服务平台,来为用户提供脚本解析和运行服务。
在脚本的选择上,考虑到同学们实现的难度。将大部分的功能都去掉了,只要能够实现一些基本的脚本功能就好了。关键是体验云计算的服务的基本精神。详细要求见:http://ic.sdo.com/norm_1.php
后来,同事们说:你这个并不能完整的体现云计算的精髓。没有办法,为了降低同学们的工作量,已经将题目中的内容砍去了太多太多了。为了能够让同学们更进一步的体验云计算的精神,我们又补充了一道题目,那就是大规模并行日志分析,主要是让大家尝试一下如何使用Map Reduce的方式来进行大规模数据分析和处理。具体要求见:http://ic.sdo.com/norm_2.php

让我们大家一起来体验运算基础平台的搭建过程吧。有兴趣的朋友请直接访问:http://ic.sdo.com

Blogged with the Flock Browser
Close Bitnami banner
Bitnami