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

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

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

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

直接形象一点吧，假设我们要做的事是：一次性炒一份让全北京市的人一顿吃的一道大白菜，假设大约需要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日

于珠海诚开智能