导读：大数据是当前最热的技术之一，这十年它经历了哪些阶段？每个阶段分别创造和发展了什么？未来大数据又将朝着哪些方向继续前行？此文系 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、存储优化等等理论精髓，方才以开山立派流芳百世，尔等小屁孩一登场啥都不懂就把祖师爷数十年积累贬的一文不值，砍得七零八落，你这个不是开历史倒车又是什么？数据库提了大致五点问题，摆出架势准备为数据处理的后生小辈谆谆教导一番：

1. 在大规模的数据密集应用的编程领域，它是一个巨大的倒退

2. 它是一个非最优的实现，使用了蛮力而非索引

3. 它一点也不新颖——代表了一种 25 年前已经开发得非常完善的技术

4. 它缺乏当前 DBMS 基本都拥有的大多数特性

5. 它和 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 而言，更是显得后知后觉：

1. Google 云是服务 B 端市场的，但明显 Google 云似乎一直没有意识到其主要客户是 B 端企业。不得不承认，Google 公司围绕消费者的 C 端产品固然强大，但 B 端产品思路以及市场策略实属抽风。Google 一直在强调自己的云标签是“人工智能”，试图通过拉入 AlphaGo 等重磅公关事件来提升用户对于 Google 云的认可度。AlphaGo 火了人工智能，也顺便帮 Google 的 AI 能力大大 PR 了一把，但明显这部分流量并未给 Google 云带来有效的转化，倒是后边大量云计算厂商通过开源深度学习引擎再次“捡漏”。另外，试问人工智能能够带来多少计算资源消耗，人工智能又能够提升多少云计算客户基数。很多情况下，在机器学习领域，一次数据 Training 足够、使用开源软件足够，小公司暂时没有能力也没有数据进行 Training、大公司有数据但大都自行部署开源机器学习引擎自己构建机器学习平台，何来大客户、何来大营收？人工智能在当前整个云计算生态以及大数据生态最多算个云计算公司产品黏性，再不济就只能是市场噱头，叫好不叫座。 按照企业基因学说，天生缺 toB 基因的 Google，想在云计算方面要靠全方位无死角地伺候 B 端客户，试看 Google 天生自带高贵基因，似乎难以铺广开来。

2. 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 体系能够成功，并在数据处理市场占据一席之地，其初期核心因素就在于以下几点：

1. 时机。彼时互联网 Web 2.0 风头正紧，大量用户与网站交互行为爆炸式增长，如何使用廉价的服务器（大量互联网创业公司就是穷鬼，买不起大小型机）去分析各类网站数据的业务需求已经迫在眉睫。此时，大量 Top 互联网公司有数据、有需求、有硬件，就缺一个廉价的数据分析系统。于是乎，开源、免费的 Hadoop 工具正好钻入此类大数据市场空档，迅速占领了核心种子客户群体，并为后续市场推广奠定了群众基础。

2. 开源。开源在开发者社区感染力不容小觑。Cutting 和 Cafarella 通过开源（以及 HDFS 的源代码）确保 Hadoop 的源代码与世界各地可以共享，最终成为 Apache Hadoop 项目的一部分。Google 此时并未意识到开放论文仅仅自我精神爽了一次：让尔等看看我等技术影响力；实际上并未从长远去思考大数据技术影响力构建以及更加长远的云计算商业生态构建。互联网时代下，大量软件被开发者以及背后的互联网商业公司作为开源系统贡献出来，整个互联网开发者行业已经被开源社区完全洗脑，仿佛开源就是人类灯塔，闭源就是万恶不赦。于是，此时，一个开源的、免费的、感觉挺符合互联网精髓的大数据处理软件出现在各大互联网公司圈中，迅速在互联网大数据处理领域触达了这部分市场群体。

3. 商业。早年开源软件皆靠诸位开源运动人士在业界做社区用户推广，这波人本身毫无金钱汇报全靠一腔精神热血。但本质上来说，人类以及人类社会都是趋利性的，没有利益驱动的市场行为终究无法持续。因此，早期没有找到合适盈利模式的开源软件一直发展缓慢，靠类似 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 抽象之价值和特性：

1. Hive 是基于 Hadoop 的一个数据仓库工具，可以将结构化的数据文件映射为一张数据库表，并提供完整的 sql 查询功能，可以将 sql 语句转换为 MapReduce 任务进行运行。其优点是学习成本低，可以通过类 SQL 语句快速实现简单的 MapReduce 统计，不必开发专门的 MapReduce 应用，十分适合数据仓库的统计分析。

2. 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 的大数据时代，大部分查询在数分钟、数小时、甚至于数天级别方才能够查询出结果。大数据、大数据，在一旦解决计算可处理的问题之后，时效性问题便摆上台面。

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

1. 数据从用户请求到最终呈现的实时性，这条路径强调的是请求响应的及时性。

2. 数据从发生到处理、并最终产生业务价值的全链路时效性，这条路径强调的是数据链路及时性。

前者我们称之为交互式计算领域，后者我们称之为实时（流）计算领域。我一直认为交互式查询是技术方面的优化，是人人痛恨 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 作为一个最新的实时计算引擎，具备如下流计算技术特征：

1. 完全一次保证：故障后应正确恢复有状态运算符中的状态

2. 低延迟：越低越好。许多应用程序需要亚秒级延迟

3. 高吞吐量：随着数据速率的增长，通过管道推送大量数据至关重要

4. 强大的计算模型：框架应该提供一种编程模型，该模型不限制用户并允许各种各样的应用程序在没有故障的情况下，容错机制的开销很低

5. 流量控制：来自慢速算子的反压应该由系统和数据源自然吸收，以避免因消费者缓慢而导致崩溃或降低性能

6. 乱序数据的支持：支持由于其他原因导致的数据乱序达到、延迟到达后，计算出正确的结果。

7. 完备的流式语义：支持窗口等现代流式处理语义抽象

你可以理解为整个实时计算产品技术也是时间发展而逐步成熟发展而来，而上述各个维度就是当前称之为成熟、商用的实时计算引擎所需要具备的各类典型产品技术特征。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 的前景黯淡。

结语

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

附录

1. https://www.leiphone.com/news/201901/gLVJGxFuKtGfxwJ6.html
   

2. https://darkhouse.com.cn/blog/2