半夜兩點(diǎn)，報(bào)警短信響個(gè)不停，數(shù)據(jù)管道悄無聲息地掛了：日志卡住、指標(biāo)亂飆、儀表盤延遲，老板在群里催進(jìn)度，而你卻一頭霧水。追蹤任務(wù)、反復(fù)重試、刷新報(bào)表——直到那一刻才明白，這并不是單純的“調(diào)度問題”。

數(shù)據(jù)工程的本質(zhì)，其實(shí)是以數(shù)據(jù)為核心的系統(tǒng)設(shè)計(jì)。

在這篇文章里，我想帶你梳理 15 個(gè)數(shù)據(jù)工程必懂的系統(tǒng)設(shè)計(jì)概念。它們幫助我把“救火式”開發(fā)，轉(zhuǎn)變?yōu)椤翱深A(yù)期、可擴(kuò)展”的平臺(tái)建設(shè)。這些概念看似抽象，卻是支撐現(xiàn)代數(shù)據(jù)系統(tǒng)的基石。

1. 批處理（Batch） vs 流處理（Streaming）

在數(shù)據(jù)工程里，數(shù)據(jù)如何被“采集和處理”，決定了整個(gè)系統(tǒng)的延遲、復(fù)雜度和適用場景。常見的兩種方式就是 批處理 和 流處理。

?? 批處理（Batch Ingestion）

批處理是把一段時(shí)間內(nèi)產(chǎn)生的數(shù)據(jù)收集起來，集中處理。通常是 按小時(shí)、按天 等固定周期運(yùn)行。

圖片

比如：一家零售公司每天凌晨 2 點(diǎn)從 POS 系統(tǒng)導(dǎo)出當(dāng)天的銷售交易記錄（CSV 文件），上傳到 S3。接著，一個(gè) Airflow DAG 會(huì)定時(shí)觸發(fā)，讀取這些文件，清洗后再寫入 Snowflake 數(shù)據(jù)倉庫。

適用場景：數(shù)據(jù)量大、結(jié)構(gòu)穩(wěn)定;報(bào)表分析、周期性統(tǒng)計(jì);對實(shí)時(shí)性要求不高。

不適合：實(shí)時(shí)告警;秒級反饋。

?? 流處理（Streaming Ingestion）

流處理是另一種思路：數(shù)據(jù)一產(chǎn)生，就立刻被處理，幾乎實(shí)時(shí)流入系統(tǒng)。

圖片

比如：一家網(wǎng)約車公司采集司機(jī)的實(shí)時(shí)定位信息，這些事件會(huì)直接寫入 Kafka，由 Flink 等流式引擎即時(shí)消費(fèi)，最后存入低延遲數(shù)據(jù)庫，用來支撐實(shí)時(shí)地圖和 ETA 預(yù)測。

適用場景：實(shí)時(shí)看板；異常檢測；實(shí)時(shí)告警與風(fēng)控。

挑戰(zhàn)：架構(gòu)復(fù)雜度更高；成本和運(yùn)維要求更高。

2.變更數(shù)據(jù)捕獲（CDC）

變更數(shù)據(jù)捕獲（CDC）是一種設(shè)計(jì)模式，它能在數(shù)據(jù)源端實(shí)時(shí)（或近實(shí)時(shí)）捕獲數(shù)據(jù)的變更操作（增、刪、改），并將這些變更同步到下游系統(tǒng)中。

與整體重載整張表的方式不同，CDC 只同步發(fā)生變更的部分?jǐn)?shù)據(jù)，從而使數(shù)據(jù)管道更高效、可擴(kuò)展，并能快速響應(yīng)變化。

圖片

舉個(gè)例子：假設(shè)你在一家類似 Swiggy 或 Uber Eats 的外賣平臺(tái)工作。訂單數(shù)據(jù)存儲(chǔ)在 PostgreSQL 數(shù)據(jù)庫中，包括訂單編號、用戶編號、狀態(tài)（如“已下單”“已派送”“已送達(dá)”）和更新時(shí)間。

問題：你的實(shí)時(shí)分析看板需要展示“每分鐘成功交付的訂單量”，但由于當(dāng)前數(shù)據(jù)管道每隔幾小時(shí)才全量刷新一次，看板中的數(shù)據(jù)往往是滯后的。

