除了 ETL（抽取、轉換、加載）、ELT（抽取、加載、轉換） 和 CDC（變更數據捕獲）等常見數據集成設計模式之外，行業中還廣泛采用了許多其他類型的設計方式，以應對日益復雜的數據處理需求。這些設計方式涵蓋了從數據存儲、流動到消費的各個環節，旨在提升系統的可擴展性、靈活性和實時處理能力。接下來將介紹一些在現代數據架構中更為常見且實用的設計方式，它們在不同場景下為數據工程實踐提供了有力的支持。

數據傳輸

數據工程中的數據傳輸是通過工具或協議實現數據在系統間高效、安全移動與同步的過程，支撐數據集成與分析。

1. 零拷貝數據傳輸

在系統級編程中，“零拷貝”（Zero-copy）是一種旨在減少數據傳輸過程中不必要的內存復制操作的技術。其核心思想是通過繞過 CPU 的參與，將數據直接從磁盤文件傳輸到網絡接口設備，而無需應用程序介入數據復制過程。這種方式不僅降低了 CPU 的負載，還提高了數據傳輸的效率和吞吐量。

例如，在現代操作系統中，Java 提供了 transferTo 方法，它利用 Linux 內核中的 sendfile() 系統調用來實現高效的文件傳輸。這種方法避免了傳統方式中多次在用戶空間與內核空間之間切換上下文所帶來的性能損耗。目前，NGINX 和 KAFKA 等高性能系統已廣泛采用這種技術作為其底層數據傳輸機制的重要組成部分。

然而，零拷貝并非適用于所有場景。由于它跳過了用戶空間，因此在需要對傳輸數據進行處理的情況下（如加密、壓縮或內容轉換），該技術就顯得力不從心。因此，零拷貝更適合于那些僅需高效傳輸原始數據而不涉及中間處理的場景。

此外，零拷貝有多種實現方式，具體取決于系統架構和應用場景。例如，可以通過內存映射（memory map）配合 write 系統調用實現，也可以結合 sendfile 與文件描述符（File Descriptors）來完成高效的數據傳輸。另一種常見的方法是使用 sendfile 搭配 DMA（直接內存訪問）的“聚集-收集”（Gather Collector）機制，以進一步減少內存操作。

如果對操作系統級別的性能感興趣的話， 推薦閱讀毛文安等老師的《深入理解eBPF與可觀測性》一書——

值得一提的是，Splice（拼接） 是一種基于元數據操作的零拷貝技術。它并不真正復制數據本身，而是操作數據的元信息（metadata）。這種設計建立在存儲與計算分離的基礎之上，使得計算層只需處理元數據，而非實際數據內容。當發生更新時，系統也只需要修改受影響的部分元數據，從而實現更高效的數據管理與差異保留。這為構建高性能、低延遲的數據傳輸系統提供了堅實的技術支撐。

2. n 路隊列數據傳輸

在多個應用程序需要使用相同數據的場景下，傳統的做法是由數據源直接向每個系統分別發送數據。然而，這種方法不僅增加了數據源的復雜性和負擔，還可能導致數據一致性和同步問題。為了解決這些問題，可以采用隊列或主題（topic）的方式進行數據傳輸。具體來說，數據源只需將數據發送到一個中心化的隊列或主題中，而各個消費者應用則根據自身需求從這個共享的數據管道中異步獲取所需信息。

這樣一來，不但簡化了數據源的設計和實現，同時也提高了系統的可擴展性和靈活性，使得添加或移除消費者變得更加容易而不影響整個系統的穩定性和性能。此外，這種模式有助于確保所有消費者接收到的數據是統一且一致的，進一步提升了數據處理的準確性和可靠性。通過利用隊列或多路廣播機制，數據能夠在不同的應用之間高效流轉，滿足現代分布式系統對于實時性和高并發的要求。

數據處理

3. Lambda 架構

Lambda 架構是一種統一的數據處理體系，旨在同時支持實時數據和歷史數據的采集、處理與查詢。該架構的設計理念在于通過一套系統來應對兩種主要的數據處理需求：對海量歷史數據的批處理和對新產生數據的實時處理。其核心思想是為這兩類數據流復制相同的處理邏輯，從而保證最終輸出的一致性與準確性。

整個架構由三個層次組成：批處理層負責對全量數據進行長期存儲和周期性計算；速度層則專注于低延遲的實時數據處理，以快速響應最新數據變化；而服務層用于將批處理和流處理的結果合并，并對外提供統一的查詢接口，使用戶能夠高效地獲取最新的分析結果。

4. Kappa 架構

