Apache Impala 分布式集群部署指南

目标：从零搭建 Apache Impala 4.5.3 分布式集群。Impala 原生支持多节点部署：一个集群由一个 statestored（心跳中枢）、一个 catalogd（元数据服务）与任意多个 impalad（查询引擎）组成。本文在统一网络 imparnet（192.168.150.0/24）内的 2 节点集群上实测：节点 1 承载全部基础组件（HDFS/HMS/statestored/catalogd/impalad），节点 2 为独立的第二个 impalad 执行节点。全文覆盖架构原理、节点规划、第二节点扩展、多节点验证（注册、查询、执行计划、PROFILE）、节点故障容错与扩容运维，命令与回显均为真实执行结果。

一、环境与节点规划

本文实测环境如下：

• 操作系统：Linux 服务器节点（amd64，OpenJDK 17，JAVA_HOME=/usr/lib/jvm/java-17-openjdk-amd64）；
• 软件栈：Apache Impala 4.5.3，配套 JDK 17/8、Hadoop/Hive 客户端与 Impala 二进制，部署目录 /opt/impala，依赖 HDFS（namenode/datanode）与 Hive Metastore（metastore）；
• 集群网络：统一网络 imparnet（192.168.150.0/24），statestored、catalogd 等短主机名全网可解析。

基础环境为全栈部署：节点 1 承载 namenode/datanode/metastore/statestored/catalogd/impalad 六个服务实例；在该基础上新增节点 2 的第二个 impalad（impalad2），形成 2 节点集群。节点规划如下：

二、部署前置条件

基础前置（全部就绪后才开始扩展节点 2，验证方法见下文）：

• HDFS 可用：namenode 9000 端口 OPEN，datanode 已注册；
• HMS 可用：metastore 9083 端口 OPEN；
• statestored 已启动：24000 OPEN；
• catalogd 已启动并连接 HMS：26000 OPEN，日志出现 Connected to metastore；
• 节点 1 的 impalad 已就绪：21000 OPEN。

2.1 服务状态

impala.sh 只查询本机 PID 文件，须在各节点分别执行。

在 statestored 节点执行：

/opt/impala/bin/impala.sh status statestored

在 catalogd 节点执行：

/opt/impala/bin/impala.sh status catalogd

在 impalad 节点执行：

/opt/impala/bin/impala.sh status impalad

真实回显：

statestored is running with PID 30.
catalogd is running with PID 32.
impalad is running with PID 47.

2.2 已注册节点

在 impalad 节点执行：

curl -s http://impalad:25000/backends

真实回显（关键部分）：

backend(s): 1

单节点阶段仅 1 个后端。

2.3 statestore 主题就绪

在 statestored 节点执行：

grep "Preparing initial catalog-update" /tmp/statestored.*.log.INFO.* | tail -1

真实回显：

I1007 11:31:54.434413    44 statestore.cc:515] Preparing initial catalog-update topic update for impalad@impalad:27000. Size = 259.00 B

Size = 259.00 B 表示目录主题已有数据，后续 impalad 可稳定订阅。

三、集群架构与角色

Impala 集群由三类守护进程组成，职责严格分工：

同步机制（两类主题）：

1. catalog-update 主题：catalogd 把元数据变更发布到 statestored，impalad 订阅该主题获得目录（-use_local_catalog=false 集中式模式）。
2. impalad 状态主题：每个 impalad 周期性上报自身状态（存活、执行能力），statestored 汇总广播，使所有 coordinator 知道哪些节点可用。

查询执行路径：客户端连任一 impalad（coordinator）→ coordinator 依据元数据生成分布式执行计划（SCAN/聚合/EXCHANGE 片段）→ 片段分发到全部存活 impalad（executor）并行执行 → 结果经 EXCHANGE 汇总回 coordinator。

四、扩展第二个节点（impalad2）

Impala 扩容只需新增 impalad 节点：启动脚本支持 ROLE 角色化启动，-hostname 取本机 hostname（$(hostname)），同一套 /opt/impala 部署可在新节点直接复用。将节点 2 加入与节点 1 相同的网络 imparnet，其 flags 中的 -catalog_service_host=catalogd、-state_store_host=statestored 由集群 DNS 解析到节点 1 的服务。

