导读：大数据是当前最热的技术之一，这十年它经历了哪些阶段？每个阶段分别创造和发展了什么？未来大数据又将朝着哪些方向继续前行？此文系 QCon 十周年特别策划《技术十年》系列文章之一。在这篇文章里，我们沿大数据发展时间线，从产品、行业、技术多角度讨论其发展脉络，究其发展承其脉络大家可以学习、借鉴、并最终推测未来大致走向。更有云计算、移动、运维等领域文章敬请期待。访问QCon北京2019官网日程，了解最新技术趋势与实践。

引子

我一直认为大数据中文社区里面不乏各类技术大牛所著深度架构干货，同时亦不乏各类技术的总监/VP/CXO高屋建瓴指点行业江山的激情文字，所缺的往往是站在技术、产品、社区、市场交汇点的思考点滴。有如我经常在我部门中所说，中国当前不乏各类云计算的技术大牛，亦不缺各类C端领域的产品大拿，但中国云计算领域要盘点出来一个既通晓技术、又懂得产品全局观、更有甚者能够把握行业脉络的技能全通行业闻名者，确实屈指可数乏善可陈。

我一直笃定一名优秀的云计算产品经理一定是全技能通才，上可讨论行业趋势产业脉络，下可写得了代码修得了Bug，中还可设计产品交互参与API制定，有时可能自恋一把还去InfoQ投投稿、赚赚人气、刷刷存在感。同理，我希望这篇命题式作文亦兼具如此多条思路：

沿大数据发展时间线，从产品、行业、技术多角度讨论其发展脉络，究其发展承其脉络我们可以学习、借鉴、并最终推测未来大致走向。

我不敢用“预测”而只能用“推测”，是因为我非常认可吴军老师在《硅谷来信》中所言”轻预测重反应“，他对于如此复杂如此变幻的市场、世界，缺乏直言预测的勇气。我深以为然。因此，我不敢轻言预测，只能说我们尝试用之前的发展轨迹去推测一下未来的走势。至于最终市场方向是否符合我们预计，实在是天命难测命运难为。当然，最终如果市场不按我们预测的套路出牌，错的不是市场，而是我们的理论。所谓”市场永远是正确的，错误的只能是我们的理论“，是吴军老师教会我的第二点产品市场观。

站在云高度提供独一无二的视角去观察大数据/云计算的发展。

我曾有幸作为一个不处在核心岗位仍在电商边缘工作的观察者在电商崛起的时代被有幸卷入电商浪潮。我是亲眼看到以淘宝、天猫为代表中国电商行业崛起的时代，那是一个创造金钱、财富、神话的时代，你可以比之为美国淘金时代。接下来的时代，即我们当前的时代，可能是一个更加激动人心、更加”技术爆炸“的时代，它们可能是IOT时代、是大数据时代、是云计算时代、是人工智能时代。上述都是从产业某种维度观察IT技术设施发展的浅显断论，可能是一叶障目管中窥豹，亦可能是独辟蹊径曲线救国。但不管怎样，站在云计算高度来看，这些都是当前云计算所希望领域突破，也是希望能够利用云计算服务上述更多行业、造福更多中国中小企业的领域。比如当前阿里云服务的具有百万级客户群体以及技术积累，从市场份额来看它是后续数个追随者份额之和。兵贵神速，任何的先发优势在行业井喷年代造就的发展加速度是任何后续资本、人力、技术投入都不可比拟的。才发现，差之毫厘谬以千里，形容发展加速度亦十分贴切。

接下来，我会从上篇（大数据史前）、下篇（大数据当代），讨论整体大数据发展特点和脉络。负责任地说，以下论点都是作者一家之言（不代表任何公司的立场），同时篇幅受限论点基本均是管中窥豹，不成体系。大家权当作为茶余饭后消遣阅读的IT杂文。

大数据史前

历史

如果我把大数据开创的时代当做公元元年纪年，那么我把大数据开创时代之前的时间称之为”史前时代“，当然此史前并未真正较真为“文明之前”，仅仅笔者的象征性说法。另外需要注意的是，我专门使用的名词是”史前时代“而非”田园时代“，史前指代的是蛮荒、指代的是愚昧、指代的是茹毛饮血，而田园往往给人以心理暗示是男耕女织、自给自足、路不拾遗的上古伊甸园。我从不认可人类社会文明之前乃是一个夜不闭户、道不拾遗的谦谦君子社会，古人常云”人心不古世风日下“就好比男人经常性怀念前女友整日日有所思夜有所梦，倘要他们真的返回原始社会过着食不果腹衣不蔽体，常常需要血肉厮杀、易子而食的时候，这波文人可能就两眼一瞪：傻缺才愿意回去过苦日子呢，我又不傻！

同理，我从不认为大数据之前的数据处理特别包括数据库理论才是数据处理的田园时代，以至于大批数据库理论学派发檄文声讨MapReduce理论的种种缺憾；同时我亦不认为当前整体软件系统设计过于复杂，整个大数据生态过于冗余。IT圈时常有人感慨，当前系统设计之臃肿、运作之复杂，实在有违“Simplicity is beauty”的原则，时常追忆当年玩Unix Shell、翻翻X86中断手册，无比简约无比快感。但可惜，市场永远是对的，如果当前企业级软件市场确实需要如此复杂的软件体系、如此多样的系统生态，说明这部分理论基础以及工程实践确实需要如此复杂化、多样化。试看当今任何学科之前沿领域，无不复杂绝顶，即便同一学科不同子领域之下的职业从业者亦可能相互之间无法洞悉各自精髓。社会发展已经到如此精细化地步，不能责怪与之服务的人类知识体系。

大数据史前时代的数据处理，笔者粗略地将其划为两个时代边界：程序时代以及后续的数据库时代。

程序时代

从时间上，从计算机诞生到专业数据库发迹（不精确来说，以IBM关于数据库论文发表左右时间代表专业数据库诞生，同样上述时代划分并不一定科学也并非严格意义的严谨），那个时候的程序员（或者更应该称之为计算机科学家）过着普遍“轮子帮”的编码生活，即一切都需要靠手解决。这个是程序员的蛮荒时代，人人都面临着所有最基础、最原始、最重复的劳动工作，人人需要面对硬件、面对驱动，人人需要处理算法、处理数据结构；同时，这也是程序员的黄金时代，由于重复构建轮子所练就的技术内功，人人皆可为大神：随随便便读下RFC就可以完整实现TCP/IP协议栈（Bill Joy）、做个学校大作业就可以完成一个Lex（Eric Schmidt），或者在大二在校时间写一个现代操作系统（Linus Torvalds）。不过，从商业公司角度而言我一直较为排斥重复造轮子的做法，因为大部分自研或者不客气说就是造轮子（注意，我指大部分并非全部人员，没有一棍子打死所有人），其实是对于最大化实现商业公司价值无异于缘木求鱼；而从程序员自我实现角度而言，我推荐程序员多去造造轮子，以便最大化窥览计算机最核心的知识精华。我承认，尽管在现代中国劳资双方关系还算友好，但毕竟各取所需各有利益，双方在一些底层商业逻辑上面一直有矛盾存在。

