鸿乃江边鸟-优快云博客

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

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

2025-04-03 18:32:22 811

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

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

2025-03-28 18:12:15 479

原创 Starrocks 命令 Alter table DISTRIBUTED 重分布数据的实现

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

2025-03-19 22:29:47 344

原创 Starrocks 写入报错 primary key memory usage exceeds the limit

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

2025-02-28 17:21:19 345

原创 StarRocks FE leader节点CPU使用率周期性的忽高忽低问题分析

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

2025-02-21 07:11:25 908

原创 StarRocks 怎么让特定的SQL路由到FE master节点的

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

2025-01-18 08:24:53 580

原创 StarRocks关于ConcurrentModificationException 问题的解决

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

2024-12-03 19:00:21 709

原创 Flink CDC 使用实践以及遇到的问题

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

2024-11-27 18:04:42 1588 1

原创 Flink CDC 源码解析--整体流程

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

2024-11-14 12:44:35 1207

原创 Starocks中的一致性检查ConsistencyChecker

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

2024-11-06 21:34:00 1136

原创 Starrocks Compaction的分析

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

2024-11-05 21:35:30 1360

原创记一次 Flink mongoDB CDC 到Kafka遇到的问题

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

2024-10-13 20:26:58 1442 1

原创 Flink SQL中怎么注册python以及使用python注册的UDF中数据流是怎么流转的

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

2024-10-07 15:18:05 722

原创 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的方式进行交互的，所以这种方式相对来说还是会比较慢的。

2024-10-04 17:33:46 744

原创 StarRocks 中如何做到查询超时(QueryTimeout)

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

2024-10-01 15:48:51 1380

原创 Spark关于 ExpressionEncoder[T] 以及 RowEncoder 以及Spark怎么做外部数据和内部数据的转换

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

2024-06-05 16:49:29 812 1

原创记一次Spark cache table导致的数据问题以及思考

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

2024-05-22 19:54:53 520

原创 Spark AQE 导致的 Driver OOM问题

因为原则上来说，如果没有开启AQE之前，一个SQL执行单元的是属于同一个Job的，开启了AQE之后，因为AQE的原因，一个Job被拆成了了多个Job，但是从逻辑上来说，还是属于同一个SQL处理单元的所以还是得归属到一次执行中。类在内存中存放着一个整个SQL查询链的所有stage以及stage的指标信息，在AQE中一个job会被拆分成很多job，甚至几百上千的job，这个时候 stageMetrics的数据就会成百上倍的被存储在内存中，从而导致。主要的作用是设置当前计划的所属的。该方法会获取事件中的。

2024-04-26 22:39:30 1483 3

原创 Spark Rebalance hint的倾斜的处理(OptimizeSkewInRebalancePartitions)

假如说hash(col)为0，那实际上只有reduceTask0有数据，其他的ReduceTask1等等都是没有数据的，所以最终只有ReduceTask0写文件，并且只有一个文件。这些值配置，如果这些配置调整的不合适，就会导致写文件的时候有可能只有一个Task在运行，那么最终就只有一个文件。的作用是对小文件进行拆分，使得罗盘的文件不会太大，这个会有个问题，如果我们在使用。的作用主要是进行文件的合并，是得文件不会太小，本文基于Spark 3.5.0。的值是固定的，比如说值永远是。

2024-03-21 09:05:55 1370 1

原创 Spark中InsertIntoHiveTable 和 InsertIntoHadoopFsRelationCommand(两种写hive的方式)区别和注意的点

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

2024-03-08 17:14:41 1310

原创关于Spark中OptimizeShuffleWithLocalRead 中自己的一些理解

这种情况下，在Spark的内部表示 ShuffleOrigin 为 REBALANCE_PARTITIONS_BY_NONE，这种情况下是hint为。这里的条件默认是根据shuffle的个数来计算的，如果优化后的shuffle数有增加，则会回退到之前的物理计划中去，当然用户也可以配置。针对第二种情况，这种情况一般来说都是有正向的提升效果的，但是也会经过第一种情况的逻辑判断。规则下，有可能会增加额外的Shuffle操作，这种情况就是负优化了，所以在进行了。的作用简单的来说，就是会按照一定的规则，从一个。

2024-03-06 22:58:52 906

原创 Spark中读parquet文件是怎么实现的

