新興資料倉儲設計與實踐手冊：從分層架構到實際應用（二）

本手冊將分為三部分發布，以幫助讀者逐步深入理解資料倉儲的設計與實踐。

• 第一部分介紹資料倉儲的整體架構概述；
• 第二部分深入討論ETL在數倉中的應用理論，ODS層的具體實現與應用；
• 第三部分將圍繞DW資料倉儲層、ADS層和資料倉儲的整體趨勢展開；

透過這樣的結構，您可以系統地學習每一層次的內容和設計原則。

前情提要：《新興資料倉儲設計與實踐手冊：從分層架構到實際應用（一）》https://mp.weixin.qq.com/s/_iYSM0sT_NOysducbxEJhg

數倉分層下的ETL

在不同資料層次、以及源系統到資料倉儲之間的ETL（Extraction、Transformation、Loading）是資料倉儲建設的核心，負責將分散在不同源系統的異構資料抽取到臨時中間層，經過清洗、轉換、整合後載入至資料倉儲或資料集市。

通常，ETL規則的設計和執行在資料倉儲實施中佔據了60%到80%的工作量。而隨著資料量的增加和非結構化資料和實時處理需求的增加，ETL架構也逐步被淘汰演變為EtLT架構 參見文章：《ELT已死，EtLT才是現代資料處理架構的終點!》 以更好地適應多樣化的資料來源和實時場景。

資料抽取（Extraction）

資料抽取負責將原始資料從各源系統中獲取。傳統的抽取方式包括初始化載入與定期重新整理。初始化載入用於建立維表和事實表，將初始資料匯入到資料倉儲中；資料重新整理則負責在源資料變動時追加或更新資料倉儲內容。常見的重新整理方式有定時任務和觸發器。

在處理非結構化資料（如API介面資料、XML檔案）和Binlog資料時，抽取步驟會更加複雜。

比如，需要透過互動介面（如HTTP API、SaaS API）獲取非結構化資料，並對資料庫的變更日誌（Binlog）進行解析（如Oracle CDC、AWS RDS CDC、MongoDB CDC）。

這些資料在抽取後，通常需轉換為倉庫相容的記憶體格式，以便後續的處理和整合，例如，將多種源資料統一轉為WhaleTunnel/SeaTunnel格式供處理引擎使用。

輕量級轉化/資料清洗（transform/Cleaning）

資料清洗和輕量級轉化是為消除原始資料中的二義性、重複性、不完整性或不符合業務規則的資料。

清洗過程可以去除無效資料，確保資料的一致性和準確性。輕量級清洗會資料格式化為資料倉儲所需的標準格式。不同源系統的資料欄位命名或資料格式往往不一致（如A表的欄位名為id，而B表為ids），轉換過程將統一這些命名和格式，構建一致的資料字典。

一般來說，這一步不會進行復雜的業務邏輯處理，以避免對後續升級和擴充套件帶來依賴。對於複雜的業務邏輯，通常建議在資料倉儲內透過SQL或儲存過程處理，而不是依賴於外部清洗工具。

這樣可以提高系統的靈活性，避免過多依賴特定工具帶來的維護成本。

例如，在WhaleTunnel/SeaTunnel當中利用介面/指令碼進行輕量級別資料清洗，增加欄位、修改資料型別、修改欄位名稱、過濾不需要的資料等。

資料載入（Loading）

在載入階段，經過清洗和轉換的資料會以批次載入（Bulkload）或直接寫入的方式存入目標儲存系統（如HDFS、Doris、Hive、Hudi、Iceberg、Greenplum等），為資料集市提供基礎。

大多數公司會將載入任務整合到內部資料平臺和排程平臺中（如Apache DolphinScheduler或WhaleScheduler），並封裝大資料叢集（如Hadoop、Spark、SeaTunnel、Hive等）以提供統一的操作介面。

資料平臺可以基於許可權控制，為不同使用者群體提供不同的操作許可權，便於管理與維護。在Load的時候，也儘量不使用JDBC模式，因為大量資料載入時候insert/update會形成系統瓶頸，例如，WhaleTunnel/SeaTunnel是全部記憶體轉化成高速載入的，不會把中間資料儲存在磁碟或資料庫當中，同時在Load時候採用高速資料API Bulk Load方式，效率數倍於JDBC模式。

