Flink特刊_正式版

1 .

2 .

3 . 卷首语：Apache Flink 对我们意味着什么？ 卷首语：Apache Flink 对我们意味着什么？ 作者 徐川 最近 Qubole 的一份调查报告显示，Apache Flink 是 2018 年大数据和 Hadoop 生态系统中发 展最快的引擎，与 2017 年的类似调查相比，采用量增长了 125％。这表明 Flink 正在获得越来 越多人的认可。 之所以增长这么快，和 Flink 在设计上的先进性是分不开的。流计算一直是大数据计算引擎的一 个痛点，在 Apache Storm 出现以前，大家都是采用批处理的方式来计算，其中最典型的代表就 是 Apache Spark，它推出了 Spark Streaming 试图用快速的批处理及“微批处理”来模拟流计算， 这种尝试现在被证明限制太多，Spark 本身也在尝试连续执行模式（Continuous Processing），然 而进展较为缓慢。 Storm 本身也存在问题，一个是性能，无法支持高吞吐低延迟的场景，其次是功能，对于 Exactly Once 模式和窗口支持较弱，使用的场景有限。与此相比，Flink 已经克服了流处理方面大部分的 问题，包括更好的状态管理、利用分布式一致性快照实现的检查点容错机制，让 Flink 在流处理 方面的能力趋于完善。 然而， 就如本书标题所示，Flink 并不想将自己仅仅局限于流处理引擎，而是用流处理来模拟 批处理，以及支持交互式查询、机器学习等大部分数据处理场景。这已经进入了通用计算引擎 的领域，与 Spark 展开了正面竞争，而如果你阅读了本书的案例部分，你会发现 Flink 除了生态 和社区方面与老牌计算引擎相比尚有不如，其它部分几乎都能很好的支持。连在易用性方面， 阿里也给 Flink 贡献了 Flink SQL。各大公司对 Flink 的支持，为 Flink 的发展打下了坚实的根基。 从 MapReduce，到 Spark、Storm，再到 Flink，大数据计算技术已经经历了三代发展，我们正处 于第三代的前半段，相信计算技术的不断创新，会推动上层应用的革新和进化，亲自参与技术 的变革，这就是是今天我们大数据技术人的历史机遇。 I 

4 .卷首语：愿更多的开发者融入 Flink 社区 卷首语：愿更多的开发者融入 Apache Flink 社区 Apache Flink 是德国柏林工业大学的几个博士生和研究生 从学校开始做起来的项目，之前叫做 Stratosphere。他们在 2014 年开源了这个项目，起名为 Flink。 我从 2015 年开始 接触 Apache Flink，完成并见证了 Apache Flink 作为一款卓 越的流计算引擎在阿里集团的落地，连续多年帮助阿里平 稳的度过了一个又一个双十一大促。在刚刚过去的 2018 年 双十一，Flink 引擎完美的支撑了高达 17 亿每秒的流量洪 峰。 作者 王绍翾（花名：大沙） 阿里巴巴 资深技术专家 为了让大家更为全面的了解 Flink，我和 InfoQ 的徐川老师 一起合作制作了这本介绍 Apache Flink 的中文专刊。它融 合了 Apache Flink 在国内各大顶级互联网公司的大规模实践。在这本专刊里你可以了解到：Flink 如何为整个阿里集团平稳度过双十一立下汗马功劳？如何为满足滴滴极为复杂的业务需求提 供简单直观的 API 支持？如何在字节跳动逐步取代原有的 JStorm 引擎，成为公司内部流式数据 处理唯一标准？ Apache Flink 已经被业界公认是最好的流计算引擎。然而 Flink 其实并不是一个仅仅局限于做流 处理的引擎。Apache Flink 的定位是一套兼具流、批、机器学习等多种计算功能的大数据引擎。 在最近的一段时间，Flink 在批处理以及机器学习等诸多大数据场景都有长足的突破。一方面 Flink 的批计算在经过阿里的优化后有了数量级的提升。另一方面，Flink 社区在 tableAPI，Python， 以及 ML 等诸多领域都在逐步发力，持续提升用户做 Data science 和 AI 计算的体验。此外，Flink 也在逐步提升和其他开源软件融合的体验，包括 Hive，还有 Notebook（Zeppelin, Jupyter）等等。 由于准备时间的仓促，本次专刊并没有收录很多关于 Flink 在这些新场景的进展的介绍。我们后 续还会组织发布更多关于 Apache Flink 的系列专刊。 Apache Flink 自 2014 年开源至今也才 4 年，我们期待更多的企业和开发者们和我们一起参与到 Apache Flink 的社区和生态建设中来，共同把它打造成为全球最一流的开源大数据引擎。 II 

