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

分类归档大数据开发

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

  • 首页   /  
  • 分类归档: "大数据开发"
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​​:支持命令行参数直接启用恢复模式:bash复制sh bin/start_fe.sh --metadata_failure_recovery --daemon
  • ​​Doris <2.0.2​​:需在 fe.conf 中添加 metadata_failure_recovery=true7。

​​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
doris 3月 6,2025

Apache Doris内存与超时参数配置详解

以下是根据你的需求整理的Apache Doris内存与超时参数配置详解,结合了相关技术文档和实践经验:

一、查询任务内存限制调整

1. ​默认内存限制与问题定位

Apache Doris默认限制单个BE节点上的查询任务内存使用不超过2GB(即exec_mem_limit=2147483648字节)。当复杂查询或大规模数据操作超过此限制时,会触发Memory limit exceeded错误。通过以下命令可查看当前配置:

SHOW VARIABLES LIKE "%mem_limit%";

输出示例:

+----------------+------------+
| Variable_name  | Value      |
+----------------+------------+
| exec_mem_limit | 2147483648 |  -- 默认2GB
| load_mem_limit | 0          |  -- 导入任务内存限制(0表示无限制)
+----------------+------------+

2. ​调整内存限制的方法

  • ​临时调整(当前会话生效)​​
    通过SET命令修改会话级参数,适用于单次查询优化:sqlSET exec_mem_limit = 8589934592; -- 设置为8GB
  • ​永久生效(全局配置)​​
    添加GLOBAL参数以全局生效,需在FE节点配置中持久化:sqlSET GLOBAL exec_mem_limit = 8589934592;​
  • 注意事项:
    • 若集群资源有限,需结合BE节点的总内存(通过mem_limit参数控制)合理分配,避免单任务占用过高导致节点OOM6。
    • 高并发场景建议通过资源标签(Resource Label)隔离关键任务,防止资源争用6。

二、查询超时时间优化

1. ​默认超时机制与配置查询

Doris默认查询超时时间为300秒(5分钟),可通过以下命令查看:

sqlSHOW VARIABLES LIKE "%query_timeout%";

输出示例:

+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| query_timeout | 300   |
+---------------+-------+

2. ​延长超时时间的操作

  • ​临时调整(当前会话生效)​​sqlSET query_timeout = 600; -- 设置为600秒(10分钟)
  • ​永久生效(全局配置)​​sqlSET GLOBAL query_timeout = 600;​动态生效特性:与内存参数不同,超时参数修改后通常无需重启集群即可生效7。

三、关联参数与调优实践

1. ​内存管理联动配置

  • ​BE节点总内存限制(mem_limit)​​
    控制单个BE进程的最大内存使用,默认根据物理内存自动计算(如物理内存的90%或物理内存-6.4GB)。建议在be.conf中显式设置,避免资源竞争4。bashmem_limit = 80% # 或具体值如32G
  • ​Compaction内存限制(compaction_memory_bytes_limit)​​
    控制数据合并任务的内存使用上限,默认值根据系统配置动态调整。若频繁因Compaction导致查询内存不足,可适当调低此参数5。

2. ​高并发场景优化策略

  • ​并行度与资源分配​
    提升查询并行度(parallel_degree)可加速处理,但需平衡CPU和内存消耗。例如:sqlSET GLOBAL parallel_degree = 16; -- 根据CPU核心数调整
  • ​物化视图与分区优化​
    对高频查询创建物化视图或合理分区,减少单次查询的数据扫描量,间接降低内存需求6。

四、操作验证与监控

  1. ​验证参数生效​
    修改后通过SHOW VARIABLES确认新值是否生效,并执行测试查询观察内存使用情况。
  2. ​日志与监控工具​
    • ​FE日志:检查fe.log中内存超限或超时任务记录3。
    • ​BE监控:通过curl http://BE_IP:8040/api/compaction/show?tablet_id=XXX查看Tablet状态3。
    • ​系统视图:使用SHOW PROC '/admin/stats'实时监控资源使用6
作者 east
bug清单, Flink 3月 5,2025

解决Flink SQL:Exception in thread “main” org.apache.flink.table.api.ValidationException: Rowtime attribute ‘ptime’ must be of type TIMESTAMP or TIMESTAMP_LTZ but is of type ‘BIGINT’.

在开发Flink SQL时报错:

在flink 1.16版本中执行报错:Exception in thread "main" org.apache.flink.table.api.ValidationException: Rowtime attribute 'ptime' must be of type TIMESTAMP or TIMESTAMP_LTZ but is of type 'BIGINT'.

	at org.apache.flink.table.api.TableSchema.validateColumnsAndWatermarkSpecs(TableSchema.java:535)

	at org.apache.flink.table.api.TableSchema.access$100(TableSchema.java:73)

	at org.apache.flink.table.api.TableSchema$Builder.build(TableSchema.java:802)

	at org.apache.flink.table.planner.operations.MergeTableLikeUtil$SchemaBuilder.build(MergeTableLikeUtil.java:534)

	at org.apache.flink.table.planner.operations.MergeTableLikeUtil.mergeTables(MergeTableLikeUtil.java:154)

	at org.apache.flink.table.planner.operations.SqlCreateTableConverter.createCatalogTable(SqlCreateTableConverter.java:171)

	at org.apache.flink.table.planner.operations.SqlCreateTableConverter.convertCreateTable(SqlCreateTableConverter.java:74)

	at org.apache.flink.table.planner.operations.SqlToOperationConverter.convertValidatedSqlNode(SqlToOperationConverter.java:330)

	at org.apache.flink.table.planner.operations.SqlToOperationConverter.convert(SqlToOperationConverter.java:282)

	at org.apache.flink.table.planner.delegation.ParserImpl.parse(ParserImpl.java:106)

	at org.apache.flink.table.api.internal.TableEnvironmentImpl.executeSql(TableEnvironmentImpl.java:758)

	at com.chuneng.saas.doris.FlinkDorisExtremeValueCalculation.main(FlinkDorisExtremeValueCalculation.java:44)