解決方案：通過啟用 CDC，你無需重新加載整個(gè)訂單表，而是可以實(shí)時(shí)流式獲取每一條行級別的數(shù)據(jù)變更。這樣一來，數(shù)據(jù)看板就能實(shí)時(shí)反映最新訂單狀態(tài)，真正做到動(dòng)態(tài)更新。

圖片

3.冪等性（Idempotency）

在分布式數(shù)據(jù)系統(tǒng)中，故障難以避免——而且往往以意想不到的方式發(fā)生。

這時(shí)就需要冪等性來保駕護(hù)航。所謂冪等性，是指同一個(gè)操作即便被重復(fù)執(zhí)行多次，也不會(huì)產(chǎn)生超出第一次執(zhí)行結(jié)果之外的影響。換句話說，重復(fù)操作不會(huì)帶來副作用。

舉個(gè)例子：無論在 Instagram 或 Twitter 上用戶重復(fù)點(diǎn)擊“點(diǎn)贊”多少次，最終的點(diǎn)贊數(shù)都只會(huì)增加 1。

圖片

因此，在設(shè)計(jì)數(shù)據(jù)管道時(shí)，要確保系統(tǒng)能夠在失敗和恢復(fù)中保持穩(wěn)定。讓每一個(gè)處理階段都可安全重試、且無副作用。這一設(shè)計(jì)理念的微小轉(zhuǎn)變，不僅能節(jié)省大量調(diào)試時(shí)間、提升數(shù)據(jù)可信度，更能讓你的管道達(dá)到生產(chǎn)級可靠性。

4.OLTP 與 OLAP

a. OLTP（聯(lián)機(jī)事務(wù)處理）

OLTP 系統(tǒng)用于支持日常業(yè)務(wù)操作，例如應(yīng)用程序的數(shù)據(jù)庫。它們通常具有高速、高可靠性，并針對實(shí)時(shí)讀寫進(jìn)行優(yōu)化。

 示例：在亞馬遜下單購買商品、在社交平臺(tái)發(fā)布一條評論。 常用系統(tǒng)：PostgreSQL、MySQL、DynamoDB、MongoDB

b. OLAP（聯(lián)機(jī)分析處理）

OLAP 系統(tǒng)則專注于決策分析而非日常操作。它們擅長處理海量歷史數(shù)據(jù)、執(zhí)行復(fù)雜聚合分析，并為看板和業(yè)務(wù)報(bào)表提供支持。

圖片

示例：分析銷售趨勢、統(tǒng)計(jì)用戶行為、生成財(cái)務(wù)報(bào)表。 常用平臺(tái)：Snowflake、BigQuery、Redshift、Databricks SQL

我們通常從 OLTP 系統(tǒng)中提取數(shù)據(jù)，經(jīng)過轉(zhuǎn)換與建模，最終加載到 OLAP 系統(tǒng)中——這正是 ETL 和 ELT 背后最核心的數(shù)據(jù)流模式。

5.行式存儲(chǔ) vs 列式存儲(chǔ)

理解行式存儲(chǔ)和列式存儲(chǔ)的區(qū)別，絕非紙上談兵——它直接影響到查詢速度、存儲(chǔ)效率，甚至整個(gè)架構(gòu)的可擴(kuò)展性。這是一個(gè)看似底層、卻牽動(dòng)全局的關(guān)鍵設(shè)計(jì)選擇。

我們通過一個(gè)簡單示例來看它們的存儲(chǔ)方式：

圖片

a. 行式存儲(chǔ)（Row-Based Storage）

在行式存儲(chǔ)中，數(shù)據(jù)按行連續(xù)存放——即一條記錄的所有字段在物理上相鄰存儲(chǔ)。

[1, “Alice”, 29, “USA”], [2, “Bob”, 34, “Canada”]

這意味著，如果你需要讀取或更新完整的一行記錄（比如用戶#2），系統(tǒng)可以一次性獲取所有字段。這種存儲(chǔ)方式適合事務(wù)型工作負(fù)載，常用于需要頻繁插入、更新和讀取整條記錄的場景。

IDs: [1, 2] 
Names: [“Alice”, “Bob”] 
Ages: [29, 34] 
Countries: [“USA”, “Canada”]

最適合：OLTP 系統(tǒng)（如 MySQL、PostgreSQL）；頻繁插入/更新操作；記錄級訪問（如用戶檔案、訂單信息）。

