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

分类归档大数据开发

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

  • 首页   /  
  • 分类归档: "大数据开发"
运维 8月 30,2025

解决某个软件系统更新后 xxx is unable to connect to the wmi

某个亲戚使用某个工业软件,某一天关机时不小心选择更新系统,第二天发现这个工业软件使用不了,提示“is unable to connect to the wmi”

为什么 Windows 更新后会出现这个问题?

Windows 更新过程非常复杂,它会替换、修改大量的系统文件和配置。在这个过程中,有几种可能导致 WMI 服务出现问题:

  • WMI 服务损坏:更新过程中,与 WMI 相关的文件可能被损坏或未能正确注册。
  • WMI 仓库 (Repository) 不一致:WMI 有一个数据库(称为 Repository)用来存储系统的管理信息。更新后,这个数据库可能处于损坏或与新系统文件不一致的状态。
  • 服务未启动或配置错误:更新可能更改了 WMI 服务的启动状态或相关依赖服务的配置。
  • 权限问题:更新后的安全策略可能阻止了 软件访问 WMI 接口。

解决方案步骤

请从上到下、按顺序尝试以下解决方案。这些方法从最简单、最无风险的操作开始,逐步深入。在执行需要输入命令的步骤时,请务g必以管理员身份运行命令提示符 (CMD) 或 PowerShell。


步骤 1:以管理员身份运行软件

最简单的可能性是权限问题。

  1. 右键点击 软件的快捷方式或可执行文件 (.exe)。
  2. 选择 “以管理员身份运行”。
  3. 查看问题是否解决。如果解决了,您可以设置该软件始终以管理员身份运行(右键 -> 属性 -> 兼容性 -> 勾选“以管理员身份运行此程序”)。

步骤 2:检查并重启 WMI 服务

确保 WMI 服务正在运行是解决问题的关键。

  1. 按下 Win + R 键,打开“运行”对话框。
  2. 输入 services.msc 并按回车,打开“服务”窗口。
  3. 在服务列表中,找到名为 Windows Management Instrumentation 的服务。
  4. 检查它的“状态”是否为“正在运行”,“启动类型”是否为“自动”。
  5. 如果不是,请右键点击该服务,选择“属性”,将“启动类型”设置为“自动”,然后点击“启动”按钮。
  6. 如果它已经在运行,请右键点击它,选择“重新启动”。
  7. 重启服务后,再次尝试运行软件。

步骤 3:使用 Windows 内置工具诊断和修复 WMI

这是最核心和最可能解决问题的步骤。

  1. 在开始菜单搜索框中输入 cmd。
  2. 在搜索结果中,右键点击“命令提示符”,选择“以管理员身份运行”。
  3. 在打开的黑色窗口中,逐一输入以下命令,每输入一条就按一次回车。
    • 验证 WMI 仓库是否一致:winmgmt /verifyrepository 如果返回 WMI repository is consistent (WMI 仓库是一致的),说明仓库本身没问题,可以跳到步骤 4。如果返回 WMI repository is inconsistent (WMI 仓库不一致) 或其他错误,请继续执行下面的修复命令。
    • “抢救”模式修复 WMI 仓库(推荐首先尝试): 这个命令会尝试在不完全重置的情况下修复仓库。winmgmt /salvagerepository 执行后会返回类似 WMI repository has been salvaged 的信息。执行完毕后,请重启电脑,然后再次尝试运行软件。
    • 强制重置 WMI 仓库(如果上面的“抢救”无效): ⚠️ 警告:这个命令会将 WMI 仓库恢复到 Windows 安装时的初始状态,可能会导致某些依赖 WMI 的第三方管理软件需要重新安装。但它通常能解决顽固的 WMI 损坏问题。winmgmt /resetrepository 执行完毕后,必须重启电脑,然后再次尝试运行 软件。
作者 east
Flink 8月 14,2025

Flink Checkpoint时间设置太小有什么影响

在面试时被问到这个问题,当时有点蒙圈没答好,现在记录下来好以后复习:

在 Flink 里,如果 checkpoint 时间间隔(interval)设置得太小,会带来一系列性能和稳定性方面的影响,主要包括:


1. 计算资源被 Checkpoint 占用过多

  • 原理:每次 checkpoint 都会触发状态快照(state snapshot)写入持久化存储(如 HDFS、S3、RocksDB 本地+远程),这是一个 IO 密集操作,还会涉及数据序列化、网络传输。
  • 影响:
    • CPU 用于业务逻辑计算的时间减少
    • IO 带宽被 checkpoint 数据占用
    • 延迟增加,因为算子线程要等待 barrier 对齐(barrier alignment)

2. Barrier 对齐等待时间增加

  • 如果上游多个分区流速不同,Flink 在做 checkpoint 时需要等待所有输入流的 barrier 对齐。
  • 频繁 checkpoint 会导致算子更频繁进入 barrier 对齐状态,导致吞吐下降。

3. 状态后端压力过大

  • 以 RocksDB StateBackend 为例:
    • 每次 checkpoint 都会触发 RocksDB 的 SST 文件刷写(flush)和元数据更新
    • 频繁刷写会增加磁盘 IO 竞争和后台 compaction 压力
    • 如果状态数据较大,频繁 checkpoint 会让 RocksDB compaction 线程长期占用 CPU/IO

4. 反而可能导致 checkpoint 堆积 / 失败

  • 原因:
    • Checkpoint 需要在指定超时时间内完成,如果间隔太小,上一个 checkpoint 还没完成,下一个就开始了,可能导致多个 checkpoint 并发执行(如果 maxConcurrentCheckpoints > 1),进而造成存储、网络压力飙升。
    • 在极端情况下,会触发 checkpoint 超时、失败,甚至导致作业频繁重启。

5. 延迟敏感任务反而变慢

  • 在低延迟实时任务中,业务逻辑和 checkpoint 操作会竞争资源,如果 checkpoint 太频繁,反而可能 吞吐下降、延迟上升。

6. 容错收益递减

  • 理论上,checkpoint 间隔越短,失败恢复时丢失的数据就越少。
  • 但在实际生产中,checkpoint 间隔小于 5 秒往往收益很低,而性能损耗却非常明显(尤其是状态数据大的任务)。
  • 如果作业不是超高可用的金融级场景,过于频繁 checkpoint 意义不大。
作者 east
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

1 2 … 42 下一个

关注公众号“大模型全栈程序员”回复“小程序”获取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年8月
  • 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)
  • 大数据开发 (493)
    • CDH (6)
    • datax (4)
    • doris (31)
    • Elasticsearch (15)
    • Flink (79)
    • 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)
    • 运维 (35)
      • 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删除.