Flink 推动者莫问：扛过三年双 11，团队半年贡献 120 万行开源代码

Posted 2021-04-13 InfoQ

作者丨赵钰莹

“2005 年阿里巴巴第一次在北京校招，当时特意包了一层酒店，马老师亲自来宣讲会演讲。我刚好知道那个酒店在西四环附近，就去了，也没多想。”

就这样，如今 Flink 项目的核心推动者，阿里巴巴实时计算部门的负责人莫问选择加入了阿里，当时北京分部只有寥寥数人。现在回忆起这段面试经历，他都觉得是“因缘巧合”。

他回忆道：“在当时，这是一个非主流的选择，好多同学基本都是奔着微软、谷歌这样的大型外企去的，觉得福利高，待遇也好。可我听完马老师的宣讲后就觉得很好，而且当时也确实感受到了在线交易的上升空间，身边已经有人开始在网上买东西了。”

没想到，这一冲动下做出的选择，持续了十多年。

下定决心选择 Flink

加入了阿里以后，莫问就去了当时做搜索引擎的团队，并开始关注 Hadoop 开源项目。那时的阿里远没有现在的业务体量，技术上也比较自由，开源还处于朦朦胧胧的状态，还是更多关注业务发展。

2010 年，阿里云成立，那是莫问第一次强烈感受到阿里对技术的重视程度，阿里内部开始出现大量的自研技术体系（飞天），技术氛围越来越浓厚，工程师开始有自主知识产权的意识，很多技术人才成长了起来。莫问所在的阿里巴巴搜索团队也开始尝试基于 Hadoop 和 HBase 等开源技术搭建大数据技术体系，从而处理海量的淘宝商品。

2012 年的双 11，天猫淘宝的总交易额从 2011 年的 52 亿人民币上升到 191 亿，打破了全球网购单日交易额记录，阿里坐稳了中国电商时代的霸主位置。

这时，移动化的浪潮来了。

“当时的趋势是非常明显的，用户随时随地都可以通过手机下单，商品的更新和用户行为的更新都非常快。”莫问整个团队当时就在想，单纯依靠 Hadoop 的批量计算没办法满足电商这种大规模的增长需求，尤其是双十一，不同商品的促销情况（已售罄、爆款了、调价了）变化非常快， 需要大数据实时计算来解决这个问题，当时整个团队开始思考未来实时计算在阿里的整体长期规划或者终局需要什么样的技术。

对于这个问题，阿里内部当时也有相应的解决方案，内部有自研的实时计算技术，也有不同的团队在做，这样同质化的一些技术方案未必是最终的结果，整个团队还是希望可以有一个长期的、全能的计算引擎，当时比对了业界可选的技术方案，比如 Storm、Spark 和 Flink，最后团队决定选择 Flink。

最开始，我们觉得 Storm 的使用人数比较多，但感觉这个技术没有 High Level 的 API，也不够丰富，写起来成本比较高，没有 SQL 语言，也不能做批量计算，只是一个纯流式的计算，不能做好批流融合这种全能的计算能力，只能解决局部的问题。相比较而来，Spark 是一个比较完整的计算引擎，也可以做批量计算，但是流式计算的速度会很慢，要一段段执行，并不是真正的纯流式技术，所以我们决定选择 Flink。——莫问

扛过了三年双 11，从两个人到几百人

下定决心之后，当时的莫问放弃了手里正在做的项目，拉了另一位小伙伴就开始研究源代码。没错，Flink 项目最早启动时，只有两个人。莫问说道：“一个项目肯定要有资源，也就是人，但那会儿想在阿里找几个有实力还有时间的人实在太难了。阿里内部的竞争也非常激烈，业务发展很快，从写下 Blink（Flink 在阿里的内部版本）第一行代码开始算，也只有大半年的时间准备，然后就需要支持第二年的双 11。”

2015 年 9 月份，项目开始正式启动，整个团队写下了第一行代码。2016 年 5 月份，系统正式上线，只用了大半年的时间。“我们其实是非常迅速的闪击战，毕竟阿里内部竞争非常激烈，业务发展也很快，如果一个项目投入了很久却没有产出，很难再得到其他资源，我们其实只有一次机会，那就是上线后经过几个月的大型业务验证，才能在当年（2016 年）的双 11 上线，如果九月份还没有全部准备好，没人有信心敢让你双十一上线。”

2016 年 9 月份，整个团队开始陷入 996 的状态，甚至 007，这一年是 Flink 第一次支撑阿里双 11，目标是支持搜索推荐系统，包括最核心的机器学习平台，所有淘宝和天猫的用户事件行为日志都需要梳理一遍，而且不能出现延迟，不能有任何的分布式，为了保证最后一切顺利，团队的同学国庆七天都在备战，不停地优化和调试系统，模拟峰值流量不断压测，一直持续到 11 月 10 号下午，而此时也进入了双 11 倒计时，团队开始进行最后的巡检，忐忑地等待双十一的流量轰炸。