因为对于Spark来说，任何一个事情都不是独立的存在的，比如说parquet文件的rowgroup设置的大小对读写的影响，以及parquet写之前排序对读parquet的影响，以及向量化读取等等。为‘true’(默认就是true)，则会进行unsafeRow的转换，当然这里的好处就是节约内存以及能够减少GC。最近在整理了一下 spark对Parquet的写文件的过程，也是为了更好的理解和调优Spark相关的任务，这条filter，则只会拿出rowgroup的信息和rowgrups的的行数。

2024-03-04 20:27:22 1206

原创 Spark中写parquet文件是怎么实现的

的时候得注意不能调整过大，否则会导致OOM，但是如果在最后写文件的时候加入合并小文件的功能（AQE+Rebalance的方式），也可以适当的调整大一点，因为这个时候的Task 不像没有shuffle一样，可能还会涉及到sort以及aggregate等消耗内存的操作，（这个时候就是一个task纯写parquet文件）这三个配置项存在着相互制约的关系，总的目标就是检查当行数达到了一定的阈值以后，来检查是否能够flush到内存page中，具体的可以查看。表示的是partition名字的常量。

2024-02-22 22:53:08 1556

原创 Spark中多分区写文件前可以不排序么

会根据partition或者bucket作为最细粒度来作为writer的标准，如果相邻的两条记录所属不同的partition或者bucket，则会切换writer，所以说如果不根据partition或者bucket排序的话，会导致。频繁的切换，这会大大降低文件的写入速度。目前 Spark中的实现中，对于多分区的写入默认会先排序，这是没必要的。至于Spark在写入文件的时候会加上Sort，这个是跟写入的实现有关的，也就是。这两个物理计划中，最终写入文件/数据的时候，会调用到。（默认值为0），则会加上。

2024-02-15 22:30:11 1097

原创 Spark UI中 Shuffle Exchange 和 BroadcastExchange 中的 dataSize 值为什么不一样

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

2024-01-22 20:54:41 923

原创 Spark在降本增效中的一些思考

这也是笔者一直在关注的项目，根据 TPC-H 测试结果显示起码有2倍的性能提升，但是实际效果还是得看SQL的pattern。但是由于目前我们的Spark 是基于 3.5.0的，是比较新的版本，而社区这块的融合还在继续，所以这块今年应该可以行动起来,可以参考。注意：我们批集群的CPU利用率在60%以上，引入zstd以后会增加CPU的使用率，而且在这种 long running的服务下，得增加。,但是这里请注意一点，该问题的提出点是基于 HDD 类型的磁盘的，因为我们现在是基于。

2024-01-19 09:03:16 1205

原创 Spark 中 BroadCast 导致的内存溢出(SparkFatalException)

这个问题折腾了我大约2个小时，错误发生的上下文都看了不止十遍了，还是没找到一丝头绪，可能是上帝的旨意，在离错误不到50行的地方，对于一个在大数据行业摸爬滚打了多年的老手来说，第一眼肯定是跟着堆栈信息进行排查，目前在排查 Spark 任务的时候，遇到了一个很奇怪的问题，在此记录一下。在查找错误的时候，还是得在错误的上下文中多翻几页。这个类，但是就算把代码全看一遍也不会有所发现。，没想到是 OOM 问题。理所当然的就是会找到。

2024-01-08 17:57:35 1272

原创 Spark Paimon 中为什么我指定的分区没有下推

针对于错误的写法,也就是导致读取全量数据的写法，我们分析一下，首先是类型转换阶段，在Spark中，对于类型不匹配的问题，spark会用规则进行转换，具体的规则是。最近在使用 Paimon 的时候遇到了一件很有意思的事情，写的 SQL 居然读取的数据不下推，明明是分区表，但是却全量扫描了。这种情况下，对于文件的读取IO会增大，但是对于shuffle等操作是不会有性能的影响的。对于分区字段来说，我们在写SQL对分区字段进行过滤的时候，保持和分区字段类型一致。可以看到经过了规则转换所有的过滤条件都下推到了。

2023-12-14 18:02:27 922

原创 Spark升级中对log4j的一些思考

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

2023-11-27 23:25:11 1568

原创 Spark调优案例分享

注意是Mac Keynote。

2023-11-13 20:15:49 965

原创 Apache Arrow优点

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

2023-11-10 16:31:16 350

原创 Spark UI中Shuffle dataSize 和shuffle bytes written 指标区别

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

2023-10-27 07:38:47 866

原创 Flink 中kafka broker缩容导致Task一直重启

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

2023-10-12 11:28:35 1301

spark调优案例分享

空空如也