數據建模聽起來像是一個高調的詞，你會在高風險的創業公司路演中聽到，或者在數據團隊會議上虔誠地低聲說。但如果你曾經列過購物清單，或者對衣柜進行過分類（沒錯，襪子總要有個歸宿），那么恭喜你——某種程度上來說，你已經在進行數據建模了。

在這篇博客中，我們將深入剖析最近學習到的一些最重要的數據建模方法——所有這些都是在努力平衡過多的標簽、大量的咖啡和一個令人困惑的橡皮鴨調試會話的過程中完成的。我們將從數據建模層和范式到星型模式、數據倉庫、ETL/ELT，甚至Spark 管道，分解關鍵概念，并提供真實案例，避免過多的專業術語。

數據建模層：概念層、邏輯層、物理層

數據建模是設計數據系統結構的過程。它通常分為三個層次：

• 概念模型——業務實體和關系的高級視圖，不包含技術細節。
• 邏輯模型——定義表結構、關系、鍵和屬性。獨立于物理存儲。
• 物理模型——在特定的數據庫引擎中實現邏輯模型，包括索引、分區和數據類型。

想象：

你正在規劃一棟房子。

概念=紙上草圖（臥室、廚房、浴室）

邏輯=帶有測量和布局的藍圖

物理 =用木材、瓷磚和電線實際建造

數據庫規范化（1NF-3NF）

規范化可幫助您減少重復并提高數據完整性——通過將大型冗余表拆分為更小、干凈相關的表。

前三個范式是：

• 1NF：消除重復組和嵌套數據。
• 2NF：消除部分依賴——每一列必須依賴于完整的主鍵。
• 3NF：刪除傳遞依賴關系——非鍵列必須僅依賴于鍵。

想想你的衣柜：

1NF：所有東西都折疊起來，沒有嵌套在另一件襯衫里

2NF：每個抽屜只包含一個類別（沒有混合的襯衫+褲子）

3NF：配飾（如腰帶）與服裝分開存放

TL;DR：進行規范化，直到您的查詢高效并且您的連接看起來不像謀殺謎題板。

星型模式

星型模式是數據倉庫中使用的一種維度建模方法。

• 它以一個中心事實表（銷售額或收入等定量數據）為特色，周圍環繞著維度表（客戶、產品、地區等描述性數據）。
• 此設置可使您的 SQL 速度更快并且儀表板更整潔。

可以將事實表想象成商店的銷售登記簿。維度表則是產品目錄、客戶目錄和商店列表。這種結構使分析查詢更快、更容易。

事實表與維度表

• 事實表：包含可測量的定量數據（例如銷售額、數量、收入），通常非常大（數百萬或數十億行），并具有引用維度表的外鍵
• 維度表：存儲描述性、分類數據（例如，客戶名稱、產品類型、地區），有助于為事實表中的數字提供背景信息，通常較小且經常被引用

Inmon 與 Kimball 方法

• Inmon 方法（自上而下）：首先使用規范化結構（通常為 3NF）創建一個集中式企業數據倉庫 (EDW)。數據經過大量的暫存和轉換后加載到倉庫中。EDW 完成后，將為特定部門（例如銷售、人力資源、財務）創建數據集市。這種方法有利于實現強大的治理、一致性和長期可擴展性。
• Kimball 方法（自下而上）：首先使用非規范化的星型模式，直接從源系統構建數據集市。這些數據集市隨后會集成到更大的數據倉庫中，或作為獨立的數據集市保留。該方法強調速度、訪問便捷性和業務友好性。

技術權衡：

• Inmon需要更多的前期規劃、更長的時間表和更嚴格的建模規則，但可以提供高度的數據完整性。
• Kimball部署速度更快，分析師查詢也更方便——但如果管理不善，可能會導致重復和控制松散。

當你需要全局一致性時，請選擇Inmon 。當速度和可用性至關重要時，請選擇Kimball 。

