monkeyboy_tech的博客

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。的统计信息，这个是来自于。

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

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

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

job 放入要执行的队列中，之后SchemaChangeHandler 以 alter_scheduler_interval_millisecond （10000ms）的轮询间隔从队列中取出要执行的任务，并调用。SchemaChangeHandler.process 会把当前的。来改变数据的分布状态,具体的执行过程是怎么样的呢？

经过分析我发现我们这边的分区是以月维度划分的，而且bucket的个数为2，这样每次写入数据的时候，就会把一个月的的数据的索引加载到内存中，这样就会导致BE的内存占用越来越大，除此之外，我们的业务场景就是会 更新 以往 的历史数据，且这样类似的任务有很多。我们的表结构是主键表。在Flink Yaml CDC 任务往 Starrocks写数据的过程中，突然遇到了。本文基于 StarRocks 3.3.5。可以通过如下命令查看 索引所占用的内存。所以我们进行了bucket调整，内存占用节约了5GB。

最近在做一些 StarRocks 相关的指标监控的时候，看到了FE master的CPU使用率相对其他FE节点是比较高的，且 呈现周期性的变化（周期为8分钟），于此同时FE master节点的GC频率相对于其他节点高出很多倍，于是我们利用arthas采集了大约15分钟CPU的火焰图。所以说在这种要收集的分区信息很多的情况下，HashMap的初始化，就很消耗CPU。这里会对里面涉及到的所有对象进行内存的评估，用来后续的内存使用指标显示。这种方法收集每个分区中某些字段的信息,这里后续会详细说。

大家都知道对于Starrocks来说FE是分master和follower的，而只有master节点才能对元数据进行写操作。,也就是会重定向到FEmaster节点。这其中的原因在网上是搜不到的，所以大家只知道。本文基于StarRocks3.1.7。

然而在查询的时候, Starrocks会做语法解析，以及基于CBO的优化，在这期间会统计涉及到的表的分区信息统计，而此时恰好遇到了后台线程的分区删除，导致了。阶段，这个阶段由于默认情况下是基于CBO的优化，所以会统计涉及的表所扫描的数据量,最终会走到。StarRocks 对分区带有TTL的表，会后台启动线程轮询的去删除分区，轮询的间隔受到。方法，进而生成物理执行计划，而在生成物理执行计划的阶段，会经过。这个后台线程进行分区的删除。对于这种带有TTL的分区表来说，会有。中就会删除正在进行查询迭代的。

其中涉及到的 变量为 consistency_check_end_time consistency_check_start_time 以及 MAX_JOB_NUM。把任务提交到后端的backend中去执行,主要代码在。AgentBatchTask.run方法中。本文基于Starrocks 3.1.7。

如果是失败任务的话，还会记录到failHistory中，并会重新进行Compaction的任务的延迟提交（延迟间隔为LOOP_INTERVAL_MS*10，其中LOOP_INTERVAL_MS 为200ms）中，并会重新进行Compaction的任务的延迟提交（延迟间隔为LOOP_INTERVAL_MS*2，其中LOOP_INTERVAL_MS 为200ms）注意： 这个命令只是修改了当前内存中的变量的值，如果需要永久的修改，需要配置到。处理完正在运行的Compaction任务后，会构建当前的。

因为原则上来说，如果没有开启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 问题。理所当然的就是会找到。

最终我们只留下了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),

优点采用连续的内存布局，在单机计算的时候，增加操作系统友好性，增加了缓存命中率以及采用列式存储，在单机计算的时候，可以利用SMID向量化处理，并且增加了查询效率（一般查询的时候只是查询几列）采用列式存储，IPC进程间通信传输的时候，提高了压缩率采用零拷贝，IPC进程间通信传输的时候，减少了数据传输的开销跨语言的标准化规范，消除了各个格式之间转换所需要的序列化和反序列化的时间以上优点实现了高速的数据传输和处理能力，使得它在大数据场景下有很好的优化价值参考Apache Arrow: 数据工

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

（默认30000），这两个参数来控制kakfa的客户端从服务端请求超时，也就是说每次请求的超时时间是30s，超时之后可以再重试，如果在60s内请求没有得到任何回应，则会报。这里做的事情就是从持久化的State中恢复kafkaTopicOffset信息,我们这里假设是第一次启动。获取到要提交的kafka offset信息，并持久化保存kafka中。在Flink中对于Kafka的Connector的。，这里我们只讨论kafka作为source的情况，方法会被调用，所有kafka相关的操作都可以追溯到。

首先是反序列化CleanPlan,然后在进行清理，主要是删除1. 如果没有满足的分区，直接删除该分区，2. 否则删除该分区下的满足条件的文件,最后返回。HoodieFlinkMergeOnReadTable*类型的hudi表,用来做clean等操作。,也就是在写数据失败的时候，会立即进行这次写失败的数据的清理，在这种情况下，创建一个只有一个线程的线程池，改线程池的主要作用来异步执行hudi写操作。本文主要是具体说说Flink中的clean操作的实现。真正执行clean的部分，主要是调用。

该计划的差异主要部分还是在于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的时候会把临时目录的文件真正的移到需要写入的目录下。

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

来说，什么也不操作（因为该index每次都会从parquet文件中读取信息从而组装成index），构建一个状态信息，主要是记录一下插入的记录数量和更新的记录数量 其中主要形成了以。（默认是true）会进行元数据的commit操作，这些commit的操作和之前。，则会要求排序，如果没有则只是按照partitioner进行重分区，（这里暂时忽略），主要是对数据进行分区处理，设计到小文件的处理。操作，所以没有去重的需要，所以直接采用spark原生的方式，实例的构造方法中会进行一些额外的操作。

并且从*.hoodie/20230530073115535.deltacommit* 获取internalSchemaOpt，具体的合并就是把即将写入的schema和internalSchemaOpt进行合并。因为是"bulk insert"操作，所以没有去重的需要，所以直接采用spark原生的方式，把df的schema转换成avro的schema。），则会进行去重处理，具体是调用。开始写操作，这涉及到回滚的操作。，就会进行schema的合并。是没有的，所以不会开启异步的。

目前hudi的与spark的集合还是基于spark datasource V1来的，这一点可以查看。之前说到只有获取到分布式锁的线程才可以继续一下操作。后续发现也是基于Datasource V2的。

spark full outer join目前存在一个问题，那就是在数据倾斜的时候，会导致Execuotr OOM：具体的问题描述，可以见。

支持update，支持upsert（merge），具体看类IcebergSparkSqlExtensionsParser.replaceRowLevelCommands。分区是隐藏的，在查询时不需要添加关于分区的筛选条件，建表的时候指定分区的来源（由哪个字段计算而来）Iceberg有catalog的概念，是对表进行管理(create，drop等)的一个组件。需要额外的服务治理小文件,额外的服务清理过期的snapshot。支持多种存储，如 S3，oss，HDFS 等。支持 flink sql upsert。

其中cachedLeafDirToChildrenFiles的值会在InMemoryFileIndex对象初始化的时候进行赋值，对应的方法为。那是因为，在一个jvm中，比如说是写了之后再读取，会进行。的情况下，在转换对应的逻辑计划当中，如果缓存中存在对应的表，则会复用缓存中的，具体的方法在。的错误，这种错误的原因有一种隐形的原因，那就是。在scan file的过程中，最主要涉及的是。对象，从而实现了文件的复用，从未导致问题。会缓存需要scan的文件在内存中，中 ，最主要的点是会公用同一个。