理解企業資料
另有 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)
Data Architect 課程第 4 章的學習指南。請先閱讀六個模組；這一頁幫你檢查自己記住了什麼。
**關於本學習指南。**它只依據本課程自己的內容，以及 Salesforce 公開發布的考試指南中的目標清單編寫。它從不基於真實的考試題目，也不聲稱知道考試會考什麼。如果你參加過考試，請不要把考題發給我：認證協議禁止分享考題，而且死記答案本來就不是成為架構師的正確方式。
考試指南說它不考非 Salesforce 的資料庫概念，而本章的大部分內容講的是 Salesforce 周圍的企業。所以和第 1 章一樣，這份清單寫明每一點支撐的是哪些目標。但不要跳過它：很多考試情景都從一個 ERP、一個數據倉庫或第二個 org 開始，而答案取決於誰擁有資料。
邊學邊打勾。每一條都連結到講授它的地方。
誰擁有資料（支撐 SDM-2、SDM-3 和主資料一章）
- 我能說出每類資料的記錄系統是哪個，並把這句話說完：記錄什麼的系統？（Salesforce 常常不是記錄系統，不要從產品名稱開始）
- 我知道常見的模式：客戶、產品和價格從 ERP 流入，訂單流出，也知道訂單箭頭依賴其他箭頭；然後我會問回程。（我一再看到的那種整合，單向箭頭讓我不安）
- 我會對主資料問三個問題：它在哪裡建立，在哪裡編輯，在哪裡被引用？（類別背後的四個問題）
- 我知道副本不是權威：ERP 擁有的資料在本地讀取、在受控的方式下寫入，並把 ERP 的識別符號保留為外部 ID。（ERP：後臺有引力，全景圖會改變資料模型）
資料的類型及其工作負載（支撐 DM-1、LDV-1 和 MDM-4）
- 我能區分主資料、參考資料、交易資料、後設資料、分析資料和非結構化資料，也知道每一種對它放在哪裡意味著什麼。（從類型開始，而不是從物件開始）
- 我知道參考資料雖小，卻是整合假設藏身的地方（
Delivered、Complete、D）。（參考資料） - 我能區分運營（OLTP）、分析（OLAP）和流式工作負載：org 經營業務，資料倉儲和資料湖分析業務。（類型只是問題的一半）
- 我知道同步（在門口等著）、非同步（繼續做別的，回來時再處理）和批次處理（每小時、每幾小時、每天）的區別，知道什麼時候批次處理就夠了，也知道即時是有代價的。（它需要多快地流動？）
- 我會對每個資料集問四個問題：誰擁有它，它變化得多快，它會變得多大，以及它的生命週期。（類別背後的四個問題）
Salesforce 周圍的系統（支撐 SDM-3、LDV-3 和整合相關章節）
- 我知道四種系統角色：記錄、互動、參考和洞察。（不要從產品名稱開始）
- 我知道分析放在哪裡，取決於資料放在哪裡：全都在 Salesforce 裡時用核心報表；涉及其他儲存時用分析平台（Tableau，包括 Tableau Next，或者在已經使用它的地方用 CRM Analytics）或資料倉儲。（分析放在資料所在的地方）
- 我知道資料倉儲、資料湖和湖倉是什麼，也知道 MDM、ESB 或 iPaaS 以及事件的角色。（資料倉儲、資料湖和湖倉，整合層與事件）
- 我從第一天起就把身分提供商畫到全景圖上，也知道 SSO 配置可以部署，但金鑰和憑證不會隨之遷移；在全景圖上它是一個共用憑證（信任），而不是一次呼叫，因為登入是通過瀏覽器進行的。（開發人員會忘記的系統：身分）
- 我知道 Data 360 是近核心（在核心之上管理，在核心之外託管），也知道它的零複製讓資料無需複製就能被查詢。（Data 360 放在哪裡？，核心、核心之外與 Hyperforce）
org 與託管（支撐 SDM-4）
- 我從一個 org 開始，在新增另一個之前，先尋找一條真實的邊界（資料駐留、監管、法律上的隔離、不同的運營模式、一次收購）。（從一個 org 開始，尋找真正的邊界）
- 我知道多個 org 的代價：全球報表、主資料、整合、身分和部署，每一項都成倍增加。（再走查一遍箭頭）
- 我知道 Hyperforce 讓你選擇 org 的資料駐留在哪個區域（而不是哪家雲提供商），但並不承諾每一項服務都留在那裡；也知道 GDPR 本身並不要求單獨一個 org：它為離開歐盟的個人資料制定規則，而一家公司可以選擇用一個歐洲 org 來滿足這些規則。（託管是圖的一部分，當歐洲有了自己的 org）
畫出和讀懂全景圖（支撐每一個情景）
- 我能畫出一張全景圖：人在左邊，Salesforce 在中間、它的社群在下方緊貼著它，身分在上方，整合和後臺在右邊，Data 360 在整合層下方，渠道在下方，資料進出在右下角。（Steve 的全景圖佈局）
- 在全景圖上，箭頭從開啟連線的那個系統開始，它的標籤說明移動的是什麼以及朝哪個方向；在資料流圖上，箭頭跟著資料走。兩條資料流就是兩個箭頭。（現在畫出箭頭）
- 對於每一個箭頭，我都知道用戶端處理什麼、伺服器定義什麼：位置、認證、協議和契約、資料載荷、時序、追蹤、錯誤。Salesforce 向外呼叫時，用命名憑據及其外部憑據；有東西呼叫 Salesforce 時，用 External Client App（外部用戶端應用）和一個僅限 API 的整合使用者。（每一個箭頭都需要一個機制）
- 我在畫箭頭之前先數一數：資料量寫進清單，並決定機制，甚至可以改變箭頭指向的方向。（把零的個數寫進清單）
- 只有當一個流程有一兩次以上的往返互動時，我才畫泳道。（箭頭畫在全景圖上，對話畫在泳道裡）
考試是底線，不是天花板。下面這些是本章中架構師需要的習慣，不管有沒有考題問到它們。
- **在設計 org 之前先畫全景圖。**從一張空白畫布開始。
- **把鏡頭拉遠。**Salesforce 只是眾多系統之一。
- **新的一波很少會讓舊的一波消失。**為實際存在的企業做架構，而不是為產品手冊。
- **把全景圖當作職責來讀，**而不是標誌。
- **單向箭頭讓我不安。**這條資料流依賴什麼，什麼會回傳？
- 每一個箭頭都需要一個機制。「fire and forget」不是答案。
- 箭頭畫在全景圖上，對話畫在泳道裡。
- **畫箭頭之前先數一數。**零的個數寫進清單，由它們來選擇機制。
- **在修復之前先畫出現狀：**那份電子表格，那個 SFTP 投遞，那個「我們正在退役的」系統。
- **如實標出現狀：**紅色表示糟糕的流程，虛線表示手工完成，紅色點線表示缺失的東西。每一條紅線都是一條等著被寫下來的需求。
- **兩條資料流，兩個箭頭。**雙向箭頭只用於聯結器。
- **不要扮演律師。**問清楚你在滿足哪項具體需求，並和擁有這項需求的人一起把它翻譯出來。
- 分開不等於簡單。
| 術語 | 一句話解釋 |
|---|---|
| 系統全景圖 | Salesforce 周圍的系統、使用它們的人，以及它們之間重要的資料流 |
| 記錄系統 | 儲存某類資料權威版本的地方 |
| 互動系統 | 人們做事的地方 |
| 參考系統 | 一個系統去查閱它需要但並不擁有的資訊的地方 |
| 洞察系統 | 資料匯聚起來用於度量、分析和預測的地方 |
| ERP | 負責財務、產品、庫存、採購和履約的後臺系統 |
| 主資料 | 業務圍繞其運轉的持久事物：客戶、產品、地點 |
| 參考資料 | 給其他資料分類的共用詞彙：程式碼、狀態、類別 |
| 交易資料 | 發生了什麼的記錄：訂單、配送、付款、案例 |
| 分析資料 | 從其他資料推匯出來、用於度量和比較的資料 |
| 非結構化資料 | 文件、圖片、音訊、影片、轉錄文字 |
| 資料倉儲 / 資料湖 / 湖倉 | 結構化的分析儲存 / 大規模的原始資料儲存 / 兩者的結合 |
| ESB / iPaaS | 在系統之間充當中介的整合層 |
| OLTP / OLAP | 一次處理少量記錄的運營工作 / 跨大量記錄的分析 |
| 近核心 | 在核心之上管理，在核心之外託管：Data 360 |
| 命名憑據 / 外部憑據 | Salesforce 儲存出站端點的地方 / 儲存其認證資訊的地方 |
| External Client App（外部用戶端應用） | 外部系統如何獲得授權來呼叫 Salesforce |
| 現狀 | 設計之前、今天實際存在的全景圖；標出了哪裡不對 |
| 身分提供商（IdP） | 認證使用者並建立 Salesforce 所信任的身分的系統 |
| 同步 / 非同步 / 批次處理 | 等待答案 / 繼續做別的，答案來了再處理 / 按計劃成批移動資料 |
| Hyperforce | 執行在公有雲基礎設施上的 Salesforce，可以選擇區域 |
| 零複製 | 在資料所在的地方查詢資料，而不復制它 |
按課程風格編寫的簡短情景題。開啟答案之前，先想好你的答案。
1. 銷售人員在 Salesforce 中跟進客戶，但客戶一旦購買，ERP 就簽發正式的客戶編號。Salesforce 把訂單發給 ERP。你需要設計什麼？
每個階段誰擁有客戶；把 ERP 的編號作為客戶上的外部 ID；Salesforce 可以修改哪些欄位；ERP 的變更多快到達；以及訂單發出後什麼會回傳（被接受、被拒絕、已發貨、已開票）。重讀全景圖會改變資料模型。
2. 領導層想要按區域統計、並與財務資料關聯的五年準時表現。用 Salesforce 報表來做嗎？
多半不行。這是跨多個儲存的分析工作負載，所以它屬於資料匯聚的地方：資料倉儲，上面再加 CRM Analytics 或 Tableau。分析放在哪裡，取決於資料放在哪裡。重讀分析放在資料所在的地方。
3. 一家公司在 30 個國家運營，要求每個國家一個 org。你會問什麼？
每個國家帶來了什麼需求：儲存、處理、跨境傳輸、合同、不同的託管方。沒有真實的邊界，就從一個 org 開始，因為每多一個 org，報表、主資料、整合、身分和部署都會成倍增加。重讀地理位置並不自動構成 org 策略。
4. 卡車每天傳送 20 萬條 GPS 讀數。Salesforce 應該把它們全部存下來嗎？
多半不應該。這是流式資料：排程員需要的是當前位置，而歷史和趨勢屬於為這種資料量而構建的平台。數一數零（每年超過 7,000 萬條），把「它現在在哪裡？」和「上個季度發生了什麼？」分開。重讀類型只是問題的一半。
5. 配送小組在 Salesforce 中處理他們的停靠點，但路線是在一個遺留排程工具裡建的，兩者之間沒有任何連線。你怎麼畫今天的樣子？
照實畫，並標明是現狀：路線被重新錄入 Salesforce，完成的停靠點再被錄回去，用虛線是因為這是人在做，用紅色是因為這是不對的。不要畫你希望存在的整合；每一條紅線都會成為設計的一條需求。重讀標出哪裡不對和RouteDesk 仍然在那裡。
6. 有人說歐洲的隱私法要求單獨一個 org。你怎麼回應？
既不要盲目接受，也不要直接否決。GDPR 本身並不要求單獨一個 org；它為個人資料制定規則，包括傳輸到歐盟以外。問清楚它滿足的是哪項具體需求（儲存、處理、傳輸、支援存取、一份合同、政策），然後和隱私、法務及安全團隊一起把它轉化為架構。重讀不要扮演律師和當歐洲有了自己的 org。
7. Salesforce 把訂單傳送到 ERP 的 API。哪一方處理重試，Salesforce 把金鑰存在哪裡？
Salesforce 是用戶端：它開啟連線，看到整個往返過程，是唯一能夠重試的一方。命名憑據儲存端點，它的外部憑據儲存認證資訊。ERP 是伺服器，定義契約並驗證進來的東西。重讀每一個箭頭都需要一個機制。
8. 一個整合今天每分鐘傳送幾條記錄，而業務方預計明年每小時會有幾萬條。箭頭會變嗎？
可能它的機制會變，甚至方向也會變。每分鐘幾條記錄可以是從 Salesforce 發出的標註呼叫（callout）；多得多的記錄可能意味著釋出事件，由另一個系統訂閱，於是箭頭從另一端開始；一夜幾百萬條就是批次處理。在做選擇之前先知道數量。重讀把零的個數寫進清單。
- Salesforce Certified Platform Data Architect Exam Guide (opens in a new tab)，Salesforce Help（英文，查閱日期 2026-09-25）：官方的考試目標清單及其權重。預約考試前，務必檢視最新版本。