私以为，”一切程序都是对于信息（数据）的处理“应该是我们计算机处理问题的底层构建逻辑，是计算机领域放之四海而皆准的公理性断论。因此，不管是上古时代C/S架构的代码，抑或当前风头正紧的微服务、还是大数据中有关数据处理Pipeline的抽象，均是对于数据的处理抽象。不同的是视当前问题的复杂程度、抽象对象的复杂程度，我们提供了不同层次的抽象设计原则而已。程序对于数据处理的抽象最为直接最为裸奔，整个程序处理逻辑都在于对计算机硬件执行抽象，是为数据处理Action的抽象，是Input->Action->Output的抽象。该抽象对于数据的存储、数据的结构、数据的传输、数据的压缩等等均无定义，交由应用开发程序员自行安排、自行处理。这里的抽象最为原始、最为暴力，其灵活度甚高，同样其普适性亦涵盖整个计算机应用领域，无人敢说我的程序不是处理数据/信息的，因为整个计算机的发明即为信息/数据处理所服务的。因此我可以说，程序，是为（大）数据处理最为初级的抽象方式，这是大数据史前时代最为野蛮也最为普适的一个抽象。随着计算机科学以及工程的发展，我们一定会发展出更加高阶的抽象层次。

我们可以将计算机/程序的发展脉络简单提炼出两点，同时这两点也会指导我们讨论后续所有系统发展的一般客观规律，即：

人类社会的发展脉络之一就是社会分工，程序的抽象就是计算机科学/工程领域对于社会分工的计算机实践。人类社会从最早与兽无异的捕猎者，逐步进化到农业社会有君主、有祭司、有农民，然后过渡到工业社会出现厂主、工人、商人，最终演化到时至今日三百六十行隔行如隔山的分门别类职业爆发。究其原因，均源于社会发展导致的社会分工，当人类社会面向的知识领域、技能领域浩如烟海，大量职业参与者穷其一生无法精通其中寥寥数种工种和领域之时，必定将爆发出各种人类社会分工；同时由于分工导致社会合作协作加剧，不容于社会分工体系之下的个人、公司、国家必定淘汰于这个全球分工协作网络。

计算机科学/工程无不遵守上述社会发展大规律，当有大量底层系统构建者构建出操作系统、编译器、数据库之后，上层应用开发者仅仅需要了解底层API功能原理即可拼凑完整其上层业务构建。操作系统构建者抽象了硬件资源使用方式，我们必须Follow操作系统构建者的抽象去通过各类System Call完成计算资源的调用；编译器构建者抽象了业务逻辑的表达方式，我们必须Follow编译器构建者的抽象去使用各类程序语言和Library去完成业务逻辑的编排；数据库构建者抽象了数据处理的语言表达，我们必须Follow数据库构建者的抽象去使用SQL/API操作我们的数据。同理，大数据系统/框架在分布式计算资源之上抽象了对于数据处理的Pattern，大数据应用开发者只能Follow这个抽象去做相应的大数据计算和处理。

构建底层的操作系统、数据库、中间件、大数据、AI，是社会分工的制定者，是游戏规则的设计者，是产业上游的利益分配者，他们能够定义整个IT商业市场的规模、玩法以及利益分配。他们可能是传统的软件服务商，例如Microsoft、Oracle，也可能是新型的云计算公司，例如阿里云、AWS。对于这类公司而言，未来它们（当然，得在云时代存活下来的计算服务商）会成为整个信息社会的底层构建者，未来它们会是一层不可逾越的商业基础设施。

人类文明的两大发展主线：能量和信息。人类社会一直都沿着上述两条发展主线演进，即扩大能量使用以及加速信息传播。能量的使用，从人类使用火（减少能量散失）、到发明农业

（扩大能量摄入）、到最终原子弹发明（开发更大效率的核能），所有能量发展均沿着能量的“开源节流”线发展。同时对于信息，包括文字（跨地域跨时空传播信息）、印刷术（大规模传播信息）、电报（及时传播信息）、IT技术（大规模数字化传播信息）均在尝试最大化将信息流动起来、传播起来。

从这个角度拉看，在互联网/IT领域，凡是有利于信息产生、传播、处理、反馈的技术、系统、产品都将创造巨大的社会价值，进而创造巨大的财富价值。例如从个体信息传播发展来看，从互联网1.0时代集中式官媒发声到所谓Web2.0时代大量博客、微博发声，都是有利于互联网用户传播自己的信息渠道；从Web2.0的博客（长篇大论的文字）到微博（只言片语想到说到及时上传文字+图片信息）到现在抖音（传播信息量更大的视频内容）。下一代技术/系统，凡是有利于数据从物理世界进入信息世界（当前大量行业尚未被信息化），凡是有利于信息世界传播的均是发展热点，例如：5G（加速信息传播）、VR（更多物理世界信息化）、IOT（更多物理世界信息化）。

继续从这个角度入手，我们同样可以发掘数据系统发展趋势：凡是有利于数据（信息）产生、传播、处理、反馈的技术都可能带动整体数据系统的向前演进。例如更简单地抽象了数据处理范式（SQL）、更简单地应对互联网时代下大规模数据处理能力（MapReduce以及其衍生系统）、AI（大数据处理后直接提交AI系统做市场决策）。因此，在下文我们做未来数据系统发展推演，我将不遗余力地使用该原则进行发展推演。

数据库时代

我应该把文件系统的抽象放置在数据库时代之前，毕竟文件系统的抽象同样解放了数据程序员去关注底层硬件指令和驱动的繁琐。在此，我之所以略过文件系统不在于文件系统本身重要性欠佳，文件系统抽象和操作系统抽象一样，奠定了我们今时今日整个计算机世界的工程基石。但篇幅所限，我们今天本文重点讨论数据系统，而非存储系统发展历史，我们不得不暂时省略掉不在我们讨论主线的主题。

令人称赞的数据库时代！让程序员终将摆脱直接面对硬件磁盘结构以及底层文件系统进行数据操作。可以想象，在数据库诞生之前的时代，程序员是如何面对底层存储系统结构去构建自己的应用代码，在存储要靠磁带的蛮荒时代，程序员在一个类似线性表存储中自己尝试去构建数据索引以及设计数据内容存储，并且还需要面对底层磁盘硬件操作写入方式；在接下来当提供文件系统抽象封装的操作系统之上构建各自应用时，程序员稍加解脱可基于一个成熟的文件系统而不用去直接面向磁盘操作，但终究仍需要面对设计诸如索引结构、存储结构、并发读写、失败恢复等诸多底层系统设计细节。可以想象，诸如此类基础底层的系统类软件设计和实现，绝逼难度异于常规，非大神级别参与实现不可，这将变相提升整个软件项目的复杂度以及投入成本，并最终带来项目落地以及市场商业的巨大风险。

困难往往意味着机会，越普遍越难解的困难往往蕴藏着巨大的市场机会。如前文所言，诸如操作系统、数据库、编译器之类的软件产业基础服务，投入巨大、风险巨高，非一般公司可以为之。但同理而言，一旦此类公司发布出可商用的软件版本、构建出可繁衍的软件生态，即可成就一番软件霸业。操作系统如此，看看曾经“不可一世”的微软、当前如日中天的苹果；数据库如此，瞧瞧遍大街的Oracle“霸占”多少银行电信行业，养活多大上下市场生态。

在此，我想仅仅想讨论数据库领域两个我认为涉及到本文主旨的论点。

数据处理一次社会化的大分工

文件系统的抽象将存储进行了分工，大量开发人员不用在面对硬件和驱动读写存储，而是面向文件句柄、目录层次、读写权限，这是一个巨大的飞跃，恰到好处地将操纵硬件资源包装为一个面对有结构有层次利于操作的系列文件API；再次，数据库将存储抽象从一个完全平面的、Bit线性表、操作对象粒度为文件的层次再次提升到关系二维表（特指关系型数据库）、面向业务记录（数据行）、操作对象粒度细化到数据的层次。

