1、云云原生原生湖倉一體白皮書湖倉一體白皮書 （2022022 2 年）年）云云原生原生產業聯盟產業聯盟 Cloud Native Industry AllianceCloud Native Industry Alliance，CNIACNIA 20222022 年年 1212 月月 版權申明版權申明 本白皮書本白皮書版權屬于版權屬于云原生產業聯盟云原生產業聯盟，并受法律保護，并受法律保護。轉載、摘編轉載、摘編或利用其它方式使用或利用其它方式使用本白皮書文字或者觀點的，應本白皮書文字或者觀點的，應注明注明“來源：來源：云原云原生產業聯盟”生產業聯盟”。違反上述聲明者，本。違反上述聲明者，本院院將追

2、究其相關法律責任。將追究其相關法律責任。編編 制制 說說 明明 牽頭編寫單位牽頭編寫單位：中國信息通信研究院 參與編寫單位參與編寫單位：北京偶數科技有限公司、中國聯合網絡通信集團有限公司、中信建投證券股份有限責任公司、中國人壽保險股份有限公司。編寫組編寫組：中國信息通信研究院：劉如明、魏博鍇、杜嵐、周丹穎、蔡鈺、李永欣 北京偶數科技有限公司：常雷、蘇景志、陳超峰、楊哲、丁冉、張立群、鐘彧恒、趙德攀 中國聯合網絡通信集團有限公司：劉洪波 中信建投證券股份有限責任公司：馬麗霞、李可、李海偉、許哲 中國人壽保險股份有限公司：陳宗堅、林志鵬、彭曉剛、陳學亮、鄭曉勇 前前 言言 近年來，數據產業總體保持

3、較快發展，國家先后出臺了多項政策促進數據基礎設施、關鍵技術、應用治理等方面的健康有序發展。伴隨著行業用戶對于數據價值的深入挖掘，數據平臺和產品正在發揮著不可替代的創新引領作用。本白皮書首先介紹了數據平臺發展的三個重要階段，通過對于發展歷程的總結，引出了行業用戶在進行數據分析和處理中面臨的瓶頸難題，并且重點從主要架構、關鍵技術、方案特征、應用價值等方面介紹了云原生湖倉一體最佳解決方案。之后，通過對于湖倉生態版圖、代表廠商和代表解決方案的分析，力求反應現階段國內湖倉生態現狀。最后，從銀行、保險、證券用戶單位的不同角度出發，開展了較為詳實的場景化應用分析，并進行了總結與展望。目目 錄錄 一、云原生湖

4、倉一體發展歷程.1(一)萌芽期：數據倉庫初探數據價值.1(二)上升期：大數據平臺挖掘數據價值.3(三)成熟期：湖倉一體全面展現數據價值.5 二、云原生湖倉一體方案概述.7(一)行業用戶數據處理五大難題.7(二)解決數據處理瓶頸的最佳方案.11(三)云原生湖倉一體主要技術路線.23(四)云原生湖倉一體方案應用價值.25 三、云原生數據湖倉生態現狀.28(一)國內湖倉生態版圖.28(二)國際湖倉典型應用.29 四、云原生湖倉一體實踐案例.31(一)中國建設銀行從湖到湖倉一體的演進之路.32(二)中國人壽湖倉一體總體規劃的研究之路.34(三)中信建投數據倉庫與數據湖的融合探索之路.34 五、總結與展

5、望.36 附錄：湖倉一體典型解決方案.37 1 一、云原生湖倉一體發展歷程 在全球數據產業蓬勃發展的背景下，數據系統正在發揮關鍵的支撐賦能作用，對于數據價值挖掘和業務創新發展起到重要影響。為了應對各類用戶需求，衍生出了聚焦聯機事務處理、聯機分析計算、事務分析混合等不同場景的數據平臺。數據平臺作為企業數字化轉型的重要基礎設施，決定了企業對數據這一新興生產要素的應用能力，對企業數字化轉型的成敗起到了至關重要的作用，其發展經歷了三個時期。(一)萌芽期：數據倉庫初探數據價值 1.發展背景 上世紀 50-60 年代，數據管理工具以“數據庫”的形式首次問世，先后基于網狀模型、層次模型、關系模型等不同的數據

6、結構，出現了IDS、IMS、DB2、Sybase、Oracle 和 SQLServer 等各類產品。其中最具代表性的傳統關系型數據庫，本質上是通過結構化查詢語句，對數據進行增、刪、改、查操作，以實現在 OLTP 聯機事務處理場景下對于關系型表結構數據的存儲和利用。隨著業務規模和類別的不斷豐富，累積的歷史數據越來越多，對業務數據庫產生負載，導致業務系統運行速度降低。在日益激烈的市場競爭中，企業需要對積累的數據進行分析，獲取更加準確的決策信息來完成市場推廣、運營管理等工作。由此，提出將歷史數據存儲到 2 數據倉庫(OLAP)解決方案，在改善業務系統數據庫性能的同時，可以更專注的提升數據分析效率，輔

7、助企業決策。2.技術特性 傳統關系型數據庫的技術架構，尤其是 OLTP 數據庫在海量數據的存儲、查閱以及分析方面出現了明顯的性能瓶頸。隨著分布式技術的產生和發展，出現了以 Teradata 為代表的 MPP 一體機數據庫，以及 Greenplum 和 Vertica 等軟硬件分離的 MPP 數據庫，采用無共享架構(Share-nothing)以支持數據倉庫的建設。這個階段的主要任務是數據分析和決策支持類系統的建設，如數據倉庫、ODS、數據集市、應用數據庫、歷史數據庫以及報表、分析報告、數據挖掘、客戶標簽畫像等。圖 1：OLAP 系統建設 3.階段特點 該階段早期，不少企業直接采用了共享存儲（s

8、hare-disk）架構的Oracle 和 DB2，或是采用 MPP 無共享（Share-nothing）架構的 Teradata等產品，通?；谲浻惨惑w的專有服務器和昂貴的存儲，后雖然引入 3 了基于通用 X86 服務器的解決方案，但架構依然是“無共享”的，特點體現為：數據以結構化為主，集群的擴展能力有限。圖 2：數據倉庫架構圖 然而，隨著用戶數據量的指數級增加，豐富的數據源接入，數據開始呈現出海量、異構、多源等特點，傳統數據倉庫擴容困難、處理數據類型單一的缺點開始逐漸暴露出來，也無法支撐越來越豐富的業務分析需求。(二)上升期：大數據平臺挖掘數據價值 1.發展背景 21 世紀初期，隨著互聯網

