欄位層級資料血緣建構解析與實作

– 12 分鐘閱讀

現代資料系統中，建構完善的資料血緣對於資料治理和分析至關重要。資料血緣追蹤資料從來源到最終使用的完整路徑，而欄位層級的資料血緣則更進一步解析每個欄位的來源和轉換過程。這對於理解資料的上下文、排查資料問題以及確保資料品質至關重要。實務上，透過解析複雜的 SQL 查詢，並使用工具如 ANTLR 提取欄位間的關係，可以有效地建構欄位層級的資料血緣。此外，設計友善的使用者介面，讓使用者可以直觀地瀏覽和理解資料血緣，也是實作過程中需要考量的重點。

現代資料系統中建立端對端欄位級別的資料血統

SQL查詢複雜性與資料血統解析

在現代資料系統中，建立端對端欄位級別的資料血統（Field-Level Lineage）是一項至關重要的任務。這涉及到對SQL查詢的深入解析，以理解資料如何在不同的表和欄位之間流動。以下是一個複雜的SQL查詢範例，用於展示資料血統的構建過程：

WITH 
lead_subscription_orders AS (
  SELECT 
    id AS usage_id,
    CASE 
      WHEN order_type = 'lead' THEN CAST('send lead order' AS string)
      WHEN order_type = 'regular' THEN CAST('send regular order' AS string)
    END AS action,
    MIN(timestamp_add(send_date, INTERVAL 10 HOUR)) AS action_at
  FROM 'decom.cart.usages_orders_process'
  WHERE usage_legit_order_no = 1 AND send_date IS NOT NULL
  GROUP BY 1, 2
),
submit_email AS (
  SELECT 
    id AS usage_id,
    CAST('submit email' AS string) AS action,
    created_at AS action_at
  FROM 'decom.processed.usages'
  WHERE created_at IS NOT NULL
),
activations AS (
  SELECT 
    id AS usage_id,
    CAST('activate' AS string) AS action,
    created_at AS action_at
  FROM 'decom.processed.usages'
  WHERE activated_at IS NOT NULL
),
unioned AS (
  SELECT * FROM activations
  UNION ALL
  SELECT * FROM usage_subscription_state_change_actions
  UNION ALL
  SELECT * FROM lead_subscription_orders
  UNION ALL
  SELECT * FROM lead_subscription_order_send_dates
  UNION ALL
  SELECT * FROM submit_email
)
SELECT 
  u.*,
  COALESCE(usa.action_general_order, -1) AS action_general_order,
  usa.subscription_phase_change_to AS subscription_phase_change_to
FROM unioned u
INNER JOIN (
  SELECT usage_id, MAX(created_time) AS max_created_date
  FROM usage_stuck_to_be_processed
  GROUP BY usage_id
) AS usage_created_date
ON usage_created_date.usage_id = u.usage_id
LEFT JOIN tfddatawarehouse.cart.usage_subscription_actions usa
ON u.action = usa.action
WHERE 
  NOT (u.usage_id IN ((SELECT usage_id FROM usages_stuck_to_be_processed)))
  AND NOT (u.usage_id IN ((SELECT usage_id FROM usages_batch_removeled)))

內容解密：

  1. CTE（Common Table Expressions）使用：查詢中使用了多個CTE來簡化複雜的邏輯，例如lead_subscription_orders、submit_email和activations。每個CTE都定義了一個臨時結果集，這些結果集可以在主查詢中被參照。
  2. CASE陳述式：在lead_subscription_orders CTE中，使用了CASE陳述式根據order_type欄位的值來決定action欄位的值。這展示瞭如何在SQL中進行條件邏輯處理。
  3. 聚合函式：查詢中使用了MIN和MAX等聚合函式來計算欄位的最小值和最大值，例如計算action_at欄位的最小值。
  4. UNION ALL操作：透過UNION ALL運算元，將多個CTE的結果集合併成一個統一的結果集unioned。
  5. JOIN操作：查詢中包含了多個JOIN操作，用於將不同表或結果集中的資料根據特定條件進行關聯。
  6. COALESCE函式：使用COALESCE函式來處理action_general_order欄位的空值，提供預設值-1。
  7. 子查詢：查詢中使用了子查詢來過濾資料，例如排除某些usage_id。

