springboot项目引入了doris数据，建表模式如何选？

时间：2023-02-19 14:05:48

1.为什么引入doris

因为目前博主项目用的mysql属于行存储，因为数据量较大遇到了瓶颈，每次数据刷新脚本执行的时间太长了，一晚上都不一定能更新完。于是领导让研究其他数据存放方式，而列存储很流行也很优秀，天选DB。 什么是列存储呢？举一个具体的例子，假设我们有一个employ关系表，employ表含有uuid，name，age三列，表总大小大约在3G左右。在行存储中，表”水平”存储，即按行连续存储，首先第一行，然后第二行。。。当执行SELECT uuid FROM employ 需要遍历表的所有数据(3G)来返回uuid列。而如果采用列存储，表是”垂直”存储的，每一列独立的存储为一个文件，employ表中的每一个列都有一个对应的文件存储。当用户执行SELECT uuid FROM employ 时，只需查询uuid对应的文件即可(30M)，而不必查询其他列所对应的文件，从而极大的减少了磁盘访问，提高查询速度。 列存储的优势：列存储查询可以剔除无关的列，当查询只有少量列时，可以极大的减少查询的数据量，提高查询速度。此外，列式存储还有更优秀的压缩算法等，掌握列存储技术不论对于求职面试，技术选型，还是增加自己的知识广度都是非常有帮助的。

2.doris安装与基本概念

由于官网或者各博客上都有详细的安装教程，我本人安装也没遇到啥困难，便不再赘述安装过程。默认安装完成之后可以访问8030端口的客户端，也可以通过navicat客户端工具连接，跟mysql连接用法一样，在程序中测试直接用jdbc连接即可。 基本概念：

  1. Column分类-在聚合模型中，Column 可以分为两大类：Key 和 Value。从业务角度看，Key 和Value 可以分别对应维度列和指标列。从聚合模型的角度来说，Key 列相同的行，会聚合成一行。其中 Value 列的聚合方式由用户在建表时指定。
  2. 分区和分桶（Partition & Tablet） 在 Doris 的存储引擎中，用户数据首先被划分成若干个分区（Partition），划分的规则通 常是按照用户指定的分区列进行范围划分，比如按时间划分。而在每个分区内，数据被进一步的按照 Hash 的方式分桶，分桶的规则是要找用户指定的分桶列的值进行 Hash 后分桶。每个分桶就是一个数据分片（Tablet），也是数据划分的最小逻辑单元。 ⚫ Tablet 之间的数据是没有交集的，独立存储的。Tablet 也是数据移动、复制等操作 的最小物理存储单元。 ⚫ Partition 可以视为是逻辑上最小的管理单元。数据的导入与删除，都可以或仅能针 对一个 Partition 进行。 可以不用分区，但一般都会进行分桶。 Doris 的数据模型主要分为 3 类：Aggregate、Uniq、Duplicate, 这三类模型如何选择是本文重点讨论内容。

3.doris数据模型-Aggregate

Aggregate 模型即聚合模型，表中的列按照是否设置了聚合类型（AggregationType），分为 Key（维度列）和 Value（指标列），没有设置 AggregationType 的称为 Key，设置了 AggregationType 的称为 Value。 AggregationType 目前有以下四种聚合方式： ➢ SUM：求和，多行的 Value 进行累加。 ➢ REPLACE：替代，下一批数据中的 Value 会替换之前导入过的行中的 Value(查询数据取最新的)。 ➢ REPLACE_IF_NOT_NULL ：当遇到 null 值则不更新。 ➢ MAX：保留最大值。 ➢ MIN：保留最小值。

比如我从mysql表切换到doris的时候，key列一般设置成系统原有的列，value列是多出来的几个聚合字段，如前面某个字段的sum汇总值等。 当我们导入数据时，对于 Key 列相同的行会聚合成一行，而 Value 列会按照设置的AggregationType 进行聚合。可以看出来这种模式非常适合统计分析模块，可以将经常group by分组查询的列设为key, 需要统计的值设为value列，这样导入数据时key列所有值相等的数据就预聚合了（最好不要有timestamp类型的数据，这样key值不同是无法聚合的） 什么时候会发生数据聚合呢，在 Doris 中有如下三个阶段发生： （1）每一批次数据导入阶段。该阶段会在每一批次导入的数据内部进行聚合。 （2）底层 BE 进行数据 合并 的阶段。导入后数据有FE提交给BE后，BE 会对已导入的不同批次的数据进行进一步的聚合（有时延）。 （3）数据查询阶段。在数据查询时，对于查询涉及到的数据，会进行对应的聚合。 建表语句参考：

