知乎的 Flink 數據集成平臺建設實踐

簡介： 本文由知乎技術平臺負責人孫曉光分享，主要介紹知乎 Flink 數據集成平臺建設實踐。內容以下： 1. 業務場景 ； 2. 歷史設計 ； 3. 全面轉向 Flink 後的設計 ； 4. 將來 Flink 應用場景的規劃。

本文由知乎技術平臺負責人孫曉光分享，主要介紹知乎 Flink 數據集成平臺建設實踐。內容以下：

業務場景
歷史設計
全面轉向 Flink 後的設計
將來 Flink 應用場景的規劃

1、業務場景

很高興和你們分享近期知乎以 Flink 爲基礎，重構上一代數據集成平臺過程當中的一些收穫。數據集成平臺做爲鏈接各類異構數據的紐帶，須要鏈接多種多樣的存儲系統。而不一樣的技術棧和不一樣的業務場景會對數據集成系統提出不一樣的設計要求。

咱們首先來看一下在知乎內部數據集成的業務場景。同許多互聯網公司類似，過去知乎的在線存儲系統主要以 MySQL 和 Redis 爲主，同時對於部分數據量級較大的業務也使用了 HBase。近年來隨着技術的演進，咱們開始了從 MySQL 向 TiDB 的遷移。與此相似，咱們也開始將 HBase 向基於 TiKV 技術棧研發的 Zetta 演進。在離線存儲方面絕大多數的場景則是以 Hive 表來支撐的。

從在線存儲到離線存儲，期間有着很是強的數據同步需求。除此之外也存在着大量的流式數據，好比消息系統中的數據，咱們也但願它可以同各類在線或離線存儲系統打通。過去知乎主要使用 Kafka 支撐流式數據，近期也開始引入 Pulsar。這兩套消息系統同存儲系統之間的數據交換存在着較強的需求。

在知乎的業務場景和當前發展狀態下，數據集成工做在技術和流程管理上都存在着一些挑戰。

首先從技術角度看，數據源多樣化會對數據集成系統的鏈接擴展能力提出較高的要求。並且下一代的存儲系統在給業務帶來更強能力的同時也釋放了業務的壓力，進而促使了數據量的加速膨脹。數據量級上的快速增加對數據集成平臺的吞吐和實時性都提出了更高的要求。固然做爲數據相關的基礎系統，數據準確性則是最基礎的要求，這塊咱們也必須把它作好。

另外從流程管理角度看，咱們須要理解並整合散落在不一樣業務團隊的數據，作好管理並確保數據訪問的安全，因此整個數據整合的流程是相對複雜的。雖然平臺化可以將複雜的流程自動化起來，但數據集成工做所固有的高成本並不能徹底以平臺化的方式消除。所以盡最大的可能提高流程的可複用性和可管理性也是數據集成系統須要持續應對的挑戰。

基於這兩個方向上的挑戰，咱們對數據集成平臺的設計目標進行了規劃。

從技術方向看，咱們須要支持知乎已經投入使用和未來要推廣使用的多種存儲系統，具有將這些系統中多樣化的數據進行集成的能力。此外咱們還須要在知足高吞吐，低調度時延的前提下保障數據集成的可靠性和準確性。

從流程方面看，能夠經過整合各類內部存儲系統的元數據以及調度系統，複用現有系統基礎設施的能力，達到簡化數據接入流程，下降用戶接入成本的目的。咱們還但願可以以平臺化的方式爲用戶提供自助知足數據需求的手段，從而提高數據集成工做的總體效率。

從提高任務可管理性的角度看，咱們還要維護好數據的血緣關係。讓業務更好的去度量數據產出之間的關係，更有效的評估數據產出的業務價值，避免低質量和重複性的數據集成工做。最後咱們須要對全部任務提供系統化的監控和報警能力來保障數據產出的穩定性。

2、歷史設計

在知乎的第一代數據集成平臺成型前，大量的任務散落在各個業務方本身維護的 crontab 或者自行搭建的各類調度系統中。在這樣的無管理狀態下，各項集成任務的可靠性和數據質量都很可貴到有效的保障。所以在這個階段咱們要最迫切解決的是管理上的問題，讓數據集成的流程可管理可監控。

所以，咱們整合了各類存儲系統的元數據系統，讓你們能夠在統一的地方看到公司全部的數據資產。而後在調度中心統一管理這些數據的同步任務，由調度中心負責任務的依賴管理。同時調度中心對任務的關鍵指標進行監控並提供異常告警能力。在這個階段咱們沿用了從前你們普遍使用的 Sqoop 來實現 MySQL 和 Hive 之間數據的同步。且在平臺建設後期，隨着流數據同步需求的出現，咱們又引入了 Flink 來同步 Kafka 數據到 HDFS。