原因分析

错误的核心在于:Flink 要求用于定义 WATERMARK 的字段必须是 TIMESTAMP 或 TIMESTAMP_LTZ 类型,但你的 ptime 字段被定义为 BIGINT 类型。尽管你在 WATERMARK 中尝试将 ptime 转换为 TIMESTAMP,但 Flink 的 WATERMARK 语法要求直接引用一个已经存在的 TIMESTAMP 类型字段,而不是在 WATERMARK 定义中动态转换类型。

解决方案

你需要通过 计算列(Computed Column) 将 ptime 的 BIGINT 类型转换为 TIMESTAMP 类型,然后将 WATERMARK 绑定到计算列上。

例如像下面这样:

String sourceDDL = "CREATE TABLE ods_t_iot_data (" +
        "pid STRING," +
        "pvalue DECIMAL(13,3)," +
        "ptime BIGINT," +
        "ds DATE," +
        // 定义计算列,将 BIGINT 类型的 ptime 转换为 TIMESTAMP
        "event_time AS TO_TIMESTAMP(FROM_UNIXTIME(ptime / 1000))," + 
        // 绑定 WATERMARK 到计算列 event_time
        "WATERMARK FOR event_time AS event_time - INTERVAL '5' SECOND" +
        ") WITH (" +
        "'connector' = 'doris'," +
        "'fenodes' = '10.0.0.1:8030'," +
        "'table.identifier' = 'cnsaas.ods_t_iot'," +
        "'username' = 'root'," +
        "'password' = ''" +
        ")";
作者 east
bug清单, Flink 3月 5,2025

解决Flink SQL报错”Exception in thread “main” java.lang.IllegalStateException: please declare primary key for sink table when query contains update/delete record”

在开发Flink SQL时报错”Exception in thread “main” java.lang.IllegalStateException: please declare primary key for sink table when query contains update/delete record”

这个错误表明您的Flink作业涉及更新或删除操作(如CDC场景),而JDBC Sink表没有定义主键。以下是详细分析和解决方案:

错误原因分析

当Flink作业涉及UPDATE/DELETE操作时(常见于CDC场景或使用Retract流),JDBC Sink表必须显式声明主键,因为:

  1. 主键用于定位目标数据库中需要更新的记录
  2. 没有主键时,Flink无法确定如何执行更新/删除操作

解决方案

在表定义中添加 PRIMARY KEY 声明(需与目标数据库表主键一致),例如:

val sinkDDL =
  """
    |CREATE TABLE dws_iot_extreme_info_min (
    |  device_code STRING,
    |  `day` DATE,
    |  ptime BIGINT,
    |  station_sn STRING,
    |  unit STRING,
    |  cu_device_code STRING,
    |  max_u_value DECIMAL(5,3),
    |  min_u_value DECIMAL(5,3),
    |  max_t_value DECIMAL(5,2),
    |  min_t_value DECIMAL(5,2),
    |  max_soc_value DECIMAL(5,2),
    |  min_soc_value DECIMAL(5,2),
    |  max_u_time BIGINT,
    |  min_u_time BIGINT,
    |  max_t_time BIGINT,
    |  min_t_time BIGINT,
    |  max_soc_time BIGINT,
    |  min_soc_time BIGINT,
    |  dt DATE,
    |  PRIMARY KEY (device_code, `day`) NOT ENFORCED  -- 添加主键声明
    |) WITH (
    |  'connector' = 'jdbc',
    |  'url' = 'jdbc:mysql://10.0.2.2:3306/cnsaas',
    |  'table-name' = 'dws_bigdata_device_extreme_info_min',
    |  'driver' = 'com.mysql.cj.jdbc.Driver',
    |  'username' = 'root',
    |  'password' = '',
    |  'sink.buffer-flush.max-rows' = '1000',    
    |  'sink.buffer-flush.interval' = '1s',      
    |  'sink.max-retries' = '3'                 
    |)
    |""".stripMargin

关键修改点说明

  1. 主键声明:PRIMARY KEY (device_code, `day`) NOT ENFORCED
    • 主键字段需与目标数据库表的主键一致
    • NOT ENFORCED 表示Flink不会校验数据主键约束,由数据库负责
  2. 目标表要求:
    • MySQL数据库中 dws_iot_extreme_info_min 表必须有相同的主键定义
    • 可通过以下SQL确保主键存在:
    • ALTER TABLE dws_iot_extreme_info_min ADD PRIMARY KEY (device_code, day);
作者 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

近期文章

  • 详解Python当中的pip常用命令
  • AUTOSAR如何在多个供应商交付的配置中避免ARXML不兼容?
  • C++thread pool(线程池)设计应关注哪些扩展性问题?
  • 各类MCAL(Microcontroller Abstraction Layer)如何与AUTOSAR工具链解耦?
  • 如何设计AUTOSAR中的“域控制器”以支持未来扩展?
  • C++ 中避免悬挂引用的企业策略有哪些?
  • 嵌入式电机:如何在低速和高负载状态下保持FOC(Field-Oriented Control)算法的电流控制稳定?
  • C++如何在插件式架构中使用反射实现模块隔离?
  • C++如何追踪内存泄漏(valgrind/ASan等)并定位到业务代码?
  • C++大型系统中如何组织头文件和依赖树?

文章归档

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

功能

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

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