使用 Azure Data Factory 將資料從 Amazon S3 遷移到 Azure 儲存體
適用於：
Azure Data Factory 
Azure Synapse Analytics
提示
試用 Microsoft Fabric 中的 Data Factory，這是適用於企業的全方位分析解決方案。 Microsoft Fabric 涵蓋從資料移動到資料科學、即時分析、商業智慧和報告的所有項目。 了解如何免費開始新的試用！
Azure Data Factory 提供具效能、強固，且符合成本效益的機制，以將資料從 Amazon S3 大規模遷移至 Azure Blob 儲存體或 Azure Data Lake Storage Gen2。 本文為資料工程師和開發人員提供下列資訊：
- 效能
- 複本恢復功能
- 網路安全性
- 高階解決方案架構
- 實作最佳做法
效能
ADF 提供無伺服器的架構，其可供以不同層級進行平行處理，允許開發人員建置管線來充分利用網路頻寬以及儲存體 IOPS 和頻寬來最大化環境的資料移動輸送量。
客戶已成功將由數以百萬計檔案組成的數 PB 資料從 Amazon S3 移動到 Azure Blob 儲存體，且將輸送量維持在 2 GBps 以上。
上圖說明如何透過不同層級的平行處理以達到絕佳資料移動速度：
- 單一複製活動可利用可縮放的計算資源: 使用 Azure Integration Runtime 時，您可以無伺服器的方式為每個複製活動指定最多 256 個 DIU；使用自我裝載整合執行階段時，您可手動擴大機器或擴增至多部機器 (最多四個節點)，而單一複製活動將在所有節點上對其檔案集進行分割。
- 單一複製活動會使用多個執行緒來從資料存放區讀取和寫入至資料存放區。
- ADF 控制流程可以平行方式啟動多個複製活動，例如使用 For Each 迴圈。
復原能力
在單一複製活動回合內，ADF 具備內建的重試機制，因此可處理資料存放區或基礎網路中特定層級的暫時性失敗。
執行從 S3 到 Blob，以及從 S3 到 ADLS Gen2 的二進位複製時，ADF 會自動執行檢查點。 若複製活動回合失敗或逾時，則在進行下一個重試時，複製會從上一個失敗點繼續，而非從頭開始。
網路安全性
根據預設，ADF 會透過 HTTPS 通訊協定以使用加密連線將資料從 Amazon S3 傳輸到 Azure Blob 儲存體或 Azure Data Lake Storage Gen2。 HTTPS 會提供傳輸中的資料加密，並可防止竊聽和中間人攻擊。
或者，若您不希望透過公用網際網路傳輸資料，則可透過 AWS Direct Connect 和 Azure Express Route 之間的私人對等互連連結來傳輸資料，以取得更高的安全性。 請參閱下一節中的解決方案架構，以了解如何達成此目的。
解決方案架構
透過公用網際網路遷移資料：
- 在此架構中，資料會透過公用網際網路，使用 HTTPS 安全地進行傳輸。
- 來源 Amazon S3 和目的地 Azure Blob 儲存體或 Azure Data Lake Storage Gen2 會設定為允許來自所有網路 IP 位址的流量。 請參閱此頁面稍後參考的第二個架構，以了解如何限制對特定 IP 範圍的網路存取。
- 您可以無伺服器的方式輕鬆進行擴大，以完整利用網路和儲存體頻寬來為環境取得最佳的輸送量。
- 初始快照集的移轉和差異資料移轉都可以使用此架構進行。
透過私人連結遷移資料：
- 在此架構中，資料移轉是透過 AWS Direct Connect 和 Azure Express Route 之間的私人對等互連連結來執行，因此資料永遠都不會在公用網際網路上周遊。 其需要使用 AWS VPC 和 Azure 虛擬網路。
- 您需要在 Azure 虛擬網路內的 Windows VM 上安裝 ADF 自我裝載整合執行階段，才能達成此架構。 您可手動擴大自我裝載的 IR VM，或擴增至多部 VM (最多四個節點) 來完整利用網路和儲存體 IOPS/頻寬。
- 初始快照集的資料移轉和差異資料移轉都可使用此架構進行。
實作最佳做法
驗證及認證管理
- 若要向 Amazon S3 帳戶進行驗證，則必須使用 IAM 帳戶的存取金鑰。
- 支援多個驗證類型來連線到 Azure Blob 儲存體。 我們強烈建議使用 Azure 資源受控識別: 在 Microsoft Entra ID 中的自動受控 ADF 識別之上建置，這可讓您設定管線，而不需在連結的服務定義中提供認證。 或者，您可使用服務主體、共用存取簽章，或儲存體帳戶金鑰來向 Azure Blob 儲存體進行驗證。
- 也支援多個驗證類型來連線到 Azure Data Lake Storage Gen2。 我們強烈建議使用 Azure 資源受控識別，雖然您也可使用服務主體或儲存體帳戶金鑰。
- 當不使用 Azure 資源受控識別時，強烈建議將認證儲存在 Azure Key Vault 中，讓您更輕鬆地集中管理和旋轉金鑰，而無須修改 ADF 連結的服務。 這也是其中一個 CI/CD 的最佳做法。
初始快照集資料移轉
特別是在遷移超過 100 TB 的資料時，建議使用資料分割。 若要分割資料，請使用「前置詞」設定來透過名稱篩選 Amazon S3 中的資料夾和檔案，接著每個 ADF 複製作業即可一次複製一個分割。 您可同時執行多個 ADF 複製作業，以達到更佳的輸送量。
若因為網路或資料存放區暫時性的問題而導致複製作業失敗，則可重新執行失敗的複製作業來從 AWS S3 重新載入該特定分割。 所有其他正在載入其他分割的複製作業都不會受到影響。
差異資料移轉
識別 AWS S3 新增或變更檔案效能最高的方式是使用時間分割命名慣例 ‒ 當您在 AWS S3 中的資料已使用檔案或資料夾名稱中的時間配量資訊進行時間分割時 (例如 /yyyy/mm/dd/file.csv)，管線即可輕易地識別要以累加方式複製的檔案/資料夾。
或者，若在 AWS S3 中的資料並未經過時間分割，則 ADF 可透過其 LastModifiedDate 來識別新增或變更的檔案。 其運作方式是 ADF 會掃描 AWS S3 的所有檔案，然後只複製其最後所修改時間戳記大於特定值的新增和更新檔案。 若您在 S3 中有大量的檔案，則無論符合篩選條件的檔案數量為何，初始檔案掃描可能會花費相當長的時間。 在這種情況下，建議先對資料進行分割，針對初始快照集移轉使用相同的「前置詞」設定，讓檔案掃描可以平行方式進行。
針對需要 Azure VM 上自我裝載整合執行階段的案例
無論是透過私人連結遷移資料，還是想要在 Amazon S3 防火牆上允許特定的 IP 範圍，您都需要在 Azure Windows VM 上安裝自我裝載整合執行階段。
- 針對每個 Azure VM 建議採取的初始設定是 Standard_D32s_v3，其中包含 32 個 vCPU 和 128 GB 的的記憶體。 您可在資料移轉期間持續監視 IR VM 的 CPU 和記憶體使用率，以了解是否需要進一步地擴大 VM 以改善效能，或縮小 VM 以節省成本。
- 您也可以將單一自我裝載 IR 與最多四個 VM 節點建立關聯，以進行擴增。 針對自我裝載 IR 執行的單一複製作業將會自動分割檔案集，並利用所有 VM 節點來以平行方式複製檔案。 為取得高可用性，建議從二個 VM 節點開始，以避免資料移轉期間的單一失敗點。
速率限制
最佳做法是使用代表性的範例資料集進行效能 POC，其可供判斷適當的分割大小。
使用預設 DIU 設定，從單一分割和單一複製活動開始。 逐步增加 DIU 設定，直到到達網路的頻寬限制，或資料存放區的 IOPS/頻寬限制，或到達在單一複製活動上所允許的 256 個 DIU 上限。
接下來，逐步增加同時複製活動的數量，直到達到環境的限制。
當 ADF 複製活動報告節流錯誤時，請減少 ADF 中的並行或 DIU 設定，或考慮增加網路和資料存放區的頻寬/IOPS 限制。
估計價格
注意
這是假設的定價範例。 實際定價取決於環境中的實際輸送量。
考慮下列為將資料從 S3 遷移至 Azure Blob 儲存體所建構的管線：
讓我們假設下列情況：
- 總資料量為 2 PB
- 使用第一個解決方案架構以透過 HTTPS 遷移資料
- 2 PB 會分成 1 KB 的分割區，且每個複製都會移動一個分割
- 每個複製都已設為 DIU=256，並達到 1 GBps 的輸送量
- ForEach 並行已設為 2，且彙總輸送量為 2 GBps
- 總計需要耗費 292 個小時來完成移轉
以下是根據上述假設所估計的價格:
其他參考
- Amazon Simple Storage Service 連接器
- Azure Blob 儲存體連接器
- Azure Data Lake Storage Gen2 連接器
- 複製活動效能調整指南 (機器翻譯)
- 建立和設定自我裝載整合執行階段 (機器翻譯)
- 自我裝載整合執行階段 HA 及可擴縮性 (機器翻譯)
- 資料移動安全性考量 (機器翻譯)
- 在 Azure Key Vault 中儲存認證 (機器翻譯)
- 根據時間分割檔案名稱，以累加方式複製檔案 (機器翻譯)
- 根據 LastModifiedDate 複製新增和變更的檔案 (機器翻譯)
- DF 定價頁面
範本
以下是用於將包含數億個檔案的 PB 級資料從 Amazon S3 移轉到 Azure Data Lake Storage Gen2 的入門範本。