企業資料的類型
另有 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)
第 2 個模組，共 6 個，屬於 Data Architect 課程第 4 章理解企業資料。每個模組都可以單獨閱讀。 上一篇：Salesforce 只是眾多系統之一 · 下一篇：Salesforce 周圍的系統
**本模組回答的問題：**一個企業擁有哪些類型的資料，為什麼它們屬於不同的地方？
一條客戶記錄。一份國家清單。一個訂單。一個欄位定義。五年的銷售總額。四百萬張配送照片。它們都是資料，但在架構上它們不是同一樣東西。它們的變化方式不同，增長方式不同，使用方式不同，所有者也不同，所以它們不應該自動放在同一個地方。所以當有人說「我們需要把這些資料放進 Salesforce」時，我接下來的問題是：**它是哪類資料？**答案會開始告訴我該怎麼處理它。
從類型開始，而不是從物件開始
Section titled “從類型開始，而不是從物件開始 ”作為 Salesforce 從業者，我們幾乎會立刻把需求翻譯成結構：客戶，客戶物件；照片，檔案；狀態，挑選清單。這最終是有用的。但在企業層面，我首先想知道自己面對的是哪類資訊。分類的方式有很多（DAMA 知識體系是標準參考），我覺得有六種類型很有用：**主資料、參考資料、交易資料、後設資料、分析資料和非結構化資料。**這些類別本身不是架構，而是一種提出更好問題的方式。
主資料：業務所知道的事物
Section titled “主資料：業務所知道的事物 ”主資料描述業務圍繞其運轉的那些持久的事物：客戶、產品、定價、員工、供應商、地點、資產。在一個 Salesforce 銷售 org 裡，就是你的客戶和連絡人、你的產品和價格手冊。在 Steve Trucking，零售合作夥伴是主資料。Keystone 不是一個事件，而是一個與 Steve Trucking 有持續關係的組織。九個配送中心也是主資料。
主資料比使用它的交易存在得更久：一個零售合作夥伴可以有幾百萬次配送。所以關於它的第一個問題總是**誰擁有它？**可能不是 Salesforce。ERP 可能擁有產品。Salesforce 可能擁有潛在客戶，而一旦他們成為客戶，ERP 就成為權威。一個 MDM 平台可能擁有由多個系統拼合而成的企業級客戶身分。第 6 章「主資料與身分」會深入討論。現在，先認出它的形狀。
參考資料：業務共用的詞彙
Section titled “參考資料：業務共用的詞彙 ”參考資料是用來給其他資料分類的受控詞彙：國家程式碼、貨幣、產品類別、原因程式碼、狀態。Steve Trucking 的配送狀態（已排期、已裝車、配送中、即將到達、已送達、已安裝、異常、已退回）就是參考資料。它們不是配送，而是用來描述配送的詞。
它看起來小而無害，常常只是一個有八個值的挑選清單。不要把小和不重要混為一談。如果 Salesforce 說 Delivered，ERP 說 Complete，某個零售合作夥伴發來 D，就得有人定義每個值是什麼意思、它們如何對映。參考資料是整合假設藏身的地方。
交易資料：發生了什麼
Section titled “交易資料：發生了什麼 ”交易資料記錄活動：下了一個訂單，付了一筆款，完成了一次配送，開了一個案例。在同一個銷售 org 裡，就是報價和報價行、訂單和訂單項、付款：每一條都指回一個客戶和一個產品。Steve Trucking 每年一百萬次配送是交易資料，它們的狀態更新也是：每次配送大約八次，所以每年八百萬次狀態變更，而業務每年增長 30%。
這和主資料的增長曲線完全不同。頂上是三個零售合作夥伴；底下是幾百萬行。這就是 Steve 的「零的個數」 發揮作用的地方：你不能看著零售合作夥伴 → 配送 → 狀態，就給每個方框同樣的分量。面對交易資料，我會立刻想到資料量、速度、保留、歷史、歸檔、整合，以及人們實際需要如何找到它。第 2 部分會在那裡花很多時間。
後設資料：關於資料的資料
Section titled “後設資料：關於資料的資料 ”整門課你都在和後設資料打交道：一個物件的定義，一個欄位的類型、它的描述、它的關係。整個企業都有後設資料：資料倉儲的結構、整合對映、資料目錄、API 契約，以及每個欄位的所有者、敏感級別、定義、血緣和保留規則。值是資料；對它們含義的描述是後設資料。正如第 3 章所說，Flag2__c 什麼也沒告訴任何人，而現在 AI 會讀取後設資料來弄清資料的含義，這一點就更重要了。
分析資料：我們從其他資料中製造出來的資料
Section titled “分析資料：我們從其他資料中製造出來的資料 ”「過去五年我們按零售合作夥伴統計的準時率是多少？」不是一筆交易。它是一個分析問題，要通過從幾百萬次配送中推匯出新資料來回答：準時百分比、貨損率、每個合作夥伴的收入、安裝品質、配送小組的趨勢。而且這是另一份工作。排程員問「217 號卡車的下一站是哪裡？」時，不需要掃描五年的歷史。領導層按區域比較五年的準時表現時，就需要。這就是為什麼分析資料通常放在為這種工作而構建的資料倉儲、湖倉或分析平台裡。Salesforce 能夠儲存某樣東西，並不意味著運營平台就是對它執行每一項分析的地方。
非結構化資料：裝不進行裡的東西
Section titled “非結構化資料：裝不進行裡的東西 ”文件、PDF、圖片、音訊、影片、電子郵件、轉錄文字、知識文章。在 Steve Trucking，就是配送照片：每次配送大約四張，有安裝的更多，每年四五百萬張。一張照片不只是又一個欄位。它很大，它可能拍到某人家裡的樣子，它有自己的保留規則，而且它的搜尋方式不同，如果能搜尋的話。
這類資料一年比一年重要，因為 AI 現在能對過去處於結構化模型之外的資訊做有用的事。一份轉錄文字是資料。一本 PDF 手冊是資料。一張安裝照片是資料。這並不意味著它屬於 Salesforce 的核心平台。它意味著它屬於全景圖。
六種資料，每種四個問題。答案隨種類而變，這正是關鍵所在。
類型只是問題的一半：工作負載
Section titled “類型只是問題的一半：工作負載 ”知道我們有哪類資料還不夠。我還想知道**我們要用它做什麼。**這裡有三種工作負載很重要，把它們混淆就會產生糟糕的架構。
**運營：經營業務。**排程員更新一次配送，配送小組完成一個停靠點，服務人員開一個案例。大量的小規模讀寫：找到這個，更新那個，給我看今天的停靠點。這就是 OLTP，聯機事務處理，而 Salesforce 非常擅長這個；這是管理員和開發人員的主場。
**分析：理解業務。**五年裡的每一次配送，按合作夥伴和配送中心分組，逐年比較，再和財務資料關聯。現在我們是在掃描和聚合。這就是 OLAP，聯機分析處理，資料倉儲、湖倉和分析平台正是為此而建的。簡單地說：**org 經營業務；資料倉儲和資料湖分析業務。**一個經典的錯誤，是把這種工作負載放到運營平台上，然後在零越來越多時感到意外。如果有人想反覆掃描海量的歷史，不要把它當作「又一份報表」。要問一問這是不是合適的平台。第 2 部分會在為規模而設計 *(coming soon)*中回到這一點（不要把核心當成你的資料倉儲），第 3 部分會在超越關係型 *(coming soon)*中展示分析結構是如何構建的。
**流式：流動中的資料。**事件、遙測、狀態變更、感測器讀數。Steve Trucking 的卡車每天傳送大約 **20 萬條 GPS 讀數。**排程員關心的是 217 號卡車現在在哪裡。Salesforce 需要保留每輛卡車每分鐘的每一條讀數嗎？也許不需要。「它現在在哪裡？」和「上個季度的路線效率趨勢如何？」來自同一個來源，卻導向完全不同的儲存決定。
它需要多快地流動？
Section titled “它需要多快地流動？ ”然後是延遲。我在課上是這麼說的：即時就是站在門口等某人回來。你派他們出去，然後站在那裡，因為在他們回來之前你沒法繼續。這就是同步。近即時就是看著他們離開，然後去做別的事；他們不久後回來時，你再處理。這就是非同步。然後還有批次處理：沒有人一個一個地出門。資料先等著，再按計劃成批移動：每小時、每幾小時或每天。很多情況下批次處理就足夠了，也有些情況不夠。分清哪是哪，正是你的工作。這三個不只是整合術語，而是架構上的選擇。
拿常見的 ERP 整合來說。上午 11 點，ERP 裡建立了一個新產品。銷售真的需要在中午之前就能賣它嗎？兩種答案我都見過。有些客戶希望越快越好；另一些客戶說，如果我們還沒把那個 SKU 發給你們，就不能指望你們現在去賣它。所以產品通常每天同步一次，有時更快。客戶，至少每天一次；我見過每小時的，極端情況下是近即時的。訂單就不同了：履約必須開始，所以要近即時。銷售人員成交後就去做別的事了，訂單在幾秒到一兩分鐘內到達 ERP。「企業資料」沒有唯一正確的延遲。問一問業務實際需要什麼，不要因為聽起來厲害就把一切都做成即時的。即時是有代價的。
類別背後的四個問題
Section titled “類別背後的四個問題 ”你不需要到處宣佈「這是交易資料！」分類的意義，在於對每一個重要的資料集引出四個問題：
- 誰擁有它？哪個系統是權威的？我把它拆成三個問題：它在哪裡建立，在哪裡編輯，在哪裡被引用？第 6 章會深入討論這些（在哪裡建立、編輯、引用，變化多快？）。
- **它變化得多快？**一年一次、每天、每秒幾十到幾百次？
- **它會變得多大？**十條記錄、一萬條、一千萬條、一百億條？
- **它的生命週期是什麼？**它會永遠存在、被歸檔、必須被刪除，還是會隨時間失去價值？
這四個問題告訴我的，遠比「Salesforce 能存這個嗎？」要多得多。它們也把我們已經學過的東西串了起來：所有權、生命週期、零的個數、資料放在哪裡。
一個業務會產生每一種資料
Section titled “一個業務會產生每一種資料 ”在 Steve Trucking，零售合作夥伴是主資料；狀態詞彙是參考資料；每次配送是交易資料；它的欄位定義是後設資料；五年準時率記分卡是分析資料；安裝照片是非結構化資料；GPS 資料流是流式資料。它們都是「Steve Trucking 的資料」。但這並不意味著它們屬於同一個資料庫。這就是那個轉變。
**考試之外：AI 改變了什麼。**為了回答一個問題，代理程式可能需要一條結構化的客戶記錄、一筆最近的交易、一本 PDF 手冊、一份服務轉錄文字和即時遙測資料。非結構化資料和流式資料成為架構中的一等成員，即使它們不屬於 CRM 資料庫，而架構師仍然必須知道每個來源歸誰所有、它有多新，以及代理程式是否應該信任它。
架構師在這裡決定什麼
Section titled “架構師在這裡決定什麼 ”- 每一個重要的資料集是哪類資料，以及誰擁有它。
- 它的工作負載是運營、分析、流式，還是混合。
- 它變化得多快，以及其他系統真正需要多快看到這個變化。
- 資料量和生命週期如何決定它放在哪裡、放多久。
- Salesforce 應該擁有它、保留一份副本、引用它，還是把它留在更適合這種工作負載的地方。
當有人交給你一項需求時，不要直接跳到哪個物件、哪個欄位、哪個 API。先問它是哪類資料，誰擁有它，它變化得多快，它會變得多大，它存在多久，以及我們想用它做什麼。一個客戶、一個配送事件、一個五年彙總和一張照片，可能對同一個業務都很重要，卻不是同一個架構問題。
- DAMA International，DAMA-DMBOK: Data Management Body of Knowledge，第 2 版（2017，英文）：關於資料類別和資料管理的標準參考。
- Steve Trucking 的簡介，第 4 節（資料量）。