S4 Scan
Athena scan-cost reducer
通过将 S3 data-lake Parquet 重新优化为查询实际读取的布局，将 AWS Athena 和 Redshift Spectrum scan bill 降低 30–70% — partition 和 row-group pruning、dictionary encoding、zstd、小文件 compaction — 通过安全的 shadow-then-swap 应用，绝不改变查询结果。
S4 Scan 从 Athena query history 学习哪些列被读取、哪些 predicates 过滤表，然后将底层 S3 Parquet 重写为这些查询需要的物理布局：hot columns first；按过滤列排序，使 row-group statistics 可以 prune；对 low-cardinality columns 使用 dictionary encoding；将文件 compact 到高效大小；并用 zstd 压缩。Athena 和 Redshift Spectrum 按从 S3 扫描的 TB 计费，因此更小、更容易 prune 的布局会带来直接且持续的账单降低。安全性是产品核心 — 绝不会覆盖你的 source。
面临挑战
Athena 和 Redshift Spectrum 根据实际从 S3 读取的字节数计费（默认 $5/TB，因区域而异）。如果您的 Parquet 物理布局与查询的访问模式不匹配，则每次查询扫描的 S3 数据量会远超其返回的数据量 — 而您每月都需要为这一差距买单。由于账单是扫描字节数的函数，因此布局本身决定了您的成本。
工作原理
- 1
从查询历史记录中学习
它读取您的 Glue 目录和 Athena 查询历史记录（工作组指标、CloudTrail），以了解每个表实际读取的列以及用于过滤它的谓词。
- 2
写入影子并验证
它将优化后的 Parquet 写入单独的影子位置，并验证查询结果是否完全一致，精确到值、NULL、decimal 精度和时间戳时区。
- 3
通过 Glue 进行切换，支持回滚
只有在验证通过后，它才会重新指向 Glue 表的位置 — 这是目录指针的移动，而非数据移动 — 可通过单个回滚命令撤销。
产品亮点
设计上安全：优化后的数据写入 shadow 位置，验证查询结果完全一致（值、NULL、小数 scale、timestamp tz）后，再通过 Glue catalog swap。支持一条命令回滚。源数据从不 in-place 修改。
提交前先看到节省额：dry-run 会基于真实表预测每月美元降幅，并如实归因到 pruning、dictionary + zstd 和小文件合并。
无 lock-in，无需看护：输出为标准 Athena 可读 Parquet，AMI 按 EventBridge schedule 重新优化，让节省自动累积。
包含内容
- 查询历史分析：从历史查询中分析出热列、高频谓词以及分区/排序键候选，并生成优化计划。
- 分区和行组剪枝：根据谓词键重新分区以跳过整个文件，并对过滤列进行排序，以便利用 min/max 统计信息跳过不匹配的行组。
- 字典/RLE 编码 + zstd：对低基数列进行字典编码，并使用 Athena 可读的标准 zstd 进行重新压缩，以减少投影读取的字节数。
- 小文件合并：将许多微小对象合并为少数大小合适的文件，以提高 I/O 效率并改善统计信息。
- 影子 → 验证 → 切换与单命令回滚：源数据绝不就地修改，切换仅是 Glue 指针的移动。
- Dry-run 费用预测：在不写入任何数据的情况下，报告当前与优化后的扫描字节数以及月度费用差额，真实地将节省归因于分区剪枝 / 行组剪枝 / 字典+zstd / 文件合并。
- 通过 EventBridge 调度の再优化，输出为标准的 Athena 可读 Parquet — 无锁定。
适用场景
希望在不重写任何 SQL 的情况下降低高昂的 Athena / Redshift Spectrum 扫描费用。
宽表场景：查询仅读取少数列并根据少数谓词过滤，却仍需扫描整个文件。
数据湖被大量微小的 Parquet 对象碎片化，降低了 I/O 效率并损害了统计信息。
不断增长的数据集，可通过基于 EventBridge 调度的定期再优化受益。
常见问题
这会损坏我的数据或改变我的查询结果吗？
源数据绝不会就地修改。优化后的数据将被写入一个独立的影子位置，并在验证结果完全一致 — 包括值、NULL、decimal 精度、时间戳时区和嵌套类型 — 之后，才移动 Glue 指针。如果验证失败，它不会进行切换，而是丢弃影子位置并保持源数据不受影响。切换后，只需运行单个命令即可恢复原始位置。
我会被专有格式锁定吗？
不会。输出仅为标准的 Athena 可读 Parquet（标准 zstd、字典/RLE），不使用专有 codec。您可以随时回滚，优化后的数据也可以使用普通的 Athena 工具正常读取。
S4 Scan 如何知道要优化什么？
它会从您的 Athena 查询历史中学习 — 统计哪些列被读取以及哪些谓词过滤了您的表 — 并推导出推荐的列顺序、分区键和排序键。这基于真实的访问模式，而非凭空猜测。
我能在实际执行前看到可以节省多少费用吗？
是的。dry-run 会在不写入任何数据的情况下报告当前与优化后的扫描字节数以及月度费用差额，并将节省 of 费用真实地归因于分区/行组剪枝、字典+zstd 以及文件合并。宣传的 30–70% 是一个取决于您现有布局偏差程度的范围 — 并非保证值 — 因此请先在您自己的表上运行 dry-run。
它在哪里运行？我的数据会离开我的账户吗？
它作为 AMI 在您自己的 AWS 账户和 VPC 内运行，仅访问您的 S3、Glue 和 Athena — 您的数据绝不会离开。它在最小权限的 IAM 角色下，基于 EventBridge 调度实现无干预自动运行。
计费模式
按小时计费的软件费用 + EC2（t3 / m5 class），也提供按处理 GB 付费的 offer。提供年度选项。
