在數位轉型浪潮下，資料品質已成為企業成功的根本。從雲端遷移到自助式分析，資料的可靠性直接影響業務決策的有效性。本文探討企業如何提升資料品質，涵蓋資料可觀測性、資料血緣管理、自動化資料品品檢查等實踐方法，並分析資料倉函式庫與資料湖融合的趨勢對資料品質的影響。
資料品質的重要性：企業數位轉型的關鍵
在當今資料驅動的商業環境中，資料品質已成為企業成功的關鍵因素。無論是進行雲端遷移、擴充套件資料堆積疊，還是採用自助式分析模型，資料品質都是不可忽視的核心議題。本文將探討企業何時需要開始關注資料品質，並提供實際案例與深入分析。
為什麼資料品質至關重要
1. 雲端遷移與資料可靠性
當企業進行雲端遷移時，無論是從本地佈署系統遷移到雲端，還是更換雲端平台（如從Amazon Redshift遷移到Snowflake），確保資料品質是首要任務。遷移的主要原因包括：
- 當前資料平台效能不佳，導致資料可靠性低
- 現有平台無法滿足業務擴充套件需求，需要更強大的資料處理能力
- 現有平台營運成本過高，需要更經濟高效的解決方案
以AutoTrader UK為例，在進行雲端資料函式庫遷移時，投資於資料可觀測性（data observability）是關鍵步驟。公司確保新系統的可靠性與舊系統相當，從而贏得使用者的信任。
2. 資料堆積疊的擴充套件與複雜性
隨著資料產品規模的擴大，資料來源、資料管道和資料表的數量不斷增加，資料品質的管理變得更加重要。雖然沒有明確的門檻，但當資料表數量超過50張時，通常需要考慮投資資料可觀測性。
Choozle公司在進行平台升級時預見到資料表數量激增的問題，因此提前投資於資料監控和警示系統，以確保資料的同步性和時效性。
何時需要開始關注資料品質
1. 資料團隊擴張
當企業重視資料驅動決策時，通常會擴大資料團隊規模。然而，這也帶來了新的挑戰：
- 資料團隊結構變化（從集中式到分散式）
- 新成員需要學習現有資料集的知識
- 資料治理和知識傳承問題
投資於資料認證計畫和端對端資料血緣（data lineage）管理，可以有效解決這些問題。
2. 資料團隊花費大量時間處理資料品質問題
研究表明，超過60% 的資料團隊花費大量時間（30%至50%）處理資料品質問題，包括修復故障的資料管道、錯誤的資料模型和過時的儀錶板。
3. 資料消費者數量增加
隨著企業快速成長，依賴資料的業務利益相關者越來越多，對資料的需求也更加多樣化。這增加了資料生態系統中出現錯誤資料的可能性。
AutoTrader UK 的經驗表明，當超過50%的員工每月登入並使用資料分析工具（如Looker）時，資料品質的重要性不言而喻。
4. 轉向自助式分析模型
自助式分析模型允許業務使用者直接存取和操作資料，減少了對資料工程團隊的依賴。然而，這也要求資料具有高度的可靠性和可信度。
資料品質問題可以分為可預測的（已知未知）和不可預測的（未知未知）。隨著資料在企業營運中的作用越來越重要，資料可靠性成為成功的關鍵。
5. 資料成為客戶價值主張的重要組成部分
越來越多的應用程式正在變成資料應用程式。當企業利用資料為客戶提供新的價值時，資料品質直接影響客戶體驗和企業競爭力。
Toast公司透過為餐廳客戶提供詳細的業務洞察資料，成功地將資料轉化為競爭優勢。
如何提升資料品質
- 投資資料可觀測性：實施資料監控和警示系統，及時發現和解決資料問題。
- 建立資料認證計畫：確保資料的準確性和可靠性。
- 實施端對端資料血緣管理：追蹤資料的來源、處理過程和使用情況。
- 採用自動化資料品品檢查：減少人工檢查的工作量，提高效率。
- 培養資料文化：在企業內部推廣資料驅動決策的文化，提高全員的資料意識。
內容解密：
這段SQL查詢用於檢查資料函式庫中各個表的資料品質。它統計了每個表的行數和特定欄位的唯一值數量。透過分析這些指標，可以發現空表或重複資料的問題，從而採取相應的最佳化措施。
graph LR
A[資料來源] --> B[資料處理]
B --> C[資料儲存]
C --> D[資料分析]
D --> E[資料視覺化]
E --> F[業務決策]
圖表翻譯： 此圖示展示了資料從來源到最終業務決策的整個流程。首先，資料從各種來源收集並經過處理，接著儲存在資料倉儲中。然後，資料被分析並轉化為視覺化的報表，最終用於支援業務決策。
隨著企業對資料依賴程度的加深，資料品質的重要性將進一步提升。未來，我們可以預見以下趨勢：
- 資料治理將更加完善：企業將建立更完善的資料治理體系，確保資料的準確性和可靠性。
- 自動化資料品品檢查將成為常態：隨著AI和機器學習技術的發展，自動化資料品品檢查將更加普遍。
- 資料可觀測性將成為企業標配：企業將普遍採用資料可觀測性工具，實時監控資料狀態。
總之，資料品質是企業在數位時代成功的根本。透過持續改進資料管理實踐，企業可以充分發揮資料的潛力，推動業務成長。
開創可靠資料系統的未來
隨著資料分析與資料工程技術的發展，資料作為產業正經歷著一場巨大的、不可逆轉的變革。五年前，資料通常被分散儲存於不同部門，且僅在特定需求時才會被存取。然而，現在的分析資料已成為現代企業最關鍵的競爭力。企業不再只是收集資料，更需要信任這些資料。
資料可靠性成為核心議題
諸如雲端資料倉儲、資料湖、資料目錄、開源測試框架和資料可觀察性解決方案等技術，都在為資料可靠性提供更多的功能和特性。像是 Snowflake 和 Redshift 這類別的資料倉儲，能夠輕鬆提取資料品質的相關指標；而 dbt 和 Great Expectations 等開源工具，則能讓資料從業者快速進行關鍵資料集的單元測試。甚至像 Alation 和 Collibra 這類別的資料目錄，也能夠在特定時間點提供資料完整性和可發現性的洞察。
然而，這些新興技術僅僅是提供了更多的可能性；最終，資料品質仍然取決於良好的文化、健全的流程和利害關係人的支援。 Shane Murray，前《紐約時報》資料與分析部門的高階副執行長，在訪談中強調，資料品質的優先順序往往應高於資料目錄和資料探索等專案。
「如果您不知道用來建立產品、支援分析或幫助利害關係人做出更明智決策的資料是否最新或準確，那麼您的資料堆積疊就很難產生價值，」Murray 說。「一旦資料被與下游利害關係人分享，您就必須確保這些資料是可信賴的。」
資料信任的重要性
資料信任對於任何成功的資料工程或分析計畫都至關重要，但實作並維持資料信任卻非常具有挑戰性。正如我們的同事 Michael Segner 所說：「資料信任很難建立，但很容易失去。」而且，推動資料品質的採用、資源和預算往往比預期更加困難。
大多陣列織直到資料品質問題造成損失後，才開始重視資料品質。諸如架構變更導致下游報告結果異常、資料更新異常導致使用者行為資料不準確、或是 dbt 模型失敗導致 CEO 對分析結果的有效性產生懷疑等問題，都凸顯了資料品質的重要性。
量化資料品質的價值
在第五章中，我們提出了一個計算資料停機時間（Data Downtime）的公式，這有助於我們理解資料品質問題的影響。資料停機時間的計算公式如下：
DDT = N(TTD + TTR)
其中，DDT 代表資料停機時間，N 是事件數量，TTD 是檢測時間，TTR 是解決時間。
這個公式能夠告訴我們識別和解決資料品質事件所需的時間。然而，我們如何評估良好的資料品質的價值，以便更好地為資料品質投資辯護？在沒有資料停機災難的情況下，我們該如何推動資料品質的重要性？
推動資料品質的文化變革
正如任何工程或產品開發團隊都會告訴你的，採用新的流程和文化是一段旅程，而非短跑。對於資料工程師和分析師來說，這意味著需要時間來培養資料品質的文化，並將其融入日常工作中。
程式碼範例：資料品品檢查
import great_expectations as ge
# 定義資料品品檢查的範例
def data_quality_check(data):
# 建立 Great Expectations 的 context
context = ge.data_context.DataContext()
# 定義資料的 expectation suite
expectation_suite = context.get_expectation_suite("my_suite")
# 驗證資料
validation_result = context.verify_data(
data,
expectation_suite=expectation_suite
)
# 檢查驗證結果
if validation_result.success:
print("資料品品檢查透過！")
else:
print("資料品品檢查失敗！")
for error in validation_result.results:
print(f"錯誤：{error.expectation_config.expectation_type}")
# 使用範例資料進行檢查
data = [
{"name": "Alice", "age": 30},
{"name": "Bob", "age": 25}
]
data_quality_check(data)
內容解密：
這段程式碼展示瞭如何使用 Great Expectations 進行資料品品檢查。首先，我們定義了一個 data_quality_check 函式，它接受資料作為輸入，並使用 Great Expectations 的 DataContext 來取得 expectation suite。然後，我們對資料進行驗證，並根據驗證結果輸出檢查結果。如果檢查失敗，我們會列出具體的錯誤資訊。
在未來，我們預計資料可靠性將繼續成為企業的核心議題。隨著資料量的增長和資料應用場景的多樣化，企業需要更加重視資料品質和資料信任。我們相信，透過不斷改進資料品質的文化、流程和技術，企業能夠更好地應對資料品質挑戰，並實作資料驅動的業務成功。
資料品質的重要性
graph LR
A[資料品質] --> B[資料信任]
A --> C[業務決策]
B --> D[資料驅動]
C --> D
D --> E[業務成功]
圖表翻譯： 此圖表展示了資料品質與資料信任之間的關係，以及它們如何影響業務決策和最終的業務成功。資料品質是基礎，它直接影響資料信任和業務決策的準確性。資料信任和業務決策共同推動企業實作資料驅動的業務模式，最終帶來業務成功。
主動預防資料停機：開發可靠的資料系統
在當今資料驅動的商業環境中，資料品質對於企業的成功至關重要。然而，隨著企業需要處理的資料量不斷增加，同時需要滿足多個利益相關者的需求，因此很難抽出時間進行主動措施。
主動出擊，而非被動反應
或許我們不需要看得太遠，就能理解為什麼為資料可靠性架構設計，而不是被動地處理資料問題，是對團隊時間的寶貴利用。2022 年 5 月，遊戲軟體公司 Unity Technologies 發生了一起資料停機事件，這起事件讓我們明白了主動預防資料問題的重要性。
2022 年 5 月 11 日，Unity 的股票暴跌 36%，原因是過時的資料被用於其廣告變現工具長達一個季度以上。累積幾個季度後，這個資料品質事件使公司損失了 1.1 億美元的收入。如果連最具創新力和技術實力的公司都無法預防資料停機，那麼對於其他企業來說，優先考慮資料信任的重要性就更加迫切了。
雖然最近發生的資料事故可以增加我們優先考慮資料信任的動力，但主動出擊才是正確的做法。正如 Neil Diamond 在 1978 年的經典歌曲《Forever in Blue Jeans》中唱道：「金錢不會說話，它會走路。」這同樣適用於資料品質。只有當壞資料導致金錢「走路」時，我們才會清楚地認識到好資料的價值。
因此，推動資料品質的第一步是衡量資料可靠性對業務的財務影響。為了讓企業更容易為資料品質辯護，我們提出了一個年度資料停機勞動成本的計算方法。換句話說，就是企業處理資料品質問題的大致成本。簡單來說，這個計算歸結為：資料工程師數量 × 1,804 × 62 美元 × 資料停機時間。
內容解密：
這個公式的關鍵在於計算企業每年因資料品質問題而浪費的時間。首先，我們需要計算出公司每年處理資料品質問題的小時數。根據 Monte Carlo 團隊的發現，每年平均有 1/15 的資料表會受到資料事故的影響。2022 年與 Wakefield Research 進行的調查顯示，大多數受訪的資料工程師聲稱，發現資料問題平均需要 4 小時以上，解決問題平均需要 9 小時。
# 定義計算資料停機時間的函式
def calculate_data_downtime(num_tables, data_quality_maturity):
# 根據資料品質成熟度設定 TTD 和 TTR 的總和
if data_quality_maturity == 'low':
total_hours = 8
elif data_quality_maturity == 'average':
total_hours = 6
elif data_quality_maturity == 'high':
total_hours = 4
# 計算資料停機時間
data_downtime_hours = min((num_tables / 15) * total_hours, 8760)
return data_downtime_hours
# 測試函式
num_tables = 5000
data_quality_maturity = 'average'
data_downtime = calculate_data_downtime(num_tables, data_quality_maturity)
print(f"資料停機時間：{data_downtime} 小時")
內容解密：
上述程式碼定義了一個函式 calculate_data_downtime，用於計算資料停機時間。函式接受兩個引數：資料表的數量 (num_tables) 和資料品質成熟度 (data_quality_maturity)。根據資料品質成熟度，函式設定了不同的 TTD 和 TTR 總和，然後計算出資料停機時間，並限制最大值為 8760 小時（即一年中的總小時數）。
計算財務影響
我們的計算顯示，資料停機的財務影響（即資料事故對公司的貨幣成本）介於資料工程師時間的 20%、35% 和 50% 之間，具體取決於企業的資料品質成熟度。然後將這個百分比乘以公司僱傭的資料工程師數量，再乘以根據 2022 年 2 月勞工部統計的平均年工作小時數（1,804），最後乘以根據 Glassdoor 統計的資料工程師平均時薪（62 美元）：
# 定義計算財務影響的函式
def calculate_financial_impact(num_data_engineers, data_quality_maturity):
# 根據資料品質成熟度設定百分比
if data_quality_maturity == 'low':
percentage = 0.5
elif data_quality_maturity == 'average':
percentage = 0.35
elif data_quality_maturity == 'high':
percentage = 0.2
# 計算財務影響
financial_impact = num_data_engineers * 1804 * 62 * percentage
return financial_impact
# 測試函式
num_data_engineers = 5
data_quality_maturity = 'average'
financial_impact = calculate_financial_impact(num_data_engineers, data_quality_maturity)
print(f"財務影響：${financial_impact:.2f}")
內容解密：
上述程式碼定義了一個函式 calculate_financial_impact，用於計算資料停機的財務影響。函式接受兩個引數：資料工程師的數量 (num_data_engineers) 和資料品質成熟度 (data_quality_maturity)。根據資料品質成熟度，函式設定了不同的百分比，然後計算出財務影響。
結合例項分析
假設一家公司有 5,000 張資料表，平均資料品質衛生（即資料清理和測試足夠，但不完美），5 名資料工程師，平均 TTD 和 TTR 為 8 小時。根據這個邏輯，每年的資料停機時間為 2,664 小時，勞動力成本為 279,620 美元。
graph LR
A[資料表數量] --> B[計算資料停機時間]
B --> C[計算財務影響]
C --> D[輸出結果]
D --> E[決策依據]
圖表翻譯： 此圖示展示了計算資料停機時間和財務影響的流程。首先，根據資料表的數量計算資料停機時間；然後，根據資料工程師的數量和資料品質成熟度計算財務影響；最後，輸出結果並作為決策的依據。
內容解密：
這個流程圖清晰地展示了從資料表數量到最終決策依據的整個過程。透過這個流程，企業可以更好地理解資料停機時間和財務影響之間的關係，並根據結果做出相應的決策。
未來資料品質與可靠性的預測
建立健全的資料實踐，不僅僅是在資料停機時保持主動。瞭解該領域的發展方向並積極管理組織的目標和策略也至關重要。隨著企業和員工越來越民主化資料存取，並將分析作為每個職能的關鍵部分，無可置疑的是，解決資料品質問題的需求和做法自然會演變。我們預測四個關鍵趨勢將影響未來各地團隊的資料品質。
資料倉儲與資料湖將融合
我們的首個預測與現代資料系統的根本——儲存層有關。幾十年來，資料倉儲和資料湖使企業能夠儲存（有時還能處理）大量營運和分析資料。倉函式庫以結構化狀態儲存資料，透過模式和表格，而湖主要儲存非結構化資料。
然而，隨著技術的成熟和企業爭奪資料儲存戰，AWS、Snowflake、Google和Databricks等公司正在開發融合兩者優點的解決方案，模糊了倉函式庫和湖架構之間的界限。此外，越來越多的企業同時採用倉函式庫和湖——要麼作為一個解決方案，要麼是多個方案的拼湊。
內容解密：
資料倉儲和資料湖的融合趨勢，預示著資料儲存和處理方式的重大變化。這種變化對資料品質有著深遠的影響。
傳統上，資料品質在倉函式庫中更容易維護，因為模式、數量和新鮮度更容易被原生追蹤。一些倉函式庫甚至可以處理部分提取、清理和轉換工作。另一方面，資料湖由多個入口組成，這意味著資料需要被排序和調整以便於營運使用。雖然資料湖提供了更大的使用場景和靈活性，但也引入了額外的管道複雜性和更多資料可能出錯的方式。
程式碼示例：資料湖與資料倉儲的資料處理
-- 資料倉儲中的資料處理示例
CREATE TABLE structured_data (
id INT,
name VARCHAR(255),
date DATE
);
-- 資料湖中的資料處理示例，使用Spark SQL
CREATE TABLE raw_data
USING parquet
OPTIONS (path 's3://data-lake/raw-data/');
-- 將資料從資料湖匯入資料倉儲
INSERT INTO structured_data
SELECT id, name, date
FROM raw_data
WHERE date > '2023-01-01';
內容解密：
上述程式碼展示瞭如何將資料從資料湖匯入資料倉儲。首先，在資料倉儲中建立一個結構化的表格。然後，在資料湖中使用Parquet格式建立一個原始資料表格。最後，透過Spark SQL將符合條件的資料從資料湖匯入到資料倉儲中。這種操作需要仔細設計資料管道，以確保資料的正確性和一致性。
新角色在資料團隊中的興起
2012年，《哈佛商業評論》將“資料科學家”評為21世紀最性感的工作。隨後，在2015年，LinkedIn的前資料科學負責人DJ Patil被聘為美國第一位首席資料科學家。2017年，Apache Airflow的建立者Maxime Beauchemin在一篇經典的部落格文章中預測了“資料工程師”的衰落。
資料團隊的新角色
graph LR
A[資料團隊] --> B[資料科學家]
A --> C[資料分析師]
A --> D[資料工程師]
A --> E[資料產品經理]
A --> F[分析工程師]
E --> G[管理資料產品生命週期]
F --> H[轉換和建模資料]
圖表翻譯： 此圖示展示了資料團隊中的新興角色，包括資料科學家、資料分析師、資料工程師、資料產品經理和分析工程師。資料產品經理負責管理資料產品的生命週期，而分析工程師則專注於轉換和建模資料，以使利益相關者能夠信任和使用這些資料。
隨著資料成為公司範圍內的組織，具有資料科學家、分析師和工程師等專門角色，我們預測在未來幾年中，將出現更多專門化角色來處理資料的攝取、清理、轉換、翻譯、分析、產品化和可靠性。
內容解密：
資料團隊的新角色預示著資料管理的專業化和細化。這些新角色將有助於提高資料品質和可靠性，但同時也需要更好的協調和管理。
預測的影響
我們預測資料倉儲和資料湖的融合將對資料品質產生雙重影響。一方面，這種融合可以簡化資料操作，減少資料出錯的機會，並透過標準化資料平台提高資料品質。另一方面，這種融合也可能引入額外的複雜性，增加資料使用者數量，從而導致資料重複、錯誤和下游緊急情況。
對於資料團隊來說，瞭解這些趨勢並積極管理資料品質至關重要。無論您的角色如何，資料品質都應該是首要任務，因為您使用和信任資料的能力直接影響您能夠對其負責地做出的決策。
