为什么阿里会选择 Flink 作为新一代流式计算引擎？

2017 年 10 月 4 日 机器学习研究会

2017 年 10 月 19 日，阿里巴巴的高级技术专家王绍翾（花名“大沙”）将为 QCon 上海的听众带来一场以大数据实时流计算与人工智能为主题的专题演讲，本专题将邀请来自腾讯、阿里、Facebook、Uber、Streamlio 的多位一线专家分析实时流计算和人工智能领域的最新的技术成果、应用和趋势。本文整理自 InfoQ 对王绍翾的采访问答，他与我们分享了关于实时流计算的看法，并对选择 Flink 的原因、Blink 对 Flink 所做的改进和优化、流数据 SQL 查询，以及阿里巴巴自研的基于 Blink 的在线机器学习平台 Porsche 等问题进行了解答。

更多精彩文章请添加微信“AI 前线”（ID：ai-front）

随着大数据技术的不断发展和成熟，无论是传统企业还是互联网公司都已经不再满足于离线批处理，实时流处理的需求和重要性日益增长。

近年来业界一直在探索实时流计算引擎和 API，比如这几年火爆的 Spark Streaming、Kafka Streaming、Beam 和 Flink。阿里巴巴自 2015 年开始改进 Flink，并创建了内部分支 Blink，目前服务于阿里集团内部搜索、推荐、广告和蚂蚁等大量核心实时业务。其中 Blink SQL 和 Table API（java／Scala 版的类 SQL API）是一套基于 Blink 引擎打造的可以同时支持流处理和批处理的统一的 API。与此同时，阿里巴巴还以 Blink 和分布式存储系统 HBase 为核心，设计并实现了一个面向算法人员、支持可视化自助开发运维的在线机器学习平台 Porsche。

作为 Blink 研发团队的负责人之一，同时也是本次 QCon 上海 2017“大数据实时流计算与人工智能”专题的出品人，王绍翾与我们分享了他关于实时流计算的看法，并对选择 Flink 的原因、Blink 对 Flink 所做的改进和优化、流数据 SQL 查询，以及阿里巴巴自研的基于 Blink 的在线机器学习平台 Porsche 等问题进行了解答。

InfoQ：为什么说如今企业对实时流计算的需求已经从 nice to have 变成 must have？

大沙： 今天新经济体的崛起主要依托于两个核心技术：大数据计算和人工智能。无论是传统的大数据统计还是新兴的人工智能，实时计算的能力都显得十分重要。如何获取数据、处理数据并从数据中挖掘有价值的信息，是各个新经济体都努力在解决的问题，所以实时计算一直都是 nice to have。可惜早期的实时计算是非常昂贵的。

随着软硬件的飞速发展，现在构建一套能够支撑大规模、低延迟的实时计算处理引擎变得相对容易很多（这点非常类似于沉睡多年的 deep learning 的崛起，没有新一代的软硬件计算的升级，deep learning 也只能停留在书本上）。

另外，越来越多的云计算平台开始支持实时计算产品，使得流计算更加触手可及，门槛大大减低，人人都可以花相对合理的价格买到流计算的能力。这样，实时计算就自然而然地变成了 must have。因为不使用高性能的实时计算就意味着在商业竞争中有被对手赶超甩开的可能。

InfoQ：您参加了今年 9 月在柏林召开的 Flink Forward 大会，能否跟我们分享一下流计算的最新进展？

大沙：我们从 2016 年开始先后参加了 3 次 Flink Forward 大会并做了分享。

9 月在柏林的这次会议一个比较明显的感受就是流计算的场景和用户增长十分快速。除了国内外的大公司，一些中小企业也开始尝试用流计算支撑和服务业务。应用场景上，除了常见的实时数据统计和实时监控分析等等之外，还涌现了大量的使用流计算做人工智能的技术和案例，让人十分振奋。

另外在这次大会上，dataArtisans 和阿里巴巴都公布将在近期更新升级各自的流计算云平台 (dataAtisans 的 DA，和阿里的 streamCompute)。有了这些实时流计算的云平台，可以预见到在未来的一年中，流计算应用和用户还会持续快速增长。

InfoQ：相比 Spark Stream、Kafka Stream、Storm 等，为什么阿里会选择 Flink 作为新一代流式计算引擎？前期经过了哪些调研和对比？

大沙：我们是 2015 年开始调研新一代流计算引擎的。我们当时的目标就是要设计一款低延迟、exactly once、流和批统一的，能够支撑足够大体量的复杂计算的引擎。Spark streaming 的本质还是一款基于 microbatch 计算的引擎。这种引擎一个天生的缺点就是每个 microbatch 的调度开销比较大，当我们要求越低的延迟时，额外的开销就越大。这就导致了 spark streaming 实际上不是特别适合于做秒级甚至亚秒级的计算。

Kafka streaming 是从一个日志系统做起来的，它的设计目标是足够轻量，足够简洁易用。这一点很难满足我们对大体量的复杂计算的需求。

