硅谷海归工程师，3年阿里开发生活：Flink及其在阿里Blink中的应用！

Posted 2021-04-13 养码场

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了硅谷海归工程师，3年阿里开发生活：Flink及其在阿里Blink中的应用！相关的知识，希望对你有一定的参考价值。

图左：大沙图右：养码场记者kira

8月22日上周三晚，养码场联合Flink China进行了一次技术主题专访直播。

由养码场主持人专访阿里巴巴资深技术专家、Apache Flink Committer王绍翾（花名大沙），谈论：Blink计算二三事。

2015年加入阿里巴巴集团，目前就职于阿里巴巴计算平台事业部。早期负责搜索事业部的离线大数据处理，之后负责 Blink 计算平台的SQL引擎和机器学习的相关架构设计。

场主发现，随着Flink在国内异军突起，很多技术人对此都产生了浓厚的兴趣

一则苦于相关的教材、教程少
二则不了解Flink的实践应用场景

因此，场主希望通过这次与大沙的对话，让技术人对于Flink的现状、其在阿里的应用有更深入的了解，而大沙对于技术的观点也能给到你们以启发。

硅谷工程师

进入阿里：挑战大数据或许更有意思

在硅谷当工程师是种什么体验？

“美国的工程师更加Open，有idea会直接指出来，不像中国工程师都比较害羞。也更加独立，有问题会先选择Google一下自己搞定，每个工程师都很注重开发效率。当然，国内的工程师也在改变，这些方面也在慢慢做得越来越好。”

北大本硕毕业后，大沙选择出国留学，在加州大学圣地亚哥分校攻读完计算机工程博士学位。他说，读书期间就经常回国，也看到国内移动互联网的发展。或许这时候，就已经种下了一颗归国的种子。

毕业后，他有了一个新标签：硅谷工程师。曾在Facebook开发分布式图存储系统TAO，海外的工作不错，但是2013年的时候，身边的朋友陆陆续续地选择回国。他想着：或许国内有更大的空间，更好的机会。2015年，大沙入职加入阿里。

一开始完全没有想过会做Flink，包括现在的Blink（阿里基于Flink研发的计算引擎）。只是“知道阿里数据量很大，回来做大数据领域应该会很有意思”。

随着大数据技术的不断发展和成熟，“快人一步”成为企业更为关键的竞争力，如何快人一步？在批计算之后是实时流处理的需求在日渐增长。

谈及Flink及其在阿里新一代计算引擎Blink中的应用，大沙很有体会。

Storm、Spark？

旨在批流统一的Blink：选择Flink更适合

在阿里搜索事业部，需要把每天的商家数据进行重新计算，由于数据量很大，是离线作业，此外也需要实时的作业把一些数据尽快地更新到搜索引擎。

另外，像淘宝这么大的电商平台需要做实时推荐。所以，不像一些小的公司，在阿里有一部分是离线计算，还有很大一部分是实时计算。

在这样的背景下，自主研发一套实时计算引擎成为了“拥抱变化”的选择。

“我回来后，这个项目刚刚开始。” 由于在实时部分看到了Flink的一些比较明显的优势，阿里选择基于Flink开发新一代计算引擎Blink。

大沙表示，考虑过Storm，也去拜访过Spark的团队，但最后还是Flink更“合适”。

1、Storm不支持批计算，很多复杂的逻辑都需要用户自己实现，而Flink 能够支持批流统一；

2、在实时部分， Storm的语义不支持精确计算，使用Flink能够花费更少的精力；

3、在状态管理和容错方面，Flink具备天然的优势（设计之初就非常在意性能相关的任务状态 state 和容错等关键技术的设计）；

4、16年初也拜访了Spark，但是对方的团队并不认为“超低延迟很重要”，也就是说在发展的共识方面，Flink更适合阿里对于“实时”的需求。

而在机缘巧合之下，阿里正在使用Flink被德国的Flink创始团队创办的公司data Artisans知道了，他们专门来杭州拜访了阿里。

双方一拍即合，阿里选择跟Flink社区深度合作，多方idea一起碰撞，和开源社区一起开发、成长。

大沙也曾多次拜访位于德国柏林的dataArtisans，并与其首席执行官科斯塔斯·宙马斯以及首席技术官斯蒂芬·尤恩有着广泛的合作。

谈及如何学习Flink，大沙认为，对于一些所在公司正在尝试用Flink的技术人，在实践中足矣获得成长。在实践中成长，能帮助技术人快速把握这门技术。

