顶灯闪烁，笛声响彻。

救护车载着病人，冲向茫茫车海，在时间的赛道上狂奔。

高德地图、GPS 卫星导航、路面磁感线圈、1300 个路口摄像头同时开动，为这辆救护车勘探最快路线；

GPS 传回实时数据，后台根据辅助数据纠偏，锚定救护车每一刻的精确位置；

救护车将要经过的沿途，车辆情况被实时计算。确保路口绿灯提前亮起，在救护车通过之前，刚好所有社会车辆已经行驶一空。

这不是演习，这是杭州城市大脑每天都在执行的任务。依靠计算，一辆救护车到达医院的速度，平均缩短了 50%。在这座城市，靠鸣笛和闯红灯开道的悲壮彻底成为历史。

说人同蝼蚁，其实并不为过。两百多万辆车奔跑在城市里，他们的行踪像风里的落叶一样叵测。但通过对 1300个路口的摄像头的实时计算，城市大脑就可以精确地预测出未来十五分钟、未来半小时那哪个路段将会拥堵，从而第一时间指挥路口信号灯“变换姿势”。

计算在帮人类追赶时间。

中哥今天要说的，就是这个精致而坚固的“大数据实时计算引擎”。

 

你可能从未听说过这个引擎，甚至在此刻之前都不知道它的存在，但你很可能早已成为这个引擎服务的一员：

一年一度的双11，无数人涌进天猫，每个人都能用 0.1 秒搜索到自己理想的商品，在智能推荐中发现适合的宝贝，背后正是依赖这个引擎；

双11庆典现场，大屏上那个跳动的总成交量数字，只是背后所有数据的冰山一角。几十亿种商品的实时库存、价格、优惠数据得以分秒不慢地同步给屏幕前的你，也同样依赖这个引擎

从某种意义上来说，只要给这个计算引擎足够的资源，无论面对多么庞大复杂的系统，我们都可以用几乎忽略不计的时间看到真相——这大大快于人类最聪明的大脑。

这是我们亲手创造的“先知”。

重器难成。为了这个先知一般的“大数据实时计算引擎”，阿里巴巴最核心的技术人，已经耗费了将近五年时间。

让人感慨的是，这个承载了一个个城市的交通，扛起了一条条生产线，担负了一个国家十几亿人购物的强大引擎之所以的诞生在阿里巴巴，最初并不是为了满足什么需要，而仅仅是因为它“看上去很美”。

这是一个鲜为人知的故事。

1999年，阿里巴巴在杭州成立。

同样在1999年，蒋晓伟正在美国攻读理论物理博士。作为一个初三就立志要探索宇宙秘密的年轻人，到目前为止他的人生堪称完美。

就在一个崭新的物理学家即将出炉的时候，命运开始展现它的波云诡谲。蒋晓伟突然被自己的导师“忽悠”到了一家非常有希望的互联网初创公司。理由是：“在30岁之前先财富自由，以后爱怎么学物理就怎么学物理。”

一年之后，互联网泡沫破裂。

然而，蒋晓伟却留在了这片战场。2002年，他加入微软，2010年他加入 Facebook。弹指挥间，直到回国加入阿里巴巴之前，他已经从物理学家成功转型成为数据库和计算资源调度系统专家。

他还记得，自己加入阿里的时间是 2014年12月29日。这是一年中可以办理入职的最后一天。

“为什么选最后一天？”

“因为看上去比较有美感。”

“。。。”

目测，蒋晓伟是我见过的第一个用物理公式般的美感对待人生的人。甚至，他给自己起的花名都想叫做“量子”，后来思考了一下，觉得量子不太像个人名，才改为谐音“量仔”。

蒋晓伟入职的是阿里巴巴集团搜索团队。你可能会问：纳尼？阿里巴巴还有搜索团队？当然有，而且还极其重要。举个搜索引擎的日常：

当你在淘宝搜索框里输入“杜蕾斯”的时候，搜索引擎就马上行动，从亿万卖家出售中的宝贝里帮你找到合适的 TT（及其他产品），然后按照推荐顺序排列在搜索结果里。

注意，有趣的硬核要来了：

如果，商家的 TT 价格永远不改，库存永远无限，优惠促销方案永远不变，那么搜索团队只需要做一个最简单的查询系统就行了。

但是，现实中商家会随时调整价格和优惠，某一款激情大颗粒也可能因为太受欢迎，上架十秒就卖到缺货。在淘宝网上，你会发现真实的状态是：每时每刻都有无数卖家的产品参数在改动。

