doris实战处理（一）doris表的建表规范、查询

感谢原文：https://mp.weixin.qq.com/s/tGbdkF62WU6qbAH0mqtXuA

第一部分：字符集规范

【强制】数据库字符集指定utf-8，并且只支持utf-8。

命令规范

【建议】库名统一使用小写方式，中间用下划线（_）分割，长度62字节内
【建议】表名称大小写敏感，统一使用小写方式，中间用下划线（_）分割，长度64字节内

第二部分：建表规范

【强制】确保每个tablet大小为1-3G之间。举例：假设表内单分区数据量在100G，按天分区,bucket数量100个。
【强烈建议】不要使用Auto Bucket ，按照自己的数据量来进行分区分桶，这样你的导入及查询性能都会得到很好的效果，Auto Bucket 会造成 tablet 数量过多，造成大量小文件的问题。
【强制】 5 亿以上的数据必须设置分区分桶策略

a、没有办法分区的，数据又缓慢增长的：单个tablet数据量保持在1-3G；比如5亿数据大小在20G，bucket数量给20个

b、没有办法分区的，数据又较快增长的，没办法按照时间动态分区，可以适当放大一下你的bucket数量，按照你的数据保存周期（180天）数据总量，来估算你的bucket数量应该是多少，建议还是单个bucket大小在1-3G。

c、一个是对分桶字段进行加盐处理，业务上查询的时候也是要同样的加盐策略，这样能利用到分桶数据剪裁能力

d、另外一个是数据随机分桶，这种缺点是没办法利用数据分桶剪裁能力，数据分布会很均匀

e、避免数据倾斜的问题
100M以内：1 buckets
100M-1G ：3-5 个 Buckets
大于1G-3G ：5-7个 buckets
3-5G ：7-10 个 buckets

f、维度表：缓慢增长的，可以使用单分区，在分桶策略上使用常用查询条件（这个字段数据分步相对均衡）分桶，

g、事实表
【建议】 1000w-2 亿以内数据为了方便可以不设置分区，直接用分桶策略。（不设置其实Doris内部会有个默认分区）

a、参考上面第二点
【强制】 2000kw 以内数据禁止使用动态分区（动态分区会自动创建分区，而小表用户客户关注不到，会创建出大量不使用分区分桶）

a、参考上面第二点
【强制】对于有大量历史分区数据，但是历史数据比较少，或者不均衡，或者查询概率的情况，使用如下方式将数据放在特殊分区。

对于历史数据，如果数据量比较小我们可以创建历史分区（比如年分区，月分区），将所有历史数据放到对应分区里
创建历史分区方式
例如：FROM (“2000-01-01”) TO (“2022-01-01”) INTERVAL 1 YEAR
具体参考：https://doris.apache.org/zh-CN/docs/sql-manual/sql-reference/Data-Definition-Statements/Create/CREATE-TABLE#partition_info
在这里插入图片描述

【强制】如果分桶字段存在30%以上的数据倾斜，则禁止使用Hash分桶策略，改使用random分桶策略

参考上面第二点事实表部分
【建议】前缀索引的第一个字段一定是最长查询的字段，并且需要是高基字段。这里面选取分区分桶外最长查询且高基数的列

分桶字段注意事项：这个一般是数据分布比较均衡的，也是经常使用的字段，最好是高基数字段

Int（4）+ Int（4） + varchar(50)，前缀索引长度只有28

Int（4） + varchar(50) + Int（4），前缀索引长度只有24

varchar(10) + varchar(50) ，前缀索引长度只有30

前缀索引（36位）：第一个字段查询性能最好，前缀索引碰见varchar类型的字段，会自动截断前20个字符

最常用的查询字段如果能放到前缀索引里尽可能放到前前缀索引里，如果不能，可以放到分桶字段里

good case ：UNIQUE KEY(user_id, age) user_id最长被查询，且数据分布比较散

bad case ：UNIQUE KEY(age,user_id ) age是低基数列，且可能存在数据倾斜

【强制】表的副本数必须为3
【建议】前缀索引中的字段长度尽可能明确，因为Doris只有前36个字节能走前缀索引
【强制】除了UNIQUE KEY和aggregate key要构建key的情况，否则不要基数（例如user_type）小于50的字段建立任何索引。因为Doris内置了字典类型优化。

已经有了低基数优化了

Unique Key 是aggregate key 的一个特例，当aggregate key 的key 保持唯一其实就是Unqiue key 模型

【强制】BloomFilter索引必须在查询条件是in或者=，并且是高基（5000以上）列上构建。

首先BloomFilter适用于非前缀过滤。

查询会根据该列高频过滤，而且查询条件大多是 in 和 = 过滤。

不同于Bitmap, BloomFilter适用于高基数列。比如UserID。因为如果创建在低基数的列上，比如 “性别” 列，则每个Block几乎都会包含所有取值，导致BloomFilter索引失去意义。

数据基数在一半左右

类似身份证号这种基数特别高并且查询是等值（=）查询，使用Bitmap索引能极大加速

Bloomfilter 使用场景：

【强制】bitmap索引必须在一定基数范围内构建，太高或者太低的基数都不合适

Bitmap 索引支持类型

【强制】亿级别以上数据，如果有模糊匹配，使用倒排索引或者是 NGram Bloomfilter

【建议】如果某个范围数据在分区分桶和前缀索引中都不好设计，可以考虑引入倒排索引加速。

【强制】单表物化视图不能超过6个

单笔物化视图是实时构建

在unique 模型上物化视图只能起到 Key 重新排序的作用，不能做数据的聚合，因为Unqiue模型的聚合模型是replace

【建议】建议使用JSON数据类型代替字符串类型存放JSON数据的使用方式

第三部分：数据变更规范

【强制】应用程序不可以直接使用delete或者update语句变更数据，使用CDC的upsert方式来实现。

低频操作上使用，比如 Update 几分钟更新一次

如果使用 Delete 一定带上分区条件

【强制】DBA执行delete后者update语句时必须带分区条件

【强制】禁止使用INSERT INTO tbl1 VALUES (“1”), (“a”);这种方式写入数据。

【建议】特殊大的ETL操作，简单单独在Session中设置超时时间

SELECT/+ SET_VAR(query_timeout = 1/ sleep(3);
第四部分：数据查询规范
select * from kunpeng_risk_record krr where krr.event_occur_time_date between ‘2023-10-01 00:00:00’ and ‘2023-10-25 23:59:59’ and krr.partner_code = ‘liveme’ order by krr.sequence_id desc limit 20;
3. 表属性级别

“enable_unique_key_merge_on_write” = “true”,
“store_row_column” = “true”
be.conf
disable_storage_row_cache 是否开启行缓存，默认不开启