5 .目录 案例篇 阿里巴巴为什么选择 Apache Flink？ .................................................................. 1 Apache Flink 在滴滴出行的应用与实践 ............................................................ 11 字节跳动 Jstorm 到 Apache Flink 的迁移实践 ............................................... 20 Apache Flink 在美团的实践与应用 .................................................................... 32 Apache Flink 在唯品会的实践 ............................................................................. 47 携程基于 Apache Flink 的实时特征平台 ........................................................... 57 技术篇 一文了解 Apache Flink 核心技术 ....................................................................... 66 流计算框架 Flink 与 Storm 的性能对比 ............................................................. 73 Spark VS Flink – 下一代大数据计算引擎之争，谁主沉浮？ ...................... 95 5 分钟从零构建第一个 Apache Flink 应用 .................................................. 109 Apache Flink 零基础实战教程：如何计算实时热门商品 .......................... 114 Apache Flink SQL 概览 ..................................................................................... 124 Apache Flink 类型和序列化机制简介 ............................................................. 140 深度剖析阿里巴巴对 Apache Flink 的优化与改进 ....................................... 151 

6 .不仅仅是流计算：Apache Flink® 实践 阿里巴巴为什么选择 Apache Flink？ 作者 王峰 整理 韩非 本文主要整理自云栖大会阿里巴巴计算平台事业部资深技术专家王峰（花名：莫问）在云栖大 会‘开发者生态峰会’上发表的演讲。 1 

7 . 阿里巴巴为什么选择 Apache Flink？ 伴随着海量增长的数据，数字化时代的未来感扑面而至。不论是结绳记事的小数据时代，还是 我们正在经历的大数据时代，计算的边界正在被无限拓宽，而数据的价值，再也难以被计算。 时下，谈及大数据，不得不提到最热门的下一代大数据计算引擎 Apache Flink（以下简称 Flink）。 本文将结合 Flink 的前世今生，从业务角度出发，向大家娓娓道来：为什么阿里选择了 Flink？ 合抱之木，生于毫末 随着人工智能时代的降临，数据量的爆发，在典型的大数据的业务场景下数据业务最通用的做 法是：选用批处理的技术处理全量数据，采用流式计算处理实时增量数据。在绝大多数的业务 场景之下，用户的业务逻辑在批处理和流处理之中往往是相同的。但是，用户用于批处理和流 处理的两套计算引擎是不同的。因此，用户通常需要写两套代码。毫无疑问，这带来了一些额 外的负担和成本。阿里巴巴的商品数据处理就经常需要面对增量和全量两套不同的业务流程问 题，所以阿里就在想，我们能不能有一套统一的大数据引擎技术，用户只需要根据自己的业务 逻辑开发一套代码。这样在各种不同的场景下，不管是全量数据还是增量数据，亦或者实时处 理，一套方案即可全部支持，这就是阿里选择 Flink 的背景和初衷。 目前开源大数据计算引擎有很多选择，流计算如 Storm、Samza、Flink、Kafka Stream 等，批处 理如 Spark、Hive、Pig、Flink 等。而同时支持流处理和批处理的计算引擎，只有两种选择:一个 是 Apache Spark,一个是 Apache Flink。 从技术，生态等各方面的综合考虑，首先，Spark 的技术理念是基于批来模拟流的计算。而 Flink 则完全相反，它采用的是基于流计算来模拟批计算。 从技术发展方向看，用批来模拟流有一定的技术局限性，并且这个局限性可能很难突破。而 Flink 基于流来模拟批，在技术上有更好的扩展性。从长远来看，阿里决定用 Flink 做一个统一的、通 用的大数据引擎作为未来的选型。 2 

8 .不仅仅是流计算：Apache Flink® 实践 Flink 是一个低延迟、高吞吐、统一的大数据计算引擎。在阿里巴巴的生产环境中，Flink 的计算 平台可以实现毫秒级的延迟情况下，每秒钟处理上亿次的消息或者事件。同时 Flink 提供了一个 Exactly-once 的一致性语义。保证了数据的正确性。这样就使得 Flink 大数据引擎可以提供金融 级的数据处理能力。 Flink 在阿里的现状 基于 Apache Flink 在阿里巴巴搭建的平台于 2016 年正式上线，并从阿里巴巴的搜索和推荐这两 大场景开始实现。目前阿里巴巴所有的业务，包括阿里巴巴所有子公司都采用了基于 Flink 搭建 的实时计算平台。同时 Flink 计算平台运行在开源的 Hadoop 集群之上。采用 Hadoop 的 YARN 做 为资源管理调度，以 HDFS 作为数据存储。因此，Flink 可以和开源大数据软件 Hadoop 无缝对 接。 目前，这套基于 Flink 搭建的实时计算平台不仅服务于阿里巴巴集团内部，而且通过阿里云的云 产品 API 向整个开发者生态提供基于 Flink 的云产品支持。 Flink 在阿里巴巴的大规模应用，表现如何？ • 规模：一个系统是否成熟，规模是重要指标，Flink 最初上线阿里巴巴只有数百台服务器， 3 

