monkeyboy_tech的博客

本文以Kyuubi 1.9.2为例，解析其服务启动流程。通过bin/kyuubi start脚本定位到主类org.apache.kyuubi.server.KyuubiServer，分析main方法：打印版本信息、注册信号处理器、加载默认配置，随后调用startServer启动服务。服务初始化时嵌入Kinit、GC、Metrics等辅助服务，并根据配置启动Backend（会话管理）与Frontend（请求接入）服务，最终启动服务器。整个过程体现了Kyuubi的模块化设计与高可用支持。

Kyuubi作为企业级大数据网关，不仅支持分布式多租户，还通过可插拔插件提供增强功能。核心插件KyuubiSparkSQLExtension实现自定义SQL语法（如ZORDER）、小文件合并等优化；RangerSparkExtension则集成Ranger实现细粒度权限控制，支持行级、列级数据安全。两者均基于Spark扩展机制，配置灵活，可按需启用或排除规则，显著提升查询性能与安全性。

本文分析了Spark 4.0在查询计划缓存过程中对逻辑计划进行归一化处理的实现机制。主要包含两个层面：用户可通过SparkSessionExtensions自定义归一化规则；Spark内部通过doCanonicalize方法实现归一化，包括对子节点、Alias表达式和列引用进行统一处理（如标准化ExprId、表达式名称等）。通过这种归一化处理，Spark能够判断不同但语义相同的查询计划是否等价，从而决定是否复用已缓存的InMemoryRelation，避免重复计算。文章还通过示例展示了不同会话中相同语义查询

摘要：本文分析了Spark 3.5.3中AQE框架基于运行时Shuffle统计信息动态调整join策略的三种优化场景。当检测到大量空分区时，添加NO_BROADCAST_HINT避免广播负优化；当分区数据较小时，添加PREFER_SHUFFLE_HINT选择更高效的hash join；若同时满足则直接采用SHUFFLE_HASH策略。这些优化仅在用户未手动指定HINT时触发，通过智能调整join策略提升执行效率。决策流程通过检查子节点的Shuffle统计信息，结合分区空置率和数据量大小进行判断。

Spark Tungsten（钨丝计划）通过缓存敏感计算优化排序性能，将排序键和指针存储在一起，优先比较排序键前缀（存储在连续内存的LongArray中），仅在必要时访问实际数据。支持Radix Sort和TimSort两种算法：前者直接排序8字节前缀（O(n)复杂度且缓存友好），后者在键相同时需访问数据（可能缓存未命中）。该优化利用了CPU缓存局部性原理，显著提升处理效率，但String类型因长度不定无法使用前缀比较器。核心思路是通过减少随机内存访问来提高CPU缓存命中率。

Parquet文件由RowGroup、ColumnChunk和Page三级结构组成，以"PAR1"魔数开头。数据区包含多个RowGroup，每个RowGroup包含多个列的数据块(ColumnChunk)，数据块又细分为多个Page。文件末尾的元数据区(Footer)记录了Schema、行数、列统计信息等关键元数据，采用Thrift格式序列化，并以4字节长度标记结尾。这种分层结构支持高效的列式存储和查询优化。

本文基于Spark 3.5.3分析cache和checkpoint机制的区别。在Driver端，cache仅做标记配置，实际缓存操作发生在Executor端；而checkpoint会在Driver端执行实际checkpoint操作并清除血缘关系。两者数据可相互读取：checkpoint优先使用缓存数据，cache优先使用checkpoint数据。cache数据在Executor退出或RDD被GC时清除，checkpoint数据可通过配置在RDD被GC时清理。执行过程中，任务会优先查找本地或远程BlockMa

StarRocks的Segment采用列式存储与多级索引设计：列数据独立存储为多个Page，支持智能编码和LZ4压缩。多级索引包括Ordinal（行号定位）、ZoneMap（范围过滤）、Bitmap（等值）和BloomFilter（高基数过滤）。通过排序键快速定位数据：首先利用ZoneMap找到对应Segment，再通过前缀索引和Ordinal索引定位Page，最终计算行号偏移获取数据。Segment文件包含数据页、列索引、短键索引和元数据Footer。此外，删除向量通过Ordinal索引关联行号，实现高效

本文介绍了StarRocks中的分区裁剪和tablet裁剪机制。分区裁剪通过过滤条件与分区信息求交集，剔除不相关分区；tablet裁剪则基于主键哈希计算定位特定tablet。两者配合显著减少了数据扫描范围，提升了查询效率。文章详细分析了Range分区和List分区的裁剪逻辑，并解释了哈希分桶算法的实现细节，包括CRC32哈希计算和bucket定位方法。这些优化技术共同构成了StarRocks高效查询处理的关键组成部分。

本文分析了Pipeline调度和MPP调度的差异，重点阐述了并行度参数设置流程。Pipeline调度通过细粒度任务拆分提升单机多核利用率，MPP调度则实现分布式集群的多机并行。核心流程包括：FE生成物理计划并拆分为PlanFragment，通过parallel_fragment_exec_instance_num控制实例数；BE端通过pipeline_dop设置Pipeline并行度。FE根据Fragment最左节点类型采用不同分配策略：Scan节点按数据分布和BE节点数确定实例数，Exchange/Agg