現實世界？大多數團隊都會兩者兼顧。而且會花數周時間去命名表格，卻無人能達成一致。

數據倉庫建模

Data Vault 是一種混合數據建模方法，旨在實現敏捷、可擴展且可審計的數據倉庫。它將數據分為三個核心部分：

• 中心——代表唯一的業務實體（例如，客戶、產品）。每一行都由一個業務鍵唯一標識。
• 鏈接——定義中心之間的多對多關系（例如，客戶→訂單）。
• 衛星——包含與中心或鏈接相關的上下文、歷史變化和描述性屬性。

主要特點：

• 支持緩慢變化維度（SCD）的歷史跟蹤。 -
• 專為并行加載而設計——集線器、鏈路和衛星可以獨立加載。
• 鼓勵可審計性、沿襲跟蹤和易于模式擴展。

可以將 Data Vault 想象成樂高套件——靈活、可擴展，并且您可以在不破壞整個套件的情況下克服錯誤。

一個大表（OBT）：快速，平坦，并且......有缺陷？

OBT將事實數據和維度數據合并到單個寬表中。它快速、簡單，非常適合儀表板。

但：

• 很難維持。
• 模式改變=麻煩。
• 空值？哦，肯定有很多。

例如：想象一下，你不再為收據、供應商和日期設置單獨的文件夾，而是將所有信息都放在一個大電子表格里。閱讀速度很快，但維護起來卻很困難。

何時使用：優先考慮速度的儀表板或 BI 工具、原型設計或 MVP 分析，以及當模式更改最少且簡單性是關鍵時

ETL 與 ELT 與 ETLT

• ETL：提取→轉換→加載——數據在加載到倉庫之前進行轉換。
• ELT：提取→加載→轉換——將原始數據加載到倉庫中，然后進行轉換。
• ETLT：一種混合體，具有輕度處理預載和之后更深層次的轉換。

把它想象成烹飪：ETL 是在下鍋前把所有食材準備好。ELT則是把所有食材放入鍋中，邊煮邊調味。ETLT介于大廚和“冰箱里有什么？”之間。

數據轉換工具

常用工具：

• AWS Glue：基于 Apache Spark 構建的無服務器 ETL。配置正確后，可擴展性良好。
• DBT：云數據倉庫內部基于 SQL 的轉換。非常適合倉庫中的版本控制和 CI/CD。
• AWS DataBrew：無需代碼即可進行數據整理。拖放式轉換。非常適合快速探索或非程序員使用。
• Pandas/Spark——用于轉換的自定義腳本。非常適合處理早期混亂的數據或一次性批處理作業。

Hadoop 與 Spark：傳統與 Lightning

Hadoop：

• 批處理。
• 將數據存儲在磁盤上
• 適用于大型但速度較慢的數據工作負載，歷史上使用較多

Spark：

• 內存處理，分布式計算。
• 處理批處理、流處理、ML，甚至 SQL
• 為 AWS Glue、Databricks 等現代工具以及一半的面試問題提供支持。

TL;DR：當您的數據管道想要感覺快速和智能時，它就會使用 Spark。

機器學習的特征工程

您并不總是能夠構建模型，但您卻能夠使模型成為可能。

作為數據工程師，您的職責是準備：

• 清理并標記的數據集
• 編碼類別（標簽、獨熱）
• 縮放數值
• 衍生特征（例如“每分鐘觀看次數”）
• 噪聲或缺失值最少的數據集

特征工程就像準備飯菜。準備得越干凈、越好，廚師（你的機器學習模型）的工作速度就越快。

TL;DR 備忘單

最后的想法

好的建模造就好的數據。那么，好的數據呢？這是每一個偉大的產品、洞察和決策的開端。

因此，無論您是在繪制第一個星型模式還是在生產中設置并行 Spark 作業，請謹慎、清晰地構建數據，并設置適當的混亂度以保持其趣味性。