通常，為了最佳化任務排程，大公司會將資料倉儲劃分為不同層級，設立分層，建立不同的工作量/專案進行管理，而不會全面用一個DAG 管理所有的任務。這樣，日常的數千甚至上萬條定時任務可以按不同資料倉儲層次/業務部門和小組進行維護，透過許可權、優先順序或依賴關係分層執行，提升排程的管理效率和穩定性。

資料轉換（Transformation）

前面講大量資料透過實時和批次的方式進入資料倉儲/資料湖當中，隨著資料倉儲效能的加強和SQL功能的擴充套件，目前已經不再流行使用ETL工具（例如Informatica、DataStage、Talend等）在資料倉儲當再進行處理，而是直接利用SQL處理複雜的業務。

這樣對於系統的移植、人員的管理、以及後續升級到DataOps流程支援敏捷開發都更加的方便。因此EtLT架構已經成為現在技術的主流架構。

目前的架構基本都在資料倉儲的某些欄位內容可能需要基於多個源欄位的邏輯關係計算得出，可以書寫相應的SQL完成整體開發。當前，SQL、Python或Shell指令碼是常用的轉換工具，搭配排程工具（如DolphinScheduler或WhaleScheduler）可以高效管理資料轉換任務流。

數倉分層的技術架構

資料中臺的構建涉及多個方面，涵蓋了大資料處理和管理的核心要素，在實際工作中通常包括以下內容：

01 系統架構

以Hadoop和Spark等大資料元件為核心，構建高效的分散式架構，以支援資料的儲存、計算和處理能力。

02 資料架構

透過頂層設計進行主題域劃分，並採用分層體系（如ODS-DW-ADS）來組織資料流向和結構層次，確保資料管理的靈活性和適應性。

03 資料建模

採用維度建模方法，透過確定業務過程的粒度，構建合理的維度表和事實表，以便更高效地支援業務分析和查詢需求。

04 資料管理

包括對資料資產、後設資料、資料質量、主資料和資料標準的全面管理，同時建立資料安全管理機制，確保資料的準確性、完整性和安全性。

05 輔助系統

包含任務排程、ETL處理以及監控等支撐系統，保障資料的高效處理和系統執行的穩定性。

06 資料服務

提供資料門戶、資料查詢、分析報表、視覺化、機器學習和資料探勘等服務，支援資料的多場景應用，以及資料交換、共享和下載功能。

數倉分層

在前面給大家粗略介紹了資料倉儲的分成概念，接下來給大家詳細介紹：資料倉儲通常可以分為四個層次，但這一劃分並不是固定的，不同公司可能會根據自身需求進行調整或重新命名。

ODS 貼源層

資料引入層（ODS，Operational Data Store），也稱為資料基礎層。這一層主要存放從源系統引入的原始資料，幾乎不做任何加工處理，目的是將基礎資料直接同步到資料倉儲中，便於後續的資料處理工作。

在結構上，ODS層的資料與源系統保持高度一致，是資料倉儲的資料準備區。

在現代資料架構中，ODS層的資料獲取方式逐步向CDC（Change Data Capture，變更資料捕獲）模式轉變，尤其在資料湖和實時資料倉儲的場景中。

新型的ETL工具已經可以支援源系統的DDL（資料定義語言）變更，這意味著當源系統的欄位發生變化時，ODS層可以自動更新表結構，無需手動調整。

例如，WhaleTunnel這樣的工具支援多種系統的DDL變更捕獲，保證了ODS層資料在資料倉儲、資料湖或實時資料倉儲中的一致性，不會因為源系統的改變而中斷ETL流程。

ODS層的資料通常分為當前資料和歷史資料兩部分：

• 當前資料表：用於儲存最近需要處理的資料，保持最新的資料狀態。

• 歷史資料表：儲存已處理完的資料以備後續使用，一般保留3-6個月後清理，具體時間視專案需求而定。如果源系統的資料量較小，也可以選擇更長時間的儲存，甚至全量儲存。

資料清洗和規範化

儘管ODS層主要作用在於資料引入，但並非完全不做處理。

此層通常會進行基本的資料清洗，例如：

• 處理異常欄位、規範化欄位命名、統一時間格式

• 確保資料一致性，為後續資料處理和特徵工程奠定基礎

一些公司會選擇在ODS層就進行初步的清洗和過濾，而另一些則將更多的資料加工留在DWD層。

