vlambda博客
学习文章列表

• 北京东北旺羊肉馆的双升局

• BigData就是MapReduce

• MPP SQL与Hive SQL

• 冷哲眼中的MapReduce与MPP

• 大数据发展绝不是从Hadoop开始的

• Grid Computing与Cluster Computing

• 大规模并发

• MapReduce与MPP

• KeepS系统

• Hive导出到关系型数据库是一种拙劣的方法

• 混合跑批引擎

北京东北旺羊肉馆的双升局

2014年12月，北京的天气已经步入寒冬。

MBI公司的弹性工作让大家早已经习惯了作息颠倒。

下午3点，MBI架构师严道希、和Hadoop Dev冷哲、运维二强、实习生小谢陆续背着一个印着大大的「Think」的双肩包陆续来到公司。

冷哲往电脑挂上锁扣，打开公司配的Thinkpad T430，半躺着翻阅资料，他想要找到一个适合建设全球性服务数据仓库的方案。此时是选型的关键。

下午6点半，天渐渐黑了起来。严道希吆喝大家吃饭，公司楼下的餐厅实在做得实在太差了，汉王的食堂这会也没啥东西吃的了，所以大伙决定去喝羊肉汤。东北旺往北的那个村子还没有拆迁，老板是典型的东北人，一看到这哥4个来了，赶紧吩咐后厨，「4碗加肉羊肉汤，烧饼4个」，然后让服务员把两张桌子拼在一起。严道希从口袋里掏出两副扑克牌，4人开始玩起来了双升。

严道希一边抓牌，一边叼着烟，悠闲地问到：

「 冷哲，引擎那块进展如何？」

冷哲眉头紧锁，将牌按在桌面上：

「 MapReduce和MPP，这两个比较难选。如果传统一点，我们选MapReduce，要踩的坑要少点，我这边也比较熟悉。但MPP也有很多优势的地方。我们的科学家用起来应该会更顺手，但不知道我们要踩多少坑。」

严道希从嘴里吐出一律白色的烟雾，然后又倒吸了回去：

「 这两个家伙之前挺独立的，但最近好像界限好像有点模糊了。」

旁边的运维二强耷拉着脑袋：

「 怎么这么快牌就没了？这一手烂牌，咱不玩了喝羊肉汤吧。你们要搞事情啊？Hadoop那一堆就够我们折腾了，又搞MPP。合着半夜起来的总是我，哥几个能不能靠点谱啊。」

严道希呵呵一笑，

「 没人亮主，那我亮了。」

冷哲接着二强的话茬说到：

「大哥，咱也不能就吊死在Hadoop上。得抬头看看窗外，不能因为麻烦就放弃改变。实在不行，如果上了新组件，我陪你一起过夜。」

二强嘿嘿一笑，严道希刚放下底牌，他就一把抄了上来，

「去你的。谁要你陪啊，你程序搞利索点，少半夜让我爬起来就好。」

严道希看到二强抄了底，忙叫苦连连，「废了、废了」。

他看了看冷哲：

「 冷哲，聊聊MapReduce和MPP呗。说说你的看法。」

冷哲一边捋了捋牌，「 这从哪儿说起呢。我先组织组织啊。」

旁边的实习生小谢催道，「快说快说，最近FSM team有个新产品刚好也用到这些」。

BigData就是MapReduce

冷哲深吸了一口烟，吐出一股浓浓的烟雾：

「 我们比较熟悉的MapReduce的玩法，简单来说就是把HDFS上的大文件，分成一个个的批次，然后分别独立地去处理。拿HDFS来说，它就是扫描集群上的一个个块，然后处理计算，再将多个节点上的输出合并起来得到结果。」

二强这一手牌很顺，

「 你说的这个我知道。Big Data不就是MapReduce嘛！」

严道希不屑地看了一眼二强，:

「 那MPP就不是Big Data了吗？狭隘！我们不能只看到Hadoop在发展，MPP数据库其实也在发展。Hadoop、Hive这些可以说是新型的数据库，但传统的数据库也不是没有发展空间。Hadoop也好，MPP也好，也都是得到市场认可的。」

小谢有点饿了，一边催促着服务员赶紧上羊肉汤，一边问到：

「弱弱地问下，啥是MPP？」

冷哲淡淡地说，

「MPP是对规模并行处理的简称。它和MapReduce很像，也是以独立的节点并行处理数据，然后将处理后的数据组装在一起得到最终的结果集。」

