datainfra前沿动态 · Vol.41

DuckDB v2.0 异步 I/O S3 读取最高 20× 提速；AWS EMR Advanced Managed Scaling 滑块式弹性伸缩；AWS EMR Spark KMS 解密成本三招优化

本期聚焦 DataInfra 三条性能-成本精细化管理动态：DuckDB v2.0 引入异步 I/O 架构，S3 上 Parquet 查询 3× 提速、CSV 20× 提速；AWS EMR Advanced Managed Scaling 提供从成本优先到性能优先的 5 档伸缩策略；AWS 发布 EMR Spark 场景 KMS 解密成本优化三招实战指南。

DataInfra DuckDB 异步I/O S3 Parquet CSV 数据湖 OLAP Amazon EMR Managed Scaling 弹性伸缩 Apache Spark AWS KMS 加密 成本优化 Iceberg Glue Data Catalog 分区索引

本期追踪到三条 DataInfra 动态，共同指向一个正在深化的趋势：数据基础设施的性能优化正在从”单点突破”走向”全栈精细化管理”。2026 年 7 月 31 日，DuckDB 核心开发者 Pedro Holanda 发布了一篇深度技术文章，详细披露了 DuckDB v2.0 的异步 I/O 架构——在 S3 远程存储场景下，Parquet 查询提速 3×、CSV 查询提速 20×，64 核机器上 CPU 利用率从 ~10% 跃升至 ~75%，网络带宽近乎全饱和。这标志着 DuckDB 从”本地优先”的分析引擎正式进化为”远程存储原生”的数据湖查询引擎。同日，AWS 发布 EMR Advanced Managed Scaling——通过一个从 1 到 100 的 UtilizationPerformanceIndex 滑块，让用户从”成本优先”到”性能优先”精细控制集群弹性伸缩行为。前一天（7 月 30 日），AWS 还发布了一篇实战指南，系统介绍了 EMR Spark 处理 S3 加密数据时降低 KMS 解密成本的三种技术路径。三条动态分别从查询引擎架构层、资源调度层和成本治理层，推进了 DataInfra 的”性能-成本精细化管理”能力。

DuckDB v2.0 异步 I/O 架构深度揭秘：S3 上 Parquet 3× 提速，CSV 20× 提速，64 核利用率从 10% 跃升至 75%

事件概述

2026 年 7 月 31 日，DuckDB 核心开发者 Pedro Holanda 发布了一篇名为《Asynchronous I/O in DuckDB: Work, Thread, Work》的深度技术文章，详细介绍了 DuckDB v2.0 中引入的异步 I/O 架构。该功能计划在 2026 年秋季发布的 DuckDB v2.0 中默认启用，目前已可在 v2.0.0-dev 预览版本中试用。

这是 DuckDB 从”本地优先”分析引擎向”远程存储原生”查询引擎演进的关键一步。随着 DuckDB 的使用场景从单机本地文件扩展到数据湖（DuckLake）和服务器模式（Quack 协议），数据越来越多地存储在 S3 等远程存储上，原有的同步 I/O 模型成为严重性能瓶颈。

