AWS Lambda是否比AWS Glue Job更受欢迎？

Question

在AWS Glue任务中，我们可以编写一些脚本，并通过任务执行该脚本。

在AWS Lambda中，我们也可以编写相同的脚本并执行与上述任务相同的逻辑。

因此，我的问题不是AWS Glue Job与AWS Lambda之间的区别是什么，而是我试图了解在两者都执行相同作业时，何时应优先选择AWS Glue Job？如果两者都执行相同的作业，那么理想情况下，我会盲目地选择使用AWS Lambda本身，对吗？

请尽量理解我的问题。

- john

---

胶水是为Spark而非Python设计的。 - Lamanus

@Lamanus Glue 还支持 Python/Pandas/PySpark。 - Mark B

Answer 1

额外的要点：

根据此来源，以及Lambda FAQ和Glue FAQ

Lambda可以使用多种不同的语言（例如Node.js、Python、Go、Java等），而Glue仅能使用Scala或Python代码执行作业。

Lambda可以通过其他服务的触发器（例如SQS、Kafka、DynamoDB、Kinesis、CloudWatch等）来执行代码，而Glue可以通过Lambda事件、另一个Glue作业、手动操作或计划表来触发。

针对小任务，Lambda运行速度更快，而Glue作业需要较长的初始化时间，因为它使用了分布式处理。尽管如此，Glue利用其并行处理比Lambda更快地运行大型工作负载。

Lambda看起来需要更多复杂的代码才能与数据源（Redshift、RDS、S3、在ECS实例上运行的数据库、DynamoDB等）集成，而Glue可以轻松地与这些数据源集成。但是，通过添加步骤函数，可以编写多个Lambda函数并按顺序排序以减少复杂性并提高模块化，其中每个函数都可以与AWS服务（Redshift、RDS、S3、在ECS实例上运行的数据库、DynamoDB等）集成。

Glue似乎有许多额外的组件，例如数据目录（Data Catalog），它是一个集中的元数据存储库，用于查看您的数据；一个灵活的调度程序，处理依赖关系/作业监控/重试；AWS Glue DataBrew可使用可视化界面清理和规范化数据；AWS Glue Elastic Views用于在多个数据存储中组合和复制数据；AWS Glue Schema Registry用于验证流式数据架构。

还有其他我遗漏的例子，请随意评论，我可以更新。

- deesolie

---

不错的列表。我会将 Step Functions 添加到 AWS 服务列表中，因为这可以将状态机功能引入使用 Lambda 进行数据处理。 - Bill Weiner

哇，我不知道这个集成存在。非常酷！如果客户的现有流程已经使用了 Lambda 函数，那么它似乎可以帮助减少复杂性并改善代码模块化。@BillWeiner，你会说这有助于弥合 Lambda 和 Glue 之间的差距吗？阅读附加文档和 ETL 功能方面的内容，看起来是这样的（https://aws.amazon.com/step-functions/）。 - deesolie

当然。步骤函数允许在无服务器工作流的整体执行中灵活性，并为Lambda启用成本效益的轮询过程。这是我实现ETL / ELT工作流程（数据移动编排）的首选方法。Glue虽然易于设置，但往往会出现错误的数据类型和不正确的数据格式期望，而且修改其功能也是一个泥潭。这是AWS经典的服务问题-轻松解决70％的问题，但如果您的问题落在30％中，则无法解决。使用Step Functions的Lambda易于理解和灵活，以满足所有需求。 - Bill Weiner

很高兴知道这个信息，Bill，谢谢你分享！所以Lambda可以与Redshift和其他数据库集成，只需要更多的设置，但与Glue的复杂性相比，这是值得的？ - deesolie

当你需要超出“正常”范围的任何东西时，使用Glue会出现复杂性。是的，我宁愿花费一些有限的前期时间来获得灵活、可扩展的解决方案，而不是从容易开始，最后不得不重置。 - Bill Weiner

Answer 2

Lambda的生命周期为15分钟。它可以用作触发Glue作业的事件驱动活动。也就是说，当文件着陆在S3中时，我们可以有一个事件触发器来运行Glue作业。Glue是用于所有数据处理的托管服务。

如果数据很少，也许可以在Lambda中处理，但如果某些原因使进程超过15分钟，则数据处理将失败。