抽象有利于业务表达，因为抽象会提供更高级别的API（从文件API提升到数据API），更有利于业务开发人员聚焦自身的业务表达；但任何事情都有trade-off，聚焦意味着放弃，抽象反面就是泛化，文件系统作为一个存储系统设计而言具有最为广泛的市场应用价值，但同时如果要让每个业务开发人员在文件系统层面操纵结构化数据存储，必定其痛苦万分几欲自宫。因此，数据库设计人员跨出这一步，提炼出高阶数据API同时丢失了文件系统普适性的广阔市场。于是乎，我们在云计算行业里面可以看到，阿里云的OSS、AWS的S3仍然可能承载了云上最广泛、最庞大的数据资源（但却不一定是最有业务价值的数据，例如云计算上一个存储对象的二级制文件系统服务出现宕机，可能给用户造成的后果是短时间内该文件句柄指代的对象不可读写：可能是音乐不能播放、文档不能打开，用户可能尚且能够等待网站恢复，但一个业务关键数据库系统一旦宕机，可能造成的后果就是灾难性的：全站不可登录、不可交易，是巨大的业务故障）。因为其文件系统（当然这里是一个分布式文件系统）业务适配范围远远超出关系数据库的适配范围；同时，在阿里云RDS周边，我们看到了更多类似数据库的其他垂直领域数据处理系统，例如消息队列（提供流式数据读写的API抽象）、搜索引擎（提供全文检索服务的API抽象）等等等等，因为传统关系型数据库在聚焦关系代数二维模型情况下，让出其他数据存储和处理市场份额给到了其他数据系统。

因此，就数据处理系统而言，我一直在不停强调分工、分工、分工。原因是所有的数据存储服务、工具、引擎都在基于文件系统这个普适性的存储抽象上做垂直领域化的逻辑抽象，包括数据库、消息队列、搜索引擎，以至于到本文重点大数据处理系统。这些都是抽象，是底层逻辑构建者在定义自己的理想世界，然后让上层应用开发人员心甘情愿融入或者被屈服拉入这一层被抽想改造的”乌托邦“。抽象意味着分工，意味着独立的市场领域以及商业份额，越是底层领域普适性越高、受众面越大、收入空间越足，而越是上层领域普适性越差、受众面越小、收入空间越小、但可能利润空间不错。故而，可以想象，云计算厂商在争取到巨大的IT市场流量入口之后，势必逐步下沉到普适性更强领域，因此其市场领域更大、想象空间更大，因此处于垄断地位的云计算公司未来一定会大力发展诸如CPU、GPU、IOT甚至于各类小型机、大型机等各类计算端+中心设备，而上层的软件生态，包括从最为基础的OS直到上层SaaS服务，都是在为这个庞大的IT基础设施为带动更多的算力资源消耗之目标而服务。对于庞大如阿里云、AWS类的云计算服务商，本质上做的是计算力生意，本质上是构建下一代计算力的全社会基础设施。

SQL与关系代数

我有充分的理由可以说，当前IT领域最火热的技术已经不是数据库，或者至少不是传统关系型的数据库。当前，包括大数据、人工智能、微服务、NoSQL各类新型技术层出不穷、屡见不鲜，以至于我时常误以为IT技术到了刘慈欣《三体》所言的”技术爆炸“时代。身边人所言IT技术更新换代之快速，非常容易造成从业人员跟不上节奏，不无道理。从另外角度而言，不叫卖的技术要么早已技术基石、人人皆知，要么濒临淘汰、昨日黄花。诚然，关系型数据库绝非当红炸子鸡，但其技术影响力绝非后者，而恰恰相反早已经是整个计算机科学和工程的基石。犹如计算机科学领域的操作系统，当前已经没有任何太多新颖故事可讲。犹记得我在大学时间正值中国互联网大爆发的时代，LAMP架构风头正劲无出其右，因此有关Linux/Unix的网站、教材、博客如投机创业一般地争风口要上市。而时至今日，有关Linux/Unix的材料早已烂大街再无人作为市场亮点宣传，而风头正紧的乃是大数据、人工智能、Kubernetes、Docker等各类技术噱头。每每看到这些满大街的网红技术，想想当年LAMP培训宣传的如日中天，感叹其实技术圈和网红圈本质上没有太多差别，追一个流量网红和追一个“噱头技术”其实相差无几。

数据库技术已成计算机基石，早已度过当年求曝光要宣传的流量小生时代。但不可否认，整个数据库技术为后续数据处理带来了大量基础科学理论以及工程实践。大量数据库理论论文、工程代码在后续的大数据、中间件领域中被大量借鉴、拷贝、甚至于”抄袭“。特别是关系型数据库有关数据处理模型的抽象：理论是关系代数、工程是SQL查询语言。

虽然说，数据库模型的历史虽然不是起源于关系型模型，但必须得说关系型数据库曾统一了所有的数据库模型，并一直统治至今。关系型模型进入人们视野的具体时间是E.F.Codd在1970年发表的论文: “A Relational Model of Data for Large Data Bank”。很多人对关系型数据模型的印象是表和字段，并还能想到的是表与表之间通过某些字段可以关联起来。似乎正因为这样，关系型数据库才被冠于这个名字。然而关系型数据模型中的“关系”在英文中对应的单词“Relation”是一个抽象的数学概念，它既不是独指2个表之间的关系，也不等价于一个二维表（虽然习惯于以二维表来表示）。数学中关于Relation的定义是这样的：给定n个集合S1、S2、 S3、 …、 Sn, R是一个n元数组(n-tuples)，它的第一个元素取自集合S1，第二个元素取自集合S2，以此类推。我们将R称之为基于该n 个集合的一个Relation，Sj为R的第j个域(Domain)。

另外一个值得大书特书的就是SQL，即结构化查询语言(Structured Query Language)。笔者是个产品经理，相较之如谈论如同白开水一般的计算机科学理论例如上文的关系代数，非我等产品经理兴趣所在；我们更加关注我们的产品接口（Interface），这层接口可为UI、同样亦可为API，而上述SQL即为关系代数理论之上用来方便构建用户和系统交互的恰当方式。相比较于用户之前使用硬件接口/驱动直接操纵数据读写存储空间，以及后续稍显友好文件系统读写接口，SQL给应用开发者提供的API是令人震撼的，SQL本质是声明性语言，它告诉计算机我们想要什么（What），而非执行步骤（How）。从抽象程度而言，What的命令通常要比How的命令在描述问题抽象程度更有利于业务沟通，试想“我想成功约到一个漂亮小姐姐”类似愿望的表达，始终会比”我打算去健身，同时在园区物色一个漂亮小姐姐，天天请吃西餐+看电影，持续一个月，看看对方反馈效果“的计划显得更加贴近男人的内心表达。如此，不恰当地说，前者就是声明式语言，后者就是命令式语言。同理，对于声明式语言，其业务抽象程度较之命令式更高，笔者作为产品经理非常能够理解SQL设计者意欲将关系代数理论以及数据存储处理的工程都使用SQL语言进行封装，同时我亦承认，SQL在统一数据抽象层方面意义巨大。但，理论总归完美，现实总有残缺，相比于工程而言，大量工程业务细节不一定能够完全用理论Hold，例如在某些极端情况下，一段SQL语句往往在成本和产出之间无法达到最优，往往需要专业DBA设定特殊的Hint往往才能够提升数据库查询性能。毕竟，现实数据情况多种多样，预制的专家规则无法一一穷举，只能靠具体的DBA专家进行特殊性能调优。未来，对于程序处理的优化，我们认为每个系统都会有类似AlphaGo一样的AI Daemo，时时刻刻在学习当前的数据特征以及程序处理情况，进而进行深入的、定制化的个性化优化。

