Iceberg vs Parquet+分区投影：AWS Glue实测谁更快

搞数据的人迟早会碰上一道题：Iceberg和Parquet+分区投影，到底选哪个？我在AWS Glue上跑了几个月数据接入，终于搭了个测试环境，用同一股数据流、同一批Athena查询，把两边拉到擂台上打了一架。

测试架构很简单：Python脚本模拟股票tick数据，Kinesis Data Stream做入口，然后分叉——两条Firehose，一条写Iceberg，一条写Parquet+分区投影；两个Glue作业，一个批处理算OHLC（1分钟和5分钟线），一个流式作业用滑动窗口做z-score异常检测。Athena同时查两边，比的就是同等查询条件下的表现差异。

数据格式直接用的AWS官方Firehose demo那套：ticker_symbol、sector、price、change、event_timestamp。但我把Kinesis Data Generator换成了boto3写的Python producer，这样能控制测试场景——stable（稳定基线）、trend（趋势）、spike（人为注入价格 spike）、mixed（混合）。spike专门用来验证z-score能不能抓到异常，stable和trend则用来排除误报。

核心发现集中在两个地方。一是读取模式的选择：Parquet这边用了分区投影，而不是传统的Crawler或MSCK REPAIR TABLE注册分区。分区投影的好处是免维护，但代价是读取路径的设计——我写了三种LOAD_DATA_MODE来应对不同场景，从直接读S3到利用下推谓词，性能差距能到5倍。二是代码组织：一个3行的wrapper让TDD成为可能，这在Glue这种"写脚本-上传-运行-报错"的循环里太重要了。

这个项目没有"踩坑"的戏剧性，因为那些坑我早就踩过了。分享的是基于深入理解后的 deliberate choices——哪些Firehose/Glue功能该用、按什么标准选、怎么让代码可测试，还有几个承诺过自己一定要塞进去的Docker和Terraform技巧。