用Flink取代JStorm，今日頭條的遷移過程與後續計劃

作者 | 張光輝

整理 | 張劉毅

編輯 | Debra

本文將為大家展示位元組跳動公司將 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 掉了，降低版本衝突的可能性。

測試作業

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

增加配置信息

測試完成後，需要在 dayu 平台上註冊作業，添加一些配置信息。

指定代碼版本

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

提交作業

查看作業運行狀態

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

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

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

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

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

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

Flink 1.3 -> 1.5 版本升級

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

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

本文彩蛋

最近的一份市場調查報告顯示，Apache Flink 是 2018 年開源大數據生態中發展「最快」的引擎，和 2017 年相比增長了 125% 。為了讓大家更為全面地了解 Flink，阿里巴巴和 InfoQ 共同製作了一本電子乾貨合集：《不僅僅是流計算：Apache Flink 實踐》，融合了 Apache Flink 在國內各大頂級互聯網公司的大規模實踐，希望對大家有所幫助。你可以在公眾號對話框回復關鍵詞：Flink，獲取下載地址。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！