在本小节的结束时间，我们附上有关数据库发展Timeline，希望数据库的发展路线给大家看到整个数据库发展时间脉络[注2]。

大数据当代

理论

人人皆言，是Google最早提出了云计算的概念。犹记得当年Google正值硅谷的当红炸子鸡，Google的CEO乃Eric Schmidt老爷子，其本人在硅谷的搜索引擎大会上，首次提出了Cloud Computing（云计算）概念时，何等意气风发，颇有指点江山激扬文字之意。彼时之Google乃最为高光之时刻，整个硅谷视之为“颠覆微软邪恶帝国”的自由灯塔，一时间无数文人骚客为此趋之若鹜、门庭若市。但Google虽贵为云计算概念所创者，似颇得云计算之精髓，但Google躺在其最大的广告现金流之上，类似于“站着就能把钱给挣回来”，似乎缺少开拓新B端市场的毒辣眼光，以为云计算乃“科技幻想，当前切勿有此执念”，和中外诸多头部互联网一起落入俗套，纷纷为云计算概念点赞却本身不落地推进执行。而恰恰相反的，仅仅在Google高调宣称云计算之概念的十天之后，亚马逊的云服务EC2就向公众开放提供试用。我一直揣测当时亚马逊/AWS其本身仍然认为此业务乃传统虚机租赁的延续，和云计算之类高大上的科幻名词尚有差距，自认为也不可一视同仁。但亚马逊理论上虽未创新但在商业市场孜孜不倦推动云计算产品、产业逐步落地。

回顾这段历史，我们得承认彼时亚马逊在技术领先性上和Google尚有差距，不能一概而论，但其市场先行、产品试探的商业做法无异于更加贴近于当前瞬息万变、波诡云谲的互联网时代下的企业服务。最终，Google首提云计算之概念，但花落他家，亚马逊/AWS在市场上率先证明了云计算在商业市场上的可行性。对于云计算而言，我们可以说大家（包括Google开始）都没有为此真正相信过，以至于亚马逊/AWS最终靠商业行动力获得云计算欧美市场的定义权。因为相信所以看见，为亚马逊/AWS市场商业创新能力手工点赞！

暂且按下Google云计算不表，早期Google对业界另一大贡献即是大数据概念提出，同样不幸，Google在大数据领域比云计算领域更是亲力亲为扮演活雷锋的角色。云计算中Google仅仅贡献科技概念和名词包装，早期市场方面全靠AWS一家将其发扬光大，Google早期除了贡献这个概念本质上对于云计算商业和市场并无特殊贡献，相反是贡献了“技术指导商业”往往会拖累市场发展的反例：一个纯粹的技术公司承载不了云计算的商业梦想；而大数据领域，Google不仅是贴钱、贴人地支持大数据发展，以至于最终开源大数据社区蓬勃发展成就一方霸业，但Google与之Hadoop社区，好比一匆匆过客，呆痴痴、傻乎乎地眼见诸多理论被开源“山寨”进而被其他云计算公司使用，毫无作为令人叹惋。于是乎，Google在完美地错过了云计算的先发优势之后，顺便再进一步丢弃了主导开源大数据理论、技术以及市场彪炳千秋之机会。

篇幅有限，在此我们仅从两个维度切入讨论Google的三驾马车，同时顺带聊聊Google在大数据领域的先发后至，以及Google云计算的思考。

大数据：退步还是进步？

讨论的第一个主题就是大数据相比于数据库在数据处理理论上是进步还是退化？笔者专门加上了一个“理论上”，因为前文已述，我等产品经理对于技术理论并无多大兴趣，特别对于技术领先型，如果无法转换为成本优势、性能优势、体验优势，此类技术之牛X，于我不甚关心。我会直接从商业或市场上给出结论：大数据相比于数据库是市场进步，因为他们当前更加贴近市场对于大规模数据处理的诉求。

以MapReduce为例（有关MapReduce的概念解释，请参看下文的资料推荐，本文非技术入门科普文不讨论技术原理），当年David J. DeWitt以及Michael Stonebraker有关MapReduce的声讨檄文仍历历在目。2008年，上述两位数据库大拿在databasecolumn网站发表《MapReduce: A major step backwards》（MapReduce: 一个巨大的倒退）基本上把互联网大数据派和数据库派之间的争吵推向一个高潮。任何一个稍懂数据库以及大数据的相关从业人员，都能够明确看到两者之间的严重分歧。于数据库人员而言：我派祖师爷数十年之心血积累，创建诸如关系模型、SQL语言、ACID、存储优化等等理论精髓，方才以开山立派流芳百世，尔等小屁孩一登场啥都不懂就把祖师爷数十年积累贬的一文不值，砍得七零八落，你这个不是开历史倒车又是什么？数据库提了大致五点问题，摆出架势准备为数据处理的后生小辈谆谆教导一番：

在大规模的数据密集应用的编程领域，它是一个巨大的倒退
它是一个非最优的实现，使用了蛮力而非索引
它一点也不新颖——代表了一种25年前已经开发得非常完善的技术
它缺乏当前DBMS基本都拥有的大多数特性
它和DBMS用户已经依赖的所有工具都不兼容

笔者认为上面问题将MapReduce当前设计实现的弊端描述得恰如其分，一点不冤。看MapReduce论文，其核心实现基本上推翻之前数据库几乎所有优秀研究成果，而采用了最原始最简单最暴力的实现方式，将就能用，但实属不雅。在互联网业务之局外人看来，特别在于数据库这帮学院派人士看来，类似处理方式无异于鼠目寸光、饮鸩止渴、开历史之倒车。但身居互联网行业久矣，我深知互联网行事作风：快、糙、猛。互联网做事，能用就行，快速占领市场，管什么狗屁规矩。类似邓小平先生那句名言：不管白猫黑猫，抓住老鼠就是好猫。我管你们数据库之前如何设计精巧，今天要快速搞定我大Google大数据，为何不能做trade-off。

从MapReduce之后，紧接着2006年Google再发大作《Bigtable: A Distributed Storage System for Structured Data》，BigTable则是完全瞄准在线数据处理领域，讲述了用于存储和管理结构化数据的分布式存储系统，其建立在GFS、MapReduce等基础之上。该论文启发了后期的很多的NoSQL数据库，包括Cassandra、HBase等。如果说MapReduce完全专注于离线批量大数据处理/计算，则BigTable可以说和数据库完全在同一战场。可以想象适时诸多计算机学院派大牛当面对BigTable论文时必定摇头叹息：孺子不可教也。之后整个大数据行业借助Hadoop生态春风，蓬勃发展，至今十年有余，催生诸多云计算、大数据产品的市场。

