問題所在
<我必須將大量的.tar.gz檔案（500萬）下載到AWS S3，每個檔案的大小約為1 Mb，存盤在外部FTP服務器上（我不控制它）。
我的嘗試
我已經實作了一個基于python的concurrent.futures.ThreadPoolExecutor和s3fs模塊的解決方案。我對一個10K檔案的子集進行了測驗，整個程序大約需要20分鐘（使用這種方法下載，然后使用s3fs存盤到AWS S3）。這意味著每分鐘要處理10,000 / 20 = 500個檔案。對于500萬，需要5M / 500 = 10,000分鐘的處理時間=7天。我等不起這個時間（因為時間和成本，而且我擔心FTP服務器會破壞與我的IP的連接）。
為了這個任務，我使用了一個r5.metal實體，這是我在EC2目錄上能找到的在vCPUs（96）和網路性能方面最強大的實體之一。
我的問題
所以我問：
- 這個問題的最佳解決方案是什么？
- 是否有一個需要不到一周時間的解決方案？
- 是否有一個需要不到一周時間的解決方案？
- 是否有比
r5.metal更適合這項作業的實體？ - 在AWS上是否有一個具有成本效益和可擴展的專用服務？
- 在這種特殊情況下，在
threading、multiprocessing和asyncio（和其他解決方案）之間最適應的是什么？同樣的問題也適用于下載1000個檔案，每個檔案大約50Mb. 。
非常感謝您的幫助。
uj5u.com熱心網友回復：
你可以采取兩種方法......
使用 Amazon EC2向你的Python腳本傳遞一個檔案子串列（100個）。讓它回圈瀏覽這些檔案，依次將每個檔案下載到本地磁盤。然后，使用 boto3 將其復制到 Amazon S3 上。
不要擔心如何把它寫成執行緒或做花哨的異步操作。相反，只需并行運行大量的 Python 腳本，每個腳本都有自己的檔案串列需要復制。一旦你有足夠多的腳本并行運行（只需在后臺使用&運行腳本），監控實體以確定瓶頸所在--你可能會發現CPU和記憶體并不是問題所在--更可能是遠程FTP服務器只能處理一定量的查詢和/或資料帶寬。
然后你應該能夠確定 "甜蜜點"，以最小的成本獲得最快的吞吐量（如果這甚至是一個考慮因素）。您甚至可以并行地運行多個 EC2 實體，每個實體都并行地運行腳本。
使用 AWS Lambda
將一個小的檔案名串列推送到一個亞馬遜SQS佇列中。
然后，創建一個AWS Lambda 函式，由 SQS 佇列觸發。該函式應從 FTP 服務器上檢索檔案，保存到本地磁盤，然后使用 boto3 將其復制到 S3。(確保在上傳至 S3 后洗掉檔案，因為 Lambda 函式容器中的空間有限。
這將使用AWS Lambda的并行功能來并行地執行操作。默認情況下，你可以并行運行1000個Lambda函式，但你可以請求增加這個限制。
首先用推入SQS佇列的幾個檔案進行測驗。如果這行得通，就發送幾千條訊息，看看它處理負載的能力如何。您也可以在 Lambda 中玩玩記憶體分配，但最低水平可能已經足夠了。
重新核對
假設檔案將無法下載。與其重新嘗試，不如讓它們失敗。
然后，在所有腳本運行后（在 EC2 或 Lambda 中），將上傳至 S3 的檔案與您的檔案主串列進行核對。請注意，在 S3 中列出檔案的速度可能有點慢（每次 API 呼叫會檢索 1000 個檔案），因此您可能希望使用Amazon S3 Inventory，它可以提供一個列出所有物件的每日 CSV 檔案。
常規
無論您采取哪種方法，都會出問題。例如，遠程 FTP 服務器可能只允許有限數量的連接。它可能有帶寬限制。下載將隨機失敗。由于這是一個一次性的活動，只下載檔案比制作世界上最好的程式更重要。如果你不想等待34天的下載，那么你就必須迅速得到something，這樣至少在你調整和改進流程的時候，它還能下載。
祝你好運! 讓我們知道你的進展！
祝你好運！
讓我們知道你的進展。
轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/319200.html
標籤：