9 . 阿里巴巴为什么选择 Apache Flink？ 目前规模已达上万台，此等规模在全球范围内也是屈指可数； • 状态数据：基于 Flink，内部积累起来的状态数据已经是 PB 级别规模； • Events:如今每天在 Flink 的计算平台上，处理的数据已经超过万亿条; • TPS:在峰值期间可以承担每秒超过 4.72 亿次的访问，最典型的应用场景是阿里巴巴双 11 大 屏； Flink 的发展之路 接下来从开源技术的角度，来谈一谈 Apache Flink 是如何诞生的，它是如何成长的？以及在成 长的这个关键的时间点阿里是如何进入的？并对它做出了那些贡献和支持？ Flink 诞生于欧洲的一个大数据研究项目 StratoSphere。该项目是柏林工业大学的一个研究性项 目。早期，Flink 是做 Batch 计算的，但是在 2014 年，StratoSphere 里面的核心成员孵化出 Flink， 同年将 Flink 捐赠 Apache，并在后来成为 Apache 的顶级大数据项目，同时 Flink 计算的主流方 向被定位为 Streaming,即用流式计算来做所有大数据的计算，这就是 Flink 技术诞生的背景。 2014 年 Flink 作为主攻流计算的大数据引擎开始在开源大数据行业内崭露头角。区别于 Storm、 Spark Streaming 以及其他流式计算引擎的是：它不仅是一个高吞吐、低延迟的计算引擎，同时 还提供很多高级的功能。比如它提供了有状态的计算，支持状态管理，支持强一致性的数据语 4 

10 .不仅仅是流计算：Apache Flink® 实践 义以及支持 Event Time,WaterMark 对消息乱序的处理。 Flink 核心概念以及基本理念 Flink 最区别于其他流计算引擎的，其实就是状态管理。 什么是状态？例如开发一套流计算的系统或者任务做数据处理，可能经常要对数据进行统计， 如 Sum、Count、Min、Max,这些值是需要存储的。因为要不断更新，这些值或者变量就可以理 解为一种状态。如果数据源是在读取 Kafka、RocketMQ，可能要记录读取到什么位置，并记录 Offset，这些 Offset 变量都是要计算的状态。 Flink 提供了内置的状态管理，可以把这些状态存储在 Flink 内部，而不需要把它存储在外部系 统。这样做的好处是第一降低了计算引擎对外部系统的依赖以及部署，使运维更加简单；第二， 对性能带来了极大的提升：如果通过外部去访问，如 Redis，HBase，它一定是通过网络及 RPC。 如果通过 Flink 内部去访问，它只通过自身的进程去访问这些变量。同时 Flink 会定期将这些状 态做 Checkpoint 持久化，把 Checkpoint 存储到一个分布式的持久化系统中，比如 HDFS。这样 的话，当 Flink 的任务出现任何故障时，它都会从最近的一次 Checkpoint 将整个流的状态进行 恢复，然后继续运行它的流处理。对用户没有任何数据上的影响。 Flink 是如何做到在 Checkpoint 恢复过程中没有任何数据的丢失和数据的冗余？来保证精准计 算的？ 这其中原因是 Flink 利用了一套非常经典的 Chandy-Lamport 算法，它的核心思想是把这个流计 算看成一个流式的拓扑，定期从这个拓扑的头部 Source 点开始插入特殊的 Barriers，从上游开 始不断的向下游广播这个 Barriers。每一个节点收到所有的 Barriers,会将 State 做一次 Snapshot， 当每个节点都做完 Snapshot 之后，整个拓扑就算完整的做完了一次 Checkpoint。接下来不管出 现任何故障，都会从最近的 Checkpoint 进行恢复。 5 

11 . 阿里巴巴为什么选择 Apache Flink？ Flink 利用这套经典的算法，保证了强一致性的语义。这也是 Flink 与其他无状态流计算引擎的 核心区别。 下面介绍 Flink 是如何解决乱序问题的。比如星球大战的播放顺序，如果按照上映的时间观看， 可能会发现故事在跳跃。 在流计算中，与这个例子是非常类似的。所有消息到来的时间，和它真正发生在源头，在线系 统 Log 当中的时间是不一致的。在流处理当中，希望是按消息真正发生在源头的顺序进行处理， 不希望是真正到达程序里的时间来处理。Flink 提供了 Event Time 和 WaterMark 的一些先进技术 来解决乱序的问题。使得用户可以有序的处理这个消息。这是 Flink 一个很重要的特点。 接下来要介绍的是 Flink 启动时的核心理念和核心概念，这是 Flink 发展的第一个阶段；第二个 6 

