gitweixin
  • 首页
  • 小程序代码
    • 资讯读书
    • 工具类
    • O2O
    • 地图定位
    • 社交
    • 行业软件
    • 电商类
    • 互联网类
    • 企业类
    • UI控件
  • 大数据开发
    • Hadoop
    • Spark
    • Hbase
    • Elasticsearch
    • Kafka
    • Flink
    • 数据仓库
    • 数据挖掘
    • flume
    • Kafka
    • Hive
    • shardingsphere
    • solr
  • 开发博客
    • Android
    • php
    • python
    • 运维
    • 技术架构
    • 数据库
  • 程序员网赚
  • bug清单
  • 量化投资
  • 在线查询工具
    • 去行号
    • 在线时间戳转换工具
    • 免费图片批量修改尺寸在线工具
    • SVG转JPG在线工具

分类归档大数据开发

精品微信小程序开发门户,代码全部亲测可用

  • 首页   /  
  • 分类归档: "大数据开发"
Spark 7月 7,2025

Spark Shuffle的优化

Spark Shuffle 是连接不同 Stage 的关键环节,也是 Spark 作业中最容易产生性能瓶颈的地方之一。它涉及大量磁盘 I/O、网络传输和内存使用。优化 Shuffle 对提升作业性能和稳定性至关重要。以下是一些关键的 Spark Shuffle 优化策略:

核心目标: 减少 Shuffle 数据量、降低 I/O 开销、提升网络传输效率、优化内存使用、处理数据倾斜。

主要优化策略:

  1. 减少 Shuffle 数据量 (根本之道):
    • Map-Side 预聚合/Combining: 在 Shuffle 写之前,尽可能在 Mapper 端对数据进行聚合(combineByKey, reduceByKey, aggregateByKey)。这能显著减少需要传输的键值对数量。优先使用 reduceByKey/aggregateByKey 而不是 groupByKey。
    • 选择更高效的算子: reduceByKey 优于 groupByKey + reduce;treeReduce/treeAggregate 在聚合深度大时优于 reduce/aggregate(减少网络轮次)。
    • 过滤数据: 尽早使用 filter 过滤掉不需要参与 Shuffle 的数据。
    • 列裁剪: 只选择 Shuffle 后真正需要的列(尤其是在使用 DataFrame/Dataset API 时)。避免传输整个对象。
    • 避免不必要的 distinct: distinct 会触发 Shuffle。考虑是否可以用其他方式(如 Map 端去重)或在更小的数据集上使用。
    • 广播小表: 如果 Join 操作中一个表很小,使用 broadcast 将其分发到所有 Executor,避免大表 Shuffle。spark.sql.autoBroadcastJoinThreshold 控制自动广播的阈值。
  2. 优化 Shuffle 写:
    • 调整 spark.shuffle.file.buffer: 增加 Shuffle 写过程中每个分区文件的内存缓冲区大小(默认 32K)。增大此值(如 64K, 128K)可以减少磁盘 I/O 次数,但会增加内存压力。需权衡。
    • 调整 spark.shuffle.spill.diskWriteBufferSize: 增大溢出到磁盘时使用的缓冲区大小(默认 1024K),同样减少写磁盘次数。
    • 启用 spark.shuffle.unsafe.file.output.buffer: 对于使用 Tungsten 的 Shuffle,设置这个直接内存缓冲区大小(默认 32K),作用类似 spark.shuffle.file.buffer。
    • 优化 spark.shuffle.spill: 确保 spark.shuffle.memoryFraction 或 spark.memory.fraction 设置合理,为 Shuffle 分配足够内存,减少溢出次数。监控 GC 和溢出情况。
    • 选择高效的 Shuffle 实现:
      • Sort Shuffle (sort): Spark 1.2+ 的默认方式。对每个分区排序并合并小文件。通常最稳定高效。
      • Tungsten-Sort (tungsten-sort): 基于 Project Tungsten,使用堆外内存和更高效的编码。在 Spark 1.4+ 可用,有时性能更好(尤其处理原始类型时)。通常当 spark.shuffle.manager=sort 且满足条件(序列化器支持重定位、非聚合 Shuffle 等)时会自动使用。
    • 文件合并 (spark.shuffle.consolidateFiles): (在较新 Spark 版本中已被优化或默认行为替代) 在老版本中启用此选项可以让多个 Reduce Task 共享同一个 Mapper 输出的合并文件,减少小文件数量。新版本 Sort Shuffle 本身已优化文件数量。
  3. 优化 Shuffle 读:
    • 调整 spark.reducer.maxSizeInFlight: 控制每次 Reduce Task 从远程 Executor 拉取数据的最大大小(默认 48M)。增大此值(如 96M)可以提高吞吐量,但会增加内存使用。需监控网络和内存。
    • 调整 spark.shuffle.io.maxRetries 和 spark.shuffle.io.retryWait: 网络不稳定时,增加重试次数和等待时间以避免 Fetch Failed 错误。但过度重试会拖慢作业。
    • 调整 spark.shuffle.io.numConnectionsPerPeer: 如果集群节点很多且网络是瓶颈,适当增加此值(默认 1)可以提升并发连接数。
    • 启用 spark.shuffle.compress: (默认开启) 压缩 Shuffle 数据(写和读)。使用高效的压缩算法:
      • spark.io.compression.codec: 推荐 lz4(速度快)或 zstd(压缩率高,速度也不错)。snappy 是默认值,也是不错的选择。避免使用低效的 lzf。
    • 调整 spark.shuffle.service.enabled: 启用 External Shuffle Service。这允许 Executor 在退出后(如动态资源分配下)Shuffle 文件仍能被访问,提高稳定性。通常在生产环境推荐启用。
  4. 调整分区数量:
    • 关键参数 spark.sql.shuffle.partitions (SQL/DataFrame/Dataset): 控制 Shuffle 后(如 Join, Aggregation)的分区数(默认 200)。这是最重要的优化点之一。
      • 分区过少: 每个分区数据量过大 -> 可能导致 OOM、GC 时间长、Task 执行慢、无法充分利用集群资源。
      • 分区过多: 每个分区数据量过小 -> Task 调度开销增大、产生大量小文件、网络请求次数增多(影响 Shuffle 读)。
      • 如何调整: 根据集群总核心数和数据量估算。经验值通常是集群总核心数的 2-3 倍。例如,集群有 100 个 Executor,每个 4 核,总核心数 400,可设置为 800 – 1200。需要根据实际作业数据量和执行情况(查看 Spark UI 中的 Shuffle Read Size/Records)反复调整测试。 数据量极大时可设置更高。
    • RDD API: repartition/coalesce: 在 RDD 操作中显式控制分区数。
  5. 处理数据倾斜:
    • 识别倾斜: 通过 Spark UI 查看各 Stage 中 Task 的执行时间分布。执行时间显著长于其他 Task 的通常处理了倾斜的分区。查看 Shuffle Read Size 差异。
    • 缓解策略:
      • 过滤倾斜 Key: 如果极少数倾斜 Key 可以单独处理或过滤掉。
      • 加盐打散: 给倾斜的 Key 添加随机前缀(扩容),在局部聚合后去掉前缀再全局聚合。
      • 提高并行度: 增加 spark.sql.shuffle.partitions,让倾斜 Key 分散到更多分区(对于单个 Key 数据量特别大的情况效果有限)。
      • 使用 skew join 优化 (Spark 3.0+ AQE): 自适应查询执行 (AQE) 能自动检测倾斜 Join 并将倾斜的分区分裂成更小的子分区进行处理。强烈推荐启用 AQE (spark.sql.adaptive.enabled=true)。
      • 特定算子: reduceByKey 比 groupByKey 更能容忍一定程度的倾斜(因为 Map 端合并了)。对于 Join 倾斜,考虑广播小表或使用 SortMergeJoin/ShuffleHashJoin 的替代方案。
  6. 利用自适应查询执行:
    • 启用 AQE (spark.sql.adaptive.enabled=true): Spark 3.0+ 的核心优化特性。
      • 动态合并 Shuffle 分区: 根据 Shuffle 后实际数据大小,自动将过小的分区合并,避免大量小 Task 的开销。
      • 动态调整 Join 策略: 在运行时根据统计信息将 SortMergeJoin 切换为 BroadcastJoin(如果发现小表符合广播条件)。
      • 动态优化倾斜 Join: 自动检测并处理 Shuffle Join 中的数据倾斜问题。
    • 相关参数: spark.sql.adaptive.coalescePartitions.enabled, spark.sql.adaptive.coalescePartitions.minPartitionNum, spark.sql.adaptive.advisoryPartitionSizeInBytes, spark.sql.adaptive.skewJoin.enabled, spark.sql.adaptive.skewJoin.skewedPartitionFactor, spark.sql.adaptive.skewJoin.skewedPartitionThresholdInBytes 等。强烈建议在生产环境中启用并适当配置 AQE。
  7. 硬件与集群配置:
    • 使用 SSD: 将 Shuffle 溢出目录 (spark.local.dir) 配置到 SSD 磁盘上能极大提升 Shuffle 写/读的 I/O 性能。这是非常有效的优化。
    • 充足内存: 确保 Executor 有足够内存(spark.executor.memory),特别是当 spark.memory.fraction 分配给 Storage 和 Execution(包含 Shuffle)时。减少溢出到磁盘的次数。
    • 高速网络: 万兆甚至更高带宽、低延迟的网络能显著加速 Shuffle 数据传输。
    • 合理 CPU 核数: 避免单个 Executor 分配过多 CPU 核(如 > 5),因为多个 Task 竞争磁盘/网络 I/O 可能成为瓶颈。通常每个 Executor 配置 3-5 核是一个较好的平衡点。

