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

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

數(shù)據(jù)建模層：概念層、邏輯層、物理層

數(shù)據(jù)建模是設計數(shù)據(jù)系統(tǒng)結構的過程。它通常分為三個層次：

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

想象：

你正在規(guī)劃一棟房子。

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

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

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

數(shù)據(jù)庫規(guī)范化（1NF-3NF）

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

前三個范式是：

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

想想你的衣柜：

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

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

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

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

星型模式

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

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

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

事實表與維度表

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

Inmon 與 Kimball 方法

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

技術權衡：

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

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

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

數(shù)據(jù)倉庫建模

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

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

主要特點：

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

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

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

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

但：

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

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

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

ETL 與 ELT 與 ETLT

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

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

數(shù)據(jù)轉換工具

常用工具：

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

Hadoop 與 Spark：傳統(tǒng)與 Lightning

Hadoop：

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

Spark：

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

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

機器學習的特征工程

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

作為數(shù)據(jù)工程師，您的職責是準備：

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

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

TL;DR 備忘單

最后的想法

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

因此，無論您是在繪制第一個星型模式還是在生產中設置并行 Spark 作業(yè)，請謹慎、清晰地構建數(shù)據(jù)，并設置適當?shù)幕靵y度以保持其趣味性。