只是甲的博客

那么此时可以这么理解，当集群处于空闲时，突然来了一个任务，那么此时因为所有container的优先级相同，优先选择的就是本节点的container，而第一个container 用于启动作业的AM进程，这也就对应了之前的，chd10节点申请AM会比其他节点多很多。从图中可以看出，每个节点的HDFS空间是相同的，大多节点HDFS使用量在40%左右，而出问题的这个节点居然直逼80%，鉴于之前问题出现过多次，且每次都是利用空余时间使用HDFS的rebalance进行解决的，此处需要找出具体问题，规避此类问题。

近期需要进行补录数据，需要将hive的历史数据迁移到StarRocks，因为需要补录的数据较多，hive和StarRocks均使用的是分区表，两边的日期格式也不同，hive这边是 yyyymmdd格式，StarRocks这边是yyyy-mm-dd格式。之前一直是使用DataX来从hive导入到StarRocks，因为DataX是单节点的，而hive和StarRocks是分布式的，所以这个性能其实一般，而且DataX配置json确实有点麻烦。

找了下官网，没有发现绑定变量相关的文档，只有一个类似MySQL在查询中使用变量的方法，感觉目前 还不能解决当前的问题。

（既不能是spark.zip 也不能是spark-24.zip, 需要在配置文件中写死为 spark-2x.zip）没想到打包名字居然是写死的，而且hive catalog居然受到spark 客户端的影响。现在需要使用hive外表，然后根据官网的的命令创建了hive resource。StarRocks的committer在论坛回复我了，原来是打包的问题。spark jar 打包名字需要是 spark-2x.zip。StarRocks版本 2.5.5。

使用Spark 2.4.0客户端会报错，java.lang.NoClassDefFoundError: org/slf4j/Logger。（既不能是spark.zip 也不能是spark-24.zip, 需要在配置文件中写死为 spark-2x.zip）看StarRocks lib下面使用的是Spark 2.4.6版本的jar包。然后spark_launcher_log下压根就不打印日志。spark jar 打包名字需要是 spark-2x.zip。于是使用Spark 2.4.6版本的客户端。

hive的一些默认参数设置不适合一些复杂的数据需求场景，需要针对具体情况进行调整。

公司的离线数仓是CDH集群，19个节点，HDFS存储空间大约400TB左右，使用量在200TB左右。由于历史遗留的问题，数据仓库需要重构，新旧数仓在一段时间内需要并存，此时HDFS空间救不够了。Kafka出了问题，选主过程受到ZK的影响，导致生产者写的时候找不到主节点，进而导致数据丢失。于是申请增加6个节点，每个节点挂20T的存储，累积给HDFS增加120TB左右空间。(这还是HDFS rebalance执行了一天多的时候的截图)新增加节点与旧节点之间数据分布不均匀。

公司有一个hadoop的集群。但是A项目组经常做一些定时的BI报表，B项目组则经常使用一些软件做一些临时需求。那么他们肯定会遇到同时提交任务的场景，这个时候到底如何分配资源满足这两个任务呢？是先执行A的任务，再执行B的任务，还是同时跑两个？以Capacity 调度为例。

我们需要求每一个start_date的累积数量，那么此时我们可以先求每天的，然后求每天累积的，再求当天每一个start_date累积的，加上前一日的累积的，就是最终我们需要的数据。就算数据量提升数倍，因为 join的条件由一个 data_source 变为了两个 data_souce 、dt，大大减少了笛卡尔积的数据量，整个代码的计算量也减少了许多。同样的逻辑，表连接的方式居然就可以了，而分析函数却不行，估计一个是写内存，一个是写磁盘把。将数据倾斜严重的数据，单独拿出来执行。最终的运行时间在5分钟左右。

后面把order by子句注释掉之后，居然就可以了，那么就是order by 后面不能跟聚合函数了。一个很简单的group by和count(*) 操作，然后居然报错了。大概是在Oracle MySQL上写SQL写习惯了，以为可以这么写。于是使用了聚合函数的别名，问题搞定。出了问题也是不知道从何排查。

但是实际情况是 table_b 居然是扫描了 5kw数据后，在于table_a 进行join，table_a 通过关联字段 与 table_b 进行join，然后再进行group by。table_a 10W 左右数据，通过where条件过滤数据后 剩下 10行数据。table_b 5亿左右数据，通过where过滤条件后 剩下 5kw 数据。table_b join后其实只剩下少量的数据，进行聚合运算，应该也不会太慢。通过explain查看了执行计划，发现了table_b 访问的行数太多了。

