聯通實時計算平臺演進與實踐

摘要：本篇內容整理自聯通大資料技術專家穆純進在 Flink Forward Asia 2021 平臺建設專場的演講。主要內容包括：
實時計算平臺背景
實時計算平臺演進與實踐
基於 Flink 的叢集治理
未來規劃

FFA 2021 直播回放 & 演講 PDF 下載

一、實時計算平臺背景

首先了解一下實時計算平臺的背景。電信行業的業務系統非常複雜，所以它的資料來源也是非常多的，目前實時計算平臺接入了 30 多種資料來源，這 30 多種資料來源相對於總的資料種類來說是比較小的。即使這樣，我們的資料量也達到了萬億級別，每天有 600TB 的資料增量，而且我們接入的資料來源種類和大小還在持續增長。平臺的使用者來自於全國 31 個省份公司以及聯通集團的各個子公司，尤其是在節假日會有大量使用者去做規則的訂閱。使用者想要獲取資料，需要在平臺上進行訂閱，我們會將資料來源封裝成標準化的場景，目前我們有 26 種標準化場景，支撐了 5000 多個規則的訂閱。

訂閱場景有三大類。

使用者行為類的場景有 14 個，比如位置類的場景，是關於使用者進入某個區域後停留了多長時間，還有終端登網，是關於使用者連線了哪個網路，4G 還是 5G 網，以及漫遊、語音、產品訂購等各種場景；
使用者使用類的場景有 6 個，比如使用者使用了多少流量、賬戶餘額是多少、是否有欠費停機等；
使用者觸網類的場景大概有 10 個，比如業務的辦理、充值繳費，還有新入戶入網等。

對於實時計算平臺來說，實時性的要求是很高的。資料從產生到進入我們的系統，大概有 5~20 秒的延遲，經過系統正常處理之後大概有 3~10 秒的延遲，我們允許的最大延遲是 5 分鐘，所以必須做好實時計算平臺端到端的延遲的監控。

使用者定義的場景符合要求的資料最少要下發一次，這個是有嚴格要求的，不能漏發，而 Flink 很好地滿足了這個需求；資料的準確性要求需要達到 95%，平臺實時下發的資料會儲存一份到 HDFS 上，每天我們會抽取部分訂閱和離線資料，按照相同的規則進行資料生成以及資料質量比對，如果差異過大就需要找到原因並保證後續下發資料的質量。

本次分享更多的是 Flink 在電信行業的一次企業的深度實踐：如何使用 Flink 更好地支撐我們的需求。

通用的平臺無法支撐我們的特殊場景，比如以位置類的場景為例，我們會在地圖上畫多個電子圍欄，當使用者進入圍欄並在圍欄裡面停留一段時間，並且滿足使用者設定性別、年齡、職業、收入等使用者特徵，這樣的資料才進行下發。

我們的平臺可以認為是一個實時場景中臺，將資料進行實時的清洗處理，封裝成支援多個條件組合的複雜場景，集約化地提供標準實時能力的同時，更進一步靠近業務，提供給業務方簡單易用、門檻很低的接入方式。業務方通過呼叫標準化的介面，經過閘道器認證鑑權，才可以訂閱我們的場景。訂閱成功之後會將 Kafka 的一些連線資訊和資料的 Schema 返回給訂閱使用者，使用者訂閱的篩選條件跟資料流進行匹配，匹配成功之後會以 Kafka 的形式再進行資料下發。以上就是我們的實時計算平臺與下游系統互動的流程。

二、實時計算平臺演進與實踐

2020 年以前，我們的平臺是使用 Kafka + Spark Streaming 來實現的，而且是採購廠商的第三方的平臺，遇到了很多問題和瓶頸，難以滿足我們日常的需求。現在很多企業包括我們都正在進行數字化改革，系統的自研比例也越來越高，再加上需求的驅動，自研、可靈活定製、可控的系統是迫在眉睫了。所以 2020 年我們開始接觸了 Flink，並實現了基於 Flink 的實時計算平臺，這個過程中我們也體會到了開源的魅力，今後也會更多地參與到社群中來。

我們的既往平臺存在很多問題。首先是三方黑盒平臺，我們使用廠商的第三方平臺，過多依賴了外部系統；並且在大併發下外部系統的負載會非常高，不能靈活定製個性化的需求；Kafka 的負載也特別高，因為每一個規則的訂閱都會對應多個 topic，所以隨著規則的增加，topic 和分割槽的數量也會呈線性增長，導致延時比較高。每個訂閱場景會對應多個實時流，而每個實時流都會佔用記憶體和 CPU，場景過多會導致資源消耗增長以及資源負載過高；再就是支撐的體量小，支撐場景的訂閱數有限的，比如逢年過節使用者訂閱的數量劇增，經常需要緊急救火，無法滿足日益增長的需求；此外，監控粒度也不夠，無法靈活定製監控，無法進行端到端的監控，採用人肉的排查比較多。