对于一些不从事Flink相关工作却对此很感兴趣的技术人，关注开源社区则非常关键，可以经常浏览开发者邮件列表，看大家的讨论，review社区代码，从社区中获取进步。

至于对Flink一知半解的等待入门的技术人，场主倒是推荐大沙翻译的新书《Flink基础教程》。

为何选择 Flink

流处理架构

Flink 的用途

对时间的处理

有状态的计算

批处理：一种特殊的流处理

从以上6个方面着手，由浅入深，不妨一看。

去年，出版社联系上大沙，“当初答应地很爽快，后来很后悔”，大沙笑道。因为太忙了，所以断断续续地翻译了一年，这个过程中也有一些同事帮忙review。

很辛苦，但是想到在国内Flink连本出版物都没有，很可惜，于是也都值得了。同时，大沙也期望更多的技术人可以来参与社区的翻译工作，或者能够合作写一些Flink的实践应用、代码分析等内容。

“出书是一个公益性的事情，对自己也是一个提高。”

从Flink到Blink2.0

3年研发：开发者和技术一起成长

Blink1.0主要是为了实时计算，在离线计算的应用性和性能方面还有些问题，而Blink2.0在这些方面做了大量优化，使得它的批流能力都有了很大的提升。

3年时间，大沙见证Blink从0到1的搭建，还在团队里带出了2位 Flink Committer。在他看来，团队工程师也发生了很大变化，“一开始作为用户，基于社区的代码跑起来，支持企业内部的业务，和开源社区融合后，则变成了设计者。”适应业务，融入社区，更高标准，高速迭代开发……

“我们现在的开发迭代速度比社区快很多了。”Blink在阿里大规模的数据集群上所做的稳定性和性能的优化，也在不断地反馈到Flink开源社区中。

此外，大沙还带着团队用了半年多的时间，打造了一套功能完备高性能的Blink SQL&Table API，还成功地将阿里的实时计算机器学习平台整体的迁移到这套 API 之上。

“在SQL这一层，（我们）意识到用户应该只需要描述语义，在平台上提交即可。”在这一阶段，大沙直言：遇到最大的挑战就是语义和标准。

每个开源社区都有些想法，也一直在讨论，过程中是有很多碰撞的。目前为止，从批流统一方面来说，解决了流计算上对early-firing数据的订正（流计算撤回）。同时也添加了若干重要的SQL功能，做了大量的性能优化。

“方向没有选错，解决了很多问题，用户体验也会不错。”

除了实时报表分析，Blink在阿里内部还被应用于实时机器学习的场景中。机器学习包括了训练模型，并利用模型做预测分析。早期的训练模型还不是实时的，往往需要一个较长的周期，如果把模型训练也做到实时，具有非常大的价值。

比如在阿里的大促活动中，就需要以更快的速度去更新模型的训练，拿到信息更好地做决策。

此外，除了传统的统计类计算、机器学习等场景，大沙还指出IOT是天然的实时计算场景，“（IOT 的）数据量很有可能很快超过批计算和流计算的数据总量之和”。

至于Blink的下一步规划，大沙透露，Blink正在准备贡献代码给开源社区，至于以什么方式贡献目前还在讨论中，相信不会太久。

大沙，我还有几个关于技术方面的问题！

Q&A环节中，很多技术人都踊跃提问

场主截取了部分问答如下：

对于实时数仓Flink未来的规划是什么？

数仓的建立是需要一定的存储，不仅仅是状态的存储，还需要对输入输出数据的管理，阿里也在做存储方面的开发。是否贡献给社区还要再讨论。

spark迁移到flink的主要难点在什么地方？

如果是Spark SQL的话，我们在考虑做一些工具，可以直接翻译成Flink SQL。如果是批计算并且使用的是Hive on Spark的话，我们也在计划Hive on Flink的支持。API上是兼容的。

至于迁移上的坑，批计算倒是还好，流计算上则需要注意语义，Spark是不支持retraction的，语义和功能上都是Flink的子集。

Spark和Flink流计算主要有什么区别？

可以看一下我在北京、上海Meetup上的PPT，有一页专门讲这个内容。

主要的区别一个是Flink比起Spark Streaming相比是超低延迟的。整体来看，Spark其实处于Flink早期的状态，还有一些语义等方面的问题，表达能力比较有限。Sparkcontinuous streaming只解决了native streaming的调度的问题，能够实现更低的延迟，但是支持的功能就更加有限了，还属于完全不能用于生产的测试阶段。