先讲个我实际装Doris遇到的场景。那会儿要给一套自建的数据平台搭分析引擎团队里有人提了Doris理由是它能直接读MySQL生态的语法、查询响应快报表和即席分析都不用再折腾Hive那套动不动几十秒的等待。结果一上手才发现安装本身并不复杂真正的坑全在配置细节上——FE的元数据目录放错地方、BE的内存上限没算好、集群注册后心跳不通随便一个都能让人排查到半夜。这篇文章不是那种照着官方文档念一遍的安装手册而是从零部署3节点Doris集群的完整记录。我会把每个关键配置项背后的原因说清楚再把部署链路从头到尾走一遍前置规划、FE安装、BE安装、集群注册、建表验证、高可用扩展、资源隔离最后是我实际踩过的坑和排查过程。适合正在评估Doris、或者准备在生产环境部署Doris的运维同学和数据工程师参考。1. 动手前先搞清楚部署角色和版本选择1.1 FE和BE的分工装之前先画一张部署图很多人第一次装Doris上来就解压、启动然后发现两台机器各跑了一个进程却完全不知道它们之间是什么关系。Doris的部署角色其实非常清晰安装之前必须先把这张分工图刻在脑子里。FEFrontend负责元数据管理、接收客户端SQL、生成执行计划、把任务分发给BE、汇总结果返回。它不存业务数据但它知道每份数据在哪个BE上。BEBackend负责数据存储和实际计算。每个BE上存放一部分数据副本执行FE下发的查询任务。打个比方FE像餐厅的前台接待负责记座位、接订单、安排后厨出菜顺序BE像后厨加库房菜和食材都在它这儿真正干活的是它。一台BE宕机只要副本数足够数据不会丢FE宕机整个集群就失去对外服务能力所以FE的数量和部署规格反而比BE更敏感。部署形态上需要注意单机部署一个FE一个BE只能用来跑通Demo生产环境我强烈建议FE和BE分开部署原因有两方面一是FE元数据读写和BE的数据落盘都是IO敏感型任务混在一起会互相干扰二是生产上FE需要保证多副本BE又需要弹性扩容两者资源规划方向完全不同。放一台机器上扩容一个的时候另一个也被迫跟着动非常被动。1.2 版本怎么选别追新选能落地的版本选择是我每次都要强调的点。Doris社区版本迭代速度很快各种新功能看着很诱人但对于要搭生产集群的团队来说稳定性和文档完整性远比新特性重要。我个人的建议是选择Apache Doris 2.1系列的LTS版本而不是追3.x的开发线。2.1这个系列已经打磨得比较久网上能搜到的踩坑案例、第三方数据同步方案、监控插件都更成熟。下载的时候直接拿官方发布页的release tar包除非你有定制源码的需求否则不要自己从源码编译——编译耗时不说还容易因为依赖版本问题卡住纯属浪费时间。如果你是从旧版本比如1.x迁移过来的不要想当然地直接替换二进制文件。Doris某些版本之间的元数据格式是不兼容的升级前一定查对应版本的升级文档有的跳版本升级还需要做元数据转换这部分操作不可逆必须谨慎再谨慎。1.3 硬件规划与环境检查清单这里给出一套我比较推荐的最小生产形态3台FE 3台BE总数据量在TB级别以内完全够用。FE对CPU要求不高8核16G的小机器就能跑内存建议预留16G以上给JVM堆。BE则要把重点放在磁盘和随机IO上一个BE挂一块大容量SSD或HDD阵列CPU核数越多越好毕竟查询计算都在BE上。数据副本数是另一个关键决策。Doris的表默认副本数可以按表指定生产环境至少2份、推荐3份。注意这个前提是BE数量要大于等于副本数否则系统会提示副本数不可用。比如你要设3副本BE数量必须至少3台如果你只有2台BE可以把表副本数设为2但机器故障的容忍度就比较低了。环境检查清单我列了一份照着过一遍基本能避免后面80%的奇怪问题JDK8或JDK11按你下载的Doris版本要求来提前装好并配好JAVA_HOME文件句柄数ulimit -n至少设为65536否则导入大文件时会瞬间报Too many open files时钟同步所有节点开启NTP或chronyFE节点之间时间偏差太大会导致选举异常后面坑里细说防火墙/安全组提前放行FE和BE之间的内网端口透明大页THP建议关闭BE在内存分配时受THP影响可能出现延迟抖动2. FE安装元数据目录是最容易被低估的配置2.1 下载解压与目录规划FE安装的第一步不是解压而是先想好目录结构。我见过不少人在系统盘上把Doris解压到默认目录装完才发现元数据把根分区写满了回头再挪目录非常折腾。建议规划如下把安装程序、元数据、数据目录分开# 前置准备创建统一软件目录和数据目录 mkdir -p /opt/doris /data/doris/fe-meta # 下载并解压 tar -zxvf apache-doris-2.1.7-bin-x64.tar.gz mv apache-doris-2.1.7-bin-x64 /opt/doris/doris-fe这里的关键点是/data/doris/fe-meta也就是FE元数据目录我会在下一节专门讲它为什么重要。目录权限要注意如果后续要用非root用户启动Doris进程就要确保这个用户对/opt/doris和/data/doris都有读写权限否则启动时创建meta文件会失败。2.2 fe.conf里的几个关键配置项进入/opt/doris/doris-fe/conf目录找到fe.conf文件。默认配置能跑但绝对不适合生产至少要改下面这几个参数配置项默认值说明meta_dir${DORIS_HOME}/doris-metaFE元数据目录必须改到独立数据盘http_port8030Web管理界面和部分REST接口端口rpc_port9020FE与FE之间的RPC通信端口query_port9030客户端MySQL协议连接端口edit_log_port9010FE组内元数据同步的BDB JE通信端口max_java_heap_size8GFE JVM堆大小根据FE节点内存调整meta_dir是第一个必须改的项。FE的元数据由镜像文件image和操作日志edit log组成平时看起来不大但checkpoint机制会周期性生成新的镜像文件日志也会持续追加。这些全是小文件、大量IO如果放在系统盘根分区很容易把根分区空间吃紧进而影响操作系统本身的稳定性。我见过不止一次因为meta目录放系统盘最后根分区满了导致FE无法启动的情况。把它放到独立数据盘上既避免挤压系统空间也能降低磁盘IO干扰系统其他进程。max_java_heap_size容易被低估。FE进程的本质是一个JVM服务太小了元数据缓存和SQL解析容易频繁Full GC导致查询RT不稳定太大了也没必要FE并不像BE那样在内存中缓存大量数据块。我的经验是8G起步16G封顶再大基本是浪费。其余几个端口建议保持默认除非你的网络环境真有冲突。集群内部端口规划只要统一就能避免后续排查时多个节点端口不一致的问题。修改后的最小配置大概是这样的# fe.conf meta_dir /data/doris/fe-meta http_port 8030 rpc_port 9020 query_port 9030 edit_log_port 9010 max_java_heap_size 8G2.3 启动FE并验证配置改完就可以启动了。FE的启动很简单但必须记住启动后不会像MySQL那样立刻就能连接要等几秒到几十秒完成初始化。cd /opt/doris/doris-fe sh bin/start_fe.sh --daemon # 查看启动日志 tail -f log/fe.log日志里出现finish字样或者不再有异常堆栈报错说明FE启动完成。然后用MySQL客户端连上去验证mysql -h 127.0.0.1 -P 9030 -uroot能进MySQL命令行就意味着FE已经工作了。如果连不上优先检查fe.log尾部日志而不是反复重启进程——日志基本会把问题原因写得非常清楚比如端口被占、JDK版本不对、权限不足。3. BE安装存储路径规则和内存上限的账要算明白3.1 storage_root_path的写法规则BE的配置核心是storage_root_path这个参数决定了Doris往哪些目录写数据。它的写法有一个必须记住的规则多块盘之间用英文分号;分隔同一块盘上的多个目录用英文逗号,分隔目录末尾加medium标签标注磁盘类型HDD或SSD可选举个例子假设一台BE机器有三块盘分别挂载在/data1、/data2、/data3那么配置应该是storage_root_path /data1/doris/data;/data2/doris/data;/data3/doris/data如果某块盘空间特别大想在里面划两个目录就这么写storage_root_path /data1/doris/data1,/data1/doris/data2;/data2/doris/data这里的重点是目录规划要一次到位。Doris的数据分布是按路径来的如果刚部署时只配了一个路径后面发现不够再加新路径新路径可以生效但旧路径上的数据不会自动迁移就可能导致某些BE节点上数据分布不均。所以装新集群时最好把所有数据盘一次配进去。还需要留意be.conf里的这个参数webserver_port默认8040。BE自身会起一个HTTP服务用于健康检查和部分管理接口后面排查心跳问题时会用到。3.2 mem_limit怎么估算BE是一个C进程不像FE那样有JVM堆的概念。mem_limit是BE进程整体的内存上限默认单位是字节也可以通过百分比表示比如mem_limit 80%。这个值怎么定我习惯这么算一台机器如果只跑一个BE操作系统本身要留出一定内存page cache也要占一部分所以mem_limit设在物理内存的60%到80%之间比较稳妥。如果你这台机器上还跑了监控agent、日志采集器等其他进程比例就往60%靠。mem_limit设得太小会出现什么运行大查询时BE内存达到上限后会被强制降级或直接报错表现就是SQL执行到一半突然失败错误信息里带有memory limit相关的字样。设得太大呢操作系统内存耗尽的话可能触发OOM Killer直接杀掉进程那就不只是查询失败而是整个BE挂掉。所以这个账在部署时就要算好不要等线上出问题了再调。3.3 启动BE并注册到FEBE启动本身不需要连接FE它只是一个等待调度的工作进程。真正的注册动作是在FE端完成的。cd /opt/doris/doris-be sh bin/start_be.sh --daemon # 查看启动日志 tail -f log/be.INFO然后进入FE的MySQL命令行执行注册命令ALTER SYSTEM ADD BACKEND be-node-1:9050;这里be-node-1是BE节点的IP或主机名9050是BE的心跳服务端口heartbeat_service_port。注册完成后用下面这条命令检查BE状态SHOW BACKENDS;如果对应BE的Alive列是true说明心跳正常。如果是false多半是FE和BE之间网络不通、端口没放行或者BE进程没起来。这里有个很典型的小坑FE端注册时填的hostname或IP必须是BE节点能被集群内其他节点访问到的地址。如果你填了localhost或者一个不规范的主机名FE拿着这个地址去连BE时就会失败心跳自然建立不起来。4. 第一张表的验证流程从建库到查询全链路4.1 用MySQL客户端连接集群Doris对外是兼容MySQL协议的这意味着你不需要安装任何定制客户端直接用mysql命令行工具就能连接。mysql -h fe-node-1 -P 9030 -uroot如果说FE和BE都注册成功了那么现在这个MySQL命令行就是一个完整的入口。我们所有的管理操作、查询操作都可以在这里执行。对于用惯了MySQL的同事来说这套交互方式非常友好也是Doris能快速落地的一个重要原因。4.2 建一张明细表并导入测试数据验证部署效果最好的方式不是跑官方的benchmark而是建一张贴合自己业务的明细表把导入、查询、聚合整条链路都走一遍。CREATE DATABASE IF NOT EXISTS demo; USE demo; CREATE TABLE demo.sales ( order_date DATE NOT NULL, shop_id INT NOT NULL, sku_id BIGINT NOT NULL, sales_amt DECIMAL(12,2) ) DUPLICATE KEY(order_date, shop_id, sku_id) DISTRIBUTED BY HASH(shop_id) BUCKETS 12 PROPERTIES (replication_num 3);注意看几个地方。DUPLICATE KEY表示这是明细模型适合存储不合并的订单流水如果你需要实时更新或聚合结果就要考虑UNIQUE KEY或AGGREGATE KEY模型。DISTRIBUTED BY HASH(shop_id) BUCKETS 12这部分决定了数据分桶方式关于BUCKETS数量的选择如果是初期预估数据量不大可以从12或24起步后续再调整会涉及数据重分布比较麻烦所以第一次选型就要带着业务量预估来做。replication_num 3则意味着每个分桶的数据会在BE上存三份。然后往表里插入几条测试数据跑一个分组聚合验证全链路INSERT INTO demo.sales VALUES (2024-06-01, 101, 1001, 128.50), (2024-06-01, 101, 1002, 88.00), (2024-06-01, 102, 1001, 230.00); SELECT shop_id, SUM(sales_amt) FROM demo.sales GROUP BY shop_id;能正常返回聚合结果就说明你这套Doris集群的核心链路已经完全打通了。4.3 用show tablet检查副本分布建表验证之后我建议额外做一步——检查数据分片在各个BE上的分布情况。SHOW TABLET FROM demo.sales;这条语句会列出当前表的tablet信息包括tablet ID、所属BE、副本状态等。正常情况下每个tablet应该在多个BE上各有一份副本且总数等于你设置的副本数。如果发现某个tablet副本缺了很大概率是BE数量不够或者某个BE宕机了这个检查在正式业务上线前一定要做。5. 高可用部署至少三个FE才有资格谈故障切换5.1 增加FE节点的具体流程单FE在生产环境是个大隐患因为FE一旦宕机整个集群的SQL查询入口就没了虽然BE和数据都还在但客户端完全无法访问。所以我建议生产环境至少3个FE节点。扩容FE有两种角色可选FOLLOWER和OBSERVER后面会讲区别。这里先看FOLLOWER的扩容流程。假设现在已有FE1是集群的master我们要新增FE2、FE3。首先在MySQL命令行里把新FE的地址注册进去ALTER SYSTEM ADD FOLLOWER fe-node-2:9010; ALTER SYSTEM ADD FOLLOWER fe-node-3:9010;然后在FE2和FE3节点上分别准备配置文件保持前面说的关键配置一致再以helper方式启动。所谓helper就是告诉新FE“去这个已知的FE节点拉取元数据”。sh bin/start_fe.sh --helper fe-node-1:9010 --daemon启动后回到MySQL命令行执行SHOW FRONTENDS\G;如果新节点状态显示为FOLLOWER且Alive字段是true说明元数据已经从FE1同步完成。新FE会自动从master节点拉取全量元数据不需要手动拷贝任何文件。5.2 FOLLOWER和OBSERVER的区别增加FE之前必须先理解这两个角色FOLLOWER参与master选举具备故障切换资格。只有FOLLOWER中的多数派才能选出新的master。OBSERVER不参与选举只提供查询服务。它的存在意义是扩展读能力或者作为远程容灾的只读备份。生产环境推荐至少3个FOLLOWER原因在于基于多数派投票机制如果只有2个FOLLOWER其中一个宕机剩下1个就凑不齐多数派集群无法选出新master而3个FOLLOWER中宕机1个剩下2个仍然能形成多数派完成选举。这也是为什么我总是说高可用最少要3个FE而不是2个。多出来的FE还可以配合负载均衡器统一对外提供服务这样任何一台FE单点故障客户端都不感知连接会自动切换到其他FE。5.3 为什么不能只剩下一个FE我遇到过一种情况有人把集群里的FE缩减到只剩1个理由是“平时查询都分散到多个BE上FE只是入口没有性能压力”。这种想法很危险。FE承载的工作不只是“入口”它还是整个集群的元数据中心。建表、删表、修改schema、查看集群状态全都依赖FE。FE挂了之后即便BE完好无损集群对外也是完全不可用的状态。而且如果只有1个FE且它的元数据损坏整个集群的逻辑视图就丢了恢复成本极高。所以我的建议很直接生产集群FE至少3个日常维护至少保证2个FOLLOWER在线。这比给BE扩容带来的收益要实在得多。6. 资源隔离与并发配置多业务共用集群时怎么分蛋糕6.1 Workload Group是什么Doris集群部署完之后很快会面临一个问题多个业务方共用一套集群有的在做批量ETL有的在做线上报表有的在拖即席查询。如果不对资源做任何限制一个高消耗查询就能把BE的内存吃满把其他查询全部拖垮。Doris从某个版本开始引入了Workload Group机制简单理解就是给负载分组每组独立设置CPU、内存、并发上限。这比在操作系统层面硬性限制进程资源要灵活得多因为它是根据查询粒度的资源使用来做管控而不是一刀切卡进程。一个很典型的场景给ETL任务组设置较高的CPU权重给即席查询组设置较低的CPU权重给线上报表组设置内存上限防止大查询把内存打爆。6.2 一个最小配置示例下面是一个创建Workload Group的最小示例CREATE WORKLOAD GROUP wg_etl PROPERTIES ( cpu_share 10, memory_limit 30%, max_concurrency 20 ); CREATE WORKLOAD GROUP wg_report PROPERTIES ( cpu_share 5, memory_limit 50%, max_concurrency 50 );创建好之后怎么让查询进到对应分组两种方式会话级设置或者用户级绑定。-- 会话级 SET workload_group wg_etl; -- 用户级 ALTER USER etl_user% DEFAULT WORKLOAD GROUP wg_etl;用户级绑定更适合长期稳定的人员分配会话级适合临时调试。资源隔离的语法在不同新版本之间有细微调整具体参数名称建议以你部署版本的官方文档为准但思路是完全通用的先划分业务重要等级再据此分配CPU、内存和并发额度。7. 我实际踩过的几个坑与排查过程7.1 元数据目录悄悄把系统盘写满这是我在自己第一批测试集群上遇到的第一个大坑。当时图省事FE的meta_dir没改直接用的默认doris-meta目录而我的Doris安装包就解压在系统盘根分区下。一开始没什么异常装完BE、建完表、导了几批数据一切正常。过了两天先是发现FE偶尔响应变慢随后有同事反馈说某个表的查询开始超时。登到机器上执行df -h发现根分区已用空间超过90%。接着du -sh逐层排查定位到就是FE的元数据目录吃掉了大量空间。原因很简单FE的checkpoint机制会在每次生成镜像文件后累积edit log日积月累这些文件在系统盘上越堆越多而系统盘本身也就几十G的容量根本经不起这么造。排查到根因之后修复方案是迁移meta目录。注意不是直接把目录挪走就完事正确顺序是先停止FE进程把旧meta目录完整复制或移动到新的数据盘位置修改fe.conf里的meta_dir指向新路径重启FE确认日志正常还好发现得早没有损坏元数据。但这个过程也让我明白了目录规划这类看似不起眼的事情恰恰是生产部署里决定成败的基础。7.2 建表成功但数据导入后磁盘迅速打满另一类问题是反向的——不是FE的元数据占空间而是业务数据的副本数设置出了问题。有一个业务同学反映在集群上建了一张大表导入几批数据后磁盘使用率明显激增。我去查了表结构replication_num设成了3这本身没问题但如果你的BE只有2台3个副本就必须在2台机器上复制磁盘占用自然翻倍往上飙。排查路径是这样的先SHOW BACKENDS看数据容量发现某台BE的Data Used Capacity增长异常然后SHOW TABLET FROM 表名查看副本分布确认每个tablet复制了多份最后跟业务同学确认这张表的数据量预估发现其实不需要3副本改成2副本后就恢复正常了。这里有个经验值得分享副本数不是越大越好。3副本确实更安全但每份副本都会完整占用存储空间。如果是测试表、临时表2副本完全足够生产核心表可以按业务重要度和机器规模权衡一般2到3副本都是常见选择。关键是部署时就要想清楚并在建表时按需设置而不是默认值一把梭。7.3 FE之间时钟不同步导致选主异常3个FE部署完成之后我一度觉得高可用稳了结果没过多久就遇到了选主异常的现象。具体表现是3个FE状态看着都正常但master身份一会儿在这个节点一会儿跳到那个节点切换频繁导致客户端连接时不时被拒绝。查fe.log看到大量选举超时的日志再检查三台机器的系统时间发现其中有一台偏差了将近两分钟。Doris的FE集群依赖BDB JE进行元数据同步和master选举节点间的时钟严重不一致会直接影响选举协议的超时判断。解决方案很简单在所有节点上配置NTP时钟同步让系统时间保持一致。操作完成后再观察FE日志选举风暴立刻消失master稳定下来。这也是我为什么在前面的环境检查清单里专门强调时钟同步的原因。看似和数据库无关的一个系统配置却能实打实地影响集群稳定性。7.4 建BE一切正常但心跳显示Dead心跳不通的问题一般发生在BE注册阶段但有时候会出现在运行一段时间之后。有一次新增了一台BE注册命令执行成功SHOW BACKENDS里能看到这台机器但Alive一直显示false。我确认BE进程活着端口也开着最后发现是注册时填的主机名解析有问题FE所在的机器无法通过这个主机名解析到BE的实际IP地址。排查思路如果有BE心跳异常的大致照下面这个顺序走确认BE进程是否真的在运行ps -ef | grep doris_be确认BE的HTTP健康检查端口能访问curl http://be-node:8040/api/health确认FE到BE的网络连通性包括9050心跳端口和8060BRPC端口检查FE注册时填写的host/IP是否是BE在实际内网中能被访问到的地址大部分心跳问题都出在第4步。注册时如果用了不规范的主机名或者填了127.0.0.1这种回环地址FE去连BE的时候就会找错目标心跳自然不可能建立。8. 部署后的运维清单和例行检查项8.1 每天和每周要看的几个指标集群搭好只是起点日常运维才是长期的重点。我建议至少把下面这些检查固化到流程里。查看FE和BE的存活状态SHOW FRONTENDS、SHOW BACKENDS里是否有节点Alivefalse检查磁盘使用率不仅看系统盘更要注意BE的数据盘查看FE日志和BE日志中有没有异常堆栈或长时间GC日志检查慢查询Doris有审计日志功能可以定期分析哪些SQL耗时异常每周可以再加一项查看tablet的健康状态。如果发现某些tablet长期处于副本不完整状态要尽早排查原因不要等问题积累到数据丢失才发现。8.2 备份与升级的提示Doris的高可用FE已经保证了元数据有多份同步但这不代表你可以不做备份。FE的元数据目录是集群最脆弱的部分我的建议是定期对meta目录做快照备份或者至少保证有一个DIFF角色FE部署在异地位置起到容灾作用。对于表级数据备份Doris提供了BACKUP和RESTORE机制但需要依赖Broker或对象存储连接器定位远程存储。如果你的环境暂时没有这些组件至少要把FE元数据备份做起来否则一旦所有FE节点同时出问题恢复成本会非常高。升级方面只强调一点升级前先备份FE的meta目录然后严格按照官方升级文档的步骤执行。不要跨大版本直接跳级升级也不要同时升级所有FE节点生产环境建议先在测试集群完整演练一遍再操作。最后说点实在的整套集群从零搭下来如果一切顺利大概两三个小时就能完成。但真正让人成长的往往是那些不顺的地方元数据目录把系统盘写满、心跳超时反复排查、选主异常导致服务抖动。这些问题没有一个靠死记硬背能解决都得理解Doris的架构分工之后才能顺手把根因揪出来。如果你也是第一次部署Doris我建议动手之前先把FE和BE的分工、副本数的意义、内存上限的计算这三件事想清楚。装完集群之后找个周末做一次完整的故障演练停掉一个FE看查询是否受影响停掉一个BE看数据是否仍然完整。这套流程走完你对这套集群的掌控力会完全不一样。