12 .不仅仅是流计算：Apache Flink® 实践 阶段时间是 2015 年和 2017 年，这个阶段也是 Flink 发展以及阿里巴巴介入的时间。故事源于 2015 年年中，我们在搜索事业部的一次调研。当时阿里有自己的批处理技术和流计算技术，有 自研的，也有开源的。但是，为了思考下一代大数据引擎的方向以及未来趋势，我们做了很多 新技术的调研。 结合大量调研结果，我们最后得出的结论是：解决通用大数据计算需求，批流融合的计算引擎， 才是大数据技术的发展方向，并且最终我们选择了 Flink。 但 2015 年的 Flink 还不够成熟，不管是规模还是稳定性尚未经历实践。最后我们决定在阿里内 部建立一个 Flink 分支，对 Flink 做大量的修改和完善，让其适应阿里巴巴这种超大规模的业务 场景。在这个过程当中，我们团队不仅对 Flink 在性能和稳定性上做出了很多改进和优化，同时 在核心架构和功能上也进行了大量创新和改进，并将其贡献给社区，例如：Flink 新的分布式架 构，增量 Checkpoint 机制,基于 Credit-based 的网络流控机制和 Streaming SQL 等。 阿里巴巴对 Flink 社区的贡献 我们举两个设计案例，第一个是阿里巴巴重构了 Flink 的分布式架构，将 Flink 的 Job 调度和资 源管理做了一个清晰的分层和解耦。这样做的首要好处是 Flink 可以原生的跑在各种不同的开 源资源管理器上。经过这套分布式架构的改进，Flink 可以原生地跑在 Hadoop Yarn 和 Kubernetes 这两个最常见的资源管理系统之上。同时将 Flink 的任务调度从集中式调度改为了分布式调度， 这样 Flink 就可以支持更大规模的集群，以及得到更好的资源隔离。 7 

13 . 阿里巴巴为什么选择 Apache Flink？ 另一个是实现了增量的 Checkpoint 机制，因为 Flink 提供了有状态的计算和定期的 Checkpoint 机制，如果内部的数据越来越多，不停地做 Checkpoint, Checkpoint 会越来越大，最后可能导致 做不出来。提供了增量的 Checkpoint 后，Flink 会自动地发现哪些数据是增量变化，哪些数据是 被修改了。同时只将这些修改的数据进行持久化。这样 Checkpoint 不会随着时间的运行而越来 越难做，整个系统的性能会非常地平稳，这也是我们贡献给社区的一个很重大的特性。 经过 2015 年到 2017 年对 Flink Streaming 的能力完善，Flink 社区也逐渐成熟起来。Flink 也成为 在 Streaming 领域最主流的计算引擎。因为 Flink 最早期想做一个流批统一的大数据引擎，2018 年已经启动这项工作，为了实现这个目标，阿里巴巴提出了新的统一 API 架构，统一 SQL 解决 方案，同时流计算的各种功能得到完善后，我们认为批计算也需要各种各样的完善。无论在任 务调度层，还是在数据 Shuffle 层，在容错性，易用性上，都需要完善很多工作。 篇幅原因，下面主要和大家分享两点： • 统一 API Stack • 统一 SQL 方案 先来看下目前 Flink API Stack 的一个现状，调研过 Flink 或者使用过 Flink 的开发者应该知道。 Flink 有 2 套基础的 API，一套是 DataStream，一套是 DataSet。DataStream API 是针对流式处理 的用户提供，DataSet API 是针对批处理用户提供，但是这两套 API 的执行路径是完全不一样的， 8 

14 .不仅仅是流计算：Apache Flink® 实践 甚至需要生成不同的 Task 去执行。所以这跟得到统一的 API 是有冲突的，而且这个也是不完善 的，不是最终的解法。在 Runtime 之上首先是要有一个批流统一融合的基础 API 层，我们希望 可以统一 API 层。 因此，我们在新架构中将采用一个 DAG（有限无环图）API，作为一个批流统一的 API 层。对于 这个有限无环图，批计算和流计算不需要泾渭分明的表达出来。只需要让开发者在不同的节点， 不同的边上定义不同的属性，来规划数据是流属性还是批属性。整个拓扑是可以融合批流统一 的语义表达，整个计算无需区分是流计算还是批计算，只需要表达自己的需求。有了这套 API 后，Flink 的 API Stack 将得到统一。 除了统一的基础 API 层和统一的 API Stack 外，同样在上层统一 SQL 的解决方案。流和批的 SQL， 可以认为流计算有数据源，批计算也有数据源，我们可以将这两种源都模拟成数据表。可以认 为流数据的数据源是一张不断更新的数据表，对于批处理的数据源可以认为是一张相对静止的 表，没有更新的数据表。整个数据处理可以当做 SQL 的一个 Query，最终产生的结果也可以模 拟成一个结果表。 对于流计算而言，它的结果表是一张不断更新的结果表。对于批处理而言，它的结果表是相当 于一次更新完成的结果表。从整个 SQL 语义上表达，流和批是可以统一的。此外，不管是流式 SQL，还是批处理 SQL，都可以用同一个 Query 来表达复用。这样以来流批都可以用同一个 Query 优化或者解析。甚至很多流和批的算子都是可以复用的。 9 