資料血統解析工具

為了構建資料血統，需要使用像ANTLR（ANother Tool for Language Recognition）這樣的工具來解析SQL查詢。ANTLR是一個開源的查詢解析器生成器，可以讀取、處理、執行和翻譯結構化的文字或二進位制檔案。透過使用查詢解析器提取定義語法的列，可以存取欄位級別的關係，從而構建完整的資料血統。

  graph LR;
    A[開始解析SQL查詢] --> B[使用ANTLR解析查詢];
    B --> C[提取欄位級別關係];
    C --> D[構建資料血統];
    D --> E[展示欄位級別的資料血統];

圖表翻譯： 此圖表展示了使用ANTLR解析SQL查詢並構建資料血統的流程。首先開始解析SQL查詢，然後使用ANTLR進行解析，接著提取欄位級別的關係，並最終構建和展示欄位級別的資料血統。

使用者介面構建

在構建資料血統的使用者介面時，需要決定使用哪些技術以及如何以最直觀和最有用的方式展示欄位級別的資料血統。同時，需要增強資料血統的視覺化，以便於快速解決事件並實作更可擴充套件的資料可靠性工作流程。

  graph TD;
    A[資料團隊關注點] --> B[最下游層];
    A --> C[最上游層];
    B --> D[業務智慧物件];
    C --> E[源表或欄位];
    D --> F[影響分析];
    E --> F;

圖表翻譯： 此圖表展示了資料團隊在資料血統分析中的關注點，包括最下游層的業務智慧物件和最上游層的源表或欄位。這些資訊對於進行影響分析和根因分析至關重要。

資料血緣分析中的欄位層級解析與實作

資料血緣的重要性與應用場景

在現代資料驅動的企業中，資料血緣（Data Lineage）扮演著至關重要的角色。它幫助資料團隊理解資料的來源、流動以及相互之間的依賴關係。欄位層級的血緣分析更進一步提供了細粒度到每個欄位的詳細資訊，使得資料團隊能夠有效追蹤資料問題的根源。

欄位層級血緣的實作挑戰

實作欄位層級的血緣分析面臨多項挑戰，包括：

  1. 複雜的SQL解析：需要深入理解SQL查詢中的各種子句（如SELECT、WHERE等）對欄位之間關係的影響。
  2. 高效能的渲染：由於欄位可能關聯到數十甚至數百張上游或下游表格，渲染這些關係時需要確保應用的效能不受影響。
  3. 多樣化的關係呈現：需要呈現不同型別的欄位關係，包括SELECT子句中的欄位對欄位關係，以及其他子句（如WHERE）中的欄位對表格關係。

欄位層級血緣的使用者介面設計

為了有效地呈現欄位層級的血緣資訊，我們可以採用現代的前端框架（如React）結合輕量級的視覺化工具（如Apache Preset或React Virtuoso）。這樣不僅能夠確保介面的互動性，也能有效處理大規模資料的呈現。

SELECT子句血緣

SELECT子句定義了欄位之間的直接關係，即上游欄位的變更會直接影響下游欄位。

非SELECT子句血緣

其他SQL子句（如WHERE）定義了欄位與表格之間的關係，通常與篩選或排序邏輯相關。

實作範例：欄位血緣查詢

以下是一個範例查詢，用於建立欄位之間的血緣關係：

