> **導語：** 複雜架構的危害是隱性且持續增長的，尤其在海量資料處理的業務場景下，導致系統吞吐量增長、各功能模組相互影響，且資料重複、維護困難。某遊戲公司就面臨這樣的困境，在尋求解決方案的過程中，攜手OceanBase 搭建了儲存與實時分析的一體化數倉架構，替換了ClickHouse，Hive。該公司大資料平臺負責人從實時數倉面臨的問題與挑戰談起，講述了他們從確定選型方向到最終實現選型落地的歷程，以及使用 OceanBase 的經驗，供大家參考。

## 業務背景：數倉架構複雜，重視資料分析、處理與運營

我們公司是一個遊戲公司，以前重研發，現在重運營。對於遊戲公司來說，資料分析是非常重要的一塊業務，因此，我們非常看重資料分析系統的能力。目前，我們主要使用數倉工具對使用者行為（下載、註冊、充值）和廣告營銷資料進行分析，還有其他遊戲資料的分析，比如使用者打怪升級的現狀、戰鬥的引數等，也會用到數倉。

和大多數公司一樣，我們的數倉是典型的 Lambda 架構，如圖1所示。我們透過資料來源獲取到資料後先進行預處理如資料質量控制、資料清洗等處理後，將資料放入 Kafka進行資料快取。後續的任務排程分成兩部分，一部分是透過Hive做離線處理，另一部分資料用ClickHouse 進行實時分析。處理後的資料供應用系統使用，比如BI系統、使用者系統、營銷系統、以及第三方系統如百度、騰訊、頭條、抖音等。

