簡介：本文由 Bigo 計算平臺負責人徐帥分享，主要介紹 Bigo 實時計算平臺建設實踐的介紹

本文由 Bigo 計算平臺負責人徐帥分享，主要介紹 Bigo 實時計算平臺建設實踐的介紹。內容包括：

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 隔離，等等。以上就是我們在未來要做的一些工作。

原文鏈接：https://developer.aliyun.com/article/782104?

版權聲明：本文內容由阿里云實名注冊用戶自發貢獻，版權歸原作者所有，阿里云開發者社區不擁有其著作權，亦不承擔相應法律責任。具體規則請查看《阿里云開發者社區用戶服務協議》和《阿里云開發者社區知識產權保護指引》。如果您發現本社區中有涉嫌抄襲的內容，填寫侵權投訴表單進行舉報，一經查實，本社區將立刻刪除涉嫌侵權內容。

總結

以上是生活随笔為你收集整理的流批一体生产应用！Bigo 实时计算平台建设实践的全部內容，希望文章能夠幫你解決所遇到的問題。

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