monkeyboy_tech的博客

大家都知道对于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的方式进行交互的，所以这种方式相对来说还是会比较慢的。