一、技術(shù)架構(gòu)

OPPO 大數(shù)據(jù)場(chǎng)景豐富，擁有海外的 AWS 功能云，國(guó)內(nèi)自建機(jī)房，機(jī)器規(guī)模超過(guò)萬(wàn)臺(tái)，在印度則是使用混合云模式。

首先來(lái)介紹一下 AWS 上功能云 EMR 的實(shí)踐。

1. 云原生計(jì)算架構(gòu)

OPPO 早期全部采用 EMR，其存在以下一些問(wèn)題：

• 首先，彈性伸縮遲滯。上圖中展示了資源的分配效率（不是真正的資源利用率和機(jī)器的物理利用率），以及資源彈性趨勢(shì)圖?？梢钥吹?，凌晨高峰時(shí)資源使用率瞬間變高，回收資源持續(xù)了很長(zhǎng)時(shí)間，效率低，彈性差。
• 另外，編碼機(jī)器選型固化。云上的機(jī)器基本都是 Intel 的 x86 機(jī)型，無(wú)論是 AWS 還是阿里云提出的 ARM 機(jī)型從單價(jià)上就便宜 20-30%，但是 EMR 產(chǎn)品不兼容 ARM 機(jī)型。
• 最后是調(diào)度算法固定。

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

業(yè)界有很多開源的 RSS 解決方案，包括阿里巴巴的 RSS 平臺(tái)和騰訊的 Uniform 平臺(tái)。OPPO 的云需求較少，因此投入比較低。我們的架構(gòu) base 在分布式內(nèi)存Alluxio 上，在 AWS 上實(shí)現(xiàn)彈性的 Alluxio 集群。思路是只做 shuffle 服務(wù)，存儲(chǔ)交給性能高的、更合適的存儲(chǔ)系統(tǒng)，開始是 HDFS、Cubefs 分布式文件系統(tǒng)，后面選用了 Alluxio。內(nèi)部測(cè)試系統(tǒng)性能比較高，包括彈性 RSS 服務(wù)，可以根據(jù)壓力自動(dòng)調(diào)整彈性。

資源調(diào)度優(yōu)化，核心在于計(jì)算架構(gòu)資源。自研架構(gòu)下，資源利用率彈性效率高，每個(gè)小時(shí)都有一個(gè)波峰波谷，平均物理資源利用率達(dá)到 80% 以上，長(zhǎng)時(shí)間維持在 80-90% 上下。

另外，組件全云化。除了 Yarn 和 Spark，大數(shù)據(jù)鏈路中還有許多其他關(guān)鍵的組件和工具，包括任務(wù)調(diào)度和工作流管理。調(diào)度采用的是 Airflow，并對(duì)其進(jìn)行了一些自定義修改，以適應(yīng)特定的任務(wù)調(diào)度需求或環(huán)境。Airflow 的 worker 基本是常駐資源，每一個(gè)業(yè)務(wù)來(lái)了之后都會(huì)申請(qǐng) 2 個(gè) worker，費(fèi)用昂貴，所以將其改為彈性的資源配置，有任務(wù)需要執(zhí)行時(shí)才進(jìn)行資源配置。

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

上圖是成本看板。原本 AWS 兩天才會(huì)出一次賬單，使用自研架構(gòu)后，每個(gè)小時(shí)就會(huì)出一個(gè)賬單，包括單價(jià)花費(fèi)以及每個(gè)機(jī)型的使用時(shí)間。

2. Data&AI 一體化數(shù)據(jù)湖架構(gòu)

整體架構(gòu)如上圖所示。主要解決的問(wèn)題包括：

• 數(shù)據(jù)秒級(jí)入湖，在公司內(nèi)部替代了部分資源的使用，達(dá)到了降本的效果。
• 自動(dòng)化管理，Iceberg 缺少一層服務(wù)層，業(yè)務(wù)需要自己管理。
• 兼容非結(jié)構(gòu)化數(shù)據(jù)，我們做了一個(gè) DAA Catalog 來(lái)兼容非結(jié)構(gòu)化數(shù)據(jù)的管理。

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

