自定义博客皮肤VIP专享

*博客头图:

格式为PNG、JPG,宽度*高度大于1920*100像素,不超过2MB,主视觉建议放在右侧,请参照线上博客头图

请上传大于1920*100像素的图片!

博客底图:

图片格式为PNG、JPG,不超过1MB,可上下左右平铺至整个背景

栏目图:

图片格式为PNG、JPG,图片宽度*高度为300*38像素,不超过0.5MB

主标题颜色:

RGB颜色,例如:#AFAFAF

Hover:

RGB颜色,例如:#AFAFAF

副标题颜色:

RGB颜色,例如:#AFAFAF

自定义博客皮肤

-+
  • 博客(222)
  • 收藏
  • 关注

原创 Spark Datafusion Comet 向量化Rust Native--CometShuffleExchangeExec怎么控制读写

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

2026-02-06 09:46:54 307

原创 Spark Datafusion Comet 向量化Rust Native--Native算子(CometNativeExec)怎么串联执行

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

2026-02-04 09:17:04 827

原创 Spark Datafusion Comet 向量化Rust Native--执行Datafusion计划

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

2026-02-03 09:13:23 954

原创 Spark Datafusion Comet 向量化Rust Native--创建Datafusion计划

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

2026-02-02 11:09:19 894

原创 Spark Datafusion Comet 向量化Rust Native--读数据

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

2026-01-30 09:10:57 817

原创 Spark Datafusion Comet 向量化Rust Native-- 数据写入

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

2026-01-28 14:43:23 717

原创 Spark Datafusion Comet 向量化Rule--CometExecRule分析 规则转换分析

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

2026-01-26 11:27:10 623

原创 Spark Datafusion Comet 向量化Rule--CometExecRule Shuffle分析

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

2026-01-20 08:27:24 757

原创 Spark Datafusion Comet 向量化Rule--CometScanRule分析

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

2026-01-16 11:25:14 609

原创 Spark Datafusion Comet 向量化--ApplyColumnarRulesAndInsertTransitions规则

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

2026-01-15 14:59:07 598

原创 Spark datafusion comet向量化插件CometPlugin

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

2026-01-14 11:10:37 651 1

原创 Apache Arrow的零拷贝是指什么

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

2026-01-14 09:26:39 476

原创 Spark native向量化组件 datafusion comet

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

2026-01-13 10:44:12 418

原创 Java 序列化和Scala的闭包的区别和注意点

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

2025-10-22 21:00:58 444

原创 StarRocks 各类索引以及存储位置详解

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

2025-09-22 21:48:11 1466

原创 向量化和列式存储

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

2025-09-15 21:09:19 495

原创 Flink中的 BinaryRowData 以及大小端

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

2025-09-08 20:53:48 426

原创 Spark中的堆外和堆内内存以及内部行数据表示UnsafeRow

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

2025-09-04 23:07:11 1143

原创 记录一下 StarRocks 点查的 Profile Metrics

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

2025-08-15 09:27:37 495

原创 谈谈SQL计算存储引擎中的索引和计算

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

2025-08-08 07:18:26 857

原创 Starrocks 关于 trace 命令的说明

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

2025-08-05 21:21:31 376

原创 Starrocks中的 Query Profile以及explain analyze及trace命令中的区别

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

2025-08-05 19:50:43 1263

原创 Starrocks ShortCircuit短路径的调度

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

2025-08-03 15:53:53 524

原创 Paimon中BloomFilter在key查找中的应用

本文分析了Paimon 0.9.0中BloomFilter的构造与使用机制。在构造方面,通过bfGenerator方法根据行数和误判率动态计算位数组大小和哈希函数数量,使用MemorySegment管理位数组内存。在使用方面,通过LookupLevels.createLookupFile将键值写入BloomFilter,并采用MurmurHash计算哈希值,最终通过BitSet设置对应位。整个过程实现了高效的空间占用和快速查询验证,为Paimon的查找操作提供了性能优化。

