AI前線導讀：
本文將為大家展示字節跳動公司將 Jstorm 任務遷移到Apache Flink 上的整個過程以及后續計劃。你可以借此了解到字節跳動公司引入Apache Flink 的背景，Apache Flink 集群的構建過程，如何兼容以前的 Jstorm 作業以及基于Apache Flink 構建一個流式任務管理平臺，本文將一一為你揭開這些神秘的面紗。

注意，文末有福利～
更多干貨內容請關注微信公眾號“AI前線”（ID：ai-front）

本文主要內容包括：

• 引入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-\u0026gt;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 掉了，降低版本沖突的可能性。

測試作業

寫完作業之后，可以測試作業。可以支持本地測試，也可以提交到 stage 環境測試。

增加配置信息

測試完成后，需要在 dayu 平臺上注冊作業，添加一些配置信息。

指定代碼版本

將自己 git 上的代碼，打包，升級到最新版本，在 dayu 頁面上選擇版本信息，方便回滾。

提交作業

查看作業運行狀態

提交完作業后，用戶需要查看作業運行的狀態怎么樣，提供四種方式供用戶查看作業狀態

第一個是 Flink UI，也就是官方自帶的 UI，用戶可以去看。
第二個是 Dashboard，展示作業 task qps 和 latency 以及 task 之間的網絡 buffer，將這些重要信息匯總到一個頁面，追查問題時清晰明了。

第三個是錯誤日志，將作業的錯誤日志都收集在一起，寫入到 ES 上，方便用戶查看。

第四個是 Jobtrace 工具，就是把 Flink 框架層面產生的異常日志匹配出來，直接判斷故障，告知用戶處理方法。例如當作業 OOM 了，則告知用戶如何擴大內存。

五、近期規劃
最后跟大家分享一下近期規劃

• 用戶資源配置是否合理，一直是用戶比較頭疼的一件事，因此希望能夠根據該作業的歷史表現，告知用戶合理的資源配置信息。

• Flink 1.3 -\u0026gt; 1.5 版本升級

• 優化作業重啟速度，縮短用戶重啟作業數據流中斷時間。

• Flink SQL 平臺剛上線，需要投入一些精力去了解 SQL 工作機制。
  以上就是我本次分享的主要內容，感謝Flink的舉辦者和參與者，感謝我的同事，因為以上的分享內容是我和同事一起完成的。

福利

最近的一份市場調查報告顯示，Apache Flink 是2018年開源大數據生態中發展“最快”的引擎，和2017年相比增長了125% 。為了讓大家更為全面地了解Flink，阿里巴巴和InfoQ共同制作了一本電子干貨合集：《不僅僅是流計算：Apache Flink實踐》，融合了Apache Flink在國內各大頂級互聯網公司的大規模實踐，希望對大家有所幫助。

總結

以上是生活随笔為你收集整理的Flink如何取代JStorm，成为字节跳动流处理唯一标准？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。