DAA Catalog 主要包括兩個(gè)模塊：Metastore 和管理模塊。Metastore 類似于 HMS，主要解決元數(shù)據(jù)生命周期管理的問(wèn)題。管理模塊的功能主要包括：數(shù)據(jù)安全和數(shù)據(jù)血緣、dump 服務(wù)和動(dòng)態(tài)聚合、非結(jié)構(gòu)化數(shù)據(jù)的版本管理，以及非結(jié)構(gòu)化數(shù)據(jù)的轉(zhuǎn)換服務(wù)。

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

Data & AI 中，Data 指的是結(jié)構(gòu)化的數(shù)據(jù)，AI 的數(shù)據(jù)全是非結(jié)構(gòu)化的數(shù)據(jù)。

結(jié)構(gòu)化數(shù)據(jù)的處理最初是基于 Iceberg，目前可兼容多種接口協(xié)議。自動(dòng)化管理包括cluster、dumper、indexer、combiner 等。另外對(duì)索引能力也做了增強(qiáng)。

我們?cè)诮Y(jié)構(gòu)化數(shù)據(jù)的處理上嘗試了很多優(yōu)化。因?yàn)槭欠植际絻?nèi)存的緩存，緩存上的性能加速，數(shù)據(jù)的索引，熱表緩存和數(shù)據(jù)預(yù)熱在內(nèi)存里。

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

非結(jié)構(gòu)化數(shù)據(jù)的管理，主要問(wèn)題在于元數(shù)據(jù)，我們希望非結(jié)構(gòu)化數(shù)據(jù)能夠像結(jié)構(gòu)化數(shù)據(jù)那樣方便地使用。另外一個(gè)問(wèn)題是數(shù)據(jù)格式轉(zhuǎn)換，有些處理方式還比較原始，落到湖上之后會(huì)有 Trans-Service，例如將圖片數(shù)據(jù)轉(zhuǎn)換成 h5 或 dataset 格式，dataset 格式參照 Updataset 協(xié)議，提供一個(gè)統(tǒng)一的上層 API。

圖中元數(shù)據(jù)轉(zhuǎn)換使用的是我們自己的 AndesGPT，也可以調(diào)用 ChatGPT。元數(shù)據(jù)embedding 到數(shù)據(jù)庫(kù)里面，方便上層自然語(yǔ)言式的查詢和搜索。

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

DataPrompter，在公司內(nèi)部的聊天系統(tǒng)中，在對(duì)話框里 @機(jī)器人可以很方便地查詢各種數(shù)據(jù)指標(biāo)。開發(fā)過(guò)程中遇到的問(wèn)題是，每輸入一個(gè)表格，需要人工編織很多詳細(xì)的 prompt，使 GPT 更好地去認(rèn)識(shí)數(shù)據(jù)，寫更精準(zhǔn)的 SQL，海量的數(shù)據(jù)需要一個(gè)一個(gè)地制作 prompt，這就會(huì)構(gòu)成瓶頸。入湖之后，根據(jù)元數(shù)據(jù)包括一些普通的信息都自動(dòng)生成轉(zhuǎn)換范例 prompt，從而使大模型能夠更好地理解湖倉(cāng)上的數(shù)據(jù)。

在此基礎(chǔ)上，還會(huì)將歷史查詢的業(yè)務(wù)含義反饋到 prompt 里，以及業(yè)務(wù)方的測(cè)試反饋。

Databricks 提供 Model Pre-Trainingt 的 TensorBoard 模型，把湖倉(cāng)上的元數(shù)據(jù)進(jìn)行訓(xùn)練，后期我們也會(huì)使用這種模式進(jìn)行模型微調(diào)。

