1. 项目概述从“Drois”到Apache Doris一个高性能MPP数据库的实战解析最近在数据圈里一个名字被频繁提及虽然有时会被误写为“Drois”但它的正确身份是Apache Doris。如果你正在为海量数据的实时分析、报表查询速度慢如蜗牛而头疼或者厌倦了传统数仓那复杂的架构和运维成本那么Doris很可能就是你正在寻找的答案。它不是一个新概念但凭借其极致的性能、易用的体验和拥抱开源生态的活力正成为越来越多企业数据栈中的核心组件。简单来说Doris是一个基于MPP大规模并行处理架构的现代化分析型数据库专为应对高并发、低延迟的实时分析场景而生。无论是数据工程师需要构建一个敏捷的OLAP平台还是业务分析师渴望秒级响应复杂的即席查询甚至是开发团队想要一个能够轻松与现有系统集成的分析引擎Doris都提供了极具吸引力的解决方案。接下来我将结合自己从零部署、调优到上线的完整经历为你拆解Doris的核心魅力、实战部署的每一个细节以及那些只有踩过坑才知道的宝贵经验。2. Doris核心架构与设计哲学解析2.1 为什么是MPP深入理解Doris的性能基石要理解Doris为什么快必须从它的MPP架构说起。你可以把传统的单机数据库想象成一个全能但孤独的厨师所有切菜、炒菜、摆盘都由他一人完成。当客人查询请求不多时他游刃有余但一旦举办宴会海量数据并发查询他必然手忙脚乱。而MPP架构则像是一个专业后厨团队由一位主厨Frontend进行任务规划和调度然后将具体的切配、热炒、冷盘等任务分发给一群各司其职的厨师Backend并行处理。最后主厨将各道工序的结果汇总呈现给客人。在Doris中FrontendFE就是这个主厨负责元数据管理、查询解析、规划以及协调。而BackendBE就是后厨团队负责数据的存储和计算。当一个复杂的SQL查询进来时FE会将其编译成一个分布式执行计划拆分成无数个小任务Fragment下发给多个BE节点。每个BE只处理自己本地存储的那部分数据这就是“本地计算”原则极大地减少了网络数据传输的开销。所有BE并行执行完毕后将中间结果汇总到少数BE进行最终聚合再返回给FE。这种“分而治之”的思想是Doris能够实现海量数据秒级分析的根本。注意MPP架构的优势在于处理复杂分析查询但对于高频率、小事务的OLTP场景如银行转账并不擅长。选择Doris前务必明确你的场景是“分析”而非“交易”。2.2 FE与BE的职责边界与协同机制在实际部署和运维中清晰理解FE和BE的职责至关重要这能帮助你在出现问题时快速定位。FrontendFE节点主要有两个角色Leader FE和Follower FE。你可以把Leader FE看作是后厨的行政总厨只有一个负责所有菜单元数据的最终写入和决策。Follower FE则是副厨他们同步总厨的菜单并协助接待客人处理用户连接和查询请求提供读服务。这种设计保证了元数据的高可用和读请求的负载均衡。FE节点存储的是“菜单”本身即元数据如表结构、分区信息、副本位置等而不是实际的“食材”数据。BackendBE节点是真正的“食材仓库”和“加工车间”。它们负责存储用户表的数据并以列式格式组织。当接到FE下发的加工任务查询子计划时BE会从本地磁盘快速读取所需的“食材列”在内存中进行过滤、聚合等计算。BE节点是无状态的从数据分布视角看通过增加BE节点可以线性地扩展系统的存储能力和计算能力。它们之间的协同依赖于一个高效的内部RPC通信框架。FE将执行计划发送给BEBE汇报任务状态和数据存储情况给FE。这个过程的延迟和稳定性直接影响到整个集群的查询性能。因此在生产环境中保证FE与BE之间、BE与BE之间的网络低延迟和高带宽是基础中的基础。2.3 数据模型聚合模型与明细模型的场景抉择建表是使用Doris的第一步而选择正确的数据模型决定了后续查询的效率和灵活性。Doris主要提供了两种数据模型聚合模型Aggregate Model和明细模型Duplicate Model。聚合模型适用于有明确维度分析和预聚合需求的场景。比如你的业务是分析电商网站的每日销售情况你关心的是每个商品、每个品类、每个省份的销售额、订单数。那么你可以在数据导入时就指定这些列为维度列Key将销售额、订单数列定义为聚合列Value并指定聚合方式为SUM。当后续有相同维度同商品、同品类、同省份、同日期的新数据进来时Doris会自动在底层进行求和只保留一条聚合后的数据。这极大地压缩了数据量对于“查询每日销售大盘”这类固定维度的聚合查询速度极快。但它的缺点是你无法查询到原始的单笔订单明细。明细模型则保存了最原始的每条数据没有任何预聚合。所有列都是维度列Key或者你可以简单理解为它就像一张普通的数据库表存储原始日志、交易流水等。它的优势是灵活性极高你可以进行任意维度的即席查询。例如你想分析“在晚上8点至9点之间来自北京的用户购买了手机类目且使用了优惠券的订单详情”明细模型可以轻松应对。代价就是存储成本相对较高查询时需要进行实时计算。如何选择一个实用的建议是对于需要超高速度的固定报表和仪表盘优先使用聚合模型对于需要灵活探索的即席查询和详单回溯使用明细模型。在实践中我们常常采用“分层”设计使用明细模型存储原始数据ODS层然后通过Doris的物化视图或定时导入任务将数据聚合后存入另一张聚合模型表DWS/ADS层让不同的应用各取所需。3. 从零开始单机与集群部署实战指南3.1 硬件与系统环境准备要点在下载安装包之前合理的环境规划能避免后续很多麻烦。Doris对硬件的要求比较中规中矩但有几个关键点需要注意。对于测试或轻量级生产环境单机/少量节点CPU建议4核以上。Doris的查询性能严重依赖CPU的并行计算能力特别是在进行复杂聚合时。内存这是最重要的资源没有之一。建议16GB起步。BE进程是内存消耗大户因为列式数据在处理时会加载到内存中进行计算。足够的内存可以保证大部分查询在内存中完成避免溢出到磁盘这是实现低延迟的关键。一个粗略的估算方法是预留系统内存后确保可用于BE的内存 热数据量 / 10。例如有100GB热数据建议为BE预留至少10GB内存。磁盘推荐使用SSD。Doris的列存格式虽然对IO友好但SSD能极大加速数据扫描和Compaction数据合并过程。如果数据量巨大且预算有限可以采用SSDHDD混合部署将热数据放在SSD上。磁盘空间建议预留为原始数据量的3倍以上用于存储多副本、索引以及Compaction过程中的临时文件。网络集群部署时节点间网络带宽至少需要千兆1Gbps低延迟网络能显著提升分布式查询效率。操作系统官方推荐CentOS 7 或 Ubuntu 16.04。需要确认已安装Java 8FE依赖并配置好JAVA_HOME。实操心得在虚拟机或云主机上部署时务必关闭透明大页Transparent Huge Pages因为它可能导致Doris性能不稳定。可以通过命令echo never /sys/kernel/mm/transparent_hugepage/enabled临时禁用并写入启动脚本永久生效。3.2 单机版部署五分钟快速体验对于初学者或功能验证单机部署是最快的方式。这里假设你已经下载了Doris的二进制安装包如apache-doris-2.0.0-bin-x64.tar.gz。步骤1解压与目录规划tar -zxvf apache-doris-2.0.0-bin-x64.tar.gz -C /opt/ cd /opt/apache-doris-2.0.0我习惯将软件放在/opt下数据目录单独规划例如/data/doris。步骤2配置FE进入FE的配置目录修改fe.conf核心参数# 主要配置项 priority_networks 192.168.1.100/24 # 指定FE使用的IP段避免绑定到127.0.0.1 http_port 8030 # Web UI端口 rpc_port 9020 # FE之间通信端口 query_port 9030 # MySQL客户端连接端口 # 元数据目录指向一个独立的、容量较大的磁盘 meta_dir /data/doris/fe/meta启动FE./bin/start_fe.sh --daemon。查看日志log/fe.log确认启动成功看到thrift server started字样即可。步骤3通过MySQL客户端连接并添加BE使用任意MySQL客户端如mysql命令或DBeaver连接mysql -h 192.168.1.100 -P 9030 -uroot初始密码为空。连接成功后执行以下SQL添加BE节点假设BE也部署在本机ALTER SYSTEM ADD BACKEND 192.168.1.100:9050;步骤4配置并启动BE修改BE的配置文件be.confpriority_networks 192.168.1.100/24 be_port 9060 # BE通信端口 webserver_port 8040 # BE的Web UI端口 storage_root_path /data/doris/be/storage1,medium:ssd;/data/doris/be/storage2,medium:hdd # 数据存储路径可指定多块盘启动BE./bin/start_be.sh --daemon。查看日志log/be.log看到heartbeat success等字样。步骤5验证集群状态回到MySQL客户端执行SHOW PROC /backends;查看Alive列是否为trueSystemDecommissioned列是否为false。如果都是恭喜你一个单节点Doris集群已经跑起来了。3.3 生产级集群部署架构与配置详解单机模式仅供测试生产环境需要高可用和可扩展的集群。一个典型的最小高可用集群需要3个FE1 Leader 2 Follower和至少2个BE保证数据副本数2。FE高可用部署在第一台机器部署并启动Leader FE步骤同单机。在第二、三台机器部署FE修改fe.conf增加一个配置指向Leaderpriority_networks 192.168.1.101/24 meta_dir /data/doris/fe/meta # 关键指定已有集群的Leader FE地址 helper_nodes 192.168.1.100:9010启动这两台Follower FE。启动后它们会自动从Leader同步元数据。通过任意FE的Web UIhttp://ip:8030或SQL命令SHOW PROC /frontends;可以查看所有FE状态。Leader故障时Follower会自动选举出新Leader。BE横向扩展BE的扩展非常简单只需在新机器上部署BE服务然后在任一存活的FE上执行ALTER SYSTEM ADD BACKEND “new_be_ip:9050”;即可。数据会自动在新旧BE之间进行重新均衡。关键生产配置调优be.conf中的storage_page_cache_limit控制BE用于缓存数据页的内存大小通常设置为BE可用内存的40%-60%。be.conf中的max_compaction_threads和cumulative_compaction_num_threads_per_disk控制Compaction的线程数影响数据合并速度。对于SSD可以适当调大如设置为4-8。fe.conf中的qe_max_connection限制FE的最大连接数根据业务压力调整。4. 核心操作建表、数据导入与查询优化4.1 建表语句深度解析以按月分区为例掌握了模型选择我们来实战一个最常用的场景创建一张按月分区的明细表。分区能有效裁剪数据扫描范围提升查询性能。CREATE TABLE IF NOT EXISTS user_behavior_log ( user_id BIGINT NOT NULL COMMENT “用户ID” item_id BIGINT NOT NULL COMMENT “商品ID” category_id INT COMMENT “品类ID” behavior VARCHAR(20) COMMENT “行为类型pv buy cart” ts DATETIME NOT NULL COMMENT “行为时间戳” ) ENGINEolap DUPLICATE KEY(user_id, item_id, ts) -- 指定明细模型前三列为排序列 COMMENT “用户行为明细日志” PARTITION BY RANGE(ts) -- 按时间范围分区 ( PARTITION p202401 VALUES LESS THAN (“2024-02-01”), -- 2024年1月数据 PARTITION p202402 VALUES LESS THAN (“2024-03-01”), PARTITION p202403 VALUES LESS THAN (“2024-04-01”) ) DISTRIBUTED BY HASH(user_id) BUCKETS 10 -- 分桶数据分布到BE的方式 PROPERTIES ( “replication_num” “3” -- 副本数通常与BE节点数匹配或为3 “storage_medium” “SSD” -- 存储介质 “dynamic_partition.enable” “true” -- 启用动态分区 “dynamic_partition.time_unit” “MONTH” “dynamic_partition.start” “-3” -- 保留最近3个月分区 “dynamic_partition.end” “3” -- 预先创建未来3个月分区 “dynamic_partition.prefix” “p” “dynamic_partition.buckets” “10” );关键点解析DUPLICATE KEY定义了明细模型的前缀索引。查询条件如果包含这些列的前缀可以加速数据查找。这里我们选择了user_iditem_idts因为查询常以“某个用户在某个时间点对某个商品的行为”为条件。PARTITION BY RANGE按月分区是最佳实践之一。查询时如果指定了ts的范围Doris只会扫描相关分区的数据无关分区被直接跳过。DISTRIBUTED BY HASH分桶决定了数据在多个BE间如何分布。选择user_id作为分桶键可以保证同一个用户的数据落在同一个BE上这对于用户维度的聚合查询非常有利。BUCKETS 10代表分为10个桶这个数字建议是BE节点数的整数倍且最终每个桶的数据量在100MB-1GB之间比较合适。动态分区这是解放运维的利器。通过上述配置Doris会自动创建未来3个月的分区并删除3个月前的历史分区。你再也无需手动写脚本去管理分区了。4.2 数据导入Broker Load与Stream Load的选择与实战数据导入是数仓的生命线。Doris提供了多种导入方式最常用的是Broker Load用于HDFS等外部系统批量导入和Stream Load用于程序流式写入。Broker Load示例从HDFS导入Parquet文件LOAD LABEL example_db.label_20240401 -- 导入任务标签 ( DATA INFILE(“hdfs://namenode:8020/path/to/*.parquet”) INTO TABLE user_behavior_log FORMAT AS “parquet” ) WITH BROKER “broker_name” -- 需要在Doris中预先配置的Broker PROPERTIES ( “timeout” “3600” );提交后可以通过SHOW LOAD WHERE LABEL ‘label_20240401’;查看导入状态。Broker Load适合TB级别的历史数据迁移或定时批量同步。Stream Load实战通过HTTP API实时写入这是实现实时数据接入最常用的方式。你可以使用curl命令、Flink Connector、或自定义程序调用。curl --location-trusted -u user:passwd \ -H “format: json” \ -H “strip_outer_array: true” \ -T /path/to/data.json \ http://fe_host:8030/api/example_db/user_behavior_log/_stream_loadStream Load是同步导入请求返回即表示导入成功或失败非常适用于对延迟要求高的场景。strip_outer_array: true参数允许你导入一个JSON数组。注意事项Stream Load默认会为每批导入数据创建一个新的数据版本过于频繁的小批量写入比如每秒一次会导致版本数快速增长引发频繁的Compaction消耗CPU和IO反而影响查询性能。建议在客户端进行适当缓冲比如攒批到32MB或60秒再写入。4.3 查询性能优化从慢查询到秒级响应当你发现“每分钟只插入2万条100列的数据太慢了”或者查询超时时就需要进行性能调优。这通常是一个系统工程需要从多个层面排查。1. 分析慢查询首先通过FE的Web UIhttp://fe_host:8030进入“查询”页面找到慢查询记录。点击“详情”可以查看该查询的执行计划Profile。Profile是调优的金钥匙它详细展示了查询在每个节点上的耗时。2. 解读Profile关键指标Operator各个执行算子如OlapScanNode扫描HashJoinNodeAggregationNode等。ExecTime该算子的执行时间。Rows该算子处理的行数。PeakMemory内存使用峰值。 重点关注耗时最长的算子。如果OlapScanNode耗时很长说明数据扫描是瓶颈。3. 针对性优化扫描数据量过大检查分区和分桶键确保查询条件命中了分区和前缀索引。例如查询WHERE ts BETWEEN ‘2024-01-01’ AND ‘2024-01-31’就能精准定位到p202401分区。增加索引对高频过滤条件但不在前缀索引中的列可以创建BITMAP索引适用于低基数列如city或Bloom Filter索引适用于高基数列的等值查询。-- 创建Bitmap索引 CREATE INDEX idx_behavior ON user_behavior_log(behavior) USING BITMAP;聚合或Join耗时过长检查数据分布Join的两张表如果分布键不同会导致数据在节点间进行重分布Shuffle网络开销巨大。尽量让Join键与表的分桶键一致。调整并行度通过Session变量parallel_fragment_exec_instance_num可以增加查询的并行度默认为1在BE节点多、CPU强的情况下可以适当调大如设置为BE节点数。SET parallel_fragment_exec_instance_num 4; -- 然后执行你的查询内存不足如果Profile中显示Memory limit exceeded需要增加单个查询的内存限制。通过变量exec_mem_limit设置。SET exec_mem_limit 2147483648; -- 设置为2GB4. 写入性能优化对于开篇提到的插入慢问题除了前面提到的攒批写入还可以检查BE的Compaction配置如果cumulative_compaction_num_threads_per_disk设置过小会导致数据版本堆积影响后续写入速度。可适当调大。单次导入数据量即使是Stream Load也建议单批数据量在100MB左右太小则RPC开销占比高太大则可能造成内存压力。表结构设计过宽的表100列本身在列存格式下每行数据的元信息也会带来开销。如果很多列很少被查询可以考虑拆表或使用更高效的数据类型。5. 运维、监控与生态集成5.1 集群监控与告警搭建“跑起来”只是第一步“稳得住”才是关键。Doris提供了丰富的监控指标可以通过Prometheus Grafana搭建可视化监控大盘。1. 指标暴露Doris的FE和BE都内置了Metrics接口FE:http://fe_host:8030/metrics BE:http://be_host:8040/metrics格式为Prometheus标准。2. Prometheus配置在prometheus.yml中添加抓取任务。scrape_configs: - job_name: ‘doris-fe’ static_configs: - targets: [‘fe_host1:8030’ ‘fe_host2:8030’ ‘fe_host3:8030’] - job_name: ‘doris-be’ static_configs: - targets: [‘be_host1:8040’ ‘be_host2:8040’ ‘be_host3:8040’]3. Grafana仪表盘社区有现成的Doris监控看板模板可以导入。你需要关注的核心指标包括查询doris_fe_query_latency_ms查询延迟、doris_fe_qps查询QPS、doris_fe_query_err_rate错误率。写入doris_fe_load_finish导入成功率、doris_be_tablet_base_compaction_deltaBase Compaction排队数。资源doris_be_process_memory_percentBE内存使用率、doris_be_disk_used磁盘使用率、doris_be_storage_page_cache_hit_rate页面缓存命中率。节点健康doris_fe_frontend_alive、doris_backend_alive。设置告警规则例如BE内存使用率超过85%、查询P99延迟超过5秒、副本健康数小于2等及时通知运维人员。5.2 备份、恢复与数据迁移策略任何数据库没有备份都是“裸奔”。Doris支持通过Broker将数据快照备份到远端对象存储如S3、HDFS并支持恢复。数据备份BACKUP SNAPSHOT example_db.snapshot_label TO repo_name -- 预先创建好的备份仓库 ON (table1, table2) PROPERTIES (“type” “full”); -- 全量备份数据恢复RESTORE SNAPSHOT example_db.snapshot_label FROM repo_name ON (table1, table2) PROPERTIES (“backup_timestamp” “2024-04-01-12-00-00”);对于跨集群迁移除了备份恢复还可以使用CREATE TABLE AS SELECT (CTAS)语句或者通过Spark Doris Connector进行高效的数据同步。5.3 与大数据生态的集成Flink与SparkDoris的优势在于分析而数据加工则离不开Flink/Spark。通过官方提供的Connector可以轻松实现数据流的导入和导出。Flink CDC实时入湖这是一个非常流行的架构。使用Flink CDC捕获MySQL等业务库的变更通过Flink-Doris-Connector实时写入Doris。这实现了从业务数据库到分析数据库的端到端实时同步。 在Flink SQL中只需创建一个Doris表作为SinkCREATE TABLE doris_sink ( ... ) WITH ( ‘connector’ ‘doris’ ‘fenodes’ ‘fe_host:8030’ ‘table.identifier’ ‘db.table’ ‘username’ ‘root’ ‘password’ ‘’ ); INSERT INTO doris_sink SELECT * FROM cdc_source_table;Spark离线分析对于复杂的ETL任务可以使用Spark读取Hive中的数据处理后再写入Doris。// 读取Hive val hiveDF spark.sql(“SELECT * FROM hive_table”) // 处理... // 写入Doris hiveDF.write .format(“doris”) .option(“doris.fenodes” “fe_host:8030”) .option(“doris.table.identifier” “db.table”) .option(“user” “root”) .option(“password” “”) .save()这种松耦合的架构让Doris专注于其擅长的即席查询和实时分析而将繁重的ETL工作交给更专业的计算引擎各司其职共同构建高效的数据平台。从一次偶然的误写“Drois”开始深入Apache Doris的世界你会发现它不仅仅是一个数据库更是一套为现代实时分析场景量身打造的高性能解决方案。它的价值不在于某个炫酷的特性而在于在性能、易用性和成本之间取得的精妙平衡。部署和上手并不复杂但要想真正发挥其威力需要深入理解其MPP架构、数据模型和存储原理。在实践的路上多查看Profile善用社区Apache Doris官网和GitHub仓库是宝库很多你遇到的坑前辈们都已经填平了。最后记住一点任何技术选型都要贴合业务场景当你需要面对海量数据的交互式分析时Doris绝对是一个值得你投入时间深度研究的利器。
)