在此，我想重申我的观点，大数据是大数据时代之下系统演化结果，是更加贴近大数据场景下用户处理数据的诉求，而非开历史倒车。大数据、大数据，我们讨论的就是一个“数据爆炸”时代下如何进行有效地大规模数据处理问题。这个问题是数据库之前未曾遇到、也未曾解决的特定问题，这些数据可能非结构化、非关系化，可能是半结构化的Nginx日志或者是用户上传的图片、再或者可能是整个城市大脑的交通探头高清视频数据。这些数据用传统的、狭义的关系型数据库无法解决，因此大数据方案舍弃了数据库模型中当前不适合上述数据处理的特性，牺牲某些功能从而换取大规模数据处理之能力。这是面向市场的、面向问题的、积极应对需求变化的技术做法，不教条也不做作。诚然，我相信大数据领域中某些领域，例如在处理关系数据事务型或者分析型场景下，可能仍然有大量数据库理论发挥作用，甚至看上去像一个数据库系统，如Google Spanner；但在更大的数据处理与分析领域，我们将使用更多更分门别类的数据处理和存储方式，这类方式完全异于传统数据库，例如机器学习、例如图像识别。同时，我们可以预见，随着整个物理世界更多地数据化（上篇我们曾经讨论，凡是有利于加速信息生成、采集、传输、处理、反馈的技术都能够创造市场价值），而更多的物理社会数据化（IOT）、网络化（5G）势必造成更加复杂多样的数据处理需求类型，进而可以预见未来大数据处理会更加多样化，大数据分工于数据库系统，而接下来大数据同样内部面临巨大的分工：更多更垂直更定制化的大数据系统将源源不断产生，以应对快速爆炸的数据时代。社会分工理论在此同样具备适用性。

Google大数据：机遇和失误

前文已述，Google确实在技术和理论高度创造了”大数据“的概念，Google无偿将其技术框架理论贡献给开源社区，整体上有效促进大数据开源社区以及周边行业发展，以至于最终开源大数据社区蓬勃发展成就一方霸业，Google勇气可嘉精神可叹。但至始至终，Google在大数据领域除了成就其技术影响力美名之外，基本毫无所获，遑论从云市场大数据获益。Google确实起了大早赶了晚集。究其原因，大概如下：

缺少对于云计算的重视和投入

试看当前的技术变现手段，最为直接即是云计算领域。任何一个技术领先的技术型产品，无论IaaS、PaaS甚至是SaaS的技术型产品，放置云上进行售卖乃变现之最快途径。Google早年对此市场似乎有些晕头转向，毫无章法，以至于错失诸多大数据技术商业变现机会。

看最近Google似乎已经转换云市场策略，在Google Cloud上大量铺开其核心产品，但可惜由于开源大数据早已成为业界标准，Google自行一套的大数据产品体系不一定能够讨得用户欢心。生不逢时。

缺乏对于开源社区的重视和投入

Google以技术起家，十分重视技术影响力建设，以至于一直以来都是世界各大IT人员心中的技术灯塔。但从某种角度而言，技术影响力若无法变现，包括人才变现、营收变现，均是徒有虚名。Google以三驾马车敲开大数据大门，虽打开一崭新行业，但概念虽新、落地很难，Google显然缺乏让大数据在整个行业落地的动力和想法。同时，万万没想到开源社区竟然依样画葫芦”山寨“一把并最终形成Hadoop生态体系，并最终受众众多，用户甚广，时至今日Hadoop体系早已成为大数据行业事实标准，而其祖师爷Google未能实质获得任何可见好处，有点像祖师爷的技术被江湖小辈盗版后发家致富，最终饿死祖师爷了。试想，如果当年Jeff Dean公开MapReduce、GFS论文同时，直接开放一套剥开Google内部系统依赖的完整开源软件。以Google自身强大的技术号召力，开源社区绝对不敢造次、多半服从Google技术生态。由此Google基本控制了大数据生态社区，后续云计算变现顺水推舟。但，Google错失定义开源大数据软件机会，一失足成千古恨。

不过，Google何等聪明伶俐，早已洞察一切。现在的Google，从TensorFlow、Kubernetes、Beam开始，在技术开放之初，发表论文之时，就顺便开源一套软件技术内核，并投入重金支持开源社区构建。对于Google而言，社区即标准、社区即流量、社区即商业，一切都可以导向未来的商业化变现，长线投资、长期发展；而对于开源社区，如此巨头花重金支持生态发展，拍手称赞何乐不为。各取所需各获所利。

Google云的先发后至

前文已述Google在云计算方面的创新与失误，系列文章的下篇我们还会深入讨论云计算行业的林林总总。但此刻我们更多关注与盘点Google云的失误。Google云在笔者看来犯了数个错误，这些错误在聪明如Google看来一定早已知晓，但种种原因改变的进展迟缓，特别是相对于亚马逊/AWS而言，更是显得后知后觉：

Google云是服务B端市场的，但明显Google云似乎一直没有意识到其主要客户是B端企业。不得不承认，Google公司围绕消费者的C端产品固然强大，但B端产品思路以及市场策略实属抽风。Google一直在强调自己的云标签是“人工智能”，试图通过拉入AlphaGo等重磅公关事件来提升用户对于Google云的认可度。AlphaGo火了人工智能，也顺便帮Google的AI能力大大PR了一把，但明显这部分流量并未给Google云带来有效的转化，倒是后边大量云计算厂商通过开源深度学习引擎再次“捡漏”。另外，试问人工智能能够带来多少计算资源消耗，人工智能又能够提升多少云计算客户基数。很多情况下，在机器学习领域，一次数据Training足够、使用开源软件足够，小公司暂时没有能力也没有数据进行Training、大公司有数据但大都自行部署开源机器学习引擎自己构建机器学习平台，何来大客户、何来大营收？人工智能在当前整个云计算生态以及大数据生态最多算个云计算公司产品黏性，再不济就只能是市场噱头，叫好不叫座。按照企业基因学说，天生缺toB基因的Google，想在云计算方面要靠全方位无死角地伺候B端客户，试看Google天生自带高贵基因，似乎难以铺广开来。
Google云计算是服务年薪百万级的Google员工，而非行业普通开发者水平；服务的是数亿用户的业务规模，而非行业普通业务水平。早期大量Google云产品均是服务内部的产品在云上的“云化版”，这类系统天生有个悖论，论稳定性、论成熟性、论领先性，这类系统绝对无出其右，但高射炮打蚊子，各位看官可要清楚Google云平台面对的企业内部员工可是年薪百万级别起的软件工程师，试问这类工程师其专业水平可是整个行业平均水平？Google云平台服务的是Google内部业务技术开发水平，这些业务方动辄数亿用户、动辄PB数据、动辄数百人团队，试问这类业务规模可是整个行业平均规模？Google云拿一个超越于当前年代的产品，试图让用户搬云迁站，其改造成本有多高? 其维护成本有多高？有多少用户愿意使用类似产品，或者接受如此改造？常言道，步子迈大了容易扯着X，话糙理不糙。

尊重市场是任何一家商业化公司活下来的最高法则。但令人啧啧称奇的是，诸如强大如Google、聪明如Google仍然在不停犯类似错误。例如，不可能因为Google内部广泛采用BigTable因此就要在云上劝说用户放弃使用Mysql转而投入使用BigTable。人人皆知从一个关系型数据库迁移到NoSQL数据库的改造难度，势必极大增加用户改造上云成本。我们一定是要让用户迁云过程中进行全面的代码改造再行上云，还是先将客户收入囊中循循善诱、徐徐图之。这个是技术导向和市场导向两类不同思路，麻烦就在大量云计算公司往往有技术导向的可能性以及倾向性。当前，整个云计算市场在烧钱争抢市场的阶段，犹如当年快的与滴滴烧钱培养用户打车习惯的阶段，流量为王、用户基数为王、最大规模占据市场份额为王。任何成功商业模式均需建立在庞大的市场规模之上，无规模不商业，当用户基数一到、资源消耗一到，后续任何的服务增值、利润打造、云市场买卖平台构建均基于此可以做长线演化。但用户基数是0到1的问题，此问题不解何来讨论商业模式？

Google云在今年四月适才刚刚举办了Google Cloud NEXT 2019，InfoQ随即给出了一个忍俊不禁的报道《谷歌 Cloud NEXT 重磅盘点：终于想起云做的是 ToB 生意》，看得出来诸位IT同仁对于之前Google云的评价。