优化流程建议:

  1. 监控与诊断: 使用 Spark Web UI 仔细分析作业运行情况。重点关注:
    • Shuffle Read/Write 的总数据量和在各 Stage/Task 上的分布。
    • Task 的执行时间分布(识别倾斜)。
    • GC 时间。
    • 是否有溢出到磁盘 (Spill (Memory), Spill (Disk))。
    • Shuffle Write Time / Shuffle Read Time。
    • 日志中的 WARN/ERROR 信息(如 FetchFailed, OOM)。
  2. 定位瓶颈: 根据监控信息判断是数据量太大、I/O 慢、网络慢、内存不足还是数据倾斜。
  3. 应用策略: 针对性地选择上述优化策略进行调整。优先考虑减少数据量和调整分区数。
  4. 迭代测试: 修改配置或代码后,在小规模数据或测试集群上运行测试,观察效果。每次最好只修改一个主要配置,以便定位效果。
  5. 利用 AQE: 确保在 Spark 3.x 环境中启用并配置好 AQE,它能自动处理很多棘手的优化问题(小分区合并、倾斜 Join)。

Spark Shuffle 优化原则

类别优化建议
算子选择使用 reduceByKey 代替 groupByKey,选择合适的 Join
分区策略控制合理的并发度、分区数,避免极端数据倾斜
参数调优内存、缓冲区、网络传输参数细致设置
数据倾斜通过打散、随机 key、局部聚合等方式规避热点 key
AQE开启 Spark SQL 的自适应执行,自动处理 Join/倾斜问题
文件合并启用 consolidateFiles 降低磁盘负担
作者 east
Hive 7月 1,2025

hive sql行转列,列转行sql的实例

在 Hive SQL 中,行转列和列转行是常见的数据转换操作。以下是详细说明和示例:

一、行转列(多行转多列)

场景:将同一分组下的多行数据合并为单行,不同值转为新列(如学生各科成绩横向展示)。

数据示例 (student_scores):

student_idsubjectscore
1Math90
1English85
2Math92

目标(每个学生一行,科目成绩转为列):

student_idMathEnglish
19085
292NULL

SQL 实现:

SELECT
  student_id,
  MAX(CASE WHEN subject = 'Math' THEN score END) AS Math,
  MAX(CASE WHEN subject = 'English' THEN score END) AS English
FROM student_scores
GROUP BY student_id;

关键点:

  1. 使用 CASE WHEN 按条件生成新列
  2. 用聚合函数(如 MAX/MIN/SUM)确保单行输出
  3. 必须配合 GROUP BY 分组字段

二、列转行(多列转多行)

场景:将单行的多列数据拆分为多行(如将横向科目成绩转为纵向记录)。

数据示例 (student_scores_wide):