b. 列式存儲(chǔ)（Columnar Storage）

列式存儲(chǔ)則按列組織數(shù)據(jù)——同一列的所有值連續(xù)存放在一起。此時(shí)，如果你只想執(zhí)行如下查詢：

SELECTAVG(age)FROM users;

系統(tǒng)只需掃描“年齡”這一列，跳過其他所有字段，從而大幅提升大數(shù)據(jù)集分析查詢的效率。

最適合：OLAP 系統(tǒng)（如 BigQuery、Snowflake、Redshift）；大規(guī)模掃描、聚合和篩選；高壓縮存儲(chǔ)需求。

6.數(shù)據(jù)分區(qū)（Partitioning）

數(shù)據(jù)分區(qū)是指將大型數(shù)據(jù)集按一定規(guī)則拆分成更小、更易管理的邏輯塊，從而提升查詢性能、降低資源消耗，并優(yōu)化數(shù)據(jù)的存儲(chǔ)和訪問效率。

舉例來說：假設(shè)你經(jīng)營一家披薩外賣公司，所有訂單信息都存儲(chǔ)在 orders 表中。

圖片

當(dāng)你嘗試運(yùn)行如下 SQL 查詢某一天的訂單：

SELECT * 
FROM orders 
WHERE order_date = '2025-07-31';

未做分區(qū)時(shí)：數(shù)據(jù)庫必須逐行掃描整個(gè)訂單表，才能篩選出符合日期條件的數(shù)據(jù)。

按 order_date 分區(qū)后：訂單表會(huì)按日期劃分為多個(gè)物理區(qū)塊（例如每天一個(gè)分區(qū)）。

圖片

此時(shí)再執(zhí)行同一查詢，數(shù)據(jù)庫只會(huì)讀取 2025-07-31 對應(yīng)的分區(qū)文件夾，自動(dòng)跳過其他無關(guān)數(shù)據(jù)。查詢速度因此大幅提升。

適用場景：時(shí)間序列數(shù)據(jù)（如日志、訂單、事件流）；需要頻繁按某一維度篩選（如日期、地區(qū)、類別）；大型表查詢性能優(yōu)化。

圖片

7.ETL vs ELT：兩種數(shù)據(jù)流程架構(gòu)

在數(shù)據(jù)工程中，ETL 和 ELT 是兩種常見的數(shù)據(jù)處理流程架構(gòu)，它們在數(shù)據(jù)提取、轉(zhuǎn)換和加載的順序及執(zhí)行環(huán)境上存在顯著差異。

a. ETL（提取-轉(zhuǎn)換-加載）

ETL 是一種傳統(tǒng)的數(shù)據(jù)流程方法，其過程分為三步：

• 提取：從數(shù)據(jù)庫、API、文件或應(yīng)用等源系統(tǒng)中抽取數(shù)據(jù)。
• 轉(zhuǎn)換：在數(shù)據(jù)到達(dá)目標(biāo)系統(tǒng)之前，通過獨(dú)立的處理引擎進(jìn)行清洗、過濾、去重、格式轉(zhuǎn)換等操作。
• 加載：將處理后的數(shù)據(jù)載入數(shù)據(jù)倉庫或數(shù)據(jù)庫，供分析使用。

圖片

適用場景：需要在加載前確保數(shù)據(jù)質(zhì)量和一致性；基于本地或傳統(tǒng)基礎(chǔ)設(shè)施構(gòu)建；需在存儲(chǔ)前。執(zhí)行復(fù)雜的業(yè)務(wù)邏輯或規(guī)則

b. ELT（提取-加載-轉(zhuǎn)換）

ELT 是一種更現(xiàn)代的流程架構(gòu)：

• 提取：從源系統(tǒng)獲取數(shù)據(jù)。
• 加載：直接將原始數(shù)據(jù)加載到數(shù)據(jù)倉庫中。
• 轉(zhuǎn)換：利用數(shù)據(jù)倉庫內(nèi)置的計(jì)算能力（通常通過 SQL 或 dbt 等工具）在庫內(nèi)進(jìn)行轉(zhuǎn)換。

圖片

適用場景：使用云數(shù)據(jù)倉庫（如 Snowflake、BigQuery、Redshift）；希望保留原始數(shù)據(jù)以備后續(xù)使用；需要快速數(shù)據(jù)接入和靈活的轉(zhuǎn)換能力。

