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

Posted 2021-04-13 AI前线

作者｜大沙

编辑｜Natalie

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 实时计算带来的便捷。

InfoQ：实时流式计算对机器学习平台的重要性体现在哪里？随着人工智能技术的发展，对实时流式计算的需求会发生哪些变化？

大沙：早期的机器学习都是通过离线大数据做全量计算提取特征、训练模型，然后再将这些特征和模型应用于系统之中从而影响算法结果。这种离线计算往往需要数小时甚至数天的时间，这就使得本来能够实时采集的数据最终需要经历一个很长的周期才能对算法结果产生影响。在某些极端情况下，这种离线计算产生的模型和特征都不能正确合理地体现算法效果。因此，如何通过实时计算引擎及时地同步数据的变化，从而快速地完成数据处理、特征提取、模型训练等一系列操作，就显得至关重要。

从我们多年在人工智能方面的经验来看，当一个新的人工智能技术在离线建模方面拿到比较好的结果之后，算法工程师们就会自然而然地开始思考如何把离线建模和实时计算使用结合起来，甚至是把离线建模变为实时建模。可惜早期的实时计算非常昂贵，随着软硬件飞速发展，慢慢地有一些公司拥有了一套能够支撑大规模、低延迟、高一致性保障的实时计算处理引擎之后，他们就开始利用机器学习、深度学习等人工智能技术从实时数据中高效地挖掘出有价值的信息。

随着人工智能技术的快速发展，新的人工智能算法和新的计算硬件层出不穷。因此除了要拥有实时计算的能力，计算学习平台往往还需要能够十分方便地集成各种算法和计算硬件。这些往往都是一个好的实时计算学习平台的核心竞争力。

InfoQ：您这次担任出品人的专题中也为大家带了阿里新一代实时机器学习平台 Porsche，而 Porsche 的实时计算部分主要就是基于 Blink，请介绍一下 Porsche 是如何基于 Blink 实现“在线机器学习”的？

大沙：阿里巴巴是一个非常重视以技术推动商业发展的公司。我们现在的核心电商业务的搜索和推荐后端都大量使用了人工智能技术。为了很好地支撑和接入业务，我们开发了一个面向用户的可视化算法平台，Porsche。

在这个平台上面，用户只需要简单地拖拽机器学习组件，按照需要连接他们，再做一些相应的配置，一个机器学习任务就能够完成。这样一方面使得使用 Blink 实时计算的门槛变得更低，另一方面又使得一个通用的算法组件能被更多的用户使用，大大降低了开发成本。

InfoQ：未来阿里在机器学习平台、深度学习平台和人工智能生态建设上还有哪些规划？是否会考虑向外界输出实时计算能力或推出开放的机器学习或深度学习平台？

大沙：由于人工智能算法或者模型往往和业务逻辑有着一定的联系，所以不是特别适合开放给外界。但是不排除在不远的将来，我们会将一些通用的人工智能算法通过我们的机器学习平台开放给更多的外部用户使用。

作者介绍

王绍翾，淘宝花名“大沙”，加州大学圣迭戈分校计算机工程的博士，2015 年加入阿里巴巴集团，目前就职于阿里巴巴计算平台事业部。加入阿里之前，曾在 Facebook 开发分布式图关系数据库 TAO。

加入阿里之后，王绍翾一直从事阿里新一代实时计算平台 Blink 的研发工作。早期负责搜索事业部的离线大数据处理，利用半年的时间带领团队将阿里淘宝天猫的搜索离线数据处理的计算全部迁移到了 Blink 计算平台之上。之后负责 Blink 计算平台的查询和优化。用了半年多的时间，打造了一套功能完备高性能的实时计算 Blink SQL&Table API，并成功的将阿里的实时计算机器学习平台整体的迁移到这套 API 之上。王绍翾是 Apache Flink 的 committer，除了自己，他在团队内部还培养出另外 2 位 Apache Flink committer。

今日荐文

爱奇艺视频场景下的自然语言处理应用

---

---