Kappa 架構可以看作是對 Lambda 架構的一種簡化和優化，它將原本的三層結構縮減為兩層：處理層和服務層。在 Kappa 中，所有的數據處理任務都統一交由流處理引擎完成，無論是實時數據還是歷史數據，都通過重放日志的方式來實現批處理功能。這種設計去除了單獨的批處理層，使得整體架構更加簡潔、易于維護，同時也降低了系統中因重復處理邏輯而引發不一致的風險。

通過統一使用流式處理模型，Kappa 架構不僅減少了組件復雜度，還提升了系統的實時能力與一致性保障，成為當前越來越多流處理平臺所采用的架構模式。

數據建模

隨著數據來源的多樣化以及消費方式的不斷演進，一個清晰、高效的數據建模策略已成為確保系統成功的關鍵因素。良好的數據模型不僅有助于提升查詢性能和數據一致性，還能更好地支持復雜的分析需求。

5. 規范化與非規范化：兩種核心建模方法

在數據建模中，規范化（Normalized）和非規范化（Denormalized）代表了兩種不同的設計思路。規范化模型通常用于模擬真實業務系統的結構，強調去除數據冗余并以存儲效率為導向。它通過將數據拆分為多個高度結構化的表來減少重復，并依靠多表連接（Join）實現數據完整性。這種模式常見于操作型數據庫和面向特定主題的數據集市（Data Marts），適用于需要頻繁更新和強一致性的場景。

與此相對，非規范化模型則更側重于滿足消費端或業務用戶的查詢需求，通常被稱為“維度建模”。該方法通過構建星型模式（Star Schema）或雪花模式（Snowflake Schema）來優化查詢性能。其中，維度表用于描述業務實體的屬性和可能性，例如時間、地點或產品；而事實表則記錄具體的業務事件，表示這些可能性的實際發生情況，如銷售記錄或用戶行為日志。

此外，在維度建模中，處理緩慢變化維度（Slowly Changing Dimensions, SCD）是一個關鍵問題。由于某些維度信息（如客戶地址或產品分類）會隨時間發生變化，如何有效地追蹤歷史變更并保持當前狀態，對保證分析結果的準確性至關重要。根據不同的業務要求，SCD 通常有多種處理策略，如直接覆蓋舊值、添加新記錄保留歷史，或采用時間區間等方式進行管理。

如果面對多模態的結構/半結構/非結構化數據，推薦閱讀巴川老師的《多模態數據分析》——

選擇合適的建模方式應基于具體的應用場景和性能需求。規范化模型適合寫入密集、數據一致性要求高的系統，而非規范化模型則更適合讀取頻繁、需快速響應復雜查詢的分析平臺。兩者各有優勢，在實際應用中也可結合使用，以實現靈活性與性能的平衡。

6. Data Vault 建模

Data Vault 是一種專為可擴展性和歷史追蹤而設計的數據建模方法，特別適用于需要整合來自多個源系統的復雜環境。它通過一組結構化的建模元素來表示核心業務實體、它們之間的關系以及相關的描述性信息。

在 Data Vault 中，集線器（Hub）用于表示企業中最核心的業務概念及其唯一標識符和元數據，是整個模型的主干部分。鏈接（Link）則用來表達這些核心實體之間的關聯，支持靈活且可擴展的關系建模。而衛星（Satellite）則負責存儲與集線器或鏈接相關的信息，并能夠捕捉隨時間變化的歷史狀態，其變更管理方式類似于 Type II 緩慢變化維度（SCD），從而保留完整的變更軌跡。

此外，Data Vault 的架構通常分為三個邏輯層：原始層（Raw Layer）、業務層（Business Layer）和表示層（Presentation Layer）。原始層主要用于存儲未經清洗的原始數據，業務層則進行一致性處理和整合，表示層面向最終用戶，提供易于理解和使用的數據視圖。

由于其高度模塊化、可擴展性強的特點，Data Vault 非常適合應用于現代 Lakehouse 架構中，能夠有效支持從數據湖到數據倉庫的多層次分析需求，同時兼顧靈活性與治理能力。

7. 寬表模型

寬表是一種典型的非規范化數據結構，常被形象地稱為“一張大表”（One Big Table, OBT）。它通過將事實表與多個維度表的關聯結果預先計算并存儲，形成一個包含豐富上下文信息的單一表結構，從而大幅提升查詢效率，尤其適用于需要頻繁進行多維分析和快速響應的場景。

這種模型的核心優勢在于其簡化了查詢邏輯，避免了復雜且耗時的多表連接操作，使用戶能夠更直接、高效地訪問所需數據。例如，在像 BigQuery 這樣的現代云數據倉庫中，寬表被廣泛使用，以支持大規模數據分析和實時報表生成。