選擇在哪裡進行清洗取決於企業的技術規範和需求。在實際開發中，大多數企業會在將資料存入ODS時進行基本處理，以減少後續工作量。

資料來源及儲存策略設計

資料來源可按時間進行分割槽儲存，通常以日為粒度，也有公司採用年、月、日三級分割槽以最佳化儲存效率。

資料在進入資料倉儲前進行基礎清洗，如格式錯誤資料的剔除、關鍵資訊缺失的過濾等，以保證資料質量。資料可分為實時和離線兩種處理模式。

離線資料處理

離線資料通常透過定時任務（如每日批次任務）從業務系統或資料庫中抽取。典型的日計算任務會在凌晨執行，透過SeaTunnel、DataX 或 WhaleTunnel從業務資料庫提取資料，計算前一天的業務指標，並生成報表。

Hive、Spark常用於批次計算，計算結果儲存於Hive、HBase、MySQL、Elasticsearch 或 Redis等系統中，供後續分析使用。

實時資料處理

實時資料來源主要來自日誌埋點資料或業務資料庫，常用於實時推薦、使用者畫像等業務需求。

Spark Streaming 和 Flink負責實時計算，結果通常寫入Elasticsearch、HBase 或 Redis。

實時資料來源可利用WhaleTunnel監控MySQL的Binlog變化，將資料實時寫入Kafka 或 HDFS。

資料來源

1. 業務資料庫：公司各業務系統生成的結構化資料。

2. 日誌資料：包括使用者行為日誌和系統後臺日誌。埋點資料首先經由Nginx上報，再由Flume收集並儲存在Kafka等訊息佇列中，隨後由SeaTunnel或WhaleTunnel拉取至離線資料倉儲（如HDFS）。

3. 外部資料：包括合作伙伴提供的資料或爬蟲採集的資料，整合後用於補充業務分析。

資料儲存策略（增量、全量、拉鍊）

在實際應用中，可根據需求選擇增量、全量或拉鍊儲存方式。

增量儲存增量儲存通常按天分割槽，以業務日期為分割槽欄位，每日儲存新增的業務資料。

例如，使用者A在1月1日訪問了店鋪B，生成記錄t1，並於1月2日訪問店鋪C，生成記錄t2。增量儲存會將t1存入1月1日的分割槽，將t2存入1月2日的分割槽。

如果使用者A在1月1日購買商品B（生成t1記錄）並在1月2日退貨（更新t1記錄），增量儲存會將初始購買記錄存於1月1日分割槽，退貨更新後的記錄則存於1月2日分割槽。

對於交易日誌和行為日誌等高頻變更的資料表，增量儲存能減少儲存成本和資料冗餘。 下游分析需求一般只需聚合後的彙總資料，因此不需要長期儲存全量的歷史資料。

全量儲存全量儲存以日為分割槽，每個分割槽記錄當天的完整業務資料快照。

例如，1月1日，賣家A釋出了商品B和C，生成記錄t1和t2。1月2日，賣家A下架商品B並上架商品D，此時商品B記錄t1會更新，商品D生成新記錄t3。

全量儲存會在1月1日分割槽儲存t1和t2，在1月2日分割槽儲存更新後的t1、t2和t3。

1. 對於資料量較小、變化緩慢的維度資料（如商品分類），全量儲存能夠保證資料完整性和易用性。

2. 拉鍊儲存拉鍊儲存透過在表中增加開始時間（start_dt）和結束時間（end_dt）兩個時間戳欄位，記錄每次資料變更，並以時間為分割槽欄位。這種方式適用於記錄所有變更資料的歷史快照，為分析資料演變過程提供支援。

目前WhaleTunnel已經支援了CDC、增量和全量資料抽取模式，也支援自定義插入規則，是使用者使用的快速工具不錯的選擇！

結語

資料倉儲的分層設計和模型方法為企業提供了強大的資料管理能力，不僅能夠應對複雜的業務需求變化，還能在保障系統穩定性和資料質量的同時提升運營效率。

透過合理分層，資料倉儲可以高效地儲存、處理和分析資料，實現資料價值的最大化。

感謝您閱讀本手冊的每一部分，希望這些內容對您構建現代化資料倉儲體系有所幫助。透過三部分的系統性講解，相信您已經對資料倉儲的四層架構及其應用有了更深的理解。請繼續關注我們的更多技術分享，與我們一起探索資料驅動的未來。

本文由 白鯨開源 提供釋出支援！