一、技術架構

OPPO 大數據場景豐富，擁有海外的 AWS 功能云，國內自建機房，機器規模超過萬臺，在印度則是使用混合云模式。

首先來介紹一下 AWS 上功能云 EMR 的實踐。

1. 云原生計算架構

OPPO 早期全部采用 EMR，其存在以下一些問題：

• 首先，彈性伸縮遲滯。上圖中展示了資源的分配效率（不是真正的資源利用率和機器的物理利用率），以及資源彈性趨勢圖。可以看到，凌晨高峰時資源使用率瞬間變高，回收資源持續了很長時間，效率低，彈性差。
• 另外，編碼機器選型固化。云上的機器基本都是 Intel 的 x86 機型，無論是 AWS 還是阿里云提出的 ARM 機型從單價上就便宜 20-30%，但是 EMR 產品不兼容 ARM 機型。
• 最后是調度算法固定。

為了解決上述問題，OPPO 自研了極致彈性計算架構——Yarn on EKS。EKS 是AWS 提供的托管型 Kubernetes 服務。Kubernetes 難以滿足大規模快速調度的需求，無法做到快速調度、機器可掌控、資源可控制。因此我們選用了 Yarn on EKS。

業界有很多開源的 RSS 解決方案，包括阿里巴巴的 RSS 平臺和騰訊的 Uniform 平臺。OPPO 的云需求較少，因此投入比較低。我們的架構 base 在分布式內存Alluxio 上，在 AWS 上實現彈性的 Alluxio 集群。思路是只做 shuffle 服務，存儲交給性能高的、更合適的存儲系統，開始是 HDFS、Cubefs 分布式文件系統，后面選用了 Alluxio。內部測試系統性能比較高，包括彈性 RSS 服務，可以根據壓力自動調整彈性。

資源調度優化，核心在于計算架構資源。自研架構下，資源利用率彈性效率高，每個小時都有一個波峰波谷，平均物理資源利用率達到 80% 以上，長時間維持在 80-90% 上下。

另外，組件全云化。除了 Yarn 和 Spark，大數據鏈路中還有許多其他關鍵的組件和工具，包括任務調度和工作流管理。調度采用的是 Airflow，并對其進行了一些自定義修改，以適應特定的任務調度需求或環境。Airflow 的 worker 基本是常駐資源，每一個業務來了之后都會申請 2 個 worker，費用昂貴，所以將其改為彈性的資源配置，有任務需要執行時才進行資源配置。

上圖展示了我們自研架構的資源看板。從右下方的彈性效率圖可以看到，每小時都會有波峰波谷，物理資源的平均利用率可以達到 80% 以上。

上圖是成本看板。原本 AWS 兩天才會出一次賬單，使用自研架構后，每個小時就會出一個賬單，包括單價花費以及每個機型的使用時間。

2. Data&AI 一體化數據湖架構

整體架構如上圖所示。主要解決的問題包括：

• 數據秒級入湖，在公司內部替代了部分資源的使用，達到了降本的效果。
• 自動化管理，Iceberg 缺少一層服務層，業務需要自己管理。
• 兼容非結構化數據，我們做了一個 DAA Catalog 來兼容非結構化數據的管理。

采用分布式內存來解決實時性問題，雖然線上集群規模較大，但內存閑置比較多，使用分布式內存可以將內存資源更好地利用起來，在數據湖上用這種方式解決了數據實時入湖的問題。數據實時寫入分布式內存的 block 里面，然后 Dump 服務會定時管理這些 block 何時落到 Iceberg 底層的存儲上。

DAA Catalog 主要包括兩個模塊：Metastore 和管理模塊。Metastore 類似于 HMS，主要解決元數據生命周期管理的問題。管理模塊的功能主要包括：數據安全和數據血緣、dump 服務和動態聚合、非結構化數據的版本管理，以及非結構化數據的轉換服務。

實現秒級實時的做法是，在內存里把數據做成 real-data，底層是 base-data。另外很多 dele-data 也是放在內存里，這樣 Dump 的時候自動合并。分布內存管理使用的是 Alluxio，但是對功能進行了魔改，Alluxio2.9 開源版本的通信傳輸效率不好，我們通過修改使性能得到了顯著提升。另外還實現了 Alluxio 流式讀寫，數據可以逐條寫入。

Data & AI 中，Data 指的是結構化的數據，AI 的數據全是非結構化的數據。

結構化數據的處理最初是基于 Iceberg，目前可兼容多種接口協議。自動化管理包括cluster、dumper、indexer、combiner 等。另外對索引能力也做了增強。

我們在結構化數據的處理上嘗試了很多優化。因為是分布式內存的緩存，緩存上的性能加速，數據的索引，熱表緩存和數據預熱在內存里。

上圖展示了一個比較特殊的案例，是搜推業務在實時樣本拼接時遇到的一個問題，HBase 成本較高，且性能也不能滿足需求。提出的解決方案是多數據源主鍵實時 Join。涉及到的樣本數據，單條數據量比較大，平均一兆左右，把數據的索引放到分布式內存中，數據實時過來后在內存里的 hash partition 找到相關的索引去拼接，類似于 MOR 機制。

