定義

資料合約最近幾年才出現在資料領域（儘管與手機流量合約和加密貨幣的智能合約有點混淆），然而，其背後的概念和用法並不新穎。這個概念的開發或多或少是一種對大數據和2010年代的興起的“先丟到資料湖（Data Lake）裡再考慮怎麼處理”的資料工程趨勢的反應。

簡單來說，資料合約是資料生產者（Data Producer）與資料消化者（Data Consumer）之間的正式協議，用於定義資料集的結構、格式和含義。這句話有很多重點要解讀，讓我們來深入研究一下！

正式協議

從傳統軟體開發的角度來看，所有的協議（Protocol）都一定要是正式的協議，不合協議格式定義的資料都會直接被拒絕。但由於資料工程與資料棧的設計一般都是考慮單向資料流的，對資料處理的態度更像是軟體工程的事後的補救措施，因此通常沒有強制執行協議的能力。

另外，由於資料棧一般架構在高階的系統上（設計上更抽象，不是更“高級”），一般違反協議的事件不會直接造成處理系統故障，只有到下游的資料處理管道裡才會體現問題。

資料合約的推行者主張的是應該回歸（或至少靠近）更嚴格的定義與執行協議合約，確保資料的質量和監管。

結構、格式

從資料模型的設計上來說，結構與格式的定義很接近，但還是有稍微差別的：

• 格式：有關低階資料解析與字串值的定義，像是編碼、分隔符和引用符號等。
• 結構：列名、數據類型和約束（例：唯一性、值範圍）。有時也是泛指資料集的元數據（meta-data）。

這兩個點主要是在反映之前提到的資料湖設計裡，最讓資料人痛苦的問題。資料源的格式或結構上出問題都是硬傷，基本上來說沒什麼簡單的處理辦法，只能一個一個問題依序解決。

含義

這個比較抽象，而也是比較難以資料系統上的定義來理解。當資料結構或格式上出錯時，一般來說比較容易理解：

1 != '1'
“2022-01-01” vs "2022/01/01"

但含義的定義就比較微妙。從概念上可以解讀成“這個資料列/欄是什麼意思？”。

譬如說，有一欄資料叫做is_active_user（是活躍用戶）。這欄資料的值永遠只有true和false，但是資料生產者與消化者對於”活躍用戶“的定義有沒有共識，其實是另一個問題。就算在列創建的當下有達到共識的，經過一段時間的修改，這個資料的定義是否有改變也很難說。

因為越來越多的組織正在採用分佈式資料架構，準確與維持對資料的含義的共識變得越來越複雜。

對 dbt 或 data 有興趣 :wave:？歡迎加入 dbt community 到 #local-taipei 找我們，也有實體 Meetup 請到 dbt Taipei Meetup 報名參加