monkeyboy_tech的博客

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

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

最近公司在做一些业务上的架构调整，有一部分是数据从mysql采集到Starrocks，之前的一套方法是走debezium到puslar到starrocks,这一套下来比较需要配置很多东西，而且出现问题以后，需要修改很多配置，而且现阶段问题比较多，且采集的是所有线上的数据库，维护起来很费劲。于是我们进行了采集的数据流调整，使用 Flink CDC这一套，这一套 是端到端的，且采用配置化的方式，支持schema的变更，无需再多一层中间存储层。

这里主要就是解析 yaml文件，以及根据source sink构建 pipeline并生成 filnk DataStream 任务 ，这种方式和 flink SQL的方式很像，只不过 SQL方式 是 解析SQL形成对应的flink DataStream任务。但是以上几种方式都是得写SQL或者写代码实现，这种是要一定的专业知识和门槛的，恰好 FLink CDC 提供了一种yaml文件配置化的方式来降低这种门槛，不需要掌握专业知识就能够进行快速的进行数据传输的工作，在此分析一下 Flink CDC的整个流程。

其中涉及到的 变量为 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的方式进行交互的，所以这种方式相对来说还是会比较慢的。

通过本文的分析大致可以了解到在Starrocks的FE端是如何进行Command的交互以及数据流走向，其他的命令也是可以举一反三。和Spark以及hive等但是解析一样，StarRocks也是采用的Anltr4进行语法的解析，对应的java数据结构，但是一条SQL从客户端发送过来，是怎么一个数据流呢？操作的时候，就会根据执行的长短进行超时处理了。整体的数据流就结束了，待在同一个连接中进行。获取设置的超时时间，如果超时，则调用。中了，后续的流程和之前的一致。这种情况的解析，是通过。就会在语法层面解析为。

该方法，该方法是用来把表示涉及的属性，给映射到对应的计划的属性值上，这样我们计算的时候，就可以获取到对应的值，一般是调用。这里会涉及到两个ROW的转换，两个ROW的 Schema 是不一致的，如果要涉及到两个ROW之间的转换的时候，而且。的值，所以get(0)是 GenericRowWithSchema类型的ROW，也就是ROW类型。， 前者是 Spark 内部的使用的一行数据的表示，后者是给Spark开发者使用的行数据表示。可执行表达式，最最终绑定到表的特定属性上，从而获取对应的值。

这会导致shuffle后的数据进行了错位（因为之前是shuffle(200),现在变成了shuffle(10)），具体原因笔者还是没有分析清楚，但是其中涉及到的点跟规则。从以上的分析知道：是在做join的一方(包含了AQEshuffleRead-coalesced) 影响了join的另一方，导致。目前在做 Spark 升级(3.1.1升级到3.5.0)的时候，遇到了。导致的数据重复问题，这种情况一般来说是很少见的，因为一般很少用。会做一些执行前的判断，主要是做任务shuffle的协调，

因为原则上来说，如果没有开启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写hive表有两种形式，一种是基于 Hive 原生的模式，一种是Spark native datasource的模式, 这两种模式可以通过配置的参数。方法的过程，尤其如果说是已存在的hive表有百万分区的话，很容易造成。，该方法会从把hive中的properties的信息传给。，这个方法如果对于分区数比较多的情况下是比较耗时的，而且。对于第一种原生的hive写入方式来说，最终调用的是。中的方法,里面采用的是spark自身的进行写入。中的方法,而这里面的都是采用。本文基于Spark 3.5。

这种情况下，在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），则会加上。

两个同样的 ShuffleExechange 记录条数和 ShuffleExechange 中 datasize 大小不一样，而在BroadcastExechange 中 dataSize 大小却是一样的（都是64.5MB）而该size的大小并不是实际占用的大小，而是分配给该dataPage的大小。中的是 MemoryBlock 类型数据结构所占的大小 ，而不是UnsafeRow的大小。中的datasize大小 和 2的整数倍接近。中的是真实 UnsafeRow的大小。的大小几乎和2的倍数接近。