好在，这一年顺利扛过了双 11。然而，此时的莫问可能也没想到 2017 年的双 11 压力会更大，因为这一年，集团决定双 11 的所有核心业务全面上线 Flink 项目。当时，阿里已经开始建设内部的中台，把其他不同部门的实时计算技术，比如 JStorm，全部与 Flink 项目进行合并，因为经过了前一年双 11 的验证，所以内部对 Flink 是非常看好的，这些人员也全部汇集到了 Flink 的团队，此时的团队规模可以达到百人了。随之而来的是业务的数量级式增长，这一年也是阿里第一次接入双 11 全球直播大屏，一旦屏幕出现卡顿，后果可想而知。

“双 11 之前，我们没有大肆宣扬这件事情，因为不知道结果如何。双 11 刚开始，各种战报就出来了，到一百亿用了多长时间，全球交易量是如何分布的，哪个类目排名第一等等，这些排名都是基于 Flink 做的，这就相当于我们的第一次大考。”莫问回忆起当时的场景说道。

在经历了这次大考之后，阿里整个集团的 BU 几乎都采纳了 Flink，但新的技术挑战又出现了。莫问表示，虽然经历了两次双十一的考验，信心会更大，但业务量的增长也让他们发现不能单纯通过增加机器的方式来满足需要了，团队就开始琢磨新的解决方案。

2018 年，团队开始尝试用 SQL 语言支持 Flink 的业务，这是最通用的表达式，但流式 SQL 可以大大简化数据分析的开发成本，这样可以提升效率，但问题就是这相当于为整个技术架构做一个更新，所有的东西都要升级换代，在业务量更大、数据量更大的情况下，团队负重前行。

2017 年，我们支持了将近 5 亿的 QPS，2018 年双 11，我们支持了超过 17 亿 QPS，我们无法成倍的增加机器，只能不断地改造、优化整个系统。

2018 年双 11 实时计算作战室

2019 年初，阿里巴巴宣布正式开源内部 Flink 版本 Blink，逐步将 Blink 的改进推进回社区，这也就意味着整个团队不仅要支持阿里内部的双 11，还需要推动 Flink 社区的良性发展，对社区积极贡献。

除此之外，阿里云上也提供 Flink 相关产品，这些产品背后的客户包括国内众多中大型互联网公司，一旦出现失误，很难弥补。多线并行支持成为了整个团队今年最大的压力。为了应对这种压力，整个团队内部也进行了非常明确的分工，比如，有些人会专注于基础引擎层面的开发，有些人会专注于 SQL 层的开发，有些人的工作重点会放在 Flink 生态上等，合理的团队分工让整个团队可以更加高效的应对各方压力。

史无前例的丰富应用场景，促使整个技术团队能力不断提升，他们也把探索出来的成果第一时间反馈给社区。

半年贡献 120 万行 Flink 代码

在三年为了双 11 奋战的同时，整个团队对 Flink 项目做了大量的贡献。

当时并没有想到这件事情会有这么大影响力，只是想着我们作为一个技术团队，应该如何支撑好业务，进一步想到的才是社区影响力。

2016 年，莫问所在的团队开始对外分享 Flink 相关的事情。当时 Flink 在开发者眼中，仍然是一张崭新的面孔，熟知的人并不多。

但是，团队并没有放弃，持续不断将改进推回社区，并举行了多场技术沙龙。到了 2018 年底，阿里巴巴主办的 Flink Forward China 大会吸引了超过业界千余名开发者前来，大家不仅看到了 Flink 在阿里得到的成功，同时看到了 Flink 在字节跳动，美团，滴滴等公司也开始被采用，接下来在 2019 年 Flink 开始在中国加速开花结果。

做开源，我们的第一反应是责任。听起来好像很简单，但这不是一个简单的硬件，给你就完了，这些代码都需要一点点推回，还需要遵守开源社区的一些准则。我们不能让别人觉得阿里是在硬推，需要在社区中跟开发者一起讨论，大家都觉得合理才可以推进去。就这样，我们团队半年时间就向社区推进了 120 万代码。

回顾在阿里工作的这 13 年，莫问表示：“这么多年来，阿里对开源的支持力度越来越大，也陆续把项目捐给了 Apache 等基金会，规则也在不断完善。要是让我说阿里为什么要贡献开源，我还是觉得是身上的一份责任和热爱。”

点个在看少个 bug