企业官网建设流程全解析

1. 为什么值得花时间把 Dremio 部署这件事讲透

Dremio 这个数据湖查询引擎，圈子里的人对它感情挺复杂。爱的是它那套基于 Apache Arrow 的向量化执行引擎，查 Parquet、Iceberg、Delta Lake 这些湖上格式的速度确实能打，还能直接对接对象存储做数据虚拟化；恨的是它的部署文档散落在官方手册、社区帖子和各种版本差异里，新手照着走经常卡在内存分配、ZooKeeper 连接、元数据存储这几步上。我自己前前后后在不同环境里部署过七八次 Dremio，从单机测试到多节点集群都踩过，这篇就把完整流程和那些文档里不会写的坑一次性讲清楚。

先说清楚这篇适合谁看。如果你手上有一堆存在对象存储或者 HDFS 上的 Parquet 文件，想找个不搬数据就能直接查的工具，Dremio 是对路子的；如果你是数据平台运维，需要给团队搭一套稳定的查询服务，那部署环节的每个参数你都得抠明白。这篇不假设你有多少前置知识，但会默认你懂基本的 Linux 操作和网络概念。整个流程我会按“规划—准备—部署—验证—调优”的顺序走，每一步都告诉你为什么这么做，而不是让你无脑复制命令。

需要提前说明的是，Dremio 的版本迭代比较快，不同大版本之间配置项有差异。我下面讲的内容以社区版和企业版的通用逻辑为主，具体参数名你对照自己下载的版本手册微调。另外，部署方式我推荐用 tar 包手动部署而不是 Docker，原因后面会讲，主要是为了让你对每个组件的资源占用和依赖关系有完全的控制权，出问题也好排查。

2. 部署前的整体规划与方案选型

2.1 先搞清楚 Dremio 的架构角色划分

Dremio 在集群里不是所有节点都干一样的活，它把角色分得很清楚，你部署前必须先把角色规划好，否则后面扩容或者调优会非常被动。核心角色有三个：Coordinator（协调节点）、Executor（执行节点）和ZooKeeper（协调服务）。Coordinator 负责接收查询、解析 SQL、生成执行计划、管理元数据，是整个集群的大脑；Executor 负责实际的数据扫描和计算，是干体力活的；ZooKeeper 则是用来做集群成员管理和选主的高可用组件。

这里有个关键点很多人忽略：Coordinator 本身也可以承担 Executor 的职责，在单机或者小规模场景下，一个节点同时跑这两个角色完全没问题。但一旦你的数据量上到 TB 级别、并发查询多起来，就必须把 Coordinator 和 Executor 拆开，因为 Coordinator 对内存和 CPU 的稳定性要求极高，它一抖动整个集群的查询都会受影响。我的经验是，当集群总内存超过 256GB 或者日常并发查询超过 20 个时，就该考虑拆分角色了。

ZooKeeper 这块，如果你只是单节点测试，Dremio 内置了一个嵌入式 ZooKeeper，不用你单独装。但生产环境强烈建议用外部独立部署的 ZooKeeper 集群，至少三个节点，因为嵌入式 ZooKeeper 在 Coordinator 重启时会丢失集群状态，导致所有 Executor 需要重新注册，这个过程中查询会全部失败。

2.2 硬件资源怎么估算才不浪费也不卡顿

资源估算是部署里最容易拍脑袋的环节，我给一套我自己在用的估算逻辑。Dremio 的性能瓶颈通常不在 CPU 而在内存和磁盘 IO，尤其是做聚合和 Join 的时候，中间结果会大量占用内存。

对于 Coordinator 节点，内存建议不低于 32GB，其中要给 JVM 堆分配 16GB 左右，剩下的留给操作系统做页缓存和 Dremio 的堆外内存。CPU 方面 8 核起步，因为 Coordinator 要处理查询解析和计划生成，单核性能比核数更重要。磁盘用 SSD，至少 100GB，主要放元数据（如果用本地存储模式）和日志。

