企业官网建设流程全解析

先聊一个我印象很深的场景：你自己搭了一套 Spark 集群，把 Hive 作业迁上去，SQL 写得规规矩矩，Parquet 也做了分区，Executor 从 2 个加到 20 个，跑批时间却只是从一小时降到四十分钟，再往下调就很难动了。再一看监控，CPU 平均占用不到 40%，堆内存倒是蹭蹭往上涨，Full GC 隔几分钟来一次。这时候你大概会意识到，问题不在资源不够，而在 Spark 的执行引擎把资源花在了不该花的地方。后来我开始研究 Spark native 向量化组件，把 Apache Arrow 生态里的 DataFusion 和 Comet 接了进来，才算真正找到了压榨集群性能的第三条路。这篇文章就把我对 Comet 的理解、部署经验、调参心得和踩过的坑一次性整理出来，给同样想给 Spark 提速的人一个可参考的路径。

1. Spark 执行慢的根子：JVM 行处理与序列化

1.1 一次处理一行的“行式迭代”到底输在哪

Spark 默认的执行方式，本质上还是逐行迭代。虽然 Spark 2.x 之后有了 WholeStageCodeGen（全阶段代码生成），会根据 SQL 树动态生成一段 Java 代码，把多个算子糅在一起，减少虚函数调用和中间对象的创建，但生成的代码核心仍然是一个while循环，一条 InternalRow 一条 InternalRow 地往下游吐。

这里的问题不是“循环”本身，而是 JVM 对象带来的附加消耗。每一条 InternalRow 落在一个 Java 对象里，对象头就有几十字节的开销；字段多的时候，还要处理嵌套对象、数组引用、Null 位图。数据量一大，这些开销会被无限放大。更麻烦的是，逐行处理天然对 CPU Cache 不友好。现代 CPU 从内存读数据是按 Cache Line（一般是 64 字节）来的，你一次读一行，每行可能只用了十几个字节，剩下的 48 字节就是浪费。内存带宽就这么多，大量带宽被“读了个寂寞”给吃掉了。

我用一个生活化的类比解释：逐行处理相当于你去仓库搬货，每次只搬一箱；向量化执行则是用叉车一次托起一整层托盘。托盘上的货不是按“箱”排列的，而是按“位置”排列的——所有第一行抽出来放一个区，所有第二行放另一个区。CPU 处理时，从这个区连续读几百上千个值，一次性批量运算，Cache 命中率高，SIMD 指令还能一条指令同时算多个数。这就是向量化的核心思路。

1.2 序列化才是 Spark 大规模 SQL 的真正隐形杀手

我自己做性能分析的时候发现，很多 Spark SQL 作业的瓶颈并不在计算本身，而在 Shuffle。Spark 的 Shuffle 过程，上游要写数据到磁盘，下游要拉取数据再合并。默认情况下，每个分区、每条 InternalRow 都要经过 Java 序列化器过一遍。序列化本身消耗 CPU，序列化后的数据体积可能比原始数据还要大，写磁盘和走网络传输的成本也随之上涨。

Shuffle 期间还有个非常容易被忽略的问题：反序列化后的对象会大量堆积在堆内存里。如果你跑的是 join 或 group by 这种重 Shuffle 的作业，观察 Executor 的堆内存曲线，通常会在 Shuffle 阶段看到一条陡峭的上升线，紧接着就是 GC 抖动。GC 一频繁，CPU 被垃圾回收占掉一大块，业务线程就跟着卡顿。这个问题在数据量大了以后几乎无解，因为你不管怎么调 Spark 参数，都绕不开“JVM 堆里塞满对象”这件事。

所以 Spark 社区这两年开始讨论一个更激进的思路：干脆不要用 JVM 跑执行引擎了，把执行计划交给一个原生的、用 Rust 或 C++ 写的引擎，数据也以原生列式格式放在堆外内存里。这个方向里，最典型也最值得关注的一个开源项目，就是 Apache Arrow 生态里的 DataFusion Comet。

2. Comet 是什么：用 DataFusion 给 Spark 换一个执行引擎

2.1 项目背景与定位

Comet 最初是 Apple 内部发起的项目，目标是给 Spark 提供一个“运行时加速器”，后来贡献给了 Apache Arrow 社区。它做的事情很明确：在不改变 Spark SQL 接口、不重写应用代码的前提下，把 Spark 的物理执行计划嫁接给 Apache DataFusion——一个用 Rust 实现的、原生向量化的执行引擎。

