一、數(shù)倉分層

在數(shù)字化時代，企業(yè)面臨著海量數(shù)據(jù)的挑戰(zhàn)，如何高效地管理和利用這些數(shù)據(jù)成為了關鍵。數(shù)據(jù)倉庫作為企業(yè)數(shù)據(jù)存儲、處理和分析的核心平臺，其重要性日益凸顯。而數(shù)倉建設的分層架構設計，則是提升數(shù)據(jù)倉庫效能、優(yōu)化數(shù)據(jù)處理流程的重要保障。通過合理的分層架構，可以將復雜的數(shù)據(jù)處理任務分解為多個簡單的步驟，提高數(shù)據(jù)處理效率、增強數(shù)據(jù)可擴展性、便于數(shù)據(jù)管理和維護，同時優(yōu)化查詢性能，為企業(yè)的決策提供更有力的支持。

二、數(shù)倉分層架構的基本概念

1. 定義

數(shù)倉分層架構是結合對業(yè)務場景、實際數(shù)據(jù)、使用系統(tǒng)的綜合分析，對數(shù)據(jù)模型進行的整體架構設計及層級劃分。它將數(shù)據(jù)倉庫劃分為不同的邏輯層次，每個層次負責特定的數(shù)據(jù)處理任務，使得數(shù)據(jù)在各層之間有序流轉，從而實現(xiàn)數(shù)據(jù)的高效管理和利用。

2. 常見分層方式

(1) 經(jīng)典四層架構（最廣泛應用）

• ODS（Operation Data Store） - 操作數(shù)據(jù)存儲層：也稱為原始數(shù)據(jù)層或貼源層，存放未經(jīng)過處理的原始數(shù)據(jù)至數(shù)據(jù)倉庫系統(tǒng)，結構上與源系統(tǒng)保持一致，是數(shù)據(jù)倉庫的數(shù)據(jù)準備區(qū)。主要完成基礎數(shù)據(jù)引入到數(shù)據(jù)倉庫的職責，同時記錄基礎數(shù)據(jù)的歷史變化。例如，某電商平臺將訂單系統(tǒng)、用戶系統(tǒng)等業(yè)務系統(tǒng)中的原始數(shù)據(jù)同步到 ODS 層，為后續(xù)的數(shù)據(jù)處理提供原材料。
• DWD（Data Warehouse Detail） - 數(shù)據(jù)倉庫明細層：對 ODS 層的數(shù)據(jù)進行清洗、轉換和整合，生成高質(zhì)量的明細數(shù)據(jù)。該層以業(yè)務過程作為建模驅動，基于每個具體的業(yè)務過程特點，構建最細粒度的明細層事實表。可以結合企業(yè)的數(shù)據(jù)使用特點，將明細事實表的某些重要維度屬性字段做適當冗余，即寬表化處理。比如，對 ODS 層中的訂單數(shù)據(jù)進行清洗，去除無效數(shù)據(jù)、規(guī)范字段格式，同時關聯(lián)用戶維度信息，生成訂單明細寬表。
• DWS（Data Warehouse Summary） - 數(shù)據(jù)倉庫匯總層：基于 DWD 層的數(shù)據(jù)，按照業(yè)務需求進行聚合和匯總，生成寬表或主題表。以分析的主題對象作為建模驅動，基于上層的應用和產(chǎn)品的指標需求，構建公共粒度的匯總指標事實表，以寬表化手段物理化模型。構建命名規(guī)范、口徑一致的統(tǒng)計指標，為上層提供公共指標，建立匯總寬表。例如，按天對訂單明細數(shù)據(jù)進行匯總，統(tǒng)計每個用戶的訂單數(shù)量、訂單金額等指標，生成用戶訂單日匯總表。
• ADS（Application Data Service） - 數(shù)據(jù)應用層：面向最終業(yè)務需求，提供高度聚合的數(shù)據(jù)，直接支持報表、分析和應用。存放數(shù)據(jù)產(chǎn)品個性化的統(tǒng)計指標數(shù)據(jù)，根據(jù) CDM 與 ODS 層加工生成。該層的數(shù)據(jù)高度定制化，直接為業(yè)務需求服務，具有業(yè)務邏輯的強約束性。比如，根據(jù) DWS 層的匯總數(shù)據(jù)，生成面向運營人員的銷售報表、用戶留存率報表等，為業(yè)務決策提供支持。

(2) 阿里五層模型

