monkeyboy_tech的博客

本文分析了Apache Datafusion Comet项目中Rust Native的Shuffle算子CometShuffleExchangeExec的实现机制。该算子通过ShuffleDependency控制Shuffle Writer的写入方式（CometNativeShuffle或CometColumnarShuffle），并生成CometShuffledBatchRDD用于Shuffle Read。关键点在于根据子节点类型决定Shuffle类型，进而选择不同的Writer（CometNativeS

本文分析了Apache Datafusion Comet项目中Rust Native引擎如何生成RDD[ColumnarBatch]的过程。CometNativeExec作为所有Native物理计划的父类，通过doExecuteColumnar方法实现列式执行。该方法首先检查序列化计划是否存在，然后创建CometMetricNode并遍历Native Scan节点处理加密配置，要求最多只能有一个加密Scan计划。最后收集连续的Comet物理计划作为输入节点。项目采用Spark插件化架构，结合Protobuf

摘要 Apache Datafusion Comet是苹果开源的Spark向量化加速项目，采用Spark插件化+Protobuf+Arrow+DataFusion架构。项目通过SparkPlugin实现驱动和执行器插件，利用Protobuf序列化表达式，Arrow实现高效数据交换，DataFusion作为Rust向量化执行引擎。本文基于2026年1月最新代码，重点分析Rust原生执行物理计划流程。 执行流程分为Java和Rust两部分：Java侧通过nativeLib.executePlan触发执行，支持内

本文分析了Apache Datafusion Comet项目中Rust Native创建物理执行计划的关键流程。该项目通过Spark插件化架构，结合Protobuf、Arrow和DataFusion技术实现Spark加速。重点解析了CometExecIterator类中的createPlan方法，该方法在Executor端执行时，会序列化Spark配置和查询计划，并通过JNI调用传递给Native引擎。文章详细说明了17个关键参数的用途和约束条件，包括执行上下文ID、输入数据迭代器、序列化计划、内存配置等。

Apache Datafusion Comet是苹果开源的Spark向量化加速项目，采用Spark插件+Protobuf+Arrow+DataFusion架构。本文分析其Rust Native数据读取的零拷贝实现，重点关注CometBlockStoreShuffleReader模块。通过JNI交互，Java侧传递DirectByteBuffer数据，Rust侧利用get_direct_buffer_address获取内存地址切片，支持Snappy/LZ4/ZSTD等多种压缩格式解析为Arrow Record

摘要 Apache Datafusion Comet是苹果开源的Spark向量化加速项目，采用Spark插件化+Protobuf+Arrow+DataFusion架构。本文基于最新代码分析Rust Native数据写入功能，重点解析writeSortedFileNative方法的实现细节。该方法由Spark的CometBypassMergeSortShuffleWriter和CometUnsafeShuffleWriter调用，通过JNI将参数传递给Rust实现高效文件写入。Rust利用Arrow IPC格

Apache DataFusion Comet是苹果开源的Spark向量化加速项目，通过插件化架构将Spark算子offload到Rust实现的DataFusion引擎执行。核心组件包括：Spark插件（Driver/Executor）、Protobuf序列化、Arrow数据交换和DataFusion执行引擎。本文分析了CometSparkSessionExtensions中的向量化规则转换流程，重点剖析CometExecRule如何将Spark物理计划转换为Native计划。转换过程包括：表达式归一化处理

本文分析了Apache Datafusion Comet项目的向量化规则转换机制，重点研究了CometSparkSessionExtensions中的CometExecRule。该项目采用Spark插件化架构，结合Brotobuf序列化、Arrow数据交换和DataFusion向量化引擎，通过CometShuffleManager实现两种Shuffle模式：Columnar Shuffle（JVM模式）和Native Shuffle（原生模式）。文章详细解析了CometBypassMergeSortShuf

本文分析了Apache Datafusion Comet项目中的CometScanRule向量化规则转换。该项目通过Spark插件、Protobuf、Arrow和DataFusion等技术实现Spark加速。CometScanRule主要处理扫描节点的转换，首先检查平台字节序（仅支持小端）、Comet功能开关和动态库加载状态。对于数据源V1（FileSourceScanExec），需满足HadoopFsRelation类型且无动态分区裁剪才会转换为CometScanExec；对于V2（BatchScanEx

