AWS Lambda 是否優於 AWS Glue 作業？

Question

在 AWS Glue 作業中，我們可以編寫一些腳本並通過作業執行腳本。

在 AWS Lambda 中，我們也可以編寫相同的腳本並執行上述作業中提供的相同邏輯。

所以，我的查詢不是 AWS Glue 作業與 AWS Lambda 之間的區別，而是我想了解什么時候應該優先選擇 AWS Glue 作業而不是 AWS Lambda，尤其是當兩者都做同樣的工作時？ 如果兩者都做同樣的工作，那么理想情況下我會盲目地更喜歡使用 AWS Lambda 本身，對嗎？

請嘗試理解我的查詢..

Answer 1

這個問題的答案可能涉及一些基礎設計決策。 這份工作是做什么的？ 你在處理什么樣的數據？ 是否需要決定任務應該以批處理還是面向事件的范例執行？

批

這可能是必要的或可取的，因為任務：

• 正在對大型單片數據（例如，二進制）進行處理。
• 依賴於數據集中多個記錄的上下文，因此必須將它們加載到單個作業中。
• 訂單很重要。

我覺得就像我經常看到默認選擇批處理一樣，因為“這是我們一直這樣做的方式”，但打破這種方法可能值得考慮。

Glue 是為批處理操作而構建的。 當前最長執行時間為 15 分鍾，最大 memory 為 10gb，Lambda 也能夠在單次執行中處理相當大的數據集。 在沒有具體工作負載的情況下，很難確定直接的成本比較。 在開發方面，我覺得 Lambda 在構建、測試和部署工具方面具有優勢。

事件

如果您的數據由一組記錄組成，您可能需要將它們解析並“流”到 Lambda 中。考慮如下流程：

• CSV 登陸 S3。
• S3 事件觸發 Lambda。
• Lambda讀取CSV並解析成離散事件，提交給另一個Lambda或者發布到SNS進行下游處理。 此 Lambda 的並發實例可用於加速攝取，其中每個實例負責 S3 object 的某些行。

這將所有邏輯和錯誤處理以及所需的資源推送到單個事件/記錄級別。 通常采用死信隊列等機制進行補救。 雖然給定容器的上下文在調用中持續存在 - 假設容器沒有空閑和拆除 - Lambda 通常應該被認為是無狀態的，這樣事件/記錄的處理被認為發生在它自己的 scope 中，而不是其他的在數據集中。

Answer 2

Lambda 的生命周期為十五分鍾。 它可用於觸發粘合作業作為基於事件的活動。 也就是說，例如，當文件進入 S3 時，我們可以有一個事件觸發器來運行粘合作業。 Glue 是一種用於所有數據處理的托管服務。

如果數據非常少，也許您可​​以在 lambda 中進行，但是由於某種原因，該過程超過了 15 分鍾，然后數據處理將失敗。

Answer 3

附加點：

根據此來源和Lambda 常見問題解答和膠水常見問題解答

Lambda 可以使用多種不同的語言（Node.js、Python、Go、Java 等），而 Glue 只能使用 Scala 或 Python 代碼執行作業。

Lambda 可以從其他服務（SQS、Kaftka、DynamoDB、Kinesis、CloudWatch 等）的觸發器執行代碼，而 Glue 可以由 lambda 事件、另一個 Glue 作業、手動或從計划觸發。

Lambda 對於較小的任務運行得更快，而 Glue 作業由於使用分布式處理而需要更長的時間來初始化。 話雖如此，Glue 利用其並行處理比 Lambda 更快地運行大型工作負載。

Lambda 看起來需要更多復雜性/代碼來集成到數據源（Redshift、RDS、S3、在 ECS 實例上運行的數據庫、DynamoDB 等），而 Glue 可以輕松地與這些集成。 然而，通過添加 Step Functions，多個 lambda 函數可以順序編寫和排序，因為降低了復雜性並提高了模塊化，其中每個函數都可以集成到 aws 服務（Redshift、RDS、S3、在 ECS 實例上運行的數據庫、DynamoDB 等）。 )

Glue 看起來有許多附加組件，例如 Data Catalog，它是一個用於查看數據的中央元數據存儲庫，一個靈活的調度程序，用於處理依賴項解析/作業監控/重試，AWS Glue DataBrew 用於使用可視化界面清理和規范化數據, AWS Glue Elastic Views 用於跨多個數據存儲組合和復制數據，AWS Glue Schema Registry 用於驗證流數據架構。

我還缺少其他示例，因此請隨時發表評論，我可以更新。