Flink成為字節跳動流處理唯一標準

  • 2019 年 10 月 4 日
  • 筆記

來源:字節跳動技術團隊

作者:張光輝·字節跳動

By 暴走大數據

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

關鍵詞：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 作業遷移

在遷移過程中，開始著手構建了一個流式管理平台。這個平台和其他管理平台是一樣的，主要提供作業配置管理，版本管理，監控，重啟，回滾，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 的舉辦者和參與者，感謝我的同事，因為以上的分享內容是我和同事一起完成的。

當時使用的 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 的舉辦者和參與者，感謝我的同事，因為以上的分享內容是我和同事一起完成的。

歡迎點贊+收藏

VirMach 便宜 VPS

QNews

QNews