student_idMathEnglish
19085
292NULL

目标(恢复为行式存储):

student_idsubjectscore
1Math90
1English85
2Math92
2EnglishNULL

SQL 实现:

SELECT student_id, 'Math' AS subject, Math AS score 
FROM student_scores_wide
UNION ALL
SELECT student_id, 'English' AS subject, English AS score 
FROM student_scores_wide;

优化方案(使用 LATERAL VIEW explode(),Hive 特有):

SELECT student_id, subject, score
FROM student_scores_wide
LATERAL VIEW explode(
  map(   -- 构建科目-分数的键值对
    'Math', Math,
    'English', English
  )
) subjects AS subject, score;

关键点:

  1. UNION ALL 适合列数量固定的场景
  2. LATERAL VIEW + explode(map) 动态处理多列
  3. 注意处理 NULL 值(Hive 中 NULL 会正常保留)

三、高级用法:动态行列转换

当列名不固定时(如新增科目),需结合 Hive 动态 SQL 或预处理:

  1. 行转列动态化:
    使用 collect_list + 拼接字符串,再通过 UDF 解析(较复杂,通常需借助外部脚本生成 SQL)。
  2. 列转行动态化:
    通过 Hive 元数据获取列名,动态生成 UNION ALL 语句(示例略,需依赖 Hive 变量或编程接口)。

总结对比

操作核心方法适用场景
行转列CASE WHEN + 聚合函数 + GROUP BY固定列名,聚合统计
列转行UNION ALL 或 LATERAL VIEW explode列数量少或需动态处理

提示:Hive 3.0+ 支持 LATERAL VIEW inline(array_of_structs),但需先构造结构体数组。实际使用时请根据数据规模和复杂度选择合适方案。

作者 east
doris 6月 17,2025

修复启动Doris BE报错:Please set vm.max_map_count to be 2000000 under root using ‘sysctl -w vm.max_map_count=2000000’.

启动 Doris BE 时出现的系统检查报错提示,明确指向 Linux 系统参数配置问题。报错内容如下:

Please set vm.max_map_count to be 2000000 under root using 'sysctl -w vm.max_map_count=2000000'.

这意味着当前系统的 vm.max_map_count 参数值过小。Doris BE 运行时需要大量内存映射操作(尤其在高并发或列存储文件较多的场景下),该参数至少需设置为 2000000,否则可能因内存映射区域分配失败导致启动异常。

一、错误原因解析

vm.max_map_count 是 Linux 内核参数,用于限制单个进程可创建的内存映射区域数量(如 mmap 调用)。不同系统默认值存在差异:

  • Ubuntu 通常默认值为 65530
  • CentOS 常见默认值为 65536
    这些默认值远无法满足 Doris BE 的运行需求。

二、临时解决方案(快速生效但重启失效)

通过命令行直接修改运行时参数:

sudo sysctl -w vm.max_map_count=2000000

此操作会立即调整内存参数,但系统重启后配置会丢失,适用于急需启动服务的场景。

三、永久性解决方案(推荐方案)

通过修改配置文件实现重启后持续生效,操作步骤如下:
1. 编辑系统配置文件
使用文本编辑器打开 /etc/sysctl.conf:

sudo vim /etc/sysctl.conf

在文件末尾添加参数配置:

vm.max_map_count=2000000

保存并退出编辑器。
2. 应用配置使修改生效
执行命令加载新配置:

sudo sysctl -p

若未提示错误,说明配置已成功应用。

四、验证配置是否生效

可通过两种方式检查参数是否修改成功:
1. 使用 sysctl 命令查询

sysctl vm.max_map_count

正常输出应为:

vm.max_map_count = 2000000

2. 查看系统参数文件

cat /proc/sys/vm/max_map_count

若输出值为 2000000,则表示配置已生效。
完成以上操作后,重新启动 Doris BE 服务即可正常运行。编辑分享


作者 east
Docker 6月 12,2025

docker服务器:connect to host cdh04 port 22: No route to host 分析并解决

🔍 一、排查思路总览

  1. 确认目标主机(cdh04)是否运行正常
  2. 确认目标主机的 Docker 容器是否运行并绑定了 SSH 端口
  3. 确认网络配置是否通
  4. 确认 SSH 服务是否正常监听并运行
  5. 确认防火墙和安全组设置

🧪 二、详细排查步骤

✅ 1. Ping 主机名是否能通(DNS or Hosts 问题)

ping cdh04 
  • 如果提示:ping: unknown host cdh04
    • 说明主机名无法解析,检查 /etc/hosts 或 DNS。
  • 如果提示:Destination Host Unreachable
    • 说明网络层面有问题,继续往下查。

✅ 2. 确认是否为 Docker 容器内部主机

如果你是用 Docker 模拟 CDH 集群,那么 cdh04 可能是某个容器的别名。可通过以下命令确认:

docker ps -a | grep cdh04 

如果找不到:

  • 容器可能没有启动;
  • 容器网络未配置正确;
  • 或者该容器已崩溃。

可用以下命令查看网络:

docker network ls docker network inspect <网络名> 

✅ 3. 检查容器是否监听 22 端口

进入宿主机,检查容器绑定端口:

docker inspect cdh04 | grep -A 5 "PortBindings" 

确认是否有:

"22/tcp": [   {     "HostPort": "2222"   } ] 

表示你需要用 ssh -p 2222 用户名@宿主机IP 才能访问,而不是直接 ssh cdh04。


✅ 4. 检查 SSH 服务是否运行

进入容器:

docker exec -it cdh04 bash 

确认:

ps -ef | grep sshd 

如果没有:

service ssh start 

或者:

/etc/init.d/ssh start 

还可以查看日志:

cat /var/log/auth.log 

✅ 5. 容器网络是否正常(重要)

查看容器网络是否被桥接成功:

docker network inspect bridge 

容器是否有 IP:

docker inspect -f '{{range.NetworkSettings.Networks}}{{.IPAddress}}{{end}}' cdh04 

从宿主机 ping 容器 IP:

ping <容器IP> 

如果 ping 不通,可以尝试重启容器网络:

systemctl restart docker 

或使用:

docker network rm <网络名>  # 慎用,确认后使用 docker network create ... 

✅ 6. 防火墙与安全设置

查看 iptables(或 firewalld)是否阻拦了:

iptables -L -n | grep 22 

或者:

systemctl status firewalld 

临时关闭测试:

systemctl stop firewalld iptables -F 

💡 三、常见问题与建议

问题原因解决方式
No route to host宿主机到容器路由不通检查容器网络、端口映射
Connection refused容器未运行 SSH 服务或未监听 22 端口启动 ssh 服务,检查监听端口
ping 不通容器Docker 网络异常重建 docker 网络或检查 bridge 网络配置
容器无法被主机名访问/etc/hosts 缺失或 DNS 配置错误添加主机映射或使用容器 IP
作者 east
doris 6月 10,2025

Doris FE配置中的自动恢复选项

Doris FE 的自动恢复功能主要通过 ​​metadata_failure_recovery​​ 配置项实现,用于在元数据异常或集群脑裂时恢复 FE 的元数据一致性。以下是具体配置和使用方法:


​​1. 配置参数说明​​

  • ​​参数位置​​:在 FE 的配置文件 fe.conf 中添加或修改以下参数:properties复制metadata_failure_recovery=true
  • ​​作用​​:
    • ​​启用元数据恢复模式​​:清空本地 BDBJE 的元数据存储,尝试从其他节点恢复最新元数据。
    • ​​适用场景​​:FE 无法正常启动(如元数据损坏、脑裂)、集群失去 Master 节点等。

​​2. 不同场景下的配置方法​​

​​场景 1:单节点 FE 故障​​

  • ​​操作步骤​​:
    1. 在 fe.conf 中添加 metadata_failure_recovery=true。
    2. 重启 FE:sh bin/start_fe.sh --daemon。
    3. 恢复成功后,移除该配置或设置为 false,避免后续自动触发恢复8。

​​场景 2:多节点 FE 故障(需手动选择 Master)​​

  1. ​​定位最新元数据节点​​:
    • 检查所有 FE 的 meta_dir/image 目录,找到 image.xxxx 中数字最大的节点(元数据最新)8。
  2. ​​恢复 Master​​:
    • 在最新元数据节点的 fe.conf 中添加 metadata_failure_recovery=true。
    • 重启 FE,观察日志确认是否成功切换为 Master(日志中出现 transfer from XXXX to MASTER)6。
  3. ​​清理其他节点​​:
    • 删除旧 Master 和其他 Follower:ALTER SYSTEM DROP FOLLOWER "IP:PORT";。
    • 重新添加 Follower:ALTER SYSTEM ADD FOLLOWER "IP:PORT";8。

​​场景 3:Observer 节点恢复​​

  • ​​特殊处理​​:
    • 若 Observer 的元数据最新,需先修改 meta_dir/image/ROLE 文件,将 role=OBSERVER 改为 role=FOLLOWER。
    • 按 Follower 恢复流程操作,避免角色不一致问题。

​​3. 版本差异​​

  • ​​Doris ≥2.0.2​​:支持命令行参数直接启用恢复模式:
  • sh bin/start_fe.sh --metadata_failure_recovery --daemon
  • ​​Doris <2.0.2​​:需在 fe.conf 中添加 metadata_failure_recovery=true。

​​4. 注意事项​​

  1. ​​仅限紧急恢复​​:恢复模式会清空本地元数据,需确保其他节点元数据可用。
  2. ​​恢复后操作​​:
    • 恢复成功后必须移除 metadata_failure_recovery 配置,否则下次重启会再次触发恢复。
    • 检查集群状态:SHOW FRONTENDS; 确认所有节点状态正常。
  3. ​​脑裂风险​​:恢复过程中可能产生脑裂,建议在操作前备份元数据目录(fe/doris-meta)4。

​​5. 预防措施​​

  • ​​高可用部署​​:建议配置 3 个 Follower 或 1 Follower + 1 Observer,避免单点故障7。
  • ​​定期备份​​:通过 BACKUP 命令或 Doris Manager 定期备份元数据。
  • ​​监控告警​​:使用 Doris Manager 或第三方工具监控 FE 状态,及时触发恢复流程4。
作者 east
海豚调度器 5月 30,2025

海豚调度器3.x版本解决创建文件夹时提示未指定当前登录用户的租户”的问题

在 海豚调度器 DolphinScheduler 3.x 中,出现提示:

“未指定当前登录用户的租户”

这是因为 当前登录用户没有绑定租户信息(Tenant),而 DolphinScheduler 在资源操作(如创建文件夹、提交任务等)时必须绑定租户,以便在后台进行资源隔离和权限控制。


一、问题成因分析

海豚调度器的核心概念之一是 租户(Tenant)。每个用户在执行任务时都必须以某个租户身份来进行资源调度。

在 DolphinScheduler 3.x 中:

  • 每个用户需要 绑定一个默认租户。
  • 如果没有绑定租户,进行资源操作(如资源中心上传、目录创建)时就会报错。

二、解决步骤

✅ 步骤1:登录系统,进入租户管理

  1. 使用 admin 用户登录 DolphinScheduler Web UI。
  2. 进入菜单:[安全中心] -> [租户管理]。
  3. 创建一个租户,例如:
    • 租户编码:default_tenant
    • 描述:默认租户

注意:租户编码实际对应 Linux 上执行任务的系统用户,需与服务器用户对应。


✅ 步骤2:为用户分配租户

  1. 进入菜单:[安全中心] -> [用户管理]
  2. 找到你的目标用户,点击 编辑。
  3. 在编辑用户界面,将 租户 设置为刚刚创建的租户 default_tenant。
  4. 保存设置。

✅ 步骤3:重新登录或刷新页面

分配租户之后,用户需要重新登录或刷新浏览器,以使绑定关系生效。


✅ 步骤4:重新尝试资源中心操作

现在再尝试在资源中心创建文件夹、上传资源等操作,应不会再出现“未指定当前登录用户的租户”的提示。

作者 east
doris 5月 22,2025

doris的动态分区,可以yyyy-MM这种年月格式的日期格式来做为分区吗

Doris 的 动态分区(dynamic partition) 默认支持的分区字段格式是 标准的 DATE 或 DATETIME 类型,但你提到的 yyyy-MM(即只有年月,没有日)的格式属于不完整日期(非标准 DATE 类型),不能直接用作分区字段。

