1.背景
OPPO從19年開始，用了兩年時間，以K8S，容器化為核心，完成了公司混合雲建設，並實現100%線上業務上雲。OPPO的業務，目前覆蓋國內，南亞，歐洲，美洲，在國內我們有自己的機房，在海外，更多是和公有云合作，有AWS，Google。OPPO的雲是朵雲上雲，與共有云的合作，更多隻是採購機器資源，部署我們自己的服務。OPPO雲給我司帶來了數億的降本紅利，得到了公司的廣泛認可。
目前OPPO的資料平臺規模，計算資源近萬臺，儲存接近1個EB，離線任務數近百萬，實時任務數千。統計我們過去幾年的增速，平均下來，每年大概有30%的規模增長。如此的一個規模增長下，系統SLA三個9，任務100%準點，是我們必須要保障的，同時，公司希望資料平臺能夠把過往快速增長的成本降下來。所以 業務快速增長、系統SLA和任務準點率保持高水平的前提下，如何進一步降本增效是我們必須要解決的問題。
對於這樣一個問題，我們的解法是進行一系列的技術升級，主要包括批流一體、雲數融合排程、資料湖儲存三個方面。
2.批流一體
如上圖，上半部分，典型的Lambda架構。 批流兩條計算鏈路，後設資料分開。應用側的多種OLAP引擎，也有各自的儲存方法與後設資料管理。
我們通常說的批流一體，一般涉及到三個方面的統一，後設資料，儲存，引擎。這三方面，OPPO更看重前兩點。為了後設資料的統一，我們以HMS服務為主，同時通過Waggle-Dance進行了加固。為了儲存的統一，我們引入了Iceberg ，打破實時數倉，離線資料的儲存邊界，同時提高資料倉儲的實時性。
最近兩年，開源界以Delta， Hudi， Iceberg為代表的Data Lake Format非常流行。他們近實時，ACID語意，支援快照語回溯等特性，吸引的不少開發者。剛才的介紹，大家也看到了，OPPO的選擇是Iceberg，其中最重要的是支援CDC的近實時特性。 但是近實時的特性在我們做業務推廣是，卻顯得有些雞肋。離線場景，小時任務可以滿足大部分場景的時效要求。實時場景 ，對退化為成本更低的近實時，業務上對延時很難接受。
為了實現Iceberg的實時化，我們對它做了一些技術改進，下面分兩個場景介紹。
場景一：是資料庫的CDC入湖場景，需要支援資料變更。大資料領域，解決資料實時寫入問題，通查會使用LSM結構。因此我們在架構上引入了Parker，一個支援分散式LSM的KV，在Iceberg前，承擔資料緩衝。KV的引入，對基於主鍵的upsert也能夠得到比較好的支援。
場景二：基於手機埋點的資料上報，每天的資料上報量非常龐大，萬億級別。 這條鏈路中，使用了大量的Kafka資源。我們實時數倉的鏈路，Kafka的資料儲存週期是T+3 ~ T+1天，這個過程中，我們選擇通過Iceberg，使用效率更高的列式儲存，降低Kafka的儲存水位，使Kafka的資料儲存週期變為T+3小時。既保障實時性，同時又降低Kafka儲存成本。
3.雲數融合排程
OPPO每年30%的算力增長，評估下來，2022年大概有8w核算力缺口。如果不外採，算力缺口是否有補齊途徑。有平臺經驗的夥伴，一般都瞭解，白天，通常是線上業務高峰。而夜間，往往離線計算會把叢集計算資源打的很滿，白天的負載，通常在50%左右。實現潮汐排程，線上、離線算力融合，是我們的必然選擇。
實現算力融合，我們並沒有完全走雲原生的路徑，計算資源完全由K8S排程。 因為YARN的排程邏輯比K8S簡單，對於大資料任務資源頻繁釋放回收的場景，效率上遠高於K8S。因此，我們選擇了YARN+K8S的排程邏輯，在K8S上實現yarn-operator。任務高峰，有K8S給大資料叢集釋放資源，過了高峰期，則自動回收。
雲數融合排程中，大家可能會擔心一個問題，就是容器釋放的算力，效能上是否能夠滿足計算要求。這裡可以得大家看下我們的一些測試。測試對比項是物理機、SSD容器，SATA容器，VM容器。 從測試中可以看到，同等配置條件下，物理機效能最好，SSD容器和SATA容器效能次之。VM上的容器效能下降的比較厲害。所有，SSD容器和SATA容器效能損耗，是可以接受的。
雲數融合排程中，大家通常會面臨一個問題，就是如何穩定保障計算引擎的Shuffle效率。我們使用的是OPPO自研Shuffle Service。OPPO自研Shuffle Service 的初衷，是為了降低大任務的Shuffle失敗率。我們的平臺推出計算賬單後，時不時會有使用者因為Shuffle失敗，希望我們減免計算費用。因為要知道Shuffle跑失敗的任務通常規模不會小，費用可能是成百上千元。從平臺的角度，當然不希望任務失敗，就減免費用。雲數融合中，Shuffle Service也起到了很好的作用，遠端的Shuffle 服務，有效降低了本地儲存壓力，在資源擴縮容過程中，也能夠保障計算穩定。
這裡，可以給大家，看一下Shuffle Service的測試資料。 這是TPC-H ,1TB資料下的測試結果。Shuffle Service 並不是說對所有的SQL任務，都能提高執行效率。但對Q16，Q21這樣的大任務，效率提升還是非常明顯的。 平均下來，大概有16%左右的提升。
4.資料湖儲存
OPPO的資料儲存，經歷了三個階段。
階段一：全HDFS儲存。 階段二： 引入物件儲存 。階段三： 自研ADLS資料湖儲存。
階段一到階段二，主要是將資料通過資料資產平臺的週期設定，在達到某個時間點後，自動作為冷資料遷移到物件儲存。階段二到階段三，則是統一檔案，物件儲存，由升級後的檔案系統解決後設資料瓶頸，冷熱溫分層儲存。自研儲存，關鍵技術有多協議適配，分散式後設資料，扁平命令空間加速，多級快取等。下面我逐一做下介紹。
檔案系統提供的是層次名稱空間檢視，整個檔案系統的邏輯目錄樹分成多層，如上圖所示，每個後設資料節點(MetaNode)包含成百上千的後設資料分片（MetaPartition），每個分片由InodeTree（BTree）和DentryTree（BTree）組成，每個dentry代表一個目錄項，dentry由parentId和name組成。在DentryTree中，以PartentId和name組成索引，進行儲存和檢索；在InodeTree中，則以inode id進行索引。使用multiRaft協議保障高可用性和資料一致性複製, 且每個節點集合會包含大量的分片組，每個分片組對應一個raft group；每個分片組隸屬於某個volume；每個分片組都是某個volume的一段後設資料範圍（一段inode id ); 後設資料子系統通過分裂來完成動態擴容；當一分片組資源(效能、容量)緊接臨近值時，資源管理器服務會預估一個結束點，並通知此組節點裝置，只服務到此點之前的資料，同時也會新選出一組節點，並動態加入到當前業務系統中。
單個目錄支援百萬級別容量，後設資料全記憶體化，保證優秀的讀寫效能，記憶體後設資料分片通過snapshot方式持久化到磁碟以作備份及恢復使用。
而物件儲存提供的是扁平名稱空間；以訪問objectkey為/bucket/a/b/c的物件為例，從根目錄開始，通過”/”分隔符層層解析，找到最後一層目錄(/bucket/a/b)的Dentry，最後找到的/bucket/a/b/c對於的Inode，此過程涉及多次節點間互動，層次越深，效能較差；因此我們引入PathCache模組用於加速ObjectKey解析，簡單做法是在PathCache中對ObjectKey的父目錄(/bucket/a/b)的Dentry做快取；分析線上叢集我們發現，目錄平均大小約為100，假設儲存叢集規模在千億級別，目錄條目也才10億個，單機快取效率很高，同時可通過節點擴容來提升讀效能；在同時支援"扁平"和"層次"名稱空間管理的設計，與業界其他系統相比，CBFS實現得更簡潔，更高效，無需任何轉換即可輕鬆實現一份資料，多種協議訪問互通，且不存在資料一致性問題。
資料湖架構帶來顯著的收益之一是成本節約，但存算分離架構也會遇到頻寬瓶頸和效能挑戰，因此我們也提供了一系列訪問加速技術：
一. 多級快取能力
第一級快取：本地快取，其與計算節點同機部署，支援後設資料和資料快取，支援記憶體、PMem、NVme、HDD不同型別介質，特點是訪問時延低，但容量少.
第二級快取：分散式快取，副本數目彈性可變，提供位置感知能力，支援使用者/桶/物件級的主動預熱和被動快取，資料淘汰策略也可配置
多級快取策略在我們的機器學習訓練場景有不錯的加速效果。
二. 謂語下推操作
另外儲存資料層還支援了謂語下推操作，可顯著減少儲存與計算節點間大量的資料流動，降低資源開銷並提升計算效能；
資料湖加速還有很多細緻的工作，我們也在持續完善的過程中。
5.展望
最後，結合剛才提到的三點技術方向，說下我們未來的一些規劃和展望。
批流一體的計算，我們做到了後設資料統一，儲存統一。計算引擎統一，是可以積極探索的方向。雖然以 Flink 為代表的計算引擎，不斷地宣稱自己能做到批流一體，但是從實踐角度，一個系統想做得多，往往不能再每個方向上都做到極致。統一的計算引擎我持保留意見，但不排斥這個方向的探索。這點上，我個人更傾於在批、流和互動式計算引擎上有一個公共層，通過這個公共層遮蔽不同引擎帶來的適配成本，而非在引擎層實現完全的計算統一。
雲數融合排程，目的是實現資源彈性，目前主要通過定時機制實現。因為我們知道業務資源利用規律，把這樣的規律通過規則配置到我們彈性策略中。但是，彈性排程應該是更敏捷型，更靈活的，系統可以感知負載情況，自動進行資源的釋放和回收。因為日常業務中會經常會有大規模任務重跑，任務突增等情況。這種情況下，靈活自主的擴縮容策略會對我們的業務有更好的幫助。
儲存方面，剛才我們提到的冷、熱、溫分層儲存目前還需要使用者來定義。如某張事實表資料多久變冷存，某張維表是否一直需要熱快取加速。隨著業務的變化，冷資料可能變成熱資料，也需要手動做引數調整。其實，資料冷、熱、溫的劃分，可以根據動態監測到的一些指標資料，通過演算法自動地進行標識，轉化，以達到不同資料使用不同儲存介質，進而擁有更合理的儲存成本。
最後還想說一點，資料平臺我們會持續與雲的融合。近年來廣泛討論的 Snowflake ，將資料倉儲搬到雲上，同時支援多雲部署，非常有代表性。我們的產品和能力嫁接到雲上，可以更廣泛的輸出我們的服務。
作者簡介
Keung Chau OPPO資料架構負責人
負責 OPPO 資料平臺的建設與技術演進。
獲取更多精彩內容，掃碼關注[OPPO數智技術]公眾號
