數據來源和路徑

1）什麼是Data Lineage

• 報告中的數字來自哪裏？
• 哪些表格/字段會影響模式更改?
• 為什麼KPI昨天晚上9點發生變化？
• 哪些數據進入特定模型和ML版本?

對於iGaming來說，這是至關重要的，因為監管、財務報表（GGR/NET）、防凍劑、KYC/AML、負責任的遊戲和產品變化的高速度。

2）線性水平和粒度

1.業務線是將指標和業務術語（來自詞匯表）與店面/公式相關聯。
2.技術線條（表格）-表/喬布/轉換包之間的鏈接。
3.專欄（field/column-level）-哪個源專欄構成目標專欄,並帶有規則。
4.Runtime-linj（操作）-實際運行：時間、卷、代碼/方案版本、散列工件。
5.端到端是從提供商/PSP/CRM 到報告/dashboard/模型的端到端路徑。
6.Cross-domain/Mesh是合同數據域產品之間的鏈接。

3）關鍵價值

信任和審計：可解釋報告和模型，快速調查事件。
影響分析：安全的電路/邏輯更改，發布的可預測性。
登陸速度：新的分析師和工程師更快地了解景觀。
法規遵從性：PII可追溯性,法律保留,向監管機構報告。
成本優化：識別「死」管道和重復店面。

4）物體和文物

圖的實體：source（遊戲提供商，PSP，CRM），Topic/Stream，Raw/Staging，Bronze/Silver/Gold，DWH，ML-fichi，BI模型，Dashbord。
鏈接：轉換（SQL/ELT），喬巴（Airflow/DBT/……），模型（版本），合同（Avro/Proto/JSON Schema）。
屬性：所有者,域,分類,方案版本,質量控制,清新,SLO/SLI。

5）線性的真相來源

靜態：SQL/configs paring（dbt，ETL）→建立依賴關系。
動態/運行時：在運行時收集元數據（編排器中的操作員,查詢日誌）。
事件：總線（Kafka/Pulsar）發布/閱讀消息時的線性活動，合同驗證。
手動（最小值）：描述無法自動檢索的復雜業務邏輯。

6）線性和數據合同

該合同記錄了方案，語義和SLA。
兼容性檢查（semver）和冪等性-是強制性的。
線程存儲合同/版本鏈接和驗證事實（CI/CD+運行時）。

7）iGaming中的線性： 域示例

遊戲事件→ RTP總和，波動，保留，「Game Performance Gold」展示櫃。
付款/結論/charjbacks → GGR/NET報告，反欺詐信號。
KYC/AML →狀態，檢查，Alerta →合並展示和報告。
響應遊戲→限制/自我體驗→風險評分和幹預觸發因素。
市場營銷/CRM →活動，獎金，重新組合→對LTV/ARPPU的影響。

8）圖可視化

• 有兩種模式：從字段到字段的「景觀圖」（宏圖）和「直通軌道」（微型）。
• 過濾器：按域、所有者、分類（PII）、環境（prod/stage）、時間。
• 覆蓋：新鮮度、體積、DQ錯誤、電路版本。
• 快速操作："顯示從屬"，"誰消耗此列？"，"KPI dashboard之路。"

9）影響分析和變更管理

在更改電路/邏輯之前,請啟動if： 哪些喬巴/店面/dashbords/模型將受到影響。
自動生成從屬工件的所有者。
顯示屏的雙write/藍綠色模式： v2並行填充,比較指標,切換。
Backfill花花公子：如何以及如何趕上歷史數據，如何檢查一致性。

10）線性和數據質量（DQ）

將DQ規則與圖節點/字段相關聯：有效性、唯一性、一致性、及時性。
違規時,在軌道上顯示「紅色片段」,然後向所有者舉起Alertes。
保存DQ事件的歷史及其對KPI的影響。

11）用於ML/AI的線性

可追溯性：數據集→功能→培訓代碼→模型（版本）→地基。
捕獲commits、培訓參數、框架版本、驗證數據。
線性有助於調查漂移，倒退度量並重現結果。

12）線性和隱私/合規性

標記PII/金融領域，國家/地區，法律（GDPR/本地），加工基礎。
標記應用掩碼/別名/匿名化的節點。
對於DSAR/Right to be forgotten，請破解主體在哪些櫥窗/備件中存在。

