本文由趣頭條實時平臺負責人席建剛分享趣頭條實時平臺的建設，整理者葉里君。文章將從平臺的架構、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 的一些設計思路和方法。這個功能已經上線，基本有五、六十個任務已經在用了，用戶對當前的平臺還是比較滿意的。不過更期望寫 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 方向切換。

11 月 28-30 日，趣頭條的王金海老師將出席于北京國家會議中心舉辦的 Flink Forward Asia 2019，并分享《趣頭條基于 Flink+ClickHouse 構建實時數據分析平臺》，大會倒計時 21 天，還沒報名的同學抓緊時間啦～

屆時，阿里、騰訊、美團、字節跳動、百度、英特爾、DellEMC、Lyft、Netflix 及 Flink 創始團隊等近 30 家知名企業資深技術專家齊聚國際會議中心，與全球開發者共同探討大數據時代核心技術與開源生態。

雙11福利來了！先來康康#怎么買云服務器最便宜# [并不簡單]參團購買指定配置云服務器僅86元/年，開團拉新享三重禮：1111紅包+瓜分百萬現金+31%返現，爆款必買清單，還有iPhone 11 Pro、衛衣、T恤等你來抽，馬上來試試手氣 ?https://www.aliyun.com/1111/2019/home?utm_content=g_1000083110

原文鏈接
本文為云棲社區原創內容，未經允許不得轉載。

總結

以上是生活随笔為你收集整理的趣头条基于 Flink 的实时平台建设实践的全部內容，希望文章能夠幫你解決所遇到的問題。

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