git submodule命令用于在主Git项目中嵌套管理独立的子项目仓库。通过git submodule add添加子模块，会在.gitmodules和.git/config中记录子模块信息，主项目保存的是子模块的特定Commit ID。移除子模块使用deinit和rm命令。克隆包含子模块的项目后，需先init初始化，再update更新内容，--recursive --remote参数可递归更新嵌套子模块。该功能实现了主项目与子模块版本的独立管理。

Apache DataFusion Comet是苹果开源的Spark向量化加速项目，采用Spark插件化架构结合Protobuf、Arrow和DataFusion技术。其中，Selection Vectors是向量化查询引擎过滤操作的两种表达方式之一（另一种是Bitmap），它通过存储被选中数据的下标来提高效率。项目实现了Java与Rust层的交互：Java侧的CometSelectionVector封装原始数据和选中下标，并通过Arrow格式传输到Rust层；Rust侧通过JNI接口获取这些数据，利用Da

本文分析了Apache Datafusion Comet项目中Rust Native端的指标更新机制。该机制通过Spark插件架构，利用Protobuf序列化和Arrow数据交换，将DataFusion执行引擎的指标反馈到JVM端。核心实现包括：1)通过JNI获取CometMetricNode实例；2)递归收集DataFusion物理计划的metrics数据；3)使用Protobuf编码为二进制；4)调用JNI方法将指标传输到JVM端。指标包括输出行数、计算耗时等，最终会显示在Spark UI中。该设计实现

本文分析了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算子offload到Rust实现的DataFusion引擎执行。核心组件包括：Spark插件（Driver/Executor）、Protobuf序列化、Arrow数据交换和DataFusion执行引擎。本文分析了CometSparkSessionExtensions中的向量化规则转换流程，重点剖析CometExecRule如何将Spark物理计划转换为Native计划。转换过程包括：表达式归一化处理

本文分析了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和堆外内存都

StarRocks索引存储结构摘要 StarRocks支持多种索引机制，各索引的存储位置和层级有所不同： 主键索引存储在persistent_index/目录的.pkindex文件中，是Tablet级全局索引；前缀索引和ZoneMap索引共存于segment_xxx.idx文件，是Segment级附属索引；Ordinal索引内嵌于.idx文件；Bloom Filter和Bitmap索引分别存储在独立的col_xxx.bloom和col_xxx.bitmap文件中。所有索引均可持久化，查询时可加载到内存缓存加

文章摘要： 向量化技术利用SIMD指令实现数据并行处理，相比SISD串行处理可显著提升性能。列存储更适合向量化处理，因其数据局部性强、SIMD指令优化效果好、I/O操作少且压缩率高。而行存储存在缓存命中率差、转换开销大、压缩效率低等问题。现代处理器通过扩展指令集和增加寄存器宽度来支持向量化计算，与列存储相结合可大幅提升数据分析查询效率。（149字）

本文基于Flink 1.17.0分析其内存管理机制与BinaryRowData优化。Flink同时使用堆内内存（存储用户对象和运行时数据）和堆外内存（包括网络通信用的直接内存和RocksDB等第三方库用内存），均通过MemorySegment封装，并提供不同分配方法。BinaryRowData设计可减少GC压力、降低内存占用及序列化开销。此外，MemorySegment通过判断系统字节序（大小端）确保数据在网络传输和持久化时的正确解析，保障数据处理一致性。

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

本文对比了Starrocks 3.5中开启和关闭点查（short circuit）功能时的查询性能差异。测试使用包含主键条件的查询语句，结果显示开启点查后查询总时间从14ms降至6ms。主要优化体现在：1）优化器仅执行RBO规则处理；2）调度步骤简化，跳过完整的PipelineDriver调度流程；3）执行时间从6.773ms缩短至857.455us，直接通过节点获取数据。点查功能通过减少优化步骤和简化执行流程显著提升了简单主键查询的性能。

本文介绍了Starrocks 3.5.5中TRACE命令的使用方式，支持TIMES/VALUES/LOGS/ALL等模式，并可指定BASE/MV/OPTIMIZER等模块。在ConnectProcessor.handleQuery中通过Tracers.init初始化指定模块，仅记录选定模块的指标信息（如OPTIMIZER模块的任务执行时间），避免保留所有模块数据导致FE内存过高引发OOM。这种设计通过模块化跟踪机制有效控制了内存使用。

本文分析了Starrocks中SQL性能分析的四种方法：Query Profile、EXPLAIN ANALYZE、ANALYZE PROFILE和trace。Query Profile提供最详细的执行指标，包括BE端信息但重启后丢失；EXPLAIN ANALYZE展示简化执行计划；ANALYZE PROFILE提供更丰富的执行指标；trace则专注于特定规则耗时。通过解析SQL语法树和执行流程，文章详细说明了各方法的实现机制，其中Query Profile通过FE-BE交互收集运行时数据，而EXPLAIN

