问雅典娜对红移的拼花

EN

以下是一些想法/建议

• 不要使用JDBC。
• 火花红移很好，但是一个复杂的解决方案。
• 你不需要用火花来转换为地板，也有选择使用蜂巢。请参阅https://docs.aws.amazon.com/athena/latest/ug/convert-to-columnar.html
• 雅典娜对地板使用时很棒，所以你根本不需要使用红移。
• 如果您想要使用红移，然后使用红移频谱设置一个视图针对您的拼花表，如果必要的话，在红移内的CTAS，以使数据，如果您需要的话。
• AWS Glue Crawler可以是一个伟大的方式来创建元数据所需的映射到雅典娜和红移光谱。

我提议的架构：

事件->将信息存储在S3中->蜂巢转换为拼花->直接在雅典娜使用

和/或

事件->将IT存储在S3中->蜂巢转换为拼板->使用红移谱直接在红移中使用

如果您使用正确的分区结构(s3文件夹)并对数据进行gzip，那么雅典娜/频谱的性能就可以足够好，而不需要转换到拼板的复杂性。这取决于您的用例(需要运行的数据量和查询类型)。

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

另一方面，Redshift是一个基于PostgreSQL的数据仓库，它比雅典娜更加复杂和灵活。数据分区在性能方面起着很大的作用，但是模式可以通过多种方式来设计，以适应您的用例。根据我的经验，将数据加载到Redshift的最佳方法是先将数据存储到S3，然后使用COPY COPY.html。它比JDBC快多个数量级，我发现JDBC只适合用少量数据进行测试。这也是将数据加载到Redshift中的方式。如果您不希望自己实现S3复制，则Firehose提供了一种替代方法。

这个问题很少有细节遗漏。如何管理数据管道中的增量插入。

如果您已经实现了缓慢更改的维度(SCD类型1或2)，则不能使用拼花文件来管理相同的维度。但在Redshift中，这是很容易管理的。