社区

Hadoop：开源大数据的基石

Hadoop于2005年问世。之前，Doug Cutting和Mike Cafarella已经拜读过Google的GFS论文，并且自己“手工造轮子”实现自己的Google分布式文件系统（最初称为 Nutch 分布式文件系统的 NDFS，后来改名为 HDFS 或 Hadoop 分布式文件系统）。在2004年时候，Google发表神作《MapReduce: Simplified Data Processing on Large Clusters》，上述两位正在构架开源搜索引擎的大牛在考虑构建Nutch webcrawler的分布式版本正好需要这套分布式理论基础。因此，上述两位社区大牛基于HDFS之上添加MapReduce计算层。他们称MapReduce这一层为 Hadoop，由于Hadoop核心原理均是基于上述两篇论文，即MapReduce以及GFS，其本身在技术理论上并无创新，更多是“山寨”实现。对于技术原理感兴趣的看官可自行阅读Google原作立刻了解各自原理，而对于Hadoop发展历史感兴趣的可以推荐阅读下Marko Bonaci 的《The history of Hadoop》。

Hadoop技术相比于Google原作并无新意，甚至在GFS系统细节方面折扣实现不少。但笔者在此并无讨论技术差异点的打算，我仍然回到老本行，从产品或者市场角度去探讨Hadoop成功因素以及给我们的启示。

在笔者看来，Hadoop体系能够成功，并在数据处理市场占据一席之地，其初期核心因素就在于以下几点：

时机。彼时互联网Web 2.0风头正紧，大量用户与网站交互行为爆炸式增长，如何使用廉价的服务器（大量互联网创业公司就是穷鬼，买不起大小型机）去分析各类网站数据的业务需求已经迫在眉睫。此时，大量Top互联网公司有数据、有需求、有硬件，就缺一个廉价的数据分析系统。于是乎，开源、免费的Hadoop工具正好钻入此类大数据市场空档，迅速占领了核心种子客户群体，并为后续市场推广奠定了群众基础。
开源。开源在开发者社区感染力不容小觑。Cutting 和 Cafarella 通过开源（以及 HDFS 的源代码）确保Hadoop的源代码与世界各地可以共享，最终成为 Apache Hadoop 项目的一部分。Google此时并未意识到开放论文仅仅自我精神爽了一次：让尔等看看我等技术影响力；实际上并未从长远去思考大数据技术影响力构建以及更加长远的云计算商业生态构建。互联网时代下，大量软件被开发者以及背后的互联网商业公司作为开源系统贡献出来，整个互联网开发者行业已经被开源社区完全洗脑，仿佛开源就是人类灯塔，闭源就是万恶不赦。于是，此时，一个开源的、免费的、感觉挺符合互联网精髓的大数据处理软件出现在各大互联网公司圈中，迅速在互联网大数据处理领域触达了这部分市场群体。
商业。早年开源软件皆靠诸位开源运动人士在业界做社区用户推广，这波人本身毫无金钱汇报全靠一腔精神热血。但本质上来说，人类以及人类社会都是趋利性的，没有利益驱动的市场行为终究无法持续。因此，早期没有找到合适盈利模式的开源软件一直发展缓慢，靠类似Richard Stallman类似开源黑客斗士去做市场推广，市场效率之低下。后期，在Linux商业公司红帽逐步摸索出开源软件变现模式后，其他开源软件也纷纷仿效。Hadoop一时间背后迅速成立三家公司，包括Cloudera、HotonWorks、MapR，这些公司盈利潜力完全都依赖于Hadoop开源生态的规模，因此，三家公司都会尽不遗余力地推进Hadoop生态发展，反过来促进了Hadoop整个生态用户的部署采用率。到大数据市场更后期的时代，其商业竞争更趋激烈。以Kafka、Spark、Flink等开源大数据软件为例，在各自软件提交到Apache基金会之时创始人立刻创办商业公司，依靠商业推进开源生态建设，同时通过收割生态最终反哺商业营收。

最终Hadoop在生态建设上获得了巨大的成功，其影响力在开源业界开创了一个崭新领域：大数据处理可见一斑。我们从如下几个维度来看看Hadoop生态成功的各类体现：

Hadoop的技术生态

不得不承认，Hadoop有技术基座的先天优势，特别类似HDFS的存储系统。后续各大Hadoop生态圈中的大数据开源软件都多多少少基于Hadoop构建的技术底座。故而，大量大数据生态后起之秀基本均源于Hadoop，或者利用Hadoop作为其基础设施，或者使用Hadoop作为上下游工具。此类依存共生关系在整个Hadoop社区生态已蔚然成风，越多大数据开源系统加入此生态既收割现有大数据生态客户流量，同时亦添加新功能进入Hadoop社区，以吸引更多用户使用Hadoop生态体系。就好比淘宝买家卖家相互增长，形成商业互补，相辅相成。
Hadoop的用户生态

前文已述，优秀的开源（免费）系统确实非常容易吸收用户流量、提升用户基数，这个早已是不争事实。通过开源(免费)的系统软件铺开发者市场、培养开发者习惯、筹建开发者社区，早已是开源软件背后商业公司的公开市场打法，这就类似通过免费APP培养海量客户技术，最终通过收割头部客户实现营收。或者好比一款游戏，大部分可能均是免费玩家，但用户基数达可观规模之时，一定涌现出不少人民币玩家，并通过他们实现整体营收。当前风头正紧的开源大数据公司，包括DataBricks（Spark）、Confluent（Kafka）、Ververica（Flink）莫不如此。在开源软件竞争激烈日趋激烈的环境下，其背后若无商业公司资金支撑，其背后若无市场商业团队运营支撑，当年写一个优秀的开源软件就凭”酒香不怕巷子深“的保守概念，现如今早已推不动其软件生态圈发展。试看当前大数据生态圈，那些日暮西山、愈发颓势的开源软件，其背后原因多多少少就是缺乏商业化公司的运作。

Hadoop的商业生态

大量商业公司基于Hadoop构建产品服务实现营收，云计算公司直接拉起Hadoop体系工具作为大数据云计算服务，软件集成商通过包装Hadoop引擎提供客户大数据处理能力，知识机构（包括书籍出版社、Hadoop培训机构）通过培训Hadoop开发运维体系实现营收和利润，上述种种商业行为均基于Hadoop体系实现商业利润。整个Hadoop开创了开源大数据的新概念，并由此养活大数据行业数不胜数的参与者。这波参与者享受了开源Hadoop的收益，同时也在为Hadoop贡献知识。

如果说Google三篇论文发表后敲开了大数据时代的理论大门，但论文绝逼异常高冷、不接地气、无法落地投产。真正人人皆用大数据的时代是直到开源社区提供了成熟的Hadoop软件生态体系之后，我们才可以说企业界方才逐步进入到大数据时代。可以说，当代Hadoop的诞生，为企业大数据应用推广起到了决定性作用。

生态：大数据的林林总总

Google三家马车叩开了大数据理论大门，而Hadoop才真正开启了行业大数据时代。前文已述，Hadoop已经早已超出MapReduce（计算模型）和HDFS（分布式存储）软件范畴。当前早已成为Hadoop大数据代名词，指代大数据社区生态，无数号称新一代、下一代的大数据技术无不构建在Hadoop生态基石之上。下文我们分维度重点讨论基于Hadoop生态之上的各式各样大数据组件抽象。

高阶抽象：让人人成为大数据用户