CREATE OR REPLACE TRANSIENT TABLE analytics.prod_lineage.looker_explore_to_dashboard_edges AS
(
  WITH tile_with_upstream_explores AS (
    SELECT
      a.account_id,
      a.resource_id,
      b.value::varchar AS upstream_explore,
      a.name,
      a.metadata:dashboard:dashboard_id AS dashboard_id
    FROM analytics.prod_lineage.looker_dashboard_tile_nodes a,
    LATERAL FLATTEN(input => a.extra:upstream_explores) AS b
  )
  -- 繼續處理血緣關係的建立

內容解密：

  1. 查詢目的：此查詢的主要目的是建立一個暫存表格，用於儲存Looker中的Explore到Dashboard之間的血緣邊緣資訊。
  2. 欄位解析：
    • account_id 和 resource_id 用於識別相關資源。
    • upstream_explore 欄位儲存了上游的Explore資訊，透過LATERAL FLATTEN函式從extra:upstream_explores中解析而來。
    • dashboard_id 提供了相關的Dashboard識別碼。
  3. 技術考量：使用Transient Table可以減少儲存成本並提高查詢效率。LATERAL FLATTEN函式的使用使得複雜的JSON資料結構能夠被有效解析。

最佳實踐與經驗分享

在建立欄位層級血緣的過程中，我們遵循了以下最佳實踐：

  1. 傾聽團隊成員的意見：在開發初期，我們低估了SQL解析的難度。多虧了團隊成員的經驗分享，我們得以避免重蹈覆轍。
  2. 原型開發與迭代：我們優先開發了原型並與客戶進行了早期互動。這不僅加速了開發流程，也確保了最終產品符合客戶需求。
  3. 持續交付與改進：軟體開發中的持續交付實踐幫助我們快速迭代並改進產品功能。

案例研究：Fox的資料可靠性架構

在Fox這樣的大型媒體公司中，資料的可靠性和可存取性至關重要。VP of Data Services，Alex Tverdohleb，透過建立「受控自由」的資料架構，成功地在確保資料可靠性的同時，實作了資料的民主化存取。

圖表解析

  graph LR;
    A[資料來源] -->|資料擷取|> B[資料倉儲];
    B -->|資料處理|> C[資料集市];
    C -->|資料分析|> D[商業智慧];
    D -->|決策支援|> E[業務行動];

圖表翻譯： 此圖示展示了資料從來源到最終業務行動的流程。資料首先被擷取並儲存於資料倉儲中，然後經過處理和分析，最終支援業務決策。

內容解密：

  1. 資料流程：資料從不同的來源被擷取到資料倉儲。
  2. 資料處理：在資料倉儲中的資料經過處理後被載入到資料集市。
  3. 資料分析：資料集市中的資料被用於分析和生成報告。
  4. 業務應用：最終的分析結果被用於支援業務決策和行動。

資料可靠性架構：Fox 案例研究

在當今資料驅動的商業環境中，如何確保資料的可靠性、安全性以及高效利用，已成為企業成功的關鍵。Fox 公司的資料團隊在這方面取得了顯著成就，其架構設計和技術實踐為業界提供了寶貴的參考。

去中心化資料架構的實施

Fox 公司的資料架構採用了去中心化的設計，讓內部資料消費者能夠根據業務需求自由建立和使用資料產品。這種架構的最大優勢在於提高了資料的可用性和時效性。

“如果採用集中式的資料包告結構，你需要提交請求然後等待，通常等到獲得答案時已經太晚了。” - Alex

這種去中心化的架構使得資料能夠快速流轉，滿足業務快速變化的需求。Alex 提到，業務正在以前所未有的速度發展和變化，決策需要在瞬間做出，因此資料必須隨時可得。

資料攝取與管理的關鍵領域

為了實作大規模的資料管理，Alex 和他的團隊控制了幾個關鍵領域：

  1. 資料攝取：確保資料來源的可靠性
  2. 資料安全：保護資料免受未授權存取和潛在威脅
  3. 資料最佳化：將資料轉換為最佳格式，以便於發布到標準的執行報告中

透過確保資料來源的可信度、資料的安全性以及一致的指標和定義，資料消費者可以自由地存取和使用資料。

“我們給你資料來源並保證其可信度。我們知道我們每天多次監控這些管道，並且知道裡面的資料可以用於 X、Y 和 Z —— 所以只需按照你的意願使用它。” - Alex

投資去中心化資料團隊

在 Alex 的長官下，Fox 公司的資料團隊分為五個小組：

  1. 資料標記和收集
  2. 資料工程
  3. 資料分析
  4. 資料科學
  5. 資料架構

每個團隊都有其特定的責任，但大家共同合作以解決整個業務的問題。

“我堅信必須讓團隊參與決策過程並採取協作方式。我們沒有單一的架構長官者 —— 這是一種團隊章節方法。” - Alex

分析師與工程師的協同工作

在 Fox 的資料組織中，分析師和工程師之間有明確的分工。分析師與業務部門緊密合作，瞭解痛點並驗證新的資料來源。這種知識被用於制定 源到目標對映（STM），為工程師提供明確的操作，以便構建支援業務資料需求的管道和架構。

# 示例：源到目標對映（STM）流程
def source_to_target_mapping(source_data, target_schema):
    """
    將原始資料對映到目標架構
    :param source_data: 原始資料來源
    :param target_schema: 目標資料架構
    :return: 對映後的資料
    """
    # 資料清洗和轉換邏輯
    transformed_data = transform_data(source_data)
    # 載入到目標架構
    load_data(transformed_data, target_schema)
    return transformed_data

#### 內容解密：
此函式展示了源到目標對映的基本流程。首先，我們需要對原始資料進行轉換和清洗，然後將處理後的資料載入到目標架構中。這個過程確保了資料的品質和一致性，為後續的資料分析提供了可靠的基礎。

這種分工使得團隊成員能夠專注於他們的特定領域，而不是被過多的任務分散精力。Alex 認為，讓開發人員參加大量的業務會議可能是浪費時間，因為理解業務需求通常是一個耗時且艱苦的過程。

“透過在工程團隊介入之前進行分析，我們可以彌合這一差距，然後讓開發人員專注於他們最擅長的事情 —— 構建最可靠、彈性和最佳化的作業。” - Alex

避免盲目追求新技術

Fox 的資料團隊擁有強大的技術堆疊，但 Alex 強調，資料長官者不應該盲目追求新的技術。

“首先，為了成功交付正確的底層架構，你需要了解業務。不要追逐最新和最偉大的技術，因為這樣你永遠不會停止。有時你現在擁有的技術堆疊已經足夠好 —— 你只需要最佳化它。” - Alex

資料湖倉架構的採用

Fox 的資料團隊採用了 湖倉架構，因為它結合了資料湖的靈活性和資料倉儲的結構化優勢。

“我們開始採用湖倉架構，因為它既能提供資料湖的優點，又能保持資料倉儲的乾淨和結構化。” - Alex

資料流經「三層蛋糕」

資料在 Fox 的系統中流經所謂的「三層蛋糕」：

  1. 原始層：資料以原始狀態存在
  2. 最佳化層：資料被排序、分割並最佳化為不同的檔案格式，以提高讀寫速度和可用性
  3. 發布層：資料被定義為資料模型或包含在資料集中，供公司內部更廣泛地使用
-- 示例：資料最佳化查詢
SELECT 
    column1, 
    column2
FROM 
    raw_data
WHERE 
    condition = 'optimized'
OPTIMIZE 
    FOR READ;

#### 內容解密：
這個SQL查詢展示瞭如何對資料進行最佳化以提高查詢效能。透過選擇特定的列並應用篩選條件，我們可以減少資料量並提高查詢效率。這種最佳化對於大規模資料處理尤為重要。
圖表翻譯：

此圖示展示了資料在 Fox 系統中的流動過程。資料首先以原始狀態存在，然後經過最佳化層進行處理，最後在發布層被準備好供公司內部使用。這個流程確保了資料的品質和可用性。


透過這種架構和技術實踐，企業可以更好地滿足業務需求，提高資料的利用率，並最終實作業務目標。Fox 的案例證明瞭資料架構和技術實踐對於企業成功的重要性。

## 資料品質的民主化：開發值得信賴的資料生態系統

隨著企業不斷深化資料驅動的業務策略，資料品質的重要性日益凸顯。資料工程師、分析工程師以及資料分析師面臨著確保資料品質的艱鉅任務。然而，資料品質的提升並不僅僅依靠技術層面的改進，同樣需要組織文化的支援與共識。

### 資料信任的建立

資料信任的基礎在於讓整個企業對資料品質有共識。根據Cindi Howson的觀點，資料信任的建立取決於人們對資料來源的理解，以及對資料品質的合理預期。即使是高品質的資料，也不可能達到完美無瑕的狀態，因此理解資料的「方向性準確性」至關重要。

#### 內容解密：
這段內容強調了資料信任的文化層面建設。企業需要在技術層面確保資料的可靠性，同時也要讓員工理解資料的侷限性，從而建立對資料的合理信任。

### 資料品質的挑戰

企業在推動資料分析的過程中，常常會遇到諸如「這是好的資料嗎？」或「我能信任這個儀錶板嗎？」等問題。這些問題的背後反映了資料品質和資料信任的核心挑戰。資料組織通常承擔著資料品質工作的重擔，但單靠資料組織的力量往往不足以解決問題。

#### 程式碼例項：資料品品檢查
```python
import pandas as pd

def check_data_quality(data):
    # 檢查資料是否為空
    if data.empty:
        print("資料為空")
        return False
    
    # 檢查資料中是否存在缺失值
    if data.isnull().values.any():
        print("資料中存在缺失值")
        return False
    
    # 檢查資料的資料型別是否正確
    expected_types = {
        'column1': int,
        'column2': str
    }
    for column, expected_type in expected_types.items():
        if not isinstance(data[column].iloc[0], expected_type):
            print(f"{column} 資料型別不正確")
            return False
    
    return True

# 使用範例
data = pd.Data { 'column1': [1, 2, 3], 'column2': ['a', 'b', 'c'] }
if check_data_quality(data):
    print("資料品品檢查透過")

內容解密：

這個程式碼範例展示瞭如何對資料進行基本的品品檢查，包括檢查資料是否為空、是否存在缺失值，以及資料型別是否正確。這些檢查是確保資料品質的基礎步驟。

自助式分析與資料信任

Alex和他的團隊在Fox數字組織中實施了「受控自由」的自助式分析模式，讓資料使用者能夠方便地發現和操作值得信賴的資料資產。要實作這一目標，關鍵在於確保資料的準確性、可靠性和可信度。為此，整個資料堆積疊都被包裹在品質保證、驗證和警示機制中，即資料可觀測性。

資料可觀測性流程

  graph LR
    A[資料來源] --> B[資料處理]
    B --> C[資料儲存]
    C --> D[資料可觀測性工具]
    D --> E[資料品品檢查]
    E --> F[警示機制]
    F --> G[資料修正]

圖表翻譯： 此圖示展示了資料可觀測性的流程，從資料來源到資料儲存，再經過資料可觀測性工具進行品品檢查和警示，最終實作資料的修正和最佳化。

資料民主化的關鍵

資料品質的民主化不僅僅是技術上的挑戰，更是文化上的變革。企業需要透過教育和溝通，讓所有員工理解資料的來源、侷限性和使用方法，從而建立對資料的信任。透過這樣的努力，企業能夠開發一個值得信賴的資料生態系統，推動業務的持續發展。

玄貓

玄貓

技術愛好者，專注於分享程式開發、雲端技術與 AI 應用的心得體會。