OPPO 數倉與數據湖融合架構升級的實踐與思考

作者 | 蔡芳芳

過去幾年，數據倉庫和數據湖方案在快速演進和彌補自身缺陷的同時，二者之間的邊界也逐漸淡化。雲原生的新一代數據架構不再遵循數據湖或數據倉庫的單一經典架構，而是在一定程度上結合二者的優勢重新構建。在雲廠商和開源技術方案的共同推動之下，2021 年我們將會看到更多 “湖倉一體” 的實際落地案例。InfoQ 希望通過選題的方式對數據湖和數倉融合架構在不同企業的落地情況、實踐過程、改進優化方案等內容進行呈現。本文，InfoQ 採訪了 OPPO 雲數架構部部長鮑永成，請他與我們分享 OPPO 引入數據湖和數倉融合架構的探索工作和實踐中的一些思考。

1 當我們談數據湖，談的是什麼？

InfoQ：數據湖和數倉融合架構是當下大數據領域非常重要的議題之一，不僅各大雲廠商先後提出了自己的技術方案，開源社區也有一些項目（包括 DeltaLake、Iceberg 和 Hudi）非常活躍。其實數據湖這個概念誕生至今有挺長時間了，在您看來，目前業內對數據湖的定義和重要性是否已經達成一致？雲廠商的產品和開源項目之間有什麼差異嗎？

**鮑永成：**回答這個問題之前，我們得明確倉與湖的主要區別。倉裏的數據，有明確的表、字段定義，表與表之間的關係清晰。湖裏的數據，樣式就多了，有結構化、半結構化（JSON、XML 等）、非結構化（圖片、視頻、音樂）。數據入倉，我們要預先定義好 schema。數據入湖，則沒有這樣的要求，只需要將原始數據寫入指定存儲即可（通常是對象存儲），當真正需要使用的時候，我們再設法定義 schema，進行分析應用。顯然，數據入湖比入倉要方便快捷。

回到我們的話題，雲廠商的數據湖產品，通常積極推廣他們的低成本雲存儲（S3、OSS 等），吸引用戶將數據上雲。一旦數據上雲，進而吸引用戶使用他們多年完善的大數據體系產品（計算引擎、依賴調度、質量管理、血緣管理、數據治理等），爲用戶提供數據開發、分析、應用的附加服務。其次，很多企業出於數據安全的考慮，並不願意將自己的數據上雲，一套兼容各類存儲的倉湖融合方案，是雲廠商對市場的迎合。

開源的幾個數據產品 Delta Lake、Apache Iceberg、Apache Hudi 更多可以理解爲一種 TableFormat，這種 TableFormat 可以靈活定製 Schema，對對象存儲友好，同時可以實時處理數據，支持 Update、Insert、Upsert 特性。企業應用好他們，可以助力自身構建批流一體、倉湖融合的大數據架構。

2 倉湖融合架構升級的三個階段

InfoQ：OPPO 是什麼時候決定要引入數據湖和數倉融合架構的？能否介紹下當時的整個背景情況？是希望解決什麼樣的問題或痛點？

**鮑永成：**OPPO 在 2020 年初引入數據湖的架構方案，這是建立在 OPPO 進軍 IoT 領域的大背景下。隨着公司不斷推出 IoT 產品，IoT 設備產生的數據源源不斷，設備的智能化服務需要我們對這些數據做更深層次的挖掘。海量的數據如何高效存儲、高效利用是大數據部門必須要解決的問題。數據湖方案可以幫助我們快速收集保存數據，有效支持我們做數據分析、市場預測，以及智能服務的算法訓練。

InfoQ：爲什麼選擇引入 Apache Iceberg？你們前期做了哪些技術選型和評估工作？

**鮑永成：**引入 Iceberg 構建我們的數據湖方案，主要出於兩點考慮。

InfoQ：能否詳細介紹一下 OPPO 整體的數據平臺架構或數據處理流水線？在引入 Iceberg 前後，有哪些變化和演進？

**鮑永成：**下圖是 OPPO 的大數據架構，我們目前主要在推進兩項工作。

**1、雲數融合：**OPPO 已經基於 K8s 構建了自己的雲平臺，主要數據存在對象存儲 OCS 上。大數據平臺依靠 Yarn 調度，HDFS 做存儲，後續二者將統一調度與存儲，統一運維，降低成本。雲數融合的一期重點，會通過我們自研的 ADLS 支持數據湖存儲。ADLS 的冷熱分層，全局緩存特性在數據湖落地的過程中，可以有效降低存儲成本，減輕存算分離後的性能影響。

2、流批一體、倉湖融合的架構升級

對於傳統的 Lambda 架構，流與批是單獨的兩條數據處理鏈路，維護成本高，且容易出現數據不一致的情況。新的 Kappa 架構使用 Kafka 作爲存儲，簡化了架構，但 Kafka 數據承載能力有限，且數據格式並不利於計算引擎分析。

我們在以下兩個方面，對傳統架構進行了改造。

1）針對公司原來的數據埋點鏈路，我們引入了 Iceberg，將實時數倉庫的 Kafka 替換成 IcebergFormat，通過 Spark/Presto 引擎做數據查詢，增加數據倉庫的實時性。