15 . 阿里巴巴为什么选择 Apache Flink？ Flink 的未来方向 首先，阿里巴巴还是要立足于 Flink 的本质，去做一个全能的统一大数据计算引擎。将它在生态 和场景上进行落地。目前 Flink 已经是一个主流的流计算引擎，很多互联网公司已经达成了共 识：Flink 是大数据的未来，是最好的流计算引擎。下一步很重要的工作是让 Flink 在批计算上 有所突破。在更多的场景下落地，成为一种主流的批计算引擎。然后进一步在流和批之间进行 无缝的切换，流和批的界限越来越模糊。用 Flink,在一个计算中，既可以有流计算，又可以有批 计算。 第二个方向就是 Flink 的生态上有更多语言的支持，不仅仅是 Java，Scala 语言，甚至是机器学 习下用的 Python，Go 语言。未来我们希望能用更多丰富的语言来开发 Flink 计算的任务，来描 述计算逻辑，并和更多的生态进行对接。 最后不得不说 AI，因为现在很多大数据计算的需求和数据量都是在支持很火爆的 AI 场景，所以 在 Flink 流批生态完善的基础上，将继续往上走，完善上层 Flink 的 Machine Learning 算法库， 同时 Flink 往上层也会向成熟的机器学习，深度学习去集成。比如可以做 Tensorflow On Flink, 让 大数据的 ETL 数据处理和机器学习的 Feature 计算和特征计算，训练的计算等进行集成，让开 发者能够同时享受到多种生态给大家带来的好处。 10 

16 .不仅仅是流计算：Apache Flink® 实践 Apache Flink 在滴滴出行 的应用与实践 作者 余海林 整理 赵明远 本文来自于余海林在 2018 年 8 月 11 日 Flink China 社区线下 Meetup·北京站的分享。余海林 目前在滴滴出行负责实时流计算相关工作，研发主要是集中在 Apache Flink 上。之前任职于阿 里巴巴，主要负责 TCP/IP 协议栈以及手淘的无线网络优化。 本文主要内容主要包括以下几个方面： 1、 Apache Flink 在滴滴的背景 2、 Apache Flink 在滴滴的平台化 3、 Apache Flink 在滴滴的生产实践 4、 StreamSQL 5、 展望规划 Apache Flink 在滴滴 在滴滴，所有的数据基本上可以分为四个大块： 1、 轨迹数据：轨迹数据和订单数据往往是业务方特别关心的。同时因为每一个用户在打车以 后，都必须要实时的看到自己的轨迹，所以这些数据有强烈的实时需求。 2、 交易数据：滴滴的交易数据， 11 

17 . Apache Flink 在滴滴出行的应用与实践 3、 埋点数据：滴滴各个业务方的埋点数据，包括终端以及后端的所有业务数据， 4、 日志数据：整个的日志系统都有一些特别强烈的实时需求。 1、 在滴滴应用发展的过程中，有一些对延迟性要求特别高的应用场景。比如说滴滴的轨迹数 据，以及滴滴网关的日志监控，都对我们的引擎提出了非常大的挑战，要求我们在一个秒级 或者说在一个很短的时间内能够给业务方一个反馈。在调研以及对比各个流计算引擎以后， 由于 Apache Flink（以下简称 Flink）是一个纯流式的处理引擎。发现 Flink 比较满足我们的 业务场景。 2、 在滴滴的内部，一个业务形态是事业部特别多，然后有很多业务需要进行实时处理，很多业 务部门选择自己搭建 storm 或者 Spark Streaming 小机群。但是一个个小机群会带来一定的 问题，例如：由于业务方不会有人专门去做维护流式计算引擎这些相关工作，所以每一次业 务方出问题以后，实时计算团队做的最多事情就是进行重启集群，减少这样的一些成本也 是对我们一个很大的挑战， 3、 实时计算团队需要能够掌握住流计算引擎，也就是说我们必须要有一个统一的入口，来供 大家更方便或者是更快捷更稳定的让业务方使用流计算服务。所以综上考虑，我们最终选 择了 Flink 来作为流计算引擎的一个统一入口。 12 

18 .不仅仅是流计算：Apache Flink® 实践 Flink 在滴滴的平台化 平台化的优点 • 平台化能给带来什么样的好处呢？很明显就是业务方不再需要自己去维护自己的小机群， 也不需要过多的去关心流计算引擎相关的一些问题，业务方只需要专注于业务即可，这显 然能够降低业务方的成本。 • 然后各个业务方如果自己去维护一个小集群的话，就相当于是说每个业务方这里有十台机 器，另外一个业务可能也有个七八台机器，然后每个集群上的机器可能就跑了很少的几个 应用，业务方的机器的利用率根本上不去，这对公司内部和机器资源来说都是浪费。 • 第三个就是如果每个业务方自己维护一个小集群的话，无法也没人给业务方任何的稳定性 保障，如果将流计算进行平台化以后，平台会给每个业务方承诺一个稳定性保障，并且会有 一个稳定性的一个保障体系。总之流计算平台化的优点可以归结为以下三点： 1、 降低流计算使用门槛 2、 统一流计算平台，降低机器运维成本，提升机器利用率 3、 稳定性保障 平台化整体架构 13 