对于 Executor 节点，内存是核心。一个粗略的公式是：每个 Executor 的内存 = 数据分片大小 × 并发查询数 × 1.5（安全系数）。举个例子，如果你单次查询要扫描 50GB 的数据，同时跑 4 个查询，那内存至少得 50×4×1.5 = 300GB。当然实际不会这么夸张，因为 Dremio 会做流式处理和溢写磁盘，但内存给足了查询体验完全不一样。CPU 建议 16 核以上，磁盘用 NVMe SSD，因为 Executor 要频繁读写临时溢写文件。

网络这块很多人不当回事。Coordinator 和 Executor 之间的数据传输量很大，尤其是 Shuffle 阶段，万兆网卡是底线，千兆网卡在数据量上来后会成为明显瓶颈。我实测过，同样的查询在千兆和万兆环境下，耗时能差三倍以上。

2.3 部署方式选 tar 包还是容器

Dremio 官方提供了 tar 包、RPM/DEB 包和 Docker 镜像几种部署方式。我推荐生产环境用 tar 包手动部署，原因有三个。第一，tar 包部署让你对安装路径、配置文件位置、日志目录有完全的控制权，排查问题时不用去猜容器里的路径映射。第二，容器部署虽然启动快，但 Dremio 对内存和磁盘 IO 的要求比较特殊，容器资源限制配置不当很容易出现 OOM 或者性能骤降。第三，tar 包升级和回滚都更直观，直接替换目录就行，容器升级涉及镜像和卷的配合，反而更麻烦。

当然，如果你只是想在本地快速体验一下，Docker 确实方便，一条命令就能跑起来。但只要你打算把它用在任何有实际数据量的场景，tar 包是更稳妥的选择。下面我的实操流程也以 tar 包部署为主线。

3. 部署前的环境准备与依赖检查

3.1 操作系统层面的基础配置

Dremio 对操作系统的要求不算苛刻，主流 Linux 发行版都能跑，我常用的是 CentOS 7.x 和 Ubuntu 20.04 这两个。不管用哪个，有几项系统配置必须提前做好，否则部署到一半会报各种莫名其妙的错。

第一是文件句柄数限制。Dremio 在查询时会打开大量文件，默认的 1024 根本不够。你需要修改/etc/security/limits.conf，加上这几行：

* soft nofile 65536 * hard nofile 65536 * soft nproc 65536 * hard nproc 65536

改完后用ulimit -n确认生效。这里有个坑，如果你是用 systemd 管理 Dremio 服务，limits.conf 对 systemd 启动的进程不生效，还得在 service 文件里加LimitNOFILE=65536。

第二是内存映射区域数量。Dremio 的 Arrow 引擎会大量使用内存映射文件，默认的vm.max_map_count是 65530，建议调到 262144：

sysctl -w vm.max_map_count=262144 echo "vm.max_map_count=262144" >> /etc/sysctl.conf

第三是关闭透明大页（THP）。THP 会导致 Dremio 的 JVM 出现不可预测的停顿，必须关掉：

echo never > /sys/kernel/mm/transparent_hugepage/enabled echo never > /sys/kernel/mm/transparent_hugepage/defrag

这几项配置看着琐碎，但少做一项后面都可能让你花几个小时去排查一个本可以避免的问题。

3.2 Java 环境的准备与版本选择

Dremio 自带了一个捆绑的 JDK，所以你理论上不需要单独装 Java。但这里有个细节：Dremio 捆绑的 JDK 版本和你的操作系统、Dremio 版本都有关系，某些组合下会出现兼容性问题。我的建议是，优先使用 Dremio 自带的 JDK，除非你明确知道自己在做什么。如果你非要指定外部 JDK，需要在dremio-env文件里设置JAVA_HOME，而且 JDK 版本必须和 Dremio 要求的版本匹配，一般是 JDK 8 或 JDK 11，具体看版本说明。

检查 Java 环境是否就绪，可以解压 Dremio 安装包后运行：

cd /opt/dremio bin/dremio --version

