Hadoop 三节点集群环境变量工程化：从 /etc/profile 迁移到 /etc/profile.d/ 全过程记录

升职佳兴2026-03-12 8:16

Hadoop 三节点集群环境变量工程化：从 /etc/profile 迁移到 /etc/profile.d/ 全过程记录

摘要 ：本文记录了我在三节点 Hadoop 集群（hadoop1 / hadoop2 / hadoop3）上，将所有自定义环境变量从 /etc/profile 末尾"一锅炖"的写法，迁移到 /etc/profile.d/*.sh 按组件拆分的过程。包含完整操作步骤、验证方法、踩坑排查，以及最终三台机器的验收结果。适合刚接触 Hadoop 和 Linux 环境管理的初学者参考。

一、为什么要做这件事

1.1 我之前的做法

在最初搭建集群时，我和大多数入门阶段的同学一样，把所有环境变量都追加到了 /etc/profile 文件的末尾。Java、Hadoop、ZooKeeper、HBase、Scala、Hive......一股脑全写进去：

bash 复制代码 
# 配置JDK系统环境变量
export JAVA_HOME=/export/servers/jdk1.8.0_241
export PATH=$PATH:$JAVA_HOME/bin

export HADOOP_HOME=/export/servers/hadoop-3.3.0
export PATH=$PATH:$HADOOP_HOME/bin:$HADOOP_HOME/sbin

export ZK_HOME=/export/servers/zookeeper-3.7.0
export PATH=$PATH:$ZK_HOME/bin

export HBASE_HOME=/export/servers/hbase-2.4.9
export PATH=$PATH:$HBASE_HOME/bin
# ... 还有 SCALA_HOME、HIVE_HOME 等

这种写法在初期建环境时非常直接------往文件末尾 echo >> 几行就搞定了，能跑通就行。

1.2 这种写法带来的问题

用了一段时间之后，问题逐渐暴露出来：

  1. /etc/profile 越来越臃肿 。系统默认内容和我手写的一大堆 export 混在一起，改一个组件的路径要从一堆变量里挑，改错了还不容易发现。

  2. 三台机器不一致 。hadoop1 上多了 Scala，hadoop3 上多了 Hive，其他两台不需要这些变量。但因为都写在 /etc/profile 里，要么三台都写（多余），要么手动区分（容易遗漏）。

  3. 维护风险高 。如果系统升级或某些自动化工具修改了 /etc/profile，我追加的内容有可能被冲掉。手工改文件末尾这种做法，没有任何隔离保护。

  4. 排障困难。环境变量出问题时，要在一个几十行甚至上百行的文件里肉眼找错误，效率很低。

  5. PATH 重复追加 。每次 source /etc/profile 都会重复往 PATH 里追加一遍，时间长了 echo $PATH 输出一大长串重复路径，虽然功能上不影响，但看着很不规范。

1.3 业界推荐的做法

在多节点集群、生产环境、或者有多人维护的场景下，/etc/profile.d/ 方式几乎是默认的规范做法。

给新手解释一下 /etc/profile.d/ 是什么：

Linux 系统在用户登录时，会自动执行 /etc/profile 这个文件。而 /etc/profile 里有一段逻辑，会自动去扫描 /etc/profile.d/ 目录下所有以 .sh 结尾的文件，并逐个执行它们。

也就是说，你只要把环境变量写成独立的 .sh 文件丢到 /etc/profile.d/ 目录下，系统登录时就会自动加载，效果和写在 /etc/profile 末尾是一样的。

但好处在于：每个组件一个文件，互不干扰，增删改查都方便。

迁移后的好处：

  • /etc/profile 保持系统默认，升级/变更时冲突最少
  • 按组件拆分 （java.sh、hadoop.sh、hive.sh......）更清晰
  • 多节点可统一分发，排障时定位快
  • 回滚简单 ，禁用某个组件只需移除或重命名一个 .sh 文件

想清楚了，那就动手。

二、我的环境说明

项目 值
节点 hadoop1 / hadoop2 / hadoop3（三台 CentOS 9 虚拟机）
JDK /export/servers/jdk1.8.0_241
Hadoop /export/servers/hadoop-3.3.0
ZooKeeper /export/servers/zookeeper-3.7.0
HBase /export/servers/hbase-2.4.9
Scala /export/servers/scala-2.12.15（仅 hadoop1）
Hive /export/servers/hive-3.1.3（仅 hadoop3）
操作用户 root

⚠️ 重要提醒 ：上面所有路径都是我自己环境的示例。你的 JDK 版本、Hadoop 安装目录、各组件路径大概率和我不一样。后面的操作中，每次涉及安装路径的地方，请务必替换成你自己机器上的实际路径，不要直接复制粘贴我的命令。

三、迁移操作：完整步骤

3.1 备份 /etc/profile（三台机器都做）

迁移前必须备份。万一改出问题，还能快速还原。

bash 复制代码 
cp /etc/profile /etc/profile.bak.$(date +%F-%H%M%S)
mkdir -p /etc/profile.d

命令解释：

  • cp /etc/profile /etc/profile.bak.$(date +%F-%H%M%S)：把当前的 /etc/profile 复制一份，文件名带上当前日期时间作为后缀（比如 profile.bak.2026-03-10-153022），方便区分多次备份。
  • mkdir -p /etc/profile.d：确保 /etc/profile.d/ 目录存在。正常情况下 CentOS 7 系统都有这个目录，但加个 -p 保险，目录已存在也不会报错。

执行成功后不会有任何输出（Linux 的惯例是"没有消息就是好消息"）。可以用 ls /etc/profile.bak.* 确认备份文件已经生成。

3.2 创建 PATH 防重复工具文件（三台机器都做）

在正式创建组件环境变量文件之前，我先建了一个公共工具文件。它的作用是：往 PATH 里添加路径时，先检查是否已经存在，避免重复追加。

bash 复制代码 
cat >/etc/profile.d/00-path-utils.sh <<'EOF'
append_path_once() {
    case ":$PATH:" in
        *":$1:"*) ;;
        *) PATH="${PATH:+$PATH:}$1" ;;
    esac
}
prepend_path_once() {
    case ":$PATH:" in
        *":$1:"*) ;;
        *) PATH="$1${PATH:+:$PATH}" ;;
    esac
}
EOF
chmod 644 /etc/profile.d/00-path-utils.sh

这段是做什么的：

  • append_path_once 函数：把一个路径追加到 PATH 末尾，但会先检查这个路径是不是已经在 PATH 里了------如果已经有了，就跳过，不重复添加。
  • prepend_path_once 函数：类似，但是把路径加到 PATH 的最前面（优先级更高）。
  • 文件名前缀 00- 是为了保证它最先被加载 。/etc/profile.d/ 下的文件是按文件名字母顺序执行的，所以用 00- 开头，确保后面的 10-java.sh、20-hadoop.sh 等文件调用这些函数时，函数已经定义好了。
  • chmod 644：设置权限为所有人可读，只有 root 可写。/etc/profile.d/ 下的文件至少需要 644 权限才能被系统正常加载。

⚠️ 踩坑说明 ：如果不用这种防重复机制，每次 source /etc/profile（或者每次新开终端），PATH 都会被追加一遍相同的路径。虽然功能上不会出错，但 echo $PATH 的输出会越来越长、越来越乱，排查环境变量问题时非常干扰判断。

3.3 创建各组件的环境变量文件

三台机器都执行的部分（Java / Hadoop / ZooKeeper / HBase）
bash 复制代码 
cat >/etc/profile.d/10-java.sh <<'EOF'
export JAVA_HOME=/export/servers/jdk1.8.0_241
append_path_once "$JAVA_HOME/bin"
EOF

cat >/etc/profile.d/20-hadoop.sh <<'EOF'
export HADOOP_HOME=/export/servers/hadoop-3.3.0
append_path_once "$HADOOP_HOME/bin"
append_path_once "$HADOOP_HOME/sbin"
EOF

cat >/etc/profile.d/30-zookeeper.sh <<'EOF'
export ZK_HOME=/export/servers/zookeeper-3.7.0
append_path_once "$ZK_HOME/bin"
EOF

cat >/etc/profile.d/40-hbase.sh <<'EOF'
export HBASE_HOME=/export/servers/hbase-2.4.9
append_path_once "$HBASE_HOME/bin"
EOF

chmod 644 /etc/profile.d/10-java.sh /etc/profile.d/20-hadoop.sh /etc/profile.d/30-zookeeper.sh /etc/profile.d/40-hbase.sh

文件命名规则说明：

  • 文件名前面的数字（10-、20-......）是用来控制加载顺序的。数字越小，越先加载。Java 是底层依赖，所以用 10- 最先加载；Hadoop 依赖 Java，所以 20-；ZooKeeper 和 HBase 依次往后排。
  • 这个数字不是必须的，去掉也能用，但加上后文件在 ls 列表里排列整齐，维护时一目了然。

⚠️ 再次提醒 ：这里的路径（/export/servers/jdk1.8.0_241 等）都是我的安装目录。你需要根据自己机器上 which java、echo $JAVA_HOME 等命令的输出来确认实际路径，千万不要直接照抄。

仅在 hadoop1 上执行（Scala）
bash 复制代码 
cat >/etc/profile.d/45-scala.sh <<'EOF'
export SCALA_HOME=/export/servers/scala-2.12.15
prepend_path_once "$SCALA_HOME/bin"
EOF
chmod 644 /etc/profile.d/45-scala.sh

为什么 Scala 用 prepend（前置）而不是 append（追加） ：prepend 会把 Scala 的 bin 目录放到 PATH 的最前面，这样当系统中存在多个版本的 Scala 时，会优先使用这个版本。这是一个可选的策略，用 append 也完全可以。

仅在 hadoop3 上执行（Hive）
bash 复制代码 
cat >/etc/profile.d/50-hive.sh <<'EOF'
export HIVE_HOME=/export/servers/hive-3.1.3
append_path_once "$HIVE_HOME/bin"
EOF
chmod 644 /etc/profile.d/50-hive.sh

⚠️ 为什么 Scala 只在 hadoop1、Hive 只在 hadoop3：因为不是所有节点都需要所有组件。我的集群规划里，Spark/Scala 相关任务跑在 hadoop1 上，Hive Metastore 部署在 hadoop3 上。如果你的集群布局不同，请按你的实际情况决定在哪些节点创建哪些文件。

3.4 第一轮验证：当前会话验证

文件都创建好了，但先不要急着删 /etc/profile 里的旧内容。先验证新方案能不能生效。

bash 复制代码 
source /etc/profile
echo $JAVA_HOME
echo $HADOOP_HOME
echo $ZK_HOME
echo $HBASE_HOME
which java
which hdfs

命令解释：

  • source /etc/profile：重新加载 /etc/profile。它会连带执行 /etc/profile.d/ 下所有 .sh 文件，让新创建的环境变量在当前终端生效。
  • echo $JAVA_HOME：打印 JAVA_HOME 变量的值，确认它指向正确的 JDK 目录。
  • which java、which hdfs：确认 java 和 hdfs 命令能被找到，说明 PATH 已经正确包含了对应的 bin 目录。

预期结果 ：所有变量都能输出正确路径，which 命令能找到对应的可执行文件。

在 hadoop1 还要额外验证：

bash 复制代码 
echo $SCALA_HOME
which scala

在 hadoop3 还要额外验证：

bash 复制代码 
echo $HIVE_HOME
which hive
hive --version

⚠️ 重要提醒 ：这一步即使全部通过，也不能马上删旧内容 。因为当前终端可能还残留着之前 source 旧文件时设置的变量，你看到的"正常"可能是假的。必须做下一步------新会话验证。

3.5 第二轮验证：新 SSH 会话验证（关键步骤）

这一步是整个迁移过程中最容易被忽略、但最重要的一步。

给新手解释为什么要开新会话：

当你在一个终端里执行了 source /etc/profile，当前 shell 进程的环境变量就被设置了。即使后面 /etc/profile.d/ 的文件有问题，之前设置过的变量也不会消失------它们已经在这个进程的内存里了。

所以你必须完全退出当前终端，重新 SSH 登录 ，开一个全新的会话。新会话启动时，系统会从零开始加载 /etc/profile → /etc/profile.d/*.sh，这才能真正验证你的配置是否独立生效。

hadoop1 新终端执行：

bash 复制代码 
echo $JAVA_HOME
echo $HADOOP_HOME
echo $ZK_HOME
echo $HBASE_HOME
echo $SCALA_HOME
which java
which hdfs
which scala
which hive
ls /etc/profile.d

预期：

  • JAVA_HOME、HADOOP_HOME、ZK_HOME、HBASE_HOME、SCALA_HOME 都有值
  • which java、which hdfs、which scala 有结果
  • which hive 没有结果（因为 hadoop1 上没有 Hive）
  • /etc/profile.d 里能看到 00-path-utils.sh、10-java.sh、20-hadoop.sh、30-zookeeper.sh、40-hbase.sh、45-scala.sh

hadoop2 新终端执行：

bash 复制代码 
echo $JAVA_HOME
echo $HADOOP_HOME
echo $ZK_HOME
echo $HBASE_HOME
echo $SCALA_HOME
echo $HIVE_HOME
which java
which hdfs
which scala
which hive
ls /etc/profile.d

预期：

  • 前四个变量有值
  • SCALA_HOME 和 HIVE_HOME 为空
  • which java、which hdfs 有结果
  • which scala、which hive 没有结果

hadoop3 新终端执行：

bash 复制代码 
echo $JAVA_HOME
echo $HADOOP_HOME
echo $ZK_HOME
echo $HBASE_HOME
echo $HIVE_HOME
which java
which hdfs
which hive
ls /etc/profile.d

预期：

  • JAVA_HOME、HADOOP_HOME、ZK_HOME、HBASE_HOME、HIVE_HOME 都有值
  • which java、which hdfs、which hive 都有结果
  • /etc/profile.d 里有 50-hive.sh

如果这一步全部通过，说明 /etc/profile.d/ 方案已经完全独立生效，可以放心删除旧内容了。

如果某个变量没有值或 which 找不到命令，先不要删旧内容，回去检查：

  1. 对应的 .sh 文件是否存在？ls -l /etc/profile.d/
  2. 文件内容是否正确？cat /etc/profile.d/10-java.sh
  3. 文件权限是否至少 644？ls -l /etc/profile.d/*.sh
  4. 00-path-utils.sh 是否存在？后面的文件依赖它里面的 append_path_once 函数

3.6 清理 /etc/profile 旧内容（三台机器都做）

新会话验证通过后，就可以删除 /etc/profile 末尾手工追加的那一大段自定义内容了。

先定位要删除的起始行：

bash 复制代码 
grep -n '^# 配置JDK系统环境变量' /etc/profile

命令解释：

  • grep -n：-n 参数会显示匹配行的行号。
  • '^# 配置JDK系统环境变量'：匹配以 # 配置JDK系统环境变量 开头的行。这是我最初追加环境变量时写的第一行注释，用它作为"删除起点"的标记。

⚠️ 注意 ：你的 /etc/profile 里自定义段的起始标记可能和我的不一样。请用 cat /etc/profile 或 tail -n 50 /etc/profile 看一下你的文件，找到你手工追加内容的第一行，用那一行作为删除标记。

确认找到了这一行后，执行删除：

bash 复制代码 
sed -i '/^# 配置JDK系统环境变量$/,$d' /etc/profile

命令解释：

  • sed -i：-i 表示直接修改原文件（in-place edit）。
  • '/^# 配置JDK系统环境变量$/,$d'：从匹配 # 配置JDK系统环境变量 的那一行开始，一直到文件末尾（$），全部删除（d）。

这条命令会把你从 # 配置JDK系统环境变量 到文件末尾的所有自定义内容删掉，保留系统默认部分和 /etc/profile.d 的自动加载逻辑。

删除后立即确认：

bash 复制代码 
tail -n 20 /etc/profile

看一下 /etc/profile 最后 20 行，应该已经看不到 export JAVA_HOME=...、export HADOOP_HOME=... 这些手写的变量了。如果还能看到，说明 grep 匹配的行不对，需要回去调整 sed 的匹配模式。

3.7 最终验证

先在当前会话验证：

bash 复制代码 
source /etc/profile
env | egrep 'JAVA_HOME|HADOOP_HOME|ZK_HOME|HBASE_HOME|SCALA_HOME|HIVE_HOME'

命令解释：

  • env：列出当前所有环境变量。
  • egrep：按正则表达式过滤，同时匹配多个关键词。这里是把所有我关心的变量一次性筛出来看。

然后再开一轮全新的 SSH 会话，做最终确认（是的，又开新会话------因为确认环境变量是否靠谱，只有新会话才能说明问题）：

hadoop1 最终验证：

bash 复制代码 
which java
which hdfs
which scala
which hive

预期 ：java、hdfs、scala 有结果，hive 没结果。

hadoop2 最终验证：

bash 复制代码 
which java
which hdfs
which scala
which hive

预期 ：java、hdfs 有结果，scala、hive 没结果。

hadoop3 最终验证：

bash 复制代码 
which java
which hdfs
which hive
hive --version

预期 ：java、hdfs、hive 有结果，hive --version 正常输出版本信息。

如果以上全部通过，恭喜，迁移彻底完成！

四、迁移完成后的最终状态

4.1 各节点 /etc/profile.d/ 文件清单

节点 文件列表
hadoop1 00-path-utils.sh、10-java.sh、20-hadoop.sh、30-zookeeper.sh、40-hbase.sh、45-scala.sh
hadoop2 00-path-utils.sh、10-java.sh、20-hadoop.sh、30-zookeeper.sh、40-hbase.sh
hadoop3 00-path-utils.sh、10-java.sh、20-hadoop.sh、30-zookeeper.sh、40-hbase.sh、50-hive.sh

4.2 彻底性检查清单

迁移完成后，用这几条命令做最终确认：

bash 复制代码 
# 1. /etc/profile 末尾不再有手写的 export
cat /etc/profile

# 2. /etc/profile.d/ 里有你创建的所有文件
ls -l /etc/profile.d/

# 3. 各节点的组件隔离正确
# hadoop1 上 which hive 没有结果（正确）
# hadoop2 上 which scala 和 which hive 没有结果（正确）
# hadoop3 上 which scala 没有结果（正确）
# 所有节点上 which java 和 which hdfs 有结果（正确）

五、与 systemd 服务托管的关系

如果你之前看过我的另一篇文章------把 Hive Metastore 从 nohup 迁移到 systemd 托管，你可能会问：既然环境变量已经迁移到 /etc/profile.d/ 了，systemd 服务文件里还需要写 Environment 吗？

答案是：需要，而且必须写。

给新手解释 systemd 和 /etc/profile 的关系：

/etc/profile 和 /etc/profile.d/*.sh 只在用户登录 shell 时被加载。也就是说，你 SSH 登录后打开的终端里，这些变量是有的。

但 systemd 启动的服务不是通过用户登录 shell 启动的 ，它走的是一套完全不同的启动流程。systemd 不会读 /etc/profile，也不会读 /etc/profile.d/ 下的任何文件。

所以，在 systemd 的 .service 文件里，必须用 Environment= 指令显式声明 服务运行所需的所有环境变量（JAVA_HOME、HADOOP_HOME、HIVE_HOME、PATH 等）。两边的配置是各管各的，互不替代。

简单来说：

  • /etc/profile.d/*.sh → 管你 SSH 登录后的终端环境
  • systemd .service 文件中的 Environment → 管 systemd 拉起来的服务进程的环境

两者缺一不可。

六、踩坑记录与经验总结

6.1 踩坑：不开新会话就急着删旧内容

我第一次做的时候，在当前终端 source /etc/profile 验证通过后，就直接删了 /etc/profile 里的旧内容。当时看起来一切正常，但其实这是因为旧变量还残留在当前 shell 的内存里。如果我当时 /etc/profile.d/ 的文件有写错的地方，下次重新登录就会发现环境变量全丢了。

教训：验证环境变量迁移，必须开新 SSH 会话。当前会话的结果不可信。

6.2 踩坑：忘记创建 path-utils 就创建了其他文件

我有一次在 hadoop2 上先创建了 10-java.sh，里面用了 append_path_once 函数，但忘了先创建 00-path-utils.sh。结果新开终端时看到报错：

复制代码 
-bash: append_path_once: command not found

功能上并没有完全失败（JAVA_HOME 变量是设置成功的），但 PATH 没有被正确追加。回去补上 00-path-utils.sh 后问题就解决了。

教训 ：00-path-utils.sh 必须在其他文件之前创建，并且文件名要确保排在最前面（00- 前缀）。

6.3 踩坑：文件权限不对导致不加载

有一次我用 vim 手动创建了一个 .sh 文件，保存后忘了设置权限。默认创建的文件权限可能是 600（只有 root 可读写），系统在加载 /etc/profile.d/ 时跳过了它。

教训 ：创建完 .sh 文件后，务必执行 chmod 644 /etc/profile.d/*.sh 确保权限正确。

6.4 经验：以后新增组件怎么办

从此以后，不要再改 /etc/profile 了。

以后在集群上安装新组件（比如 Spark、Flink、Kafka 等），直接在对应节点的 /etc/profile.d/ 下新建一个 .sh 文件就好。比如：

bash 复制代码 
cat >/etc/profile.d/60-spark.sh <<'EOF'
export SPARK_HOME=/export/servers/spark-3.x.x
append_path_once "$SPARK_HOME/bin"
EOF
chmod 644 /etc/profile.d/60-spark.sh

要禁用某个组件的环境变量，只需：

bash 复制代码 
# 方法一：重命名（推荐，可逆）
mv /etc/profile.d/60-spark.sh /etc/profile.d/60-spark.sh.bak

# 方法二：直接删除
rm /etc/profile.d/60-spark.sh

不需要再去改 /etc/profile，也不需要在一个大文件里定位和注释特定的行。

6.5 关于 hadoop3 上 hive.sh 的命名

我的 hadoop3 上最终的 Hive 环境变量文件是 hive.sh（没有数字前缀），这是因为我在之前做 systemd 迁移时就已经创建了它。功能上完全没问题------有没有数字前缀不影响加载。但如果你想统一命名风格，可以改名：

bash 复制代码 
mv /etc/profile.d/hive.sh /etc/profile.d/50-hive.sh

这不是必须的，只是让 ls /etc/profile.d/ 的输出更整齐。

七、备份文件的处理

迁移完成后，三台机器上都会有一个 /etc/profile.bak.* 备份文件。建议保留，不要删：

bash 复制代码 
ls /etc/profile.bak.*

这些备份文件不占多少空间，留着以防万一。如果哪天发现迁移有问题，可以直接：

bash 复制代码 
cp /etc/profile.bak.2026-03-10-153022 /etc/profile
source /etc/profile

一秒回滚。

八、总结

做了什么

  1. 把三台 Hadoop 节点的自定义环境变量，从 /etc/profile 末尾的"一锅炖"写法，拆分迁移到 /etc/profile.d/ 下独立的 .sh 文件
  2. 引入 00-path-utils.sh 防止 PATH 重复追加
  3. 按组件职责拆分：10-java.sh、20-hadoop.sh、30-zookeeper.sh、40-hbase.sh，节点差异部分单独处理（hadoop1 加 Scala，hadoop3 加 Hive）
  4. 经过"当前会话验证 → 新 SSH 会话验证 → 删除旧内容 → 再次新会话最终验证"四轮确认，确保迁移完全正确

为什么值得做

  • 环境变量管理更清晰、更规范
  • 多节点维护成本降低
  • 新增/删除组件变得简单安全
  • 消除了 PATH 重复追加问题
  • 为后续的 systemd 服务配置、自动化运维打好基础

给新手的建议

  1. 一开始搭环境时就用 /etc/profile.d/ 方式，不要等到后面再迁移
  2. 每次改完环境变量，都开新 SSH 会话验证 ，不要只在当前终端 source 后就认为成功了
  3. 改之前先备份 ，cp 一下只需要一秒钟，但能在出问题时救你一小时
  4. 不同节点需要不同组件时，按节点差异化配置，不要图省事在所有节点装一样的
  5. 记住一个原则：从此以后，不要再改 /etc/profile 了。以后新增组件，直接加 /etc/profile.d/NN-name.sh

本文基于个人实际操作环境编写，文中所有路径、版本号均为示例。请读者务必根据自己的实际环境调整后再执行。

相关推荐
IT从业者张某某2 小时前
Docker部署Hadoop-05-配置Docker容器的命名卷和挂载卷
hadoop·docker·容器
科技快报2 小时前
华为发布AI数据平台，重塑数据基座，加速企业AI应用落地
大数据·人工智能·华为
珠海西格2 小时前
红区蔓延的底层逻辑：分布式光伏爆发与配电网短板的“时空错配”
大数据·服务器·分布式·安全·架构
小马爱打代码2 小时前
分布式订单系统：订单号编码设计实战
分布式
我爱学习好爱好爱2 小时前
Elasticsearch 7.17.10 双节点集群部署（二）：安装 elasticsearch-head 插件实现可视化
大数据·linux·elasticsearch
Elastic 中国社区官方博客3 小时前
SearchClaw：将 Elasticsearch 通过可组合技能引入 OpenClaw
大数据·数据库·人工智能·elasticsearch·搜索引擎·ai·全文检索
weixin_505154464 小时前
博维数孪携手微软，打造智能电网数字化手册新标杆
大数据·人工智能·智慧城市·数字孪生·产品交互展示
T06205147 小时前
【数据集】“银发经济”百度搜索指数数据（2024.1.8-2026.3.8）
大数据
yxy___8 小时前
达梦分布式集群DPC_分区表重建与性能优化操作指南_yxy
分布式·性能优化·分区表
热门推荐
01GitHub 镜像站点02OpenClaw 使用和管理 MCP 完全指南03本地部署 OpenClaw + DeepSeek-R1 完全指南04得物前端部门，没了05OpenClaw 连接飞书完整指南：插件安装、配置与踩坑记录06OpenClaw 飞书机器人不回复消息？3 小时踩坑总结07Window 10部署openclaw报错node.exe : npm error code 12808OpenClaw macOS 完整安装与本地模型配置教程（实战版）09npm-error code 128问题解决方法10OpenClaw 接入 QQ Bot 完整实践指南