2

对于大多数用例，可以使用 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 转换的用例。

4

1 回答 1

9

在第一种情况下，我更喜欢使用 Redshift 进行转换：

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

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

  • 当您希望在 S3 上同时拥有原始数据和转换后的数据时，例如“数据湖”策略
  • 需要复杂的转换。使用 Redshift 无法进行某些转换，例如何时
    • 管理复杂的大型 json 列
    • 动态旋转数据（可变数量的属性）
    • 需要第三方库
  • 数据量如此之大，以至于需要更大的红移集群来处理转换。

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

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

还应考虑 AWS Batch 和 AWS lambda。

于 2019-07-24T06:13:10.413 回答