基於上述問題，我們全面自研了基於 Flink 的實時計算平臺，根據每個場景的特點進行最優的定製，最大化資源的使用效率。同時我們利用 Flink 的狀態減少外部依賴，降低了程式的複雜度，提升程式的效能。通過靈活定製實現了資源的優化，相同體量的需求下大大節約了資源。同時為了保證系統的低延遲率，我們進行了端到端的監控，比如增加了資料的積壓、延遲、資料斷傳監控。

整個平臺的架構比較簡單，採用了 Flink on Yarn 的執行方式，外部只依賴 HBase，資料是以 Kafka 接入並由 Kafka 下發。

Flink 的叢集是獨立搭建的，它獨享了 550 臺伺服器，沒有和離線計算混用，因為它對穩定性要求比較高,需要日均處理 1.5 萬億資料，近 600TB 的資料增量。

我們對場景深度定製的主要原因是資料量大，同一個場景的訂閱又非常多，而且每個訂閱的條件又是不一樣的。從 Kafka 讀取一條資料的時候，這條資料要匹配多個規則，匹配中後才會下發到規則對應的 topic 裡面。所以不管有多少訂閱，只從 Kafka 中讀取資料一次，這樣能夠降低對 Kafka 的消耗。

手機打電話或者上網都會連線到基站，相同基站的資料會按一定的時長視窗和固定訊息進行壓縮，比如三秒鐘一個視窗，或者訊息達到了 1000 再進行觸發，這樣下游接收到的訊息就會有量級的降低。然後是圍欄匹配，外部系統的壓力是基於基站規模的，而不是基於訊息數目。再就是充分利用了 Flink 的狀態，當人員進入和滯留的時候會存入狀態，用 RocksDB 狀態後端減少了外部依賴，簡化了系統的複雜度。此外，我們還實現了億級標籤的關聯不依賴外部系統。通過資料壓縮、圍欄匹配、進入駐留、標籤關聯後，我們才開始正式匹配規則。

使用者訂閱場景後，訂閱的規則會以 Flink CDC 的方式同步到實時計算平臺，這樣可以保證延遲比較低。由於人群的進入滯留會存入到狀態，基於 RocksDB 的狀態後端資料量比較大，我們會通過解析狀態的資料進行問題排查，比如使用者到底有沒有在圍欄之中。

我們自定義了 HASH 演算法，在不依賴於外部系統的情況下，實現了億級標籤的關聯。

在大併發下，如果每個使用者都要關聯外部系統獲取標籤的資訊，那麼外部系統的壓力會非常大，尤其是在我們聯通這麼大資料量的情況下，依賴於外部系統建設的成本也很高，這些標籤都是離線標籤，資料相對比較穩定，比如有日更的有月更的。所以我們對使用者使用自定義的雜湊演算法，比如有個手機號，按照雜湊演算法它被分配到 index 為 0 的 task_0 例項中，再通過離線計算將標籤檔案中的手機號也按照相同的雜湊演算法分配到編號為 0 的 0_tag 中。

task_0 例項在 open 方法中獲取自己的 index 編號，即 index=0，然後拼接出標籤檔名 0.tag，並將檔案載入到自己的記憶體中。Task_0 例項接收到手機號後就可以從本地記憶體獲取到此手機號的標籤資料，不會造成記憶體的冗餘浪費，提升了系統效能，減少了外部依賴。

有標籤更新的時候， open 方法也會自動載入新的標籤，並重新整理到自己的記憶體中。

上圖是我們做的端到端的時延監控。因為我們的業務對延遲要求比較高，所以我們進行了事件時間的打標，比如進出 Kafka 時間的打標，這裡的事件就是訊息。對於運算元的延遲監控，我們根據打標的時間和當前的時間計算出延遲，這裡並不是每條訊息來了之後都去計算，而是採用抽樣的方式。

對積壓斷傳也做了監控，是通過採集 Kafka offset 進行前後對比來判斷的，另外還有對資料延遲的監控，利用事件的時間和當前的時間來計算延遲，可以監控上游系統的資料延遲。

上圖是端到端延遲監控和反壓監控的圖表。可以看到端到端的延遲正常是在 2~6 秒之間，也符合我們的預期，因為定位的條件是比較複雜的。我們還對反壓進行了監控，通過監控運算元 input channel 的使用率來定位每個運算元產生的反壓，比如第二個圖出現了嚴重的反壓且持續了一段時間，這時候我們需要定位到具體的運算元，然後去排查原因，來保證系統的低延遲。

上圖是我們對 Kafka 叢集中的每個 topic 分割槽的 offset，以及對每個消費者消費到的位置進行採集來定位它的斷傳和積壓。

