Bigo 實時計算平臺的發展歷程特色與改進業務場景效率提升總結展望一、Bigo 實時計算平臺的發展歷程

今天主要跟大家分享 Bigo 實時計算平臺的建設歷程，我們在建設過程中解決的一些問題，以及所做的一些最佳化和改進。首先進入第一個部分，Bigo 實時計算平臺的發展歷程。

先簡單介紹一下 Bigo 的業務。它主要有三大 APP，分別是 Live， Likee 和 Imo。其中，Live 為全球使用者提供直播服務。Likee 是短影片的創作與分享的 App，跟快手和抖音都非常相似。Imo 是一個全球免費的通訊工具。這幾個主要的產品都是跟使用者相關的，所以我們的業務要圍繞著如何提高使用者的轉化率和留存率。而實時計算平臺作為基礎的平臺，主要是為以上業務服務的，Bigo 平臺的建設也要圍繞上述業務場景做一些端到端的解決方案。

Bigo 實時計算的發展歷程大概分為三個階段。

在 2018 年之前，實時作業還非常少，我們使用 Spark Streaming 來做一些實時的業務場景。從 18 年到 19 年，隨著 Flink 的興起，大家普遍認為 Flink 是最好的實時計算引擎，我們開始使用 Flink，離散發展。各個業務線自己搭一個 Flink 來簡單使用。從 2019 年開始，我們把所有使用 Flink 的業務統一到 Bigo 實時計算平臺上。透過兩年的建設，目前所有實時計算的場景都執行在 Bigo 平臺上。

如下圖所示，這是 Bigo 實時計算平臺的現狀。在 Data Source 端，我們的資料都是使用者的行為日誌，主要來自於 APP 和客戶端。還有一部分使用者的資訊存在 MySQL 中。

這些資訊都會經過訊息佇列，最終採集到我們的平臺裡。訊息佇列主要用的是 Kafka，現在也在逐漸的採用 Pulsar。而 MySQL 的日誌主要是透過 BDP 進入實時計算平臺。在實時計算平臺這塊，底層也是基於比較常用的 Hadoop 生態圈來做動態資源的管理。在上面的引擎層，已經統一到 Flink，我們在上面做一些自己的開發與最佳化。在這種一站式的開發、運維與監控的平臺上，我們內部做了一個 BigoFlow 的管理平臺。使用者可以在 BigoFlow 上開發、除錯和監控。最終在資料儲存上，我們也是對接了 Hive、ClickHouse、HBase 等等。

二、Bigo 實時計算平臺的特色與改進

接下來我們看一下 Bigo 計算平臺的特色，以及我們做的改進。作為一個發展中的公司，我們平臺建設的重點還是儘可能的讓業務人員易於使用。從而促進業務的發展，擴大規模。我們希望建設一個一站式的開發、運維、監控平臺。

首先，在 BigoFlow 上面，使用者可以非常方便的開發。我們在開發這一塊的特色與改進包括：

功能強大的 SQL 編輯器。圖形化拓撲調整、配置。一鍵多叢集部署。版本統一管理，儘可能收斂。

另外，在運維這一塊，我們也做了許多改進：

完善的 savepoint 管理機制。日誌自動收集到 ES，內建常 用錯誤排查規則。儲存了任務歷史，方便進行對比和問題追蹤。

最後是監控這一塊，我們的特色有：

監控自動新增，使用者基本無需手動配置。自動化分析資源使用，為使用者推薦合理資源配置。

我們元資料的儲存主要有三個地方。分別是 Kafka、Hive 和 ClickHouse。目前我們能夠把所有的儲存系統的元資料全面打通。這會極大的方便使用者，同時降低使用成本。

Kafka 的元資料打通之後，就可以一次匯入，無限使用，無需 DDL。Flink 與 Hive 也做到了完全打通，使用者在使用 Hive 表的時候，無需 DDL，直接使用即可。ClickHouse 也類似，可自動追蹤到 Kafka 的 topic。

其實，我們今天提供的不僅僅是一個平臺，還包括在通用場景提供了端到端的解決方案。在 ETL 場景，我們的解決方案包括：

通用打點完全自動化接入。使用者無需開發任何程式碼。資料進入 hive。自動更新 meta。

在監控這一塊，我們的特色有：

資料來源自動切換。監控規則不變。結果自動存入 prometheus。

第三個場景是 ABTest 場景，傳統的 ABTest 都是透過離線的方式，隔一天之後才能產出結果。那麼我們今天將 ABTest 轉為實時的方式去輸出，透過流批一體的方式大大提高了 ABTest 的效率。

對 Flink 的改進主要體現在這幾個方面：

第一，在 connector 層面，我們自定義了很多的 connector，對接了公司用到的所有系統。第二，在資料格式化層面，我們對 Json，Protobuf，Baina 三種格式做了非常完整的支援。使用者無需自己做解析，直接使用就可以。第三，公司所有的資料都直接落到 Hive 裡面，在 Hive 的使用上是領先於社群的。包括流式的讀取，EventTime 支援，維表分割槽過濾，Parquet 複雜型別支援，等等。第四，在 State 層面我們也做了一些最佳化。包括 SSD 支援，以及 RocksDB 最佳化。三、Bigo 典型的業務場景

傳統的打點入庫，都是透過 Kafka 到 Flume，然後進入到 Hive，最後到 ClickHouse。當然 ClickHouse 裡面大部分是從 Hive 導進去的，還有一部分是透過 Kafka 直接寫進去的。