这里要特别强调，Comet 不是要替代 Spark，而是作为 Spark 执行引擎的一个可选加速插件存在。它的兼容策略是：能接的算子就接过去，接不了的算子自动回退到 Spark 原生实现。这种“渐进式替换”的设计，让 Comet 的落地成本比推到重来的方案低了一个量级。

我见过不少团队一上来就打算用 Presto/ClickHouse 替代 Spark 做交互查询，结果业务侧一堆自定义 UDF 和复杂 SQL 迁移不过去，项目最终烂尾。Comet 的路线是留着 Spark 的“大脑”——Catalyst 优化器、AQE、DataSource API 全都还在——只替换“手脚”和“肌肉”，也就是底层的执行算子。对于存量 Spark 任务，接入 Comet 的代价可能就是加几个启动参数和一张 jar 包。

2.2 核心架构：Scan、Exec、Shuffle 三管齐下

Comet 把加速分成了三个层面，理解这三层，你就能知道它到底在哪些环节提速。

第一层是CometScan（扫描加速）。Spark 读 Parquet 文件时，默认是 JVM 内逐行解码，而且经常要配合 Schema 推断、向量化读取器这些逻辑。Comet 利用 Arrow 的 Parquet 读取能力，直接在 native 层解析列式文件，把数据直接输出为 Arrow 列式格式放到堆外内存，绕开了 Java 对象的创建。这一步配合谓词下推和列裁剪，扫描阶段的 CPU 和内存开销会明显下降。

第二层是CometExec（计算加速）。对于 Project、Filter、Sort、HashAggregate、HashJoin 这类核心算子，Comet 会把 Spark 物理计划里的对应节点翻译成 DataFusion 的物理算子，由 Rust 原生代码以批量方式向量化执行。所有中间结果都以 Arrow RecordBatch 在堆外流转，不碰 JVM 堆。

第三层是CometShuffle（Shuffle 加速）。这是我最喜欢的一层，也是收益最直观的一层。Comet 把 Shuffle 的写读两边都改成 Arrow IPC 格式：上游以列式格式把分区数据写盘，下游直接按 Arrow 数据块拉取，不再做 Java 序列化和反序列化，也基本不再产生堆内中间对象。Shuffle 本身的排序、分区选择在 native 层完成，整个数据链路几乎都是堆外内存操作。

2.3 为什么选择了 DataFusion 而不是自研引擎

市面上做 Spark 原生加速的不止 Comet 一家，比如 Gluten 项目选择的是 C++ 的 Velox 引擎。Comet 选择 DataFusion，我认为有几个很现实的理由。

先说技术层面的契合度。DataFusion 本身就是 Apache Arrow 社区的核心项目，从设计之初就采用 Arrow 列式内存格式和向量化执行模型。Comet 想给 Spark 做 native 加速，最省力的方式就是找一套同样以 Arrow 为核心的原生引擎，这样数据在不同层之间流转不需要格式转换。DataFusion 的模块化做得很好，它的核心库（datafusion-core）、物理计划、表达式求值都是可重用的组件，Comet 能以库的形式直接 link 进来，而不是把它当独立服务跑。

其次是安全和运维的考量。Rust 没有 GC、没有 JVM 对象头，内存安全是编译期保证的，这也意味着生产环境里因为引擎本身的内存踩踏导致崩溃的概率低很多。我见过一些用 C++ 写数据组件的场景，一遇到特殊数据就是段错误，排查起来极其痛苦。Rust 在这里的工程优势很明显。

最后是社区活力。DataFusion 的 PMC 和贡献者背景分布很广，而且它已经通过 Arrow Flight SQL 等组件被大量产品拿去当底层引擎，稳定性经过了多种场景锤炼。选一个活跃且被广泛验证的引擎，比自己在 JNI 层手写一堆 C++ 算子要靠谱得多。

3. 向量化到底“化”了什么：从 Arrow 列式格式说起

3.1 二维表结构里的“横竖转变”

要理解向量化，先要理解 Arrow 列式内存格式。传统 JVM 内存里一张表可能是“行优先”存储的，一行对应一个对象，想象成一个横着切片的列表；Arrow 则是“列优先”存储的，一整列连续放在一段内存里，想象成一个竖着切的列表。