但可以通过 以下方法间接实现以年月为粒度的分区。


✅ 一、推荐方式:使用 DATE 字段 + 动态分区,按月分区

虽然不能直接用 yyyy-MM,但你可以用 DATE 类型字段(例如 2024-05-01),然后通过 动态分区的 granularity 为 MONTH 的方式实现「按月分区」。

示例:

CREATE TABLE example_table (
id INT,
event_time DATE
)
DISTRIBUTED BY HASH(id) BUCKETS 10
PARTITION BY RANGE(event_time) ()
PROPERTIES (
"dynamic_partition.enable" = "true",
"dynamic_partition.time_unit" = "MONTH",
"dynamic_partition.start" = "-12",
"dynamic_partition.end" = "3",
"dynamic_partition.prefix" = "p",
"dynamic_partition.buckets" = "10",
"dynamic_partition.create_history_partition" = "true"
);

效果:

会自动创建如下分区:

分区名分区范围(event_time)
p202405[2024-05-01, 2024-06-01)
p202406[2024-06-01, 2024-07-01)

你在写入数据时,只需往 event_time 列写入标准的 DATE 类型值(如 2024-05-10),Doris 会自动路由到对应分区 p202405。


✅ 二、如果你的原始数据字段是 yyyy-MM 字符串格式

你需要:

  1. 在写入时用 SQL 转换成 DATE 类型;
  2. 或者使用视图或计算列。

示例:将 yyyy-MM 字符串转换为 DATE

-- 假设有个 staging 表字段是 "2024-05"
SELECT STR_TO_DATE(CONCAT(partition_ym, '-01'), '%Y-%m-%d') AS event_time
FROM staging_table;

然后写入主表中。


🚫 不推荐:直接使用字符串 yyyy-MM 作为分区字段

虽然技术上可以用 VARCHAR 字段做 RANGE 分区,但:

  • 无法使用动态分区功能(只支持 DATE/DATETIME 字段);
  • 不能使用时间函数做范围推导、自动创建分区等操作;
  • 写入和查询逻辑不直观、不易维护。
作者 east
大数据开发 4月 19,2025

执行sqoop报错 Unrecognized argument

具体错误如下:

25/04/15 12:16:39 ERROR tool.BaseSqoopTool: Unrecognized argument: --delete-target-dir
25/04/15 12:16:39 ERROR tool.BaseSqoopTool: Unrecognized argument: -m
25/04/15 12:16:39 ERROR tool.BaseSqoopTool: Unrecognized argument: 1
25/04/15 12:16:39 ERROR tool.BaseSqoopTool: Unrecognized argument: --split-by
25/04/15 12:16:39 ERROR tool.BaseSqoopTool: Unrecognized argument: id
25/04/15 12:16:39 ERROR tool.BaseSqoopTool: Unrecognized argument: --input-null-string
25/04/15 12:16:39 ERROR tool.BaseSqoopTool: Unrecognized argument: \\N
25/04/15 12:16:39 ERROR tool.BaseSqoopTool: Unrecognized argument: --input-null-non-string
25/04/15 12:16:39 ERROR tool.BaseSqoopTool: Unrecognized argument: \\N
25/04/15 12:16:39 ERROR tool.BaseSqoopTool: Unrecognized argument: --null-string
25/04/15 12:16:39 ERROR tool.BaseSqoopTool: Unrecognized argument: \\N
25/04/15 12:16:39 ERROR tool.BaseSqoopTool: Unrecognized argument: --null-non-string
25/04/15 12:16:39 ERROR tool.BaseSqoopTool: Unrecognized argument: \\N
25/04/15 12:16:39 ERROR tool.BaseSqoopTool: Unrecognized argument: --as-textfile
25/04/15 12:16:39 ERROR tool.BaseSqoopTool: Unrecognized argument: --fields-terminated-by
25/04/15 12:16:39 ERROR tool.BaseSqoopTool: Unrecognized argument: \001
25/04/15 12:16:39 ERROR tool.BaseSqoopTool: Unrecognized argument: --hive-delims-replacement
25/04/15 12:16:39 ERROR tool.BaseSqoopTool: Unrecognized argument:

报错信息表明 Sqoop 无法识别某些参数,实际原因是参数书写格式不正确,尤其是参数与参数值之间缺少必要的空格。以下是详细分析和改正建议:

此错误指明整个字符串被当作了一个参数,而不是把 --target-dir 和目录路径分开处理。这通常是由于缺少空格引起的。

其他错误(如 -m 1, --split-by id 等)也是由于在参数与其值之间没有按照预期格式分隔,或参数顺序不当导致参数解析出错。

注意 –query 参数中的问题

使用 --query 时需注意两点:

  • 必须包含 \$CONDITIONS 字符串,否则 Sqoop 无法生成分割条件。在你的查询里,应将条件追加上 AND \$CONDITIONS。
  • 例如: sqlCopyEdit--query "SELECT * FROM bigdata_iot_day WHERE day = '2025-03-24' AND \$CONDITIONS" 这里的 \$CONDITIONS 会在实际执行时被 Sqoop 替换为分片条件。
    注:在某些 shell 环境中可能需要对 $ 进行转义或者引用,确保在执行时 Sqoop 接收到正确字符串。

作者 east
Flink 4月 19,2025

两种Flink 生成水印的方案的对比

在开发中用到flink下面2种生成水印方式,它们优劣和适用场景如何。

方案1:
.assignTimestampsAndWatermarks(
        WatermarkStrategy
          .forBoundedOutOfOrderness[RunData](Duration.ofSeconds(5))
          .withIdleness(Duration.ofSeconds(5))
          .withTimestampAssigner(new SerializableTimestampAssigner[RunData] {
            override def extractTimestamp(element: RunData, recordTimestamp: Long): Long = {
              Math.max(element.getTime.longValue(), recordTimestamp)            
            }
          })
      ),

方案2:
.assignTimestampsAndWatermarks(
        WatermarkStrategy
          .forBoundedOutOfOrderness[RunData](Duration.ofSeconds(5))
          .withIdleness(Duration.ofSeconds(5))
          .withTimestampAssigner(new SerializableTimestampAssigner[RunData] {
            override def extractTimestamp(element: RunData, recordTimestamp: Long): Long = {
              element.getTime.longValue()      
            }
          })
      )