在节点 2 上部署并启动 impalad，要点如下：主机名设为 impalad2；加入集群网络 imparnet；以 ROLE=impalad 角色化启动；服务端口 21000/25000（对外端口 21001/25001）。

启动等待：启动脚本内 wait_port statestored 24000、wait_port catalogd 26000 探测通过后启动 impalad，轮询 25000 直到就绪。

节点 2 的 impalad 启动日志，真实回显：

Using JAVA_HOME: /usr/lib/jvm/java-17-openjdk-amd64
Using hadoop native libs in '/opt/hadoop/lib/native'
Service stdout is redirected to '/tmp/impalad.out'.
Service stderr is redirected to '/tmp/impalad.err'.
(1/20) impalad on port 25000 is not ready.
(2/20) impalad on port 25000 is not ready.
(3/20) impalad is ready.
[impalad] impalad 已启动

五、多节点验证（真实回显）

5.1 statestore 注册日志

在 statestored 节点执行：

grep "registered" /tmp/statestored.*.log.INFO.* | tail -4

真实回显：

I1007 11:31:44.669631    84 statestore.cc:570] Subscriber 'catalog-server@catalogd:26000' with type CATALOGD registered (registration id: b74f3f3ff1374f07:757978a8218afba3)
I1007 11:31:54.434285    85 statestore.cc:570] Subscriber 'impalad@impalad:27000' with type COORDINATOR AND EXECUTOR registered (registration id: d84eecce869396c7:69384375fe5694a3)

第二节点注册后追加：

Subscriber 'impalad@impalad2:27000' with type COORDINATOR AND EXECUTOR registered

（类型 COORDINATOR AND EXECUTOR 表示该 impalad 同时承担协调与执行。）

5.2 /backends 显示两个后端

在 impalad 节点执行：

curl -s http://impalad:25000/backends | grep -oE "impalad[0-9]*:[0-9]+" | sort -u

真实回显：

impalad:25000
impalad:27000
impalad2:25000
impalad2:27000

（WebUI 页面标题同时显示 backend(s): 2。）

5.3 从两个节点分别查询

节点 1 的 impalad 上执行：

export JAVA_HOME=/usr/lib/jvm/java-17-openjdk-amd64; \
  /opt/impala/shell/impala-shell -i impalad:21000 --protocol=beeswax \
  -q "SELECT id, name, salary FROM default.emp ORDER BY salary DESC;" --quiet

真实回显：

+----+-------+--------+
| id | name  | salary |
+----+-------+--------+
| 3  | Carol | 15000  |
| 1  | Alice | 12000  |
| 2  | Bob   | 9000   |
+----+-------+--------+
Fetched 3 row(s) in 0.52s

节点 2 的 impalad2（从节点 2 本机连接）：

export JAVA_HOME=/usr/lib/jvm/java-17-openjdk-amd64; \
  /opt/impala/shell/impala-shell -i impalad2:21000 --protocol=beeswax \
  -q "SELECT id, name FROM default.emp ORDER BY id LIMIT 2;" --quiet

真实回显：

+----+-------+
| id | name  |
+----+-------+
| 1  | Alice |
| 2  | Bob   |
+----+-------+
Fetched 2 row(s) in 0.71s

客户端也可通过节点 2 的对外端口 21001 直达 impalad2（-i 节点2的IP:21001），用法与 21000 相同。

5.4 分布式执行计划（EXPLAIN）

以 impalad2 为 coordinator 观察聚合查询的执行计划（在节点 2 上执行）：

export JAVA_HOME=/usr/lib/jvm/java-17-openjdk-amd64; \
  /opt/impala/shell/impala-shell -i impalad2:21000 --protocol=beeswax \
  -q "EXPLAIN SELECT dept, COUNT(*) FROM default.emp GROUP BY dept;" --quiet

真实回显（节选）：

| PLAN-ROOT SINK                                                                     |
| 04:EXCHANGE [UNPARTITIONED]                                                        |
| 03:AGGREGATE [FINALIZE]                                                            |
| 02:EXCHANGE [HASH(dept)]                                                           |
| 01:AGGREGATE [STREAMING]                                                           |
| 00:SCAN HDFS [default.emp]                                                         |