小谢接着问，

「 照你的意思， MapReduce和MPP是亲戚呗，有血缘关系。」

冷哲继续，

「 你可以这么理解。」

严道希摇了摇头，这把牌烂完了，被二强抄完底，根本没法玩了，

「 之前公司其实也收购过一个MPP产品。虽然MapReduce和MPP是亲戚，但场景还是不太一样的。你看公司那个MPP部门的客户哪个不是财大气粗的，买设备跟买白菜似的。你看看隔壁的EMC不也搞了一个并行数据仓库么。一会回公司，我们还得找个会议室聊聊，我把另外的几个Dev约上。至于MPP和MapReduce，冷哲后边可以单独搞个training。」

这时，梳着齐刘海的漂亮服务员妹子端来了羊肉汤和烧饼，大家赶紧把牌撤了，各自端上一碗，猛放了几勺辣子，狼吐虎咽起来。

MPP SQL与Hive SQL

吃完饭又玩了几把，严道希手气背得很，一直输。于是，拉着大家回公司。从羊肉馆出来，天已经黑了，远远地看见前面的软通动力的大楼灯火通明。

冷哲继续之前的话题说道：

「 我之前看到的也跟老严说的差不多，大家上MPP一般都是搞的高端硬件，很多厂商搞的都是成套解决方案。咱们现有机房的老破旧，不一定能玩起来。」

二强接过话茬：

「这个大项目，你们只管先提需求好了。只要不太过分，power系列也是可以的。」

「那就好。我们搞的这个项目很有可能MapReduce和MPP都需要。因为KeepS那个系统的数据我们还得用MapReduce把数据整过来，所以后面有很大可能需要搞几套集群，一套是Hadoop、一套MPP。Hadoop集群的硬件可以配低点，但MPP要配好一点的机器。」

冷哲背着双手一边踢着路上的小石子说道。

小谢乘机问了下：

「 冷爷，你说的这MapReduce，要写Java了吧，这数据处理起来很是费劲啊，出了问题，排错、调试成本很高啊。而且有些问题，我们只有到product上才能发现。」

冷哲又是一脸鄙视：

「现在谁还玩MapReduce哦，都用Hive了，写SQL就行。」

严道希听到冷哲说到Hive，说道：

「 冷哲，你给他们说说，Hive也是写SQL，MPP也写SQL。有区别吗？」

冷哲嘿嘿一笑，

「这个区别我说直接一点吧，写Hive不懂MapReduce举步维艰，其本质上还是命令式的，调优啥的跟Java非常紧密。但MPP更适合以前那帮做数据库的，Native的声明式SQL，效率自然也更高，你看看咱们的客户不也是有很多用MPP搞数仓么，有的客户用HP的Vertica、还有的用EMC的Greenplum。你跟他们说Java，看他们鄙视你不。老老实实在MPP上写SQL不也挺好吗？省事省心。」

严道希也笑了笑，

「要想省事省心，还是那句话，钱花在哪儿哪好。自己搞，还得脱层皮。我草，咱们走快点，James在找我。」

四人加快脚步，匆匆回到公司。

冷哲眼中的MapReduce与MPP

会议室冷哲几人已经列席，今晚要讨论关于项目的引擎选型问题。会议开始之前，冷哲先跟大家继续聊MapReduce与MPP。

大数据发展绝不是从Hadoop开始的

冷哲清了清嗓子，先吐槽了几句。

「我很厌烦天天张口闭口Hadoop那帮人。那几年，没有Hadoop、Hive就不搞数仓吗？你们去外边的公司里看看，是不是都在用Hive？我并不是说Hadoop不好，只不过咱们还是得搞清楚之前大家是怎么玩数据的。Hadoop这几年开始流行起来，之前MPP数据库应用还是挺多的。不过慢慢不行了，大家看看Terdata的股票就知道了，跌成啥样了。Hadoop是大玩家啊。这几年，有很多公司开始将Hadoop定位为传统数据仓库的替代品，这也意味着它也是MPP的替代品。」

Grid Computing与Cluster Computing

「MPP代表的是大规模并行处理，而MPP数据库也就是大规模并行处理的数据库，例如：Vertica、Greenplum都是。MPP数据库的架构肯定和传统的MySQL之类的数据库架构是不一样的，它采用的是非单机架构。这说到分布架构，就要聊聊网格计算（Grid Computing）和集群计算（Cluster Computing）。」

