DorisDB明细模型与聚合模型

DorisDB明细模型与聚合模型

            --2021-06-14 刘春雷

1、前言

作为一个刚接触DorisDB不久的小白,今天跟大家分享下明细模型与聚合模型的业务场景。

为什么要分享这个呢?其实在使用DorisDB初期,我一直天真的以为,DorisDB为什么要提供这么多模型呢?一个明细模型不就能覆盖所有场景了吗?

然鹅,随着逐步的使用,我发现聚合模型: 真香!不仅聚合模型,更新模型都是有着许多的场景的,可以大大方便了业务的使用。

2、业务场景

58同城有着上万台的服务器,每天这些服务器上的信息情况到底如何?有没有安全风险?各种进程数据信息是什么样的?这些都是内部安全人员比较关心的。

但是面对着如此多的服务器,如此多的信息,如何快速收集落地、统一实时分析呢?

  • 写入的量上的要求,每天大约 三十亿 左右的数据需要落地
  • 实时分析:快速的分析,例如:最近15分钟,机器相关信息的情况是怎样的?
  • 数据保留30天内

3、业务数据接入与对比

这个安全分析的业务是DBA接手的第一个DorisDB业务,当时DBA就快速的搭建了一套集群,3FE+3BE,建立了明细表,走kafka接入数据。大致如下:(省略了其他信息字段)

【建表SQL】:

CREATE TABLE test_dup_table (
create_time datetime NULL COMMENT “create time”,
ip varchar(15) NULL COMMENT “IP”,
pid int NULL COMMENT “”
) ENGINE=OLAP
DUPLICATE KEY(create_time, ip,pid)
PARTITION BY RANGE(create_time)
(PARTITION p20210613 VALUES LESS THAN (‘2021-06-13 23:59:59’),
PARTITION p20210614 VALUES LESS THAN (‘2021-06-14 23:59:59’),
PARTITION p20210615 VALUES LESS THAN (‘2021-06-15 23:59:59’)
)
DISTRIBUTED BY HASH(ip) BUCKETS 48
PROPERTIES (
“replication_num” = “3”,
“in_memory” = “false”,
“storage_format” = “DEFAULT”
);

【模拟数据写入】:

insert into test_dup_table values(‘2021-06-14 14:16:00’,‘10.0.0.1’,1);
insert into test_dup_table values(‘2021-06-14 14:17:00’,‘10.0.0.1’,2);
insert into test_dup_table values(‘2021-06-14 14:18:00’,‘10.0.0.2’,3);
insert into test_dup_table values(‘2021-06-14 14:31:00’,‘10.0.0.1’,1);
insert into test_dup_table values(‘2021-06-14 14:32:00’,‘10.0.0.1’,1);
insert into test_dup_table values(‘2021-06-14 14:33:00’,‘10.0.0.1’,1);

【数据信息】:

明细数据

【问题】:

刚开始写入都挺好的,写入性能也很快,写入速度大约3.5w/s,简单测试查询SQL也都ok。

但过了一阵,业务反馈,无法写入了,我们排查,存在报错:

ERROR 1064 (HY000): errCode = 2, detailMessage = Database[default_cluster:xxx] data size exceeds quota[1024.000 GB]

排查为需要设置配额:执行SQL修改就行

ALTER DATABASE xxx SET DATA QUOTA 24576GB; 新版本取消

这时我们还没感觉到不对劲~又过了十几天,我们登录数据库发现表条数已经超过800亿了,磁盘占用8T+,且查询效率也下降了。

【优化】:

这时候我们发现,也不能一味的狂写详细表,数据量大了,效率肯定会存在问题,如何优化呢?我们又跟业务沟通了下场景。发现业务是想统计某些IP、pid 在指定时间范围的数据情况并排序等,例如15分钟区间。对于特别详细的历史信息不强求。