在四層基礎上增加 DIM（維度層）和 DWM（中間層）：

• DIM（維度層）：基于維度建模理念思想，建立整個企業(yè)的一致性維度。降低數(shù)據(jù)計算口徑和算法不統(tǒng)一風險。公共維度層的表通常也被稱為邏輯維度表，維度和維度邏輯表通常一一對應。例如，建立商品維度表、用戶維度表、時間維度表等，為數(shù)據(jù)倉庫中的事實表提供維度信息。
• DWM（中間層）：在 DWD 層的數(shù)據(jù)基礎上，對數(shù)據(jù)做一些輕微的聚合操作，生成一系列中間結果表，提升公共指標的復用性，減少重復加工的工作。例如，對 DWD 層中的訂單明細數(shù)據(jù)按商品類別進行輕度聚合，統(tǒng)計每個商品類別的訂單數(shù)量、訂單金額等指標，生成商品類別中間表，為 DWS 層的匯總提供基礎。

(3) 三層簡化架構

適用于初創(chuàng)公司或簡單業(yè)務：

• ODS：數(shù)據(jù)接入，存儲從業(yè)務系統(tǒng)中直接采集的原始數(shù)據(jù)。
• DW：整合建模（合并 DWD/DWS），完成數(shù)據(jù)的清洗、轉換和聚合，構建數(shù)據(jù)倉庫的核心模型。
• APP：應用集市，面向具體的業(yè)務應用，提供數(shù)據(jù)服務。

三、數(shù)倉分層架構的原因

1. 數(shù)據(jù)解耦與模塊化

通過分層，可以將復雜的數(shù)據(jù)處理流程解耦為多個獨立的部分，每一層處理特定的數(shù)據(jù)任務。這使得數(shù)據(jù)處理更加模塊化，便于開發(fā)、維護和功能更迭。同時，分層架構使得數(shù)據(jù)血緣關系更加清晰，便于問題定位和避免重復計算。例如，當源業(yè)務系統(tǒng)的業(yè)務規(guī)則發(fā)生變化時，只需調(diào)整 ODS 層或 DWD 層的數(shù)據(jù)處理邏輯，而無需對整個數(shù)據(jù)倉庫進行重構。

2. 提升數(shù)據(jù)處理效率

數(shù)據(jù)倉庫通常包含多個來源的數(shù)據(jù)，且需要經(jīng)過多個處理階段，如數(shù)據(jù)抽取、數(shù)據(jù)清洗、數(shù)據(jù)轉換和數(shù)據(jù)加載等。將數(shù)據(jù)按照層次結構組織，可以提高處理效率，減少數(shù)據(jù)重復處理和多次掃描的問題。通過預計算、維度退化、數(shù)據(jù)聚合等手段，將數(shù)據(jù)按照預期的功能進行冗余存儲，實現(xiàn)以空間換時間的目的，從而滿足不同使用場景和數(shù)據(jù)粒度的需求。比如，在 DWS 層進行數(shù)據(jù)的預聚合，減少了上層應用在查詢時的計算量，提高了查詢性能。

3. 增強數(shù)據(jù)可擴展性

當源業(yè)務系統(tǒng)的業(yè)務規(guī)則發(fā)生變化時，只需調(diào)整相應層次的數(shù)據(jù)處理邏輯，而無需對整個數(shù)據(jù)倉庫進行重構。這有助于降低維護成本，提高數(shù)據(jù)倉庫的可擴展性。例如，隨著業(yè)務的發(fā)展，需要增加新的數(shù)據(jù)源或業(yè)務指標，只需在相應的層次進行擴展和調(diào)整即可。

4. 便于數(shù)據(jù)管理和維護

分層建設使得數(shù)據(jù)倉庫中的數(shù)據(jù)更加有序，便于進行數(shù)據(jù)備份、數(shù)據(jù)恢復和數(shù)據(jù)歸檔等管理操作。同時，不同層次的數(shù)據(jù)可以采用不同的安全措施，提高數(shù)據(jù)的安全性。例如，對 ODS 層的數(shù)據(jù)進行全量備份，對 DWS 層和 ADS 層的數(shù)據(jù)進行定期備份；對敏感數(shù)據(jù)在 DWD 層進行脫敏處理，確保數(shù)據(jù)的安全性。

5. 優(yōu)化查詢性能

