趣頭條基於 Flink 的實時平臺建設實踐

本文由趣頭條實時平臺負責人席建剛分享趣頭條實時平臺的建設，整理者葉里君。文章將從平臺的架構、Flink 現狀，Flink 應用以及將來計劃四部分分享。

一．平臺架構

1.Flink 應用時間線

首先是平臺的架構，2018 年 3 月以前基本都是基於 Storm 和 Spark Streaming 來作的。目前，基本已經把 Spark Streaming 和 Storm 淘汰了，主要都是 Flink SQL 來作的。起初還比較傳統，通常是接需求而後開發相似於 Flink SQL 的任務，基本是手工做坊操做模式。

後來 Flink SQL 的任務逐漸多了起來，就開始考慮往平臺化方向發展。大概在 2018 年 10 月份，咱們開始搭建實時平臺。當時設計實時平臺時就直接拋棄了 Spark Streaming 和 Storm，基礎理念設計的時候，主要以 Flink 場景來設計平臺。趣頭條實時平臺上線將近兩個月後，當時任務量並很少，因爲趣頭條基本都是 PHP 和 Golang 開發語言，而Flink更偏向於 Java 包括它 API 的提供，因此常常會接到用戶需求，如： Golang 能不能開發， PHP 能不能開發？

這個問題聽起來比較奇怪，可是對於不會用而且確實也想用的用戶，就須要想辦法解決這個問題。後來咱們作了一版相似於 Flink SQL 配置化開發，可讓用戶不用寫Flink 代碼，初衷是考慮到操做門檻若是相對高，那麼 Flink 在趣頭條的應用推動就不會這麼順暢。這也是 1.0 的配置開發誕生的背景。

在以上三件事情完成後，這個平臺基本就能提供給有開發能力的同窗開發一些 Flink 任務，同時相似於分析師、優秀的產品等沒有開發能力的的同窗也知道 Flink，他們更關心天天曲線的變化，能夠根據數據對一些產品作相應的策略調整，可以本身配比較簡單的 SQL 化任務。

在此以後，平臺任務逐漸增多，就開始作實時平臺的分佈式，包括多集羣。單集羣由於部分部門的任務要求較高，至少要達到三個九的標準，因此當時設計的時候就考慮到要支持 Flink 多集羣，後期好比說 A 集羣故障了，可讓用戶立馬切到B集羣發佈，兩集羣保持互通，底層 Checkpoint 是能夠實時同步的。

到了 19 年 6 月份，1.0 配置化開發的方案不是更抽象的，或者說不是 Flink 工程化的結構，後來也參考 Flink 的開源分支 Blink 並參考 Blink 本身實現了一版相似於 Blink 的方案，以後基本在配置化開發這一塊能夠推廣給代碼開發的同窗，由於他們可能對 Source 的源跟 Sink 源，包括一些數據中間環節的處理流程，比產品和分析師稍微瞭解的相對較多。

2.集羣及任務量

這個是目前集羣的規模，CPC 集羣差很少是 30 個節點，採用了 Flink on Yarn 的這種模式，這個是獨立的計費集羣，會有一些廣告商的點擊計費統計。當時這個定的時候，會是由兩個集羣去跑兩個任務，相似於 HA，它能夠在應用層面去作降級。好比說集羣掛了，它還能夠在另外公共集羣也會有任務。這樣的話就是說若是出問題，至少不會兩個集羣同時出問題，這種機率應該是比較小。

公共集羣如今是 200 多個節點，到今年 10 月左右，節點數可能會增至 400 到 500 個左右。目前 Kafka 也是有多副本集羣的，後續 Kafka 的數據流的轉換，也是經過 Flink 去實現可配置化的方式數據導流，好比 Kafka 是公司數據流的核心的鏈路之一，若是出問題的話會致使整個影響全部的依賴於上下游這種數據消費。目前 Kafka 那邊會有多副本集羣這種概念，那 Flink 在中間扮演的就是我能夠把這個數據流實時的同步到不一樣的集羣去作，相似於作容災的方案。

3.數據流架構

公共集羣 Flink 的任務目前是 200 多，而後 CPC 是十多個任務，下面爲數據流結構數據源基原本自於手機端 H5 還有服務端。而後中間會有一層 Log Server 這個是公司本身開發的，所有打到了 Log Server 以後，Log Server 會打到 Kafka，Kafka 也是多鏈路，有主副本集羣這種概念，中間環節在以前是有 storm 和 spark，目前 100% 都是 Flink。