如果这条命令能正常输出版本号，说明 Java 环境没问题。如果报错，先看JAVA_HOME是否设置正确，再看捆绑 JDK 的目录权限是否正常。

3.3 存储与目录规划

Dremio 需要几个关键目录：安装目录、数据目录（存放元数据和临时文件）、日志目录。我习惯这样规划：

数据目录这块要特别说一下。Dremio 的元数据默认存在本地，如果你用嵌入式 ZooKeeper 和本地元数据存储，那这个目录就是整个集群的命根子，必须做好定期备份。生产环境更推荐把元数据存到外部数据库（比如 PostgreSQL），这样 Coordinator 节点故障时恢复起来容易得多。

4. 单节点部署的完整实操流程

4.1 下载与解压安装包

先从官方渠道获取对应版本的 tar 包。下载完成后，用非 root 用户来运行 Dremio 是更安全的做法，我一般会创建一个专用的dremio用户：

useradd -m -s /bin/bash dremio mkdir -p /opt/dremio /data/dremio /var/log/dremio chown -R dremio:dremio /opt/dremio /data/dremio /var/log/dremio

然后切换到 dremio 用户解压：

su - dremio tar -xzf dremio-community-*.tar.gz -C /opt/dremio --strip-components=1

解压后你会看到bin、conf、jars、plugins这几个目录。conf目录是后面配置的重点，bin目录里是启动脚本。

4.2 核心配置文件详解

Dremio 的配置主要在两个文件里：conf/dremio.conf和conf/dremio-env。前者管集群角色和路径，后者管 JVM 参数和环境变量。

先看dremio-env，这个文件里最关键的是内存分配。找到DREMIO_MAX_MEMORY_SIZE_MB这个参数，它控制 JVM 堆的最大值。我的经验是，堆内存不要超过物理内存的 50%，剩下的留给堆外内存和操作系统。比如 64GB 内存的机器，堆设 28GB 左右比较合适：

DREMIO_MAX_MEMORY_SIZE_MB=28672 DREMIO_MAX_DIRECT_MEMORY_SIZE_MB=16384

DREMIO_MAX_DIRECT_MEMORY_SIZE_MB是堆外内存，Arrow 引擎会大量使用，这个值给足了查询性能会明显提升。但注意堆内存加堆外内存不能超过物理内存，否则会被系统 OOM Killer 干掉。

再看dremio.conf，单节点部署的核心配置大概是这样：

paths: { local: "/data/dremio" dist: "pdfs:///data/dremio/pdfs" } services: { coordinator: { enabled: true, master: { enabled: true, port: 45678 } }, executors: { enabled: true, count: 1 } } zookeeper: "localhost:2181"

这里paths.local是数据目录，paths.dist是分布式存储路径，单节点用pdfs://本地文件系统就行。services.coordinator.master.enabled设为 true 表示这个节点是主 Coordinator。zookeeper指向本地，因为单节点用嵌入式 ZooKeeper。

4.3 启动服务与首次访问

配置改完后，用这个命令启动：

bin/dremio start

启动过程会输出日志到log/dremio.log，你可以用tail -f盯着看。第一次启动会初始化元数据，大概需要一两分钟。看到日志里出现Dremio is up and running就说明启动成功了。

然后浏览器访问http://<节点IP>:9047，这是 Dremio 的 Web UI 端口。首次访问会让你创建管理员账号，填好邮箱和密码后进入主界面。这时候你可以先建一个简单的数据源测试一下，比如连一个本地的 Parquet 文件目录，跑个SELECT * LIMIT 10看看能不能出结果。

注意：9047 是 Web UI 端口，9048 是 ODBC/JDBC 端口，45678 是节点间通信端口。防火墙规则要把这几个端口都放开，尤其是多节点部署时 45678 必须互通。

5. 多节点集群部署的关键差异点

5.1 Coordinator 与 Executor 的配置区分

多节点部署时，Coordinator 和 Executor 的dremio.conf配置不一样，这是最容易搞混的地方。Coordinator 节点的配置里，services.coordinator.enabled设为 true，services.executors.enabled设为 false（除非你想让它也承担计算任务）。Executor 节点则反过来：

