字节跳动Jstorm到Apache Flink的迁移实践_不仅仅是流计算：Apache Flink实践-QQ阅读女生仙侠网

书名：不仅仅是流计算：Apache Flink实践
作者名：InfoQ中文站
本章字数：2191字
更新时间：2020-06-26 06:08:27

字节跳动Jstorm到Apache Flink的迁移实践

作者张光辉

整理张刘毅

本文将为大家展示字节跳动公司将Jstorm任务迁移到Apache Flink上的整个过程以及后续计划。你可以借此了解到字节跳动公司引入Apache Flink的背景，Apache Flink集群的构建过程，如何兼容以前的Jstorm作业以及基于Apache Flink构建一个流式任务管理平台，本文将一一为你揭开这些神秘的面纱。

本文内容如下：

· 引入Apache Flink的背景

· Apache Flink集群的构建过程

· 构建流式管理平台

· 近期规划

一、以引入Apache Flink的背景

下面这幅图展示的是字节跳动公司的业务场景

首先，应用层有广告，AB测试，推送，数据仓库等业务；其次中间层针对python用户抽象出来一个模板，用户只需要在模板里写自己的业务代码，结合一个yaml配置将spout, bolt组成DAG图；最后将其跑在Jstorm计算引擎上。

大概在17年7月份左右，当时Jstorm集群个数大概20左右，集群规模达到5000机器。

当时使用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，因此历史作业可以无缝迁移到新框架上，没有历史包袱，不需要维护两套系统。

以上就是Flink的优势，于是我们就决定从Jstorm往Flink迁移。

二、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结构创建适合Flink作业的资源配置信息。

迁移Jstorm

上述工作全部准备完成之后，开始推动业务迁移，截止到当前，基本已经完成迁移。

在迁移的过程中我们也有一些其他优化，比如说Jstorm是能够支持task和work维度故障恢复，Flink这一块做得不是特别好，在现有Flink故障恢复的基础上，实现了single task和single tm维护故障恢复，这样就解决部分作业因为单task故障导致整个作业全部重启。

四、构建流式管理平台

在迁移过程中，开始着手构建了一个流式管理平台。这个平台和其他管理平台是一样的，主要提供作业配置管理，版本管理，监控，重启，回滚，Debug功能，操作记录等功能。

不同的是，我们在架构上分两层实现的，上面一层是面向用户端的产品，称作大禹（取自大禹治水）；下面一层是用来执行具体和Yarn, Flink交互的工作，称作TSS（Toutiao Streaming Service）。这样的好处是，未来有一些产品也可以构造自己面向用户端的产品，这样他直接对接TSS层就可以了。

下面给大家介绍一下，在字节跳动实现一个流式作业的流程。

创建流式作业

创建一个作业模板，使用maven提供的脚手架创建一个任务模板，重要内容是pom.xml文件。生成的作业模板pom.xml已经将Flink lib下面的Jar包都exclude掉了，降低版本冲突的可能性。