所以，搜索引擎的挑战就是，要根据每时每刻最新的数据库来瞬间算出最适合呈现给你的搜索结果。

相信我，只有用最新鲜的数据算出的结果，才能让屏幕对面的你露出心满意足的表情：

面对这种现实，一个最稳妥的方式就是，搜索引擎用把现在的数据库全部算一遍，给出结果。

但是，这会耗费大量的计算力。毕竟这一秒相对于上一秒来说，可能发生参数变动的宝贝只有十个，而没有参数变动的宝贝有十万个。

那么，你自然会想：“有没有一种方法，让我只计算改动的部分，再通过特别的数学运算和之前的结果融合，就能达到和计算全量数据一样的效果呢？”

有的，这就叫“流式计算”。

打个最简单的比方：

你负责把椰汁平分给10个妹纸。刚开始你有10瓶椰汁，于是你一人分了一个。后来，你又得到了10瓶椰汁，这时候椰汁的总数变成了 20 瓶，平均每个妹纸应该得到两个。

但你没有必要把之前分给妹纸的椰汁收回来，重新每人给两个；而是可以让每个妹纸手上拿着之前的那瓶椰汁的基础上，每人再补发一瓶。

通过这个例子，我猜你已经感受到了“流式计算”的激荡。当然，实际的数据库运算比“分椰汁”复杂得多。

需要说明的是，当时在阿里巴巴内部，并不是没有流式计算引擎，各部门都根据自己的需求研发了特定的流式计算引擎，只不过，大多引擎只用来解决各自部门的问题，没有通用性。

但蒋晓伟突然发现，流式计算背后隐藏着一个神奇的事实：

既然只计算增量，就能得知全量的结果；那么就可以永远用计算增量的方式来表达计算全量。

也就是说：增量计算等效于全量计算；流式计算等效于批处理计算，实时计算等效于离线计算！

也就是说，如果按照这个构想做出一套完整功能的“流式计算引擎”，就可以一统江湖，运转在阿里巴巴所有的技术底层。这可是一份不小的产业啊！

蒋晓伟越想越鸡冻。

然鹅，让他激动的最主要原因竟然是：“这个引擎太完美了！”他发现，其实自己身体里的那个“物理学家”一直都在。物理追求的终极就是“大一统理论”——用一套机制解决所有问题。没想到人生峰回路转，在计算机领域也给发现了一个“大一统”的机会。

老实说，蒋晓伟老湿傅这个想法有点危险。危险在哪呢？

首先，如果把当时搜索业务需要的流式计算比作汽车发动机的话，蒋晓伟想要研制的发动机，是豪华到可以用到下一代宇宙飞船上的“核能发动机”。自己团队支持的这摊子业务目前根本不需要这么好的引擎。

其次，研究这个引擎的基本动力居然是“美感”。出于美感开发一个计算引擎，这种动机天然就有一种理想主义气质。。。能不能研究成，那只有天知道。

再说，面对这么宏大的任务，手下能用来做研发的团队，只有五个人。况且这五个兄弟还有日常的任务，人手极度短缺。

“但马老师不是说了么，梦想还是要有的，万一实现了呢？”

刚刚加入阿里的蒋晓伟倒是决心已定。

蒋晓伟“能用”的团队，全员都在北京。

这个小分队的老大叫做王峰。王峰是个老阿里了，2006年加入阿里巴巴，在阿里北京的雅虎中国团队做搜索，后来又做过一淘和淘宝搜索。此时此刻，他和北京的几个兄弟主要负责一个开放搜索项目的离线系统。 

听到蒋晓伟对于“流式计算引擎”的描述，王峰内心惊呼“卧槽”。对于一个合格技术宅来说，一个好的技术构想比萌妹子更能让他动心。

蒋晓伟和王峰一合计，事情很简单：脚踩两只船，那基本没戏。要么就趁早死心，放弃新引擎研发；要么就大家就把旧工作完全交出去，破釜沉舟干票大的。

王峰的决定是，干！

王峰回忆，领导们觉得很不可思议。因为交出原有的业务，北京这个小团队相当于“失业”了。而新的研究——流式计算引擎——当时只是个构想，连技术方向也没有，代码更是一行都还没写。对于王峰来说，这相当于一次破釜沉舟的内部创业，前途未卜，凶险异常。

事实也证明，别人的担心都是对的。一开始团队努着劲儿写了三个月代码，仍然没办法达到蒋晓伟理想中的通用性，连他本人都有点心虚。