數(shù)據(jù)倉庫中的數(shù)據(jù)通常需要進行復雜的分析和查詢。將數(shù)據(jù)按照層次結構組織可以優(yōu)化查詢路徑，減少數(shù)據(jù)掃描和查詢時間，提高查詢性能。例如，上層應用在進行數(shù)據(jù)分析時，可以直接從 DWS 層或 ADS 層獲取已經(jīng)匯總好的數(shù)據(jù)，避免了從大量的明細數(shù)據(jù)中進行查詢和計算。

四、數(shù)倉建設分層架構過程中的注意要點

1. 架構規(guī)范

(1) 明確分層原則

通常遵循自下而上的 ODS、DWD、DWS、ADS 架構，各層有明確的作用和職責。ODS 近乎原樣存儲從源系統(tǒng)抽取的數(shù)據(jù)，起到緩沖和備份源數(shù)據(jù)作用；DWD 對 ODS 數(shù)據(jù)初步清洗、標準化，為上層提供統(tǒng)一格式明細數(shù)據(jù)；DWS 按照主題域聚合 DWD 數(shù)據(jù)，如按銷售、財務等主題匯總，提供分析型數(shù)據(jù)；ADS 面向具體業(yè)務應用，如報表、數(shù)據(jù)挖掘需求定制數(shù)據(jù)。例如，在設計數(shù)倉架構時，要明確每個層次的功能定位，避免層次之間的職責混淆。

(2) 數(shù)據(jù)流向清晰

嚴格規(guī)定各層數(shù)據(jù)單向流動，禁止跨多層回溯調(diào)用，一般只允許相鄰層間交互，即 ODS -> DWD -> DWS -> ADS，確保數(shù)據(jù)處理流程有序，易于維護與追蹤。比如，ADS 層的數(shù)據(jù)只能從 DWS 層獲取，不能跨越 DWS 層直接從 DWD 層或 ODS 層獲取數(shù)據(jù)。

2. 層間調(diào)用規(guī)范

(1) 下層服務上層

下層數(shù)據(jù)層為直接上層提供數(shù)據(jù)支撐，上層只能從緊鄰下層獲取所需數(shù)據(jù)，不能跨層調(diào)用。例如 DWS 層構建的銷售主題匯總數(shù)據(jù)，供 ADS 層銷售報表應用直接使用，而不能從 ODS 層跨越 DWD 層直接取用原始銷售數(shù)據(jù)。

(2) 接口標準化

相鄰層間數(shù)據(jù)交互接口需統(tǒng)一規(guī)范，包括數(shù)據(jù)格式（如日期統(tǒng)一為“YYYY-MM-DD”）、傳輸協(xié)議（常用 HTTP、FTP 等），確保不同層開發(fā)團隊協(xié)作順暢，數(shù)據(jù)傳輸穩(wěn)定高效。

3. 需求實現(xiàn)方案規(guī)范

(1) 基于分層設計

接到業(yè)務需求，首先分析應在數(shù)倉哪一層實現(xiàn)，如簡單報表需求多在 ADS 層通過關聯(lián)已有匯總數(shù)據(jù)快速滿足；復雜分析需求可能需從 DWD 層開始重新聚合、加工數(shù)據(jù)。例如，對于簡單的日報表需求，可以直接從 ADS 層獲取已經(jīng)匯總好的數(shù)據(jù)進行展示；對于復雜的多維度分析需求，則需要從 DWD 層的數(shù)據(jù)開始進行重新計算和聚合。

(2) 方案評審

需求實現(xiàn)方案需組織跨團隊評審，涵蓋業(yè)務、開發(fā)、運維等人員，確保方案既滿足業(yè)務目標，又遵循架構規(guī)范，不破壞已有數(shù)據(jù)生態(tài)，如評估新方案對數(shù)據(jù)存儲、計算資源的影響。

4. 模型規(guī)范

(1) 模型設計規(guī)范

• 主題域劃分：依據(jù)業(yè)務核心流程，劃分如客戶、產(chǎn)品、訂單、財務等主題域，每個主題域獨立建模，便于管理與理解。例如在客戶主題域，圍繞客戶基本信息、購買行為、忠誠度等構建實體關系模型。
• 采用星型/雪花型架構：事實表處于中心，關聯(lián)多個維度表。星型架構維度表直接與事實表連接，簡潔高效，適用于快速查詢場景；雪花型架構維度表有層級細分，規(guī)范化程度高，適合復雜分析，依業(yè)務需求權衡選用。

(2) 模型命名規(guī)范