同样是 1000 万行数据，行式存储要建 1000 万个对象；列式存储只需要为每一列建若干连续的内存数组。以整数列为例，Arrow 可以直接让这一列对应一个连续的i32数组，不需要为每个整数单独造一个装箱对象。查询WHERE age > 30时，引擎直接在这段连续数组上做循环，CPU 可以一次加载多个整数进寄存器，再配合 SIMD 指令一口气判断完一批数据。

Arrow 对变长字段也做了约定：比如字符串列，用三个数组组合表示（offset 数组 + 数据缓冲区 + 可选的 null bitmap），这样可以做到整个列的数据几乎连续，而不是每个字符串散落在堆的各处。Null 值统一用 bitmap 标记，既省空间也便于批量判断。这套设计让数据变得更“规整”，更适合 CPU 的高效处理。

3.2 DataFusion 的批处理执行模型

DataFusion 的执行模型就是典型的“批量 + 流水线”。上游算子一次输出一个 RecordBatch（比如默认 8192 行），下游算子拿到的不是一行，而是一个带着完整列数据的数组块。这种模式下，Filter 算子可以连续几千次循环处理同一列的数据，Join 算子可以一次性为整批数据构建探测表，聚合算子在批之间维护状态。因为处理单位从“一行”变成了“一个 batch”，函数调用次数、虚拟派发开销、内存分配次数都被压缩了几个数量级。

批处理还有一个隐形的收益：JIT 编译和算子熔断更容易做。原生代码可以在编译期知道列的类型、长度和布局，生成高度特化的循环；多个相邻算子也可以合并成同一个循环，减少中间数据的物化。DataFusion 里有物理计划优化器专门做这类工作，Comet 接到物理计划后可以直接复用这部分能力。

我打个比方：行式处理像是你每次从冰箱拿一个鸡蛋，煎完再拿下一个；向量化执行是预先从冰箱拿出一整板鸡蛋，先全部打到盆里，再一次性下锅。后者的“准备工作”和“单次动作”都大大减少，这就是向量化能跑得更快最朴素的原因。

3.3 从 Spark 物理计划到 DataFusion 计划的一跳

Comet 的底层衔接其实是一个“翻译”过程。Spark 经过 Catalyst 优化的物理计划树里，每个节点就是ProjectExec、FilterExec、SortExec、HashAggregateExec这样的执行算子。Comet 通过 Spark 的 extension 机制注册了规则，尝试把整棵物理计划树转换为自己的 Comet 执行计划。

转换并不是逐个节点原样照搬，而是能合并的尽量合并。比如 Spark 物理计划里连着的 Filter、Project，Comet 会组合成 DataFusion 的单个算子链，减少不必要的中间数据交接。Shuffle 之前的分区计算、排序键提取、序列化，也会整个挪到 native 层一口气做完。转换不了的部分，比如自定义 UDF、某些特殊窗口函数，Comet 会在那个节点标记“fallback”，让 Spark 接管那一段执行，两头通过数据交换衔接起来。

这种“能者多劳、难者回退”的机制有个好处：任务总能跑出正确结果，最坏情况也就是退化成和原来几乎一样的效率。所以接入 Comet 的风险评估相对简单，你不需要保证每个 SQL 都完全命中原生算子，只要大部分重活是原生在干，收益就已经很可观了。

4. 实操：把 Comet 接到自己的 Spark 集群

4.1 环境准备与 jar 包构建

先交代一下我的运行环境，给你做个参照：Spark 3.5，Scala 2.12，JDK 8/11 都可以，Hadoop 3.3。Comet 目前官方主线对 Spark 3.2 到 3.5 都有对应的 profile，构建时按自己的 Spark 版本选模块即可。理论上 Spark 4.0 也陆续有支持，但我建议生产环境保守一点，先停在主流 3.x 版本上。

Comet 没有发布到 Maven 中央仓库的稳定版本（在早期阶段），你需要从源码构建。构建命令大概是这样的：

git clone https://github.com/apache/arrow-datafusion-comet.git cd arrow-datafusion-comet mvn -pl comet-spark-spark3.5 -am -Pspark-3.5 clean package -DskipTests