非結構化數據的管理，主要問題在于元數據，我們希望非結構化數據能夠像結構化數據那樣方便地使用。另外一個問題是數據格式轉換，有些處理方式還比較原始，落到湖上之后會有 Trans-Service，例如將圖片數據轉換成 h5 或 dataset 格式，dataset 格式參照 Updataset 協議，提供一個統一的上層 API。

圖中元數據轉換使用的是我們自己的 AndesGPT，也可以調用 ChatGPT。元數據embedding 到數據庫里面，方便上層自然語言式的查詢和搜索。

上圖是一個管理示例，我們可以像 SQL 查詢一樣去查詢圖片、文本數據的詳情。

DataPrompter，在公司內部的聊天系統中，在對話框里 @機器人可以很方便地查詢各種數據指標。開發過程中遇到的問題是，每輸入一個表格，需要人工編織很多詳細的 prompt，使 GPT 更好地去認識數據，寫更精準的 SQL，海量的數據需要一個一個地制作 prompt，這就會構成瓶頸。入湖之后，根據元數據包括一些普通的信息都自動生成轉換范例 prompt，從而使大模型能夠更好地理解湖倉上的數據。

在此基礎上，還會將歷史查詢的業務含義反饋到 prompt 里，以及業務方的測試反饋。

Databricks 提供 Model Pre-Trainingt 的 TensorBoard 模型，把湖倉上的元數據進行訓練，后期我們也會使用這種模式進行模型微調。

數據入湖階段，大語言模型為更好地寫出更精準的 SQL，會把 SQL 的規則編寫到prompt 里面。另外，表結構、字段和指標口徑說明打開直接寫進去。模型輸出OutputCommand 關注點和格式要求，輸出 SQL 對應寫法要求和標準。

二、應用落地

1. 實時特征平臺

實時特征平臺的架構如上圖所示。

通過主鍵實時 Join，實現了每秒拼接單機 qps-7k，延伸到多臺機器實現了線性的擴展。

2. 機器學習訓練數據加速

下面介紹機器學習訓練湖倉數據加速的方法。首先是搜推算法訓練數據加速，很多數據是裸的文本數據，txt 格式，上層的 Python 讀取的時候會涉及到序列化性能慢的問題，我們將文本數據轉換為 Parquet 格式，并使用 Arrow 庫來讀取。經過線上測試，性能會有 10 倍的提升。

大模型的訓練加速，會將裸的圖片數據轉換成分割好的 tar 包的 Dataset 的數據格式，通過緩存加速大模型訓練數據的讀取。訓練時圖片數據加載還是個瓶頸，圖片數據的數據量比較大，如果用比較大的 tar 包性能會比較差。通過轉換為小的 dataset 能得到數倍的性能提升。

3. 混合云場景應用

混合云在印度業務中有使用，但由于沒有太多算法的業務，機器規模較小。以混合云上數據湖倉數據任務靈活編排。DAA-Catalog 統一管理混合云數據復制遷移。

通過混合云模式，混合云數據任務遷移中，帶寬是主要的瓶頸，遷移的時候通過找到數據和計算對帶寬依賴最小的子圖的方式去遷移，同時也會考慮底層的數據一致性，使得數據入湖底層路徑透明。

DataPrompt 落地的情況，Datachart 架構流程如圖，底層是湖倉的數據，先確定是否為數據分析問題然后轉化為 SQL 執行，數據在湖倉上解決不了的話就聯網分析。Glacier 湖倉服務會找到這個表的 Prompt 推給大語言模型，進行自然語言數據分析。

上圖中展示了內部的使用情況。通過數據對比可以得出，大語言模型在數據分析上是比較有幫助的。

三、展望

未來仍會注重大數據方面的開發和發展。在公有云架構方面進一步深挖，公有云實施的彈性架構為公司節省了大量財務支出，單任務計算成本相比 EMR 降低了約 80% 左右，后續將嘗試更多手段，繼續深化這塊領域的技術。公有云架構 Spark on GPU 的加速已經實現，進一步要對接 Shuttle Service。Spark on GPU 的收益為，性能提升 4 倍，成本降低約 50%。引擎向量化 Gluten+Velox 的概念，業內比較火熱，各大公司都在嘗試，開發中存在一些問題，所以目前沒有過多的投入，但是未來的一個方向。持續降本增效永遠是底層技術的主題，降本和穩定性是兩條生命線，降本是否可以犧牲一定的穩定性這一問題仍需思考。

另外一個方向是 Data & AI 湖倉架構，很多業界頂尖公司都在推動這一理念。但是元數據管理存在痛點，活躍度低的表仍需解決沖突問題，向上與大模型應用結合。半結構化數據通過統一接口訪問，封裝了 dataset 的接口，向下需與 Paimon 結合，兼容更多底層格式，方便用戶查找和訓練數據。