✅ 方案区别概述:

方案时间戳提取逻辑
方案1使用 Math.max(element.getTime, recordTimestamp) 取当前数据时间戳与 recordTimestamp 的较大值
方案2直接返回 element.getTime,不考虑 recordTimestamp

🧠 方案分析


🔹方案1:使用 Math.max(element.getTime, recordTimestamp)

✅ 优点:

  1. 更稳健处理乱序数据:
    • 如果 recordTimestamp(通常为前一条数据的时间戳)大于当前数据的时间戳,那么直接使用 element.getTime 会导致时间回退,从而影响 Watermark 计算,进而导致窗口触发不正确。
    • 该逻辑防止了 “时间倒退” 的现象。
  2. 适合数据源存在时钟漂移或乱序程度较高的情况:
    • 尤其是传感器数据、日志数据等不按顺序到达场景。
    • 若数据有一定延迟,选最大值可防止系统过早推进 Watermark。

❌ 缺点:

  1. 可能高估时间戳,导致 Watermark 滞后:
    • 如果 recordTimestamp 一直偏大,会导致 Watermark = 当前最大时间戳 - 允许延迟 总是处于偏后的状态,进而 延迟窗口触发时间,影响下游计算的实时性。
  2. 不太适用于严格顺序数据或延迟容忍低的场景:
    • 因为该策略会让窗口的计算始终比实际事件时间慢。

✅ 适用场景:

  • 数据存在明显乱序或可能存在时间回退的场景。
  • IoT 场景、传感器采集、日志采集系统。
  • 对准确性高于实时性的业务逻辑(如:统计分析类任务)。

🔹方案2:使用 element.getTime 直接提取时间戳

✅ 优点:

  1. 时间戳准确,还原数据本身的时间:
    • 直接以 数据本身时间 为准,更加符合事件时间语义。
    • 如果数据是有序或近乎有序的,它能够 精准推进 Watermark,使窗口 尽早触发。
  2. 低延迟,适合对实时性要求高的场景:
    • 例如实时告警系统、实时监控、业务中台。

❌ 缺点:

  1. 存在时间回退风险:
    • 如果某条数据时间比前面数据的还小,可能导致 Watermark 被“拉回”,系统可能拒绝处理这条数据或错误触发窗口。
  2. 依赖数据源严格有序性或 Watermark 容错时间足够长:
    • 对乱序不友好,需要配合合理的 forBoundedOutOfOrderness 延迟容忍时间。

✅ 适用场景:

  • 数据基本有序或有轻微乱序(容忍在 Duration.ofSeconds(5) 内)。
  • 实时性要求高的业务场景(如金融交易监控、实时用户行为处理)。
  • 数据源可靠性高(Kafka 的 event-time 顺序性高)。

✅ 总结对比表

项目方案1(Math.max)方案2(直接提取)
容错能力⭐⭐⭐⭐(强)⭐⭐(弱)
实时性⭐⭐(延迟高)⭐⭐⭐⭐(延迟低)
复杂数据处理⭐⭐⭐⭐⭐⭐
精确性(恢复事件时间)⭐⭐⭐⭐⭐⭐⭐
是否适合乱序数据是否(需轻度乱序)
场景推荐传感器、日志、数据分析实时告警、交易监控、行为分析

💡 建议:

  • 如果你对 数据顺序不确定、业务允许延迟:选 方案1。
  • 如果你 清楚数据较有序、实时性优先:选 方案2。
  • 两者都设置了 .withIdleness(Duration.ofSeconds(5)),意味着在数据空闲 5 秒内,Flink 会认为该 source 闲置,避免整个 Watermark 卡住 —— 这是对空数据源的一种保护机制,适合多 source 场景。

如果 用 Math.min(eventTime, recordTimestamp) 的效果是啥?

理论上的优势:

优势说明
✅ 防止因“异常大时间戳”推高 Watermark有些数据可能时间戳未来太远(如某个设备出错时间为2099年),使用 min 可以防止 Watermark 被拉得太靠前,导致后续正常数据全是迟到数据
✅ 更严谨处理数据乱跳若数据到达时间波动大,但我们只取历史最小时间戳推进,可以更“保守”处理

❌ 实际上的问题和风险:

问题说明
❌ 时间倒退严重如果 recordTimestamp 比当前数据早,就永远使用旧的时间,窗口不会推进,Watermark卡死
❌ Watermark 不会正常前进因为时间戳总是被压制成“更早的”,所以 Watermark 永远低于真实事件时间
❌ 数据无法被触发处理Flink 的窗口系统等 Watermark 过去“窗口边界”才会触发计算,这种写法可能导致窗口永远不触发,任务“看起来没问题但没产出”!
作者 east
运维 4月 18,2025

centos服务器如何查看是 x64(avx2)、x64(no avx2)还是arm64

要判断 CentOS 服务器 是 x86_64(支持 AVX2 / 不支持 AVX2) 还是 ARM64 架构,可以使用以下命令组合来精准确认架构类型及 AVX 指令集支持情况。


✅ 一、查看 CPU 架构(x86_64 vs aarch64)

bashCopyEdituname -m

输出示例:

  • x86_64 👉 表示是 Intel/AMD 架构(64位)
  • aarch64 👉 表示是 ARM 架构(64位 ARM)

✅ 二、进一步查看是否支持 AVX2 指令集

bashCopyEditcat /proc/cpuinfo | grep -m 1 flags

或者(更加清晰地只看 AVX 相关的):

bashCopyEditcat /proc/cpuinfo | grep -m 1 flags | grep -o 'avx[^ ]*'

如果输出中包含:

  • avx:支持 AVX
  • avx2:支持 AVX2
  • avx512f 等:支持 AVX-512(极少数高端 CPU)

✅ 三、使用 lscpu 更清晰(推荐)

bashCopyEditlscpu

输出示例中关注两行:

bashCopyEditArchitecture:        x86_64       # 架构
Flags:               ... avx avx2 ...  # 支持指令集

🧠 最终判断表格:

uname -mFlags 中包含 AVX2判断结果
x86_64有 avx2x64(支持 AVX2) ✅
x86_64无 avx2x64(无 AVX2)⚠️
aarch64–ARM64(不支持 AVX2)❌