9、行業線上業務的快速發展，數據規模呈幾何倍數增長，數據種類也變得更加豐富。傳統數據倉庫側重結構化數據，建模路徑較長，無法滿足企業對于非結構化數據的處理以及數據處理時效性的需求，由此帶來了海量異構數據存儲和處理等的諸多問題?；诠雀琛叭{馬車”論文，形成了 Hadoop 大數據解決方案，4 大數據平臺開始受到關注，尤其受互聯網行業迅速發展的影響，大數據平臺迎來快速發展期。2.技術特性 Hadoop 平臺使用 HDFS 實現數據的分布式存儲，有效解決海量數據的存儲問題。與傳統數據倉庫相比，HDFS 在支持存儲結構化數據的同時還實現了非結構化數據的存儲。HDFS 不是一個單機文件系統，而是分布在多個集

10、群節點上的文件系統。當存儲文件時，文件的數據將分布在多個節點上。讀取文件時，數據從多個節點讀取。Hadoop 平臺使用 MapReduce、Spark 等組件實現分布式計算，并且可以對存儲的數據進行大規模并行處理。通過切片將大量復雜的任務分解成多個少量簡單的任務進行處理，再對處理完成后的任務結果進行匯總分類。3.階段特點 Hadoop 發展初期僅有 HDFS 和 MapReduce 兩個組件，隨著數據量的不斷增大以及對于數據處理時效性的需求不斷升高。計算和存儲組件也在不斷的變化，以適應不同場景的數據存儲與處理需求。大數據平臺底層存儲經過了十余年發展，一直是 HDFS 一枝獨秀。大數據平臺在計算

11、方面發展迅速，由于最初的 MapReduce 大規模批處理無法滿足海量數據處理的實時性，業界在計算方面設計了Spark 快速批處理、Flink 實時數據處理等計算框架。配合這些計算框 5 架的，還有像 Sqoop 這樣的數據流轉采集組件。在大數據分析和處理領域，Hadoop 兼容體系已經成為一個非常成熟的生態圈。圖 3：Hadoop 生態系統重要組件 Hadoop 的誕生改變了企業對數據的存儲、處理和分析的過程，加速了大數據的發展，受到廣泛的應用，給整個行業帶來了變革。隨著云計算時代的到來，企業開始對 Hadoop 的架構進行從基于物理集群到云原生化的改造。(三)成熟期：湖倉一體全面展現數據價

12、值 1.發展背景 經過前兩個階段的嘗試，更多的企業發現獨立構建大數據平臺與數據倉庫平臺的技術架構，已經無法滿足某些場景下的業務需求。企業在構建數據湖和數據倉庫的同時，通過ETL操作實現數據的匯聚，完成湖倉獨立部署，這就是業內常說的“Hadoop+MPP”模式,我們稱之為湖倉分體模式。湖倉分體模式最大的問題就是數據孤島和業務實時數據分析能力不足，因此面臨著數據多集群冗余存儲、集群規模受 6 限、業務的實時性不足、業務應用開發敏捷需求不足等問題，這些需求和痛點促進了湖倉一體技術的發展。2技術特性 湖倉一體方案應該在數據和查詢層面形成一體化架構，徹底解決實時性和并發度，以及集群規模受限、非結構化數據

13、無法整合、建模路徑冗長、數據一致性弱、性能瓶頸等問題，有效降低 IT 運維成本和數據管理的技術門檻。所以，新時代需求的湖倉一體方案應具備實時處理、數據共享、高并發、云原生等特性。3.階段特點 云的普及讓業務上云成為趨勢，為了實現數據湖的靈活性和數倉的易用性、規范性、高性能結合起來的融合架構，并且保證存儲和計算可以獨立的彈性擴展和伸縮，數據平臺的設計出現了一個嶄新的架構，即存算分離架構。在此階段，Snowflake、Amazon、阿里云、偶數等企業相繼突破了傳統 MPP 和 Hadoop 的局限性，實現了存算分離。從市場發展角度出發，“湖倉一體”架構是技術發展的必經之路，優勢明顯，缺點也同樣突出

14、，而更為先進的“湖倉原生一體”架構在未來將更加契合用戶對于數據價值挖掘的訴求。7 二、云原生湖倉一體方案概述(一)行業用戶數據處理五大難題 2000 年以來，隨著大數據技術的廣泛使用，金融行業的運營管理人員每天都會采用報表數據來指導決策，由于業務的不斷增長，采集的數據復雜度越來越高，管理者希望能第一時間掌握市場動態，以便及時做出有利于業務發展的決策。為了滿足業務應用發展要求，數據處理通常會遇到各種挑戰。數據加工過程中，需要耗費大量時間，完成各種業務數據加工處理和匯總統計；數據開發過程中，需要耗費大量人力，借助各類數據工具，從多個數據源系統中采集搬運數據并進行分析；數據管理過程中，需要充分考慮安

15、全因素，避免由于不同使用者的修改，或者系統故障，造成數據不一致，從而影響數據分析結果；數據應用過程中，需要保障消費者的使用體驗，面對海量的歷史數據，所有的信息查詢都要通過各種條件限制，以控制查詢的數據規模；數據系統升級過程中，需要停止業務操作，影響業務連續性等。我們據此總結出了現階段數據處理瓶頸的五大難題。1.數據處理面臨數據孤島的難題 很多企業的數據平臺都是經過多次系統迭代和技術升級后建設而成的，在這個過程中隨著技術的發展、組織管理結構變化，導致企業的數據平臺往往存在多個數據庫集群，每個數據庫就是一個數據孤 8 島和煙囪，甚至因數據庫產品的擴展性，還可能導致 MPP 和 Hadoop集群建設

16、多套的情況，形成更多的孤島和煙囪。圖 4：數據孤島 這些數據孤島和煙囪的出現在存儲、開發、運維、治理等多個方面帶來了影響。數據存儲方面，多個獨立數據庫集群中都放了同樣的數據，大約可以造成 3 倍-5 倍的數據冗余，相當于占用了大約 3 倍-5倍存儲空間，這就意味著造成了大約 3 倍-5 倍的資源成本的浪費。數據開發方面，多個數據庫集群，意味著，數據平臺整體的架構相對復雜，不同集群之間的時序、數據同步流程多。這種情況會導致數據庫產品技術門檻多，對于技術人員的素質要求高；集群之間需要大量的數據同步，一般情況下同步作業占到總作業量 50%左右，對于一項數據開發的總體工作量大約增加了 1 倍左右。從項

17、目管理的角度看大約增加了 1 倍的成本；同時，作業的鏈路延長，大大降低了數據時效。技術運維方面，和開發面臨的情況基本類似，對于運維人員的素質要求較高，需要精通多個數據庫產品，日常運維管理的數據作業任務也比較多。數據治理方面，基于多份數據進行維護，可能會導致數據不一致，數據質量等問題，數據治理難度大，浪費的成本難以估量。9 2.數據處理面臨性能瓶頸的難題 傳統數據平臺的計算性能不能滿足業務需求，大體上有兩種情況：一方面因數據平臺的數據處理、業務查詢時間長，性能慢，無法滿足業務需求，需要在業務流程和用戶端進行規避，導致用戶體驗很差。另一方面部分企業為了提高性能，在數據平臺之上架設一個或多個內存查詢

18、引擎，這種方式犧牲了 ACID 和兼容性。性能不足的問題影響運營、決策效率、無法支撐業務運行對時延的要求；部分計算引擎為了提升計算效率，犧牲了事務一致性，犧牲語法兼容性；部分計算引擎只支持簡單查詢，缺少復雜關聯分析能力。3.數據處理面臨高并發復雜查詢的難題 隨著移動互聯網的發展，很多業務逐步開放至更多的人員參與，出現了很多需要數千查詢并發的場景，例如：明細數據查詢，數據集市查詢；保險銷售員查詢業績，客戶查詢權益視圖；證券研究員查詢上市公司數據等各類場景。但是傳統數倉、Hadoop 僅支持幾十并發，導致分庫、分表，限制業務部門使用，限制查詢，對很多新型的業務沒有很好的支撐。為了保證各類查詢同時進

19、行，采用很多計算引擎分流的方式實現，如：實時計算、批處理、固定報表、即席查詢等廠家分別由不同計算引擎來支撐，無法統一查詢，數據平臺采用的數據庫產品無法同時支撐多業務場景。4.數據處理面臨實時處理的難題 10 Gartner 定義的實時數據處理的包括三個階段：第一階段，Real-Time Continuous Intelligence：對事件做出實時處理響應，包括指標對比，告警，趨勢分析，自動決策；第二階段，Real-Time,On-Demand Intelligence：生成報告，支持即席查詢，延伸數據探索，記錄操作流程；第三階段，Offline On-Demand Intelligence：

20、離線任務，包括報告，即席查詢，實時決策，建模及長期決策；對應的在實時分析處理中按照事件的發生時間長短可以總結為：事件發生同時的實時流處理、事件發生短時間內的實時按需分析、事件發生后較長時間的離線分析。圖 5：實時分析場景 傳統數據處理平臺不能完全滿足實時數據分析需求，存在以下問題：實時數據與批量數據的關聯查詢，有實時數據與維表關聯查詢，有實時數據與事實數據關聯查詢，離線數據量大現有平臺難以支撐；多庫數據無法實時歸集，按需查詢需求無法滿足；交易型數據庫無法支持頻繁、復雜的查詢，為保證數據庫的穩定，只能限制查詢；現有 11 基于 Flink 和 Kafka 的流處理平臺，不支持數據血緣，不能支持即

21、席按需查詢分析等。5.數據處理面臨資源彈性伸縮的難題 傳統數據平臺因技術架構的局限性，對敏捷彈性資源管理支持度不高，在升級維護時需要暫停服務，對業務造成極大的影響。資源敏捷管理難題基本可以分為敏捷應用響應難題、如何實現資源彈性合理調配使用。敏捷應用響應難題主要體現為：傳統 MPP 上線新應用的資源分配周期長，無法滿足業務端快速試錯、快速布局的訴求；超過集群規模上限時，性能不增反減，約減少 50%以上；集群擴容耗時很長，停機維護影響業務等。資源無法彈性調度，波峰波谷資源不能合理有效分配和使用，主要體現為：在非云環境，資源不能共享，資源以獨占的方式使用，利用率很低；資源不夠時無法彈性擴展，資源空閑

22、時無法分配給需要的用戶，無法做到削峰填谷，提高資源利用率。(二)解決數據處理瓶頸的最佳方案 通過對于現階段數據分析存在的瓶頸和難題進行深入分析，我們發現，為了解決數據孤島、性能不足、高并發、實時處理和資源彈性問題，可以嘗試以下的解決方案：數據孤島 需要數據平臺架構支持存算分離，實現單一數據集群能支持數千上萬節點，這樣避免由于單一集群規模限制產生數據孤島；12 性能不足 大數據平臺的計算引擎相比 MPP 存在較大差距，需要引入基于MPP 技術的高性能解決方案，提升計算引擎的處理能力；高并發 傳統的 MPP 技術或者大數據平臺技術都只能支持數十并發，需要引入多主節點技術實現分析型數據平臺上的高并發

23、，將并發從目前的數十可以提升到數千或者上萬；實時處理 目前的實時處理只能處理實時場景，無法同時處理實時和數據規模比較大的歷史數據相結合的實時業務場景，需要引進支持海量數據下實現高性能高并發以及具備資源隔離的支持多租戶技術的數據平臺，才能滿足所有實時業務場景的需求；資源彈性 當前數據平臺在資源橫向擴展時，無法做到計算和存儲資源的各自獨立擴展，同時，對于資源的使用無法實現根據業務需要進行設置，導致資源利用率不高，使用成本很高，需要引入存算分離的架構，并且支持虛擬計算資源的管理方式，實現業務按需進行計算資源的分配調度管理。同時考慮到以上計算存儲分離、彈性可擴展架構、ACID 特性、SQL 標準支持、

24、高性能并行執行等方面的能力，基于云原生技術架構的云原生湖倉一體產品，可以通過云平臺構建、部署和交付的數據服務，提供可擴展的、高可靠的數據解決方案。1.云原生湖倉一體典型架構 Gartner 認為湖倉一體是將數據湖的靈活性和數倉的易用性、規范性、高性能結合起來的融合架構，無數據孤島。云原生湖倉一體就 13 是將數據湖和數據倉庫兩個平臺合為一個平臺，并依托云原生的特性，支持基于數據湖的普通存儲硬件和存儲引擎以及數據倉庫的多功能高性能分析引擎，實現對海量原始數據（結構化、非結構化、流式數據、圖數據）以及潔凈數據（對原始數據進行治理和分析后的數據）統一存儲、分析、管理，集群可在線擴容到幾千節點。支持數

25、據倉庫的豐富功能及高性能，支持配套的高性能 ETL、數據治理及數據資產管理工具等。支持數據科學和自動化機器學習，支持無代碼/低代碼數據加工，支持自助式 BI。圖 6：云原生湖倉一體典型架構 2.云原生湖倉一體關鍵技術（1）存算分離技術 在云原生數據庫出現之前，由于單機吞吐量和集群網絡帶寬限制等因素，數據庫集群部署都是存儲和計算在一起，讓計算靠近數據，而不是將數據傳輸到計算節點，這種方式可以產生更少的數據遷移，降低機器間、機柜間的網絡帶寬消耗。隨著數據量的增長，無論是計 14 算還是存儲先達到瓶頸，都必須同時對計算和擴展進行擴展，因此就會存在不少浪費，并且擴展需要大量數據移動，非常不方便。計算與

26、存儲的解耦，可以讓我們更加方便的管理計算與存儲資源。在大規模數據處理場景下，管理員可以快速的單獨擴展計算或存儲資源，并且性能可以隨著節點的增加線性增長。存算分離后，數據實現了統一存儲，可以被多種計算引擎所共享。因此，存算分離是湖倉一體平臺必備的技術之一。然而，存算分離也帶來了挑戰，比如存算解耦以后，如何管理計算層與存儲層的映射關系，節點異常處理、如何保證讀寫一致等問題。此外，存算分離需要萬兆甚至更快的網絡帶寬。因此，存算分離架構通常是云原生數據庫的重要特性之一。（2）高性能計算引擎技術 存算分離以后勢必帶來更多的網絡開銷，影響數據庫集群的整體性能。因而需要通過其他方面的增強來彌補這一損耗。其中

27、一個重要的途徑就是通過優化計算引擎來增強性能。采用基于代價的優化器（CBO），通過算法來動態選擇每個 SQL的最優查詢計劃，彈性的執行引擎可以動態調整計算單元，使得資源使用更加合理和高效。在計算層通過使用向量化執行器可以大大提升SQL 的執行速度，由于存算分離會帶來額外的網絡開銷，因此計算層采用分布式的緩存服務，采用基于 LRU 協議的緩存管理機制，用戶還可根據情況動態配置緩存空間的大小，緩存支持使用內存和計算節 15 點的本地磁盤空間。節點之間的通訊協議，改為采用 UDP 的互聯協議，可以大大提升通訊效率。性能的提升意味著在單位時間內云原生湖倉一體平臺可以處理更多的數據。（3）多活主節點支持

28、超高并發 云原生湖倉一體平臺的主節點采用多活主節點集群部署，主節點采用無狀態設計，各主節點之間沒有相互依賴關系，不存儲任何元數據。用戶可以非常方便的對主節點集群進行擴展，以處理更多的連接請求(JDBC/ODBC)。主節點可以在線增減，實現資源的動態調度。例如當用戶請求越來越多時，用戶可以根據情況隨意增加一個或多個主節點，反之則可以減少一個或多個主節點。主節點的動態增減不會影響數據庫的服務。當主節點集群中某個節點出現故障時，也不會影響整個集群的可用性。支持用戶可視化的方式輕松完成擴容。圖 7：多主節點架構（4）元數據集群高可用 元數據集群架構采用 P2P 去中心化完全對等網絡架構，集群內無固定主

29、節點，通過一致性協議算法實現節點的數據同步，當某一節點 16 宕機時，集群內部可自動實現服務的漂移而無須人工干預，實現了集群的高可用。元數據采用多副本機制，均勻的分布在各個節點上，確保了元數據的安全。各個主節點將同時并發連接每個元數據節點，因此，元數據集群內不存在單點瓶頸，實現了元數據讀寫的負載均衡。（5）多虛擬計算集群支持混合負載 在存算分離基礎上，多虛擬計算集群支持對用戶訪問的 CPU 和內存資源的物理隔離。多虛擬計算集群（Virtual Cluster）可以將一個超大規模計算節點根據負載情況劃分為多個虛擬計算子集群。數據庫管理員可通過配置，將用戶與某個 VC 進行綁定。當用戶發起執行請求

30、后，主節點只會調度該用戶對應的 VC 資源來執行，當 VC 資源不夠時，管理員可快速增加從其他 VC 中調度計算資源來給 VC 進行擴容，并且是在線秒級擴容。用戶可根據自己的業務場景劃分多個 VC，來支持不同的業務部門或機構。同時，因為快速的進行資源調度，可以大大提高資源利用率，從而減少硬件資源的投入。圖 8：多虛擬計算集群 17 （6）可插拔存儲框架 可插拔存儲框架實現計算資源可同時訪問不同類型的存儲，如：HDFS 存儲、基于 S3 協議的對象存儲以及分布式表存儲。通過可插拔的存儲框架，可以實現在線的存儲擴容，例如，管理員可以方便的通過配置，新增一套或多套存儲系統，并且這種異構的存儲對于用戶

31、訪問是透明的，即用戶無需知道數據存放在哪種存儲上，而是直接通過表名讀寫數據?？刹灏未鎯蚣苓€可以支持二次開發，用戶可通過二次開發使得計算引擎對接未來新出現的存儲系統。如下圖所示，通過可插拔存儲框架的支持，使得云原生湖倉一體平臺可以對接多套 HDFS，并且對用戶無感。圖 9：可插拔存儲架構（7）多虛擬存儲集群實現磁盤 IO 的隔離 上述的可插拔存儲框架實現了計算資源與存儲的對接，但是在實際使用中，依然存在著存儲中磁盤 IO 資源的競爭，因此多虛擬存儲的功能實現類似于 HDFS 的聯邦功能。多虛擬存儲集群支持用戶將多 18 套 HDFS 集群或分布式表存儲集群劃分為一套虛擬存儲集群（Virtual

32、 Storage Cluster）。開發人員在進行數據建模時，可以根據磁盤 IO 的負載情況，將不同負載的表建在不同的 VSC 中，就可實現負載的隔離，用戶在使用時不會感知 VSC 的存在，并且 VSC 與計算階段沒有綁定關系，可以被任意的計算資源訪問，保證了數據的共享。同時，云原生湖倉一體平臺根據使用量自動將不同的表分布到統一 VSC 中的不同 HDFS 集群或分布式表存儲集群中，從而實現數據的均勻分布?；谶@個特性，用戶在進行存儲擴容時就實現在線的秒級擴容而無須進行數據重分布。當某一 VSC 存儲空間不夠時，用戶可以新部署一套 HDFS 集群加入到 VSC 中，即實現了存儲空間的擴容，又無

33、須進行人工干預。圖 10：多虛擬存儲集群（8）高性能分布式表存儲支持實時數據讀寫 在實時場景中，數據往往是逐條進行插入、更新或刪除，這種對數據的操作特性與交易場景非常接近，而 HDFS 或對象存儲僅適合對 19 數據進行批量操作，并且原生并不支持數據的更新，無法滿足實時場景的業務需求。因此，云原生湖倉一體平臺需要引入分布式表存儲支持高并發、事務以及提供索引，并且原生支持數據更新和刪除。在云原生湖倉一體平臺的架構中，分布式表存儲與HDFS、對象存儲平行，是能夠獨立運行的存儲系統，不依賴第三方組件。分布式表存儲的主要特性有：采用完全點對點(P2P)無中心分布式存儲（相比主從架構更容易管理更容易擴展

34、）結構化數據定義存儲（不是簡單鍵值對形式存儲）支持數據的增刪改查（提供真正的 INSERT UPDATE DELETE功能）支持基于 Raft 協議數據復制實現數據存儲和訪問服務的高可用 支持基于多版本 MVCC 的分布式事務特性 目前提供針對分析型負載的高性能數據查詢能力（行列混合存儲格式）支持數據索引功能（包括主鍵索引，非主鍵索引）整合數據預處理技術提升數據查詢性能（非純粹的數據存儲實現，具有內建計算能力）便捷的集群動態擴展 自動集群容錯和負載均衡能力 20 圖 11：高性能分布式數據讀寫 從讀寫性能的角度比較，分布式表存儲的性能優于 HDFS，HDFS的性能優于對象存儲。因此，在實際使用

35、中通常會把 T+0 的實時數據寫入分布式表存儲，T+1 的批量數據寫入 HDFS，而對象存儲由于更加低廉，但是性能最慢，所以一般只用來存儲三年以上的歷史歸檔數據。從用戶視角看，開發人員需要基于不同使用場景把不同的表建立到不同的存儲中，在之后的使用中則不再感知異構的存儲，也就是說用戶直接通過表名即可查詢各種類型存儲中的數據，也可以把存儲在不同類型存儲中的數據進行關聯查詢、計算、比較等不同的操作。如下圖所示：21 圖 12：高性能分布式 SQL 查詢（9）Hadoop 生態兼容能力 云原生湖倉一體平臺可以直接使用 Hadoop 生態普遍使用的HDFS 來作為數據存儲，同時存儲格式使用開源社區比較通

36、用的 orc和 Parquet 格式，此外還支持 CSV、TEXT 等類型。支持直接讀寫 Hive數據，無須預先創建外表，更無需搬遷數據，云原生湖倉一體平臺管理的數據表也同樣可以被 Hive 訪問。在實時場景下，源數據主要有兩類：一類是流計算引擎處理的過程或結果數據，另一類是通過 CDC 工具采集的實時變化的數據。云原生湖倉一體平臺支持這兩類數據的同時讀寫。例如：Flink 可直接連接分布式表存儲，將流處理結果直接寫入分布式表存儲中，用戶可使用 SQL 直接查詢。此外，云原生湖倉一體平臺支持使用 Hudi、Iceberg 開源數據湖格式，用戶也可以選擇將實時數據直接寫為 Hudi 22 或 I

37、ceberg 格式，這樣可以將數據統一存儲到 HDFS 中，實現數據的物理統一。3.云原生湖倉一體六大特性 對于上述云原生湖倉一體的關鍵技術，我們從用戶角度概括成六個代表字母的 ANCHOR 特性。A(All Data Types:支持多類型數據）、N(Native on Cloud:云原生）、C(Consistency:數據一致性）、H(High Concurrency:超高并發）、O(One Copy of Data:一份數據）、R(Real-Time:實時 T+0）。支持多類型數據（All Data Types,Structured&Unstructured）：支持關系表、文本、圖像、視

38、頻等結構化數據和非結構化數據存儲。云原生（Native on Cloud）：適合云環境，自由增減計算和存儲資源，按用量計費，節約成本，不再有數據孤島存在。數據一致性（Consistency）：通過完善的事務機制，保障不同用戶同時查詢和更新同一份數據時的一致性。超高并發（High Concurrency）：支持數十萬用戶使用復雜分析查詢并發訪問同一份數據。一份數據（One Copy of Data）：所有用戶（BI 用戶、數據科學家等）可以共享同一份數據，避免數據孤島。實時 T+0（Real-Time）：通過全量數據 T+0 的流處理和實時按需查詢，滿足基于數據的事前預測、事中判斷和事后分析。2

39、3 (三)云原生湖倉一體主要技術路線 1.主要技術路線對比分析 目前，常見的湖倉一體技術方案主要有兩大類型：基于傳統Hadoop 架構的方案，以及基于云原生數據倉庫架構的方案?；趥鹘y Hadoop 的方案主要從事務特性出發進行優化，基于HDFS 或 S3 實現一個支持事務的存儲層，其他方面與 Hadoop 區別不大。而云原生數據倉庫，其存算分離特性更具有技術前瞻性，該架構將是未來的發展趨勢。維度維度 參數參數 云原生湖倉一云原生湖倉一體平臺體平臺 傳統數據倉庫傳統數據倉庫平臺平臺 傳統數據湖平傳統數據湖平臺臺 技術先進性技術先進性 技術架構 云原生、存算分離 非云原生、存算耦合 非云原生、存

40、算耦合 性能性能&并發并發 性能 高 中 低 并發 高 低 低 功能功能 支持事務 完整支持事務ACID 完整支持事務ACID 事務支持差 集群規模 100000 1000 SQL 標準 完善兼容 SQL標準 完善兼容 SQL標準 部分兼容 SQL 數據類型 結構/半結構/非結構化 結構化 結構/半結構/非結構化 存儲引擎 可插拔存儲：HDFS/S3/Magma 本地表私有存儲 HDFS/S3 24 存儲格式 ORC，Parquet，Hudi 等 私有格式 ORC，Parquet 全實時 支持 否 否 湖倉一體 支持，OushuDB 支持 HTAP 否 否 開發開發 數據共享 共享同一份數據

41、數據孤島、共享困難 數據孤島、共享困難 數據治理 簡單 復雜 十分復雜 實施難度 低 低 高 運維運維 運維難度 低 低 高 2.云原生湖倉一體的建設路徑 從云原生湖倉一體平臺的建設方式上，企業可以結合業務情況、已有數據平臺情況等方面出發進行建設路徑的規劃，主要有以下三種建設途徑：從數據倉庫到云原生湖倉一體 企業目前數據類應用主要集中在數據倉庫，而且總體數據量也不大的情況下，可以考慮從數據倉庫向數據湖方向建設，最終實現云原生的湖倉一體平臺建設。首先從數據倉庫開始進行技術平臺的升級，選擇云原生的數據庫產品進行數據倉庫的遷移替換，將底層“倉”的存儲和“湖”的存儲實現數據打通，建立統一的數據模型。從

42、數據湖到云原生湖倉一體 一般情況下，因數據湖中的數據體量較大，為了避免數據的搬遷采用從數據湖到湖倉一體的建設方式，最終實現云原生湖倉一體平臺。25 在現有的數據湖上進行技術平臺升級，在湖上增加具備數據倉庫計算能力的組件并將新的業務應用部署到湖倉一體平臺上，逐步將原有的數據倉庫和集市的數據和應用都遷移到湖倉一體平臺上。數據湖和數據倉庫融合建設 湖倉融合的建設方式要求：不再有獨立的數據湖和數據倉庫，湖倉融合為一個產品的解決方案，底層的數據產品均具備云原生特性、計算存儲分離彈性可擴展架構、強 ACID 特性、強 SQL 標準支持、高性能并行執行能力。首先，進行平臺技術能力升級，將原來的數據湖和數據倉

43、庫底層的數據產品的元數據打通，共享一份元數據，數據湖和數據倉庫共同使用一個入口，并保證強事務一致性。其次，構建統一的數據模型，將數據湖和數據倉庫的數據納入統一的數據模型進行管理，并只保留一份。最后，完善數據處理工藝，制定統一的數據接入標準，數據處理工序，數據存儲原則等。最終完成云原生湖倉一體平臺的建設。(四)云原生湖倉一體方案應用價值 1.用戶體驗的提升 云原生湖倉一體平臺能夠大大提升用戶的數據服務體驗：管理人員：一個湖倉一體的平臺可以統一運營企業內所有應用的數據，不需要單獨考慮不同數據平臺產品的部署、招標采購、擴容等問題，提升了管理決策的效率，降低了管理運營的成本。26 運維人員：僅需要運維

44、管理一個平臺，技術架構簡潔，運維門檻降低。而且湖倉一體平臺存算分離的架構，支持計算資源與存儲資源的單獨橫向擴容和縮容，給日常的升級維護帶來極大的便利。業務人員：湖倉一體平臺實現超高的并發，一個平臺支撐所有數據存儲、計算、分析的需求，并提供面向業務部門的自助數據分析服務，在實際工作中不需要切換平臺進行業務實現；數據底層共用一份數據，用戶之間可以很方便地共享數據。2.數據平臺運營成本下降 云原生湖倉一體平臺支持資源物理隔離，按照業務需求分配資源，大大提升資源利用率、硬件資源池按需建設，采購規模下降、折舊減少。通過湖倉一體平臺可以有效降低數據平臺運營成本，主要體現在以下幾方面：湖倉一體平臺完成了數據

45、倉庫、數據集市和數據湖的數據整合，實現一份數據，融合共享，避免了多份數據存儲，可以節省大約 3 倍-5 倍存儲空間和資源成本。平臺基于一份數據，避免了不同數據平臺間的數據傳輸和拷貝，一般在數據處理任務中數據同步作業占到總作業量 50%左右。開發工作量可以節省 1 倍左右、平臺算力資源節省 1倍左右；同時，避免了作業的鏈路延長，數據時效降低。27 湖倉一體平臺基于云平臺進行部署，不再依賴底層單節點的計算和存儲資源，由云平臺統一進行合理的安排和管理。不同配置的服務器都可以通過云平臺提供算力資源和存儲資源。3.管理、開發和運維的效率提升 云原生湖倉一體平臺啟用以后，可以大大提升管理，開發，運維和業務

46、部門的協同工作效率，降低管理成本，具體體現在以下方面：管理人員相比原來的平臺可以近乎實時的了解企業業務現狀，第一時間做出決策；運維人員僅需維護和管理一個平臺，極大地減少了運維壓力和成本。湖倉一體平臺能夠超高并發的處理多業務場景，不需要額外學習其他產品，有效地降低了技術開發門檻。平臺基于一份數據，還降低了數據治理難度。降低了數據治理類項目成本投入；避免了數據同步作業開發，開發工作量節省 1 倍左右、減少 1 倍左右的項目成本；同時，作業的鏈路延長，數據時效降低。云原生湖倉一體平臺具備的實時特性支持業務創新，增強用戶體驗，可以讓用戶與金融行業的企業之間互動更加頻繁，帶來最佳用戶體驗，形成業務發展的

47、新模式，帶來新價值。28 三、云原生數據湖倉生態現狀(一)國內湖倉生態版圖 當前，湖倉一體技術架構正處于發展早期，頭部企業紛紛嘗試構建自己的湖倉一體數據平臺。以金融行業為例，“湖倉一體”的應用覆蓋銀行、券商、保險等細分領域，可以幫助企業應對數字化轉型過程中的創新難題。圖 13：國內湖倉生態版圖 2020 年，大數據 DataBricks 公司首次提出了湖倉一體（Data Lakehouse）概念，希望將數據湖和數據倉庫技術合而為一，此概念一出就得到眾多廠商的推崇。湖倉一體技術依托硬件層提供的計算、存儲、網絡能力，實現數據采集、匯聚、計算、分析，是整個“湖倉一體”的生態基石。湖倉一體通過基礎軟件

48、層的技術創新，打破了數據湖與數據倉庫在存儲、計算、網絡三個層面割裂的體系，并將數據湖的靈活性、生態豐富能力與數據倉庫的企業級部署能力進行融合，構建了數據湖和 29 數據倉庫相融合的數據管理平臺?！昂}一體”繼承了數據倉庫的數據處理和管理優勢，打通了數據湖和數據倉庫兩套體系，讓數據和計算在湖和倉之間自由流動，既能面向業務實現高并發、精準化、高性能的數據實時查詢服務，又能承載分析報表、批處理、數據挖掘等分析型業務。軟件層面，企業在數據接入、數據存儲、數據管理、數據分析等不同技術方向做出了新的嘗試。在服務層面，根據不同行業場景的具體應用需求，各大廠商紛紛為用戶提供行業定制化的解決方案，幫助企業解決數

49、據孤島、實時數據分析、高性能處理、高并發查詢、資源彈性伸縮等難題。為企業提供安全可靠的“湖倉一體解決方案”，構建融合創新的新一代數據平臺。(二)國際湖倉典型應用 1.Lambda 數據框架 Lambda 數據處理框架由 Storm 的作者 NathanMarz 首次提出，目標是設計出一個能滿足實時大數據系統關鍵特性的架構，整合離線計算和實時計算，讀寫分離和復雜性隔離等，可集成 Hadoop，Kafka，Storm，Spark，Hbase 等各類大數據組件。Lambda 架構通過把數據分解為服務層（ServingLayer）、速度層（SpeedLayer，亦即流處理層）、批處理層（BatchLa

50、yer）三層來解決不同數據集的數據需求。在批處理層主要對離線數據進行處理，將接 30 入的數據進行預處理和存儲，查詢直接在預處理結果上進行，不需再進行完整的計算，最后以批視圖的形式提供給業務應用。圖 14：Lambda 架構邏輯圖 由于服務層通常使用 MySQL，HBase 等實現，供業務應用查詢使用，此處的批視圖就是 MySQL 或 HBase 中的表，這些表存儲著批處理作業產生的結果；流處理層主要是對實時增量數據進行處理，新數據通過流計算不斷的更新實時視圖，例如在實時大屏場景，實時視圖通常就是 MySQL 中的表信息，流處理作業在新數據到來后不停更新實時視圖提供給到業務層；服務層主要是響應

51、用戶的請求，根據用戶需求把批處理層和流處理層產生的數據合并到一起得到最終的數據集。圖 15：Lambda 架構部署圖 2.Kappa 數據框架 Kappa 架構在 Lambda 架構的基礎上移除了批處理層，利用流計算的分布式特征，增加流數據的時間窗口，統一批處理和流處理，處理后的數據可以直接提供至業務層使用。因為在 Kappa 架構下，作業 31 處理的對象是所有歷史數據和當前數據，其產生的結果我們稱之為實時批視圖（Realtime_Batch_View）。圖 16：Kappa 架構邏輯圖 在 Kappa 架構中，輸入數據在采集后通常存儲在 Kafka 中，在流處 理 程 序 需 要 升 級

52、迭 代 時，會 啟 動 一 個 新 版 本 作 業（StreamJob_Version_N+1）,該作業會從 Kafka 中讀取所有歷史數據和新增數據，直到追上舊版本作業（StreamJob_Version_N），舊的作業版本才會停止。Kappa 架構通過這種方法升級流處理程序，架構的流處理系統通常使用 SparkStreaming 或者 Flink 等實現，服務層通常使用 MySQL 或 HBase 等實現。圖 17：Kappa 架構部署圖 四、云原生湖倉一體實踐案例 當前各行各業的云原生湖倉一體建設剛起步，本次白皮書重點介紹金融行業場景，選擇了中國建設銀行、中國人壽、中信建投等金融機構，分

53、析最近 3 年在云原生湖倉一體技術上的研究成果和實踐探索。當前，金融行業普遍存在數據倉庫和大數據平臺兩套數據平臺各司其職的情況。在湖倉一體建設思路上，由于歷史包袱沉重，多數企 32 業規劃將兩套數據平臺體系通過統一的云平臺以及軟件工具實現一定程度的資源共享和數據互訪。但是，數據平臺的五大難題依然存在。從云原生湖倉一體建設的六大特性來看，企業選擇轉型為云原生湖倉一體可以為企業帶來巨大的經濟效益和社會效益。因此，我們建議企業可以將云原生湖倉一體平臺的建設確定為企業數據平臺建設的主要方向。在具體建設方法上，為了保護企業多年來的投資價值，保證數據平臺的平穩過渡，可以考慮將業務部門的新業務、傳統領域中的

54、創新業務，以及傳統業務中對性能要求高、對數據共享能力要求高的業務遷移到新建的云原生湖倉一體平臺上，以實現企業云原生湖倉一體平臺價值的最大化，并在后續的運營中形成符合企業獨有特色的云原生湖倉一體平臺。(一)中國建設銀行從湖到湖倉一體的演進之路 中國建設銀行在多年的數據平臺建設中，逐步匯聚了多種數據平臺的技術棧，積累了 PB 級的海量數據，同時也帶來了數據冗余、加工流程復雜、數據服務效率無法滿足業務需求等一些亟待解決的問題。建行于 2019 年提出了關于“數據供應鏈的時效性和可用性”的要求，確定了加快推進“數據湖建設”的決議。同年，啟動了數據湖建設技術路線的研究工作，并確定了云原生、高性能、穩定安

55、全、自主可控的技術原則。33 在技術選型上，建行對比了 Apache hudi、Apache HAWQ 等多種開源的數據湖方案。經過多輪全面的測試和對比確定了以 Apache HAWQ 作為建行未來湖倉一體建設的基礎技術方案，打造建行自主可控的云原生數據庫產品 CHAWQ 作為建行湖倉一體數據平臺建設的整體解決方案。2020 年隨著 CHAWQ 產品在行內部署上線，建行啟動將多個業務應用遷移到湖倉一體平臺上，由此相比原來的業務運維工作，大大降低了每天的數據搬遷工作，減少了數據冗余，降低了運營成本。由此，建行基于云原生數據庫產品 CHAWQ 走出了一條適合建行發展的湖倉一體技術發展之路。圖 18

56、：建設銀行湖倉一體架構 截至 2022 年底，建行湖倉一體平臺可供數據湖上數百個分析類應用場景使用，包括營銷、風險管理等，支撐了萬億級別的交易明細 34 數據查詢在線應用，毫秒級響應延遲。數據冗余減少了大約 2 倍，作業數量減少了近十萬，大大降低了數據平臺運營成本。(二)中國人壽湖倉一體總體規劃的研究之路 中國人壽作為國家大型金融保險企業，2018 年集團公司合并營業收入 7684 億元，合并保費收入 6463 億元，合并總資產近 4 萬億元。集團公司下設 8 家一級子公司、1 家全國性股份制銀行，業務范圍全面涵蓋壽險、財險、企業和職業年金、銀行、基金、資產管理、財富管理、實業投資、海外業務等

57、多個領域多家公司和機構。集團目前采用了 SQLSERVER 數據庫采集各個省級分公司的數據，并建立了數據倉庫平臺用于報表的匯總統計分析。業務創新的需求驅動下，國壽推出用戶權益視圖的數據服務，對數據平臺的實時采集能力、海量歷史數據的流批一體實時計算能力，以及高并發高性能的秒級響應查詢能力提出了更高的技術能力要求。經過充分的研究和必選，最終確定了云原生湖倉一體的技術方向，通過與相關廠商開展深入探索和測試，對未來云原生湖倉一體的平臺建設進行了架構規劃設計，并從業務角度進行創新設計，逐步發揮云原生湖倉一體平臺在業務領域的巨大價值。(三)中信建投數據倉庫與數據湖的融合探索之路 中信建投證券在“科技賦能、

58、運營升級，以數字化轉型助推客戶服務體系建設”的戰略目標指引下，持續進行數據平臺的升級和建設，逐步建設了基于 GP 的數據倉庫、基于 Hadoop 的數據湖和基于 35 Flink+kafka 的實時數倉，支撐了公司從各業務線到管理的所有應用。然而，由于底層技術的局限，導致數據倉庫與數據湖的建設較為割裂，平臺內存在多個數據孤島，造成大量的數據冗余，從而不斷推升了運營成本。同時分散的數據也給數據管理帶來了巨大的挑戰，為了維護數據的質量通常需要花費大量的人力和物力成本，并且收效甚微，數據質量難以保障。進入 2022 年，中信建投緊跟國家信創戰略的發展方向，使用國產的云原生數據庫替換現有數據倉庫集群，

59、實現數倉應用的平滑過渡，由于云原生數據庫可直接訪問并使用數據湖進行數據存儲，從而實現了數據倉庫與數據湖的完美打通，業務數據不再分別存儲，而是統一存儲，數據應用可根據業務需求選擇使用 SQL 引擎、機器學習引擎或流處理引擎來加工處理所需要的數據，各引擎之間可共享一份業務數據，數據不再需要跨集群流動，從而大大增加了數據處理的效率，同時也減少了數據冗余。下一步，中信建投證券將繼續探索數據倉庫與數據湖的融合，優化數據開發體系，縮短數據加工鏈路，提升數據供給效率，從而加速數據這一生產要素在企業內部的應用和流動。36 圖 19：中信建投湖倉融合架構 五、總結與展望 歷經多年發展，云原生技術生態日趨完善，行

60、業用戶接納度急速提升，資本市場熱潮涌動。中國信息通信研究院數據顯示，2021 年我國公有云 IaaS 市場規模達 1614.7 億元，同比增長 80.4%；PaaS 市場規模達 196 億元，同比增長 90.7%。SaaS 市場規模達 370.4 億元，同比增長 32.9%?？梢灶A見我國云原生產業即將進入高景氣周期。在大數據領域，隨著容器、微服務、無服務器、服務網格等技術的發展成熟，云原生的技術價值已經得到了行業的充分認可，為了滿足大數據時代快速變化的用戶需求，機構需要充分利用云原生能力實現數據系統的“云原生”轉型?；谠圃夹g實現的湖倉一體解決方案，憑借存算分離、彈性擴縮、統一編排、靈活調

61、度、無服務化等特性，為數據價值的挖掘提供便捷部署和管理的同時，更可以實現海量數據的高效存儲、便捷訪問、決策分析，將成為企業數字化轉型和創新發展的重要基石。37 附錄：湖倉一體典型解決方案 華為云華為云 FusionInsightFusionInsight 華為云 FusionInsight 智能數據湖涵蓋了分布式存儲、大數據、數據倉庫、數據治理等方面,主要基于 Lakehouse 湖倉一體架構，實現存算分離和多樣化數據分析,基于相同架構可以同時支持 SQL、BI 和 AI等不同場景。圖 20：華為云 FusionInsight 全景圖 華為云 FusionInsight 基于云原生數據湖 MR

62、S、數據湖探索 DLI、云數據倉庫 GaussDB、云數據遷移 CDW、數據接入服務 DIS、對象存儲 OBS，以及數據湖治理中心 DGC 和數據可視化 DLV 等服務，實現一站式大數據平臺、全托管大數據服務、數據治理、數據遷移和實時處理等場景需求，具有流批交互式一體、千萬級 TPS、毫秒級隨機讀寫、百萬并發等優勢。38 華為云 FusionInsight 采用計算和存儲分離架構，支持按需擴縮，資源靈活配比，可自由選擇鯤鵬、x86、AMD 等異構算力。同時，具有統一的數據安全保護中心和完備的隱私保護機制，讓數據使用安全、合規，讓數據流通可信、可審計；多元分析、多源接入、統一存儲和統一管理，簡化

63、大數據系統復雜性，提升面向未來演進的靈活性。阿里云阿里云 MaxComputeMaxCompute MaxCompute是 適 用 于 數 據 分 析 場 景 的 企 業 級SaaS（SoftwareasaService）模式云數據倉庫，以 Serverless 架構提供快速、全托管的在線數據倉庫服務，消除了傳統數據平臺在資源擴展性和彈性方面的限制，最小化用戶運維投入，使用戶可以經濟并高效地分析處理海量數據。隨著數據收集手段不斷豐富，行業數據大量積累，數據規模已增長到了傳統軟件行業無法承載的海量數據（TB、PB、EB）級別。MaxCompute 提供離線和流式數據的接入，支持大規模數據計算及查

64、詢加速能力，提供面向多種計算場景的數據倉庫解決方案及分析建模服務。MaxCompute 還可以提供完善的數據導入方案以及多種經典的分布式計算模型，用戶不必關心分布式計算和維護細節，便可輕松完成大數據分析。MaxCompute 適用于 100GB 以上規模的存儲及計算需求，最大可達 EB 級別，并且 MaxCompute 已經在阿里巴巴集團內部得到大規模應用。MaxCompute 適用于大型互聯網企業的數據倉庫和 BI 分析、網 39 站日志分析、電子商務交易分析、用戶特征和興趣挖掘等。詳細發展歷程、產品榮譽及客戶案例請參見發展歷程和客戶案例。圖 21：MaxCompute 的產品架構 MaxC

65、ompute 還深度融合了阿里云如下產品：DataWorks基于 DataWorks 實現一站式的數據同步、業務流程設計、數據開發、管理和運維功能。機器學習 PAI基于機器學習平臺的算法組件實現對MaxCompute 數據進行模型訓練等操作。QuickBI基于 QuickBI 對 MaxCompute 數據進行報表制作，實現數據可視化分析。偶數偶數科技的云原生湖倉一體平臺科技的云原生湖倉一體平臺 SkylabSkylab 偶數科技推出的湖倉一體解決方案，基于新一代云數據平臺Skylab、云數據庫 OushuDB 等產品，為用戶提供極速性能、彈性伸縮、計算資源按需分配、全量數據單一存儲、混合負載

66、等相關能力。偶數科技的湖倉一體方案采用了 Omega 全實時數據處理架構，其能夠為用戶提供批流一體處理能力，基于目前全球最快的新一代云數據 40 庫OushuDB，可以實現PB級大數據交互式查詢；將計算與存儲分離，讓計算集群之間數據可以方便共享；彈性擴展架構，可以擴張到上千節點；其支持 Hadoop 生態，用戶可以快速實現擴展；數據管理平臺Lava 可以實現統一數據資產管理、統一數據標準、統一數據服務、統一機器學習及深度學習建模，這些技術特點使得各種復雜的金融業務場景的數據處理通過湖倉一體平臺實現最佳用戶體驗，并實現業務快速增值和業務的持續創新。圖 22：偶數科技 Skylab 湖倉一體解決方案架構