MDM Steward 佇列
Steward 佇列用於處理不確定身分匹配。解析任務可以提出「某個來源記錄可能屬於某個 golden record」的候選，steward 在對應被確認前進行人工審閱。
該佇列處理身分決策。通用資料品質錯誤應進入資料品質和 rejected-row 工作流。
準備工作
- 查看候選需要
dfs:read。 - 批准或拒絕需要
dfs:write。 - 審閱人需要理解被比較的來源系統。
- 審閱人需要有權決定兩筆記錄是否代表同一真實物件。
開啟頁面
Data Integration > DFS Pro > Steward Queue
可按 entity type 和 status 過濾。
| 狀態 | 含義 |
|---|---|
| Pending | 候選需要人工決策。 |
| Approved | 候選已接受，alias 已確認。 |
| Rejected | 候選已拒絕，後續不應重複提出同一候選對。 |
審閱流
把佇列當作受控工作清單使用。每個決策都應留下足夠上下文，便於下一次 resolver run、下游資料 owner 和專案交接記錄複用。
審閱流程
- 選擇 Review。
- 比較 incoming source record 與 candidate golden record。
- 查看 similarity。
- 查看 field diff。
- 必要時檢查來源系統證據。
- 只有確認代表同一真實物件時才 approve。
- 不同物件或證據不足時 reject。
重點比較欄位：
| 欄位組 | 檢查內容 |
|---|---|
| 來源身分 | Source system、source ID、物件類型和 source owner。 |
| 實體身分 | 序號、設備編碼、資產標籤、站點或位置。 |
| 描述欄位 | 名稱、類別、型號、廠商和自由文字描述。 |
| 時間有效性 | 生效時間、替換時間、投運時間或退役狀態。 |
| 既有決策 | Active aliases、rejected pairs、merge history 和 split history。 |
Similarity score 用於排序和分流。最終 steward 決策應基於來源系統證據，而不是只看分數。
批准候選
當 source ID 應作為候選實體的 alias 時，批准該候選。
批准後會建立或更新 cross-source alias，並把候選標記為 approved。如果該身分影響活躍輸出，應重新驗證下游融合或報表。
批准後檢查：
- 開啟 master entity。
- 確認新的 source alias 已 active。
- 檢查 alias 是否帶有預期 valid-from 日期。
- 重新執行或刷新依賴該實體的下游 fusion task。
- 當 alias 影響生產報表、AI Agent 證據或 Inspector 記錄時，把決策寫入交接記錄。
決策參考
| 信號 | 處理方式 |
|---|---|
| 可信來源系統中的相同穩定 ID | 強證據，但仍需確認實體類型和時間窗口。 |
| 只有顯示名稱相同 | 弱證據，需要檢查位置、序號、類別或來源 owner。 |
| 時間接近且故障文字相似 | 對事件候選有幫助；資產身分仍需來源系統證據。 |
| 位置或序號衝突 | 通常應拒絕，或進入 split 審閱。 |
| 關鍵欄位缺失 | 保持 pending 或帶說明 reject，直到來源資料修正。 |
拒絕說明
好的 note 應簡短說明原因：
不同實體設備，只是名稱相似。來源 ID 在替換後重複使用，需要檢查歷史時間段。來源記錄缺少序號或位置證據。
拒絕後應判斷該來源記錄是應該成為新實體、保持未匹配，還是等待來源系統修正。拒絕記錄的作用是減少重複審閱，而不是掩蓋資料品質問題。
佇列營運策略
生產使用前，先定義簡單的佇列策略：
| 策略項 | 建議做法 |
|---|---|
| Owner | 為每類 entity type 指定負責的資料 steward 組。 |
| 審閱頻率 | 上線期間每次 resolver run 後審閱；穩定後改為固定節奏。 |
| 升級路徑 | 缺少來源系統證據的候選應轉給系統 owner，而不是進入泛化 backlog。 |
| Aging threshold | 追蹤超過約定窗口仍 pending 的候選。 |
| 高影響實體 | 用於生產報表、工單或 AI Agent 工作流的實體應增加二次審閱。 |
只有低風險且證據模式一致的候選適合批量審閱。涉及序號、位置、替換歷史或 source owner 差異時，應逐筆判斷。
檢查清單
- Pending candidates 由理解來源系統的人審閱。
- Approve 後 golden record 出現預期 alias。
- 容易復發的 reject 已寫明原因。
- 高影響身分變化已通知下游 owner。
- 交接記錄包含審閱數量和未處理候選。
- Aging pending candidates 有明確 owner 和下一步動作。
- Approved aliases 已反映到下一次下游刷新。
下一步
當現有身分結構需要修正時，繼續閱讀 Merge, Split, Re-Point。