MDM 實體解析任務
實體解析任務是面向實施人員的 DFS 融合任務，用於準備 MDM 輸出。它可以建立或更新 golden records，確認 deterministic aliases，並把不確定匹配送入 steward queue。
業務 steward 通常只需要使用 Master Entities 和 Steward Queue。本頁面用於實施設定、執行驗證和交接。
能力邊界
- DFS 和後端服務負責 MDM 持久化、tenant scope、權限和稽核。
- 解析器根據傳入上下文計算實體、別名和模糊候選。
- 模糊匹配進入 steward queue，不靜默接受。
- 來源系統仍然是業務記錄的系統來源。
Resolver 是受治理的資料準備流程，steward 決策仍然是身分流程的一部分。
準備工作
- 來源資料集已經可用並有 steward。
- 目標 entity type 已存在。
- 所需 reference data 已準備好。
- method configuration 已審閱。
- 來源欄位包含穩定身分信號。
- 下游 owner 知道該任務是測試、試點還是生產用途。
輸入
| 輸入 | 用途 |
|---|---|
| Source datasets | 可能描述同一物件的來源記錄。 |
| Entity type | 目標類型，例如 device、asset、part、station。 |
| Match keys | 高信心 deterministic 匹配欄位。 |
| Fuzzy fields | 名稱、描述、別名或屬性，用於提出候選。 |
| Survivorship rule | 來源系統衝突時如何選擇 canonical 屬性。 |
| Existing MDM context | 目前實體、active aliases、rejected pairs。 |
平台應組裝 MDM 上下文並傳給解析器。面向生產規模的執行中，解析器可以透過 staged handoff 交回計算出的實體、別名和模糊候選，並在執行記錄中返回數量。後端再透過受治理的 MDM 服務完成最終寫入。
這樣租戶範圍、權限、稽核行為、屬性保留、時間有效別名和人工審閱佇列建立都留在平台層，解析器專注於匹配計算。
設定檢查清單
在 resolver 面向完整資料集執行前，應和資料 owner 一起審閱設定：
| 設定項 | 需要回答的問題 |
|---|---|
| Entity type | 該類型是否代表具有穩定生命週期的真實營運物件？ |
| Source priority | 名稱、位置、類別、狀態衝突時，哪個來源優先？ |
| Deterministic keys | 哪些欄位可以直接確認匹配，無需進入 steward review？ |
| Fuzzy fields | 哪些欄位只適合提出候選，需要人工審閱？ |
| Validity period | 如何處理設備替換、退役資產和重複使用 source ID？ |
| Rejected-pair memory | 是否納入既有 steward 拒絕記錄，避免重複誤報？ |
| Run mode | 本次執行是 preview、pilot，還是允許寫入 approved MDM output？ |
建議從小範圍切片開始，包含乾淨記錄、已知重複、退役物件和少量困難樣本。只用乾淨記錄測試會高估上線準備度。
輸出
- 建立或更新的 entities；
- 被確認的 aliases；
- 進入 steward queue 的 fuzzy candidates；
- run metrics 與錯誤；
- 支撐決策的 lineage。
大規模執行中，整合應把執行指標、staged 數量、persisted 數量和人工審閱佇列數量作為執行摘要。受治理結果應在主資料實體、跨來源別名和人工審閱佇列中查看。
普通資料集列需要時可透過單獨的資料工作流發布。MDM 輸出是身分層；融合資料集、報表、Inspector 工作流或 AI Agent 工作流應消費審閱後的身分結果。
實施邊界
規劃實施時使用以下邊界：
| 負責人 | 職責 |
|---|---|
| DFS Lite 與 DFS Pro | 提供來源列、source contract、欄位畫像和資料集血緣。 |
| 解析器 | 比較記錄、提出實體和別名、為模糊候選打分。 |
| 後端 MDM 服務 | 持久化實體、別名、模糊候選、稽核記錄和時間有效別名變更。 |
| 人工審閱工作流 | 核准或拒絕不確定候選，並記錄負向決策。 |
| 下游工作流 | 消費已審閱 entity ID、別名、執行指標和交接說明。 |
重跑應保持冪等。一次重試應更新目標記錄或佇列項，而不是製造重複實體、重複別名或重複誤報候選。
驗證流程
審閱執行結果
每次執行後檢查：
- 建立或更新的 entity 數量；
- 被確認的 alias 數量；
- 進入 steward queue 的 fuzzy candidate 數量；
- 被跳過或格式異常的記錄；
- task errors；
- steward 工作量是否可接受。
候選量過高通常說明 match keys、來源資料品質或 survivorship rules 還需要調整。
| 指標 | 意義 |
|---|---|
| Deterministic match rate | 觀察多少記錄可用穩定 key 匹配。 |
| New entity rate | 發現意外的實體膨脹。 |
| Fuzzy candidate rate | 預估生產 steward 工作量。 |
| Rejected-pair repeat rate | 判斷既有拒絕決策是否被複用。 |
| Missing-key count | 指向來源映射或資料品質問題。 |
| Downstream row movement | 觀察身分更新後多少融合記錄、工單或事件發生變化。 |
每類結果都應抽樣檢查。總體指標健康時，也可能在某個資產類別或來源系統中產生高影響錯誤。
端到端場景
典型實施路徑會把 MDM 連接到 DFS 其他能力：
- 使用 DFS Lite 匯入維護、BMS、巡檢或表格中的資產記錄。
- 歸一化來源欄位，並映射必需的身分信號。
- 針對目標 entity type 執行 MDM resolver task。
- 確認 deterministic aliases，並把不確定匹配送入 Steward Queue。
- 重新執行 DFS Pro fusion task，把工單、讀數、巡檢和事件關聯到 master entity ID。
- 將審閱後的資料集交給 Inspector 工作流、AI Agent 證據檢索、BI 報表或其他營運應用。
交接內容應包含 resolver run ID 或 task name、source slice、entity type、steward decision counts、open exceptions 和 downstream refresh status。
交接清單
- 任務名稱和用途清楚。
- 目標 entity type 正確。
- 輸入資料集和來源欄位已記錄。
- match keys 和 fuzzy fields 已審閱。
- steward queue 有 owner。
- 下游工作流知道輸出是否可用。
- 已知限制和未解決身分問題已記錄。
- 執行指標已附到交接記錄。
- 後續來源資料刷新時的重跑方式已經明確。
下一步
繼續閱讀 Steward Queue。