這個鏈路是一個非常老的鏈路，它存在以下問題：

第一，不穩定，flume 一旦有異常，經常會出現資料丟失和重複。第二，擴充套件能力差。面對突然到來的流量高峰，很難去擴充套件。第三，業務邏輯不易調整。

所以我們在建設 Flink 之後，做了非常多的工作。把原先 Flume 到 Hive 的流程替換掉，今天所有的 ETL 都是透過 Kafka，再經過 Flink，所有的打點都會進入到 Hive 離線數倉，作為歷史的儲存，使資料不丟失。同時，因為很多作業需要實時的分析，我們在另外一個鏈路，從 Flink 直接進入 ClickHouse 實時數倉來分析。

在這個過程中，我們做了一些核心改造，分為三大塊。首先，在使用者接入這一塊，我們的改造包括：

儘可能簡單。通用打點全自動。元資訊打通，無需 DDL。

另外，在 Flink 自身這一塊，我們的改造有：

Parquet 寫最佳化。併發度調整。透過 SSD 盤，支援大狀態的作業。RocksDB 最佳化，更好控制記憶體。

最後，在資料 Sink 這一塊，我們做了非常多的定製化的開發，不僅支援 Hive，也對接了 ClickHouse。

四、Flink 為業務帶來的效率提升

下面主要介紹 ABTest 場景下，我們做的一些改造。比如說，資料全部落到 Hive 之後，就開始啟動離線的計算，可能經過無數個工作流之後，最終產出了一張大寬表。表上可能有很多個維度，記錄了分組實驗的結果。資料分析師拿到結果之後，去分析哪些實驗比較好。

雖然這個結構很簡單，但是流程太長，出結果晚，並且不易增加維度。主要問題其實在 Spark 這塊，這個作業有無數個工作流去執行，一個工作流要等到另外一個執行完才能去排程。而且離線資源沒有非常好的保證。我們之前最大的問題是 ABTest 上一天的結果要等到下一天的下午才能輸出，資料分析師經常反饋上午沒法幹活，只能下午快下班的時候才能開始分析。

所以我們就開始利用 Flink 實時計算能力去解決時效性的問題。不同於 Spark 任務要等上一個結果才能輸出，Flink 直接從 Kafka 消費。基本上可以在上午出結果。但是當時因為它最終產出的結果維度非常多，可能有幾百個維度，這個時候 State 就非常大，經常會遇到 OOM。

因此我們在第一步的改造過程中取了一個折中，沒有直接利用 Flink 在一個作業裡面把所有的維度 join 起來，而是把它拆分成了幾個作業。每個作業計算一部分維度，然後把這些結果先利用 HBase 做了一個 join，再把 join 的結果匯入到 ClickHouse 裡面。

在改造的過程中，我們發現了一個問題。可能作業需要經常的調整邏輯，調完後要去看結果對不對，那麼這需要 1 天的時間視窗。如果直接讀歷史資料，Kafka 就要儲存很久的資料，讀歷史資料的時候，要到磁碟上去讀，對 Kafka 的壓力就非常大。如果不讀歷史資料，因為只有零點才能觸發，那麼今天改了邏輯，要等到一天之後才能夠去看結果，會導致除錯迭代非常慢。

前面提到我們的所有資料在 Hive 裡面，當時還是 1.9 的版本，我們就支援了從 Hive 裡面流式的去讀取資料。因為這些資料都是用 EventTime 去觸發，我們在 Hive 上支援了用 EventTime 去觸發。為了流批統一，這裡沒有用 Spark，因為如果用 Spark 去做作業驗證，需要維護兩套邏輯。

我們在 Flink 上面用流批一體的方式去做離線的補資料，或者離線的作業驗證。而實時的這條用於日常作業的產生。

剛才說了這其實是一個折中的方案，因為對 HBase 有依賴，也沒有充分發揮 Flink 的能力。所以我們進行了第二輪的改造，徹底去除對 HBase 的依賴。

經過第二輪迭代之後，我們今天在 Flink 上已經能夠扛住大表的天級別的視窗交易。這個流批統一的方案已經上線了，我們直接透過 Flink 去計算完整個大寬表，在每天的視窗觸發之後，將結果直接寫到 ClickHouse 裡面，基本上凌晨就可以產出結果。

在整個過程中間，我們對 Flink 的最佳化包括：

State 支援 SSD 盤。流式讀取 Hive，支援 EventTime。Hive 維表 join，支援 partition 分割槽 load。完善的 ClickHouse Sinker。

最佳化之後，我們的小時級任務再也不延遲了，天級別完成時間由下午提早到上班前，大大加速了迭代效率。

五、總結與展望

總結一下實時計算在 Bigo 的現狀。首先，非常貼近業務。其次，跟公司裡用到的所有生態無縫對接，基本上讓使用者不需要做任何的開發。另外，實時數倉已現雛形。最後，我們的場景跟大廠相比還不夠豐富。一些比較典型的實時場景，由於業務需求沒有那麼高，很多業務還沒有真正的切換到實時場景上來。

我們的發展規劃有兩大塊。

第一塊是拓展更多的業務場景。包括實時機器學習，廣告，風控和實時報表。在這些領域，要更多的去推廣實時計算的概念，去跟業務對接好。另外一塊就是在 Flink 自身上面，我們內部有很多場景要做。比如說，支援大 Hive 維表 join，自動化資源配置，CGroup 隔離，等等。以上就是我們在未來要做的一些工作。