• 統(tǒng)一前綴：不同層級模型采用特定前綴區(qū)分，如 DWD 層模型前綴為“dwd_”，DWS 層為“dws_”，便于識別與管理，像“dwd_sales_detail”表明是明細數(shù)據(jù)層銷售明細模型。
• 表意清晰：名稱包含業(yè)務主體與關鍵信息，如“dws_financial_report_monthly”能直觀反映是財務主題、月度匯總報表模型，方便開發(fā)、運維人員快速定位。

(3) 詞根管理規(guī)范

• 建立詞根庫：梳理業(yè)務常用術語，提煉詞根，如“sale”代表銷售、“cust”代表客戶，所有相關模型、字段命名盡量基于這些詞根拓展，保證語義連貫性。
• 定期維護：隨著業(yè)務發(fā)展，新術語涌現(xiàn)，定期更新詞根庫，確保命名體系與時俱進，同時回溯審查已有模型命名，必要時調(diào)整優(yōu)化。

(4) 指標體系建設規(guī)范

• 指標定義統(tǒng)一：對業(yè)務關鍵指標，如銷售額、利潤率、客戶留存率等，明確定義計算口徑、時間范圍、數(shù)據(jù)來源，確保不同報表、分析場景下指標含義一致。例如，銷售額定義為含稅訂單金額，統(tǒng)計周期為自然月。
• 分層構建：底層指標基于明細數(shù)據(jù)計算，為上層復合指標提供支撐，像日銷售額是基礎指標，月銷售額可由日銷售額匯總得到，構建層次分明的指標體系，滿足不同業(yè)務深度需求。

5. 流程規(guī)范

(1) 需求承接規(guī)范

• 需求收集：主動與業(yè)務部門溝通，定期組織需求調(diào)研會，通過問卷調(diào)查、業(yè)務訪談等形式，全方位收集數(shù)據(jù)需求，包括報表需求、數(shù)據(jù)分析需求、數(shù)據(jù)挖掘需求等。
• 需求文檔化：將收集到的需求整理成詳細規(guī)范的文檔，涵蓋需求背景、目標、詳細功能描述、預期交付時間等，便于后續(xù)開發(fā)、測試、驗收環(huán)節(jié)對照執(zhí)行，避免需求模糊引發(fā)項目風險。

(2) 運維機制規(guī)范

• 監(jiān)控體系：建立全方位數(shù)據(jù)監(jiān)控，包括數(shù)據(jù)質(zhì)量（準確性、完整性、一致性）監(jiān)控，通過數(shù)據(jù)校驗規(guī)則比對；任務執(zhí)行狀態(tài)監(jiān)控，實時查看 ETL 任務、數(shù)據(jù)處理任務是否成功執(zhí)行，利用工具如 Zabbix、Prometheus 實現(xiàn)可視化監(jiān)控。
• 故障應急：制定詳細故障應急預案，依據(jù)故障影響范圍、嚴重程度分級，不同級別啟動相應處理流程，從故障發(fā)現(xiàn)、通知責任人到恢復系統(tǒng)正常運行各環(huán)節(jié)明確時間節(jié)點與操作步驟，如數(shù)據(jù)延遲故障，5 分鐘內(nèi)發(fā)現(xiàn)通知，30 分鐘內(nèi)定位修復。

(3) 上線流程規(guī)范

• 預上線測試：在正式上線前，進行多輪測試，包括單元測試，開發(fā)人員自測代碼功能；集成測試，模擬真實業(yè)務場景，檢驗不同模塊、組件協(xié)同工作能力；用戶驗收測試，邀請業(yè)務用戶驗證是否滿足需求，所有測試通過方可進入下一步。
• 灰度上線：對于重大變更或新功能，采用灰度上線策略，先在小部分用戶或業(yè)務場景試用，收集反饋，確認無誤后逐步擴大范圍，降低整體上線風險。

(4) 模型設計流程規(guī)范

• 業(yè)務調(diào)研：深入了解業(yè)務需求、流程，與業(yè)務專家溝通，確定模型服務的業(yè)務場景、目標，如為精準營銷構建客戶畫像模型，需調(diào)研營銷流程與客戶特征需求。
• 設計文檔：依據(jù)調(diào)研結果，撰寫詳細模型設計文檔，包括模型架構圖、實體關系圖、字段定義、數(shù)據(jù)來源、預期性能指標等，作為后續(xù)開發(fā)依據(jù)，并在團隊內(nèi)部評審，確保設計合理性。