小谢举手问到，「冷爷，啥是网格计算」

「哦，这样说。网格计算其实还是一个分布式系统，由很多的异构计算机组成一个“超级计算机”，它将分布在网络中的计算机共同来实现数据处理。它可以利用系统空闲的计算资源来执行处理任务。网格计算资源管理是非常重要的。它可以控制提交的任务请求，将任务请求调度到选定的服务器上。这些选定的服务器组成一个网格。任务可以在网格中独立执行。」

小谢接着提问：

「 之前我们这边有一款HPC（高性能计算）的产品，我看那帮三线把它称之为Cluster Computing。这跟网格计算有啥区别？

冷哲给小谢竖起了大拇指：

「这个好问题。我们之前说Grid Computing时，重点提到了异构两个字，Grid Computing指的是异构网络、不同硬件、不同操作系统在网格中连接在一起。而Cluster Computing指的是同构的快速局域网、相同硬件设备、相同操作系统连接在一起组成一个集群，集群计算中的每个计算机称为一个节点，每个节点都具备相同的硬件架构和相同的操作系统。所以，我们一般都说Hadoop集群。对吧？」

小谢一头雾水：

「那Cluster Computing岂不是一种特殊的Grid Computing？不能因为网络、设备、操作系统都一样，就叫Cluster Computing吧？

冷哲继续说道：

「说得不错。Grid Computing是一个更大的概念。你可以把Grid Computing理解为一个超算中心。Cluster Compting一般用于解决数据库、或者是Web应用服务器中的问题。而Grid Computing用于遗传学建模、工程设计、甚至是成吉思汗墓搜索、搜索外星智慧等，有一些工作必须要通过异构系统来解决。例如：一个物联网网格架构中包含了各种传感器系统、数据存储/计算系统、图像/音频处理系统、雷达信号分析系统，这些系统可能分布在不同的网络中，可能一个在香港、一个在多伦多、一个在北京等等。所以，网格计算核心强调的是异构，而集群计算强调的是同构。Cluster Computing可以是Grid Computing的一部分。」

「Cluster Computing运行的任务都是一样的，而Grid Computing运行的任务是不一样的。」

小谢有点似懂非懂，但也不好意思继续问了。

大规模并发

冷哲喝了口在茶餐厅自动售卖机买的红牛，继续说道：

「Grid Computing的两个关键字：空闲资源、异构。基于这种架构的MPP可以将分布在网络中的计算机都利用起来，但因为它要根据可用性机会性的使用资源，这肯定会提高资源利用率，但这就会限制在处理高峰时期能够使用的资源，无法保证稳定的带宽、资源来应对。Cloud Computing就是由Grid Computing发展过来的，云计算侧重于提供资源的抽象和服务。」

「而另一种流行的架构就是Cluster Computing了，它可以将特定的节点连接在一起，提供稳定的资源服务。」

「从概念来说，我认为，绝大多数的MPP都是Cluster Computing。」

冷哲话锋一转，看向严道希：

「问个问题，MPP强调的是什么？」

严道希笑道：

「当然是大规模并发了」。

冷哲冲着严道希挤了挤眼睛：

「没错，MPP强调的大规模并发，我问大伙，MapReduce的同时执行的 任务并发高吗？」

二强回答道：

「高啊，这家伙，集群的负载老高了，同时运行几千个任务。」

冷哲撅了撅嘴，：

「不对，你说的是整个集群。你看当我们去执行一个程序时，MapReduce在Map执行完前，并不会直接启动其他的任务。但如果是MPP，就不是这样了，它会提前让所有并行全部都跑起来执行，每个节点都处理本地的一小部分数据，最后合并出来。这样效率是不是更高？所以，大家看到MPP的效率要高出很多，原生的SQL引擎做的优化也非常的暴力。」

小谢继续提问：

「那是不是MPP适合所有场景呢？」

冷哲嘴角微微上扬，呵呵一笑：