8.CAP 定理

CAP 定理指出，任何分布式數(shù)據(jù)系統(tǒng)最多只能同時(shí)保證以下三個(gè)特性中的兩個(gè)：

• 一致性（Consistency）：所有用戶在同一時(shí)刻讀取到的都是相同的數(shù)據(jù)
• 可用性（Availability）：每一個(gè)請求都能獲得響應(yīng)，即使返回的不是最新數(shù)據(jù)
• 分區(qū)容錯(cuò)性（Partition Tolerance）：即使部分網(wǎng)絡(luò)發(fā)生故障，系統(tǒng)仍能繼續(xù)運(yùn)行

圖片

在實(shí)際應(yīng)用中，我們需要根據(jù)業(yè)務(wù)場景做出權(quán)衡：

訂單處理系統(tǒng)通常選擇 CP（一致性 + 分區(qū)容錯(cuò)性）：寧可暫時(shí)拒絕訂單，也不能出現(xiàn)重復(fù)下單或數(shù)據(jù)錯(cuò)亂——此時(shí)可以犧牲一定的可用性。

餐廳搜索功能則更適合 AP（可用性 + 分區(qū)容錯(cuò)性）：即使返回的結(jié)果略有延遲，也比完全無法提供服務(wù)要好——因此可以接受一定程度的數(shù)據(jù)不一致。

9.流處理中的窗口機(jī)制（Windowing）

窗口機(jī)制是一種將無界數(shù)據(jù)流按時(shí)間或數(shù)量劃分為有限數(shù)據(jù)塊（窗口）的方法，以便進(jìn)行聚合計(jì)算、指標(biāo)統(tǒng)計(jì)或觸發(fā)告警。

就像把一部永不結(jié)束的電影切成5分鐘的片段，逐段分析劇情。常見的窗口類型：

a. 滾動(dòng)窗口（Tumbling Window）

• 固定大小、不重疊的時(shí)間區(qū)間
• 每個(gè)事件只屬于一個(gè)窗口
• 示例：每分鐘統(tǒng)計(jì)一次用戶數(shù)量
• 窗口示例：[12:00–12:01)，[12:01–12:02)…

b. 滑動(dòng)窗口（Sliding Window）

• 固定大小的窗口按更小間隔滑動(dòng)
• 事件可能屬于多個(gè)窗口，窗口之間有重疊

示例：每1分鐘計(jì)算一次過去5分鐘的平均值

• 窗口示例：[12:00–12:05)，[12:01–12:06)…

c. 會(huì)話窗口（Session Window）

• 基于用戶活動(dòng)的動(dòng)態(tài)窗口，一段時(shí)間無活動(dòng)后自動(dòng)關(guān)閉
• 示例：將用戶點(diǎn)擊行為分組，間隔超過30秒則開啟新會(huì)話

d. 計(jì)數(shù)窗口（Count Window）

• 基于事件數(shù)量（而非時(shí)間）劃分窗口
• 示例：每100個(gè)事件計(jì)算一次總和
• 窗口示例：[1–100]，[101–200]…

處理延遲數(shù)據(jù)時(shí)，建議采用事件時(shí)間+水印機(jī)制，確保計(jì)算結(jié)果的準(zhǔn)確性。

10.有向無環(huán)圖（DAG）與工作流編排

隨著數(shù)據(jù)系統(tǒng)日益復(fù)雜，如何協(xié)調(diào)任務(wù)執(zhí)行的內(nèi)容、時(shí)機(jī)與順序，已成為數(shù)據(jù)工程中的關(guān)鍵環(huán)節(jié)。此時(shí)，有向無環(huán)圖（DAG） 和工作流編排便發(fā)揮了核心作用。

它們就像樂隊(duì)的指揮，確保數(shù)據(jù)管道中的每個(gè)任務(wù)協(xié)調(diào)運(yùn)作、有序執(zhí)行。

a. 什么是有向無環(huán)圖（DAG）？

圖片

DAG 是工作流編排工具中用于定義任務(wù)流程的一種結(jié)構(gòu)：

• 有向（Directed）：任務(wù)之間有明確的執(zhí)行順序（如 A → B → C）
• 無環(huán)（Acyclic）：不允許出現(xiàn)循環(huán)或回退（不能從后任務(wù)跳回前任務(wù)）
• 圖（Graph）：由節(jié)點(diǎn)（任務(wù)）和邊（依賴關(guān)系）組成