技术解析

  • 双线程池架构：DuckDB 实现了两个独立的线程池——REGULAR（工作线程池，默认每 CPU 线程一个）和 ASYNC（异步线程池，4× 系统线程数，上限 256）。核心洞察是：远程 I/O 时异步线程几乎全部时间都在等待 HTTP 响应等阻塞操作，CPU 利用率极低，因此需要远超 CPU 线程数的 I/O 线程来维持足够多的并发请求。工作线程在空闲时也可执行 I/O 任务，但不会被阻塞等待——I/O 完成后异步恢复处理。

  • 预读队列（Read-Ahead Queue）：异步 I/O 的核心策略不是”按需读取”而是”提前调度读取”。Parquet 的一个任务 = 一个文件的一个行组（Row Group），CSV 的一个任务 = 文件内的一个扫描边界。工作线程在寻找扫描任务时会先填充队列，异步线程独立执行获取子任务且可并发运行。任务 I/O 完成后工作线程认领并开始解码，同时立即释放队列槽位以允许生成替换任务，形成”预读→完成→认领→释放→新预读”的流水线。

  • 内存治理机制：引入 read_ahead_depth 配置选项（-1 默认无限，0 关闭预读，N>0 最多预读 N 个任务）。预读预算与临时内存管理器协商——当内存压力大时，队列可能只允许一个任务，扫描行为接近同步扫描；内存密集型操作完成后，管理器释放预算，队列重新填充。在 8 GB 严格内存限制的并发查询测试中，异步 I/O 仍实现了 35.9s→24.2s 的提速，RSS 峰值仅从 10.4 GB 增至 11.5 GB。

  • Parquet 基准测试（EC2 r7i.16xlarge，TPC-H Q6 SF100，S3 同区域）：

    • 单文件（~22 GB，4,880 个行组）：v1.5.5 同步 = 8.23s → v2.0.0-dev 异步 = 2.84s（3×），调优后 = 2.23s（3.7×）
    • 小文件（976 个文件，每文件 5 个行组，约 22 MB/文件）：9.34s → 2.95s（3.2×）
    • 网络吞吐量：v1.5.5 维持约 5 Gbit/s，v2.0.0-dev 多次接近 25 Gbit/s 上限，调优后近乎全饱和
    • 本地冷盘：1.32s → 0.88s（1.5×），热盘差异可忽略
    • 行组大小敏感性：行组数过少导致并行度不足——1 个行组（仅 2 个 S3 流）运行 25.26s，306 个行组（~70 MB/行组）最快 2.11s

  • CSV 基准测试：80.89 GB CSV 文件，v1.5.5 同步 = 877.6s → v2.0.0-dev 异步 = 45.3s（20×）。CSV 为行导向格式，扫描传输更多数据并执行固定大小缓冲区读取，并发远程读取的价值特别大。

  • 并发查询测试（TPC-H Q1/6/9/18 并发）：v1.5.5 同步下 64 核机器平均仅使用约 6 个核心（~90% 空闲等待同步 S3 读取），v2.0.0-dev 异步下平均使用 48 个核心，峰值达到全部 64 核，网络近乎全饱和。默认内存限制下总运行时间从 35.8s 降至 15.6s（2.3×），8 GB 内存限制下仍达 24.2s（1.5×）。

行业影响

DuckDB 异步 I/O 的引入不仅仅是一个性能优化——它标志着 DuckDB 在架构层面对”数据湖原生查询”的正式定位。当 DuckDB 可以像查询本地文件一样高效查询 S3 上的 Parquet/CSV 数据时，它与 Trino、Spark 等传统分布式查询引擎的竞争格局将发生实质性变化——DuckDB 的”单机高性能 + 远程存储原生”模式可能在某些中型数据湖场景中取代”分布式计算集群 + 对象存储”的传统架构。

另一个值得关注的维度是行组大小对异步 I/O 性能的显著影响。文章显示 306 个行组达到最优性能，而 4 个行组（每行组 ~3.2 GB）性能仅为最优的 3.5 倍差。这对数据湖的文件组织实践提出了一个明确的优化方向：适当降低行组大小以增加并行度（理想情况行组数至少等于系统线程数），与传统”尽可能大的行组以获得更好压缩”的建议形成了有意义的张力。

更宏观地看，DuckDB 异步 I/O 与上周 Vol.39-40 密集报道的 Agent-First DataInfra 叙事存在有趣的联系：Agent 在执行数据消费任务时，可能需要频繁地对远程对象存储上的小数据集做临时查询。DuckDB 的异步 I/O 让这种”嵌入式、零部署、远程原生”的查询模式成为可能——Agent 不需要等待 EMR 集群启动，不需要写 SQL 方言适配，直接嵌入 DuckDB 实例，对 S3 数据做亚秒到秒级的分析查询。

相关链接

AWS EMR Advanced Managed Scaling：从成本优先到性能优先的五档滑块式弹性伸缩

事件概述

2026 年 7 月 31 日，AWS 发布博文《Optimizing costs and performance with Advanced Managed Scaling on Amazon EMR on EC2》，正式介绍了 EMR Advanced Managed Scaling 能力。该功能在现有 Managed Scaling（2020 年推出）的基础之上，引入了一个从 1 到 100 的 UtilizationPerformanceIndex 滑块，让用户可以直接表达”我更关心成本还是性能”的偏好，EMR 内部自动将这一意图转化为具体的伸缩策略。

支持 5 个离散值：1（Utilization Optimized，成本优先）、25、50（Balanced，推荐起点）、75、100（Performance Optimized，性能优先）。通过 put-managed-scaling-policy API 即可配置，无需自定义伸缩规则。

