信息化的本质分享 http://blog.sciencenet.cn/u/Babituo

博文

从架构看大数据和云计算的关系

已有 13239 次阅读 2015-1-31 12:43 |个人分类:面向资源软件开发方法|系统分类:观点评述| 大数据, 云计算, 架构, 面向资源

从架构看大数据和云计算的关系

   

当说到大数据和云计算,乃至超级计算的关系时,很多专家都给出类似的科普级的观点:大数据是大菜,云计算是大锅,炒大菜当然要用大锅,有大锅当然能炒大菜。

比如,当我质疑新闻稿中说“天河一号”用于了大数据处理的说法时,闵应骅前辈给出了如下科普级的解释:大数据需要高速度的计算机。这个解释当然有道理,却还是解答不了我的疑问。我的疑问实际是:巨型机“天河一号”在架构上是如何支持大数据的计算的?它有支持巨型机实施大数据计算的架构么?

为什么会有此疑问?因为炒大菜的充分必要条件,不仅仅是有足够的地方存放足够多的食材,和有足够多的锅(云计算)或足够大的锅(巨型机)这两项条件,容易被忽视的是:如何才能够将这足够多的食材,怎么放到锅里去抄的问题。这,就是一个架构的问题。

直接形象一点吧,假设我们要做的事是:一次性炒一份让全北京市的人一顿吃的一道大白菜,假设大约需要1000吨的白菜吧。和我们平时家里吃一餐的几颗小白菜相比,算是大数据了(不很贴切,要贴切是可以的,但太罗嗦,“砖家”不要急着拍砖)。好,这么多的菜需要一锅炒出来,得需要一口多大的锅(巨型机)啊?或需要多少口不小的锅(云主机)同时炒啊?

好,假设我们要为此建一个超级大厨房(云计算中心),需要在20分钟内完成炒菜装盘送到餐桌前的过程,否则,菜就凉了,要不然,全北京市的人排队吃这“一顿午饭菜”,可能要持续进行一个月的时间。

咋办呢?这厨房得建成啥样的呢?怎么运作呢

让我来设计一下吧:

我们不能从农民的地里把这1000吨大白菜(大数据)用大卡车运来直接倒进锅里煮吧?

所以,我设计了1万个足球场大小的备料场。是这么分组的:100个操场负责卸菜,然后派发到每个卸菜场负责把卸下的菜,分发到100个操场上去进行挑拣,清洗和切细。嗯,知道吧,这就是一个负责大数据处理的集群。因为这些处理要在5分钟内完成,所以,必须是1万个备料场同时进行,分散并行处理,这就是所谓的Map。

切好的菜需要在炒之前地先运到灶台上去吧?所以,100条传送带把切好的菜料汇聚到一条超宽的传送带上,再由这条超宽的传送带送往灶台。这就是Reduce了,我们的传送带(网络)有足够的带宽,把这些菜料3分钟运到灶台是没问题的。

假设1口大锅(主机)一次3分钟大约可炒熟300公斤的洗好,切好的大白菜,假设有10分钟的时间来炒菜,那么,一口锅最多炒3轮,也就是900公斤,我们需要1000口这样的锅。实际上是不是这样也没关系,反正就是1000个下料口,1000个出菜口,里面到底是多少口什么锅无所谓,可能是3000口100公斤的大锅;也许是30口10吨大锅。经过“虚拟化”,从外面看上去就是1000口300公斤大锅了。每口大锅不会同步开炒,同步完成,炒的菜会给谁吃,也说不准。反正,尽量给这个炒完,可能歇会,再给下一个炒。如果吃菜的人不动,是给人炒菜的锅移动到吃菜的人跟前来炒,那么,看上去就是炒菜锅象天上的云一样在流动。流动到哪,就给那的人炒菜。所以,叫“云炒菜”,不是忽悠人的,而是为了让人好明白才这么叫的。

好了,“云炒菜中心”的架构就这么设计好了。我们可以看到,里面实际有两个中心:“理菜中心”和“炒菜中心”。理菜中心解决的要炒的菜多,排队炒等不起的问题;而炒菜中心解决的是吃菜的人多,每人一个专用锅浪费的问题。大数据处理和云计算,实际上目前还只是在不同的场地上,由不同的家伙式来干的不同的事。但由于只有一个名字:“(云)计算中心”,很容易让人误以为,只要是有这个名字的地方,就可以两种事都做齐了。而实际的事实是:大多数的有这个名字的地方,要么只是理菜中心,要么只是炒菜中心。能合二为一的地方,意味着它里面,大数据和虚拟云计算这两套家伙式(基础设施)都得有,而且必须能配合得起来。

比如,那个巨无霸,我是很怀疑在它的周围是否设有“理菜中心”的。巨无霸提供的只是炒菜的能力强准确地说,只是快,可能人家炒一锅,它可炒10万锅,“锅”当然也不小,能不能一轮就炒出一个大菜来,还要看有没有给它配一个自动供料的“理菜中心”。

