StarRocks 有比较丰富的数据模型

1、表的存储

对表进行存储时，会对表进行分区和分桶两层处理，将表的数据分散到多台机器进行存储和管理。

• 分区机制：高效过滤，提升查询性能。

分区类似分表，是对一个表按照分区键进行分割，可以按照时间分区，根据数据量按照天 / 月 / 年划分。在查询过程中，可以利用分区裁剪降低数据扫描量提升查询效率，也可以根据数据的冷热程度把数据分到不同介质上。

• 分桶机制：充分发挥集群性能，避免热点问题。

使用分桶键 Hash 以后，把数据均匀分布到所有 BE 上，不要出现 bucket 数据倾斜的情况。分桶键的选择原则就是分桶列（一个或多个分桶列）的基数要足够高可以将数据充分打散。

Bucket 数量需要适中，如果希望充分发挥性能，可以设置为：BE 数量 * CPU core/2， tablet 最好控制在 1GB-10GB 左右，新版本已经实现 tablet 内部的并行 scan，tablet 数量和 SQL 并行度已经不完全绑定，即使在 Tablet 数量较少的情况下，依然能够充分利用 CPU 资源来并行计算。

• Tablet：最小的数据逻辑单元，可以灵活设置并行计算资源。

一张表被切分成了多个 Tablet，StarRocks 在执行 SQL 语句时，可以对所有 Tablet 实现并发处理，从而充分利用多机、多核提供的计算能力。

表在创建的时候可以指定副本数，多副本够保证数据存储的高可靠、服务的高可用。

• Rowset：每一次数据导入都会生成一个新的数据版本，保存在一个 rowset 中。

一个 tablet 可能有 N（N>=0） 个 rowset，一个 rowset 对应 M（M>=0） 个实际数据文件。

每次写入都会增加一个版本，无论是单条、还是 stream load 几个 G 的文件。

• Segment：如果一个 Rowset 数据量比较大，则拆分成多个 Segment 数据落盘。

#04

案例一：指标工厂服务

—

1、业务背景

指标工厂服务主要面向业务人员，通过对业务指标的采集和处理，实时反映产品状态，为运营提供数据支撑、检测产品漏洞或服务异常、提供指标异常告警功能等。

2、业务场景分析

业务指标埋点方式多样，并不局限于某种方式，只要符合埋点标识明确、业务参数丰富、数据满足可解析的基本要求皆可作为数据源，大致可以分为：SDK、MySQL BinLog、业务日志、阿里云 ODPS 数据分析。

各种业务场景众口难调，归纳数据特征如下： 

1. 需要全量日志明细；

2. 需要数据始终是最新的，即满足实时更新场景；

3. 需要对数据做层级聚合的，即可能是月、周、日、小时等；

4. 需要可以承载更大的写入量；

5. 每个业务数据都要灵活配置数据的保存时间；

6. 数据源来源多，报表定制化比较高，有多个数据源合并成一个大宽表的场景、也有多表连接的的需求；

7. 各种监控图、报表展示、业务实时查询等，即较高的并非查询。

3、引入 StarRocks

幸运的是，StarRocks 有比较丰富的数据模型，覆盖了上面的所有业务场景的需求，即明细模型、更新模型、聚合模型、主键模型。同时，选择更为灵活的星型模型代替大宽表的方式，即直接使用多表关联来查询。 

• 明细模型： 

1. 埋点数据经过结构化处理后按明细全量存储；

2. 该场景对 DB 在亿级数据量下查询性能有较高的要求；

3. 数据可以通过配置动态分区来配置过期策略；

4. 场景使用时从结构化数据选择个别字段维度在线聚合查询。

• 聚合模型：

1. 埋点数据数据量巨大，且对明细数据不要求溯源，直接做聚合计算，比如计算 PV、UV 场景；

2. 数据可以通过配置动态分区来配置过期策略。 

• 更新模型： 

1. 埋点数据状态会发生变动，且需要实时更新数据，更新数据范围不会跨度多个分区的，比如：订单、优惠券状态等；

2. 数据可以通过配置动态分区来配置过期策略。

基于以上业务场景的分析，这三种模型可以完美解决数据的问题。

需要实时的数据写入场景，我也沿用了业内流行的解决方案，使用 Flink 实时消费 Kafka 的数据，再以微批的方式（十秒一批）写入到 StarRocks。并且 StarRocks 提供了非常好用的 Flink-connector 插件，可以通过多种方式控制数据的写入频率，在满足数据时效性的要求的同时，也可以降低集群的导入压力。