2）公司原有的數據庫入倉鏈路通過 Flinkx 完成數據同步， 無法支持 CDC。目前 Flink 已經原生支持 CDC 數據解析，binlog 通過 flink-cdc-connector 拉取可以自動轉化成 INSERT、DELETE、UPDATE_BEFORE、UPDATE_AFTER 消息，結合 Iceberg 支持的 Update、Delete 特性，可以高效準確地將數據庫同步到數倉，方便計算引擎進行分析。

OPPO 的一些數據，存儲在 Oracle，SqlServer 等數據庫中，Flink 對這些數據庫的數據的拉取並沒有提供支持。我們封裝了 Obus-DB 的組件，來適配各類數據庫，將數據同步到 Kafka 中，支持後續數據入湖的消費。

InfoQ：你們是如何將基於 Apache Iceberg 的數據湖方案，與 OPPO 已有的數據倉庫融合的（分哪些階段、關鍵工作等）？改造過程中存在哪些難點和挑戰？你們是如何解決的？

**鮑永成：**倉湖融合可以分爲 3 個階段，目標是做到 3 個統一：統一數據、統一元數據、統一計算引擎。

1）統一數據

大數據 Lambda 架構分實時離線兩條鏈路，兩條鏈路可能造成數據不一致。Kappa 架構雖然統一了鏈路，但 kafka 的特徵註定了這套架構對歷史分析並不友好。引入 Iceberg 換掉 kafka，可以認爲是 Kappa 架構的升級，簡稱 Kappa+，可以做到在一條鏈路上完成數據入倉，支撐流批數據分析。Iceberg Commit Snapshot 架構實時性不及 Kafka。目前我們採用 Iceberg 備份 Kafka 數據，同時縮短 Kafka 數據的存儲時間，以滿足用戶的實時性需求，併爲後續的 Iceberg 優化預留空間。

2）統一元數據

目前大數據的元數據基本都存儲在 HiveMetaStore 中，Iceberg 構建表，需要融合其中。Flink 1.9 版本以前，是自己管理元數據，基於此，OPPO 的元數據也分離線和實時兩套；Flink 1.11 版本後，對 HiveMetaStore 的集成已經比較成熟，我們正在將實時鏈路的元數據逐部遷移到 HiveMetaStore。

3）統一引擎

Iceberg 目前可以支撐 Flink、Spark、Presto 的查詢，這雖然給了用戶更多的選擇，但同時也給用戶帶來了選擇困難。在引擎層，可以做到一套引擎出口，根據數據特徵通過 HBO 靈活選擇執行引擎。這項工作目前正在規劃中。

目前數據埋點入倉與數據庫 CDC 入倉兩條鏈路已經完成了數據湖架構改造，但 OPPO 每天入倉的數據量巨大，Iceberg 性能還需要優化。

3 沒有完備的數據體系，空談湖倉之爭沒意義

InfoQ：您認爲現階段 Iceberg 還存在哪些不足待改進？你們有沒有什麼踩坑經驗可以分享？

**鮑永成：**Iceberg 目前雖然有基於文件的統計信息，方便做謂詞下推的數據過濾，但還缺少細緻的索引規範來加速文件檢索。同時 Row-level delete 的性能也不夠高效，還有優化空間。

InfoQ：接下來對於數據湖引擎和調度平臺的建設，以及湖倉融合架構改造，你們還有哪些規劃？

**鮑永成：**談論數據湖和數據倉庫，立足點應該建立提供更好的數據服務上。完備的數據體系，包括數據存儲、多模態計算引擎、依賴調度、質量管理、血緣管理、任務診斷、數據集成、統一元數據、數據安全、數據服務等多方面內容，只有這些方面的能力完備，才能提供優質的數據服務，這是 OPPO 數據中心的核心工作。無論是數據湖，還是數據倉庫的數據，只有運轉在這套體系下，才能得到高效利用。在上述能力具備的條件下，解決好湖數據快速構建 schema、湖與倉的元數據統一問題，倉湖自然融合。上述能力不完備，空談湖與倉之爭，沒有太多意義，孤島問題不可避免，數據利用率低，使用成本高。

InfoQ：您怎麼看數據湖和數倉融合架構未來的發展趨勢？企業或業務團隊該從哪些方面去評估自己是否需要引入湖倉融合架構？

**鮑永成：**倉湖融合的架構是個必然趨勢。數據時代，人們產生和接觸的數據越來越多樣，數據服務的要求也越來越高。快速而又低成本的利用數據，數據湖有着較爲明顯的優勢。如果企業與團隊面臨這樣的挑戰，可以引入倉湖融合的架構。但要做到倉湖融合，可以結合自身的情況，參考上一個問題的回答。

採訪嘉賓介紹

鮑永成，OPPO 雲數架構 & 個人雲負責人。曾服務於土豆網、思科、京東、頭條等公司。長期負責雲計算平臺、大數據平臺的研發與技術演進。帶領團隊先後在京東商城、OPPO 實施完成了全量業務上雲戰略。目前致力於打造 OPPO 開放的雲與大數據能力，在跨場景、多終端的超大空間爲用戶提供智慧服務。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/RVBFmpteXCLwkn43dYnA4g

猜你喜歡