Doris数据表、分区、分桶设计详解

1、表数据模型：
数据以表（Table）的形式进行逻辑上的描述。
一张表包括行（Row）和列（Column）。
Row即用户的一行数据，Column用于描述一行数据中不同的字段。
Column可以分为两大类：Key和Value，从业务角度看分别对应，维度列和指标列。
Doris 的Key列是建表语句中指定的列，建表语句中的关键字unique key或aggregate key或duplicate key后面的列就是Key列，除了Key列剩下的就是Value列。
Doris 的数据模型主要分为3类：
明细模型 Duplicate
主键模型 Unique
聚合模型 Aggregate

建表的列类型建议
1、Key列必须在所有Value列之前。
2、尽量选择整型类型。因为整型类型的计算和查找效率远高于字符串。
3、对于不同长度的整型类型的选择原则，遵循够用即可。
4、对于VARCHAR和STRING类型的长度，遵循够用即可。

模型选择建议
因为数据模型在建表时就已经确定，且无法修改。所以，选择一个合适的数据模型非常重要。
1、Aggregate模型可以通过预聚合，极大地降低聚合查询时所需扫描的数据量和查询的计算量，非常适合有固定模式的报表类查询场景。
但是该模型对 count(*) 查询很不友好。同时因为固定了 Value 列上的聚合方式，在进行其他类型的聚合查询时，需要考虑语意正确性。
2、Unique模型针对需要唯一主键约束的场景，可以保证主键唯一性约束。
但是无法利用ROLLUP等预聚合带来的查询优势。对于聚合查询有较高性能需求的用户，推荐使用自1.2版本加入的写时合并实现。
3、Duplicate适合任意维度的Ad-hoc查询。
虽然同样无法利用预聚合的特性，但是不受聚合模型的约束，可以发挥列存模型的优势（只读取相关列，而不需要读取所有Key列）

2、分区和分桶（Partition & Tablet）
Doris支持两层的数据划分。
第一层是支持水平分区（Partition），支持Range和List的划分方式。
将数据按照某个字段值进行分区，相同的值会被分配到同一个分区中。这种方式可以将数据均匀地分布到不同的节点上，提高查询效率和并行处理能力。
第二层是支持垂直分桶-Bucket（Tablet），支持Hash和Random的划分方式。
将同一行数据的不同列分别存储在不同的桶中。这种方式可以将经常一起查询的列存储在同一个桶中，提高查询效率。

1 2 3 4 6 7 -partion1

2 3 |4 5 6 7 -partion2
2 4 |5 6 7 9 -partion2
bucket1 bucket2
一个Tablet只属于一个分区。
一个分区包含若干个Tablet。
Tablet 是数据移动、复制等操作的最小物理存储单元。
若干个分区组成一个Table。
分区可以视为是逻辑上最小的管理单元。
建表时如果不建立分区，此时Doris会生成一个默认的分区，对用户是透明的。使用默认分区时，只支持Bucket划分。

官方Partition和Bucket的数量和数据量的建议:
1、一个表的Tablet总数量等于(Partition num * Bucket num)。
2、一个表的Tablet数量，在不考虑扩容的情况下，推荐略多于整个集群的磁盘数量。
3、单个Tablet的数据量理论上没有上下界，但建议在1G-10G的范围内。
如果单个Tablet数据量过小，则数据的聚合效果不佳，且元数据管理压力大。
如果数据量过大，则不利于副本的迁移、补齐，且会增加Schema Change或者Rollup操作失败重试的代价（这些操作失败重试的粒度是 Tablet）。
4、当Tablet的数据量原则和数量原则冲突时，建议优先考虑数据量原则。
5、在建表时，每个分区的Bucket数量统一指定。
但是在动态增加分区时（ADD PARTITION），可以单独指定新分区的Bucket数量。可以利用这个功能方便的应对数据缩小或膨胀。
6、一个Partition的Bucket数量一旦指定，不可更改。
所以在确定Bucket数量时，需要预先考虑集群扩容的情况。
比如当前只有3台host，每台host有1块盘。如果Bucket的数量只设置为3或更小，那么后期即使再增加机器，也不能提高并发度。
举一些例子：假设在有10台BE，每台BE一块磁盘的情况下。
如果一个表总大小为500MB，则可以考虑4-8个分片。
5GB：8-16个分片。5
0GB：32个分片。
500GB：建议分区，每个分区大小在50GB 左右，每个分区16-32个分片。
5TB：建议分区，每个分区大小在50GB 左右，每个分区16-32个分片。