本文分析了Starrocks 3.3.5中的点查(ShortCircuit)优化机制。点查通过跳过复杂的优化器和调度流程，直接向BE节点请求数据，相比常规查询节省了DAG构建、任务部署等时间。文章指出，在行存模式下点查只需通过PK获取单行数据，而列存模式则需要从不同列块中获取并组装数据，因此效率较低。调度机制方面，Starrocks默认采用Pipline调度，并行度参数随引擎模式切换而变化。代码分析显示，点查直接进入ShortCircuit路径，而常规查询还需经历prepareExec和deliverExe

本文基于Paimon 0.9源码分析了主键表的部分更新和DeleteVector实现机制。部分更新通过MergeTreeWriter的SortBufferWriteBuffer和PartialUpdateMergeFunction实现，按主键+sequenceNumber排序后合并更新字段。DeleteVector在Compaction时生成，通过"Compaction+lookup"机制标记需要删除的记录，仅支持主键表且为bucket级别。核心逻辑集中在MergeTreeWriter的

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格式。每种类型都通过特定字节组合标识类型和存储内容，采用小端

本文基于StarRocks 3.3.5版本，分析了全局字典优化中涉及的两个关键规则：AddDecodeNodeForDictStringRule和LowCardinalityRewriteRule。该优化主要针对低基数字符串列，将其改写为整型列以提高查询性能。规则通过自底向上方式遍历物理计划树，在Scan、Filter、Agg等操作中应用字典优化，并在必要时插入decode节点还原原始字符串。文章详细解读了AddDecodeNodeForDictStringRule的实现逻辑，包括优化开关检查、表类型判断、

RoaringBitmap是高效压缩位图，简称RBM，它的原理是将 32bit int（无符号的）类型数据 划分为 2^16 个桶，即2^16=65536个桶，每个桶内用container来存放一个数值的低16位

本文基于Starrocks 3.3.5版本分析了物化视图的原子性更新机制。研究显示，Starrocks通过Insert Overwrite方式实现物化视图更新：首先创建临时分区写入数据，最后通过加锁操作原子性地替换分区。分析核心流程发现，在doCommit阶段会对表加写锁（LockType.WRITE），确保分区替换操作的原子性，而数据写入阶段不加锁以保证性能。这种设计既保证了数据一致性（不存在读取中间状态），又维持了高QPS场景下的稳定响应时间（RT）。元数据操作仅在最终替换时短暂加锁，使整个更新过程高效

本文分析了Starrocks 3.3.5版本中算子代价计算机制，重点关注StatisticsCalculator类对三种核心算子的统计信息估算方法： Scan算子：从CachedStatisticStorage获取表行数和列统计信息，处理分区剪枝，并通过谓词分析进一步优化统计估算。 Filter算子：直接继承子节点的统计信息，不进行额外计算。 Projection算子：基于子节点统计信息，通过表达式分析估算新生成列的统计值。 研究表明，Starrocks采用自顶向下的统计信息估算方法，大部分统计值都是通过近

本文分析了Starrocks 3.3.5版本中统计信息的收集机制。统计信息通过周期性运行SQL语句（以分区为维度）进行收集，并存储在_statistics_.column_statistics表和GlobalStateMgr.CachedStatisticStorage中，供后续基于CBO的代价计算使用。统计信息的收集由StatisticAutoCollector类管理，默认调度周期为5分钟。收集过程包括调度时间检查、统计表状态检查、初始化默认任务和运行采集任务。任务运行时会根据配置和表健康度决定是否进行全

本文总结了大数据场景下实时写入更新策略的演进，重点分析了COW、MOR和Delete+Insert三种技术策略。Starrocks的主键表通过Delete+Insert策略优化了实时更新和查询效率，避免了MOR策略中的读放大问题。在写入时，Starrocks利用主键索引和DelVector标记删除数据，更新操作则转换为Delete+Insert，确保数据一致性。读取时，仅需查询主键索引，避免了历史数据的合并操作，提升了查询性能。此外，谓词和索引的下推进一步减少了数据扫描量。总体而言，Starrocks的主键

本文基于Starrocks 3.3.5版本，探讨了如何在FE端实现短路径查询以加速点查速度。用户需将enable_short_circuit设置为true以启用该功能。通过ShortCircuitPlanner.checkSupportShortCircuitRead方法判断SQL是否支持短路径查询，该方法首先检查enable_short_circuit是否启用，然后通过LogicalPlanChecker判断SQL操作是否支持短路径。目前，仅支持Scan、Project、Filter和Limit操作。对于

其中 balanceClusterDisk balanceClusterTablet balanceBackendDisk balanceBackendTablet 分别对应上述的1 2 3 4 四点。最近在研究了一下 Starrocks的tablet的Rebalance的能力，这里进行记录一下。其中里面设计到的移动都是以 tablet Replica（副本）为单位进行移动的，,而最终的信息是来源于 BE和 FE进行交互的。本文基于 StarRocks 3.3.5。的统计信息，这个是来自于。