數(shù)據(jù)入湖階段，大語(yǔ)言模型為更好地寫出更精準(zhǔn)的 SQL，會(huì)把 SQL 的規(guī)則編寫到prompt 里面。另外，表結(jié)構(gòu)、字段和指標(biāo)口徑說(shuō)明打開直接寫進(jìn)去。模型輸出OutputCommand 關(guān)注點(diǎn)和格式要求，輸出 SQL 對(duì)應(yīng)寫法要求和標(biāo)準(zhǔn)。

二、應(yīng)用落地

1. 實(shí)時(shí)特征平臺(tái)

實(shí)時(shí)特征平臺(tái)的架構(gòu)如上圖所示。

通過(guò)主鍵實(shí)時(shí) Join，實(shí)現(xiàn)了每秒拼接單機(jī) qps-7k，延伸到多臺(tái)機(jī)器實(shí)現(xiàn)了線性的擴(kuò)展。

2. 機(jī)器學(xué)習(xí)訓(xùn)練數(shù)據(jù)加速

下面介紹機(jī)器學(xué)習(xí)訓(xùn)練湖倉(cāng)數(shù)據(jù)加速的方法。首先是搜推算法訓(xùn)練數(shù)據(jù)加速，很多數(shù)據(jù)是裸的文本數(shù)據(jù)，txt 格式，上層的 Python 讀取的時(shí)候會(huì)涉及到序列化性能慢的問(wèn)題，我們將文本數(shù)據(jù)轉(zhuǎn)換為 Parquet 格式，并使用 Arrow 庫(kù)來(lái)讀取。經(jīng)過(guò)線上測(cè)試，性能會(huì)有 10 倍的提升。

大模型的訓(xùn)練加速，會(huì)將裸的圖片數(shù)據(jù)轉(zhuǎn)換成分割好的 tar 包的 Dataset 的數(shù)據(jù)格式，通過(guò)緩存加速大模型訓(xùn)練數(shù)據(jù)的讀取。訓(xùn)練時(shí)圖片數(shù)據(jù)加載還是個(gè)瓶頸，圖片數(shù)據(jù)的數(shù)據(jù)量比較大，如果用比較大的 tar 包性能會(huì)比較差。通過(guò)轉(zhuǎn)換為小的 dataset 能得到數(shù)倍的性能提升。

3. 混合云場(chǎng)景應(yīng)用

混合云在印度業(yè)務(wù)中有使用，但由于沒(méi)有太多算法的業(yè)務(wù)，機(jī)器規(guī)模較小。以混合云上數(shù)據(jù)湖倉(cāng)數(shù)據(jù)任務(wù)靈活編排。DAA-Catalog 統(tǒng)一管理混合云數(shù)據(jù)復(fù)制遷移。

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

DataPrompt 落地的情況，Datachart 架構(gòu)流程如圖，底層是湖倉(cāng)的數(shù)據(jù)，先確定是否為數(shù)據(jù)分析問(wèn)題然后轉(zhuǎn)化為 SQL 執(zhí)行，數(shù)據(jù)在湖倉(cāng)上解決不了的話就聯(lián)網(wǎng)分析。Glacier 湖倉(cāng)服務(wù)會(huì)找到這個(gè)表的 Prompt 推給大語(yǔ)言模型，進(jìn)行自然語(yǔ)言數(shù)據(jù)分析。

上圖中展示了內(nèi)部的使用情況。通過(guò)數(shù)據(jù)對(duì)比可以得出，大語(yǔ)言模型在數(shù)據(jù)分析上是比較有幫助的。

三、展望

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

另外一個(gè)方向是 Data & AI 湖倉(cāng)架構(gòu)，很多業(yè)界頂尖公司都在推動(dòng)這一理念。但是元數(shù)據(jù)管理存在痛點(diǎn)，活躍度低的表仍需解決沖突問(wèn)題，向上與大模型應(yīng)用結(jié)合。半結(jié)構(gòu)化數(shù)據(jù)通過(guò)統(tǒng)一接口訪問(wèn)，封裝了 dataset 的接口，向下需與 Paimon 結(jié)合，兼容更多底層格式，方便用戶查找和訓(xùn)練數(shù)據(jù)。