本文由趣頭條實時平台負責人席建剛分享趣頭條實時平台的建設，整理者葉裡君。文章将從平台的架構、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 家知名企業資深技術專家齊聚國際會議中心，與全球開發者共同探讨大資料時代核心技術與開源生态。