19 . Apache Flink 在滴滴出行的应用与实践 通过看上面这一张图，很明显滴滴平台化可以分为以下几个部分： • 第一个是上游的数据源，在滴滴内部，数据源用的比较多的差不多有两类，第一类是 Kafka， Kafka 作为滴滴的一个大型的日志系统，因此 Kafka 用的会比较多，然后还有 DDMQ（滴滴 内部自研的一个消息队列），这两类中件间在数据流输入方面用的比较多。 • 然后对于中间这一块，是滴滴流计算平台的核心部分，应用管控、StreamSQL、WebIDE、诊 断系统都是围绕着这个核心来做的。在滴滴内部现在主要维护了两个引擎，一个是 Flink， 还有一个是 Spark Streaming，滴滴流计算平台上的这两个引擎，用户都是能够非常方便的使 用到的。 • 再往下，用户提交上来的流计算应用都是由平台去做应用管理的，无论是 Flink 还是 Spark Streaming 应用都是以 On Yarn 模式运行的，流计算平台使用 Yarn 来管理计算资源和集群。 对于需要持久化的一些依赖，在底层平台是存储在 HDFS 上的。 • 最后是流计算平台的下游，在下游当然也包括上游的一些中间件，比如 Kafka 和 DDMQ，当 然在流计算的过程中，不可避免地要使用到 HBase 或者 MySQL，KV 数据库等下游存储。综 上所述这就是滴滴的一个整体平台化的架构。 引擎改进 对于引擎我们主要做了一下这些优化： • 平台化我们第一个做的工作就是将整个任务提交以及任务管控的各个方面都进行服务化了， 既然要流计算平台化，服务化是肯定要做的。 • 第二是在流计算平台化的过程中，为了能够更好的去限制每一个应用，更好的管理应用的 资源，流计算平台限制了每个 Yarn-session 上只能提交一个 Job，如果在一个 Yarn-session 上 提交多个 Job，平台会进行提示或报错，保证 Job 提交不上去。 • 然后是应用在使用的过程中无法避免的会去做一些升级的操作，比如说一个 Flink Application 在今天使用的时候，很可能没有预估到明天流量会涨很多，这就导致应用在启动的过程中 申请到的资源不够，用户可能要重启去修改代码，修改算子的并行度等。但是重启总是会带 来一定的业务延迟，因此流计算平台提供了支持动态扩容的新特性。Flink Application 在重 启的时候，以前已经在使用的资源不会被释放，而是会被重新利用，平台会根据新的资源使 用情况来进行动态的缩扩。 • 最后一个是在使用官方 Flink 版本的过程中，碰到比较多的问题，例如在 Zookeeper 这一层 面就碰到了不少的问题，平台内部修复了很多围绕 Zookeeper 相关的一些问题。例如 Zookeeper 抖动会导致获取不到 CheckPoint 的 ID，在官方的版本里面会存留一些 bug，平台 内部已经进行修复了。 14 

20 .不仅仅是流计算：Apache Flink® 实践 流计算任务开发 • 流计算平台化很大的一个目标，就是让用户开发更简单，能够更加便捷的去使用平台，因此 流计算平台提供了多元化的开发方式。在早期主要有两种，第一种是用户在 WebIDE 上进行 开发，第二种就是用户在本地的 IDE 中进行开发。现在流计算平台提供了第三种方式： StreamSQL IDE，流计算平台希望通过 StreamSQL 大大的降低用户开发使用流计算的门槛。 Flink 任务监控 • 对于流计算平台，用户非常关心任务每时每刻的运行情况，并且用户需要非常实时的进行 查看和确认，既然是流式任务，自然对实时要求比较高，因此用户特别关心应用的延迟有多 少。所以流计算平台提供了一个完善的监控大盘，让用户来可以实时的看到他们所关心的 每一个指标，当然用户还可以去自定义更个性化的指标。在下面的图中，分别给出了延迟， 和吞吐量（就是应用最大能够消费多大的一个数据量，极限是多少）的实时数据。同时对用 户来说，不可能实时的去盯着监控大盘，查看这个任务到底有没有出问题，因此流计算平台 也提供了针对各个指标的报警服务，平台会根据适当的策略进行实时告警。 15 

21 . Apache Flink 在滴滴出行的应用与实践 任务诊断体系 • 虽然流计算平台提供了监控报警的服务，但是用户看到报警数据以后，有可能没法及时有 效的去判断自己的实时计算作业到底发生了什么，出现了什么问题。因此流计算平台还提 供了任务诊断的服务，流计算平台会把用户任务的一些日志，包括流计算引擎里面的日志 进行实时的采集，然后实时的接入到 ES 里面，这样用户就可以实时的查到指定应用的日志 了。然后对于监控大盘里面看到的监控数据，流计算平台还会在 Druid 中保存一段时间。然 后流计算平台修复了 Watermark 没法正常显示等 Flink UI 上面的问题。这样可以让用户能够 更好地去查看监控，以及对问题进行诊断。 Flink 在滴滴的生产实践 生产实践 滴滴的流计算业务在滴滴内部来讲，对于用户认可的业务场景来说，简单的归纳一下，主要是 以下四种： • 实时 ETL • 实时数据报表 16 