“我刚来阿里巴巴，就忽悠兄弟们把之前的项目都放弃了，要是最后证明我的构想是个坑，那不是害了别人么。。。”他想。

焦急之中，已经到了 2015 年夏天，蒋晓伟突然在业内著名的大数据峰会 Hadoop Sumit 的论坛上看到有人发表了一个惊悚的评论：感觉 Flink 出来之后，Hadoop 就显得不怎么需要了。。。

Hadoop 是当年最火的大数据分布式架构，这个 Flink 是个神马，根本没听过啊。但是当蒋晓伟、王峰和团队研究完技术资料之后突然发现，这种“用流式计算来等效一切计算”的理念不就和我们想开发的那套引擎一模一样吗？

蒋晓伟仰天长啸：

真是天助我也！既然已经有开源的技术，那么我们只要在此之上继续开发流计算引擎就好了啊！

这里多介绍一句。Flink 是一个流式计算的开源框架，2010 年诞生于德国研究中心和柏林工业大学，2014年被捐赠给 Apache 基金会，并由创始公司 DataArtisans 继续运营。

简单来说，2015年的时候，Flink 刚刚“出道”一年，几乎没有人知道，更没有人大规模使用。就像一个刚刚毕业的大学生，看上去很有潜力，但“稳定性”和“实用性”都缺乏事实验证。

就这样，这帮阿里巴巴的技术专家，成为了全球第一批使用 Flink 框架做大数据引擎研发的人，蒋晓伟一瞬间就给自己的引擎起好了名字——“Blink”。这是英文眨眼的意思。”一眨眼，所有东西都计算好了！“

2015年底，搜索部门要向阿里巴巴 CTO 行癫汇报。每人20分钟时间，结果蒋晓伟上去讲 Blink，沉浸在对这个“完美引擎”的想象中，一下就说了40分钟。

作为阿里巴巴所有核心技术的掌门人，行癫素来对新技术很敏感。他听懂了蒋晓伟的技术路线，内心也觉得相当靠谱。但这毕竟是搜索团队自己“偷偷”搞的项目，这帮兄弟究竟可以坚持走多远，行癫心里也没底。于是鼓励蒋晓伟说：“那就等你们明年做出来，我们再看！”

说到底，Blink 是一个通用引擎。它就像一个万能发动机，可以装载到轿车、卡车、飞机、火箭任何地方。

蒋晓伟手握这台“万能发动机”的1.0版本，到处去找车实验。他盯上的“第一批车”，就是搜索业务中的使用场景。

简单科普一下：

搜索业务的机器学习平台内部代号叫“保时捷”（还真是一辆车。。。），可以根据你浏览商品的时间和动作，实时判断出你可能会对什么感兴趣，从而在下一秒就能给你智能推荐可能喜欢的商品。这是阿里巴巴非常有技术含量的一个应用。

实际上，机器学习平台当时已经“心有所属”，配有一台流式计算引擎——之前王峰带领搜索团队自研的 iStream。iStream 是专门为搜索设计的，虽然目前可以很好地完成任务，但结构简单，不具有特别强的通用性。

机器学习算法团队的一位负责人仁基，技术思想非常超前，非常巧的是，他同样是个执着于“美感”的人。他相信，未来 Flink 很可能会成为下一代机器学习算法重要的底层计算框架，于是在 Blink 系统研发的早期，就把团队里一百多位算法工程师的力量都用来配合蒋晓伟。

“一两百人的团队，被我一个人折腾。”回忆到这里，蒋晓伟露出了羞赧的表情。

说得很美好，结果真拿来 Blink 一用，动不动就躺尸。。。说实话，算法工程师没有义务为 Blink 的技术问题买单。毕竟算法工程师是“生产汽车的”，而 Blink 这个“发动机”质量不稳定，导致人家的汽车备受诟病，可以说相当冤枉了。

所以那几个月一百多位算法工程师的日常就是各种吐槽“疯子”蒋晓伟。

后来蒋晓伟才知道，这些吐槽，全都被仁基扛下来。仁基尽自己一切所能，在保护着这个弱小的 Blink。

终于，2016年5月，第一个基于 Blink 的机器学习小功能“A/B Testing”上线。虽然还存在一些青涩的小毛病，但所有的技术人都看到了，Blink 已经像会呼吸的小兽一样，泛出诱人的引擎光泽。

最激动的，当然是蒋晓伟本人。