技术解析

  • 伸缩行为差异（3 TB TPC-DS 测试，50 节点上限）：

    • Utilization Optimized [1]：峰值 50 节点，Job 耗时 14 分钟（840s），成本最低。扩缩容均保守，Job 完成后约 5 分钟释放节点。适合有规律性波峰且空闲时间极短的连续作业序列——节点不会频繁创建/销毁，下一批 Job 可直接复用。
    • Balanced [50]：峰值 48 节点请求/50 节点运行，Job 耗时 13 分钟（780s），成本适中。4 分钟内优雅释放所有节点。适合运行时间稳定或混合长短 Stage 的稳态工作负载。
    • Performance Optimized [100]：Job 启动 3 分钟内即请求满 50 节点，Job 耗时 11 分钟（660s），成本最高。约 7 分钟释放节点。适合 SLA 敏感、对延迟零容忍的工作负载。

  • 与原有 Managed Scaling 的关系：Advanced Scaling 是在 EMR Managed Scaling 基础上的增强，保留了其核心优势——shuffle 感知（不会在 shuffle 期间缩容导致数据丢失）、Application Master 保护（不会误杀 YARN Application Master 导致 Job 失败）。新增的只是”你告诉我偏好的方向，我自动调整激进/保守程度”这一层抽象。

  • 与自定义 Auto Scaling 规则的对比：传统 Auto Scaling 需要用户手动编写 CloudWatch 指标 + 伸缩策略的规则组合，存在缩容时丢失 shuffle 数据、误终止 Application Master、响应慢等风险。Advanced Scaling 将所有策略逻辑内置在 EMR 服务侧，用户只需选择一个数字即可。

  • API 层面设计：用户在集群创建时或运行中通过 put-managed-scaling-policy API、指定 ScalingStrategy: "ADVANCED" 和 UtilizationPerformanceIndex: N 即可启用。五个离散值（1/25/50/75/100）而非连续值的设计暗示了底层可能对应五种不同的预设算法策略，而非简单线性插值。

行业影响

EMR Advanced Scaling 的发布反映了云上大数据产品的一个重要趋势：从”专家调参”到”意图驱动”的范式转换。过去，优化 EMR 集群的成本-性能平衡需要 Spark/Hadoop 运维专家深度理解 YARN 调度器、Spot 实例策略、shuffle 行为和 CloudWatch 指标——这不是大多数数据工程师的核心技能。Advanced Scaling 将这一复杂性封装为”你只需要告诉我一个数字”的体验，本质上是将运维专家的领域知识固化为服务端的自动化策略引擎。

从竞争格局看，这一功能直接对标了 Databricks 的 Autoscaling（基于 Spark 内部的 Executor 级别伸缩）和 Google Cloud Dataproc 的 Autoscaling（基于 YARN 指标）。EMR 的优势在于其 shuffle 感知和 Application Master 保护机制——这是 AWS 自研 Managed Scaling 四年积累的工程经验。但 Databricks 的自动伸缩直接集成在 Spark 内部，粒度更细（Executor 级 vs EMR 的 Instance 级），这是两种架构哲学的选择。

相关链接

AWS EMR Spark KMS 解密成本三招优化：文件聚合、格式选择和分区索引

事件概述

2026 年 7 月 30 日，AWS 大数据博客发布了一篇由 Navaneedha Krishnan Jagathesan 撰写的实战指南《Lowering AWS KMS decrypt API costs in EMR Spark jobs》。文章针对一个日益突出的成本痛点：当 EMR Spark 处理 S3 上 KMS 加密的大量小文件时，每个 S3 对象的读取都会触发一次 kms:Decrypt API 调用，在大规模场景下累积为显著且往往意料之外的成本。

文章指出，S3 Bucket Keys 是降低 KMS 调用成本的最有效方法，但部分组织因合规审计需求（如 CloudTrail 中必须保持逐对象级别的加解密审计日志）而无法使用 Bucket Keys。针对这类场景，文章系统介绍了三种可独立或组合使用的优化技巧。