22 .不仅仅是流计算：Apache Flink® 实践 • 实时业务监控。 • 然后还有一个就是 CEP 在线业务。 业务场景——实时网管监控 背景 • 相信很多公司都会有一个业务网关，从网关上面可以看到的各个业务线，网关上面会对每 一个业务线去做一些像业务分发这样的逻辑，如果业务线非常庞大，例如滴滴就有很多业 务线。 • 如果某一个业务在某一时刻出现了故障，我们怎么能够快速的发现，同时怎么快速的定位 到问题。例如网关后面的每一个业务都会有相关的调用关系，一个 Service A 有可能会依赖 于 Service B 或者是 Service C，然后如果一个服务出现故障以后，依赖这个服务的其他服务 也有可能会出问题。 • 但是从应用最上层来看，某个业务曲线出现了下跌，或者是说曲线毛刺很高，这是不符合预 期，是异常的。对于这样的一些问题，对内部系统来说，如果一个个模块去排查，是很难排 查的，相当于说需要将链路上面的每一个调用关系都一个一个的进行排查，这个过程是相 当复杂的。 • 因此滴滴内部做了一套实时的日志监控系统，能够实时的按业务线进行监控。每一个业务 都会细化到每一个子业务，实时的去反映一个系统的服务到底是好还是坏。为了能够支持 这样的一些业务场景，我们进行了适当的抽象，把所有的网络日志全部采集到 Kafka 的一个 topic 里面，Topic 里面的日志能够覆盖到滴滴 90%的业务，然后我们会按照业务和服务去做 一些 Filter，Group By 以及一定范围内的 Window 聚合等计算服务。 架构 在前面是介绍了我们这个系统的背景，然后现在来看看滴滴这个系统的架构设计。最前面是滴 滴的数据采集服务，然后日志数据会被统一收集到 Kafka 中，在中间这一块，主要由 Flink Streaming 来进行处理，这里面是一个 Pipline，例如在这个 Pipline 里面会进行一系列操作：数 据展开，数据展开以后，会根据具体的规则进行实时匹配，同时因为规则会动态更新，所以匹 配的过程中是需要考虑的。对于规则的动态更新，在滴滴是通过配置流来实现的。配置流更新 以后，会广播到下游的算子中去，下游的算子接收到规则更新以后，会对主数据流进行相应的 变更。数据处理完以后，会把数据落到后端的一些系统里面去。比如 ES，数据进入 ES 以后，会 有各种各样的使用方式，比如说实时的进行展示，基于这些数据进行判断是否需要进行告警。 从整个链路上面来讲，整个实时网关日志架构还是非常清晰的。 17 

23 . Apache Flink 在滴滴出行的应用与实践 StreamSQL 滴滴内部的 StreamSQL 正在开发中，以后会作为滴滴内部流计算主要的使用方式，滴滴内部的 StreamSQL 的核心功能如下： • 第一个就是支持 DDL。滴滴内部使用的数据比较多，格式也比较多，所以滴滴 StreamSQL 的 DDL 具有支持多格式以及多数据源的特点。 • 第二个就是支持 DML，对于 DML 在滴滴，只有一种即：INSERT INTO TABLE，就是插入流 数据到某一张表，这个表的一定是一张 Sink 表，并且只能插入到要输出的一个下游。 • 然后是一些常用的、核心的一些功能点。比如 Group Agg、Window Agg，Join。Join 的场景 主要有两种：一种是双流上面 no-window join 以及流和维度表的 Join，同时也支持 UDF、 UDTF、UDAF 等用户自定义函数。 在这里简单的介绍一下滴滴定义数据源的一种方式，比如说现在要从 Kafka 中加载数据，我们 的元数据具有各种各样的格式，比如说是 JSON 的，需要用户去指定所定义的数据流的 Schema， 同时定义 Schema 的时候，必须要指定数据类型。然后在滴滴用的比较多的一个业务场景是分 流 SQL，也就是说一条数据可能会往多个地方写，例如既要写 Hbase 又要写 Kafka 这样的一些 需求。Flink 官方的 Stream SQL 是不支持这么去做的，原因可能是因为 SQL 的一些限制导致的， 但是滴滴的 Stream SQL 支持分流这一新特性。同时 Stream Join 也是我们正在着力推进的一个 18 

24 .不仅仅是流计算：Apache Flink® 实践 功能点，双流 noWindow 的 join，在滴滴也是准备支持的，也是滴滴正在不断研发的一个新特 性。当然 noWindow 是滴滴给出的一个复杂概念，真正的数据当然还是有一定的状态，Window 里面的数据还是会有一定的过期时间的，只是说滴滴正在尝试天级别的一个过期时间。在用户 设置以后，会在指定的一个时间，比如说每天凌晨或者说固定的一个时间点，将一些过去的数 据一次性的清空掉。最后对于维度表，滴滴 Stream SQL Join 的永远是当前表，并且只支持当前 表，不支持和历史表进行 Join，也不支持数据的回撤。 展望规划 前面讲到的 StreamSQL，滴滴内部正在不断推进。下图是 Flink 在滴滴内部的一个大致的规划和 展望。 1、 我们希望 StreamSQL 以后会承载滴滴内部至少 90%的流计算任务，越来越多的任务都会慢 慢的往 StreamSQL 上面迁移，比如说增加的新任务，以及历史遗留的一些任务。 2、 第二个是关于 CEP，滴滴也会将其融入到 StreamSQL 的体系中，同时会不断的进行这方面性 能优化。 3、 第三点是关于业务场景的，在滴滴，监控和实时报表这样的一些业务场景会占比较多的一 个部分。以后滴滴会探索开发更多业务场景，让 Flink 不断成长。 4、 第四点是为了去应对流量突发带来的稳定性的一些问题，滴滴会在动态扩容上做更多的一 些事情，同时滴滴也正在尝试在算子级别进行资源的自动缩扩。 19 