在建設初代集成平臺時咱們作過一次技術選型的選擇，是繼續使用已經獲得普遍驗證的 Sqoop 仍是遷移到其它可選的技術方案。同 Sqoop 相比，阿里開源的 DataX 是這個領域一個很是有競爭力的對手。若是把這兩個產品進行橫向對比，能夠發現他們在不一樣的方面互相有對方所不具有的優點。

好比 Sqoop 在系統規模上具有 MapReduce 級別的擴展性和原生的 Hive 支持。但 Sqoop 又有數據源支持不豐富，缺少一些重要功能特性的缺點。

而 DataX 提供了很是豐富的數據源支持，內置了數據集成系統很是重要的限速能力，還有它的良好設計所帶來的易於定製和擴展的能力。但它也存在無集羣資源管理支持和欠缺 Hive Catalog 原生支持的缺陷。

在當時的狀態下這兩個產品相互比較起來沒有一款產品具備絕對的優點。因此咱們選擇了繼續使用 Sqoop，而維持使用 Sqoop 在驗證環節上也爲咱們節約了許多投入，因此第一代的數據集成平臺在很是短的時間內就完成了開發和驗證並完成上線。

隨着初代數據集成平臺的上線和成熟，它很好的支撐了公司的數據集成業務需求並得到了顯著的收益。到目前爲止平臺上一共有大約 4000 個任務，天天運行超過 6000 個任務實例，同步大約 82 億條共計 124TB 的數據。

在平臺的幫助下，數據接入流程獲得了極大的簡化，爲用戶提供了自助解決數據集成需求的能力。而且，平臺在關鍵的流程節點上可以輔以必要的規範約束和安全審查，在提高了管理水平的同時，總體的安全性和數據質量也獲得了顯著的提高。

藉助於 Yarn 和 K8s 的彈性能力，集成任務的規模擴展能力也有了很大的提高。固然，做爲解決從 0 到 1 問題的第一代系統，也必然會伴隨着一系列問題。好比：

Sqoop 的 MapReduce 模式所固有的高調度時延問題
業務數據分佈不均所致使的數據傾斜問題
社區不活躍致使部分 Issue 長期沒法獲得解決的問題
Sqoop 代碼設計不理想致使的可擴展性和可管理性弱的問題。

3、轉向 Flink

與 Sqoop 相對的，是用於支持 Kafka 消息到 HDFS 數據集成任務的 Flink，它以優秀的可靠性和靈活的可定製性得到了你們更多的信任。基於流式數據集成任務爲 Flink 創建的信心，咱們開始嘗試全面轉向 Flink 來建設下一代的數據集成平臺。

雖然 Flink 是本次平臺演進中的最佳候選，咱們仍是基於當時的狀況對市面上可選的技術方案再次進行了調研。此次咱們將 Apache NIFI 項目和 Flink 進行了多方面的比較，從功能角度看：

Apache NIFI 很是強大且徹底覆蓋了咱們當前的數據集成需求。可是偏偏由於它功能過於強大而且自成體系，因此也帶來了較高的整合門檻。並且，沒法利用現有 Yarn 和 K8s 資源池也會帶來額外的資源池建設和維護的成本。

相比之下， Flink 具備一個很是活躍和開放的社區，在立項時刻就已經具有了很是豐富的數據源支持，能夠預期在將來它的數據源覆蓋必定會更加全面。並且 Flink 做爲一個通用計算引擎有着強大易用的 API 設計，在這個基礎上進行二次開發很是容易，因此它在可擴展性方面的優點也很是突出。

最後基於咱們對批流一體目標的認同，將來在知乎完成大數據計算引擎技術棧的統一也是一個極具吸引力的目標。

基於這些考量，在本輪迭代中咱們選擇了全面使用 Flink 替代 Sqoop，基於 Flink 完整實現了以前 Sqoop 的功能並從新建設了全新的集成平臺。

以下圖所示，橙色部分是本輪迭代中發生了變化的部分。除了做爲主角出現的 Flink 以外，在本輪迭代的過程當中咱們還開發了 TiDB、Redis 和 Zetta 三種存儲系統的數據集成功能。在消息系統這邊則直接從社區得到了 Pulsar 的支持。在咱們開始開發工做的時候，Flink 已經演進到了比較成熟的階段，對 Hive 內建了原生的支持，整個遷移過程沒有遇到過多的技術困難，很是順暢。

Flink 的遷移爲咱們帶來了許多收益。

1. 首先從可維護性上看，相比 Sqoop 有了很是顯著的改善。以下圖所示，左邊是過去使用 Sqoop 時的任務定義，這裏是一大堆非結構化的容易出錯的原始命令。而 Flink 則只需使用 SQL 定義一個源表和一個目標表再配合寫入命令來定義任務。任務的可理解性、可調試性遠好於從前，變成最終用戶也可以理解的模式。不少問題再也不須要平臺開發者配合排查，用戶就可以自助的解決許多常見的任務異常。

1. 在性能角度方面，咱們也有針對性的作了許多優化。

2.1 調度策略

