將數百 TB 的資料遷移至 Azure Cosmos DB

  • 發行項

適用於：NoSQL MongoDB Cassandra Gremlin Table

Azure Cosmos DB 可以儲存 TB 級的資料。 您可以執行大規模資料移轉來將生產工作負載移動到 Azure Cosmos DB。 本文說明將大規模資料移至 Azure Cosmos DB 所涉及的挑戰，並介紹有助於因應這些挑戰以及將資料遷移至 Azure Cosmos DB 的工具。 在此案例研究中，客戶使用 Azure Cosmos DB API for NoSQL。

將整個工作負載遷移至 Azure Cosmos DB 之前，您可以先遷移一小部分資料來驗證某些層面，例如分割區索引鍵選擇、查詢效能和資料模型化。 驗證概念證明之後，就能將整個工作負載移至 Azure Cosmos DB。

資料移轉工具

目前 Azure Cosmos DB 的移轉策略會隨所選 API 和資料大小而不同。 若要遷移較小的資料集，以驗證資料模型化、查詢效能、分割區索引鍵選擇等，您可以使用 Azure Data Factory 的 Azure Cosmos DB 連接器。 如果熟悉 Spark，您也可以選擇使用 Azure Cosmos DB Spark 連接器來遷移資料。

大規模移轉的挑戰

現有將資料遷移至 Azure Cosmos DB 的工具有一些限制，規模很大時尤其明顯：

  • 擴增能力有限：為了儘快將數 TB 的資料遷移至 Azure Cosmos DB，並有效運用已佈建的全部輸送量，移轉用戶端的擴增能力必須不受限制。

  • 缺少進度追蹤和檢查點：遷移大型資料集時，必須追蹤移轉進度，還要有檢查點。 否則，只要移轉過程中出錯就會停止移轉，流程必須從頭開始。 當移轉過程完成 99% 時，全部重來很沒效率。

  • 缺乏無效信件佇列：在大型資料集內，部分來源資料有時會出現問題。 此外，用戶端或網路也可能發生暫時性問題。 無論何種狀況，都不致於造成整個移轉失敗。 雖然大部分移轉工具都有強大的重試能力，可防止間歇性問題，但總是力有未逮。 例如，如果不到 0.01% 的來源資料文件大於 2 MB，則會導致文件寫入在 Azure Cosmos DB 中失敗。 移轉工具最好將這些「失敗」文件保存到另一個無效信件佇列，等到移轉之後再處理。

對於 Azure Data Factory、Azure 資料移轉服務等工具，目前正在修正上述諸多限制。

自訂工具搭配大量執行工具程式庫

有一個自訂工具可以解決上節所述的挑戰，不僅可以跨多個執行個體輕鬆擴增，還能從暫時性失敗中復原。 此外，自訂工具可以在不同的檢查點暫停和繼續移轉。 Azure Cosmos DB 已提供大量執行工具程式庫，涵蓋上述部分功能。 例如，大量執行工具程式庫已有能力處理暫時性錯誤，還可以擴增單一節點中的執行緒，每個節點各耗用大約 500 K 個 RU。 大量執行工具程式庫也將來源資料集分割成多個微批次，像檢查點一樣獨立運作。

自訂工具使用大量執行工具程式庫，支援跨多個用戶端擴增，還可在擷取過程中追蹤錯誤。 若要使用此工具，應該在 Azure Data Lake Storage (ADLS) 中將來源資料分割成不同檔案，讓不同的移轉背景工作角色挑選每個檔案，並內嵌至 Azure Cosmos DB。 自訂工具利用單獨的集合，其中儲存 ADLS 中每一個來源檔案移轉進度的中繼資料，並追蹤任何相關的錯誤。

下圖說明使用此自訂工具進行的移轉流程。 此工具在一組虛擬機器上執行，各虛擬機器查詢 Azure Cosmos DB 中的追蹤集合，以獲得租用其中一個來源資料分割。 完成之後，工具讀取來源資料分割，並使用大量執行工具程式庫，將分割區內嵌至 Azure Cosmos DB。 接著，更新追蹤集合，以記錄資料擷取的進度及發生的任何錯誤。 處理來源資料分割之後，工具嘗試查詢下一個可用的來源資料分割。 繼續處理下一個來源資料分割，直到所有資料都遷移為止。 此工具的原始程式碼位於 Azure Cosmos DB 大量擷取存放庫。

Migration Tool Setup

追蹤集合包含如下列範例所示的文件。 來源資料中的每個分割區各有一份這種文件。 每份文件包含來源資料分割的中繼資料，例如位置、移轉狀態和錯誤 (若有)：

{ 
  "owner": "25812@bulkimporttest07", 
  "jsonStoreEntityImportResponse": { 
    "numberOfDocumentsReceived": 446688, 
    "isError": false, 
    "totalRequestUnitsConsumed": 3950252.2800000003, 
    "errorInfo": [], 
    "totalTimeTakenInSeconds": 188, 
    "numberOfDocumentsImported": 446688 
  }, 
  "storeType": "AZURE_BLOB", 
  "name": "sourceDataPartition", 
  "location": "sourceDataPartitionLocation", 
  "id": "sourceDataPartitionId", 
  "isInProgress": false, 
  "operation": "unpartitioned-writes", 
  "createDate": { 
    "seconds": 1561667225, 
    "nanos": 146000000 
  }, 
  "completeDate": { 
    "seconds": 1561667515, 
    "nanos": 180000000 
  }, 
  "isComplete": true 
}