技术解析

  • 数据聚合（Data Aggregation）：将小文件合并为大文件是降低 KMS 调用数最直接的方法。文章给出了一套完整的对比验证流程：先用 spark.read.format("csv").load() 建立基线 KMS 调用数（通过 CloudTrail 查询确认），再用 data.coalesce(10).write.parquet() 将数据聚合并写回 S3，最后重跑作业验证 CloudTrail 中调用数的下降。核心原理简单明了：N 个小文件 = N 次 Decrypt 调用，M 个大文件（M << N）= M 次 Decrypt 调用。

  • 文件格式和压缩优化：

    • 列式格式（Parquet/ORC）：Spark 读取列式格式时可以只读需要的列，减少 I/O 量和相应的解密调用。CSV 全表扫描 = 全量解密开销，Parquet 投影查询 = 仅读取所选列的文件块。
    • Iceberg 表格式：更重要的优化来自 Iceberg 的自动文件布局管理——包括文件合并、分区演化和元数据层面的文件跳过。文章给出了完整的 EMR + PySpark + Iceberg 代码示例（iceberg-spark-runtime-3.4_2.12:1.4.2），展示如何将 CSV 数据写入 Iceberg 表并受益于其文件管理能力。
    • 压缩（Snappy/ZSTD）：虽然文章使用 Snappy 做示例，但指出 ZSTD 是 Iceberg 的推荐默认压缩编码，压缩比更高，间接减少需要读取和解密的数据总量。

  • Glue Data Catalog 分区索引：

    • 问题：没有分区索引时，Spark 查询分区表（如 WHERE year='2000' AND month='04'）→ Glue 调用 GetPartitions 返回所有分区→ Spark 扫描所有分区中的 S3 对象→ 每个对象触发一次 KMS Decrypt。即使查询只需要一个月的数据，也会产生所有分区的解密成本。
    • 优化：在 Glue Data Catalog 中为 year 和 month 列创建分区索引后，Glue 在服务端完成分区过滤，只返回匹配的分区→ Spark 只扫描匹配分区的对象→ KMS 解密调用数大幅下降。文章给出了完整的前后对比 CloudTrail 截图流程。

  • 成本优化的层次结构：文章明确给出了推荐的优先级——S3 Bucket Keys（最有效）> 上述三种优化技巧（补充优化）。当可使用 Bucket Keys 时优先启用；当因审计要求不能使用时，上述技巧提供了一条可行的替代路径。

行业影响

这篇博客的价值不在于技术本身有多新颖——文件合并、列式格式、分区索引都是数据工程领域的基础实践——而在于它将一个隐性成本问题显性化并系统化了。大多数数据工程师在设计和维护 Spark 作业时，关注点集中在计算成本（EC2 实例/EMR 集群费用）和存储成本（S3 存储费），很少有人能在作业设计阶段就意识到”每一次 KMS Decrypt 调用都在产生成本”。

从更广的视角看，这反映了云上数据基础设施的”成本可观测性”正在从粗粒度向细粒度演进。过去只要看 EMR 集群的月度账单，现在需要关心每个 API 调用的累积效应。这种趋势对 DataInfra 工具提出了新的要求：成本管理需要内建到作业设计阶段，而不是事后通过账单发现。一个理想的数据平台应该在作业提交前就能预估不同文件组织策略下的 KMS 调用成本差异——类似 Spark 的 AQE（Adaptive Query Execution）在运行时优化查询计划，未来可能需要”Adaptive Cost Optimization”在提交时优化成本计划。

相关链接

编者评

本期三条动态看似分散——一条关于单机分析引擎的 I/O 架构重构，一条关于集群弹性伸缩的策略抽象，一条关于加密 API 成本治理——但它们共同揭示了一个更深层的行业趋势：DataInfra 正在进入”性能-成本精细化管理”的第二阶段。

第一阶段（过去 5-10 年），数据基础设施的核心叙事是”从无到有”——我们有 HDFS 了，我们有 S3 了，我们有 Spark 了，我们有 Iceberg 了。这一阶段的核心问题是”能不能做”。第二阶段（当前），核心叙事转向”做得更好更省”——64 核机器不能让 90% 的 CPU 浪费在同步 I/O 等待上，弹性伸缩不能总是”要么太激进要么太保守”，加密合规的代价必须在设计阶段就被理解和控制。这一阶段的核心问题是”怎样更高效、更经济地做”。

将本期三条动态与上周追踪的 Google Cloud Agent-First DataInfra 叙事放在一起看，会发现两个对立的趋势在并行推进：一方面，Agent 成为数据的新消费者，要求基础设施在功能层做大规模新增（联邦查询、自然语言接口、语义层）。另一方面，现有工作负载的成本和效率压力要求基础设施在性能层做精细化存量优化（异步 I/O、伸缩策略、API 成本治理）。功能扩容和效率优化从来不是零和博弈——但 2026 年下半年的 DataInfra 领域中，两者的并行加速正在创造出一种独特的行业张力：既要为 AI Agent 这种”未来工作负载”搭建全新的数据通路，又要让已有的 Spark 作业跑得又快又省。能在两条战线上同时推动的产品和团队，将定义下一个阶段的 DataInfra 格局。