他把自己在 Flink 上成功的应用作为一个演讲，投给了当年的 Hadoop Sumit 大会。非常巧，Flink 的创始人 Kostas 和 Stephan 也在同一个大会上有一个演讲。他们两拨人实际是那次 Hadoop 大会上唯二的 Flink 演讲。

Kostas 提前看到了议程，顿感相见恨晚，于是主动联系了蒋晓伟，希望他能用团队研究的成果影响社区。

“本来之前是想自己玩玩的，我们连阿里都不敢影响，还敢影响社区？”蒋晓伟说。但是 Kostas 和 Stephan 觉得这群阿里人的尝试简直不要太酷，特别支持。

蒋晓伟深受感动，“从那时候开始就觉得，我们不仅得把阿里内部的业务做好，还要为 Flink 社区做贡献，把 Flink 社区做好。”

就这样，蒋晓伟和团队就跟组织“接上了头”，成为了 Flink 社区的核心成员。

在搜索团队内部证明了 Blink 能力，又得到了 Flink 社区的认可，蒋晓伟终于有资格正视自己的“野心”了。

他提出要让 Blink 支撑“双11”上的实时机器学习任务，对方同意了。

也就是说，双11当天，数亿人在淘宝天猫搜索商品，他们的每次查看，点击，都会影响个性化的智能推荐，在下一秒就能看到为自己量身定做的宝贝推荐。而这背后的实时计算，都要由 Blink 来支撑。

然而抬眼一看，夏天已经到了，距离双11只有不到半年了。

整个九、十月份，Blink 和机器学习系统的联调都处在各种花式崩溃之中。Blink 还小，压根就没见过双十一这种“人类狂欢”的阵仗。出现了一个死结：一旦超大规模数据进来，Blink 的性能立刻大幅下降。

要知道，在 AI 领域，性能就是功能。性能大幅下降的 Blink 分分钟就把人工智能坑成“人工智障”。

老程序猿都知道，数据规模是对一个系统最大的考验。一个系统承受不住大规模的数据浪潮，有可能证明这个架构就是无解的。如果真是架构缺陷，那么解决方案只有一个：放弃。

带领团队攻坚的王峰回忆，那几天“自己已经崩溃了”。

十一假期，所有团队的人都从北京冲到了杭州，别说休假，连觉都不睡了。六七个人就在工位上吃住，寻找究竟是哪个节点出了问题。即使是面对这样的情况，蒋晓伟、王峰，还有其他同事都完全相信，Flink 架构是完美的，问题一定是局部的可解的，只是我们还没找到它。

终于，问题找到了！是不同层级算子之间的调度模式需要优化。解决这个问题之后，系统能处理的数据量立刻跃升。十月中旬，Blink 正式切上线。本以为劫波渡尽，没成想又是一大堆系统配合的问题接踵而来。

蒋晓伟记得，将近11月，Blink 还有一些问题没搞定。这边基础引擎不搞定，算法团队就没办法在它的基础上调优双11的算法。到最后，算法团队的老大都直接找到蒋晓伟，着急地质问：“你们究竟是怎么回事啊？”

现在想想，他的意思可能是想让我别折腾，直接换回去年的旧系统。但我的情商低，当时没听明白。就是一门心思地组织大家调优 Blink。。。

蒋晓伟回忆。

终于赶在11月前，Blink 完成了联调。原则上，从11月1日开始，双11的系统就要封闭代码，谁都不能动了。但是，这是 Blink 第一次承担这么重大的任务，为了万无一失，相关团队又提了很多冗余性的建议。

王峰记得很清楚，一直到11月10日，还有几个小时双11就开始了，代码还最后改了几行，最终封闭。

人事已尽，唯听天命。

11月11日，巨大的数据像海啸一样涌向 Blink，蒋晓伟和王峰都捏了一把汗。然而，这个年轻的引擎应对自如。

第二天，Blink 在阿里巴巴一炮而红。

你以为故事结束了么？图样图森破。紧随而来的 2017 年对于蒋晓伟来说，简直不要更刺激。

意识到大数据引擎这么重要，阿里巴巴集团决定调整组织架构，集全公司之力发展大数据引擎，由原阿里云的首席科学家周靖人组建计算平台事业部，在流式计算方面，把公司发展最好的三个引擎团队合三为一。

这三个引擎分别是：阿里中间件团队的 JStorm、阿里云的 Galaxy、阿里巴巴搜索团队的 Blink。

得知大牛周靖人负责整合三个团队，正在美国参加 Flink 官方大会 Flink Foward 的蒋晓伟和王峰内心有点波澜。他们知道，三个队伍合并之后，很可能在三条技术路线之中选择一条。