Storm 是一个没有批处理能力的数据流处理器，除此之外 Storm 只提供了非常底层的 API，用户需要自己实现很多复杂的逻辑。另外，Storm 在当时不支持 exactly once。种种原因，Storm 也无法满足我们的需求。

最后，我们发现了 Flink，并且惊喜地发现它几乎完美满足了我们所有的需求：

a) 不同于 Spark，Flink 是一个真正意义上的流计算引擎，和 Storm 类似，Flink 是通过流水线数据传输实现低延迟的流处理；

b) Flink 使用了经典的 Chandy-Lamport 算法，能够在满足低延迟和低 failover 开销的基础之上，完美地解决 exactly once 的目标；

c）如果要用一套引擎来统一流处理和批处理，那就必须以流处理引擎为基础。Flink 还提供了 SQL／tableAPI 这两个 API，为批和流在 query 层的统一又铺平了道路。因此 Flink 是最合适的批和流统一的引擎；

d) 最后，Flink 在设计之初就非常在意性能相关的任务状态 state 和流控等关键技术的设计，这些都使得用 Flink 执行复杂的大规模任务时性能更胜一筹。

Info Q：Blink 和 Flink 的主要区别是什么？Blink 做了哪些优化和升级？

大沙：简单的说 Blink 就是阿里巴巴开发的基于开源 Flink 的 enterprise 版计算引擎。如前面所说，虽然 Flink 在理论模型和架构方面有很多创新，但是在工程实现上还有不少问题。这些问题大多都是我们在大规模使用中发现的。阿里的业务场景非常复杂，job 的体量都相当大，很多问题在一般的公司、一般的场景是很难接触到的。

从 2015 到 2016 年，我们 Blink 团队主要专注于解决 Blink 的 runtime 稳定性和 scalability 的问题：

a）优化了集群调度策略使得 Blink 能够更好更合理地利用集群资源；

b）优化了 checkpoint 机制，使得 Blink 能够很高效地处理拥有很大状态的 job；

c）优化了 failover 的策略，使得 job 在异常的时候能够更快恢复，从而对业务延迟造成更少的影响；

d）设计了异步算子，使得 Blink 能够在即使被读取外部数据阻塞的同时还能继续处理其他 event，从而获得整体非常高的吞吐率。

在拥有了稳定的 runtime 之后，我们开始专注于增强 Blink 的易用性。所以从 2016 年底到现在，我们大力开发 Blink 实时计算 SQL，通过 SQL 作为统一 API 服务于各种复杂业务。从规范 streaming SQL 的语义和标准，到实现 UDX、join、aggregation、window 等一系列 SQL 最重要的算子，我们几乎一手打造了完整的 streaming SQL，并且将这些工作推回了 Flink 社区。我们的工作也获得了 Flink 社区的认可。截止今天，Blink 团队先后拥有了 5 位 Flink committer。

InfoQ：流数据的 SQL 查询存在什么难点？Blink SQL/Table API 是一套基于 Blink 引擎打造的可以同时支持流处理和批处理的统一的 API，那么它是否已经可以很好地解决流式数据的 SQL 查询问题？是怎么做到的？

大沙：流计算 SQL 设计中最大的难点就是 Stream SQL 的语义和标准。这个事情在 Flink 和 Calcite 两个社区一直都在讨论研究中，直到最近我们基本达成了共识，那就是“世界上不存在 Stream SQL”。流和批的计算可以自然而然地在传统 SQL 这一层统一。

流计算所特有的 unbounded 特性其实本质只是何时观测抽样计算结果，这种属性可以作为一个 job 的 configure 来设置而无需去改变用户的 business query logic。为了能够使用传统 SQL 在流计算上执行，我们和 Flink 社区一起引入了 dynamic table 的概念。这里不详细展开，感兴趣的可以去看一下我们今年在 Flink 官方 blog 上发表的这方面的介绍（“Continuous Queries on Dynamic Tables”, by Fabian Hueske, Shaoxuan Wang, and Xiaowei Jiang）。也可以去听一下我们今年 4 月和 9 月在旧金山和柏林分别举办的 Flink forward 上的分享（在 youtube 上有视频）。

除了 dynamic table 之外，我们还提出并解决了流计算撤回（retraction）等其他重要的流计算场景拥有的概念。有了这些语义和功能，使用传统批处理 SQL 就能写出 Blink 流式计算的任务，这样就使得使用 Blink SQL 作为一个支持流处理和批处理的统一的 API 成为可能。

InfoQ：阿里内部哪些业务和产品用到了 Blink SQL？

大沙：我们基于 Blink SQL 打造了新一代阿里巴巴流计算平台 streamCompute。现在整个阿里集团包括搜索、推荐、广告等大部分核心流计算业务都是通过 streamCompute 平台来提供服务。我们近期还会通过阿里云开放我们的 streamCompute 平台，使更多的用户享受到 Blink 实时计算带来的便捷。

转自：AI前线

完整内容请点击“阅读原文”

登录查看更多