于是我们开始考虑:聚合模型。思路就是:业务写入的时间分为3种,处理后的时间戳跟最近的15分钟对齐,然后传入正常时间,分别记录为 最小时间,最大时间,添加count字段,记录数量。与15分钟对齐的时间+IP+pid 为唯一。

建表改为:

CREATE TABLE test_agg_table (
agg_time datetime NULL COMMENT “agg time”,
ip varchar(15) NULL COMMENT “IP”,
pid int NULL COMMENT “”,
all_count bigint SUM NULL COMMENT “all count”,
time_min datetime MIN NULL COMMENT “min time”,
time_max datetime MAX NULL COMMENT “max time”
) ENGINE=OLAP
AGGREGATE KEY(agg_time, ip,pid)
PARTITION BY RANGE(agg_time)
(PARTITION p20210613 VALUES LESS THAN (‘2021-06-13 23:59:59’),
PARTITION p20210614 VALUES LESS THAN (‘2021-06-14 23:59:59’),
PARTITION p20210615 VALUES LESS THAN (‘2021-06-15 23:59:59’)
)
DISTRIBUTED BY HASH(ip) BUCKETS 48
PROPERTIES (
“replication_num” = “3”,
“in_memory” = “false”,
“storage_format” = “DEFAULT”
);

【模拟数据写入】:

insert into test_agg_table values(‘2021-06-14 14:15:00’,‘10.0.0.1’,1,1,‘2021-06-14 14:16:01’,‘2021-06-14 14:16:59’);
insert into test_agg_table values(‘2021-06-14 14:15:00’,‘10.0.0.1’,2,1,‘2021-06-14 14:17:01’,‘2021-06-14 14:17:59’);
insert into test_agg_table values(‘2021-06-14 14:15:00’,‘10.0.0.2’,3,1,‘2021-06-14 14:18:01’,‘2021-06-14 14:18:59’);
insert into test_agg_table values(‘2021-06-14 14:30:00’,‘10.0.0.1’,1,1,‘2021-06-14 14:31:01’,‘2021-06-14 14:31:59’);
insert into test_agg_table values(‘2021-06-14 14:30:00’,‘10.0.0.1’,1,1,‘2021-06-14 14:32:01’,‘2021-06-14 14:32:59’);
insert into test_agg_table values(‘2021-06-14 14:30:00’,‘10.0.0.1’,1,1,‘2021-06-14 14:33:01’,‘2021-06-14 14:33:59’);

【数据信息】:

select * from test_agg_table order by agg_time;

【优化效果】:

可以从表中看出,新写入的数据,已经进行了合并,数量all_count 进行了累加,这样数据量就明显减少了,且数据按照时间分区,定期清理数据就行了。

对比

4、总结

4.1、模型业务场景

所以大家接入业务的时候,要充分了解业务的场景、需求,查询情况等,来方便给业务建表模型的建议。

官方文档上对于明细模型与聚合模型的大致说明如下,大家可以参考,后续更新模型我们后面会有使用,届时再进行分享~

【明细模型】:场景特点:

  • 需要保留原始的数据(例如原始日志,原始操作记录等)来进行分析;
  • 查询方式灵活, 不局限于预先定义的分析方式, 传统的预聚合方式难以命中;
  • 数据更新不频繁。导入数据的来源一般为日志数据或者是时序数据, 以追加写为主要特点, 数据产生后就不会发生太多变化。

【聚合模型】:场景:

对数据进行统计和汇总操作的场景:

  • 分析网站或APP访问流量,统计用户的访问总时长、访问总次数;

  • 广告厂商为广告主提供的广告点击总量、展示总量、消费统计等;

  • 分析电商的全年的交易数据, 获得某指定季度或者月份的, 各人口分类(geographic)的爆款商品.

【聚合模型】:特点:

  • 业务方进行的查询为汇总类查询,比如sum、count、 max等类型的查询;
  • 不需要召回原始的明细数据;
  • 老数据不会被频繁更新,只会追加新数据。
1赞