蒋晓伟当然觉得自己的开源技术路线技术前景最好。但平心而论，Galaxy 的框架同样非常优秀。更关键的问题在于，Galaxy 一直是周靖人团队的成果。虽然在阿里巴巴不会出现因为亲疏远近而偏袒某个技术路线，但不可否认周靖人一定对于 Galaxy 更为熟悉。

那时的蒋晓伟，和这个即将成为新领导的周靖人完全不熟悉，他完全无法预测将会发生什么。

我担心，不会一回到国内，就没工作了吧。。。。

蒋晓伟回忆。

回国之后，周靖人来找蒋晓伟，蒋晓伟的心已经快跳到嗓子眼了。周靖人说：“我想把整合之后的团队交给你来负责，你们三人一起商量未来的技术路线，你觉得怎么样？”

这意味着，蒋晓伟突然拥有了80人的豪华阵容。那一瞬间他在心里默念：“稳了！”只要不是强制采用某个技术路线，他就有信心说服 Galaxy 和 JStorm 的负责人。技术摆在这里，孰优孰劣是能讲得清道理的。

蒋晓伟回忆，三个技术负责人的“谈判”整整维持了一周。

大家都知道，这次技术路线的抉择，将会影响阿里巴巴未来十年甚至更远的技术发展，谁都不敢掉以轻心。

谈到最后，争夺的焦点就集中在 Blink 和 Galaxy 之间。

Flink 的开源生态，最终说服了Galaxy 的支持者。此时的 Flink 已经不像两年那样鲜有人问津，而是已经形成了巨大的社区，中国已经有腾讯、滴滴、美团等公司开始用 Flink 建造自己的流式计算引擎。

在这个社区里，会有无数国内外大牛对 Flink 的代码做贡献。建立在这个开源基座上的架构，也会发展得更快速。

至此，Blink 正式成为了阿里巴巴计算引擎的王牌军。

王牌军可不是白当的。

2017年双十一，Blink 领到了自己的艰巨任务——支持全集团（阿里巴巴、阿里云、菜鸟）的流式计算任务。

王峰告诉我，其实2016年双11 Blink 承担的搜索任务，已经是一个重头戏，有过这个经历垫底，再适配很多系统的时候只不过是麻烦一点而已。唯独有一样：Blink 要接管后台所有的交易数据的实时计算任务。

交易数据计算，是淘宝天猫业务的最核心。也是支撑背后支付、物流的核心依据。

很多其他的计算都要基于订单数据的结果。这就像面包店的面粉一样，无论你做什么蛋糕，都需要面粉。如果面粉的供应出问题，那整个面包店就要关门了。所以无论面临多大的订单量，交易数据计算必须稳定、快速、实时。一旦出现错误，损失无可估量。

每年双十一狂欢晚会上的那块大屏幕上显示的实时成交数字，也是由订单数据汇总而成的。也就是说，如果 Blink 当天挂掉，不仅对淘宝天猫的运转影响巨大，还会导致一个略为明显的结果：成交量大屏一直维持“0”，一秒把人丢到全球无死角。

2014、2015、2016 这三年，这个核心任务都是由兄弟引擎 Galaxy 来承担的。

所有人都想到一个稳妥的方案：2017年“双11”让 Blink 和准备退役的 Galaxy 来个双备份，如果 Blink 临时废掉，还可以用 Galaxy 作为备份顶上，至少不会丢人。

然鹅，2016年双11的成交量是1207亿元，按照历年经验推测，2017年的成交量八成是会超过1500亿的（事实证明确实如此，达到了1682亿）。而根据 Galaxy 的技术架构，如果不做大量繁琐的优化，很可能顶不住。

初出茅庐的 Blink，就这样成为 2017 年双11媒体大屏“全球指定唯一必须顶上不干不行合作伙伴”。。。

双11 当天，两条 Blink 链路互为备份。“虽然成功率基本是100%，但万里有一，假设 Blink 本身设计存在未知的缺陷，或者两条备份链路的机器硬件同时坏掉，都可能导致灾难。”蒋晓伟回忆。

在双11到来前一周，王峰带领兄弟们已经把 Blink 引擎调整到无以复加的好状态。蒋晓伟想了想，又派同样是 Facebook 回来的大牛工程师大沙去天竺法喜寺烧了一炷香。。。

2017年11月11日零点。狂欢现场。

时钟敲响零点，然后出现五秒倒计时。按照流程，留给 Blink 的计算时间只有这五秒。也就是说，00:00:05 的时候，无论如何大屏幕都会切到 Blink 给出的双11前五秒交易总额。

