对日志分区以提升速度并降低成本

由于 Athena 按扫描的数据量收费，为查找某一天的事件而查询一整年的日志，会浪费金钱和时间。分区可以让 Athena 只读取相关的数据片段，从而使查询速度大幅提升、成本显著降低。这是 Athena 最重要的优化手段。

分区按照一个或多个列的值划分表中的数据，通常使用日期组成部分，并将其映射到 S3 前缀。CloudTrail 日志本来就按 region/year/month/day 的结构排列，因此按照这些字段分区可以匹配其物理结构，让 Athena 跳过不属于查询范围的文件夹。

当查询按照分区列进行筛选时，Athena 会执行分区裁剪：只读取匹配的前缀，忽略其余部分。使用正确分区查询某一天的数据时，只需扫描存储桶中极小的一部分。如果没有裁剪，同一个查询就会扫描所有数据，包括那些不可能用到的数据。

注册分区的一种方式是使用 ALTER TABLE ADD PARTITION，将分区值映射到其 S3 位置。这种方式可行，但对于每日产生的日志来说十分繁琐，因为您每天都要添加一个分区。它适合一次性的历史数据加载，却无法很好地扩展到持续产生的日志。

分区投影是现代且推荐的方法：您告诉 Athena 分区模式，例如某个日期范围，Athena 就会在查询时计算前缀，而无需将每个分区存储在目录中。对于持续增长的 CloudTrail 和流日志数据，这种方法可以避免不断维护，并让分区裁剪自动完成。

Glue 爬虫也可以按计划发现新分区，并将其添加到目录中。这能自动化不断变化的数据的分区管理；不过，对于可预测的按日期排列的数据布局，分区投影通常更简单，而且不会产生爬虫成本。

分区限制读取哪些文件；Parquet 等列式格式则限制在这些文件中读取哪些列。将两者结合起来——把日志转换为 Parquet，并按日期分区——可以将扫描的数据量降低几个数量级。许多团队会运行转换任务，为高容量日志存储经过查询优化的副本。

使用 GZIP 或 Snappy 等格式压缩日志数据，可以进一步减少扫描字节数和存储成本。Athena 会透明地读取压缩文件。结合分区和列式存储后，压缩完善了这三项技术，使大规模日志分析变得经济可行。

对于安全日志，应主要按日期分区，因为调查通常有明确的时间范围；对于组织跟踪，还可以考虑按账户或区域分区，以便快速定位某个账户。正确的分区键应当反映调查实际使用的筛选条件，从而最大限度地提高真实查询中的分区裁剪效果。

Athena 会报告每个查询的扫描数据量。关注这个指标可以判断分区是否有效：经过良好分区且限定时间范围的查询应扫描兆字节，而不是太字节。如果查询扫描的数据远超预期，通常说明您的筛选条件没有与分区列对齐。

优化方案包括：使用分区跳过无关数据，使用列式格式仅读取所需列，并使用压缩减少字节数。将这些方法应用于 CloudTrail 和流日志后，可以把原本缓慢且昂贵的扫描变成快速、低成本的调查，这正是大规模安全分析所需要的。

测试您对分区的了解。

分区按照列（通常是日期）划分表数据，使 Athena 能够执行分区裁剪，只扫描相关前缀，从而降低成本并节省时间。对于不断增长的日志，优先使用分区投影，而不是手动使用 ADD PARTITION 或依赖爬虫。将分区与列式 Parquet及压缩结合起来，可以大幅节省资源；安全日志应按日期和账户分区，并关注扫描数据量指标。