构建完成后，需要的产物是类似comet-spark-spark3.5/target/comet-spark-spark3.5_2.12-xxx.jar的 jar。同时构建过程还会在某个临时目录生成 native 动态库，比如libcomet.so或libcomet.dylib。实际部署时，我需要额外提醒一个很多人会忽略的点：动态库的加载路径。

Comet 的 native 库默认会打包进 jar，或者你需要用spark.executorEnv.LD_LIBRARY_PATH把动态库目录暴露给 Executor 进程。我在实操中发现，直接把 jar 放到 Spark 的jars目录是最省心的方法，但 native 库依赖如果没打进去，启动时会报找不到.so的错误。如果你遇到这类问题，可以先确认jar tf comet-xxx.jar | grep libcomet能不能看到动态库，再决定要不要在启动脚本里手动指定LD_LIBRARY_PATH。

4.2 启动参数与核心配置

接到集群上，最朴素的方式是在spark-submit里加 jar 和配置：

./bin/spark-submit \ --jars /path/to/comet-spark-spark3.5_2.12-xxx.jar \ --conf spark.sql.extensions=org.apache.spark.sql.comet.CometSparkSessionExtensions \ --conf spark.comet.enabled=true \ --conf spark.comet.exec.enabled=true \ --conf spark.comet.exec.shuffle.enabled=true \ --conf spark.comet.shuffle.enabled=true \ --conf spark.comet.exec.memoryOverhead=4g \ --conf spark.comet.exec.otherMemoryOverhead=4g \ --class com.example.MyApp my-app.jar

spark.sql.extensions是 Spark 开放的扩展点，Comet 通过它注册自己的优化规则、查询执行策略和 AQE 相关支持。核心开关是spark.comet.enabled，不打开这个总开关，后面一堆配置都是空转。spark.comet.exec.enabled控制执行引擎的 native 化，spark.comet.shuffle.enabled控制 Shuffle 数据格式切换，spark.comet.exec.shuffle.enabled再把 Shuffle 内部的执行逻辑也切到 native（比如分区合并、排序、聚合）。

下面这张表格是我个人常用的参数清单，你可以照着抄，然后根据集群资源微调。

spark.comet.exec.memoryOverhead这里的“内存”指的是堆外内存，不占用 Executor 堆。Comet 执行期间，列式数据、中间结果缓存在堆外，所以如果你原来就压着 Executor 堆内存跑，记得把spark.executor.memoryOverhead也同步调大，避免 JVM 和 native 内存互相挤兑。就我观察，数据量在单 Task 几百 MB 到几个 GB 的场景，4g 起步够用；如果单 Task 扫描的数据特别大，建议跑到 8g 再观察。

4.3 怎么确认 Comet 真的生效了

配置完之后，别急着跑全量任务，先用一条中等复杂的 SQL 观察执行计划。在 Spark SQL 里执行：

EXPLAIN SELECT sum(l_extendedprice * l_discount) FROM lineitem WHERE l_shipdate >= '1994-01-01' AND l_shipdate < '1995-01-01';

如果 Comet 生效，物理计划里应该能看到类似CometScan parquet、CometProject、CometHashAggregate这样的节点名。反过来，如果物理计划里还是FileScan parquet、ProjectExec、HashAggregateExec，说明要么扩展没注册上，要么那个算子在当前 SQL 下不支持回退到了 Spark 原生执行。

另一个验证技巧是看 Shuffle 阶段的数据格式。启用 Comet Shuffle 后，Shuffle 写出的文件大小体积往往会比默认的 Java 序列化方式小不少。如果你盯着 Spark UI 看 Shuffle 读写的字节数，会发现和优化前有明显差异。这个信号虽然间接，但很直观。

还有个小坑要提醒你：Comet 默认对 Spark SQL 会话是动态感知的。如果你在代码里动态创建了临时视图，或者通过.option()查询外部表，执行计划一样会经过 Comet 的转换，没问题；但如果你在扩展类没配置对的情况下直接改spark.comet.enabled=true，容易出现“配置看着开了，实际计划没变”的情况。所以建议调试阶段多依赖EXPLAIN，不要只看日志里有没有报错。

5. 性能效果、适用场景与调优经验

5.1 收益到底有多大，别只看“官方数字”