資料移轉的必要條件

資料移轉開始之前，請注意幾項必要條件：

估計資料大小：

來源資料大小可能不準確對應至 Azure Cosmos DB 中的資料大小。 可以從來源插入幾份樣本文件，以檢查在 Azure Cosmos DB 中的資料大小。 根據樣本文件大小，就能估計移轉之後 Azure Cosmos DB 中的資料大小總計。

例如，如果移轉之後 Azure Cosmos DB 中的每份文件大約 1 KB，而來源資料集大約有 600 億份文件，這表示 Azure Cosmos DB 中的估計大小接近 60 TB。

預先建立具備足夠 RU 的容器：

雖然 Azure Cosmos DB 會自動擴增儲存體，但不建議從最小的容器大小開始。 容器愈小，可用的輸送量愈低，相對就需要更長的時間才能完成移轉。 相反地，最好以最終資料大小建立容器 (如上一個步驟所估計)，並確保移轉工作負載完全耗用已佈建的輸送量。

在上一個步驟中， 由於資料大小估計約為 60 TB，需要有至少 2.4 M RU 的容器，才能容納整個資料集。

估計移轉速度：

假設移轉工作負載可以耗用已佈建的全部輸送量，則從佈建的輸送量就能估計移轉速度。 接續前述範例，將 1 KB 文件寫入 Azure Cosmos DB API for NoSQL 帳戶需要 5 個 RU。 240 萬個 RU 每秒可以傳輸 480,000 份文件 (或 480 MB/秒)。 這表示完整移轉 60 TB 需要 125,000 秒，或大約 34 小時。

如果想在一天之內完成移轉，則應該將佈建的輸送量增加到 500 萬個 RU。

停止編製索引：

因為應該儘快完成移轉，在每個內嵌的文件上建立索引所耗的時間和 RU 最好降到最低。 Azure Cosmos DB 自動編製所有屬性的索引，最好只挑少數幾項來編製最少索引，或在移轉期間完全不要編製索引。 您可以將 indexingMode 變更為 none，以停用容器的編製索引原則，如下所示：

  { 
        "indexingMode": "none" 
  }

您可以在完成移轉之後再更新索引。

移轉程序

完成必要條件之後，您可以使用下列步驟來遷移資料：

  1. 首先，將資料從來源匯入 Azure Blob 儲存體。 為了加快移轉速度，最好平行處理各個來源資料分割。 開始移轉之前，應該將來源資料集分割成大約 200 MB 大小的檔案。

  2. 大量執行工具程式庫可以擴大，在單一用戶端 VM 中耗用 500,000 個 RU。 由於可用的輸送量為 500 萬個 RU，在您的 Azure Cosmos DB 資料庫所在的區域，應該佈建 10 個 Ubuntu 16.04 VM (Standard_D32_v3)。 您應該以移轉工具及其設定檔案來準備這些 VM。

  3. 在其中一部用戶端虛擬機器上，執行佇列步驟。 此步驟會建立追蹤集合，以掃描 ADLS 容器，並為每個來源資料集的分割區檔案建立進度追蹤文件。

  4. 接下來，在所有用戶端 VM 上執行匯入步驟。 每個用戶端都可以取得來源資料分割的所有權，並將資料內嵌至 Azure Cosmos DB。 一旦完成且追蹤集合中也更新狀態，用戶端就能在追蹤集合中查詢下一個可用的來源資料分割。

  5. 此流程持續到整組來源資料分割都內嵌為止。 處理所有來源資料分割之後，應該在相同的追蹤集合上以錯誤更正模式重新執行此工具。 需要此步驟來識別因為錯誤而應該重新處理的來源資料分割。

  6. 其中一些錯誤可能起因於來源資料中的不正確文件。 應該查明並修正。 接下來，您應該在失敗分割區上重新執行匯入步驟，以重新內嵌分割區。

完成移轉之後，您可以驗證 Azure Cosmos DB 與來源資料庫中的文件計數是否一致。 在此範例中，Azure Cosmos DB 中的大小總計結果為 65 TB。 移轉之後，您可以選擇開啟索引編製，並將 RU 數降到工作負載作業所需的程度。

下一步

  • 若要深入了解，請使用 .NET 和 JAVA 來試驗應用程式範例取用大量執行工具程式庫。
  • 大量執行工具程式庫已整合至 Azure Cosmos DB Spark 連接器，若要深入了解，請參閱 Azure Cosmos DB Spark 連接器一文。
  • 在大規模移轉方面，如需更多協助，請按照 [一般諮詢] 問題類型和 [大型 (TB+) 移轉] 問題子類別，提交支援票證，以連絡 Azure Cosmos DB 產品小組。
  • 正在嘗試為遷移至 Azure Cosmos DB 進行容量規劃嗎？ 您可以使用現有資料庫叢集的相關資訊進行容量規劃。