可以把它想象成一個(gè)流程圖：箭頭標(biāo)明執(zhí)行順序，任務(wù)按依賴關(guān)系依次觸發(fā)。

b. 什么是工作流編排？

工作流編排是指對一系列（通常相互依賴的）任務(wù)進(jìn)行定義、調(diào)度和監(jiān)控的過程，以實(shí)現(xiàn)數(shù)據(jù)管道、機(jī)器學(xué)習(xí)訓(xùn)練、ETL任務(wù)等的自動(dòng)化運(yùn)行。

簡單來說：它是一種協(xié)調(diào)機(jī)制，確保多個(gè)數(shù)據(jù)任務(wù)能以正確的順序、依賴關(guān)系和容錯(cuò)機(jī)制穩(wěn)定執(zhí)行。

11.重試機(jī)制與死信隊(duì)列

關(guān)鍵不在于杜絕問題，而在于如何妥善應(yīng)對。

構(gòu)建健壯數(shù)據(jù)管道的兩大核心策略是：

• 重試機(jī)制：在發(fā)生臨時(shí)性故障時(shí)自動(dòng)重試
• 死信隊(duì)列（DLQ）：隔離并記錄持續(xù)失敗的事件

二者結(jié)合使用，可顯著提升管道的容錯(cuò)性、可觀測性和可恢復(fù)性。

a. 什么是重試機(jī)制？

重試機(jī)制是一種故障應(yīng)對策略：當(dāng)任務(wù)執(zhí)行失敗時(shí)，系統(tǒng)不會(huì)立即放棄，而是自動(dòng)嘗試重新執(zhí)行。

典型重試場景包括：

• 網(wǎng)絡(luò)波動(dòng)或瞬時(shí)超時(shí)
• 臨時(shí)性的服務(wù)不可用
• 資源短暫擁塞

b. 什么是死信隊(duì)列（DLQ）？

死信隊(duì)列是一個(gè)特殊的緩沖隊(duì)列，用于存放經(jīng)過多次重試仍無法被正常處理的消息或事件，避免它們阻塞主流數(shù)據(jù)管道。

可以把 DLQ 看作一個(gè)“數(shù)據(jù)隔離區(qū)”，專門收納那些格式錯(cuò)誤、無法處理或持續(xù)失敗的數(shù)據(jù)，便于后續(xù)排查與修復(fù)。

12.數(shù)據(jù)回填與重新處理

作為數(shù)據(jù)工程師，我們的職責(zé)不僅是搬運(yùn)數(shù)據(jù)，更要確保數(shù)據(jù)正確、完整、可信——即使在出現(xiàn)問題之后。

這正是數(shù)據(jù)回填（Backfilling）和重新處理（Reprocessing）的意義所在。

它們幫助我們在發(fā)生故障、邏輯錯(cuò)誤或 schema 變更后，依然保證數(shù)據(jù)的完整性、準(zhǔn)確性和可靠性。

a. 什么時(shí)候需要重新處理（Reprocessing）？

重新處理是指對已處理過但存在錯(cuò)誤或邏輯過時(shí)的數(shù)據(jù)，重新執(zhí)行計(jì)算過程。常見場景包括：

• 轉(zhuǎn)換邏輯出現(xiàn)錯(cuò)誤（如錯(cuò)誤的聚合公式）
• 業(yè)務(wù)規(guī)則變更，需調(diào)整輸出結(jié)果
• 數(shù)據(jù)格式轉(zhuǎn)換（如 CSV → Parquet）
• 修復(fù)錯(cuò)誤的關(guān)聯(lián)查詢、錯(cuò)誤查詢或貨幣換算

 示例：你發(fā)現(xiàn)訂單金額匯總邏輯有誤，需對過去7天的數(shù)據(jù)重新計(jì)算并更新結(jié)果。

b. 什么時(shí)候需要數(shù)據(jù)回填（Backfilling）？

回填是指對因故未能及時(shí)處理的某一時(shí)段歷史數(shù)據(jù)，進(jìn)行補(bǔ)處理。常見場景包括：