关于 Comet 的性能收益，网上能搜到不少 benchmark 数据。官方公开的测试里，TPC-H 和 TPC-DS 在 1TB 规模下，中位数加速比都在两倍上下，部分查询能跑到五六倍以上。我在自己集群上的实测结果没有那么夸张，但也符合预期：纯扫描和聚合型的查询加速明显，Shuffle 重的 join 任务提速空间大，短小 SQL 基本没感觉，偶尔还会因为 JNI 初始化略慢一点点。

我不建议你拿别人环境的数据当自己的 KPI。性能这个东西受数据分布、集群规模、文件格式、并发度影响太大。比如你原来 Spark 作业瓶颈本来就是存储 IO（比如冷数据走 S3 而且网络带宽受限），那把执行引擎换成向量化的也救不了磁盘读取速度。真正适合 Comet 的场景，是那种“数据都在本地/存储读得动，但 CPU 集中在序列化、反序列化和 GC 上”的作业。

我这边最典型的获益作业是“大表 join 小表 + 聚合”。之前跑 1 小时 40 分钟的任务，在同等资源下切到 Comet Shuffle 和原生执行后，大概是 50 分钟跑完。时间主要省在了 Shuffle 阶段——Shuffle 数据量目测少了 30% 到 40%，GC 频率也明显下降。这种收益来自三个叠加：序列化开销没了、堆内对象没了、列式压缩让落盘数据变小。

5.2 调优思路：内存、并行度、AQE 的配合

接入 Comet 后，Spark 本身的一些调优参数仍然有效，但侧重点变了。

第一优先级是堆外内存。我会先给每个 Executor 预留至少 4g 的spark.comet.exec.memoryOverhead，同时把spark.executor.memoryOverhead从默认的“10% 堆内存”手动拉到几个 GB。理由很简单：Comet 做 Shuffle 和 join 时，中间列式数据是堆外存放的，如果堆外空间不足，它会回退或者 OOM。我说的 OOM 不是 JVM 的OutOfMemoryError，而是 native 层的 abort，错误信息会很不一样。

第二优先级是并行度与分区大小。因为向量化执行一次处理一个 batch，batch 太小会让向量化的优势打折扣。如果你的 Spark 作业 shufle 分区数量特别多（比如 10000 个分区但是每个分区只有几百 KB），Comet 启动、JNI 调用的开销会吃掉不少收益。建议先把分区控制在一个 Task 处理 100MB ~ 200MB 数据这个量级，再观察效果。

第三是和 AQE 的配合。Comet 对接了 Spark 的 Adaptive Query Execution，动态合并分区、动态 join 策略这些优化在原生执行里同样有效。我建议保持 AQE 开启。此外，我记得 Comet 也有些自己的 AQE 规则（比如动态切换 join 策略），如果你发现某个 join 没有走 Comet 原生执行，可以往“统计信息缺失导致 Spark 选择了 broadcast join，而 broadcast join 没被 Comet 覆盖”这个方向排查。

5.3 什么时候不建议用 Comet

Comet 不是银弹，有几类场景我是不推荐硬上的。

一是你大量使用自定义 UDF，尤其是不支持原生执行的 Python UDF 或复杂 Java UDF。Comet 遇到这类算子会整段回退，回退后还要做一次堆内外数据交换，这个交换本身就有开销。如果一个 SQL 里 UDF 占比很高，省下的执行时间可能不够补偿交换成本。

二是低延迟交互查询。向量化引擎天然为批量执行设计，批处理要攒到一定行数才划算。如果你查询的数据量只有几万行，毫秒级任务里 JNI 初始化和计划转换的开销反而显著，基本不会得到正面收益。我这里说的“低延迟查询”是真正秒级以内的那种，不是分钟级 BI 报表。

三是集群内存已经非常紧张。Comet 需要额外的堆外内存。如果一台机器 16G 内存里 JVM 堆已经占了 12G，再逼 Comet 去挤堆外内存，最后只会大家一起 OOM。这种情况可以只开 Shuffle 加速（spark.comet.shuffle.enabled=true，关闭spark.comet.exec.enabled），Shuffle 阶段对堆外的占用通常会比全量执行小一些，收益也依然可观。

6. 踩坑实录与问题排查速查

6.1 版本与依赖问题

