Parquet 与 Athena VS Redshift

Question

我希望有人可以帮助我解决这个问题。我目前正在做一个数据管道项目，我目前的困境是是否将 parquet 与 Athena 一起使用或将其存储到 Redshift

2 场景： 首先，

EVENTS --> STORE IT IN S3 AS JSON.GZ --> USE SPARK(EMR) TO CONVERT TO PARQUET --> STORE PARQUET BACK INTO S3 --> ATHENA FOR QUERY --> VIZ

第二，

EVENTS --> STORE IT IN S3 --> USE SPARK(EMR) TO STORE DATA INTO REDSHIFT

这种情况的问题：

1. 使用 Redshift 的 Spark JDBC 速度很慢
2. 数据砖的 Spark-Redshift 存储库构建失败，并于 2 年前更新

我找不到关于哪种方法更好的有用信息。我应该使用 Redshift 还是 parquet 足够好？

如果有人能告诉我是否还有其他方法可以将 Spark 与 Redshift 连接起来，那就太好了，因为我在网上看到的只有 2 个解决方案 - JDBC 和 Spark-Reshift(Databricks)

附：定价模型对我来说不是一个问题，而且我正在处理数百万个事件数据。

Answer 1

这里有一些想法/建议

• 不要使用 JDBC。
• Spark-Redshift 工作正常，但解决方案复杂。
• 您不必使用 spark 转换为 parquet，也可以选择使用 hive。 看 https://docs.aws.amazon.com/athena/latest/ug/convert-to-columnar.html
• Athena 非常适合用于镶木地板，因此您无需使用 完全红移
• 如果要使用 Redshift，请使用 Redshift 光谱设置 查看您的镶木地板表，然后在必要时查看 CTAS 如果需要，Redshift 可将数据引入。
• AWS Glue Crawler 是创建所需元数据的好方法 将镶木地板映射到 Athena 和 Redshift Spectrum。

我提议的架构：

事件 --> 将其存储在 S3 中 --> 用于转换为镶木地板的 HIVE --> 直接在 Athena 中使用

和/或

事件 --> 将其存储在 S3 中 --> HIVE 以转换为镶木地板 --> 使用 Redshift Spectrum 直接在 Redshift 中使用

您可能不需要转换为 parquet，如果您使用正确的分区结构（s3 文件夹）并 gzip 数据然后 Athena/spectrum 那么性能可以足够好，而无需转换为 parquet 的复杂性。这取决于您的用例（您需要运行的数据量和查询类型）。

Answer 2

使用哪一个取决于您的数据和访问模式。 Athena 直接使用 S3 密钥结构来限制要扫描的数据量。假设您在事件中有事件类型和时间。 S3 密钥可以是例如yyyy/MM/dd/type/* 或 type/yyyy/MM/dd/*。前一种键结构允许您按日期或日期和类型限制要扫描的数据量，但不能单独按类型。如果您只想按类型搜索 x 但不知道日期，则需要完整的存储桶扫描。后一个键模式将是相反的。如果您主要需要以一种方式（例如按时间）访问数据，Athena 可能是一个不错的选择。

另一方面，Redshift 是一个基于 PostgreSQL 的数据仓库，它比 Athena 更加复杂和灵活。数据分区在性能方面起着重要作用，但可以通过多种方式设计模式以适应您的用例。根据我的经验，将数据加载到 Redshift 的最佳方法是首先将其存储到 S3，然后使用 COPY https://docs.aws.amazon.com/redshift/latest/dg/r_COPY.html 。它比 JDBC 快多个数量级，我发现它只适用于使用少量数据进行测试。这也是 Kinesis Firehose 将数据加载到 Redshift 的方式。如果您不想自己实现 S3 复制，Firehose 提供了替代方案。

Answer 3

问题中缺少一些细节。您将如何管理数据管道中的增量 upsert。

如果您实施了渐变维度（SCD 类型 1 或 2），则无法使用 parquet 文件进行管理。但这在 Redshift 中很容易管理。