执行路径解读：00:SCAN HDFS（各节点并行扫描数据文件）→ 01:AGGREGATE [STREAMING]（各节点本地预聚合）→ 02:EXCHANGE [HASH(dept)]（按 dept 键跨节点重分布）→ 03:AGGREGATE [FINALIZE]（汇总节点最终聚合）→ 04:EXCHANGE [UNPARTITIONED]（结果回传 coordinator）→ PLAN-ROOT SINK（返回客户端）。两个 EXCHANGE 片段正是分布式并行执行的分界线。

5.5 PROFILE 跨节点资源统计

在节点 1 的 impalad 上执行：

export JAVA_HOME=/usr/lib/jvm/java-17-openjdk-amd64; \
  /opt/impala/shell/impala-shell -i impalad:21000 --protocol=beeswax -p \
  -q "SELECT COUNT(*) FROM default.emp;" --quiet

真实回显（节选）：

  Summary:
Max Per-Host Resource Reservation: Memory=8.00KB Threads=3
Per-Host Resource Estimates: Memory=10MB
    Per Host Min Memory Reservation: impalad2:27000(8.00 KB) impalad:27000(0)
    Cluster Memory Admitted: 20.00 MB

Per Host Min Memory Reservation: impalad2:27000(8.00 KB) impalad:27000(0) 直接证明查询被分发到两个执行节点执行，两个后端都参与片段执行。

六、节点故障容错实测（真实回显）

分布式集群的韧性：执行节点失联后，其余节点继续服务查询。

6.1 停止节点 2

停止节点 2 上的 impalad 进程。

6.2 statestore 心跳失败判定

等待约 15 秒（心跳频率 1000ms，连续失败阈值触达），在 statestored 节点查看日志：

grep -iE "impalad2.*(failed|disconnected)" /tmp/statestored.*.log.INFO.* | tail -2

真实回显：

I1007 11:45:57.587165    66 failure-detector.cc:91] 10 consecutive heartbeats failed for 'impalad@impalad2:27000'. State is FAILED
I1007 11:45:57.587172    66 statestore.cc:1432] Subscriber 'impalad@impalad2:27000' has failed, disconnected or re-registered (last known registration ID: c24405dce917b7f9:f1f7c364eee392a4)

10 consecutive heartbeats failed ... State is FAILED：statestored 连续 10 次心跳失败（约 10 秒）后将节点标记 FAILED 并广播，各 coordinator 不再向该节点分发新查询片段。

6.3 失联期间查询不受影响

在节点 1 的 impalad 上执行：

export JAVA_HOME=/usr/lib/jvm/java-17-openjdk-amd64; \
  /opt/impala/shell/impala-shell -i impalad:21000 --protocol=beeswax \
  -q "SELECT COUNT(*) FROM default.emp;" --quiet

真实回显：

+----------+
| count(*) |
+----------+
| 3        |
+----------+
Fetched 1 row(s) in 0.05s

查询在节点 1 上正常完成。

6.4 恢复节点 2

重新启动节点 2 上的 impalad 进程。等待约 20 秒后，节点重新注册（/backends 恢复两个后端），在 impalad 节点执行：

curl -s http://impalad:25000/backends | grep -oE "backend\(s\): [0-9]+" | head -1

真实回显：

backend(s): 2

6.5 注意事项（实测发现）

• 冻结而非停止时，进行中的查询会挂起：若执行节点进程被冻结（不响应但未断开），已分发到该节点的 fragment 无响应，coordinator 会在查询级等待（默认无 exec_time_limit_s 时限时查询长时间挂起）。生产环境应设置 exec_time_limit_s 或依赖 statestore 失联判定后由客户端重试。
• 停止（SIGTERM）节点时 statestore 立即收到断开事件，失联判定快；kill -9 则依赖心跳超时（约 10 秒）。

七、角色分离配置（专用 Coordinator/Executor）

默认每个 impalad 同时是 coordinator 与 executor。大规模集群可分离角色以优化资源：

