跳到主要内容

表模型概述

在 Doris 中建表时必须指定表模型(Table Model),它决定了数据的存储、去重、聚合与更新方式。Doris 提供三种表模型:明细模型(Duplicate Key)、主键模型(Unique Key)和聚合模型(Aggregate Key),分别覆盖原始数据保留、按主键更新、预聚合分析三类典型场景。表模型在建表后不可修改,因此选型至关重要。

按场景选择表模型

下表帮助您在建表前快速判断应使用哪种表模型:

业务场景推荐模型关键特征
日志、事件、行为分析等需保留全部原始记录明细模型(Duplicate Key)Key 列允许重复,适合任意维度的 Ad-hoc 查询
实时维表、订单、用户画像等需按主键更新主键模型(Unique Key)Key 列唯一,仅保留同 Key 的最新数据
报表汇总、流量统计等需预聚合的固定分析聚合模型(Aggregate Key)按 Key 列预聚合,减少扫描量与计算量

三种表模型详解

明细模型(Duplicate Key Model)

  • 核心机制:允许指定的 Key 列重复,存储层保留全部写入数据,不做去重或聚合。
  • 适用场景:必须保留所有原始数据记录的情况,例如日志、明细事件、行为流水等。
  • 优势:不受聚合约束,可充分利用列式存储——查询时只读取相关列,无需读取全部 Key 列,适合任意维度的 Ad-hoc 查询。
  • 限制:无法利用预聚合带来的查询加速。
  • 详细说明明细模型

主键模型(Unique Key Model)

  • 核心机制:每行的 Key 值唯一,存储层针对每个 Key 仅保留最新写入的数据。
  • 适用场景:需要唯一主键约束、且数据会被持续更新的情况,例如实时维表、订单状态、用户画像。
  • 优势:保证主键唯一性,支持 UPDATEDELETE 语句,支持导入时整行更新与部分列更新。
  • 限制:无法利用 ROLLUP 等预聚合带来的查询加速。
  • 详细说明主键模型

聚合模型(Aggregate Key Model)

  • 核心机制:按 Key 列对 Value 列进行预聚合,存储层仅保留聚合后的结果。
  • 适用场景:维度固定的报表类查询,例如指标汇总、流量统计、广告点击聚合。
  • 优势:通过预聚合大幅降低查询时的扫描数据量与计算量。
  • 限制
    • count(*) 查询不友好。
    • Value 列的聚合方式在建表时已固定,进行其他类型的聚合查询时,需要考虑语意正确性。
  • 详细说明聚合模型
部分列更新

主键模型与聚合模型均支持部分列更新,请查阅 主键模型部分列更新聚合模型部分列更新 获取相关使用建议。

排序键(Sort Key)

在 Doris 中,数据按列存储,一张表的列分为两类:

  • Key 列:用于分组与排序,建表时显式指定。
  • Value 列:跟随 Key 列存储,用于参与聚合计算。

Key 列可由一个或多个字段组成。无论使用哪种表模型,建表时都需要指定 Key 列,数据在存储层会按 Key 列排序存储。Key 列在不同模型中的含义略有差异:

表模型Key 列作用
明细模型(Duplicate Key)仅用于排序,不强制唯一
主键模型(Unique Key)排序 + 唯一约束,用于按主键去重
聚合模型(Aggregate Key)排序 + 唯一约束,用于按 Key 预聚合

合理使用排序键的收益

合理设计排序键可以从以下三方面提升性能:

  1. 加速查询性能:排序键有助于减少数据扫描量。范围查询或过滤查询可基于排序键直接定位数据位置;需要排序的查询也能借助排序键加速。
  2. 优化数据压缩:相似数据按排序键聚集存储,显著提升压缩率,降低存储空间占用。
  3. 降低去重成本:在主键模型中,排序键能让 Doris 更高效地完成主键去重,保证数据唯一性。

排序键设计建议

设计 Key 列时,建议遵循以下原则:

  • Key 列必须位于所有 Value 列之前
  • 优先选择整型类型:整型在计算与查找效率上远高于字符串。
  • 整型长度够用即可:在满足业务范围的前提下,选择尽可能短的整型类型。
  • VARCHARSTRING 长度够用即可:避免预留过长的字段长度。

表模型能力对比

下表汇总了三种表模型在去重、视图、更新与导入方面的能力差异:

能力明细模型主键模型聚合模型
Key 列唯一约束不支持,Key 列可以重复支持支持
同步物化视图支持支持支持
异步物化视图支持支持支持
UPDATE 语句不支持支持不支持
DELETE 语句部分支持支持不支持
导入时整行更新不支持支持不支持
导入时部分列更新不支持支持部分支持

下一步

了解模型差异后,可继续阅读各模型的详细文档: