Skip to content
SteveTechArcSteveTechArc Courses

資料品質與治理

另有 28 種語言版本

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

An open sketchbook on a drafting table at dawn, a building sketched on one page and a data model on the other, with a pencil, an eraser, a cup and a lamp.
圖片由 AI 生成

Data Architect 課程第 5 章的學習指南。請先閱讀六個模組；這一頁幫你檢查自己記住了什麼。

**關於本學習指南。**它只依據本課程自己的內容，以及 Salesforce 公開發布的考試指南中的目標清單編寫。它從不基於真實的考試題目，也不聲稱知道考試會考什麼。如果你參加過考試，請不要把考題發給我：認證協議禁止分享考題，而且死記答案本來就不是成為架構師的正確方式。

本章承載了考試的「資料治理」部分（10%），以及「資料建模」（後設資料）和「Salesforce 資料管理」（一致性）的部分內容。它也是隱私法與資料模型相遇的地方。這是架構，不是法律意見：由法務部門決定什麼適用，由架構師讓它變得可執行。平台的數字會變，所以在依賴它們之前先檢視當前的數字。

備考要點

Section titled “備考要點 ”

邊學邊打勾。每一條都連結到講授它的地方。

GOV-2：設計一個治理計劃

  • 我知道記錄所有人（一種存取權限的平台機制）不等於資料所有者（作為業務資產對資料負責的人），也知道每個欄位都可以記錄一個 Data Owner。（記錄所有人不等於資料所有者）
  • 我能區分資料所有者（制定策略）、資料專員（讓它持續運轉）和資料保管人（運營系統）。（所有者、資料專員、資料保管人）
  • **考點：**我知道運作治理專案的三種方式：集中式、聯邦式（分散式）和混合式，以及每種方式對由誰制定策略、共用定義放在哪裡意味著什麼。（治理專案如何運作）
  • 我能用 RACI 來回答資料在哪裡建立、編輯和引用。（讓 RACI 名副其實）
  • 我能為一項治理策略說出一個執行點（權限、驗證、只允許整合寫入的欄位、欄位歷史記錄），而不只是培訓。（治理必須變成機制）
  • 我知道值得度量的品質訊號，是那些有人會據此行動的訊號。（度量有人會據此行動的東西）

SDM-2 和 MDM-4：把壞資料擋在門外

  • 我能決定客戶的建立應該開放還是鎖定，也知道針對在 ERP 中主控的客戶的臨時記錄類型路徑。（開放還是鎖定？，折中的做法）
  • 我能保護受治理的屬性（ERP ID、法定名稱），同時讓 Salesforce 自己的欄位保持可編輯：一個混合式黃金記錄。我也知道 Dynamic Forms 頁面上的只讀欄位不是執行點；欄位級安全性或驗證規則才是。（保護受治理的記錄，每個資料流一個記錄類型）
  • 我知道雙向資料流最難：如果 ERP 主控一個欄位，Salesforce 就是在請求修改它，而衝突需要一條規則（ERP 勝出；如果值已改變就拒絕；或者由一個人來解決）。（保護受治理的記錄）
  • 我知道必填欄位可能製造假資料（N/A、999999），也知道替代辦法。（不要讓必填欄位製造假資料）
  • 我能決定沒通過檢查的入站資料會怎樣：接受、拒絕還是隔離，以及誰擁有這個例外。（每一條資料邊界都需要一個品質決定）
  • 我知道參考資料也需要後設資料：定義、一個所有者、一個來源，以及系統之間的對映。（參考資料也需要後設資料）

DM-3：業務後設資料和技術後設資料

  • 考點：我能區分業務後設資料（含義、定義、所有者、規則、敏感性）和技術後設資料（物件、欄位、類型、API 名稱、模式、對映、血緣）。（兩種後設資料）
  • 我知道業務詞典（它意味著什麼）、血緣（它從哪裡來）和分類（必須如何對待它）之間的區別。（瞭解你的資料）
  • 我知道 Salesforce 的分類欄位：Data Owner、Field Usage、Data Sensitivity Level、Compliance Categorization，適用於標準欄位和自訂欄位。（分類回答的是另一個問題）
  • 我知道要給敏感欄位分類，而不是每個欄位，也知道沒有執行的分類只是裝飾。（沒有執行的分類只是裝飾）

GOV-1：個人資料和敏感資料

  • 我認識主要的法律（GDPR、CCPA/CPRA、PIPEDA、LGPD、澳大利亞的 Privacy Act、HIPAA、PCI DSS、SOX、COPPA），知道 GDPR 可以適用於歐盟以外的組織，也知道這些法律的共同點：權利、跨境傳輸、資料洩露通知和問責原則。（你應該認識的法規，法律不止於國界）
  • 我知道加密、遮罩、假名化和匿名化之間的區別，也知道假名化的資料仍然是個人資料。（匿名化、假名化、加密、遮罩）
  • 我知道少收集是一種隱私控制，而保留要在一開始就設計好。（少收集是一個架構決定，保留是模型的一部分）
  • 我瞭解同意資料模型：個人上的全域同意、互動渠道同意、聯絡點同意和資料使用目的。（使用 Salesforce 已經構建好的模型）
  • 我知道這些請求都有期限（GDPR：一個月，可再延長兩個月），所以副本地圖必須事先就存在。（時鐘已經開始走了）
  • 我知道被遺忘權意味著找到每一份副本（歷史、歸檔、分析、日誌、檔案、自由文字），也知道 Privacy Center 的策略按物件、針對一條客戶記錄執行。（現在這個人說：忘掉我，Privacy Center 是一個工具）
  • 我知道 Shield Platform Encryption 的權衡：機率性加密的欄位不能在 SOQL 中篩選、分組或排序；確定性加密允許篩選；加密欄位不能驅動基於條件的共用。（加密是一種控制，而不等於合規）
  • 我知道不要把生產環境的敏感資料複製到沙箱裡，也知道 Data Mask 正在被 Data Mask & Seed 取代。（不要把生產環境的風險複製到沙箱裡）
  • 我知道欄位歷史記錄追蹤（每個物件最多 20 個欄位；保留 18 個月，只有通過 API 才能達到 24 個月；長文字只記錄被編輯過）與 Field Audit Trail（最多 200 個欄位，一直保留到你刪除為止）的區別。（歷史也是資料）
  • 我知道 Event Monitoring 的日誌保留期（沒有附加元件時部分事件保留 1 天，有附加元件時預設 30 天，延長後最多 365 天），也知道要在需要之前就把事件匯出到 SIEM：付費日誌無法獲取合同開始之前的資料。（稽核和監控不是一回事）

考試之外

Section titled “考試之外 ”

考試是底線，不是天花板。下面這些是本章中架構師需要的習慣，不管有沒有考題問到它們。

  • 一項沒有執行點的策略，基本上只是一個願望。
  • **所有者制定策略；架構師負責執行。**不要編造策略，也不要扮演律師。
  • **治理永遠沒有完成的一天。**它時起時落；要設計好反饋。
  • **不要依賴自覺。**把控制措施建起來：人、整合和代理程式都會犯錯。
  • 治理要恰當，而不是事無鉅細。
  • **先預防代價高昂的錯誤。**一個帶著兩年曆史的重複記錄是個大問題。
  • 區分給人讀的東西和讓機器據此做決定的東西。
  • 廣泛地寫文件；有選擇地分類。
  • 治理成本最低的敏感資料，是你從未複製過的資料。
  • **同意是資料，**而使用資料的許可必須能夠表示為資料。
  • **先控制個人資料去往何處，**因為刪除既少見又困難。
  • 合規不是一個產品。
  • 採集 → 分類 → 保護 → 使用 → 保留 → 刪除 → 稽核。
  • 在任何人要求之前就採集好證據。

必知術語

Section titled “必知術語 ”
術語一句話解釋
資料治理關於資料的策略，以及讓它們成真的架構
資料所有者對某類資料負責的人或職能
資料專員在日常中保持資料健康的人
資料保管人運營存放資料的系統的團隊
RACI負責執行、負最終責任、諮詢、通知
臨時記錄在權威系統接受它之前就建立的記錄
業務詞典對業務中重要術語達成一致的定義
血緣一個值從哪裡來，以及它在途中經歷了什麼
資料分類按敏感性和合規類別給資料貼標籤，讓它得到合適的控制
分類體系一個組織用來給資料分類的一套標籤
個人資料能識別某個人，或能被關聯回某個人的資訊
假名化替換識別符號，但仍存在一條回去的路；仍然是個人資料
匿名化消除合理識別這個人的能力
同意資料模型Salesforce 中按個人、渠道、聯絡點和目的管理同意的物件
被遺忘權在法律賦予的情況下，一個人要求刪除其個人資料的權利
混合式黃金記錄一條記錄同時包含主控系統的欄位和 Salesforce 自己的欄位，每類欄位只有一個來源
業務後設資料 / 技術後設資料資料意味著什麼、由誰擁有 / 它如何構建、如何流動
Field Audit Trail更長的欄位歷史：每個物件最多 200 個欄位，一直保留到被刪除
Event Monitoring登入、匯出、API 呼叫和檢視的日誌，保留有限的時間
SIEM儲存和分析事件日誌的安全儲存庫