「这就不对了。MPP虽然快，效率特别高。但任何东西都不是绝对的。MapReduce一个阶段一个阶段地执行，非常稳定，每个任务都可以看到非常详细的执行日志，方便排错。而MPP我们能看到的就是物理执行计划了，它不是按阶段执行地，所以有时候调试错误会很麻烦。资源不利于管控。因为MPP任务和执行器是绑定的，所以，假设有个节点处理慢就会导致整个作业性能变慢，短板效应非常明显。另外，MPP的节点越多，出现问题的概率越大。一旦节点出问题，会导致整个集群性能受限。所以，一般MPP集群规模不会太大。但Hadoop集群可以非常大，上万个节点也是没有问题的。」

MapReduce与MPP

冷哲继续说到：

「MapReduce的并行度确实不是最大化的。写过MapReduce都知道，程序主要包含了Mapper和Reducer两部分。而Hive做的事情是将SQL解析为命令式的Java MapReduce，本质上还是MapReduce。如果程序里面有一些聚合计算，是必须要等到Mapper任务都执行完才能继续往下执行。它在资源有限的场景比较适合。还有，现阶段的Hive还是有很多地方和传统的SQL不兼容的，写法上也是要做一些调整的。」

小谢托着下巴一脸迷茫，问了一句：

「我是不是可以理解MapReduce的作业从整体上看是分为一个个阶段串行来运行的？并没有把集群的资源全部利用起来？那能不能把各个阶段并行来处理，不就能提高处理效率吗？」

冷哲笑着说道：

「好问题！要知道Hive就是基于MapReduce引擎，那么有一个限制就是所有的SQL物理执行计划其实都是MapReduce。这个框架的编程模型是固定的，它就是一个阶段、一个阶段执行的。Hive的SQL解析器会分析处理阶段与阶段的依赖，然后调度执行。所以，为什么我们还是说Hive是一个命令式的SQL引擎。我们接着来说MPP数据库了。MPP数据库是由传统关系数据库发展来的。虽然，现在一说Mysql、Oracle之类的，大家可能会觉得有点low。但它还是有很多有点的，就SQL来说，它就是声明式的，计算和存储能够很好的衔接在一起。MPP数据库有一个非常关键的技术，就是它能够根据SQL来找到数据与数据之间的依赖，将能够最大化并行的部分分发到集群节点中运行。这也是之前给大家提到的大规模并行，以此来提高性能。」

「咱们考虑一个很大的数据集，MapReduce是能够将数据集分成一个个的批次，然后分别启动任务来处理。而MPP肯定也是有机制能够让大数据集分成一部分一部分来处理的。分布式计算基本上都是这个套路。我们用MapReduce的时候，因为数据大都是存储在HDFS这种分布式数据集上，这种存储成本较低，很稳定。但要知道，它就是一个文件系统，它对数据本身的了解一定是有限的。所以查询计划对依赖的处理可能那么准确，甚至是基于成本的执行计划也是难搞出来的。MPP数据库的优势在这里就比较明显了，数据依赖很容易识别，而且MPP数据库一般都是单独部署的，并行处理能够最大化地发挥出来。」

冷哲一口气说了一大堆，也不管大家有没有get到他的点，继续说道：

「MPP数据库也是分布式并行计算，它会根据数据分布，将处理分成一小队一小队的，然后每个小队都放在计算节点去执行，计算完成后再将结果合并在一起。在效率上MPP数据库肯定是有优势的，但对计算资源的要求也很高。」

KeepS系统

Hive导出到关系型数据库是一种拙劣的方法

大家聊了一会MPP，严道希推门进来，看了看手表，已经过去半个小时了。打开Sametime，给另外几个同事发了几个消息，让他们来4楼的meeting room。

然后，跟大家说道：

「大伙儿，冷哲后面单独在Think Friday上准备一个training，跟大家好好说说MPP和MapReduce。我把另外几位dev兄弟也叫过来。来聊聊关于项目的事。」

过了一会，一位呆萌的小个子女生（小尧）、和一位走路一瘸一拐的中年男性（铁拐）、还有一位个子很高的同事（李宏）推门进来。大家都依次坐下。

严道希也没有客套，直奔主题。

「今天，叫大家坐在一起，就是要来聊一聊关于项目架构的事。咱们也别太发散，一些细节后面我们再单独聊。先把跑批的engine敲定下来。有几种方案，一个是用Hadoop生态的Hive、一个是MPP数据库、还有一个是基于Hadoop，用MapReduce+MPP计算引擎。大家说说自己的想法吧。」

小尧刚来MBI，还有点摸不清楚状况，有点也不太敢先说。

李宏先说话，