# Executor 节点配置 services: { coordinator: { enabled: false }, executors: { enabled: true, count: 4 } }

executors.count表示这个节点上启动几个 Executor 进程，一般设成 CPU 核数的一半左右，因为每个 Executor 进程都会占用独立的内存。比如 32 核的机器，设 4 到 8 个比较合理，具体看内存大小。

5.2 ZooKeeper 集群的接入配置

生产环境用外部 ZooKeeper 集群时，所有节点的dremio.conf里都要指向 ZooKeeper 集群地址：

zookeeper: "zk1:2181,zk2:2181,zk3:2181"

这里有个坑：ZooKeeper 的连接串必须用主机名而不是 IP，因为 Dremio 在注册节点时用的是主机名，如果 ZooKeeper 里存的是 IP 而节点间通信用主机名，会出现节点互相找不到的情况。所以要么统一用主机名，要么在/etc/hosts里把主机名和 IP 的映射配好。

另外，ZooKeeper 的zoo.cfg里maxClientCnxns默认是 60，Dremio 集群节点多的时候会不够用，建议调到 200 以上。

5.3 元数据存储的外部化

单节点用本地元数据没问题，但多节点必须把元数据存到外部数据库，否则 Coordinator 切换时元数据不一致会导致集群状态混乱。Dremio 支持 PostgreSQL、MySQL 等作为元数据存储。配置方式是在dremio.conf里加：

metadata: { database: { type: "postgresql", host: "pg-host", port: 5432, database: "dremio", username: "dremio", password: "yourpassword" } }

数据库要先建好，Dremio 启动时会自动建表。这里要注意数据库的连接数限制，Dremio 集群规模大时连接需求也大，PostgreSQL 的max_connections默认 100 可能不够，建议调到 300 以上。

6. 部署后的验证与性能调优

6.1 集群健康状态检查清单

部署完成后别急着上业务，先按这个清单过一遍。第一，Web UI 的 Settings 里看 Nodes 页面，所有 Coordinator 和 Executor 都应该显示为 Online 状态。第二，随便建一个数据源，跑几个不同类型的查询（全表扫描、聚合、Join），确认都能正常返回。第三，看 Executor 的日志里有没有OutOfMemory或者Direct buffer memory相关的报错。第四，用jps命令确认 Dremio 的 Java 进程都在运行。

我整理了一个快速检查表：

6.2 查询性能调优的几个关键参数

Dremio 的性能调优空间很大，但部署阶段先把这几个参数调好，能解决大部分性能问题。第一个是dremio.executor.memory，控制单个 Executor 的内存上限，前面已经讲过。第二个是dremio.exec.work.foreman.heap，控制查询协调线程的堆大小，并发高的时候要适当调大。

第三个是溢写策略。Dremio 在内存不足时会把中间结果写到磁盘，这个行为由dremio.exec.sort.external和dremio.exec.join.external控制。如果你的查询经常溢写，说明内存不够，要么加内存要么优化查询。但溢写本身不是坏事，它保证了查询不会因为内存不足而失败，只是速度会慢。

第四个是并行度。dremio.exec.work.foreman.parallelism控制查询的并行执行程度，默认值在大多数场景下够用，但数据量特别大时可以适当调高。不过并行度不是越高越好，太高会导致资源争抢，反而变慢。

6.3 日志与监控的配置建议

Dremio 的日志默认输出到log/dremio.log，但默认级别是 INFO，排查问题时可能需要调到 DEBUG。修改conf/logback.xml里的日志级别即可，但注意 DEBUG 级别会产生大量日志，排查完记得调回来。

监控方面，Dremio 暴露了 JMX 接口，可以用 Prometheus 的 JMX Exporter 采集指标。关键指标包括：查询队列长度、Executor 内存使用率、溢写文件大小、查询平均耗时。这些指标能帮你提前发现瓶颈，而不是等用户投诉了才去查。

7. 常见问题排查与避坑经验

7.1 启动失败类问题速查

