2014-10-16-bigdata-and-actor

Posted on October 16, 2014

漫谈BigData和Actor 根据我的观察,最近两样东西比较火:Hadoop和Actor。一时流行的东西也许只是昙花一现, 不过这俩星星之火大有燎原之势。 Hadoop估计人人耳熟能详了。 从BigTable被提出,到yahoo将自家实现的“BigTable” Hadoop开源给全世界, 今天世界上各个角落都运行着大数据的Hadoop集群。 不知什么时候开始数据从方方面面爆发出来,再也无法在原来的关系型数据库里落地生根。 为了存储这些大量涌现的数据,为了合理的处理这些数据,为了支持快速的对数据进行各种各样的数据分析,需要存储的数据量在原有的RDBMS基础上再上一个数量级。 尽管RDBS集群可能有100多台机器,说起来也能存很多数据,可惜它们并不是设计来处理这样大量的数据的,因此面对苛刻复杂的现实要求它们还是无能为力。 有点像农业时代出现了蒸汽机,整个社会都被改变了。

我必须得插一段:我不久之前还不是这么想的。 那个时候,我总觉得人们太矫情了,哪儿来的那么多大数据。 一个很大的跨国公司,整个公司的重要数据, 汇总在一起一天也不过几个Giga, 多算一点几十个G,还是不需要大数据平台来处理。切成几十份还是原来一样处理,我当时的结论是:RDBMS+旧的系统架构并没有过时。 必须得承认,人得视野被他所处的位置所局限。 一家表面上大的公司处理的数据不多并不能说明其他的小公司处理的数据不多, 不同的行业, 不同的客户, 不同的产品满意程度都定义了对数据的不同需求。 一个简单的结论,数据量处理量不大的软件系统很难对这个社会有多大用处。 这个社会真的有太多的数据可以处理了:人们访问浏览器产生数据,商家对这些数据进行分析可以获得行业利益,广告行业对这些数据进行分析也能给用户和广告主都带来好处。

大家都纷纷效仿Google的大数据,Google却傲娇的说:BigTable这种架构已经过时了, Google内部已经开始使用流式处理系统了。 也曾经聊起这个话题,MapReduce还是作业式的,批处理式的, 数据处理的时延不理想。 而Google所说的流式处理系统大概能够克服这一缺点,做到实时性很好的大量数据分析。

还有一个一直很受关注的项目就是Actor了,常年排在我关注的Github项目的活跃项目顶端。Actor是一个致力于提供低延时高并发的网络编程框架。 仍然记的若干年前提起高可靠,低延时,高并发的网络系统的时候,人们讨论的还是高性能的硬件,系统底层调优,Cache优化,多线程。 而现在更多的系统考虑扩放性设计,在资源无法满足需求的时候只需要扩放硬件就能满足增长的需求。 甚至将硬件投放到开放云平台上,跟据实际使用量对硬件使用付费。

上个世纪80年代,电信巨头爱立信就已经提出了这样的系统设计目标,并且成功的设计出了Erlang语言来解决公司电信系统的需求。 接下来的这些年里爱立信的Erlang取得了巨大的成功:5个9的稳定率,极少的故障率, 系统即使升级也无需停机。 直到今天Erlang系统仍然在爱立信的主干电信系统里面稳定的运行着。 这些传奇使得Erlang收到关注,Scala/Actor大量借鉴了Erlang的这些设计哲学, Akka Actor现在能够以极小的代价做到高并发,1G的Heap能够容纳1M个Actor同时工作。 并且Actor能够跨越物理机器完美的scale,如果Actor的处理能力不够了,那么只要增加物理机器启动新的Actor即可。

和同事聊到在线的集成开发环境(Atom,Cloud9)的时候就设想了这样的画面:未来人们不需要带任何很占体积的计算设备, 计算随手可得,计算无处不在。 总觉得现在的节点是:计算机的硬件价格已经下降到一定程度,可计算的设备已经普遍容易获得。 现在和10年前不一样,现在的物理计算机也成了软件体系抽象的对象。 在现代的框架看来,计算机就是无差别的计算单元,唯一的目标就是能够执行计算任务, 如果计算力量无法满足, 那么明智的做法是买一些便宜的硬件而不是现有的硬件限制上钻牛角尖。这并不意味着物理机器的性能调优并不重要,只是说我们只需挖掘出硬件95%的潜力, 剩下5%的相对困难的硬件潜力就不再继续投入大量的人力物力。

瞎扯了这么多,这两个东西也实际接触过一点:

Hadoop,这已经不是一个项目了,已经包含了一打项目。 从接触这个项目开始就不停的听说新的名词:Hadoop,HDFS,Hive,Pig,Oozie,Solr。 每一个名词都是一个相对独立的项目,而且还有模有样。 环境的搭建也异常复杂, 环境的搭建尚且这么复杂实际的使用恐怕更难。 还有那些喜欢研究源代码的人,大数据的框架你从哪里下手呢?

Actor在reactive programming课程里用过, 也读了一些源代码。 使用起来感觉十分简单,没有复杂的安装,便利的配置,测试驱动套件。 相信Actor框架能够做到Erlang的那种程度,帮助很多企业开发这样的低延迟高并发系统。

==