自我檢查

Section titled “自我檢查 ”

按課程風格編寫的簡短情景題。開啟答案之前，先想好你的答案。

1. 策略規定只有財務部門可以修改客戶的法定名稱。團隊打算在培訓中講到這一點。缺了什麼？

一個執行點。培訓不是控制措施：使用欄位級存取權限、一個只有整合才能寫入的欄位、一條驗證規則，或者一個受控流程。所有者制定策略；架構師讓它在機制上成真。重讀治理必須變成機制。

2. 客戶在 ERP 中主控。銷售代表需要馬上開始向新的潛在客戶銷售。你如何讓他們做到，而又不讓兩個系統都去建立主記錄？

讓銷售代表把客戶建立為一個臨時記錄類型，然後通過一個受控流程來轉換它：由財務部門批准，或者由整合提交給 ERP，ERP 比對或建立客戶，並回傳權威 ID。重讀折中的做法。

3. 一個新的必填欄位被填滿了「N/A」和「999999」。發生了什麼，你會怎麼做？

使用者在知道答案之前就被迫回答了。在流程的後面再要求它，讓另一個系統來提供它，使用臨時狀態，或者在「未知」是一個真實答案時允許明確選擇未知。重讀不要讓必填欄位製造假資料。

4. 團隊把姓名換成了權杖，說資料已經匿名化了，所以刪除請求已經完成。是這樣嗎？

如果權杖可以被關聯回這個人，就不是：那是假名化，資料仍然是個人資料。準確說明系統做了什麼、對映關係存放在哪裡，並讓法務部門判斷它是否滿足要求。重讀匿名化、假名化、加密、遮罩。

5. 一位收貨人同意接收配送簡訊，但拒絕營銷。模型應該如何儲存這一點？

用同意資料模型，而不是一個核取方塊：這個人、渠道（簡訊）、具體的號碼，以及資料使用目的（配送通知，而不是營銷）。還要決定哪個系統是同意的權威來源，讓撤回能到達每一個據此行事的系統。重讀使用 Salesforce 已經構建好的模型。

6. 合規部門需要按一個加密的社會安全號碼欄位篩選報表。這個欄位使用的是預設加密方案。問題在哪裡？

機率性加密不允許在 SOQL WHERE 子句或資料管理篩選條件中篩選。確定性加密允許篩選，代價是強度略有降低。加密是一個有權衡的設計決定，而不是最後勾一下的核取方塊。重讀加密是一種控制，而不等於合規。

7. 事件發生六個月後，有人問是誰匯出了一批記錄。沒人設定過 Event Monitoring 的儲存。你能告訴他們什麼？

多半什麼也說不了：事件日誌只保留有限的時間（即使延長也最多一年），所以更早的資料，除非被匯出過，否則就沒了。在需要之前就設定好 Event Monitoring，並把事件傳送到 SIEM。重讀稽核和監控不是一回事。

8. 一位銷售代表請求 Salesforce 修改一個客戶的法定名稱，而這個欄位由 ERP 主控。就在同樣的幾分鐘裡，有人在 ERP 中修改了它。設計應該怎麼規定？

Salesforce 是在請求修改，而不是在修改：這個欄位由 ERP 主控。事先決定衝突規則（ERP 勝出；如果值已改變就拒絕；或者由一個人來解決），以及相關欄位是否一起傳遞。重讀保護受治理的記錄。

9. 一個人的刪除請求到了。團隊打算開始梳理這個人的資料存放在哪裡。問題在哪裡？

時鐘已經開始走了：根據 GDPR，期限是一個月，複雜的請求可以再延長兩個月。副本地圖必須在請求到來之前就存在。重讀時鐘已經開始走了。

延伸探索

Section titled “延伸探索 ”