CREATE TABLE IF NOT EXISTS test_db.example_user
(
 `user_id` LARGEINT NOT NULL COMMENT "用户 id",
 `date` DATE NOT NULL COMMENT "数据灌入日期时间",
 `city` VARCHAR(20) COMMENT "用户所在城市",
 `age` SMALLINT COMMENT "用户年龄",
 `sex` TINYINT COMMENT "用户性别",
`last_visit_date` DATETIME REPLACE DEFAULT "1970-01-01 
00:00:00" COMMENT "用户最后一次访问时间",
 `last_visit_date_not_null` DATETIME REPLACE_IF_NOT_NULL DEFAULT 
"1970-01-01 00:00:00" COMMENT "用户最后一次访问时间",
 `cost` BIGINT SUM DEFAULT "0" COMMENT "用户总消费"
)
AGGREGATE KEY(`user_id`, `date`, `city`, `age`, `sex`)
DISTRIBUTED BY HASH(`user_id`) BUCKETS 10;

4.doris数据模型-Uniq

在某些多维分析场景下，用户更关注的是如何保证 Key 的唯一性，即如何获得 Primary Key 唯一性约束。因此，我们引入了 Uniq 的数据模型。该模型本质上是聚合模型的一个特例，也是一种简化的表结构表示方式。 建表语句参考：

CREATE TABLE IF NOT EXISTS test_db.user
(
 `user_id` LARGEINT NOT NULL COMMENT "用户 id",
 `username` VARCHAR(50) NOT NULL COMMENT "用户昵称",
 `age` SMALLINT COMMENT "用户年龄",
 `sex` TINYINT COMMENT "用户性别",
 `phone` LARGEINT COMMENT "用户电话",
 `address` VARCHAR(500) COMMENT "用户地址",
 `register_time` DATETIME COMMENT "用户注册时间"
)
UNIQUE KEY(`user_id`, `username`)
DISTRIBUTED BY HASH(`user_id`) BUCKETS 10;

5.doris数据模型-Duplicate

在某些场景下，数据既没有主键，也没有聚合需求。Duplicate 数据模型可以满足这类需求。数据完全按照导入文件中的数据进行存储，不会有任何聚合。即使两行数据完全相同，也都会保留。 而在建表语句中指定的 DUPLICATE KEY，只是用来指明底层数据按照那些列进行排序。

CREATE TABLE IF NOT EXISTS test_db.example_log
(
 `timestamp` DATETIME NOT NULL COMMENT "日志时间",
 `type` INT NOT NULL COMMENT "日志类型",
 `error_code` INT COMMENT "错误码",
 `error_msg` VARCHAR(1024) COMMENT "错误详细信息",
 `op_id` BIGINT COMMENT "负责人 id",
 `op_time` DATETIME COMMENT "处理时间"
)
DUPLICATE KEY(`timestamp`, `type`)
DISTRIBUTED BY HASH(`timestamp`) BUCKETS 10;

6.数据模型的选择建议

因为数据模型在建表时就已经确定，且无法修改。所以，选择一个合适的数据模型非常重要，如果建表时没有指定具体模式，默认为明细Duplicate模式。 （1）Aggregate 模型可以通过预聚合，极大地降低聚合查询时所需扫描的数据量和查询 的计算量，非常适合有固定模式的报表类/统计分析类查询场景。但是因为数据发生了聚合所以该模型对 count(*) 查询很不友好，这里可以通过增加一个聚合类型为sum或replace的统计字段来解决。同时因为固定了 Value 列上的聚合方式，在进行其他类型的聚合查询时有可能得到不正确的结果，如一个Max类型的value列，求最小值可能不正确。 （2）Uniq 模型针对需要唯一主键约束的场景，可以保证主键唯一性约束。但是无法利 用 ROLLUP （有点像在表的基础上增加个物化视图）等预聚合带来的查询优势（因为本质是 REPLACE，没有 SUM 这种聚合方式）。 （3）Duplicate 适合任意维度的查询。虽然同样无法利用预聚合的特性，但是不 受聚合模型的约束，可以发挥列存模型的优势（只读取相关列，而不需要读取所有 Key 列）

综上，因为我们项目的需求定制化程度较高，建表模式选了官方推荐的Aggregate模型，但因为有时间戳字段所以基本上没有聚合，为了防止聚合后查询数量不正确加上了冗余的字段。 非常遗憾的是团队成员对doris不熟悉，且引入新的服务到生产环境有个繁琐的审批流程，期待doris能帮助提高查询性能的计划落空了。

标签：

相关文章