6. 管理規(guī)范

(1) 監(jiān)控告警規(guī)范

• 告警閾值設定：針對數(shù)據(jù)質(zhì)量、任務執(zhí)行等監(jiān)控指標，結合業(yè)務容忍度與歷史數(shù)據(jù)波動，設定合理告警閾值。如數(shù)據(jù)準確性低于 95%、任務延遲超過 10 分鐘觸發(fā)告警，確保問題能及時被發(fā)現(xiàn)。
• 告警渠道：利用多種渠道發(fā)送告警，如郵件、短信、企業(yè)即時通訊工具，優(yōu)先選擇能及時觸達責任人的方式，且告警信息包含問題描述、影響范圍、緊急程度、建議處理措施等，便于快速響應。

(2) 存儲管理規(guī)范

• 分區(qū)策略：根據(jù)數(shù)據(jù)特性，如時間序列數(shù)據(jù)按年、季、月、日分區(qū)；地域數(shù)據(jù)按地區(qū)分區(qū)，便于數(shù)據(jù)查詢、管理，減少全表掃描，提高查詢效率，如查詢某季度銷售數(shù)據(jù)，直接定位季度分區(qū)即可。
• 存儲介質(zhì)選型：熱數(shù)據(jù)（近期頻繁訪問）優(yōu)先選用高性能關系型數(shù)據(jù)庫，如 Oracle、MySQL；冷數(shù)據(jù)（歷史久遠、訪問少）考慮分布式存儲，如 Hadoop HDFS，平衡存儲成本與訪問效率。

(3) 數(shù)據(jù)安全管理規(guī)范

• 訪問權限控制：基于角色的訪問控制（RBAC），為不同崗位人員（如業(yè)務分析師、開發(fā)人員、運維人員）設定不同權限，業(yè)務分析師只能查詢 ADS 層報表數(shù)據(jù)，開發(fā)人員有權限修改開發(fā)層模型數(shù)據(jù)，防止越權訪問。
• 數(shù)據(jù)脫敏：對敏感數(shù)據(jù)，如客戶身份證號、銀行卡號，在非必要場景進行脫敏處理，采用哈希、替換等方法，保證數(shù)據(jù)可用性同時保護隱私，如身份證號保留前 6 位和后 4 位，中間用星號代替。

五、特殊場景下數(shù)倉建設分層架構的處理方法

1. 小型團隊或簡單業(yè)務

適用場景為數(shù)據(jù)量?。ㄈ缛赵隽?lt;GB 級）、業(yè)務邏輯簡單（如僅需幾張報表）。此時省去分層設計的開發(fā)和管理成本，可快速交付。但業(yè)務擴展后可能面臨重構壓力。例如，某創(chuàng)業(yè)公司初期業(yè)務簡單，數(shù)據(jù)量較小，直接從原始數(shù)據(jù)層進行簡單的數(shù)據(jù)處理和報表生成，滿足業(yè)務需求。隨著業(yè)務的發(fā)展，數(shù)據(jù)量和業(yè)務復雜度增加，再考慮對數(shù)據(jù)倉庫進行分層設計和重構。

2. 實時數(shù)據(jù)流處理

適用于需要實時響應的場景（如監(jiān)控、風控），數(shù)據(jù)直接從消息隊列（如 Kafka）寫入 OLAP 引擎（如 Doris）。使用流式處理（Flink）+ 實時數(shù)倉（如 ClickHouse），跳過傳統(tǒng)分層。例如，某金融機構的實時風控系統(tǒng)，通過 Flink 對 Kafka 中的實時交易數(shù)據(jù)進行實時處理和分析，將結果直接寫入 ClickHouse 供實時查詢和監(jiān)控。

3. 探索性分析或臨時需求

適用于臨時數(shù)據(jù)探查、PoC 驗證，可直接在原始數(shù)據(jù)層（ODS）或數(shù)據(jù)湖中操作。通過 Trino、Spark SQL 直接查詢原始數(shù)據(jù)，快速輸出結果。例如，數(shù)據(jù)分析師在進行新的業(yè)務分析探索時，直接從 ODS 層的數(shù)據(jù)中進行查詢和分析，無需對數(shù)據(jù)進行復雜的處理和分層。

4. 現(xiàn)代架構的演進

(1) Data Lakehouse