🚀 快速一键命令总结:

bashCopyEditecho "架构: $(uname -m)"; lscpu | grep -i 'avx'
作者 east
Java 3月 31,2025

SpringBoot打包冲突导致找不到主类问题分析与解决

在Java开发中,使用Maven构建SpringBoot应用时,经常会遇到”找不到或无法加载主类”的错误。这个问题通常与打包配置有关,特别是当项目同时使用了多个打包插件时。本文将深入分析这一问题的原因和解决方案。

问题现象

当我们使用命令java -cp target/xxx-jar-with-dependencies.jar com.example.MainClass 运行应用时,出现以下错误:

错误: 找不到或无法加载主类 com.example.MainClass

这表明Java虚拟机无法在指定的JAR包中找到主类,即使该类确实存在于源代码中。

原因分析

1. SpringBoot打包机制与传统打包的冲突

SpringBoot应用使用spring-boot-maven-plugin 打包时,会将类文件放在BOOT-INF/classes 目录下,而不是传统JAR包的根目录。这导致使用-cp 参数指定类路径时,JVM无法在预期位置找到主类。

2. 多插件打包导致的结构混乱

当项目同时配置了spring-boot-maven-plugin 和maven-assembly-plugin 时,两个插件会各自执行打包逻辑,可能导致最终JAR包结构不符合预期。特别是,maven-assembly-plugin 可能无法正确处理SpringBoot的特殊目录结构。

3. 主类声明位置不正确

在Maven配置中,主类可以在多个位置声明:

  • spring-boot-maven-plugin 的<configuration><mainClass> 元素
  • maven-assembly-plugin 的<archive><manifest><mainClass> 元素
  • maven-jar-plugin 的<archive><manifest><mainClass> 元素
    如果这些配置不一致或缺失,可能导致生成的JAR包中没有正确的主类信息。

解决方案

1. 禁用SpringBoot重新打包功能

如果使用maven-assembly-plugin 创建包含依赖的JAR包,可以禁用SpringBoot的重新打包功能:

<plugin>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-maven-plugin</artifactId>
    <configuration>
        <skip>true</skip>
    </configuration>
</plugin>

2. 使用正确的运行命令

对于SpringBoot应用,应使用java -jar 命令而非java -cp 命令:

java -jar target/application.jar

3. 统一打包策略

选择一种打包策略并坚持使用:

  • 使用SpringBoot的打包机制:依赖spring-boot-maven-plugin
  • 使用传统打包:依赖maven-assembly-plugin 或maven-shade-plugin
    避免混合使用多种打包插件,以防止目录结构冲突。

4. 检查类路径和包名

确保源代码中的包名与Maven配置中声明的主类包名完全一致,包括大小写。同时,验证编译后的类文件确实存在于JAR包中的预期位置。

作者 east
bug清单, 运维 3月 23,2025