上篇道，数据库两位大拿David J. DeWitt以及Michael Stonebraker十分不待见MapReduce论文所诉理论，基本上是羽檄争执、口诛笔伐。其讨伐重点之一便是使用MapReduce而抛弃SQL抽象，将实际问题的解决难度转嫁用户非正确的系统设计方式。同样，这个批判确为MapReduce之缺陷，凡是正常人类绝逼感同身受。一个普普通通数据处理业务，用SQL表达多则百行、少则数行，熟练的数据工程师多则数小时少则数分钟即可完成业务开发，轻松简便。而一旦切换到MapReduce，需要将SQL的直接业务表达子句换成底层各种Map、Reduce函数实现，少则数千行多达数万行，导致整个数据开发难度陡增，业务开发效率抖降。

针对上述两个问题，Google和Hadoop两条技术分别做出各自的技术方案：

Google公司的FlumeJava

Google尝试提供高阶的API去描述数据处理Pipeline，进而解决上述业务表达难题。FlumeJava通过提供可组合的高级 API 来描述数据处理流水线，从而解决了这些问题。这套设计理念同样也是Apache Beam主要的抽象模型，即 PCollection 和 PTransform 概念，如下图：

这些数据处理 Pipeline 在作业启动时将通过优化器生成，优化器将以最佳效率生成 MapReduce 作业，然后交由框架编排执行。整个编译执行原理图如下图。

FlumeJava 更清晰的 API 定义和自动优化机制，在 2009 年初 Google 内部推出后 FlumeJava 立即受到巨大欢迎。之后，该团队发表了题为《Flume Java: Easy, Efficient Data-Parallel Pipelines》的论文，这篇论文本身就是一个很好的学习 FlumeJava 的资料。

开源生态的Hive

开源社区受众更广，其使用者更多，因此实际上开源社区对于开发效率提升诉求更高。但Hadoop社区似乎对于SQL情有独钟，更多将精力投入到SQL-On-Hadoop类的工具建设之中，最终，社区吸收Facebook提交给Apache基金会的Hive，并形成了业界SQL-On-Hadoop的事实标准。

对于Hive而言，其官网特性说明充分阐释了Hive的作为一套Hadoop MapReduce之上的DSL抽象之价值和特性：

Hive是基于Hadoop的一个数据仓库工具，可以将结构化的数据文件映射为一张数据库表，并提供完整的sql查询功能，可以将sql语句转换为MapReduce任务进行运行。其优点是学习成本低，可以通过类SQL语句快速实现简单的MapReduce统计，不必开发专门的MapReduce应用，十分适合数据仓库的统计分析。
Hive是建立在 Hadoop 上的数据仓库基础构架。它提供了一系列的工具，可以用来进行数据提取转化加载（ETL），这是一种可以存储、查询和分析存储在 Hadoop 中的大规模数据的机制。Hive 定义了简单的类 SQL 查询语言，称为 HQL，它允许熟悉 SQL 的用户查询数据。同时，这个语言也允许熟悉 MapReduce 开发者的开发自定义的 mapper 和 reducer 来处理内建的 mapper 和 reducer 无法完成的复杂的分析工作。

于笔者这样的产品经理而言，其重要意义是将MapReduce进一步进行抽象为业务高阶语言，让更多不善于Java/C++编码的数据工程师能够快速上手使用大数据工具进行数据分析，让大数据业务开发成本更低、使用门槛更低、维护成本更低，让传统的、使用数据库的数据分析师能够基本无缝迁移到基于Hadoop的大数据平台，从而极大扩展了大数据用户群体，进一步拉动Hadoop社区的用户生态以及商业生态。

从另外一个方面，Hive作为一个SQL-On-Hadoop工具，为后续诸多大数据处理软件提供了很好的表率：即越高阶的业务抽象API能够极大降低用户开发门槛，拉动使用者基数。后续大量的开源闭源大数据系统都或多或少、有模有样地提供了各自SQL方言，方便用户更加快速、简单地上手各自的大数据软件。开源社区来看，从Hive开始，Presto、Impala、Spark、或者当前风头正紧的Flink，无不提供SQL作为高阶数据分析语言。从闭源产品而言，阿里云的MaxCompute、AWS的Redshift、Google的BigQuery，均提供各自SQL抽象以争取更多云上开发人员的使用。据阿里对外宣传的文章来看，基于MaxCompute的离线数仓体系服务了整个阿里集团数万名员工之众、每日运行作业达数百万至多，以至于集团内部包括数据工程师、产品经理、运营人员、财务人员人人可以分析数据，人人可以提取数据，人人皆为数据分析师。可以想像，若非SQL这类高阶业务表达语言助力，阿里集团大数据体系绝无可能有如此规模的受众群体，亦不可能产生巨大业务价值。

实时计算：让计算更快产生业务价值

大数据诞生之初给使用者最大的疑惑在于：为何计算如此之慢？彼时使用数据库多数查询在亚秒级别返回，使用数仓多数查询在数秒级别返回，到Hadoop的大数据时代，大部分查询在数分钟、数小时、甚至于数天级别方才能够查询出结果。大数据、大数据，在一旦解决计算可处理的问题之后，时效性问题便摆上台面。

大数据领域下，时效性分为两个方面：

数据从用户请求到最终呈现的实时性，这条路径强调的是请求响应的及时性。
数据从发生到处理、并最终产生业务价值的全链路时效性，这条路径强调的是数据链路及时性。

前者我们称之为交互式计算领域，后者我们称之为实时（流）计算领域。我一直认为交互式查询是技术方面的优化，是人人痛恨MapReduce计算模型太慢太落后的技术优化，和产品形态并无太大关联。而后者，则是整个大数据产品模型的变化，这是一种触发式计算，有点类似阿里云的FunctionCompute，或者是AWS的Lambda；或者更加准确地定义是：基于事件流的实时流计算。我们通常看到三个系统：

第一代：Storm

Storm 是 Nathan Marz 的心血结晶，Nathan Marz 后来在一篇题为《History of Apache Storm and lessons learned》的博客文章中记录了其创作历史。这篇冗长的博客讲述了 BackType 这家创业公司一直在自己通过消息队列和自定义代码去处理 Twitter 信息流。Nathan 和十几年前 Google 里面设计 MapReduce 相关工程师有相同的认识：实际的业务处理的代码仅仅是系统代码很小一部分，如果有个统一的流式实时处理框架负责处理各类分布式系统底层问题，那么基于之上构建我们的实时大数据处理将会轻松得多。基于此，Nathan 团队完成了 Storm 的设计和开发。

上述将Storm类比为流式的MapReduce框架，我自认为特别贴切，因为这个概念类比更好向各位看官传达了Storm API的low-level以及开发效率低下，这类基础大数据的API让业务人员参与编写业务逻辑好比登天。同时，Storm 的设计原则和其他系统大相径庭，Storm 更多考虑到实时流计算的处理时延而非数据的一致性保证。后者是其他大数据系统必备基础产品特征之一。Storm 针对每条流式数据进行计算处理，并提供至多一次或者至少一次的语义保证。我们可以理解为Storm不保证处理结果的正确性。

第二代：Spark

Spark 在 2009 年左右诞生于加州大学伯克利分校的著名 AMPLab。最初推动 Spark 成名的原因是它能够经常在内存执行大量的计算工作，直到作业的最后一步才写入磁盘。工程师通过弹性分布式数据集（RDD）理念实现了这一目标，在底层 Pipeline 中能够获取每个阶段数据结果的所有派生关系，并且允许在机器故障时根据需要重新计算中间结果，当然，这些都基于一些假设 a）输入是总是可重放的，b）计算是确定性的。对于许多案例来说，这些先决条件是真实的，或者看上去足够真实，至少用户确实在 Spark 享受到了巨大的性能提升。从那时起，Spark 逐渐建立起其作为 Hadoop 事实上的继任产品定位。

