Amazon EMR 与 Amazon Redshift

Question

对于大多数用例，可以使用 Amazon EMR 对流数据或有界数据（例如来自 Amazon S3）进行 Spark 转换，然后可以使用转换后的数据再次将数据写入 S3。

还可以在 Amazon Redshift 中使用将 S3 中的不同数据加载到不同的 Redshift 表，然后将不同 Redshift 表中的数据加载到最终表中来实现转换。 （现在有了 Redshift 光谱，我们也可以直接从 S3 中选择和转换数据。）

话虽如此，我发现转换可以在 EMR 和 Redshift 中完成，Redshift 加载和转换可以用更少的开发时间完成。

那么，EMR 是否应该用于主要涉及流式/无限数据的用例？什么其他用例更适合 EMR（我知道 Spark 也提供其他核心、sql、ml 库），但只是为了实现转换（涉及连接/减速器），我没有看到除此之外的用例在 EMR 中进行流式传输，此时在 Redshift 中也可以实现转换。

请提供使用 EMR 转换与 Redshift 转换的用例。

Answer 1

首先，我更喜欢使用 Redshift 进行转换：

• 开发更简单，SQL 而非 Spark
• 维护/监控更容易
• 假设您可以在“非高峰期”运行，基础设施成本会更低 次。

有时 EMR 是更好的选择，我会在以下情况下考虑：

• 当您希望在 S3 上同时拥有原始数据和转换后的数据时，例如一种 “数据湖”战略
• 需要复杂的转换。有些转变只是 无法使用 Redshift，例如当
  • 管理复杂的大型 json 列
  • 动态转换数据（属性数量可变）
  • 需要第三方库
• 数据量太大，需要更大的红移集群来处理转换。

除了 Redshift 和 EMR 之外，还有其他其他选项，这些也应予以考虑。 例如

• 标准 python 或其他脚本语言：
  • 创建动态转换sql，可以在redshift中运行
  • 从 csv 到 parquet 或类似的处理
  • 调度（例如气流）
• AWS 雅典娜
  • 可与 s3（例如 parquet）输入和输出一起使用
  • 使用 Presto 语法使用 SQL（因此在开发时间上有一些优势），在某些情况下它比 Redshift SQL 更强大
  • 可以带来显着的成本效益，因为不需要永久性基础设施成本，按使用付费。

还应考虑 AWS Batch 和 AWS lambda。