13）線性度量（SLO/SLI）

Coverage：具有柱形線條的表/字段的百分比。
Freshness SLI：在更新SLA中堆疊的節點比例。
DQ通行率：成功的關鍵路徑檢查的比例。
MTTD/MTTR用於數據事件。
Change lead time：平均同意時間和安全發布模式。
死亡資產：無人認領的店面/喬布的比例。

14）工具（類別）

Catalog/Glossary/Lineage：一個元數據圖,從SQL/編排器/總線導入。
命令：收集運行時元數據，任務狀態，SLA。
計劃註冊/合同：兼容性檢查，版本策略。
DQ/Dobservability：規則、異常、新鮮度、體積。
Sec/Access：PII標簽，RBAC/ABAC，審核。
ML Registry：模型，工件和dataset的版本。

15）模板（準備使用）

15.1線性節點護照

• 分類：Public/Internal/Confidential/Restricted（PII）
• 來源/輸入：表/topics+合同版本
• 轉型：SQL/job/repo+commit
• 出口/消費者：店面/dashbords/型號

• 可觀察性信號：新鮮度、體積、異常

• 事件歷史：提切特/後太平間參考

15.2個通訊卡（column-level）

從字段： 計劃。table.col（類型,nullable）

在字段中： schema。table.col（類型,nullable）

轉換規則： 表達式/函數/字典

質量上下文： 檢查、範圍、參考

15.3花花公子調查事件

1.確定受影響的KPI/dashboard → 2）將路徑向上（上遊）追溯到源→

2.檢查每個節點上的新鮮/卷/DQ → 4）查找最新的代碼/模式更改→

3.比較prod/stage/昨天 → 6）分配固定和背面→ 7）後太平間和未來規則。

16）流程和整合

在變化中：repo 中的每個更改方案/SQL的merge都會觸發線性重排和影響分析。
上運行：每個成功/失敗的job都將運行時元數據寫入圖形。
Access-hooks：訪問請求顯示通往PII和負責所有者的路徑。
政府儀式：每周審查關鍵途徑，SLO月度報告。

17）實施路線圖

0-30天（MVP）

1.定義關鍵KPI/dashbords及其端到端路徑。
2.連接表線的SQL/jobs分配。
3.啟動節點/通信護照和最低新鮮度指標。
4.描述關鍵路徑（KYC，付款）中的PII標簽。

60-90天

1.進入頂層店面的專欄級別。
2.集成編排器的運行時元數據（時間，音量，狀態）。
3.將DQ規則與圖相關聯,啟用異序。
4.可視化：按域/所有者/PII篩選器，新鮮度覆蓋物。

3-6個月

1.事件總線（遊戲/支付籌碼）上的合同和計劃註冊。
2.完整的ML線性曲目（dannyye→fichi→model→inferens）。
3.CI中的影響分析→依賴項所有者的自動滴答作響。
4.覆蓋範圍為≥70％的活動店面；SLO報告。

18）模式和反模式

• 圖形第一：一個元數據圖作為更改的「指南針」。
• Contract-aware線性：與電路版本和驗證結果的關系。
• Observability overlay： 在圖頂部的新鮮/體積/DQ。
• 產品思考：域名所有者發布經過認證的「數據產品」。

• 「圖片是為了圖片」，沒有自動收集和支持。
• 手動的maind maps代替parsing和runtime true。
• KPI關鍵路徑中沒有柱狀細節。
• 不帶可用性/PII和DSAR/Legal Hold流程的線條。

19）實用支票單

在發布數據更改之前

• 合同更新，兼容性檢查通過
• 依存關系影響分析完成
• v2陳列櫃並行組裝，比較度量ok
• backfill和回滾計劃已記錄

每周審查

• 新鮮綠色的關鍵途徑
• 沒有「孤兒」喬布/店面
• DQ事件已關閉並記錄下來
• column-level覆蓋範圍>目標閾值

結果

線程將混亂的數據流轉換為受控的地形圖：可以看到來自何處，誰回答，風險以及如何安全更改。對於iGaming來說，它是KPI，實驗速度和成熟合規性的信任基礎。