解决Error: /usr/lib64/libc.so.6: version `GLIBC_2.18′ not found

在centos运行node应用,分析下面报错并给出解决方案:node:internal/modules/cjs/loader:1282 return process.dlopen(module, path.toNamespacedPath(filename)); ^ Error: /usr/lib64/libc.so.6: version `GLIBC_2.18′ not found (required by /home/wwwroot/gitweixin/tool/svg2jpgApi/node_modules/canvas/build/Release/librsvg-2.so.2) at Object.Module._extensions..node (node:internal/modules/cjs/loader:1282:18) at Module.load (node:internal/modules/cjs/loader:1076:32) at Function.Module._load (node:internal/modules/cjs/loader:911:12) at Module.require (node:internal/modules/cjs/loader:1100:19) at require (node:internal/modules/cjs/helpers:119:18) at Object.<anonymous> (/home/wwwroot/gitweixin/tool/svg2jpgApi/node_modules/canvas/lib/bindings.js:3:18) at Module._compile (node:internal/modules/cjs/loader:1198:14) at Object.Module._extensions..js (node:internal/modules/cjs/loader:1252:10) at Module.load (node:internal/modules/cjs/loader:1076:32) at Function.Module._load (node:internal/modules/cjs/loader:911:12) { code: ‘ERR_DLOPEN_FAILED’

在CentOS上运行Node应用时遇到的GLIBC版本问题,可以通过以下步骤解决:

错误分析

  • 根本原因:应用依赖的canvas模块需要GLIBC_2.18,但当前系统的GLIBC版本过低(如CentOS 7默认使用GLIBC 2.17)。
  • 影响:系统缺失所需GLIBC版本,导致Node无法加载原生模块(librsvg-2.so.2)。

解决方案

方法1:重新构建canvas模块(推荐优先尝试)

  1. 安装构建依赖:bash复制sudo yum install -y gcc-c++ cairo cairo-devel libjpeg-turbo-devel pango pango-devel giflib-devel
  2. 重新编译canvas:bash复制# 删除现有模块并重新安装 rm -rf node_modules npm install
    • 如果问题依旧,尝试强制重建原生模块:bash复制npm rebuild canvas –update-binary

方法2:升级GLIBC(谨慎操作)

警告:升级GLIBC可能导致系统不稳定,仅建议在测试环境中使用。

  1. 下载并编译GLIBC 2.18:bash复制# 安装依赖 sudo yum install -y bison make gcc # 下载源码 wget http://ftp.gnu.org/gnu/glibc/glibc-2.18.tar.gz tar -xzf glibc-2.18.tar.gz cd glibc-2.18 # 编译安装(指定目录避免覆盖系统文件) mkdir build && cd build ../configure –prefix=/opt/glibc-2.18 make -j4 sudo make install
  2. 临时指定GLIBC路径运行Node应用:bash复制LD_LIBRARY_PATH=/opt/glibc-2.18/lib node your-app.js

方法3:使用Docker容器(推荐生产环境)

通过Docker隔离环境,避免修改宿主机GLIBC。

  1. 创建Dockerfile:Dockerfile复制FROM centos:7 # 安装依赖 RUN yum install -y gcc-c++ cairo cairo-devel libjpeg-turbo-devel pango pango-devel giflib-devel # 安装Node.js RUN curl -sL https://rpm.nodesource.com/setup_14.x | bash – RUN yum install -y nodejs # 复制应用代码 WORKDIR /app COPY package*.json ./ RUN npm install COPY . . CMD [“node”, “your-app.js”]
  2. 构建并运行容器:bash复制docker build -t node-app . docker run -it –rm node-app

方法4:使用第三方仓库(如SCL)

CentOS 7可通过Software Collections(SCL)获取较新工具链。

  1. 启用SCL仓库:bash复制sudo yum install -y centos-release-scl
  2. 安装高版本开发工具链:bash复制sudo yum install -y devtoolset-8
  3. 使用新工具链编译应用:bash复制scl enable devtoolset-8 bash rm -rf node_modules npm install

总结建议

  • 推荐方案:优先尝试方法1(重新构建)或方法3(Docker),避免直接升级GLIBC的风险。
  • 生产环境:强烈建议使用Docker容器化部署,确保环境一致性。
  • 备用方案:若必须升级GLIBC,务必在测试环境中验证稳定性。
作者 east

1 2 … 41 下一个

关注公众号“大模型全栈程序员”回复“小程序”获取1000个小程序打包源码。回复”chatgpt”获取免注册可用chatgpt。回复“大数据”获取多本大数据电子书

标签

AIGC AI创作 bert chatgpt github GPT-3 gpt3 GTP-3 hive mysql O2O tensorflow UI控件 不含后台 交流 共享经济 出行 图像 地图定位 外卖 多媒体 娱乐 小程序 布局 带后台完整项目 开源项目 搜索 支付 效率 教育 日历 机器学习 深度学习 物流 用户系统 电商 画图 画布(canvas) 社交 签到 联网 读书 资讯 阅读 预订

官方QQ群

小程序开发群:74052405

大数据开发群: 952493060

近期文章

  • 如何在Chrome中设置启动时自动打开多个默认网页
  • spark内存溢出怎样区分是软件还是代码原因
  • MQTT完全解析和实践
  • 解决运行Selenium报错:self.driver = webdriver.Chrome(service=service) TypeError: __init__() got an unexpected keyword argument ‘service’
  • python 3.6使用mysql-connector-python报错:SyntaxError: future feature annotations is not defined
  • 详解Python当中的pip常用命令
  • AUTOSAR如何在多个供应商交付的配置中避免ARXML不兼容?
  • C++thread pool(线程池)设计应关注哪些扩展性问题?
  • 各类MCAL(Microcontroller Abstraction Layer)如何与AUTOSAR工具链解耦?
  • 如何设计AUTOSAR中的“域控制器”以支持未来扩展?

文章归档

  • 2025年7月
  • 2025年6月
  • 2025年5月
  • 2025年4月
  • 2025年3月
  • 2025年2月
  • 2025年1月
  • 2024年12月
  • 2024年11月
  • 2024年10月
  • 2024年9月
  • 2024年8月
  • 2024年7月
  • 2024年6月
  • 2024年5月
  • 2024年4月
  • 2024年3月
  • 2023年11月
  • 2023年10月
  • 2023年9月
  • 2023年8月
  • 2023年7月
  • 2023年6月
  • 2023年5月
  • 2023年4月
  • 2023年3月
  • 2023年1月
  • 2022年11月
  • 2022年10月
  • 2022年9月
  • 2022年8月
  • 2022年7月
  • 2022年6月
  • 2022年5月
  • 2022年4月
  • 2022年3月
  • 2022年2月
  • 2022年1月
  • 2021年12月
  • 2021年11月
  • 2021年9月
  • 2021年8月
  • 2021年7月
  • 2021年6月
  • 2021年5月
  • 2021年4月
  • 2021年3月
  • 2021年2月
  • 2021年1月
  • 2020年12月
  • 2020年11月
  • 2020年10月
  • 2020年9月
  • 2020年8月
  • 2020年7月
  • 2020年6月
  • 2020年5月
  • 2020年4月
  • 2020年3月
  • 2020年2月
  • 2020年1月
  • 2019年7月
  • 2019年6月
  • 2019年5月
  • 2019年4月
  • 2019年3月
  • 2019年2月
  • 2019年1月
  • 2018年12月
  • 2018年7月
  • 2018年6月

分类目录

  • Android (73)
  • bug清单 (79)
  • C++ (34)
  • Fuchsia (15)
  • php (4)
  • python (45)
  • sklearn (1)
  • 云计算 (20)
  • 人工智能 (61)
    • chatgpt (21)
      • 提示词 (6)
    • Keras (1)
    • Tensorflow (3)
    • 大模型 (1)
    • 智能体 (4)
    • 深度学习 (14)
  • 储能 (44)
  • 前端 (5)
  • 大数据开发 (491)
    • CDH (6)
    • datax (4)
    • doris (31)
    • Elasticsearch (15)
    • Flink (78)
    • flume (7)
    • Hadoop (19)
    • Hbase (23)
    • Hive (41)
    • Impala (2)
    • Java (71)
    • Kafka (10)
    • neo4j (5)
    • shardingsphere (6)
    • solr (5)
    • Spark (100)
    • spring (11)
    • 数据仓库 (9)
    • 数据挖掘 (7)
    • 海豚调度器 (10)
    • 运维 (34)
      • Docker (3)
  • 小游戏代码 (1)
  • 小程序代码 (139)
    • O2O (16)
    • UI控件 (5)
    • 互联网类 (23)
    • 企业类 (6)
    • 地图定位 (9)
    • 多媒体 (6)
    • 工具类 (25)
    • 电商类 (22)
    • 社交 (7)
    • 行业软件 (7)
    • 资讯读书 (11)
  • 嵌入式 (71)
    • autosar (63)
    • RTOS (1)
    • 总线 (1)
  • 开发博客 (16)
    • Harmony (9)
  • 技术架构 (6)
  • 数据库 (32)
    • mongodb (1)
    • mysql (13)
    • pgsql (2)
    • redis (1)
    • tdengine (4)
  • 未分类 (7)
  • 程序员网赚 (20)
    • 广告联盟 (3)
    • 私域流量 (5)
    • 自媒体 (5)
  • 量化投资 (4)
  • 面试 (14)

功能

  • 登录
  • 文章RSS
  • 评论RSS
  • WordPress.org

All Rights Reserved by Gitweixin.本站收集网友上传代码, 如有侵犯版权,请发邮件联系yiyuyos@gmail.com删除.