25 . 字节跳动 Jstorm 到 Apache Flink 的迁移实践 字节跳动 Jstorm 到 Apache Flink 的迁移实践 作者 张光辉 整理 张刘毅 本文将为大家展示字节跳动公司将 Jstorm 任务迁移到 Apache Flink 上的整个过程以及后续计 划。你可以借此了解到字节跳动公司引入 Apache Flink 的背景，Apache Flink 集群的构建过程， 如何兼容以前的 Jstorm 作业以及基于 Apache Flink 构建一个流式任务管理平台，本文将一一 为你揭开这些神秘的面纱。 本文内容如下： • 引入 Apache Flink 的背景 • Apache Flink 集群的构建过程 • 构建流式管理平台 • 近期规划 一、以引入 Apache Flink 的背景 下面这幅图展示的是字节跳动公司的业务场景 20 

26 .不仅仅是流计算：Apache Flink® 实践 首先，应用层有广告，AB 测试，推送，数据仓库等业务；其次中间层针对 python 用户抽象出 来一个模板，用户只需要在模板里写自己的业务代码，结合一个 yaml 配置将 spout, bolt 组成 DAG 图；最后将其跑在 Jstorm 计算引擎上。 大概在 17 年 7 月份左右，当时 Jstorm 集群个数大概 20 左右，集群规模达到 5000 机器。 21 

27 . 字节跳动 Jstorm 到 Apache Flink 的迁移实践 当时使用 Jstorm 集群遇到了以下几个问题： • 第一个问题：单个 worker 没有内存限制，因此整个集群是没有内存隔离的。经常会出现单 个作业内存使用过高，将整台机器的内存占满。 • 第二个问题：业务团队之间没有 Quota 管理，平台做预算和审核是无头绪的。当时几乎大 部分业务方都跑在一个大集群上面，资源不足时，无法区分出来哪些作业优先级高，哪些作 业优先级低。 • 第三个问题：集群过多，运维工具平台化做得不太好，都是靠脚本来运维的。 • 第四个问题：业务方普遍使用 python，某些情况下性能有些差。其次由于平台针对 Java Jstorm 的一些 Debug 工具，SDK 较弱，故推广 Java Jstorm 作业较难。 针对上面的问题，有两个解决方案： （1）在 Jstorm 的基础上支持内存限制，业务 Quota 管理， 集群运维；（2）Flink on yarn，也能够解决内存限制，业务 Quota 管理，Yarn 队列运维。 最终选择方案（2）也是考虑到 Apache Flink （以下简称 Flink）除了解决上述问题之外，能将运 维工作交付给 yarn，节省人力；Flink 在 exactly once，time window，table/sql 等特性上支持更 好；一些公司，例如阿里，在 Flink 上已经有了生产环境的实践； Flink 可以兼容 Jstorm，因 此历史作业可以无缝迁移到新框架上，没有历史包袱，不需要维护两套系统。 22 

28 .不仅仅是流计算：Apache Flink® 实践 以上就是 Flink 的优势，于是我们就决定从 Jstorm 往 Flink 迁移。 二、Flink 集群的构建过程 23 

29 . 字节跳动 Jstorm 到 Apache Flink 的迁移实践 在迁移的过程中，第一件事情是要先把 Flink 集群建立起来。一开始肯定要是追求稳定性，需 要 把 流 式 yarn 集 群 和 离 线 集 群 隔 离 开 ； 提 交作业，checkpoint 等依赖的 HDFS 也 独立 namespace；然后跟业务方梳理旧 Jstorm 作业，根据不同的业务团队，创建不同的 Yarn 队列； 同时也支持了一下最重要的作业跑在独立 label yarn 队列上，与其他业务物理隔离。 三、Jstorm->Flink 作业迁移 兼容 Jstorm 当时使用的 Flink 版本是 1.3.2，Flink 官方提供了一个 flink-storm module，用来支持将一个 Storm topology 转换为 Flink 作业，借鉴 flink-storm 实现了一个 flink-jstorm，完成将 Jstorm topology 转换为 Flink 作业。 仅仅做完这件事情还是不够的，因为有一批外围工具也需要修改。例如提交作业脚本；自动注 册消费延迟报警；自动注册作业状态的 Dashboard 等。 完成上面事情后，还有一件最重要的事情就是资源配置的转换。Jstorm 和 Flink 在资源配置管 理方面还是有些不同，Jstorm 没有 slot 的概念，Jstorm 没有 network buffer 等，因此为了方 便用户迁移作业，我们完成了一个资源配置脚本，自动根据用户的资源使用情况，以及 Topology 24