Salesforce 超大量資料匯入優化策略
https://zhuanlan.zhihu.com/p/35101315
Salesforce和很多其他系統都可以很好的協作。在協作過程中，資料的匯入匯出便成為了一個關鍵的步驟。
當客戶的業務量非常大的時候，會有將超大量資料匯入Salesforce的需求。對於超大量資料的匯入，必須做好萬全的準備，才能保證匯入過程的順利與高效。
對於超大量資料匯入過程，可以從多個方面進行優化。它們也適用於Salesforce的其他功能。
精簡表
有些時候，業務中涉及到大量、複雜的關係。在Salesforce中設計對應的物件時，可能會出現很多物件，它們互相之間存在複雜的聯絡。在進行查詢的時候，Salesforce內部會將儲存這些物件和關係的資料表進行聯合（JOIN）操作，從而會消耗很多系統資源。
採用“精簡表”（Skinny Table）可以對這種情況進行優化。精簡表從若干資料表中提取相關欄位，集中儲存起來，使得Salesforce在進行查詢時不需要進行多表的聯合，而是直接從精簡表中查詢，提高了效率。
比如：在Salesforce中物件的標準欄位和自定義欄位是分開存放的。對於Account物件，有表A（儲存了標準欄位）和表B（儲存了自定義欄位）。當用戶對Account物件進行查詢時，系統會將表A和表B進行聯合，給出查詢結果。為了避免聯合操作，可以建立一個精簡表C，其中同時存放了來自表A和表B的欄位，它們都是使用者需要經常使用和查詢的。那麼在使用者對Account物件進行查詢時，Salesforce直接對錶C進行查詢即可。
要注意的是，每一張精簡表中的各個欄位只能屬於同一個物件，並且只能通過Salesforce的客服進行申請建立。
欄位索引
為了優化各種查詢語句，Salesforce內部使用了查詢優化器。查詢優化器中包括的最重要一點就是欄位索引。在Salesforce中對很多欄位都可以設定索引，或者自動被索引，比如Id、Name、CreatedById、CreatedDate，還有被設定為“唯一”（Unique）或“外部ID”（External ID）的欄位。
在使用Salesforce的SOQL語言進行查詢時，在WHERE部分儘量使用索引的欄位，可以極大的提高查詢效率。
有些欄位的索引必須通過Salesforce的客服來啟用。
記錄所有者優化
Salesforce規定每條記錄必須有所有者（Owner）。與此同時，Salesforce中對於資料記錄的許可權有著複雜的設定。每當資料記錄的所有者的許可權發生變化時，Salesforce會自動計算其所擁有的所有記錄的許可權。
在超大量資料的匯入過程中，會產生很多資料，它們都需要被分配所有者。如果將大量記錄統一分配到同一個使用者作為所有者，而該使用者在今後被更改了角色設定，那麼所有屬於該使用者的記錄都會被重新計算許可權。記錄的數量越大，計算所需的系統資源就會越大。
為了避免這種情況的發生，在進行匯入資料的時候，需要儘量避免讓同一個使用者擁有過多的記錄（10000條以內）。
如果某個使用者必須成為很多記錄的所有者，則儘量將此使用者的角色定位為角色結構的頂端，並且儘量不要更改該使用者的角色，這樣可以避免非常多的許可權重新計算。其他使用者可以通過其他的共享設定來讀取該使用者擁有的資料記錄。
物件的關係優化
Salesforce中可以對物件之間進行各種關係的定義，比如Lookup型別、Master-Detail型別等。當用戶對於某條記錄擁有許可權，那麼該使用者對於此條記錄的相關父記錄也擁有許可權。這些計算是Salesforce自動完成的。當某條資料記錄擁有過多數量的相關子資料記錄，而某條子記錄被修改的時候，Salesforce有可能會執行相當多的計算量來檢查各條資料記錄的許可權。
舉個例子：
- 某條Account記錄擁有100個Contact記錄，Account記錄的所有者不是使用者A，而所有Contact記錄的所有者都是A，那麼A自動獲得了該Account記錄的許可權。
- 當A將某條Contact記錄的所有者改為使用者B時，B同時得到了該Contact記錄和Account記錄的許可權，而A則失去了該Contact記錄的許可權。
- 與此同時，Salesforce為了檢查A是否還擁有Account記錄的許可權，會檢查所有其他的99條Contact記錄，只有當A失去了所有的Contact記錄的許可權後，A才會失去Account記錄的許可權。
從這個例子可以看出，當某條記錄包含了太多的子記錄時，更改某個子記錄的許可權會導致Salesforce對所有其他的記錄進行一一檢查，會耗費相當多的系統資源。
要解決這個問題，就要儘量避免某條父記錄下擁有過多（10000條以上）的子記錄。
精簡物件相關設定
Salesforce中對於物件的共享許可權、關係等設定有很多種。在進行資料匯入時，Salesforce會根據這些設定對資料進行檢測。當這些檢測的數量過多的時候，會消耗相當多的系統資源。從以下幾個方面可以進行優化：
- 組織預設共享許可權（Organization-wide sharing defaults）：當匯入了一條記錄時，如果該記錄所屬的物件有著預設的公開讀寫許可權（Public Read/Write），那麼系統會跳過對其許可權的計算，減少了系統資源的使用。
- 物件關係：如果某物件和其他物件有著過多的“父-子”關係，那麼當匯入屬於該物件的一條記錄時，其相關的各種子記錄的許可權都會被檢查。所以減少物件之間複雜的關係可以減少多餘的檢查，減少了系統資源的使用。
- 共享規則（Sharing rule）：如果某物件被設定了很多的共享規則，在匯入該物件的資料記錄時，Salesforce會根據這些共享規則對其進行各種許可權的檢查，會消耗很多系統資源。
- 驗證規則（Validation rule），觸發器（trigger），工作流規則（Workflow rule）：這些設定都會在資料匯入時執行。當某物件擁有過多的這些設定，它們的執行會消耗非常多的系統資源。
資料匯入的最佳實踐
在匯入資料前：
- 啟用並行許可權計算（parallel recalculation）和延遲共享計算（defer sharing calculation）功能：進行大量資料匯入會導致非常長的共享規則計算。要避免這些問題，可以在資料匯入的過程中將這些計算所消耗的系統資源減少。
- 建立角色結構定義
- 在匯入資料之前匯入使用者。
- 儘可能的將物件的組織預設共享許可權（Organization-wide sharing defaults）設定為公開讀寫許可權（Public Read/Write），從而讓系統跳過對這些物件的記錄的許可權計算。
- 讓資料儘可能的“乾淨”，尤其是各種外來鍵關係。如果有破壞了這些關係的資料存在，會在匯入過程中跳出錯誤，延長匯入的時間。
- 儘可能的停用資料相關的設定，比如驗證規則（Validation rule），觸發器（trigger），工作流規則（Workflow rule）。
在匯入資料時：
- 如果物件之間有“父-子”關係，確保首先匯入父物件，在匯入子物件，確保匯入的資料是“乾淨”的，不會出錯的。
- 儘量使用insert和update的方式進行匯入，而非upsert方式，因為後者需要更多的時間來完成操作。
- 當使用update方式進行資料匯入，讓匯入的資料只包含更新的欄位，而非物件的所有欄位。
- Salesforce在更新子記錄時，其所屬的父記錄會被鎖定，直到子記錄更新完成。在匯入子記錄時，儘量將從屬於同一條父記錄的子記錄分成一組，從而在匯入的過程中同一條父記錄不會被不同的執行緒鎖定。