本文分析了Spark 4.0.0中的ApplyColumnarRulesAndInsertTransitions规则，该规则负责在行列执行模式转换处插入转换节点。核心方法insertTransitions和insertRowToColumnar通过递归遍历物理计划，在需要行列转换的位置插入RowToColumnarExec或ColumnarToRowExec节点。前者将行式数据转为列式，后者反之。该机制使Spark既支持传统的行式执行(doExecute)，也支持向量化的列式执行(doExecuteColu

Apache Datafusion Comet是苹果开源的Spark向量化加速项目，采用Spark插件化+Protobuf+Arrow+DataFusion架构。其中CometPlugin作为Spark插件，在Driver端通过CometDriverPlugin初始化，主要功能包括：1）检查堆外内存配置，未启用则直接返回；2）注册CometSparkSessionExtensions以添加向量化转换规则；3）在特定条件下调整Executor内存配置（当Comet Native执行、Shuffle和堆外内存都

摘要 Apache Arrow的零拷贝技术通过共享内存指针实现跨系统（Python、Java、C++等）高效数据交换，避免数据复制和序列化开销。其核心在于标准化的列式内存布局和C Data接口，使不同运行时可直接访问相同内存数据。该技术适用于Arrow原生格式、IPC通信及集成引擎场景，但在处理可写NumPy数组或复杂嵌套数据时会失效。主要优势包括提升数据处理性能、降低内存压力以及简化跨工具数据交互架构。

Apache DataFusion Comet是苹果开源的高性能Spark加速项目，采用Spark插件化架构结合Arrow和DataFusion技术栈。通过SparkPlugin实现Driver/Executor插件机制，利用Protobuf序列化执行计划，借助Arrow实现高效列式数据交换，最终将计算任务offload到基于Rust的DataFusion向量化引擎执行。使用方式上，通过配置插件、列式shuffle和off-heap内存等参数即可启用。项目提供了Rust原生基准测试(Criterion)和火

本文分析了Spark中DataSourceScanExec因动态分区裁剪导致的NPE问题，核心在于maxMetadataValueLength字段的序列化机制。文章指出，该字段在序列化时会保存整数值而非引用对象，解释了为何Executor反序列化时不会报错。同时探讨了Java序列化原理和Scala闭包特性，建议通过预计算值避免闭包引用外部对象。文章结合具体代码示例，说明了如何通过调整变量作用域来优化序列化行为，解决Spark中的NPE问题。

本文基于Spark 4.0.0分析内存管理机制与内部行处理优化。Spark内存分为执行内存（处理shuffle数据）和存储内存（缓存RDD/broadcast数据），通过MemoryManager实现堆内(Heap)和堆外(Unsafe)内存分配。堆外内存通过Unsafe直接操作原生内存，堆内内存则管理Long数组对象并采用弱引用优化GC。UnsafeRow作为InternalRow实现，通过字节数组存储减少GC压力，同时降低内存占用并精确计算内存使用，在shuffle过程中直接操作字节数据，显著减少了序列

文章摘要：本文介绍了SQL计算存储引擎的核心概念与优化方法。计算存储引擎分为计算（SQL解析、优化、执行）和存储（数据格式、获取）两部分。对比分析了Spark和Flink的任务调度模式（StageByStage与AllAtOnce），并详细阐述了SQL计算流程：从SQL解析到物理计划转换，包括RBO和CBO优化策略。在数据存储方面，区分了无存储系统（依赖底层文件过滤）和存算一体（支持索引）两种引擎的差异，特别强调了点查场景下调度优化的必要性。文章还提出了通过减少数据量、优化shuffle等方法来提升SQL执

Spark 4.0引入新型Variant数据类型优化半结构化数据处理，兼具JSON的灵活性和Struct类型的高性能。Variant采用二进制编码存储，无需预定义模式，支持快速查询。其核心方法getFieldByKey通过智能搜索策略（短列表线性搜索，长列表二分查找）高效获取字段值，handleObject方法解析对象元数据布局。相比JSON字符串解析，Variant直接读取二进制数据，显著提升处理速度，为半结构化数据提供了更优的存储和查询方案。

本文介绍了Spark 4.0中VariantType类型的存储机制，该类型通过优化字节存储来高效处理JSON数据。文章详细解析了VariantBuilder.buildJson方法对不同JSON数据类型（如字符串、数字、布尔值、对象等）的处理逻辑：字符串根据长度分为LONG_STR和SHORT_STR两种存储格式；数字根据范围采用INT1/2/4/8或DECIMAL4/8/16分级存储；浮点数优先尝试Decimal存储，否则用IEEE DOUBLE格式。每种类型都通过特定字节组合标识类型和存储内容，采用小端

中 内存排序(UnsafeInMemorySorter)最基本的思想：先根据前缀比较算法进行比较，如果相等的话，则再遍历实际数据的指针去获取真正的数据进行比较,这种可以规避随机内存读取从而提交缓存的命中率，进而提高比较的速度。这里特别说一下：两种类型的BinaryType(对应内部的类型为Array[Byte]) 和 StringType(对应的内部的类型为UTF8String) 获取prefix的.会根据Spark的内部类型，获取Long类型的可以用于比较的值,所以我们可以看到在。

分享本文的目的就在于 使读者明确 怎么在Spark SQL中调用 python注册的UDF，这里的的SQL 可以不仅仅是在 python api 中调用，也可以是在 java或者scala api中调用的。,好像都没有说到在Spark SQL中怎么直接调用 python定义的UDF，但是其实在使用上，Spark SQL是可以直接使用 python定义的UDF的，可以看到 这种运行 python UDF的方式是以socket的方式进行交互的，所以这种方式相对来说还是会比较慢的。

因为原则上来说，如果没有开启AQE之前，一个SQL执行单元的是属于同一个Job的，开启了AQE之后，因为AQE的原因，一个Job被拆成了了多个Job，但是从逻辑上来说，还是属于同一个SQL处理单元的所以还是得归属到一次执行中。类在内存中存放着 一个整个SQL查询链的所有stage以及stage的指标信息，在AQE中 一个job会被拆分成很多job，甚至几百上千的job，这个时候 stageMetrics的数据就会成百上倍的被存储在内存中，从而导致。主要的作用是设置当前计划的所属的。该方法会获取事件中的。

假如说hash(col)为0，那实际上只有reduceTask0有数据，其他的ReduceTask1等等都是没有数据的，所以最终只有ReduceTask0写文件，并且只有一个文件。这些值配置，如果这些配置调整的不合适，就会导致写文件的时候有可能只有一个Task在运行，那么最终就只有一个文件。的作用是对小文件进行拆分，使得罗盘的文件不会太大，这个会有个问题，如果我们在使用。的作用主要是进行文件的合并，是得文件不会太小，本文基于Spark 3.5.0。的值是固定的，比如说值永远是。

这种情况下，在Spark的内部表示 ShuffleOrigin 为 REBALANCE_PARTITIONS_BY_NONE，这种情况下 是hint为。这里的条件默认是根据shuffle的个数来计算的，如果优化后的shuffle数有增加，则会回退到之前的物理计划中去，当然用户也可以配置。针对第二种情况，这种情况一般来说都是有正向的提升效果的，但是也会经过第一种情况的逻辑判断。规则下，有可能会增加额外的Shuffle操作，这种情况就是负优化了，所以在进行了。的作用简单的来说，就是会按照一定的规则，从一个。

因为对于Spark来说，任何一个事情都不是独立的存在的，比如说parquet文件的rowgroup设置的大小对读写的影响，以及parquet写之前排序对读parquet的影响，以及向量化读取等等。为‘true’(默认就是true)，则会进行unsafeRow的转换，当然这里的好处就是节约内存以及能够减少GC。最近在整理了一下 spark对Parquet的写文件的过程，也是为了更好的理解和调优Spark相关的任务，这条filter，则只会拿出rowgroup的信息和rowgrups的的行数。

的时候得注意不能调整过大，否则会导致OOM，但是如果在最后写文件的时候加入合并小文件的功能（AQE+Rebalance的方式），也可以适当的调整大一点，因为这个时候的Task 不像没有shuffle一样，可能还会涉及到sort以及aggregate等消耗内存的操作，（这个时候就是一个task纯写parquet文件）这三个配置项存在着相互制约的关系，总的目标就是检查当行数达到了一定的阈值以后，来检查是否能够flush到内存page中，具体的可以查看。表示的是partition名字的常量。

会根据partition或者bucket作为最细粒度来作为writer的标准，如果相邻的两条记录所属不同的partition或者bucket，则会切换writer，所以说如果不根据partition或者bucket排序的话，会导致。频繁的切换，这会大大降低文件的写入速度。目前 Spark中的实现中，对于多分区的写入默认会先排序，这是没必要的。至于Spark在写入文件的时候会加上Sort，这个是跟写入的实现有关的，也就是。这两个物理计划中，最终写入文件/数据的时候，会调用到。（默认值为0），则会加上。

这个问题折腾了我大约2个小时，错误发生的上下文都看了不止十遍了，还是没找到一丝头绪，可能是上帝的旨意，在离错误不到50行的地方，对于一个在大数据行业摸爬滚打了多年的老手来说，第一眼肯定是跟着堆栈信息进行排查，目前在排查 Spark 任务的时候，遇到了一个很奇怪的问题，在此记录一下。在查找错误的时候，还是得在错误的上下文中多翻几页。这个类，但是就算把代码全看一遍也不会有所发现。， 没想到是 OOM 问题。理所当然的就是会找到。

针对于错误的写法,也就是导致读取全量数据的写法，我们分析一下，首先是类型转换阶段，在Spark中，对于类型不匹配的问题，spark会用规则进行转换，具体的规则是。最近在使用 Paimon 的时候遇到了一件很有意思的事情，写的 SQL 居然读取的数据不下推，明明是分区表，但是却全量扫描了。这种情况下，对于文件的读取IO会增大，但是对于shuffle等操作是不会有性能的影响的。对于分区字段来说，我们在写SQL对分区字段进行过滤的时候，保持和分区字段类型一致。可以看到经过了规则转换 所有的过滤条件都下推到了。

最终我们只留下了log4j2 (log4j-core + log4j-api) + logback (logback-classic + logback-core) ,其他的都排除掉，web端打包加编译没有任何问题，一切还是那么的美好（毕竟花了一天时间）在 spark3.1中采用的是log4j1 (log4j + slf4j-log4j2),spark 3.5中采用的是log42(log4j-core + log4j-api + log4j-slf4j2-impl),

注意是Mac Keynote。

目前在做一些知识回顾的时候，发现了一些很有意思的事情，就是Spark UI中ShuffleExchangeExec 的dataSize和shuffle bytes written指标是不一样的，指的是写入文件的字节数，会区分压缩和非压缩，如果在开启了压缩（也就是spark.shuffle.compress true）和未开启压缩的情况下，该值的大小是不一样的。那么在AQE阶段的时候，是以哪个指标来作为每个Task分区大小的参考呢。的实例，这样就获取到了实际内存中的每个分区的大小,

该计划的差异主要部分还是在于Rule在和的差别处理。

最主要关心的是 parser这个变量，因为由于上述规则的原因，两个schema单独在不同的parser中，而这里的 Child是由regexp_replace表达式组成的，所以该正则表达式会计算两次，这里就会解析为 Alias(GetStructField(attribute.get, i), f.name)()(主要就是调用JsonToStructs.toString的方法)进行 UnresolvedStar 的expand方法的调用。主要的原因是 Spark 3.1.x 引入的。

大概的意思因为要保证task commits的原子性，所以好的建议是remove掉v2，不推荐使用V2。所以最后得出的结论就是：V1是安全的，但是性能不好，V2有可能是不安全的，但是性能好，推荐使用V1。FileOutputCommitter.commitTask方法。也就是为了保证spark向前向后的兼容性，强行设置为。dataWriter.write和commit方法。该executeTask方法最后会调用。当然Spark官方文档也有解释。对于spark来说默认的。更多关于细节，可以参考。

虽然说在Executor端写入了多个重复数据的文件，但是因为在只有一个真正的文件会被Driver认可，所以通过最终返回的被driver认可的文件和marker文件求交集就能删除掉其他废弃的文件。在写入真正文件的同时，会在 .hoodie/.temp/instantTime目录下创建maker文件，比如.hoodie/.temp/202307237055/f1.parquet.marker.CREATE,之后在task.commit的时候会把临时目录的文件真正的移到需要写入的目录下。

这步操作主要是把生成的Compaction plan序列化成字节，并保存在相应的文件中，并生成一个Compaction的Request。baseFile，partitionPath，logFiles，还有Compaction策略。该方法主要是生成一个调度Compaction的计划。执行当前Commit的compaction操作。重新运行上次失败的Compaction计划。是够是异步Compaction计划生成。中，我们没有过多的解释Spark中。的实现，在这里详细说一下。

如果在语意允许的情况下，选择left join可以大大加速任务运行,笔者遇到的情况就是 left join 运行了。一样，唯一不一样的是SortMergeJoin 的child的outputPartitioning是。后如果不重新shuffle，会导致一个任务中会有id为null值的存在，会导致join的结果不正确。来说就不一样了，task join完后id还是保持原来的就不会变，所以就不必重新shuffle。只有在读取source文件完之后才会有Exchange的shuffle的操作。

最终会调用反射去获取字段，要知道反射是比较消耗时间的，要知道我们现在是有1000多个字段，如果每一行都会被反射1000次，再加上几十亿行的数据，这个计算速度肯定是比较慢的，而且为了达到更新的效果，我们还调用了。目前在我们公司遇到了一个任务写delta（主要是的。delta的MergeIntoCommand。操作，这又增加了cpu的计算（1000多次）set该schema的字段，其他的字段不变。实现的，该操作的的具体实现，可以参考。操作），写入的时间超过了。

来说，目前存储所有的事件信息以及UI所需要的信息都是默认存储在内存中，这在CS中，对于以。作为存储以后，能够减少driver所需内存，并且引进新的。数据结构为InMemoryStore。能够大大加快spark事件的读写事件。Spark UI和SHS。

中，我们提到Spark 3.4.x中是Client和Server之间的数据传输是采用。的，那具体是怎么实现的呢？这里的逻辑就是转换为。