「老严，我们知道，公司的KeepS系统是一个全球系统，数据量是很庞大的。大家也知道，最终计算出来的数据结果是要推送给多伦多的几个VP的。我们必须得保证数据是准确、稳定的。所以，我不认为MPP是一个很好的选择。至少，在跑批上，我认为它并不可靠。」

铁拐听完李宏的说话，马上接下去说：

「我赞同李宏的说法，我们数仓的基础数据层是不能容许出现任何问题的，尤其是不能丢数。所以不管是抽数、中间的ETL都得是稳定、可靠的。不过，如果是基于MapReduce引擎，你后面报表这块怎么办？我们总不能拿着Tableau来接Hive吧？」

小尧看到其他两位dev都说话，马上也说出了自己的一点看法：

「这个感觉问题不大啊，我们用个工具把Hive的数据导到Postgres。然后让Tableau连到PostgrSQL来查询。这样，也把数仓的一部分高粒度的分析放到PostgreSQL里面...」

MBI有些部门之所以用Postgres，是因为Oracle之前把Mysql收购了，有点顾虑。

还没等小尧说完，冷哲劈头盖脸一顿痛批：

「你这说法显然是不靠谱的。KeepS里面估计得有7000多张表，后面每个产品部门都要自己开发报表。难道每次都要把这些结果集都导出来吗？而且，你以为这7000多张表不会变吗？你注意看看KeepS系统，哪天不再上线？业务那边有改动，分析的报表也会变化，我们要专门找几个人来守着PostgreSQL吗？还有，你以为分析的结果特别少吗？查详情数据又改怎么处理？」

冷哲的一系列发问，怼得小尧一句话都不敢往下说了，气氛一下变得有点紧张，场面有点尴尬。

严道希赶紧打下圆场：

「导出到PostgreSQL在小的项目里面玩一玩还是可以的，我们后面可以看看有一些场景可以用这种方案，」

大家都听得出来，严道希只是缓解下紧张的气氛而已，让小尧不那么尴尬。

混合跑批引擎

冷哲说完，大家都不太敢说话了。于是，严道希开始来说自己的想法：

「前面铁拐提出的问题确实存在。我们现在面对的是庞大的KeepS系统，但大家再考虑一个问题，如果所有几千张表全部都用Hive来跑，大家想想看什么时候能跑完？会不会到第二天需要查数的时候，我草，结果还没跑出来？那不就废了吗？」

李宏说道：

「这个应该问题不大吧。我们把集群规模搞大一点。尽量让能够并行处理的作业多一些。」

二强接过话说：

「大哥，你以为公司的机器不要钱吗？咱们所有部门都是独立核算的。虽然是开发部门来提申请，但肯定也是在预算范围内，不可能给咱们太多的冗余。就算到时候manager出马也是不行的。」

严道希继续说道：

「有没有可能，我们将多种引擎混合到ETL里面。资源肯定是有限的，有没有可能我们把资源更充分地利用起来。几千张表里面，我肯定并不是每个都特别重要、每个都是海量数据。就KeepS那帮老油条，如果每个都是海量，他们早都要跳着换存储架构了。我其实想表达的是：我们需要找出来最核心的业务相关的表，把所有的资源都优先给它们，并且保证它们跑出来的数据是没有问题的。然后那些没有那么重要的表，我们就用MPP引擎迅速结束战斗。」

冷哲补充道：

「对了，有个前提，存储层是必须统一的，不然后面数据的集成会很麻烦，运维工作也很困难。这个大家应该都没有疑问。所以，一旦我们选择了MPP数据库，那也就意味着我们要放弃灵活性。计算引擎、甚至是运行环境都得配套。所以，我们能选择的就是Hadoop。MPP数据库不适合当下的这个场景。混合引擎，我们之前没有考虑过，不过好像还蛮有意思的。不错的点子。」

严道希说道：

「是的，存储这一块我们别给自己挖坑。我也是赞同采用HDFS存储的。MPP数据库我们需要搞成一套解决方案，这对于我们现在来说，没有那么多成本来踩坑。」

「另外，大家不要局限在书或者其他资料里，我看了那些书都怀疑作者是不是在自己想象场景。我也看过网上的各种架构图，一个个好像都是一个模子刻出来似的。一点技术含量都没有。」

未完待续

后续，冷哲会基于严道希提出的混合跑批引擎构建项目的批处理架构蓝图。

请继续关注我哦。