多源異構數據爆炸式增長帶來數據沼澤、信息孤島等問題，導致無用數據和陳舊數據產生，而數據湖憑借原始格式存儲、數據存儲類型多樣和開放訪問等優勢解決了數據存入問題，但其缺乏事務管理支持能力、數據治理能力，從而限制了數據產出。因此，企業多以將數據提取/加載/轉換（ELT）到數據湖后再提取/轉 換/加載（ETL）到數據倉庫中的方式打通湖倉之間管道以同時獲取二者優勢，但這種二層架構存儲成本高、數據一致性和可靠性不足、對高級分析的支持有限。在此基礎上，業界提出湖倉一體（lakehouse），在數據湖上添加高級管理層具化數據倉庫功能，實現多元化數據存儲、存儲計算資源分離、事務管理支持、豐富場景分析應用等優勢組合。
當前少數企業已面向業務需求實施湖倉一體解決方案，但仍存在功能不完善、架構不通用、治理不成熟、數據難共享、系統難擴展等挑戰。為此，本文從數據治理的視角出發，基于數據倉庫、數據湖、湖倉一體三代數據平臺的差異性，分析湖倉一體面臨的挑戰，提出分布式湖倉一體架構，并綜合當前研究構建靜態湖倉一體功能模塊及動態流批一體數據流轉過程，形成具有一定可行性、通用性和可擴展性的湖倉一體架構體系，以支持企業決策。Databricks公司于2020年率先提出湖倉一體概念，并將其描述為“一個新的、開放的數據管理架構，將數據湖的靈活性、成本效益和規模與數據倉庫的數據管理和事務管理結合起來”；Armbrust等將其定義為“基于低成本和可直接訪問的存儲數據管理系統，同時具備傳統分析型數據庫管理系統的管理和性能特征，如事務管理、數據版本、審計、索引、緩存和查詢優化”。目前并無對湖倉一體的統一且成熟的定義，相關研究多引用Armbrust等的說法。國外學者分別定義了自下而上［數據源/數據湖/元數據、緩存和索引層/應用程序編程接口（API）層/消費用例］、自上而下（數據源/采集過程/原始數據開放格式存儲并治理/開放API/消費用例）、自左到右（數據源/存儲層/計算層/API層/消費用例）的湖倉一體架構，雖表述存在差異，但提出的湖倉一體架構有相似的5個組成部分：數據源、數據存儲、計算層、API層以及消費用例。Armbrust等明確將數據存儲在數據湖中以強調湖倉一體滿足不同類型數據的開放格式存儲需求。Microsoft Azure、Databricks等公司的湖倉一體架構則更為重視對存儲對象的區域劃分：青銅區（原始數據采集和保留）、白銀區（過程數據過濾、清洗和增值）和黃金區（業務數據匯總）。數據倉庫、數據湖和湖倉一體之間的差異（見表1）主要體現在以下幾點。（1）數據類型：數據倉庫內部高度結構化且多為關系型數據庫，一般只支持在入倉前完成處理工作的結構化數據存儲；數據湖可包容開放的數據類型，但其主要存儲原始格式的數據，數據加工處理屬于額外工作；湖倉一體存儲所有類型的已處理和原格式數據。 （2）采集過程：數據倉庫的寫時模式需在數據入倉前預先建模，并按照既定的ETL模式，以專屬格式導入；數據湖的讀時模式在數據入湖后按需定義架構，湖中數據以開放格式存在以適應多變的業務需求；湖倉一體同時支持預定義數據和開放數據導入以及需求導向的數據加工轉換。 （3）訪問方式：數據倉庫內的數據訪問以SQL（Structured Query Language）為主，用戶可以獲取具有專屬格式的數據；數據湖和湖倉一體配置大量開放API，可支持對數據的直接讀取，讀取方式包括SQL、 R、Python等語言，湖倉一體同時支持原格式和處理后數據的訪問。 （4）可靠性和安全性：數據倉庫發展較為成熟，基于其高度結構化的管理能力，可實現高質量和安全性的數據存儲；數據湖內部數據具有多源異構性，尚未形成有效治理策略，易導致數據沼澤，這也是其當前面臨的最大挑戰；湖倉一體在湖存儲機制上添加數據倉庫管理功能和數據安全保障機制，可顯著提高數據可靠性和安全性。（5）適用場景：數據倉庫適用于BI（Business Intelligence）、SQL應用和報告等；數據湖適用于數據科學和機器學習，二者僅支持有限應用場景；湖倉一體可同時滿足SQL分析需求和數據科學、機器學習等高級分析需求，且支持直接在原始數據上應用各類分析工具，以及對流數據的持續處理和實時分析。盡管湖倉一體可以實現對數據湖和數據倉庫優勢的有機結合，但依然存在以下挑戰。（1）單體架構需擴展：湖倉一體仍是一種綜合數據倉庫、數據湖、Delta Lake、Spark等技術的單體架構，存在可擴展性不足、管理成本高等問題。數據網格是Dehghani于2019年提出的分散架構模式，融合了分布式領域驅動、自助平臺設計、數據產品化以及聯合計算治理思維。區別于微服務，數據網格專注于數字工程而非軟件工程，將其分布式領域驅動概念抽象化，以支持湖倉一體擴展。（2）架構體系需完善：相關企業湖倉一體架構多以特定業務為導向而不具有通用性，現有研究尚未形成完善的架構體系，存在缺乏完整數據生命周期過程、對存儲對象定義不明確、數據治理能力需優化、支撐應用軟件技術需補充等問題。（3）領域數據需共享：當前企業數據多由中央數據團隊集中統一管理，各業務領域間缺乏高效數據共享機制，易形成數據孤島。領域數據專業化管理并自主共享更符合海量數據環境下的數據治理愿景。為此，針對湖倉一體面臨的挑戰，在解耦海量數據資源并形成分布式湖倉一體架構基礎上，分別構建靜態湖倉一體功能模塊以完善化、合理化湖倉一體系統中各功能組件構成，以及動態流批一體數據流轉過程，這一過程貫穿數據采集、存儲、處理、分析等數據生命周期。分布式湖倉一體按業務領域劃分海量數據資源，由熟悉業務的領域團隊獲取相關數據并履行管理義務，以降低數據集中化治理難度并提高治理效率，其優勢如下：通過調整領域結構來應對不斷變化的數據環境和多元化業務需求，避免企業“牽一發而動全身”；各領域按需部署湖倉一體功能模塊以支撐數據采集、存儲、處理、分析等數據生命周期過程，脫離中央數據團隊而自主發布數據訪問請求并有效共享；中央和領域團隊協同發布聯合數據治理策略并參與治理過程，既確保企業層面數據治理的可持續和有效性，又適應不同業務領域層面治理過程的獨特性、靈活性，并最終實現共同戰略目標下治理結果的一致性。分布式湖倉一體架構（見圖1）由中央發布網格目錄、聯合數據治理標準并提供相關基礎設施，通過業務解耦定義分布式領域節點（領域1、領域2、…、領域n），對于不斷擴展的數據源、用例或訪問類型只需增加相應領域節點，每個領域獨立治理和維護，通過端到端完備的數據服務確保數據可訪問和調用。各領域湖倉一體可擁有獨立的數據目錄，網格目錄鏈接所有節點并獲取完整元數據信息，是用于發現不同節點中可用數據元素的主目錄，各節點通過數據共享服務和網格目錄實現跨領域數據訪問。基于湖倉一體功能模塊和流、批數據流轉過程需要搭建基礎設施，各節點通過本地實施的物理服務器、虛擬機和容器或云服務自動部署技術支撐組件，避免重復建設。應用分布式領域驅動概念，將企業業務域解耦并映射到數據視角，再將數據域解耦以消除冗余?？筛鶕髽I實際業務和組織分類來定義領域，例如某個產品組、獨立組織實體或特定業務流程都可以作為域，更具系統性的方法是將數據域劃分為3種類型：源數據域（以下簡稱“源域”）、聚合數據域和消費者/用戶數據域。源域與處于原始狀態的數據源（例如業務系統、社交媒體等）一致，此類數據尚未用于擬合或建模而直接反映當前業務事實，多以業務域事件形式存在，其依據分布式日志或易于消費的歷史片段（在密切反映業務域變化的間隔時間段內進行匯總）。源域內數據的建模和訪問并非直接在數據源上進行，而是在湖倉一體中存儲和結構化以便更好地理解和訪問報告、機器學習訓練和各類非交易性工作負載。此外，數據源變化與源域內數據變化的頻率可能不一致，二者擁有不同的生命周期。企業范圍內業務域與數據源系統可能并非一對一映射，通常許多源系統可為屬于一個共享業務域的部分數據提供服務，因此可能有眾多與源系統對應的數據，需要將其匯總到一個統一的聚合數據域中。例如，通過營銷和銷售數據生成用戶畫像，這個過程需要由多個源域內數據組成的長期聚合數據以形成對用戶的整體看法。與源域內數據相比，消費者/用戶（例如數據科學家、數據分析師）數據域內的數據擁有不同的性質，通常通過處理、加工、轉換等將源域中的事件轉變為適合特定用例的結構和內容。例如，數據科學家從源域內數據中提取某些特征和附加信息，一旦這些特征（屬性）被提取便可作為與用戶數據相一致的領域數據被維護和共享，以訓練情感分析模型或其他相鄰領域模型。分布式領域驅動剝離中心節點，各領域湖倉一體提供數據共享服務，且任意領域間可以共享數據，跨領域湖倉一體數據共享過程如下：各節點數據發布者發布元數據到數據目錄中，管理員審查數據治理規范后錄入，同時在網格目錄中更新元數據信息。當某一節點產生數據需求，便可瀏覽網格目錄查詢感興趣數據集所在節點，并向數據共享服務發送訪問請求，訪問請求通過消息傳遞組件被路由同步到相關數據發布者。當請求通過后，發布者則將感興趣數據集通過數據共享服務與請求者所在領域節點共享，并不斷監測數據使用模式以保證共享過程可控。傳統單一集中化的數據治理模式低效且難以應對快速變化的數據視圖，數據網格模式下各領域擁有數據主權并通過全局標準化實現互操作性，因此聯合數據治理包含兩種治理模式：全局數據治理和領域數據治理。全局數據治理模式包括：定義數據所有權和各領域邊界等信息；發布可適用于所有領域的通用治理方案，例如治理策略、流程、組織等；制定共同遵循的數據規范，例如共享API接口描述語言或元數據建模標準語言；統一業務詞匯表建模，例如對客戶識別號等概念的共同定義；確立最低數據質量和安全標準，例如在一組固定維度上評估所有領域質量以及根據中央身份管理來執行訪問控制；通過網格目錄對領域數據產品實施有效監控。在領域數據治理模式下，治理責任被分配給領域數據團隊，并根據各領域數據產品的屬性（例如數據類型、格式、訪問方式等）制定元數據管理、數據質量管理、數據生命周期管理等治理計劃，這種去中心化的自治模式對大數據治理更有效。企業各領域按需自動部署湖倉一體，對功能模塊要考慮可面向所有領域的通用性以及架構體系的完整性。功能上，確保結構化、半結構化、非結構化數據的采集、存儲、共享、實時處理和分析，以及全生命周期數據治理；結構上，直接在數據湖上配置數據倉庫功能，以免除數據遷庫帶來的成本和不一致等問題；服務上，支持復雜場景的數據分析應用。湖倉一體功能模塊（見圖2）包括3個部分：數據源、湖倉一體核心功能區和用戶。立足數據生命周期維度，可將湖倉一體的核心功能區拆解為6層：數據采集層、數據湖層、計算層、數據服務層、數據分析層和數據治理層。任何生成數據的操作系統都可能成為潛在數據源，通常聯機事務處理過程（Online Transaction Processing，OLTP）產生事務數據，這些事務數據以結構化數據為主，并以高度結構化形式存儲于關系數據庫中。此外，非結構化數據存儲于NoSQL數據庫中，包括鍵值對、圖形和JSON（JavaScript Object Notation）數據等。除操作系統外的其他數據源以非結構化數據為主，其中：文本數據是非結構化數據的主要類型，包括文件和純文本等，通過自然語言處理可以從文本數據中洞察信息；流數據是固定時間點某一系統不斷傳輸的數據，包括從物聯網設備發出的遙測數據、來自社交媒體平臺的持續反饋以及來自地理信息系統的位置信息等，流數據為實時分析提供支持，可以滿足情感分析、關鍵詞檢測等用例需求；媒體數據以圖像、語音和視頻為主，可以完成對圖像識別、語音識別、語音翻譯文本等高級用例的支持。數據采集方式以批量數據采集和實時數據采集為主。批量數據采集是指定期將數據提取到數據湖層，采集周期受數據源生產、推送能力和允許拉取數據能力等影響，實施批量采集操作需考慮源系統可否用于數據獲取以及可獲取批量數據規模的大小。實時數據采集是指在數據產生于源系統時將其拉入數據湖層，多基于Kafka隊列服務實現，該服務將實時數據流分組并臨時存儲為用于采集的隊列，還可捕獲數據庫中的數據變更。實時數據為持續數據流，對系統吞吐量和延遲等方面有更高要求。數據采集層的功能是支持各主流關系數據庫管理系統（Relational Database Management System，RDBMS）數據遷庫，可進行跨平臺實時文件交換、各類應用系統實時日志采集、基于業務數據庫日志的增量同步和各類消息隊列服務等。湖倉一體將存儲對象可視化為數據湖，以確保繼承數據湖的多元混合存儲機制，同時按數據格式和存儲狀態將數據湖劃分為原始數據區、中間數據區、已處理數據區和存檔數據區。數據以離線和實時兩種形式接入原始數據區長期存儲，并保留原格式（如CSV、Apache Parquet和JSON等）。中間數據區是原始數據完成處理任務的中間階段，例如數據清洗、過濾、聚合、附加等，保留中間數據的好處在于避免處理過程重啟造成的數據丟失。已處理數據區是數據湖最高層，經過加工轉換后的數據將被應用于數據分析任務（例如BI、報告和機器學習等），以及響應消費需求，服務于各類系統（如報告系統、下游應用系統、數據共享系統）等。存檔數據區為應對長期存儲目標而存在，以冷數據存儲為主，這類數據一般沒有快速檢索的需求，因此多采用低價存儲技術。湖內數據以Apache Parquet等標準文件格式存儲在對象存儲系統中，并附加元數據層和API層。元數據層是數據湖存儲重要組件，以往數據湖存儲系統僅支持低級別的對象存儲或文件系統接口，而豐富有效的元數據可實現湖內事務管理和其他數據管理功能，如Apache Hive工具允許以事務方式更新表，Delta lake和Apache Iceberg工具支持Apache Parquet、ORC格式文件，在實現與原始數據湖相似存儲機制的基礎上增強可操作性。API層提供豐富的SQL API以支持BI和報告等，并開發大量聲明性DataFrame API以支持數據科學和機器學習等高級分析，外部應用可查詢元數據層并通過適當接口實現對湖內數據的訪問。湖倉一體功能模塊解耦存儲和計算資源，使其分別使用獨立集群，可以實現存儲計算的獨立擴展以支持具有大數據工作負載的并發用戶。計算層內置Hive、Spark、Flink、Impala等計算引擎，為湖內數據的集成、處理、分析等提供豐富的計算環境，主要包括可支持讀寫分離的數據倉庫中間件、數據ETL/ELT過程所需的批處理計算引擎、實時分析所需的流計算引擎、內存計算以及可支持高級分析的機器學習庫。已處理數據通過數據服務層滿足下游用戶消費需求，主要包括基于SQL技術的數據倉庫服務、基于NoSQL技術的數據接口（API）和實時數據服務以及基于數據共享技術的共享數據服務。（1）SQL技術：根據系統的查詢性能和成本優化，主要可采用兩種架構類型的SQL數據庫作為服務層。其一是對稱多處理（SMP）架構，包括SQL Server、Oracle、MySQL等，此類架構優勢在于高速度、低延遲、少故障及事務管理，但其高耦合結構只適用于數據量較少的場景，當數據以PB級別擴張，則需應用大規模并行處理（MPP）架構，包括Azure Synapse、Amazon Redshift等。該架構將數據按區塊劃分且并行獨立處理，同時支持系統的垂直和水平擴展，適用于大數據場景。（2）NoSQL技術：包括文本數據庫（如MangoDB），具有高靈活性和可擴展性且支持實時數據訪問、鍵值存儲，簡化查詢，用數據緩存方式降低訪問延遲、提高吞吐量并實現類似于關系數據庫的寬列存儲，通過表內可靈活調整的列結構和數據庫寫入模式優化查詢速度。（3）數據共享技術：規定數據發布過程的相關條款和使用條件、共享過程的訪問管理和請求審批，確保數據以受控和結構化方式在企業內部各領域或外部實體間流轉。按照湖倉一體內數據的來源、數據類型以及數據消費群體等，可主要劃分4類數據服務：①數據倉庫服務不僅可存儲在線和歷史數據，還可以支持BI和報告，為業務分析需求提供數據查詢平臺，同時可作為下游數據集市的數據源；②實時數據服務對接下游應用系統，例如在線移動系統、客戶關系管理（CRM）系統、網站推薦引擎等；③基于API的服務通過各類API與外部服務進行交互，通常以JSON文件類型為主，此類服務可擴展性最高；④數據共享服務提供多源異構數據系統間數據共享所需的控制方式和策略，支持數據以結構化方式共享，該服務通?；贏PI進行。數據分析是將數據轉化為洞察力的過程。湖倉一體中可能存在的數據分析類型包括按需查詢、商業報告、自助BI、數據湖探索等在內的描述性分析，以及數據科學、機器學習等高級分析。（1）描述性分析：按需查詢以業務需求為導向，理解潛在數據模式并創建SQL數據表以查詢獲取數據、執行分析；商業報告根據具體要求定期生成，并以移動APP等渠道分發給相關用戶，報告通過挖掘服務層中的數據和預先定義的標準化報告格式來創建，提供了對多業務領域歷史和當前的看法以及跨功能維度的分析匯總；自助BI為功能用戶擺脫技術依賴進行分析提供可能，不同用戶可依托自助BI對分析報告進行切片以創建不同數據視圖，滿足個性化分析需求；基于SQL的工具無法支撐數據湖探索工作，應由技術型用戶探索數據特征生成特征集，并建立針對性數據模型，例如Jupyter Notebook為典型的開源數據湖探索工具。 （2）高級分析：數據科學、機器學習等高級分析以算法為支撐，用歷史數據集來獲得預測結果或從數據中提取復雜數學關系來產生洞察力。數據分析層通過分析沙盒、BI服務、數據科學和機器學習等組件，支撐多種類型的分析活動。（1）分析沙盒：根據執行分析的類型創建按需計算的集群，例如SQL集群和Spark集群等，并通過如Jupyter Notebook等交互式工具與數據湖或數據倉庫交互，用其存儲的大量數據進行特別分析或假設推演分析，沙盒可支持按需查詢和數據湖探索。 （2）BI服務：具有查看、分析和理解數據等能力，并輔助關鍵決策制定，為企業提供強有力的分析平臺，可支持商業報告和自助BI。商業報告以標準化格式為主，例如預制報告和可視化儀表盤等；自助BI可實現在線分析處理（OLAP）功能，以測量和維度的形式創建用戶友好型數據描述。 （3）數據科學和機器學習系統：基本支持湖格式數據的直接讀取以進行有效訪問，同時聲明性DataFrame API可對機器學習工作負載中的數據訪問進行查詢優化。類似分析沙盒，機器學習系統由計算層機器學習庫獲取計算資源并創建按需計算的實例，以執行相關探索性數據分析、特征工程、模型訓練和測試、可視化模型開發等。數據治理為相關數據管理活動提供可靠遵循規范，避免系統淪為數據沼澤。數據治理層以保證湖倉一體數據的可靠性、可訪問性和高質量為目標，從內容和過程控制的角度可劃分為數據治理策略、數據生命周期管理、元數據管理、主數據管理、數據質量管理和數據安全管理。（1）數據治理策略：是確保企業數據和信息資產得到一致管理和正確使用的章程，定義數據的可用性、完整性和一致性等參數，在數據發布方式和消費方式上保持一致，同時建立數據架構、標準定義和版本控制等原則，這些原則隨企業成熟度、愿景變化而變化。為企業制定數據治理度量評估體系，依托評估工具，根據相關度量維度和規則為治理結果打分并提出改進計劃。（2）數據生命周期管理：持續監管數據由產生到消亡的價值屬性，并實時反饋，使企業掌握當前數據狀態。此工作需依據基于完整的元數據信息獲取的數據特征和關聯信息來完成，并創建索引來跟蹤特定數據及其關聯數據。（3）元數據管理：可為湖內數據提供完整性描述以保持其可操作性，以元數據為基礎形成數據目錄是避免數據沼澤化的關鍵。按蘊含信息和功能屬性可將元數據劃分為技術元數據、操作元數據和業務元數據，需要元數據捕獲引擎、圖譜和搜索引擎等組件支持編制數據目錄，分別實現元數據的定期自動掃描捕獲、自動編目形成可視化關系圖以及提供訪問窗口。 （4）主數據管理：針對關鍵業務實體（如員工、客戶、產品、供應商等）建立統一視圖以在相關數據存儲中獲得唯一實體識別，并對已識別主數據按數據規范要求進行治理和互聯網技術（IT）改造，其目標在于提供準確、及時、完整的主數據來源，保證在企業范圍內重要業務實體數據的一致性（定義和實際物理數據一致），以支持企業內部決策分析和業務流程再造、企業業務流和工具鏈的打通和串聯。（5）數據質量管理：數據治理層的最重要環節，數據質量可定義為數據適合實際使用的程度，高質量的數據是企業做出正確決策的基礎。質量管理的前提是定義同時適用于數據湖層和數據服務層的質量規則，依據規則劃分質量等級（以數據成本和價值效益為參考），按規則實時監測數據的完整性、時效性、唯一性、一致性、有效性和精確性等并進行打分，以評估企業當前數據質量水平，打分結果為提出質量改進計劃和重新定義質量規則提供可靠參考。（6）數據安全管理：通過身份和訪問管理（IAM）對訪問用戶進行授權和認證，以確保湖倉數據按需訪問的安全性，可以阻止惡意訪問并通過基于風險的訪問控制、身份保護和認證工具來保證證書的完整性，同時不會干擾正常的訪問過程。通過數據加密將信息編碼，包括對稱加密和非對稱加密，加密過程以算法（如高級加密標準等）和各類加密工具為基礎，以保護存儲在云服務器中的數據并防止多種網絡攻擊。通過數據屏蔽實現數據加密但保持其可讀性（僅適用于特定的敏感數據元素），并在需要時將屏蔽解除，以靜態數據屏蔽（SDM）和動態數據屏蔽（DDM）方法為主。除身份和訪問控制之外，湖倉一體外部網絡和內部各層級之間數據流動的安全性可通過虛擬網絡、防火墻、虛擬專用網絡（VPN）等技術得到保障。依據數據分析和服務的主題可將用戶分為技術用戶和功能用戶：前者是在特定領域具有技術能力的利益相關者，包括數據分析師、數據科學家等；后者是擁有特定領域專業知識的利益相關者，例如管理人員和各類信息系統等。湖倉一體確保所有類型數據原始格式和轉換格式的可訪問性以滿足各類用戶需求。數據科學家專注于所有數據，在特定平臺創建和測試數據模型；數據分析師受業務驅動，專注于清洗和處理后的數據，通過查詢、匯總和切片數據來完成分析任務。企業管理人員通過BI工具，由報告系統獲取業務報告用于業務決策。報告系統定期獲取數據并生成報告，為訂閱者提供預定、臨時和自助式服務。下游應用系統可能是OLTP系統、其他系統中的數據倉庫或數據湖，這些系統定期提取處理后的信息或采用一定機制將信息推送至最終用戶。湖倉一體通過大量API向各類內、外部系統提供數據服務，基于API的數據消費可滿足特定系統的個性化交付需求，具有較高的可擴展性。數據共享系統為用戶提供開放可控的數據市場。各業務領域湖倉一體功能模塊各層級間依據一定規則實現數據流入流出。由于數據倉庫的ETL或數據湖的ELT過程均難以滿足湖倉一體內部數據流轉需要，采用一種提取/加載/轉換/加載（ELTL）方法實現流批一體的數據采集、存儲和處理，如圖3所示。原格式數據通過批量采集引擎以推/拉方式加載到數據湖原始數據區并長期保存，采集服務按需提供，在數據源可執行采集操作時被激活，數據推送方法包括文件傳輸協議（FTP）和編程語言等，數據拉取方法包括開放數據庫鏈接或JAVA數據庫鏈接等。原始數據會加載到批處理引擎，由于湖內數據的多源異構屬性，以分布式批處理方式為主：制定分布策略，將數據集劃分為多塊，包括散列分布和循環分布等，并為每一塊數據子集配置獨立計算單元以實施轉換過程。分布式批處理支持計算單位的水平和垂直擴展來加速處理，在數據處理過程中，中間數據被保留，已處理數據被重新合并為統一數據集保存在已處理數據區并按需加載到數據服務層，中間數據區和已處理數據區可與批處理引擎進行多次交互。實時數據來自社交媒體平臺、物聯網等流數據源，主要價值在于時效性，實時分析多在數據上直接進行，因此無須長期存儲。實時數據通過事件發布/訂閱服務等消息中間件采集到原始數據區用作備份，并按需加載到流處理引擎。流數據的轉換過程可分為微批處理和執行階段，微批處理負責從流數據中提取較小數據集并轉換，這個階段基于時間和事件。完成微批處理創建后需在其上執行處理任務，包括分組任務（如過濾、聚合、排序、連接等）以及某一特定事件的事件導向型任務，經處理的數據將被第一時間推送至數據服務層并載入已處理數據區。數據湖向湖倉一體的過渡代表數據平臺向管理結構化、系統化方向轉變。分布式湖倉一體意在通過業務數據解耦使單體數據架構向可擴展架構轉變，這種轉變更是海量分布數據環境下數據治理思維方式的升級。通過比較三代數據平臺差異并分析當前湖倉一體面臨的挑戰，提出分布式湖倉一體架構，構建完整數據生命周期下的湖倉一體功能模塊和數據流轉過程。下一步，將依托相關技術研究該架構落地方法以供相關研究或企業參考。