![Image](https://img.alicdn.com/imgextra/i1/O1CN01mKOOVR206uRaRRAIg_!!6000000006801-2-tps-902-422.png)

*圖1 數倉架構*

當前的數倉在獲取資料後會進行解析和資料質量的處理。當收集到質量不符合規定的（缺欄位、欄位的型別不對）資料都會進行告警和處理。遊戲行業資料處理比較特別的一點是會對資料進行歸因，簡單來說就是把資料收集流程進行詳細解析，以此來判斷該資料是透過哪個渠道哪個廣告位產生的，後續的廣告營銷策略也會依賴於資料歸因。另外，我們還有一套“資料打寬”流程，這是資料倉儲中最為常見的業務加工場景，可以將使用者的 IP 解析後顯示使用者的國家、省市、地區、資訊，可以解析使用者的手機型號，可以解析使用者的年齡和性別等，放入離線數倉和實時數倉中，為使用者畫像提供支撐。

## 業務挑戰：實時性、一致性、可維護性差，查詢慢

我們的數倉架構包括資料貼源層，資料詳細層、資料中間層、資料服務層、資料集市等，原始資料透過資料質量檢查後，分別寫入Hive 和 ClickHouse 中的ODS貼源層，嚴格來說kafka中有什麼資料，ODS層也有什麼資料，Kafka也屬於貼源層的範疇，資料透過任務排程系統，進行打寬如解析ip、解析年齡和加工後，存入資料詳細層DWD，資料在資料中間層DWM和資料服務層DWS經過一系列指標匯聚處理後，放入資料集市，我們是用PostgreSQL資料庫和Redis中來做的資料集市，其中任務排程系統是我們自研的，可以進行源數字典的管理和資料質量管理及任務排程，可以執行任務重跑、任務優先順序調整、資料質量告警等操作，是一個比較強大的排程系統。雖說這個架構是當前較為先進的架構，但在使用過程中也遇到了不少挑戰。

**挑戰1：實時性。** 很多公司的數倉策略都是T+1，此前我們在使用 Hive 數倉時對其進行了最佳化，達到了資料從產生到可見只需要30分鐘。就是說我們30分鐘就去load一遍資料，寫入Hive再insert overwrite 到當天的分割槽裡面（可減少資料的碎片）。在實時數倉上ClickHouse也達到了一分鐘可見。但有些場景需要在毫秒內看到結果，是 Hive 和ClickHouse無法達到的。

**挑戰2：一致性。** 相信用過 Lambda 架構的人都知道 ClickHouse和Hive 的資料經常“打架”，二者計算出來的資料不一致。我們允許資料重複，在計算上也做了重複資料的去重處理，但即使重複處理完，仍然有資料不一致的問題，導致ClickHouse 的資料只能用於實時資料的檢視，Hive 資料則會用於最終資料使用。

**挑戰3：可維護性。** ClickHouse實時數倉一套程式碼，Hive 離線數倉一套程式碼，一個架構兩套系統，維護起來比較困難。

**挑戰4：即席查詢。** Hive 離線數倉，需要幾分鐘甚至十幾分鍾才能看到查詢結果。ClickHouse實時數倉在幾秒鐘至幾分鐘就能展示查詢結果。即席查詢在大多數情況下一切正常，但在以下兩種極端情況下會遇到挑戰。

- 一種情況是使用者身份資訊邦聯查詢，當使用者在註冊過程中繫結了身份證，需要透過身份證回查使用者賬號時，是需要毫秒級的響應。而我們的使用者資訊是存在MySQL中，在資料量較小時，查詢達到毫秒級響應是沒問題的，但在數量上億或者數十億的查詢場景下，MySQL的響應就非常慢甚至不可用。

- 另一種情況是廣告渠道邦聯查分析，需透過訂單資料邦聯使用者資料再邦聯廣告商渠道資訊，以往檢視廣告投放效果需等待要半小時。而我們的需求是1秒內可見。

目前 Lambda 架構下的數倉不支援上述需求，這迫使我們探索新的數倉工具。

## 技術選型：OceanBase 查詢測試，效能提升286倍

我們調研了Hudi、Doris兩款數倉工具，Hudi從資料寫入到Join查詢，至少需要60秒；Doris 能實現10秒到60秒可見，而我們已經在用的ClickHouse查詢結果的可見時間為 66秒（見圖2），相比之下，如果選用Hudi或Doris與使用現有的ClickHouse並沒有明顯的數值提升，沒有從根本上解決業務的需求。

![Image](https://img.alicdn.com/imgextra/i3/O1CN015SJL0S1Rn2K47Bk5h_!!6000000002155-2-tps-894-570.png)

*圖2  ClickHouse查詢資料66秒可見*

在進行新工具調研的過程中，我們瞭解到 HTAP 資料庫 OceanBase，並使用 OceanBase 在使用者身份證號查詢使用者ID的場景下簡單測試了資料查詢速度。透過圖3可以看到，我們在對 OceanBase 未做分割槽最佳化只做索引最佳化的情況下，1.2 億 Join查詢 34億條資料，初次查詢用時0.23秒，資料預熱後 0.01秒出資料查詢結果，效能提升66/0.23=286倍。我們認為，這是一個很“嚇人”的效能提升。

![Image](https://img.alicdn.com/imgextra/i4/O1CN01DDOfXa1n3ACTC9unL_!!6000000005033-2-tps-790-526.png)

*圖3 OceanBase查詢資料結果毫秒可見*

因此，我們當即決定封裝 OceanBase 的能力去滿足業務需求，包括透過身份證號查詢使用者ID、透過使用者ID查詢廣告資訊、實時紅包推廣效果等。

## 生產部署：實時資料寫入最佳化，歷史資料匯入踩坑

在確定使用 OceanBase 後，下一步的計劃就是考慮如何把它用起來。首先，我們對歷史資料和實時資料進行區分。

- 歷史資料：我們用 DataX 將歷史資料匯出為 CSV 檔案後，再用 DataX 將 CSV 檔案匯入OceanBase。

- 實時資料：考慮到使用者需求是毫秒級響應，我們選用了 Flink SQL 抽取實時資料。經過測試，從資料產生到資料落到 OceanBase，1秒內完成。

對於歷史資料的匯入，由於前期對 OceanBase 不夠熟悉，在使用過程中，我們也走了一些彎路，很多問題透過在OceanBase 技術答疑群（釘釘群號：33254054）與技術專家交流得到了解決。在資料匯入過程中，透過 DataX 匯出 CSV 檔案時，配置檔案中最好用 2881 埠直連 OceanBase 資料庫，如果透過2883埠，也就是OBProxy 代理連線的話，由於OBProxy 的分發機制，可能將不同的命令分發到另外一臺機器上，如果另外一臺機器沒有部署 DataX並匯出檔案的話則會找不到檔案，所以我建議使用Datax的時候，連線2881是最保險的。

對於實時資料的寫入，值得一提的是，在寫 OceanBase 時，我們也考慮過 Spark。Spark 是透過微批的方式去寫，在微批寫時，實時性還是比 Flink 差了一些。最大的微批時間間隔為300毫秒的延遲。而 Flink 則可以實時寫入 OceanBase，因此，我們選擇透過 Flink SQL 的方式把資料寫到 OceanBase 中。

下面三張圖片是Flink 資料實時ETL 的載入轉化以及寫入OceanBase 的流程程式碼展示。其中，圖4是使用Flink-kafka抽取實時資料的過程；圖5為使用FlinkSQL轉換、加工整理實時資料的過程；圖6為使用FlinkSQL實時載入至目的地 OceanBase 的過程。

![Image](https://img.alicdn.com/imgextra/i3/O1CN01E56hyr1TFGLen0DEn_!!6000000002352-2-tps-804-506.png)

*圖4 使用Flink-kafka抽取實時資料*

![Image](https://img.alicdn.com/imgextra/i3/O1CN01L4h7L129AsPkNeTFy_!!6000000008028-2-tps-800-538.png)

*圖5 使用FlinkSQL轉換、加工整理實時資料*

![Image](https://img.alicdn.com/imgextra/i1/O1CN01B2CXZC1Sdhs0x4uNC_!!6000000002270-2-tps-798-558.png)

*圖6 使用FlinkSQL實時載入至OceanBase*

我也對這些程式碼進行部分抽取，將其做成指令碼成批次提交，在轉化成指令碼工具化後 Flink Source 資料來源可以支援從Kafka、MySQL、Oracle、OceanBase、MongoDB、PostgreSQL、Sqlserver等資料來源實時同步資料並加工後寫入OceanBase 中，資料形成了閉環，OceanBase 作為資料中臺核心/實時數倉的雛形初步完成。

以上程式碼我們已經部署到生產環境中，目前應用到兩個應用場景中：一是透過使用者身份證號查詢使用者ID，二是透過使用者 ID 查詢資料歸因等資訊，比如使用者透過哪個廣告渠道瞭解並註冊到我們的產品。目前，OceanBase 在業務系統中的位置如圖7所示。

![Image](https://img.alicdn.com/imgextra/i3/O1CN01yA4yey20tSQapc942_!!6000000006907-2-tps-904-440.png)

*圖7 使用OceanBase後的數倉架構*

## 總結與展望：一個系統支撐TP與AP場景，解決所有問題

隨著 OceanBase 在我們業務系統中的穩定落地，幫助我們解決了上文提到的四個固有問題。

**實時性：** 從Kafka到Flink再到 OceanBase，寫入與匯出的實時性沒有任何問題。例如，使用 Flink SQL抽取實時資料並寫入 OceanBase，能實時完成。對於flink-sql-connector-OceanBase-cdc工具，我希望它更好的支援歷史資料再加工高效效率，以及不重不漏高效的歷史資料、實時資料無縫對，我們期待 OceanBase 的CDC工具能夠迭代出更完美的版本。我們更期待社群開發出 OceanBase 專有的flink-connector，實現不重不漏高效的寫 OceanBase。做好flink-sql-connector-OceanBase-cdc讀工具和flink-connector寫工具，就可以不重不漏高效的進行數倉第二層，第三層的加工，將OceanBase的生態擴充套件到了大資料圈，順帶實現了大資料環境下的存算分離。

**一致性：** OceanBase 可以完美對接我們現有系統中的歷史資料和實時資料，實現資料不重、不漏、不丟。

**即席查詢：** 我們在對 OceanBase 未做分割槽最佳化只做索引最佳化的情況下，1.2 億 Join查詢 34億條資料，初次查詢用時0.23秒，資料預熱後 0.01秒出資料查詢結果，效能提升66/0.23=286倍。資料可以達到毫秒內可見。

**可維護性：** 以往我們需要維護ClickHouse和Hive這兩套程式碼，未來我們計劃將所有核心場景逐漸遷移至 OceanBase，簡化架構，只需維護一套程式碼即可實現TP和AP的雙重能力。

下一步，我們計劃在使用者系統、廣告系統、資料分析系統，以及營銷和渠道管理分析中推廣和使用OceanBase（見圖8），目前已經開始了程式碼開發與資料對接。我們的理想狀態是將所有的業務資料放到 OceanBase 中進行分析、儲存，實現資料閉環，一個系統解決所有問題。

![Image](https://img.alicdn.com/imgextra/i3/O1CN013KeT191uYwzv9JtMq_!!6000000006050-2-tps-920-396.png)

*圖8 將OceanBase應用至更多系統*

此次 OceanBase 落地實踐帶給我們很多驚喜，正所謂千里之行始於足下，我們要敢於嘗試，才能逐漸到達千里之外，感受更美麗的風景。最後，希望 OceanBase 能夠越做越好。

海量資料下查詢慢、資料不一致難題如何解？看某遊戲公司的技術實踐

相關文章