接下來就是 Sink 出來之後的數據，目前用的種類仍是挺多的，包括 MySQL， Clickhouse，Cassandra， Elasticsearch 包括也會落部分 Hadoop 到 HDFS 還有 Prometheus。再日後主要是基於後續落的數據作了一些相似於企業級的應用，最上面 Dashboard 是大屏，通常是用來顯示數據流的大屏。第二個是基礎部門的性能指標。

最下面是數據入庫，下面是機器學習使用，目前 TensorFlow 基本是經過 Flink 拼接樣本清洗一些數據，而後落一些 TensorFlow 的數據結構出來，再經過 TensorFlow 作機器學習的訓練。

4.平臺架構

以上爲趣頭條的平臺架構，以前也是單節點，只能作集羣的任務發佈，目前改形成提供給用戶的 HA 架構，中間開發一層相似於發佈機器的概念，上面部了 Flink Gateway 即每集羣在一樣的 Gateway 上是能夠隨意切換的，好比說 Server 1，Server 2，Server 3，三個環境是同樣的，後續若是須要擴容，也只須要去擴 Flink Gateway，一樣的再去部署一套就好了。

再下面 Flink Gateway 能夠往 Hadoop 集羣上發，好比目前用的是 Hadoop Yarn，是兩個集羣，即 Gateway 能夠任意切換到這兩個集羣發佈任務。後續就是經過Filebeat將任務全部運行的記錄及日誌收集上來。收集完成以後也有基於Flink開發的通用日誌統計和分析的工具，將數據落到ELK（Elasticsearch + Logstash + Kibana，如下簡稱 ELK）裏，而後提供給用戶。好比，用戶任務上線以後可能會出現一些異常，包括統計等都會接到ELK裏面，由 ELK 提供可視化的界面，這個就是平臺的架構。

二．Flink 應用

1.應用場景

第二部分就是 Flink 目前在基分的應用，除了趣頭條，米讀、米讀極速版跟萌推目前這些產品包括數據流的統計，數據中間處理環節，基本已經換到 Flink 來了，支撐整個集團的產品。業務場景大概主要是計費、監控、倉庫，畫像包括算法、內容線六部分。

• 計費主要是算廣告商接入的計費成本，跟他們進行結算。每次廣告點擊完成後，每月可能會有相似於離線報表，目前若是須要切換成實時，基本只須要點擊，就會產生扣費環節，這個算是很是核心的任務。
• 監控有各類，好比說機器層面的，應用層面的。
• 倉庫目前基本是批量落數據，好比說五分鐘、十分鐘，相似於窗口的間隔時間去落數據
• 畫像即將用戶畫像的一些數據經過 Flink 清洗，完成以後會落到 HDFS 上，用來作訓練。
• 算法目前除了用戶畫像，還有推薦，目前的 APP 打開以後會給不一樣用戶推薦不一樣的內容。
• 內容線目前作的是風控，可能有一些用戶知道 APP 會去刷金幣，好比說打開某個內容以後，不看內容而多是在後臺跑一百多個程序刷金幣，目前經過 Flink 能夠作到實時風控，能實時識別出某臺設備到底是不是真正的用戶，若是不是，就會將其屏蔽掉。

2.用戶聲音

• Flink 能用 Python/Golang 開發嗎？
• Flink 好學嗎？
• 我就會 SQL 能夠用嗎？
• 有沒有更簡單的方式？

以上四個問題是目前接觸到的公司內部用戶在 Flink 應用時常常會提到的，包括最初去推實時平臺時，可能不少人都會問 Flink 怎麼用、可否用 Python 或者 Golang 進行開發，或者僅會 SQL 不會寫代碼也想用等。

Flink 究竟好很差用？給業務線培養 Flink 的開發人員所面臨狀況在於部分業務線確實知道 Flink，可是沒有 Java 的背景，語言上主要寫 Golang，或者每月須要對產品進行一些策略的調整，但若是沒有數據去看，基本就是摸黑的，沒法評估策略調完以後可能會給產品帶來什麼樣的影響。

3.解決方案

針對以上問題，咱們也拿出瞭解決方案。在初版的時候，用戶只須要寫 SQL，即會有相似於內存裏的寬表，Flink 把從 Kafka 消費過來的數據抽象成內存的一張表，用戶只須要打開以下界面根據本身的邏輯去寫自定義 SQL，就能夠提供給產品和分析師，包括其餘想用平臺的用戶。有了這個解決方案以後，其餘用戶就能夠經過簡單的方式來體驗到 Flink 帶來便捷。