启动失败是最常见的问题，我按出现频率排了个序。排第一的是端口被占用，Dremio 默认用 9047、9048、45678、2181 这几个端口，如果机器上已经有服务占了，启动会直接失败。用netstat -tlnp | grep <端口>确认，然后改dremio.conf里的端口配置。

排第二的是权限问题。Dremio 进程需要对数据目录和日志目录有读写权限，如果之前用 root 跑过，目录属主变成 root 了，再用 dremio 用户启动就会失败。用chown -R dremio:dremio修复。

排第三的是内存配置过大。如果DREMIO_MAX_MEMORY_SIZE_MB设得比物理内存还大，JVM 启动时会直接报错退出。检查dremio-env里的配置，确保堆内存加堆外内存不超过物理内存的 80%。

7.2 查询报错类问题排查思路

查询报错的花样就多了，但有几个高频的。“Direct buffer memory”错误说明堆外内存不够，调大DREMIO_MAX_DIRECT_MEMORY_SIZE_MB。**“Query cancelled”通常是查询超时或者资源不足，看 Coordinator 日志里的具体原因。“Connection refused”**是节点间通信问题，检查 45678 端口是否互通。

还有一个比较隐蔽的问题：查询结果不正确。这通常和数据类型推断有关，Dremio 在读取 Parquet 时会自动推断 schema，如果推断错了，查询结果就会有问题。解决办法是在数据源配置里手动指定 schema，或者用 SQL 的CAST显式转换。

7.3 那些文档里不会写的实操心得

说几个我踩过的坑。第一，不要在 Dremio 运行时直接改配置文件然后重启，有些配置项改了之后需要清理元数据才能生效，直接重启可能导致集群状态不一致。正确做法是先停服务，改配置，必要时清理paths.local下的缓存目录，再启动。

第二，Executor 节点的executors.count不要设太大。我见过有人为了追求并行度把 count 设成 CPU 核数，结果每个 Executor 分到的内存很少，查询频繁溢写，整体性能反而下降。一般设成 CPU 核数的四分之一到二分之一比较合理。

第三，升级前一定要备份元数据。Dremio 的元数据存在数据库或者本地目录里，升级过程中如果元数据迁移失败，回滚会很麻烦。备份元数据数据库或者paths.local目录，花不了几分钟，但能救命。

第四，测试环境不要用生产数据。我见过有人在测试环境直接挂生产数据源跑查询，结果一个全表扫描把生产存储的 IO 打满了。测试环境用数据子集或者脱敏数据，这是基本纪律。

8. 部署完成后的收尾与后续扩展

部署完、验证过、调优完，还有几件收尾的事要做。第一是把启动脚本加到 systemd 里，实现开机自启和进程守护。Dremio 自带的bin/dremio start是前台启动的变体，用 systemd 管理更规范。写一个 service 文件，设置好User、ExecStart、Restart=on-failure就行。

第二是配置日志轮转，防止日志把磁盘写满。Dremio 的 logback 配置里可以设置日志文件大小和保留数量，或者用系统的 logrotate 来管理。

第三是规划扩容路径。Dremio 的扩容主要是加 Executor 节点，新节点配置好dremio.conf指向同一个 ZooKeeper 集群，启动后会自动注册进来。Coordinator 的扩容比较麻烦，因为涉及元数据存储的切换，一般不建议频繁扩 Coordinator。

后续如果数据量继续增长，可以考虑把元数据存储从 PostgreSQL 换成更高并发的数据库，或者把溢写目录从本地 SSD 换成更高 IOPS 的存储。但这些都属于进阶优化了，先把基础部署跑稳，再根据实际瓶颈逐步调整。

我个人在实际操作中的体会是，Dremio 部署的难点不在步骤本身，而在对资源规划和角色划分的理解。你把内存、磁盘、网络这三样算清楚了，配置项照着改，基本不会出大问题。反倒是那些急着跑起来、跳过规划环节的，后面往往要花更多时间返工。慢就是快，这话在数据平台部署上特别成立。