在 Spark 创建几年后，当时 AMPLab 的研究生 Tathagata Das 开始意识到：嘿，我们有这个快速的批处理引擎，如果我们将多个批次的任务串接起来，用它能否来处理流数据？于是乎，Spark Streaming 就此诞生。相比于Storm的低阶API以及无法正确性语义保证，Spark是流处理的分水岭：第一个广泛使用的大规模流处理引擎，既提供较为高阶的API抽象，同时提供流式处理正确性保证。有关更多Spark的信息，笔者推荐Matei Zaharia关于该主题的论文《 An Architecture for Fast and General Data Processing on Large Clusters》:

第三代：Flink

Flink在2015年突然出现在大数据舞台，然后迅速成为实时流计算部分当红炸子鸡。从产品技术来看，Flink作为一个最新的实时计算引擎，具备如下流计算技术特征：

完全一次保证：故障后应正确恢复有状态运算符中的状态
低延迟：越低越好。许多应用程序需要亚秒级延迟
高吞吐量：随着数据速率的增长，通过管道推送大量数据至关重要
强大的计算模型：框架应该提供一种编程模型，该模型不限制用户并允许各种各样的应用程序在没有故障的情况下，容错机制的开销很低
流量控制：来自慢速算子的反压应该由系统和数据源自然吸收，以避免因消费者缓慢而导致崩溃或降低性能
乱序数据的支持：支持由于其他原因导致的数据乱序达到、延迟到达后，计算出正确的结果。
完备的流式语义：支持窗口等现代流式处理语义抽象

你可以理解为整个实时计算产品技术也是时间发展而逐步成熟发展而来，而上述各个维度就是当前称之为成熟、商用的实时计算引擎所需要具备的各类典型产品技术特征。Flink是当前能够完整支持上述各类产品特征参数的开源实时流处理系统。关于此，各位看官可以关注这篇文章《容错和高性能如何兼得: Flink 创始人谈流计算核心架构演化和现状》。

全家桶：一套引擎解决“所有”大数据问题

Flink和Spark：All-In-One

大数据全家桶其实是一个实打实的产品问题：从大数据社区反馈的情况来看，对于大部分大数据处理用户，实际上的大数据处理诉求分类有限，基本上在Batch（60%+）、Stream（10%+）、Adhoc（10%+）、其他（包括ML、Graph等等）。对于任何一个大数据处理引擎深入做透一个领域后，势必会考虑下一步发展，是继续做深做专，抑或还是横向扩展。做又红又专？从商业来看，这个领域的市场规模增长可能有限，眼瞅着都到天花板了；但从横向角度来看，周边大数据引擎虎视眈眈，随时都有杀入我们现有市场之中。面对市场，各色需求可穷举；面对技术，引擎基础业已夯实，为何不周边突破扩展，开拓新的大数据领域。Spark从批入手，针对Hadoop处理性能较差的问题，将Spark的Batch功能做成一个“爆款应用”，同时提供Spark Streaming、Spark ML，前期靠Spark Batch为整个Spark社区用户倒流，并吸收为Spark Streaming、Spark ML的客户。而通过Spark大数据全家桶功能，Spark产品构建一个粘性的护城河。大量中小用户一旦全功能上了Spark，大家理解后续很难因为Spark某个功能点不太满足需求而抛弃使用Spark。

Spark从批入手，尝试在一个技术栈体系内统一基础的大数据处理；在另外一个方向，Flink从Stream入手，在构建出Flink Stream强大生态后，也在考虑布局Flink Batch，从Stream切入Batch战场。

下图是Spark的软件栈体系：

下图是Flink的软件栈体系：

两者在产品功能栈上早已十分相似，缺的是各自薄弱领域的精细化打磨。在此，我们不讨论两者功能强弱分布，毕竟本文不是一个产品功能介绍文章。未来两个系统鹿死谁手花落谁家，各位看官拭目以待吧。

Beam: One-Fits-All

前文已述，早期Google在大数据领域纯粹扮演了一个活雷锋的角色，以至于整个开源大数据生态蓬勃发展起来，并最终形成完整的大数据商业生态之时，Google基本门外一看客，眼瞅着自己的技术理论在开源社区发扬光大，自己没捞半点好处。适时，Google云业已发展起来，并拉起诸多祖师爷级别的产品技术服务客户，例如BigTable。常理而言，BigTable开创NoSQL大数据之先河，其Paper位列Google大数据三驾马车之中，技术地位可见一斑。再看社区HBase，乃直接“抄袭”Google BigTable论文理论，实乃徒子徒孙之技术。但最终，Google云发布BigTable产品之时，为了考虑社区产品兼容性以及用户上云迁移成本，竟然不得不兼容HBase 1.0的API接口。可以想象，BigTable项目组成员当时内心感觉只能是：简直日了狗！但一切为了云计算营收，BigTable产品放下技术执念选择兼容HBase接口，实属难得！我们为Google尊重市场而放下身段的行为点赞！

Google受此大辱，吃此大亏，当然会痛定思痛，考虑建设开源社区并尝试力图控制社区。于是在此背景之下，Apache Beam“粉墨登场”。Google考虑问题之核心不在于是否要开源一个大数据处理系统（当时社区Spark已经蔚然成风，Flink的发展同样亦是扶摇直上，似乎社区并无缺少一个好的大数据引擎），而仅仅缺乏开源社区大数据处理接口之统一，包括将核心的批处理以及流处理接口统一。而之前Google内部的FlumeJava一直承担大数据Data Pipeline之API定义角色，于是想当然地从内部将之前的FlumeJava接口进行抽象改进，提供统一的批流处理API后在2016年贡献提交给Apache基金会。试图通过定义一套统一的API抽象层，说服各个厂商实现该套抽象，即可完成API统一的千秋大业，并为用户迁移Google云上埋下最大伏笔。

此类打法构思只能是技术人员对于大数据社区发展不切实际的梦想，或者是Google实在太高估自己的技术影响力，认为只要Google技术一出，开源社区绝对俯首称臣，拉下老脸哭着喊着求兼容。但Google打错算盘的是，从没有一个市场追赶者角色制定标准来让市场领导者来做适配，市场领导者凭什么鸟你。你区区一个追赶者，制定标准，挖下大坑，让领导者来兼容你的标准绝对是痴人说梦。于是乎，在Apache Beam发布之后，除Flink社区意图想联合Beam社区一起做做技术影响力之外，其他开源大数据产品和Beam一直若即若离。大家都是明白人，都明白Google大力推动Beam的明修栈道暗度陈仓，我兼容你标准，最终你不是靠云上产品想把大家的流量全部收割了么。因此，开源社区难以有真心和Beam社区结成歃血同盟者，社区合作者多半皆是善于投机的机会主义者。一时间，Beam的前景黯淡。

结语

本文浏览了整个大数据发展历史，特别重点关注了数据计算处理部分的内容。我们从程序本质以及行业发展脉络分别描述了大数据之前的程序时代以及数据库时代，大数据当代的各类理论、系统、社区发展。我们观察历史，是让我们有信心面对当前；我们分析当代，是让我们有机会看清未来。未来整个云计算以及之上的大数据发展，已经超出本文的讨论范畴，但从上述历史、当代分析能对未来其发展推测一二，欢迎大家自行思考。文章行文较为仓促，定有纰漏之处，望各位看官不吝赐教。

附录

创作场景

大数据十年回顾：浪潮之巅数英雄