在構建和維護寬表的過程中，通常會借助自動化數據管道來提升效率與一致性。開發人員可以使用如 Airflow 和 dbt 等工具，實現從數據抽取、轉換到加載（ETL/ELT）全過程的代碼化管理。這些工具不僅支持任務調度和依賴管理，還能確保數據處理流程具備良好的可維護性和可擴展性。

同時，在數據庫對象的持續交付（CD）方面，Liquibase 或 Flyway 等工具也被廣泛采用，用于版本化管理數據庫結構變更，確保寬表及相關對象在不同環境中的部署一致且可控。

寬表模型通過犧牲一定的存儲空間換取了查詢性能的顯著提升，是現代數據分析平臺中一種非常實用的設計模式，尤其適合對響應速度和易用性有較高要求的業務場景。

如果您希望更好地掌握數據體系建設，推薦閱讀王曉華老師的《一本書講透數據體系建設：方法與實踐》——

8. 數據倉庫：星型模式下的并行加載優化

在傳統的星型模式數據倉庫架構中，數據加載通常遵循先維度表、后事實表的順序。這種串行加載方式雖然能確保外鍵約束的完整性，但也帶來了明顯的性能瓶頸，尤其是在處理大規模數據時，維度表的加載延遲會直接影響到整個ETL流程的效率。

為了解決這一問題，一種常見的優化策略是引入代理鍵的哈希計算機制。具體來說，可以在數據準備區（staging area）中對維度表的關鍵字段生成 VARCHAR(32) 類型的代理鍵，并通過計算其 MD5 哈希值作為唯一標識。這樣可以在不依賴實際維度表主鍵的前提下，提前準備好事實表所需的外鍵信息。

在此基礎上，進一步的改進措施包括禁用外鍵約束，從而實現維度表與事實表的并行加載。通過這種方式，多個數據流可以同時進行加載操作，大幅縮短整體加載時間。待所有數據加載完成后，再重新啟用外鍵約束，以保證數據的一致性和引用完整性。

這種優化方法不僅提升了加載性能，還增強了系統的可擴展性，特別適用于高并發、大數據量的現代數據倉庫環境。同時，它也為構建高效、靈活的數據管道提供了堅實的基礎。

9. 事實表子集化

在處理大規模數據環境中的大型事實表時，為了提升查詢性能并優化數據處理效率，可以采用一種稱為“事實表子集化”的策略。該方法的核心思想是根據實際的訪問模式和使用場景，從原始的大型事實表中提取出一個精簡的數據子集，構建一個結構更為緊湊、查詢響應更快的小型事實表。

這個子集通常包含最常被訪問或最關鍵的業務數據，例如最近一段時間內的交易記錄、高頻查詢所涉及的特定維度組合等。通過這種方式，不僅可以減少每次查詢掃描的數據量，還能降低ETL處理的開銷，提高整體系統性能。

值得注意的是，這種小型事實表可以在與主事實表相同的批次流程中進行填充，也可以作為獨立的數據流單獨處理，視具體的數據架構和業務需求而定。無論采用哪種方式，事實表子集化都為實現更高效的數據分析提供了一種靈活且實用的解決方案，尤其適用于對響應速度和資源利用率有較高要求的場景。

數據組織

數據工程中的數據組織通過結構化存儲、分類和目錄管理，提升數據可訪問性、管理效率，并確保數據質量。

10. Medallion Lakehouse

Medallion Lakehouse 是一種分層數據組織架構，旨在通過層級化的結構提升數據質量和可用性。該架構將數據按照處理階段劃分為多個層次，每一層都代表了不同成熟度的數據資產，并為下一層提供更高質量、更結構化的輸入。

最底層是 Bronze 層，用于存儲從源系統直接攝取的原始數據，通常以“原樣”（raw）或增量形式保存。這一層的數據尚未經過清洗或轉換，保留了最原始的狀態，主要用于數據的初步存儲和后續處理。

在 Bronze 層基礎上，數據經過清洗、驗證和初步整合后進入 Silver 層。這一層的數據已經去除了無效或錯誤記錄，具備一致的格式和基本的業務規則，適合用于輕量級分析或作為上層數據處理的來源。

最終，Silver 層的數據進一步豐富、聚合并建模，形成面向具體業務場景的結構化數據，進入 Gold 層。該層數據質量最高，專為支持關鍵業務指標、報表展示或高級分析而設計，具有高度的可讀性和即用性。

這種逐層演進的方式不僅提升了數據治理能力，還增強了整個 Lakehouse 架構的靈活性與可維護性，使其成為現代數據平臺中廣泛采用的一種組織模式。