導讀｜過去幾年，數據湖能力已經在騰訊內部包括微信視頻號、小程序等多個業務大規模落地，數據規模達到 PB至 EB 級別。在此基礎上，騰訊自研業務也啓動了雲原生湖倉能力建設。雲原生湖倉架構最大的挑戰什麼？騰訊雲原生湖倉 DLC 從哪些方面着手解決問題？接下來由騰訊雲大數據專家工程師於華麗帶來相關分享。
雲原生湖倉的誕生背景、價值、挑戰
當前這個階段，相信大家對於數據湖，數據倉，湖倉一系列的名詞已經不算陌生了，我用最直白、最狹義方式去解釋“湖倉”的話，就是數據湖跟數倉存儲架構統一。
數據湖最初的需求是，要存儲和分析海量的半結構化、非結構化的數據，以及數據倉備份和溫冷數據存儲。在公有云找到了對象存儲（海量、低價、高 SLA 和高可靠性）這樣一個全託管的存儲產品後，成本方面對象存儲對比客戶 HDFS 自建大概爲 1：10，非常有吸引力。
這個存儲系統看起來這麼好，有沒有可能把數倉一起解決，結構化數據是不是存在這裏？伴隨着這個需求的升級，現代湖倉架構的基礎也隨之產生。
雲原生湖倉又是什麼呢？最狹義的理解就是容器計算 + K8s。更加廣義的理解應該長在雲上，更多的使用雲上已有的全託管產品，比如利用對象存儲、本身服務雲原生化等。
在雲原生湖倉架構下，會面臨很大的挑戰就是“性能”。爲什麼有“性能”的挑戰？第一：對象存儲有很好的成本優勢，但是引入對象存儲之後變成了存算分離的架構，損失了本地計算，整體性能損失 30% 以上；其次彈性計算跟分析性能是矛盾的變量，ScaleUp 需要時間，甚至有可能彈不出來，沒有文件緩存，彈性會引起數據傾斜；最後是敏捷分析，海量明細數據直接分析也是很直接的需求。
騰訊雲原生湖倉產品 DLC 如何應對挑戰
1）DLC 產品定位
DLC 的第一個特點，簡單三個字概況便是——“全託管”，不同於 EMR，DLC 是開箱即用的，例如交互界面、元數據、安全、Spark DDL Server、Spark History 服務等都是全託管、免搭建的，甚至有很多是免費提供的。
第二個特點，DLC 是騰訊雲數據湖解決方案的粘合劑，不同產品能夠用一份湖倉數據，帶給用戶低成本，低維護成本的價值。
2）DLC 架構理念
接下來講 DLC 的架構理念。**DLC 是騰訊大數據自研能力的上雲，但是並不是簡單平移部署，產品形態便是最大的差異。**DLC 是多租戶的全託管產品，我們秉持兩大原則：保持簡單 KISS、雲原生。保持簡單上我們是非常執着的。
對於服務引用非常保守，服務能少則少。取而代之的是 SDK 的接入，例如上圖右側的 Presto 的 Local Cache 就不會引入 Alluxio Cluster，Spark 這兒不引入 RSS 服務而是輕量簡單的 Shuffle Manager 等等。
降低使用複雜度，DLC 集成了騰訊自研 SuperSQL，去實現統一函數和語法來去兩個引擎無縫切換。上圖右側大部分服務都是託管的，如元數據、調度、權限、DDL 服務、Spark History 等這些服務都是用戶免搭建，開箱即用的，大部分是免費的，而且我們還給到了用戶一定的免費額度，只要配置得當，基本是能滿足客戶需求的。
雲原生原則：狹義的說，DLC 都是基於容器的，包括計算引擎和各種服務容器化。廣義的說，雲原生更應該“長在雲上”，DLC 是直接使用雲上的對象存儲、雲數據庫、雲 Kafka、TDSQL 等等全託管 SaaS 服務的。
LC 實現 PB 級數據秒級分析
回到最開始的問題“高性能”，PB 級數據秒級分析該怎麼去做，從三個大維度展開。我們從三個層面出發講，第一從多維 Cache 的角度出發，包括文件緩存，中間結果緩存等；第二從彈性模型出發；第三從三維 Filter 的模型：分區、列、文件出發。
1）多維 cache
多維 Cache 分了三個角度：文件緩存、Fragment 結果緩存以及中間結果緩存、元數據的緩存，重點說說前兩個。
文件緩存：我們在 DLC 上線了 Alluxio Local Cache，優點是沒有單獨的 Alluxio 集羣，也不佔用計算資源，免運維。當然也會有需要優化的地方，比如文件 /Split 級別、跨租戶 Cache 緩存數據安全、緩存一致性、彈性影響、監控、黑名單等，這些優化空間 DLC 都會幫客戶完成。在一些情況下，訪問 Cos 的性能有 3—10 倍的提升。
Fragment 結果緩存：優點是不需要預計算，我們知道物化視圖也非常流行，但是物化視圖的利用率往往不好量化，事實上通常很低，而根據訪問行爲緩存下來的是用戶行爲肯定的；另外是用戶幾乎沒有什麼成本，同時也很大程度上降低底層存儲的壓力。當然，還會涉及到一些問題需要大家注意，例如緩存一致性、跨租戶的安全等。性能方面，從來自 Presto 社區的數據看，Raptorx 有接近 10X 的提升。
2）虛擬集羣彈性模型
剛纔講兩種緩存效果接近 10 倍的性能提升，對彈性模型就有了很高的要求，因爲緩存的命中是很依賴集羣拓撲的穩定性的。另外資源啓動要時間，新拉容器和鏡像最快也要 1—2 分鐘；最後 Client 預熱很重要，包括各種服務都是 Lazy 加載的 Module 等等，這也都是需要 30 秒甚至 1 分鐘的時間，這跟我們要求的秒級分析就差太遠了。
那 DLC 是如何解決這個問題的呢？我們採用了虛擬集羣架構，以子集羣爲最小單位去橫向彈子集羣，這樣子集羣拓撲穩定，資源跟 Client 都有很好預熱。而且因爲子集羣的 Query 隔離，子集羣也是很容易縮容的。
3）多維 Filter 過濾
繼續說性能提升，還是 IO 優化，技術也是比較成熟的，只是還不怎麼普及。先看第二個，列存 Parquet/ORC，結合引擎 Project 的下推，這樣只有關心的列纔會被掃描。第三個分區 / 分桶也比較常規了，但是最新業界的新特性比如 Dynamic Partition Puning，可以很好地加速分區需要推斷的場景。
下面仔細說說稀疏索引。Bloomfilter、Zordering 本質邏輯上是類似的，需要結合引擎的謂詞下推減少 IO掃描，加速分析。
在大數據的海量低成本要求下，稀疏索引可以做到降低存儲成本並且加速分析性能，通過減少數據掃描量達到性能提升。具體分兩步：第一步數據要進行 Cluster，類似的數聚在一起，結合引擎謂詞下推，性能達到10X 以上的提升。同時也能帶來存儲的下降，這個原理其實很容易理解，類似的數據在一起了，Encodin 壓縮能起到更好的效果。這也是大數據引擎，比如說像 CK、Doris 很重要的性能加速模型。
穩定性也是大數據很重要的訴求，前面看到像索引的構建都需要進行大規模的數據 ETL。對於穩定性我們遇到了很多挑戰，包括虛擬集羣彈性模型本身減少了彈性引擎的數據傾斜、Iceberg 減少底層 List、Rename導致任務失敗等等問題。這裏我們主要分享下 DLC 的 Spark Shuffle Manager 架構。
我們知道騰訊開源了 RSS 的服務 Filestorm，在全託管雲原生的場景下我們做了簡化和改造，原理是：優先使用本地磁盤，不足的時候 Spill 到 Cos，下面是業界幾種典型的思路，DLC 的做法秉持着減少服務引入、保持簡單、降低用戶成本、減少用戶/服務的運維。效果也很明顯，大部分任務 /Task 都會以原有的性能完成，少量數據傾斜的任務 /Task 會損失一定的性能，但是依然能穩定完成。
DLC 作爲全託管的產品，還是要強調一下低成本和易用的特性。COS 湖存儲 VS 自建 HDFS 的成本優勢，其實 80% 以上節省來至於 EC、HDFS 要預留資源以及 COS 有各種冷熱分層策略進一步降低成本等。基於 EKS 或者 TKE 彈性資源，對比固定資源節省約 50% 以上的成本，如果是交互式分析場景，週六週日兩天成本就是節省的，晚上也是節省的，離線是類似的。
最後 DLC 是全託管的免運維的一個產品，統一的 SQL 在兩個引擎平滑遷移，SaaS的元數據、DDL服務、權限、調度、SaaS級別的Spark History 保障了用戶開箱即用，而且這些公共服務大部分免費，有的是有免費額度的，正確使用都完全夠用。
湖倉背景下的建模新思路
接下來一起看下，在雲原生湖倉架構下，建模有有哪些新思路：
第一個，扁平湖倉架構，核心是不再維護複雜的數倉分層，而是把明細層的數據能夠直接高性能分析；第二個是離線增量；第三個，現在業界比較時髦的新方向實時增量湖倉。
仔細講一下扁平湖倉的結構，要解釋爲什麼需要扁平湖倉建模，首先要看一下爲什麼要一層層去做分層建模。首先是在傳統的數倉架構下，明細數據的分析的性能不夠高，被迫去進行的預計算，同時因爲多個結果可能會重複利用一部分公共數據，進行了 ETL 抽取。但是在 PB 級數據秒級分析的能力下，這些幾乎都是不必要的。
層層建模的問題：第一是模式是固定的，不夠敏捷。響應需求，從需求對接、歷史數據刷新、測試驗收，一兩個周就過去了；其次是計算利用率往往是低的，尤其 Cube。Cube 雖然命中很快，單 Cube 的利用率往往是個大大的問號，從我們的經驗來看其實非常低；另外分層離線更新是比較慢的，而現在特別火的實時增量更新並不是成熟和穩定，即使落地了對於存儲和計算硬件的需求往往也是很高的。
結合前面講的雲原生湖倉做性能提升的各種手段，在明細層直接分析的扁平湖倉架構的時代自然是大勢所趨了。當然最好能結合 BI 工具的時序結果緩存，這樣 BI 層都可以省去。
最後介紹下一個遊戲客戶的案例：實時扁平湖倉秒級分析——邏輯架構非常簡單直接，數據都是在 Kafka，通過 DLC Spark 去做實時數據的接入，直接寫入幾百張Iceberg 明細表，並且能夠保證冪等。值得注意的是一個 Kafka 裏面有很多張表的數據，保證冪等也有一些比較有意思的邏輯。入到明細表之後，開啓明細表背後的一些優化，用 DLC SuperSQL—Spark，進行清洗、合併小文件、以及稀疏索引構建等，最後達到的效果直接用 DLC SuperSQL-Presto 去做秒級分析，最後去對接 BI 的工具，達到一個非常好的分析性能，架構簡單明瞭，無需各種建模。
你可能感興趣的騰訊工程師作品
公衆號後臺回覆“湖倉”，領本文作者推薦的更多資料