SQL 配置化 1.0 版本中 SQL 是有限制的，測試顯示若是提供給用戶寫的 SQL 愈來愈多，Checkpoint 的壓力，與 distinct 的這種計算結果會帶來數據傾斜的這種壓力，致使任務可能會失敗，因此在設計 SQL 代碼量時有必定的限制，不會讓用戶無休止的加 SQL，基本目前限制是 10 個。在 1.0 版本上線以後，恰好 Blink 開源出來了，咱們知道 1.0 方案仍是不夠優雅(從工程化看)，又參考 Flink 和開源出來的 Blink 方案，升級到了第二版，能夠更大化的提供用戶自定義的方式，也能夠把數據源抽象出來，數據源就不只僅是 Kafka 了，很大程度上改善了原來 1.0 的版本。當全部的數據來了以後先到 Kafka，目前數據源能夠支持 HDFS、MySQL、MQ 等，只須要建立 Source 源的概念。下面是平臺較詳細的截圖，基本是輸入，輸出以及統計邏輯。

目前跟 Blink 基本一模一樣，也是參考了 Blink 的一些設計思路和方法。這個功能已經上線，基本有5、六十個任務已經在用了，用戶對當前的平臺仍是比較滿意的。不過更指望寫 SQL 基本就能完成統計指標，這也是實時平臺後續想要去作的（儘量的再去屏蔽一些資源設置好比：tm/slot 通常用戶不太懂）。

三．現狀

第三部分是想分享一下趣頭條實時平臺的現狀，目前 Flink 1.9 版本已經出來了，咱們在測 Flink 1.9 的新特性，Flink 對 Python 的支持是很是驚喜的，內部不少用戶仍是比較喜歡腳本式語言的，而 Python 的開發是寫腳本式語言，就能提交 Flink 任務，這是咱們當前測試內容的一部分。另外一部分是 Flink 模板簡化，上面提到的 2.0 模板，讓用戶寫一大堆的 SQL，仍是比較麻煩的，用戶仍是更傾向於統計邏輯的簡單 SQL。咱們最終的目標仍是想把 Flink 推廣到整個集團公司，讓更多的受衆參與進來享受 Flink 帶來的好處。

最後一塊是 Flink SQL 的 HDFS 落庫，目前這個功能開發完了，目標是將 Kafka 出來的數據作相似的實時倉庫，即數據能夠實時落到 HDFS 上，而上一個版本是經過 Flink 開發，基本是按時間窗口去落的還不是實時的。

四．將來計劃

首先，版本升級，趣頭條的實時平臺目前用的是 Flink 1.7，後續是想往 1.9 版本去切，Flink 1.9 版本提供的 Task Fault Tolerance 的容錯、Checkpoint 的容錯等很好的修復了 1.7 版本中存在的問題。

第二，實時倉庫，趣頭條當前用到的 Flink 按時間窗口落可能數據也不是實時的，後續想讓它作到相似於秒級數據流入，體大提高倉庫服務數據能力。

第三，平臺智能診斷，當前工做中更大一部分時間是在解答用戶問題，用戶在使用中出現的各類報錯沒法自行解決，須要平臺提供技術上的支持，這部分其實比較影響平臺規劃的目標方向的進度，所以後面想開發平臺智能診斷。常見的報錯和最佳實踐都概括下來集成到平臺中。出現問題時可以自動診斷識別推薦給用戶解決方案。

第四，Flink 彈性式資源計算，這是目前面臨的比較重要的問題。目前 300 多個任務，集羣的規模增加也比較迅猛，大約每週將近 20 臺機器的擴容速度，後續的資源利用率也是很是重要的。目前我瞭解 Flink 社區是沒有相似於這種彈性式資源計算，也期待社區能解決這類問題。好比：Flink 任務起來以後，可能業務方已經將流已經停掉了，若是用戶不去看這個任務，其實他仍是在跑。最終內存、資源仍是被佔着，沒有釋放。

最後是 Flink 機器學習實踐。目前機器學習平臺基本用的仍是批訓練，後續仍是想去作一些嘗試 Demo 方案，提供給機器學習團隊，爭取他們能夠後續往 Flink 方向切換。

 

 

 

 

原文連接

本文爲雲棲社區原創內容，未經容許不得轉載。