monkeyboy_tech的博客

本文基于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” 阶段完成的。是常量，所以能够裁剪到对应的分区中去，而。在优化算子阶段就已经计算出来了,为。在计划优化阶段就可以计算出结果。函数的 只选择了一个分区的数据。

经过分析我发现我们这边的分区是以月维度划分的，而且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任务后，会构建当前的。

是用来Flink用来产生CDC数据的,Flink SQL Planner 会自动为 Upsert 类型的 Source 生成一个 ChangelogNormalize 节点，并按照上述操作将其转换为完整的变更流；所以这里我们选择把 kakfa的数据转换成的正常的 数据流，而不是CDC数据，因为我们最终存储的 Adb 是可以支持upsert操作。这里获取到的数据就是 正常的json数据，而不是 debezium-json数据，具体区别，可以参考下面的说明。，因为我们现在选择 kafka sink的是。

所以说 Flink SQL 调用 python UDF 还是采用了 Py4j ，这种方式也是采用了进程间通信的方式，在效率上还是比不了基于 java/scala 而写的UDF，这种方式和Spark SQL中怎么注册python以及使用python注册的UDF中数据流是怎么流转的类似。

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