这五秒，几乎是蒋晓伟人生当中最漫长的五秒。

1、2、3。。。

第三秒的时候，蒋晓伟面前的监视器跳出了实时成交数据！再两秒之后，实时交易数据被投上大屏，穹顶之下，欢声雷动。

蒋晓伟知道，现场观众并不一定理解大屏运行原理，内心也并没有特地把一份掌声送给幕后的流式计算引擎团队。

但那一刻，他热泪盈眶。这几年兄弟们付出的努力值了。

经过两年双11的考验，已经没人怀疑 Blink 是阿里巴巴最强悍的计算引擎之一。

所以，不仅阿里巴巴集团所有用到流式计算的场景都会选用 Blink，Blink 还开始对外提供服务。虽然在蒋晓伟看来，各个场景的计算都可以用 Blink 来解决，但目前被应用最多的场景有如下几个：

1、实时统计分析。

在电商行业，尤其是促销的场景中，巨大的网络流量涌来，形势变幻莫测。每一秒的库存统计、订单报表，都能揭示出用户的行为规律。对这些数据进行实时分析，就能随时调整促销策略。

2、在线机器学习。

用户的行为会展现出他的性格和偏好，用机器学习分析一个人浏览商品的姿势，就能为他精准推荐可能感兴趣的商品。

但是，可能一个用户只浏览一分钟，如果在这个时间段内没有能够吸引他的商品，它就会退出。所以必须在一秒钟之内，对他刚才的动作进行实时学习，才能保证他第一时间看到感兴趣的宝贝。

3、实时金融风控。

在金融领域，技术就是金钱。每成功阻断一次欺诈交易，就等于挽回了真金白银。通过对一个账户实时行为的分析，就可以知道现在它有没有进行危险交易，从而在第一时间阻断。

4、IoT 边缘计算。

在工厂中，每台生产线都会随时产生数据，如果可以实时对这些数据进行分析，就可以减少生产线的损坏几率，提高产品的良品率。

如此，才有了开头一幕所说：阿里云承建的城市大脑，可以利用 Blink 来预测道路拥堵，为救护车开拓生命道路。

根据阿里云首席科学家闵万里博士的介绍：

2018年，城市大脑第一次出国，被部署在马来西亚吉隆坡，把救护车到达现场的时间缩短了 48.9%。

借助工业大脑，流式计算实时判断生产线的健康状况，帮助世界第一大光伏企业协鑫光伏提高了良品率1%，每年可以节省上亿元的无谓浪费。

2018年12月20日，阿里巴巴将 Flink 的旗舰会议 Flink Foward 第一次引入中国，现场座无虚席。蒋晓伟、王峰和流式计算团队的每一个人，在过去的三年都亲眼见证了 Flink 从踽踽独行到集结成军。

为了感谢社区的帮助，在这次会议上周靖人宣布，在未来会把基于 Flink 修改的 Blink 流式计算引擎开源。从2019年1月开始，所有人都可以查阅这个支持了双11、支持了城市大脑、支持了工业IoT等无数顶级计算的引擎代码。

也就是在这一年，王峰正式接替蒋晓伟，成为流式计算的新掌门。而蒋晓伟则朝着他的“完美梦想”更进一步，带着一帮兄弟在此基础上研究“带有流式计算引擎的数据存储系统”——交互式查询系统，让这个引擎能够解决更多通用的计算问题。

带有流式计算引擎的数据存储系统，听起来有些不知所云。其实，这个世界上最经典的这类系统，其实就是我们的大脑。

我们一生中会接受各种信息，这些信息共同构成大脑的资料库，帮助我们预测未来。每当有新的信息进来，我们都会根据这一点点信息增量微调我们对于未来的预测。

这种调整，毫无疑问是实时的。我们的祖先不小心触摸野火，从那一刻开始就会告诉自己和家人小心火焰。

我们依靠对世界的万亿次反馈，发现了万有引力，发现了相对论，发现了量子力学。

正是千万人实时更新的预测能力，构成了我们的文明，也书写了我们的历史。

以前，所有关于未来的预测都在我们的脑海里，如今，我们终于有机会在躯体之外，利用人类的武器——计算力——建造起一个硕大的预测引擎。

角落里，这些技术英雄笑起来安静而羞涩。但正因他们存在，人类面对未来，再也不是手无寸铁。

 

原文链接
本文为云栖社区原创内容，未经允许不得转载。