- Yuva

Answer 3

这个问题的答案可能涉及到一些基础的设计决策。这项工作是做什么的？你正在处理什么样的数据？是否需要决定该任务应该采用批处理还是事件导向的范式？

批量处理： 由于以下原因，这可能是必要或有益的：

1. 处理大型单块数据（例如二进制数据）。 2. 依赖于数据集中多个记录的上下文，必须将它们加载到单个作业中。 3. 顺序很重要。

我觉得批处理方式通常被默认选择，因为“这就是我们一直以来的方式”，但从这种方法中脱离出来可能值得考虑。Glue适用于批量操作。Lambda目前最长执行时间为15分钟，最大内存为10GB，能够在一个单独的执行中处理相当大的数据集。很难针对工作负载进行直接成本比较。在开发方面，我认为Lambda在构建、测试和部署工具方面具有优势。

事件处理： 如果您的数据包含一组记录，则将它们解析并“流式传输”到Lambda可能会更好。考虑以下流程：

1. CSV数据落地到S3。 2. S3事件触发Lambda。 3. Lambda读取并解析CSV为离散事件，提交给另一个Lambda或发布到SNS进行下游处理。可以使用并发实例加快摄取速度，其中每个实例负责处理S3对象中的某些行。

这将把所有逻辑和错误处理以及所需资源推送到单个事件/记录级别。通常会使用死信队列等机制进行修复。虽然假定容器在调用之间保持活动状态且未关闭时，给定容器的上下文会跨越调用而持续存在，但应将Lambda通常视为无状态，从而将事件/记录的处理视为发生在其自己的作用域之外，而不是数据集中其他部分的作用域内。

- ormu5

---

很棒的分析，但是...I/O太贵了。我们之所以使用批处理，并不是因为一直都这样做，而是因为这可以限制I/O的数量。如果我有一百万个事件要处理，那么通过获取几个批次而不是调用一百万个Lambda实例，我肯定能更快、更便宜地完成任务。每个Lambda调用内部都是一个HTTP请求，这需要时间。然后呢？你把数据放到数据库里？一百万个并行插入操作会让你的数据库崩溃，但是管理良好的批处理将在没有任何问题的情况下快速处理。 - Kamil Janowski

很好的观点，Kamil。一些想法：

• HTTP：在SOA时代，这本身并不是负面的。松耦合带来了低效，但也带来了好处。
• “更快更便宜”：据我所见，线上对此存在不同意见。我可能会进行一些测试。如果我这样做，我会回报的。
• DB：这取决于数据领域。如果我的领域是“订单”，我可能不希望一个临时的Glue作业直接写入我的订单表。我可能会将ETL记录推送到SQS队列中，由指定服务/Lambda拥有的表插入它们（是的，可以选择批处理从队列中离线并进入DB）。

- ormu5

Answer 4

简单来说，不要仅仅把无服务器执行理解为在云上执行一段代码。它远不止于此。

以下是它的区别：

差异	AWS Lambda	AWS Glue
执行时间	15分钟	48小时
用途	事件驱动的无服务器计算	ETL（抽取、转换、加载）数据处理
编程语言	支持多种语言（例如Python、Node.js、Java）	Python或Scala（ETL脚本）
扩展性	根据需求自动扩展（调用次数）	ETL作业的水平扩展（Spark分布式处理）
分布式处理	不支持，需要自定义代码进行线程处理（不推荐）	内置Apache Spark支持
执行模型	短暂的、事件驱动的	长时间运行的批处理
成本模型	基于调用次数和持续时间	基于数据处理单元（DPUs）和持续时间
集成	与各种AWS服务和触发器集成	专为AWS数据源和数据存储设计
延迟	处理实时事件的低延迟	通常批处理的延迟较高
执行控制	通过事件或计划触发	按计划、事件驱动或按需执行
复杂性	更灵活，但需要显式编码	内置连接器简化了ETL任务，但需要额外设置自定义库

- Balaji

Answer 5

Lambda有一些限制，你可以在这里找到Lambda的限制这里，Glue也有限制这里，但它比Lambda更强大。你可以比较限制并决定何时使用Glue。

- Shalauddin Ahamad Shuza