• 數(shù)據(jù)管道故障（如 Airflow DAG 暫停運(yùn)行3天）
• 數(shù)據(jù)源延遲上傳
• 流式數(shù)據(jù)中的延遲到達(dá)事件
• 新增表或分區(qū)
• 新邏輯需要覆蓋歷史數(shù)據(jù)

示例：由于上游API問題，7月15–17日的銷售任務(wù)執(zhí)行失敗。修復(fù)后，需專門針對這三天重新運(yùn)行管道，補(bǔ)全數(shù)據(jù)。

13.數(shù)據(jù)治理（Data Governance）

數(shù)據(jù)治理是一套集政策、流程、角色和工具于一體的管理體系，旨在確保企業(yè)中的數(shù)據(jù)達(dá)到以下目標(biāo)：

• 可用可控：數(shù)據(jù)易于查找、訪問且使用規(guī)范
• 準(zhǔn)確一致：數(shù)據(jù)可靠、統(tǒng)一，值得信賴
• 安全合規(guī)：數(shù)據(jù)受到保護(hù)，滿足隱私和監(jiān)管要求

為什么在系統(tǒng)設(shè)計(jì)中至關(guān)重要？

• 信任與質(zhì)量：低質(zhì)量數(shù)據(jù)會(huì)導(dǎo)致錯(cuò)誤洞察，削弱數(shù)據(jù)產(chǎn)品的可信度。數(shù)據(jù)治理通過執(zhí)行標(biāo)準(zhǔn)保障數(shù)據(jù)一致性和準(zhǔn)確性。
• 安全與權(quán)限管控：系統(tǒng)需明確定義不同角色在何種條件下可訪問哪些數(shù)據(jù)，并集成身份認(rèn)證、權(quán)限管理及加密機(jī)制。
• 合規(guī)性要求：GDPR、HIPAA、CCPA 等法規(guī)對數(shù)據(jù)處理、血緣追蹤、用戶授權(quán)和數(shù)據(jù)留存提出嚴(yán)格要求。缺乏合規(guī)控制可能引發(fā)法律風(fēng)險(xiǎn)與聲譽(yù)損失。

14.數(shù)據(jù)時(shí)間旅行與版本控制

隨著數(shù)據(jù)量與復(fù)雜度的不斷提升，能夠追溯數(shù)據(jù)在任意歷史時(shí)刻的狀態(tài)變得愈發(fā)關(guān)鍵。無論是調(diào)試數(shù)據(jù)管道、合規(guī)審計(jì)、基于歷史快照訓(xùn)練模型，還是意外數(shù)據(jù)損壞后的恢復(fù)，時(shí)間旅行與數(shù)據(jù)版本控制都為這些需求提供了可靠的技術(shù)基礎(chǔ)。

什么是數(shù)據(jù)時(shí)間旅行（Time Travel）？

時(shí)間旅行功能允許用戶查詢數(shù)據(jù)在歷史上某個(gè)特定時(shí)間點(diǎn)或特定版本的狀態(tài)。就像為數(shù)據(jù)提供了一個(gè)“回放按鈕”，你可以回退至某一時(shí)刻、比對不同時(shí)期的數(shù)據(jù)狀態(tài)，或執(zhí)行時(shí)點(diǎn)分析。

通俗來說，就像數(shù)據(jù)層的“撤銷操作”或 git checkout，讓歷史數(shù)據(jù)狀態(tài)可查、可溯、可復(fù)用。

示例：某訂單表在周一誤刪了一批數(shù)據(jù)，借助時(shí)間旅行功能，可快速查詢周日23:59的數(shù)據(jù)狀態(tài)并進(jìn)行恢復(fù)。

什么是數(shù)據(jù)版本控制（Data Versioning）？

數(shù)據(jù)版本控制是對數(shù)據(jù)集隨時(shí)間變更進(jìn)行系統(tǒng)性跟蹤和管理的機(jī)制。它會(huì)在每次數(shù)據(jù)修改時(shí)創(chuàng)建檢查點(diǎn)或提交記錄——類似于用 Git 管理代碼版本。其管控范圍不僅包括表或文件，還可擴(kuò)展至 schema、元數(shù)據(jù)甚至邏輯定義（如轉(zhuǎn)換規(guī)則）。

從設(shè)計(jì)層面看，版本控制可在以下層級實(shí)現(xiàn)：