我怀疑的理由是:让我们看看现在世面上的厂家的做的厨房和各家所用的厨房吧,你会知道我的怀疑不是胡思乱想的。

好,就让我们以云计算为例,来检视一下目前的云计算架构和大数据处理的架构吧,看看在架构上,我们是否已经准备好了“同时既能容纳足够多食材,又能容纳足够多的炒锅”的厨房和灶台了吧。

 

先看IBM的“蓝云”

看吧,这框出来的部分,显然只是一个大“灶台”-虚拟云计算环境。而作为理菜场的“大数据”在哪?难道要建在虚拟网络里吗?大数据可是实打实地需要网络吞吐量的哦,好吧,就算可以建在虚拟网络里,而且我们这100个大操场确实是从一块有足够大面积的场地(存储空间)中虚拟出来的,可难保这100个大操场的100张大门,不是从一张门虚拟出来的啊(是否有足够的网络与存储设备间的带宽,值得怀疑),尽管这张门也可能比较宽,但要做到真实所需的100张门这么宽,就没有虚拟的必要了。要知道,大数据处理,是依靠真实可同时开进开出的通道,才能做到并行“捡菜、切菜”的啊!

 

再来看惠普云计算解决方案吧。

是不是也是一个大“灶台”,它告诉你,那1000个炒菜锅,或许是100个刀片服务器虚拟出来的。而且,它还直接明了的告诉我们:服务器存储网络SAN是独立架构的。不管其SAN是用超融合设备还是用纯软件解决,总之,网络内的存储资源已被统一池化。这意味着:虚拟出来的主机系统,即便可以用来当作大数据处理的某个结点(一块理菜的场地),但这块场地的门,是否独立,能否支持全部主机的并行数据进出,是个大疑问。



再来看个国产的华为的吧

华为没有把大数据平台和云计算平台混谈。

这是其大数据平台架构:


显然,这个架构和“虚拟化”,池化无关。一个Hadoop集群完成“理菜中心”的任务,是比较完整的电信级的大数据解决方案。

  

下面这就是华为的“大灶台”虚拟云计算中心了:

厂家的看到这了,看到这,我们应该明白这个道理了:所谓云计算平台和大数据平台是两个不同的平台,我们在云计算平台中看不到集群的影子,在大数据平台中,看不到虚拟池化的影子。而不是所谓的:只要是云计算,就是用大锅炒大菜了。大数据和虚拟云完全是两个可以不搭边的不同应用。当然,也可以搭边,但要搭边,就一定要同时拥有这2套系统,才能用大锅炒大菜。在这,我只是打出了IBM和HP的“炒菜中心”方案,相信,IBM,HP也有自己各自的“理菜中新”方案。



下面来看玩家的。当然,先看亚马逊的。

这是亚马逊的弹性云平台EC2


这是一个真正把“理菜中心”和“炒菜中心”整合在一起了的一个方案。其弹性大数据处理MapReduce部分是一个相对独立的架构,底层跨在Ec2 Instances和S3 之上,意味着,这个独立的大数据处理平台,是构建在虚拟的计算资源和虚拟存储资源基础之上的。所以,我有点怀疑这个架构的大数据处理能力和效率,应该不会比Google强。

 

好,立马来看Google的云架构



看到了吧,Google是干什么的,Google的云架构主要是由N多个Node组成,每个Node其实就是一个“理菜中心”,所以,google的“云计算”里面,其实没有云计算,只有大数据处理。基于GSF的MapReduce是Google干的最多的活。他们不出租计算主机,所以不提供虚拟云。

 

微软的是个灶台,不用多说了,看下图就知道:没有大数据,只有虚拟资源服务。





下面看国内玩家的



百度在架构上显然是同时支持“炒菜”和“理菜”的,这点和亚马逊相当。和竞争对手Google比,至少在架构上设计更全面,可支持更丰富和开放的服务。当然,从实际开发的IT应用项目的数量和先进性而言,google领先于百度是毫无疑问的,但这和云计算架构无关。也就是说,作为一个平台,百度至少是不输给google的。

 

本来不想看的,还是来看一下“阿里云”吧


阿里云的架构显得很怪异,它更象一个独立的网络版应用系统,也就是一个功能级的应用支撑平台,而不是一个通用的系统级网络应用支撑平台。其架构从图示上看给人个感觉就是“混乱”。整个数据中心作为底层,之上支撑的仅仅是一个操作系统Linux,似乎是Linux装载在“数据中心”这个“裸机”上。再往上的层次也是,似乎是想将整个阿里云当作一台电脑来打造一样。

这个想法比较独特,但在技术支撑上,很可能被主流的云计算平台架构技术“吞没”。尽管阿里有钱了,这么任性,风险还是有点大。从应用的角度来看,阿里云的架构似乎只能支撑自己的一盘大菜,老百姓各炒自己的小菜,便是他的大菜。

