StarRocks明细模型与聚合模型
--2021-06-14 刘春雷
1、前言
作为一个刚接触StarRocks不久的小白，今天跟大家分享下明细模型与聚合模型的业务场景。
为什么要分享这个呢？其实在使用StarRocks初期，我一直天真的以为，StarRocks为什么要提供这么多模型呢？一个明细模型不就能覆盖所有场景了吗？
然鹅，随着逐步的使用，我发现聚合模型： 真香！不仅聚合模型，更新模型都是有着许多的场景的，可以大大方便了业务的使用。
2、业务场景
58同城有着上万台的服务器，每天这些服务器上的信息情况到底如何？有没有安全风险？各种进程数据信息是什么样的？这些都是内部安全人员比较关心的。
但是面对着如此多的服务器，如此多的信息，如何快速收集落地、统一实时分析呢？
- 写入的量上的要求，每天大约 三十亿 左右的数据需要落地
- 实时分析：快速的分析，例如：最近15分钟，机器相关信息的情况是怎样的？
- 数据保留30天内
3、业务数据接入与对比
这个安全分析的业务是DBA接手的第一个StarRocks业务，当时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等类型的查询；
- 不需要召回原始的明细数据；
- 老数据不会被频繁更新，只会追加新数据。