結合數(shù)據(jù)湖的靈活性和數(shù)倉的管理能力（如 Delta Lake、Iceberg），部分場景可替代分層。Data Lakehouse 可以存儲各種類型的數(shù)據(jù)，包括結構化、半結構化和非結構化數(shù)據(jù)，同時支持數(shù)據(jù)的管理和分析。例如，某企業(yè)使用 Delta Lake 構建 Data Lakehouse，將原始數(shù)據(jù)存儲在 Delta Lake 中，同時通過 SQL 進行數(shù)據(jù)的查詢和分析，無需進行復雜的分層架構設計。

(2) Serverless 查詢引擎

如 BigQuery、Snowflake，通過虛擬化層自動優(yōu)化查詢，降低對分層的依賴。這些 Serverless 查詢引擎可以根據(jù)查詢需求自動分配計算資源，無需用戶進行復雜的資源管理和分層設計。例如，某公司使用 Snowflake 進行數(shù)據(jù)查詢和分析，Snowflake 會自動對查詢進行優(yōu)化，提高查詢性能。

5. 實時數(shù)倉場景

(1) 即席查詢

實時要求非常高，要求寫入即可查，更新即反饋，有即席查詢需求，且資源較為充足，查詢復雜度較低。將操作層（ODS 層）的數(shù)據(jù)經(jīng)過簡單的清理、關聯(lián)，然后存儲到明細數(shù)據(jù)，暫不做過多的二次加工匯總，明細數(shù)據(jù)直接寫入 Hologres。Flink 加工增量數(shù)據(jù)，實時更新明細數(shù)據(jù)至 Hologres，MaxCompute 加工后的離線表寫入 Hologres。因為上層的分析 SQL 無法固化，在 CDM/ADS 層以視圖（View）封裝成 SQL 邏輯。上層應用直接查詢封裝好的 View，實現(xiàn)即席查詢。例如，某電商平臺的實時數(shù)據(jù)分析系統(tǒng)，對用戶的實時行為數(shù)據(jù)進行即席查詢和分析，通過上述架構實現(xiàn)快速響應和靈活查詢。

(2) 分鐘級準實時

有實時需求，以分析為主，實時性滿足分析時數(shù)據(jù)在業(yè)務場景具備實時含義，不追求數(shù)據(jù)產(chǎn)生到分析的秒級絕對值，但開發(fā)效率優(yōu)先。將操作層（ODS 層）的數(shù)據(jù)經(jīng)過簡單的清理、關聯(lián)，然后存儲到明細數(shù)據(jù)，暫不做過多的二次加工匯總，明細數(shù)據(jù)直接寫入 Hologres。Flink 加工增量數(shù)據(jù)實時更新明細數(shù)據(jù)至 Hologres。CDM/ADS 層為實際的物理表，通過 DataWorks 等調(diào)度工具調(diào)度周期性寫入數(shù)據(jù)。前端實時請求實際的物理表，數(shù)據(jù)的實時性依賴 DataWorks 調(diào)度周期配置，例如 5 分鐘調(diào)度、10 分鐘調(diào)度等，實現(xiàn)分鐘級準實時。比如，某企業(yè)的運營監(jiān)控系統(tǒng)，對業(yè)務數(shù)據(jù)進行分鐘級的實時分析和監(jiān)控，采用該方案平衡了時效性與開發(fā)效率。

(3) 增量數(shù)據(jù)實時統(tǒng)計

實時需求簡單、數(shù)據(jù)更新少、只需要增量數(shù)據(jù)即可統(tǒng)計結果，以大屏和風控等在線服務場景為主，需要數(shù)據(jù)產(chǎn)生到分析盡量實時，可以接受一定開發(fā)效率的降低和計算成本的上升。增量計算的數(shù)據(jù)由 Flink 進行清洗加工轉換和聚合匯總，ADS 層應用數(shù)據(jù)存儲在 Hologres 中。Flink 加工的結果集采取雙寫的方式，一方面繼續(xù)投遞給下一層消息流 Topic，一方面 Sink 到同層的 Hologres 中，方便后續(xù)歷史數(shù)據(jù)的狀態(tài)檢查與刷新。在 Flink 內(nèi)通過增量流、增量流連接靜態(tài)維表、增量流連接增量流這三種場景統(tǒng)計出數(shù)據(jù)，寫入 Hologres。Hologres 通過表的形式直接對接上層應用，實現(xiàn)應用實時查詢。例如，某金融機構的實時風控大屏，對交易數(shù)據(jù)的增量進行實時統(tǒng)計和展示，采用該方案滿足了實時性要求。