总的看来,阿里云不是一个技术云,而是一个业务云。说白了,大数据系统是系统之下的系统,云计算系统则是系统之上的系统,阿里的架构师看来是不懂这个,或者太懂这个了,居然可以集成得像一台机器。如果是后者,其野心大得有点可怕,当然,也就风险很大。

 

接着从纯技术的角度来看下大数据和云计算的通行架构吧。

大数据,当然,以目前仍占主流的Hadoop为例,尽管它应该很快被Spark所替代掉。

写到这,不免让我有所慨叹:我们国内的技术跟风者,简直就像我们A股市场上的散户——如果把国际云计算技术比作A股市场的话。看看人家的顶尖大学在做什么,而我们的呢?难怪,当我发出豪言要超越他们的时候,显得那么“蚁马赛跑”。好在有“蚁群算法”,而没有“马群算法”,赛就赛吧,期待蚁王驾到,蚁群出现。



不用讲了,我已经讲过了,这就是个“大白菜料理场”而已。所有的技术概念都可以和大白菜料理场的概念对应上,你丝毫不必觉得它有什么神秘。如何映射概念,由于时间关系暂时也不展开了。

 

 

 

更想说说Spark的架构



说是Spark的架构,还真不如说是Spark的生态。说生态的感觉确实比架构的感觉舒服很多。多种物种的共生环境,确实比冰冷的组件、构件、模块结构相互支撑互动的系统,让人感觉温暖得多。计算机架构仿生的理念,总算逐渐被“发源”了——显然,这不仅仅是心理的温暖感的需求,而是技术质变的需求。

这里只说RDD,Spark的核心创新:抽象的弹性分布式数据集。还是用比喻来说科普一点:如果说MapReduce的机制,是生产线上的“皮带传动”运输处理线的话,RDD就是叉车托盘运输处理流程线。关键差别在哪?在分散数据在处理过程中的共享。当然,这意味着RDD必须比Mapreduce支持更多的操作,这些更多的操作支持,最终可使数据处理更灵活和流畅。可见,这种生态感是从骨子里透出来的。

这里不得不提一下我发现的“资源”概念。RDD是最接近资源概念的数据集概念,但还没有达到资源概念的创新高度。何以此说?资源是一种“分布式弹性对象”,走看吧,我敢打赌,未来RDD的升级版提出类似“分布式弹性对象”、再发展下去,当国外大拿们提出某种“软件组件虚拟化”的技术概念来的时候,国内的跟风卖力者必定又将趋之若鹜。殊不知,蚂蚁已经走在骏马之前了,可谁会跟蚂蚁的风?蚂蚁就算没命奔跑也带不起风啊。哦,原来,是“跟风”这种行为的错,群可不是靠跟风来形成群体智慧的啊。

顺便提下REST,RESTful和“资源”的关系。最早的互联网是把数据资源化,接下来是把软件服务资源化,也就是RESTful,云计算环境下的互联网把硬件资产资源化了,当然,SOA走到了云计算的前面是一种阴差阳错,差错在SOA是软件服务的行为化。走在云计算后面的软件服务,将是:将资源进行到底——软件组件直至程序逻辑和语句的资源化。

RESTful是把用代码程序语言开发的软件资源化,而我的面向资源开发,是用虚拟化的软件资源开发程序。本质相同的是资源化的方法手段,本质不同的是资源化的架构层次。

资源化,就是虚拟化,云化,池化。其背后的本质,是将“分享、共享的技术机制(请决不要理解为仅仅是精神意念)”沉淀到底。RDD正是走在这条路上的“先行者”(先行马,前面还有只“先行蚁”,是资源,呵呵)之一。

 

 

一般云计算架构,上刘鹏的图了:


我猜这个刘鹏就是当面在北大推动网格计算的那位刘鹏。记得我和他通过一封邮件,邮件中我很赞赏他的工作和网格计算的理念,是将混沌的互联网引向有序的起点。他也给我回过邮件表示同意我的观点。

 

最后,给出我描绘的未来云计算的通行架构


最后,表达个人期望:我非常希望能加入一个类似“透明计算”团队这样的国家队,把面向资源开发的这只蚂蚁变成一匹骏马。最终让质疑我们国人技术创新能力的人闭嘴,让国外厂商来跟我们的风。

除最后一幅图,图片来自网络,版权归其作者所有

 

邱嘉文

2015年1月31日

于珠海诚开智能




https://wap.sciencenet.cn/blog-33982-864350.html

上一篇:“顶层设计”设计什么?
下一篇:对“顿悟”的顿悟——TRIZ理论
收藏 IP: 218.13.226.*| 热度|

3 张利华 陈辉 李亚平

该博文允许注册用户评论 请点击登录 评论 (3 个评论)

数据加载中...

Archiver|手机版|科学网 ( 京ICP备07017567号-12 )

GMT+8, 2024-3-28 20:49

Powered by ScienceNet.cn

Copyright © 2007- 中国科学报社

返回顶部