首先制定一個 source 來獲取 topic 列表和消費者組列表，再這些列表下發到下游，下游的運算元可以採用分散式的方式去採集 offset 值，也是利用了 Flink 的特性。最後寫入 Clickhouse 中進行分析。

Flink 日常監控主要包括以下幾類：

Flink 作業的監控、告警接入聯通統一告警天眼平臺；
作業的執行狀態、checkpoint 的異常耗時；
運算元的時延、反壓、流量、條數；
taskmanager CPU、記憶體的使用率，JVM GC 等指標的監控。

三、基於 Flink 的叢集治理

我們還基於 Flink 搭建了我們的叢集治理平臺。搭建這個平臺的背景是我們的總叢集節點達到了 1 萬多臺，單叢集最大有 900 個節點，總共 40 多個叢集，總資料量單副本達到了 100 個 PB，每天有 60 萬個作業執行，單個叢集的 NameNode 的檔案數最大達到了 1.5 億。

隨著公司業務的高速發展，資料的需求越來越複雜，所需要的算力也越來越大，叢集的規模也越來越大，承載的資料產品也越來越多，導致 Hadoop 叢集面臨很大的挑戰：

檔案數比較多對 nameNode 造成很大的壓力，影響儲存系統的穩定。
小檔案特別多，導致讀取同樣資料量的時候需要掃描更多檔案，導致更多 NameNode RPC。
空檔案多，需要掃描更多的檔案，導致更多的 RPC。
平均檔案比較小，從巨集觀上也體現出了小檔案數比較多的。
生產上會持續產生檔案，作業輸出的檔案要進行調優。
冷資料多，缺少清理的機制，浪費儲存資源。
資源負載高，而且擴容成本又太大，擴容了也無法支撐太長時間。
作業耗時長影響產品的交付。
作業消耗資源大，佔用太多的 CPU、核數和記憶體。
作業存在資料傾斜，導致執行時間非常長。

針對這些挑戰，我們搭建了基於 Flink 的叢集治理架構，通過採集資源佇列的資訊，解析 NameNode 的後設資料檔案 Fsimage，採集計算引擎的作業等資訊等，然後對叢集做 HDFS 畫像、作業畫像，資料血緣、冗餘計算畫像、RPC 畫像以及資源畫像。

資源畫像：我們會同時對多個叢集的多個資源佇列的情況比如它的 IO、 metric 等進行分鐘級的採集，可以實時檢視整個叢集和細分佇列的資源使用趨勢。

儲存畫像：我們以無侵入的方式對多叢集的分散式儲存進行全域性性的多維度的分析。比如檔案數到底分佈在哪裡，小檔案分佈在哪裡，空檔案分佈在哪裡。對於冷資料的分佈，我們對每個資料庫每張表的分割槽目錄也做了精細化的畫像。

作業畫像：對多叢集全產品線不同計算引擎的作業，我們進行實時採集，從時間維度、佇列維度以及作業提交來源等多個維度，從耗時耗資源，資料傾斜、大吞吐量、高 RPC 的作業等多方面進行洞察，找出有問題的作業，篩選出那些待優化的作業。

資料血緣：通過分析生產環境 10 萬級別的 SQL 語句，繪製出無侵入的、全域性的、高精準的資料血緣關係。並在任意週期內提供了資料表級/賬戶級的呼叫頻次、資料表的依賴關係、產線加工的流程變更、加工故障的影響範圍和垃圾表的洞察等功能。

此外我們還做了使用者操作審計和後設資料方面的一些畫像。

上圖是叢集治理儲存大屏。除了一些巨集觀指標比如總檔案數、空檔案數、空資料夾，還有冷目錄數、冷資料量和小檔案的佔比等。我們還對冷資料進行分析，比如哪些資料最後訪問在某個月的資料量有多大，由此可以看到冷資料的時間分佈；還有比如 10 兆以下、50 兆以下、100 兆以下的檔案分佈在哪些租戶上。除了這些指標，還可以精確定位到哪個庫、哪張表、哪個分割槽存在小檔案。

上圖是叢集治理的效果展示，可以看到資源負載達到 100% 的時長也明顯縮短，檔案數降低了 60% 以上，RPC 負載也大幅降低。每年會有千萬級別的成本節約，解決了長時間的資源緊張問題，降低了擴容的機器數。

四、未來規劃

目前我們還沒有一個完善的實時流管理平臺，且監控比較分散，研發通用的管理和監控平臺勢在必行。

面對日益增長的需求，深度定製化雖然節約了資源，提升了支撐的規模，但是它的開發效率並不理想。針對資料量不大的場景，我們也考慮了使用 Flink SQL 來搭建通用的平臺，以此來提升研發效率。

最後，我們還會繼續探索 Flink 在資料湖中的應用。