• 行級版本控制：記錄行級別數(shù)據(jù)變更
• 表級版本控制：保存整張表的快照
• 管道級版本控制：對管道輸出結(jié)果或模型訓(xùn)練數(shù)據(jù)進(jìn)行版本化管理

示例：訓(xùn)練機(jī)器學(xué)習(xí)模型時(shí)，可明確指定使用某版本的數(shù)據(jù)集，確保實(shí)驗(yàn)可復(fù)現(xiàn)、結(jié)果可追溯。

15.分布式處理核心概念

當(dāng)數(shù)據(jù)規(guī)模超出單機(jī)能力時(shí)，分布式處理成為數(shù)據(jù)工程的關(guān)鍵手段。其核心思想是將數(shù)據(jù)任務(wù)拆分為多個(gè)小塊，并通過集群中的多臺(tái)機(jī)器（節(jié)點(diǎn)）并行執(zhí)行。包含一下幾個(gè)核心原理：

數(shù)據(jù)分區(qū)（Partitioning）

數(shù)據(jù)分區(qū)是指按照一定規(guī)則（如日期、地區(qū)、客戶等）將數(shù)據(jù)拆分為更小的邏輯塊

分桶（Bucketing）

以圖書館為例：首先按書籍類型分區(qū)（小說類、歷史類、科幻類…），但每個(gè)分區(qū)內(nèi)書籍仍然很多。此時(shí)可進(jìn)一步按作者姓氏首字母分桶（A-Z），將圖書歸到不同的書架上。

在數(shù)據(jù)工程中，分桶是指在每個(gè)分區(qū)內(nèi)，按照列的哈希值或其他規(guī)則將數(shù)據(jù)劃分為更小的存儲(chǔ)單元（例如按 customer_id 分桶），可顯著提升分區(qū)內(nèi)的關(guān)聯(lián)查詢和點(diǎn)查效率。

數(shù)據(jù)傾斜（Data Skew）

數(shù)據(jù)傾斜指數(shù)據(jù)在分區(qū)、分桶或節(jié)點(diǎn)間分布不均，導(dǎo)致部分任務(wù)負(fù)載遠(yuǎn)高于其他任務(wù)。

示例：90% 的銷售數(shù)據(jù)集中來自 customer_id=1000 的客戶。在按 customer_id 進(jìn)行關(guān)聯(lián)或聚合時(shí)，處理該客戶數(shù)據(jù)的節(jié)點(diǎn)將成為瓶頸，其他節(jié)點(diǎn)早早空閑，整體任務(wù)延遲。

應(yīng)對數(shù)據(jù)傾斜的常見方法：

• 加鹽（Salting）：為傾斜的鍵添加隨機(jī)前綴（如1000_1、1000_2），將數(shù)據(jù)分散到多個(gè)桶中，處理完成后再聚合結(jié)果
• 廣播（Broadcasting）：將小數(shù)據(jù)集復(fù)制到所有工作節(jié)點(diǎn)，避免網(wǎng)絡(luò)傳輸和大表Shuffle
• 調(diào)整分區(qū)鍵：使用復(fù)合鍵（如 customer_id + region）或更換分布更均勻的列作為分區(qū)鍵

數(shù)據(jù)洗牌（Shuffling）

洗牌是指在分布式系統(tǒng)中根據(jù)鍵值重新分布數(shù)據(jù)的過程，通常發(fā)生在分組、關(guān)聯(lián)和排序等操作中。 類比：一個(gè)房間里每個(gè)人隨機(jī)拿著一些信件，現(xiàn)在需要按郵政編碼重新整理，大家必須走動(dòng)并將信件放到對應(yīng)郵編的桌子上——這個(gè)過程耗時(shí)且資源密集。

容易觸發(fā)洗牌的操作：Group By / 聚合；Join（尤其鍵值分布在不同節(jié)點(diǎn)時(shí)）；Order By / 排序。

優(yōu)化建議：盡量通過廣播、預(yù)分區(qū)等技術(shù)減少洗牌，避免寬依賴操作。

這15個(gè)系統(tǒng)設(shè)計(jì)概念，正是數(shù)據(jù)工程從“腳本小子”到“平臺(tái)架構(gòu)”的關(guān)鍵分水嶺。它們不是孤立的術(shù)語，而是一套相互關(guān)聯(lián)、支撐現(xiàn)代數(shù)據(jù)系統(tǒng)的思維框架。