我接入 Comet 过程中，第一个坑就是 jar 版本和 Spark 版本对不上。一开始我直接用了 spark3.5 的模块，结果集群上实际是 Spark 3.3，启动后 Spark 扩展类能注册，但执行到一半就抛一些诡异的NoSuchMethodError。这种错误往往不是 API 名字写错，而是运行时方法与编译时版本不一致。排查方法不复杂，把它当普通 jar 冲突处理：先查 Spark 版本，再查spark.version系统属性，确保构建时 profile 一一对应。

另一个高频报错是本地找不到 native 库。我在第 4 节提过libcomet.so的事，这里再说一个判断技巧：报错如果包含UnsatisfiedLinkError，基本可以确定是 native 库加载问题；如果报ClassNotFoundException或NoClassDefFoundError，才能往 jar 缺失方向查。这个区分能帮你省很多时间。

6.2 Shuffle 和内存问题排查

Shuffle 阶段如果出现数据错乱或者结果不对，先不要急着怀疑向量化引擎的计算逻辑。我遇到过一次比较隐蔽的问题：上游任务用spark.comet.shuffle.enabled=true，下游任务读数据时用的是 Spark 默认的 shuffle reader，格式对不上导致数据解析异常。这在混合集群里很常见——你的一部分作业开了 Comet，另一部分没开，而 Shuffle 文件是按 Job 写的。解决办法很简单，要么同一套 SQL 链路的 Executor 配置保持一致，要么单独为 Shuffle 开一条专用链路。

内存方面，native OOM 的报错通常不是java.lang.OutOfMemoryError，而是进程直接异常退出，或者 stderr 里出现failed to allocate memory之类的字样。看到这种信息，我一般先调大spark.comet.exec.memoryOverhead，同时降低单 Executor 的并发 Task 数。如果并发 Task 数降不下来，可以在 Spark 配置里限制每个 Executor 的 CPU 份额，给 native 内存留出呼吸空间。

还有个经验：对 Spark 的动态分配不敏感。Comet 的动态库是随 Executor JVM 加载的，Executor 启动和销毁时都要付出 native 初始化成本。如果你的集群开了很激进的动态伸缩（比如空闲 60 秒就释放 Executor），任务一多就会频繁看到启动开销。我建议短期跑批作业干脆关掉动态分配，把固定资源池拉起，Comet 的优势才能稳定发挥。

6.3 如何快速确认算子是否回退

给读者一个我常用的诊断顺序。第一步，对目标 SQL 跑EXPLAIN，看物理计划中有没有Comet开头的算子节点。第二步，查看 Spark UI 里对应 Stage 的日志，Comet 会在日志里输出 native 执行相关的信息（不同版本日志格式不太一样），如果全是默认的 Spark 调度日志，说明这条链路基本没走原生。第三步，用一个小数据量的 SQL 做 A/B 验证，分别开和关spark.comet.exec.enabled，对比同一个 Job 的 CPU 时间、GC 时间、Executor 内存曲线。

这三步做完，你基本能定位问题是出在“没启用”还是“不支持”。如果是“不支持”，看是不是某个特定算子导致的。Comet 对算子覆盖度一直在扩大，但像某些窗口函数、复杂子查询、带特殊 Hint 的 join，仍然可能回退。对这种 SQL，能改写法就改，不能改就接受局部回退，反正大部分场景下整体收益还是正的。

7. 个人体会与下一步可做的事

我在实际接入 Comet 的这段时间里，最大的体会是：Spark 性能优化的天花板，其实不在“调参”而在“执行模型”。参数调优是在给一个低效模型打补丁，向量化执行是从根上换了一套更高效的运转方式。Comet 这种“留大脑、换手脚”的路线，对现有 Spark 用户非常友好，你不需要改一行业务代码，只需要接受“让 Rust 帮 Spark 搬数据”这个设定，就能拿到相当可观的提速。当然，它也有限制，算子覆盖、堆外内存管理、混合版本环境都需要你花时间去适应。

最后再分享一个小技巧：如果你不确定 Comet 对某个 SQL 的收益，可以用spark.comet.enabled=true和false各跑一遍同样的数据量，但只看最近一个 Stage 的“Shuffle 读/写字节数”和“GC 时间”两个指标。这两个指标对执行引擎的变化最敏感，也能最直观地反映向量化组件到底在哪个环节帮你省了钱。等 Comet 后续对更多算子和文件格式（比如 ORC、Iceberg 等）的支持逐渐补齐，它在生产集群里的想象空间还会更大，我后面也会持续关注它的更新动向。