2025-07-27 09:57:56 775

原创 Paimon的部分更新以及DeleteVector实现

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

2025-07-23 21:49:40 1315

原创 Spark 4.0的 VariantType 类型优点以及使用分析

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

2025-07-09 07:02:53 531

原创 Spark 4.0的VariantType 类型以及内部存储

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

2025-07-03 19:39:16 1166

原创 Starrocks 低基数全局字典优化

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

2025-06-24 21:33:39 889

原创 Starrocks中RoaringBitmap杂谈

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

2025-06-04 19:28:24 1109

原创 Starrocks 物化视图的实现以及在刷新期间能否读数据

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

2025-05-29 13:33:42 1040

原创 Starrocks 怎么计算各个算子的统计信息

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

2025-05-24 07:19:15 621

原创 Starrocks的CBO基石--统计信息的来源 StatisticAutoCollector

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

2025-05-22 19:29:59 1274

原创 Starrocks的主键表涉及到的MOR Delete+Insert更新策略

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

2025-05-13 18:34:17 929

原创 Starrocks 的 ShortCircuit短路径

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

2025-05-09 16:48:19 1449

原创 Starrocks 数据均衡DiskAndTabletLoadReBalancer的实现

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

2025-04-18 18:03:08 745

原创 Chainlit 快速构建Python LLM应用程序

chainlit 是一款简单易用的Web UI goggle,它支持使用 Python 语言快速构建 LLM 应用程序,提供了丰富的功能,包括文本分析,情感分析等。鉴于国内需要VPN访问openai的模型问题, 我们以 chainlit + deepseek(openai) 的方式进行演练。这里面的 api_key 用你在deepeeek 申请到的 api_key替换即可。提供的例子,快速的开发一个带有UI的聊天界面,且支持MCP方式。,对于api的调用的话,这里也提供了一些。接下来就可以进行交互了。

2025-04-16 08:06:53 598

原创 快速部署大模型 Openwebui + Ollama + deepSeek-R1模型

提供了用户友好的 AI 界面(支持 Ollama、OpenAI API 等),且能够支持多种大模型,我们可以部署除了deepseek以外的其他模型,可以很方便的在模型之间切换等功能。是一个开源的本地化大模型部署工具,提供与OpenAI兼容的Api接口,可以快速的运行大模型服务,我们用他来部署deepseek。本文主要快速部署一个带有web可交互界面的大模型的应用,主要用于开发测试节点,其中涉及到的三个组件为。上的模型为例进行演示,运行如下命令就会下载并运行deepseek-r1模型。在这里可以进行提问了。

2025-04-15 18:14:54 607

原创 Starrocks的Bitmap索引和Bloom filter索引以及全局字典

写这个的主要作用是梳理一下Starrocks的索引效率以及使用场景。

2025-04-09 19:45:58 1191

原创 Spark中排序--前缀排序prefixSort

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

2025-04-03 18:32:22 1239

原创 StarRocks 中 CURRENT_TIMESTAMP 和 CURRENT_TIME 分区过滤问题

方法中, 具体的实现,可以细看 PartitionPruneRule对应的方法,也就是在这个规则里会对涉及到的谓词来过滤出对应的分区,很显然因为。至于 PartitionPruneRule 则会在“Optimizer” 阶段完成 ,也就是。函数不支持常量折叠,也就是不支持在计划解析和优化阶段来计算结果。以上的 都在 “Transformer” 阶段完成的。是常量,所以能够裁剪到对应的分区中去,而。在优化算子阶段就已经计算出来了,为。在计划优化阶段就可以计算出结果。函数的 只选择了一个分区的数据。

2025-03-28 18:12:15 893

spark调优案例分享

spark的调优案例分享

2023-11-13

空空如也

TA创建的收藏夹 TA关注的收藏夹

TA关注的人

提示
确定要删除当前文章?
取消 删除