• 专用协调节点（-is_coordinator=true -is_executor=false）：只接收客户端连接、做分布式调度，不参与片段执行，适合作为统一的 SQL 接入层。
• 专用执行节点（-is_coordinator=false -is_executor=true）：不接收客户端连接（拒绝 21000/21050），专注执行片段，适合作为纯计算资源池。

真实 -help 原文：

    -is_coordinator (If true, this Impala daemon can accept and coordinate
      queries from clients. If false, it will refuse client connections.)
      type: bool default: true
    -is_executor (If true, this Impala daemon will execute query fragments.)
      type: bool default: true

配置示例（专用执行节点，impalad_flags）：

-hostname=impala-exec3
-catalog_service_host=catalogd
-state_store_host=statestored
-is_coordinator=false
-is_executor=true
-mem_limit=3072m
-use_local_catalog=false

客户端仅连接专用协调节点列表（可前置负载均衡），执行节点对客户端不可见。

八、集群级 JVM 与内存配置

8.1 JVM 堆 256-512MB（全节点一致）

每个节点（catalogd 所在节点与所有 impalad 节点）的 /opt/impala/conf/impala-env.sh 保持相同的 JVM 堆约束：

export JAVA_TOOL_OPTIONS=${JAVA_TOOL_OPTIONS:- -Xms256m -Xmx512m}

• -Xms256m 初始堆 256MB、-Xmx512m 最大堆 512MB，JVM 启动时自动读取，作用于 impalad Frontend 与 catalogd 的 JVM 部分。
• 调整示例：sed -i 's/-Xms256m -Xmx512m/-Xms512m -Xmx1g/' /opt/impala/conf/impala-env.sh，然后重启该节点对应服务（catalogd 节点重启 catalogd，impalad 节点重启 impalad）。
• 验证：grep -E "JAVA_TOOL_OPTIONS|Xmx|Xms" /tmp/impalad.*.log.INFO.* | tail -2。

8.2 进程内存

impalad_flags 的 -mem_limit 按节点规格单独设置（4 核/8G 机器建议 1536m-3072m），catalogd 节点建议预留 1GB 以上给目录缓存：

-mem_limit=3072m

九、扩容与运维要点

9.1 扩容流程

1. 准备新节点：基于同一套部署（含 JDK 17/8、Hadoop/Hive 客户端、Impala 二进制）完成 impalad 安装；
2. 加入集群网络：接入 imparnet，确保 statestored、catalogd 短主机名可解析；
3. 设置唯一 hostname：如 impalad2（决定 -hostname 与注册标识）；
4. 以 ROLE=impalad 角色化启动，设置对外端口（21000/25000 等，避免与已有节点端口冲突）；
5. 验证：statestore 日志出现 Subscriber 'impalad@<hostname>:27000' ... registered，/backends 计数增加；
6. 下线节点：停止该节点 impalad 进程，等待 statestore 标记 FAILED 后 /backends 自动减员。

9.2 安全说明

Impala 4.5.3 默认无内置认证，集群内任何能到达 21000/21050 的客户端均可执行 SQL。生产环境：所有节点启用 TLS（-server_credentials）与 LDAP/Kerberos（-principal/-keytab_file），客户端与执行节点间的通信走 KRPC 27000 也应纳入受控网络。系统管理凭据：root / q1w2e3r4（演示环境专用）。

十、常见问题

• 节点启动后 /backends 不增加：检查该节点能否解析 statestored/catalogd（getent hosts statestored），以及 -state_store_port/-catalog_service_port 是否与节点 1 一致。
• 新节点反复启动失败（Waiting for local catalog）：确认 catalogd 已先就绪且目录主题 Size>0（见 2.3 节）；集中式目录场景必须保证 catalogd 先于 impalad 稳定运行。
• 主机名解析不一致：所有节点必须使用彼此可解析的唯一主机名（同一集群网络内的 hostname），否则注册/心跳对不上。
• 网络名/主机名含下划线：集群网络名或主机名含下划线会导致 catalogd 连接 HMS 时 Java URI 解析失败（Illegal character in hostname），务必使用不含下划线的网络名与主机名。

十一、参考链接

• Apache Impala 官网：https://impala.apache.org/
• Apache Impala 官方文档：https://impala.apache.org/impala-docs.html