5.3　定義需求

數據遷移服務有4個主要模塊：

接入模塊

負責將數據一次性或持續地從源數據存儲復制到目標數據存儲。

轉換模塊

負責將數據從源數據復制到目標數據時進行轉換。

合規模塊

確保用于分析的遷移數據遵循監管規定。

驗證模塊

確保源數據和目標數據之間的數據一致性。

每個組件的需求因部署的不同而不同，這取決于幾個因素，包括行業法規、平臺技術的成熟度、洞察用例的類型、現有數據流程、數據用戶的技能等。本節討論數據用戶在定義與數據遷移服務相關的需求時需要考慮的方面。

5.3.1　接入需求

數據接入需求主要考慮三個關鍵方面。

源數據存儲技術和目標數據存儲技術

從數據存儲中讀取和寫入數據需要一個特定技術的適配器。可用的解決方案根據其支持的適配器而有所不同。因此，列出當前部署的數據存儲非常重要。表5-1列出了一些常用的數據存儲類別。

數據規模

數據工程師需要了解的與數據規模相關的關鍵信息包括：

1. 表的行數有多少？

2. 表的物理內存大小是多少TB？

3. 當前要復制的表的數量大致是多少？

數據規模的另一個方面是變化率：根據新增、更新和刪除的數量來估計表是否在快速變化。利用數據的大小和更新率，數據工程師可以估計規模需求。

可接受的刷新延遲

對于探索性用例，數據遷移通常是一次性操作。對于數據的持續拷貝，有一些不同的選擇，如圖5-1所示。在圖中，預定的數據拷貝可以實現為批處理（周期性）操作，而不是連續操作。批處理操作既可以是表的完整副本，也可以是只拷貝上次變化的增量。對于連續拷貝，源數據上的更改將以近實時的方式（以秒或分鐘為單位）傳輸到目標上。

5.3.2　轉換需求

在數據遷移過程中，目標數據可能不是源數據的完整副本。作為數據遷移服務的一部分，定義服務需要支持的不同類型的轉換很重要。有4類轉換：

格式轉換

目標數據最常見的形式是源表的副本。目標數據也可以是源數據追加更新的日志，或者是代表表的更新、插入或刪除的更改事件列表。

自動模式演進

對于預定的數據遷移，源表的模式可以得到更新。數據遷移服務應該能夠自動適應變化。

過濾

原始源表或事件可能有需要從目標中過濾的字段。例如，目標表可能只需要源表中列的子集。此外，過濾還可以用于刪除重復的記錄。根據分析的類型，對刪除記錄的過濾可能需要特殊處理。例如，財務分析要求被刪除的記錄可以用刪除標志（稱為軟刪除）而不是用實際刪除（硬刪除）來標記。

聚合

在源數據跨多個孤島的場景中，轉換邏輯會聚合并創建一個單一的具體化視圖。聚合還可以通過連接不同的數據源來豐富數據。

5.3.3　合規需求

在數據遷移過程中，應該考慮多方面的合規性。圖5-2顯示了需要考慮的馬斯洛需求層次結構。在三角形的底部是合規性的三個A：身份驗證、訪問控制和審計跟蹤。上面是處理PII的加密和屏蔽方面的考慮。再往上是任何特定于監管合規的需求，如SOX、PCI等。最上面是數據權限合規，即遵守CCPA、GDPR等法律。

5.3.4　驗證需求

確保源數據和目標數據一致是數據遷移過程的關鍵。根據分析類型和所涉及的數據性質，可以定義不同的一致性檢查需求。例如，通過檢查行數是否一致可以確保所有源數據都反映在目標數據上。還有抽樣一致性檢查，比較行的子集以驗證源數據和目標數據上的記錄是否完全匹配，并且在數據遷移期間沒有出現數據損壞（比如數據列顯示為null）。其他質量檢查（比如列值分布和跨表引用完整性）詳見第9章。如果檢測到錯誤，應該將數據遷移服務配置為發出告警或使目標數據不可用。

5.3.5　非功能性需求

以下是在設計數據遷移服務時應該考慮的一些關鍵非功能性需求：

方便接入新的源數據存儲

簡化數據源所有者對服務的使用體驗，并支持主流的源數據存儲和目標數據存儲。

自動監控和故障恢復

服務應該能夠創建檢查點并從任何數據遷移失敗中恢復。在遷移大型表時，這一點尤其重要。解決方案中還應該包含一個全面的監控和告警框架。

盡量減少對數據源性能的影響

數據遷移不應該降低數據源的性能，因為這會直接影響應用程序的用戶體驗。

解決方案的擴展

考慮到數據的持續增長，該服務應該支持每天數千次的計劃性數據遷移。

社區廣泛使用的開源技術

在選擇開源解決方案時，請注意有一些是僵尸項目。確保開源項目是成熟的，并被社區廣泛使用。