很多人使用 Apache Doris 建表时永远只会一套模板按天分区、user_id 分桶。结果就是有的表查询飞快、运维丝滑有的表查询扫全分区、数据严重倾斜、热点 BE 节点、删数据卡顿、并发上不去。Doris 的数据存储核心是两层划分架构分区Partition 分桶Bucket。很多人搞不懂核心差异分区管管理与裁剪分桶管分布与并行。本文不讲枯燥概念完全按照「什么业务场景、该怎么分区、该怎么分桶、为什么这么设计、错误示范」的逻辑搭配可直接上线的 SQL 案例手把手教你搞定 Doris 表结构设计。一、先搞懂核心本质分区和分桶到底负责什么这是所有设计的底层逻辑记住这两句话搞定 80% 问题分区 Partition第一层逻辑分层、数据生命周期、查询裁剪控制数据按范围/维度拆分实现分区裁剪、过期删除、冷热分离目标让查询尽量只扫目标分区不扫全表让删数据、归档数据秒级完成分桶 Bucket第二层物理打散、负载均衡、查询并行度控制单个分区内的数据通过 Hash/Random 打散到不同 BE 节点目标数据均匀无倾斜、最大化集群并行计算、消除热点节点极简总结分区解决数据太多不好管、查询范围太大的问题。分桶解决数据扎堆不均匀、计算跑不满的问题。二、分区设计用什么字段用 Range 还是 List1. 分区选型铁律生产通用标准95% 时序业务日志、订单、流水、行为数据用Range 范围分区优先时间字段dt、create_time离散维度固定业务地区、渠道、门店、设备类型用List 列表分区小表、维度表、数据量小、无过期清理需求可以不分区2. Range 时间分区最常用场景案例适用场景所有随时间递增、按天/月统计、需要清理历史数据、查询必带时间条件的大表。例如用户行为日志、订单表、交易流水、监控指标、CDC 同步业务表。设计依据查询 90% 带时间过滤完美触发分区裁剪支持动态分区自动建分区、自动删过期数据零运维按时间拆分后单次导入、单次查询数据量可控落地案例按天动态分区生产万能模板-- 业务每日订单流水表按天分区自动过期清理 CREATE TABLE order_daily ( order_id BIGINT, user_id BIGINT, amount DECIMAL(18,2), create_dt DATE, city STRING ) DUPLICATE KEY(order_id) -- 分区规则按日期范围分区 PARTITION BY RANGE(create_dt) ( PARTITION p20260701 VALUES LESS THAN (2026-07-02) ) -- 开启动态分区 PROPERTIES ( dynamic_partition.enable true, dynamic_partition.time_unit DAY, dynamic_partition.start -30, dynamic_partition.end 3, dynamic_partition.prefix p, dynamic_partition.buckets 32, dynamic_partition.create_history_partition true );设计亮点自动保留近 30 天数据预创建未来 3 天分区无需手动维护。3. List 离散分区场景案例适用场景数据按固定维度离散分布、经常按维度单独查询、需要单独管理某类数据。例如按城市、按渠道、按业务线、按设备类型拆分的数据。设计依据如果业务经常WHERE city 北京List 分区可以直接命中对应分区无需扫描全部分区。落地案例按城市 List 分区CREATE TABLE user_city_stat ( user_id BIGINT, city STRING, pv INT, stat_dt DATE ) DUPLICATE KEY(user_id) PARTITION BY LIST(city) ( PARTITION p_beijing VALUES IN (北京市), PARTITION p_shanghai VALUES IN (上海市), PARTITION p_guangdong VALUES IN (广州市,深圳市) );4. 二级分区高阶优化场景适用场景查询既带时间又高频带地区/渠道筛选单分区裁剪不彻底。设计方案一级时间 Range 二级维度 List。解决痛点只按时间分区时跨城市查询依然扫描大量数据二级分区精准裁剪。三、分桶设计选什么字段多少桶Hash 还是 Random1. 分桶核心三原则必记高基数字段唯一值多user_id、order_id、device_id绝对不要用性别、状态、渠道等低基数字段单分桶高频过滤查询经常带该字段等值/范围条件可触发桶裁剪数据均匀避免热点保证每个 BE 节点数据量基本一致2. 分桶方式选型Hash 分桶DISTRIBUTED BY HASH精准点查、用户维度分析、需要 Colocate Join 场景首选Random 分桶DISTRIBUTED BY RANDOM通用分析、维度不固定、防止数据倾斜、宽表大表首选3. 桶数量黄金标准生产通用单分区单桶数据量控制在1GB ~ 10GB最佳日增量千万以内16/32 桶日增量千万~亿级32/64 桶超大表、高并发64/128 桶禁忌桶太少并行度不够桶太多产生大量小文件元数据压力大。4. 场景化分桶实战案例场景 1用户维度明细表点查用户分析设计Hash 分桶分桶键user_idDISTRIBUTED BY HASH(user_id) BUCKETS 32原因user_id 基数极高、分布均匀按用户查询可精准桶裁剪用户维度 Join 可 Colocate 优化。场景 2订单流水大表、查询维度不固定设计Random 分桶DISTRIBUTED BY RANDOM BUCKETS 64原因查询无固定等值字段Random 彻底杜绝倾斜适配任意维度聚合分析。场景 3单字段倾斜严重如商家数据头部热点设计组合 Hash 分桶DISTRIBUTED BY HASH(shop_id, user_id) BUCKETS 64原因单一 shop_id 热点严重组合高基数字段打散数据彻底解决倾斜。四、全网最实用业务场景一键匹配分区分桶方案业务场景分区方案分桶方案核心理由用户行为日志、点击曝光Range 按天动态分区Hash(device_id/user_id) 32 桶时序数据需过期清理用户维度查询多订单/交易流水表Range 按天动态分区Hash(order_id) 64 桶订单唯一主键绝对均匀点查高效城市/渠道维度统计表List 按城市/渠道分区Random 16 桶维度固定聚合查询多无需定点裁剪大宽表、多维度随机分析Range 按月分区Random 64 桶规避倾斜最大化集群并行度维度小表、配置表不分区Random 8 桶数据量小无需分区管理五、高频踩坑黑名单90% 人都错错误 1用低基数字段分桶❌ 错误hash(status)、hash(sex)✅ 后果数据极度倾斜部分 BE 打爆部分空闲查询超时错误 2大表不分区❌ 错误亿级流水无分区✅ 后果无法过期删除、查询必扫全表、数据膨胀无法治理错误 3分区极细、分区过多❌ 错误秒级/小时级分区产生上万分区✅ 后果元数据爆炸、FE 压力大、查询性能骤降原则日数据量千万级用天分区亿级可小时分区绝大多数业务天分区足够。错误 4分区键和查询条件脱节❌ 按时间分区但业务经常跨月查询、不带时间条件✅ 后果分区裁剪失效分区完全白设计六、终极设计口诀快速复盘分区看业务、分桶看分布1. 时序流水必按时间 Range 动态分区方便裁剪与过期清理2. 固定离散维度用 List 分区精准缩小扫描范围3. 分桶优先高基数单点查询用 Hash通用分析用 Random4. 单字段倾斜就组合分桶桶数控制单桶 1-10GB5. 小表不分区、大表必分区、杜绝低基数分桶七、结尾Doris 的性能上限80% 取决于分区分桶设计20% 才是 SQL 优化、索引优化。很多时候你的查询慢、集群负载不均、数据过期卡顿并不是集群配置不够而是表结构分层设计完全不合理。按照本文场景化方案建表基本可以覆盖企业 99% 实时数仓、离线分析、数据同步场景实现性能与运维性双最优。
