表结构设计是Doris性能优化的起点不合理的表结构会导致后续所有优化事倍功半。核心在于通过合理的数据划分、索引选择和模型匹配从源头减少数据处理量和计算开销。1.1 分区分桶策略数据划分的艺术Doris采用两层数据划分机制第一层是分区Partition实现数据的逻辑隔离和范围裁剪第二层是分桶Bucket实现数据在BE节点间的均匀分布。分区最佳实践优先使用时间维度作为分区列如dt、create_time这是最常用的查询过滤条件能实现高效的分区裁剪推荐使用2.1版本引入的Auto Partition自动分区功能避免手动创建分区的繁琐和遗漏分区粒度根据数据量调整日分区适合每天数据量10GB的场景月分区适合数据量较小的历史表对于有历史数据删除需求的场景分区机制能实现秒级的分区删除远优于DELETE语句分桶最佳实践分桶列选择区分度高的列如user_id、order_id避免数据倾斜单Tablet分桶压缩后的数据量控制在1-10GB之间计算公式分桶数单分区总数据量/(1-10GB)分桶数建议为BE节点数的整数倍确保数据均匀分布避免分桶数过多过多分桶会增加FE元数据压力和BE的Compaction开销示例合理的分区分桶表创建CREATE TABLE user_behavior ( dt DATEV2 NOT NULL COMMENT 日期, user_id BIGINT NOT NULL COMMENT 用户ID, item_id BIGINT NOT NULL COMMENT 商品ID, behavior_type TINYINT NOT NULL COMMENT 行为类型1-点击2-收藏3-加购4-购买, behavior_time DATETIMEV2 NOT NULL COMMENT 行为时间, amount DECIMAL(10,2) COMMENT 交易金额 ) AUTO PARTITION BY RANGE (DATE_TRUNC(dt, DAY)) -- 自动按天分区 DISTRIBUTED BY HASH(user_id) BUCKETS 32 -- 按用户ID分桶32个桶 PROPERTIES ( replication_num 3, storage_medium SSD, enable_segcompaction true -- 开启Segment Compaction2.1默认开启 );1.2 索引优化加速数据检索Doris提供多种索引类型合理使用索引能大幅提升查询性能但需注意索引会增加导入开销和存储成本。Bloom Filter索引适用场景高基数列如user_id、order_id的等值查询不适用范围查询、低基数列创建方式ALTER TABLE user_behavior ADD INDEX bf_item_id(item_id) USING BLOOM_FILTER;Bitmap索引适用场景低基数列如性别、状态、行为类型的等值过滤和组合过滤不适用高基数列、更新频繁的列创建方式ALTER TABLE user_behavior ADD INDEX bitmap_behavior(behavior_type) USING BITMAP;1.3 数据模型选择匹配业务场景Doris提供三种核心数据模型需根据业务需求选择最合适的模型错误的模型选择会导致性能和功能问题。数据模型核心特点适用场景Aggregate模型导入时自动按Key聚合相同行报表统计、数据汇总、预计算场景Unique模型保证主键唯一性支持更新订单表、用户表等需要主键约束的场景Duplicate模型不做任何聚合保留所有原始数据原始日志、明细数据、无聚合需求的场景注意Unique模型在2.0版本引入了Merge-on-Write实现更新性能较之前的Merge-on-Read提升了数十倍推荐优先使用。二、数据导入优化打通入仓高速通道数据导入是Doris数据链路的入口导入性能直接影响数据的实时性和系统稳定性。Doris提供多种导入方式需根据数据源类型、数据量和实时性要求选择合适的导入方式。2.1 导入方式选择按需匹配Broker Load适用场景TB级以上大规模批量数据导入数据源为HDFS、S3、OSS等外部存储优势支持分布式并行导入吞吐量大适合离线数据同步示例LOAD LABEL db.user_behavior_label_20240611 ( DATA INFILE(hdfs://namenode:8020/data/user_behavior/20240611/*.parquet) INTO TABLE user_behavior FORMAT AS PARQUET ) WITH BROKER broker_name PROPERTIES ( timeout 3600, max_filter_ratio 0.01 );Stream Load适用场景GB级以下小文件导入、实时数据写入、程序接口导入优势同步导入实时返回结果无需部署Broker示例curl --location-trusted -u user:password \ -T user_behavior_20240611.csv \ -H label:user_behavior_20240611_stream \ -H format:csv \ http://fe_host:8030/api/db/user_behavior/_stream_loadRoutine Load适用场景从Kafka持续消费实时数据优势支持Exactly-Once语义自动容错无需人工干预是实时数据入仓的首选方式Insert Into适用场景小批量数据导入、Doris内部表之间的数据转换、ETL作业2.1版本引入了MemTable前移优化使得INSERT INTO…SELECT的导入性能提升了100%以上2.2 并行度与参数调优导入并行度是影响导入性能的关键因素合理调整并行度能充分利用集群的CPU和IO资源。全局参数调优-- 开启全局运行时过滤提升大表Join性能 SET GLOBAL global_runtime_filter_mode GLOBAL; -- 设置每个查询的并行实例数建议为BE节点CPU核心数的1/4-1/2 SET GLOBAL parallel_fragment_exec_instance_num 8;Broker Load专项调优WITH BROKER broker_name PROPERTIES ( load_parallelism 16, -- 导入并行度建议为BE节点数的2-4倍 send_batch_parallelism 5, -- 发送批次并行度 exec_mem_limit 21474836480, -- 单个导入任务的内存限制20GB timeout 7200 )高频小批量导入优化开启Group Commit功能将短时间内的多个小事务合并为一个大事务减少Edit Log写入次数和MemTable刷盘频率减轻Compaction压力特别适合日志、IoT等高频小数据量写入场景2.3 文件预处理从源头提升效率文件格式和大小对导入性能有显著影响预处理好文件能大幅提升导入效率。小文件合并避免导入大量小于100MB的小文件小文件会导致FE元数据膨胀和BE Compaction压力剧增文件格式优先使用Parquet或ORC列式存储格式比CSV格式导入速度快3-5倍且占用更少的存储空间压缩算法使用Snappy或LZ4压缩算法平衡压缩比和压缩/解压速度数据类型匹配确保导入文件的数据类型与表结构一致避免类型转换带来的性能开销三、集群配置优化释放硬件潜能合理的集群配置是Doris高性能运行的基础需根据硬件规格和业务负载调整FE和BE的配置参数。3.1 FE配置优化元数据与调度核心FE是Doris集群的大脑负责元数据管理、查询调度和导入协调其性能直接影响整个集群的稳定性和响应速度。JVM堆内存配置FE堆内存建议设置为16GB以上对于大规模集群10个BE建议设置为32GB-Xmx和-Xms设置为相同值避免JVM堆内存动态调整带来的GC停顿示例JAVA_OPTS-Xmx32g -Xms32g -XX:UseG1GC元数据管理优化# 元数据检查点间隔单位秒减少元数据恢复时间 metadata_checkpoint_threshold_sec3600 # 编辑日志滚动数量控制Edit Log文件大小 edit_log_roll_num50000 # 元数据备份数量 max_bdbje_txn_logs100并发控制优化# FE最大连接数 qe_max_connection4096 # 查询最大重试次数 max_query_retry_time3 # 导入任务最大并发数 max_running_txn_num_per_db1003.2 BE配置优化存储与计算引擎BE是Doris集群的存储和计算节点所有的数据导入和查询操作都在BE上执行BE配置对性能影响最大。存储优化# 存储页缓存大小建议设置为BE节点内存的40%-50% storage_page_cache_limit32G # 禁用存储页缓存会导致查询性能大幅下降生产环境切勿关闭 disable_storage_page_cachefalse # 每个存储目录的刷盘线程数 flush_thread_num_per_store4导入优化# 导入进程最大内存限制字节 load_process_max_memory_limit_bytes107374182400 # 100GB # 导入进程内存占BE总内存的最大比例 load_process_max_memory_limit_percent30 # 单个导入任务的默认内存限制 default_load_mem_limit2147483648 # 2GB压缩与IO优化# 默认压缩算法 compression_codecsnappy # 磁盘IO调度算法建议使用deadline或noop disk_io_schedulerdeadline # 最大并发IO请求数 max_disk_io_thread_num163.3 资源组管理负载隔离与优先级在多业务共享集群的场景下不同业务的查询负载可能会互相干扰导致核心业务性能下降。Doris 2.1版本引入了增强的Workload Group资源组功能支持CPU硬限制和内存限制实现严格的负载隔离。示例创建资源组并分配给用户-- 创建核心业务资源组CPU硬限制为60%内存限制为60% CREATE RESOURCE GROUP core_business_rg PROPERTIES ( cpu_hard_limit 60%, memory_limit 60%, query_timeout 300 ); -- 创建普通业务资源组CPU硬限制为30%内存限制为30% CREATE RESOURCE GROUP normal_business_rg PROPERTIES ( cpu_hard_limit 30%, memory_limit 30%, query_timeout 600 ); -- 将用户分配到对应的资源组 ALTER USER core_user% SET RESOURCE_GROUP core_business_rg; ALTER USER normal_user% SET RESOURCE_GROUP normal_business_rg;四、查询优化提升检索响应速度查询优化是提升用户体验的关键通过合理的SQL编写、物化视图和统计信息收集能显著降低查询延迟。4.1 SQL编写最佳实践**避免SELECT ***只查询需要的列减少数据扫描和内存占用强制分区裁剪WHERE条件中必须包含分区列避免全表扫描合理使用过滤条件将过滤条件尽量下推减少后续处理的数据量避免大表全量Join优先使用Broadcast Join小表广播到大表所在节点大表Join使用Shuffle Join避免在WHERE条件中对列进行函数操作会导致索引失效和分区裁剪失效反例与正例对比-- 反例对分区列使用函数导致分区裁剪失效 SELECT * FROM user_behavior WHERE DATE_FORMAT(dt, %Y-%m-%d) 2024-06-11; -- 正例直接使用分区列进行过滤 SELECT * FROM user_behavior WHERE dt 2024-06-11;4.2 物化视图预聚合用空间换时间物化视图是Doris的核心优化特性之一通过预计算常用的聚合结果将复杂查询转化为简单的物化视图扫描能提升查询性能数十倍甚至上百倍。示例创建用户行为统计物化视图CREATE MATERIALIZED VIEW mv_user_behavior_daily AS SELECT dt, user_id, COUNT(*) AS behavior_cnt, SUM(amount) AS total_amount FROM user_behavior GROUP BY dt, user_id;