首先是調度策略上的優化，在第一代集成平臺中咱們只使用 Flink 同步流式數據，因此任務調度徹底使用 Per Job。如今平臺同時支持了 Session 和 Per Job 的混合調度模式，因而，對於從消息系統接入數據的流式任務會繼續使用 Per-Job 模式運行，而批同步的任務則採用 Session 模式複用集羣從而避免集羣啓動的耗時提高同步效率。

固然，在這樣的場景中使用 Session 集羣也存在着一系列的挑戰，好比工做負載隨着任務提交不停變化而帶來的資源需求變化問題。因此咱們建設了自動的擴縮容機制來幫助 Session 集羣應對變化的負載。除此之外，爲了簡化計費機制和隔離風險，咱們還爲不一樣的業務線建立了私有 Session 集羣用於服務對應業務線的數據集成任務。

2.2 數據庫

在關係數據庫方面，咱們採用了常見的 JDBC 方式對 MySQL 進行數據同步，但這種方式也會存在一些固有難以解決的問題。

好比因業務數據在主鍵維度上空間分佈不均致使的數據傾斜問題。

再好比爲了隔離在線離線工做負載所建設的專用同步從庫，所產生的資源浪費和管理成本。

而且因爲 MySQL 實例衆多規格不一，合理協調多個併發任務的實例和實例所在的主機，進行合理的速度控制也很是困難。

相比之下，考慮到正在全面將數據從 MySQL 遷移到 TiDB 這一趨勢。咱們開發了原生 TiDB 的 Flink connector 來充分利用 TiDB 架構上的優點。

首先 region 級別的負載均衡策略可以確保對於任何表結構和任何的數據分佈，同步任務都可以以 region 爲顆粒度進行拆分避免數據傾斜問題。

其次經過設定副本放置策略，能夠在離線數據中心對數據統一放置一個 Follower 副本。進而在保持原有目標副本數量不變，無需額外資源成本的狀況下，利用 Follower read 的能力隔離在線交易和數據抽取的負載。

最後咱們還引入了分佈式的數據提交方式提高了數據寫入的吞吐能力。

1. 最後是爲知乎內部普遍使用的 Redis 提供數據集成的能力。Flink 社區已經有一個 Redis connector，但它目前只具有寫入能力而且難以靈活定製寫入時所使用的 key。因此咱們基於自身需求從新開發了一個 Redis connector，同時支持以 Redis 做爲 Source 和 Sink。

一樣爲了不數據抽取過程影響在線交易，在數據讀取路徑上咱們採用了 Redis 原生的 master/slave 機制獲取並解析 RDB 文件抽取數據，得到了單實例約 150MB 每秒的數據抽取吞吐。並且得益於打通內部存儲系統的元數據，咱們不但可以支持分片模式 Redis 集羣的數據抽取，還能夠只選擇每一個分片的 slave 節點做爲數據抽取源頭，避免抽取對 master 節點產生壓力。

此次全面轉向 Flink 的演進，解決了不少上一代數據集成平臺的問題，得到了很是顯著的收益。

從吞吐角度看，以 Flink 替代 MR 模式將整個調度的時延從分鐘級下降到了 10 秒左右。而且在一樣的數據量和一樣的 Flink 資源量狀況下，TiDB 原生 connector 可以比 JDBC 提高 4 倍的吞吐。

從功能角度看，新平臺不但可以原生支持分庫分表的數據集成任務，還可以以業務無關的方式避免數據傾斜的問題。

在數據源支持能力上，咱們以很是低的成本得到了 TiDB、Zetta、Redis 和 Pulsar 的支持。並且，隨着 Flink 的生態愈來愈完善，將來必定會有更多的開箱即用的 connector 供咱們使用。

從成本上看，最後下線 MySQL 離線節點和統一使用 K8s 資源池所帶來的資源效率提高，在成本和管理角度看都使咱們得到了顯著的收益。

4、Flink 即將來

回過頭看，本次全面 Flink 化的演進投入產出比很是高，這也進一步加強了咱們對 「Flink 即將來」 的的信心。目前在知乎內部除了數據集成場景，Flink 在搜索 Query 的時效性分析、商業廣告點擊數據處理和關鍵業務指標的實時數倉上也都有所應用。

在將來咱們但願可以進一步擴展 Flink 在知乎的使用場景，建設更加全面的實時數倉、系統化的在線機器學習平臺。咱們更但願批流一體的落地，讓報表類和 ETL 類的大型批任務也可以在 Flink 平臺上落地。

基於知乎大數據系統建設的模式和整體資源投入的狀況，將來將技術棧向 Flink 收攏是一個很是適合知乎的選擇。做爲用戶咱們很是期待可以一同見證將來 Flink 批流一體目標的達成。同時做爲社區的成員，咱們也但願可以用本身的方式爲這一目標的達成貢獻一份力量。

原文連接本文爲阿里雲原創內容，未經容許不得轉載。