CPU解析SQL生成执行计划，需要依赖统计信息，如统计信息正在收集中，那么此时CPU会等待统计信息收集完成或采用动态采样。可以看到，慢查询里面，CPU用于解析SQL生成执行计划的时间非常长，远高于实际执行的时间。从下图我们可以看到列的统计信息是此次新增的，要收集所有存量表的列的统计信息，耗时较久。从普罗米修斯上看到，集群CPU资源使用率不高，也就不存在资源的瓶颈。后面想到了，新版本的统计信息会有新增，那我们来看看统计信息。升级完成后，所有的查询均比较慢，前端报表页面点开也卡。

因为StarRocks也属于mysql的生态，而且使用的是mysql 5.1的版本。在DBeaver上执行某些SQL语句的时候，直接报 unknown error。奇怪的是我直接用命令行连接没报错，可以正常运行成功。那么此时问题就是DBeaver这个工具的问题了。将驱动降到5.1版本，重新测试，SQL运行正常。然后我们看看DBeaver使用的驱动的版本。是最新的8.0.29的。

因为Hive不支持XML数据格式，后端写入数据库存的是一个String类型，此时格式就没那么规范了，会有一些特殊字符。遇到不懂的问题，首先上官方文档查询相关文档，然后照着官网的demo改改，一般就能解决问题了。今天接到一个新需求，hive表里面有个字段存储的是XML类型数据。丰富的XML相关函数及测试用例。

这种非等值连接，不能写在on子句，只能写在where子句后面，那么此时的问题就是连个表的关联变成笛卡尔积了，产生的数据量太大了，而且笛卡尔积是全局的，所以只有一个reduce，执行进程上看，reduce进度一直卡在99%不动。那么此时我们需要的是人工的给两个表一个join条件，避免只有一个reduce操作。顺便指定一下reduce的个数，以免hive自动判断的reduce数发生错误。今天遇到一个问题，一个大表join 一个拉链表，获取对应的数据。优化后，执行时间由之前的18分钟，优化到4分钟左右。

今天跑一个MR任务，数据量不大，跑了半个小时左右，遇到了超时的报错。

因为本身是离线数据，此时可以借助临时表，首先把每个用户首次访问的时间记录下来，这样就可以将处理的数据大大减少，最后再通过开窗函数处理即可。一般一个reduce处理的数据是1G，所以首先想能不能增加reduce的个数来调优上述Hive SQL。SQL也是因为 count(distinct)的存在，导致reduce数分配少了，进而出现数据性能问题。上述SQL所代表的业务逻辑是求截止当前每分钟的用户访问数(如出现多次，只算一次)经验证，调整了上述参数后，问题依旧没有得到解决。

因为数据已经同步到了Hive，Spark SQL默认可以读取Hive表的数据，所以可以直接进行操作。

如果是整个yarn-session异常，也可以启动yarnsession的时候指定checkpoint。在网上看到的资源都是针对代码级别的，没有看到Flink SQL级别的。对于一些大表，最好还是先通过Spark进行初始化，然后在接增量。把yarn-session的资源由8G提升到16G问题解决。在Flink web界面将Flink SQL任务手工结束掉。Flink可以自己重试，这个还是比较不错，无需人工干预。等mysql启动成功之后，任务又可以继续衔接上。看来是我的checkpoint都没成功。

如果是生产环境，可以指定一个较高的并行度，我这个地方因为是测试环境，并行度指定为1。内存尽量多指定，不然会包 OOM的错误。

索引 index 是判断数据重复的核心数据结构， index.state.ttl 设置了索引保存的时间， 默认 1.5 天，对于昌时间周期的更新， 比如更新一个月前的数据，需要将 index.state.ttl 调大(单位 天)， 设置小于0代表永久保存。Merge On Read 默认开启了异步的compaction，策略是 5 个 commits 压缩一次， 当条件满足会触发压缩任务，另外，压缩本身因为耗费资源，所以不一定能跟上写入效率，可能有滞后。，我还以为是提示错误，后来想想也不至于，然后想到。

异步的 clustering 相对于 online 的 async clustering 资源隔离， 从未更加稳定。仍然保持开启，由写任务阶段性出发 clustering plan。为 false，关闭在线 clustering。推荐由写定时出发，写参数。

hudi

从 0.11 开始支持默认的flink 流式 写入使用 state 存储索引信息: primary key 到 fileID 的映射关系。当数据量比较大的时候， state的存储开销可能成为瓶颈， bucket 索引通过固定的 hash 策略， 将相同 key 的数据分配到同一个 fileGroup 中，避免了索引的存储和查询开销。

Hudi写入模式

Hudi离线批量写入

hudi常用参数

Hudi元数据同步到Hive

Hudi元数据持久化

Hudi集成hive

Flink 与 Hudi 类型映射

Flink CDC 实时将MySQL数据写入到Hudi

Flink 流式插入

Flink SQL操作Hudi表Flink Hudi集成

Flink 集成 Hudi

Spark SQL操作Hudi

pyspark 操作Hudi

Spark 集成 Hudi

Hudi读写流程

Hudi核心概念