StarRocks实战——多维分析场景与落地实践

一、OLAP 系统历史背景

1.1 历史背景与痛点

1.2 组件诉求

二、StarRocks 的特点和优势

2.1 极致的查询性能

2.2 丰富的导入方式

2.3 StarRocks 的优势特点

三、多维分析的运用场景

3.1 实时计算场景 / 家长监控中心

3.2 实时更新模型选择

3.2.1 更新模型UNIQUE

3.2.2 主键模型PRIMARY

3.3 主键模型不能使用Delete方式删除数据

3.4 报表实时指标计算

3.5 数据关系模型转变

3.7 精确一次性保证

3.8 指标存储转变

3.9 常用数据导入方式

3.9.1 实时数据

3.9.2 离线数据

3.10 分区分桶选择

3.11 慢查询分析

四、未来规划

原文大佬的这篇StarRocks多维分析场景与落地实践的文章整体写的很深入，这里直接摘抄下来用作学习和知识沉淀。

一、OLAP 系统历史背景

1.1 历史背景与痛点

先阐述下之前做实时和离线指标计算所使用的一些组件：

分钟级别调度的指标计算：用 Presto 或者是 Clickhouse。
kafka数据流的计算：用SparkStreaming或者Flink去读取并计算
标签表的计算：会导入一些标签表到 HBase 里面，然后通过 Data API 的方式去提供给其他的系统使用（比如我们公司是做游戏的，会有一些玩家的标签表在对接客服之类的系统，他们会实时去查看每一个玩家的信息，进行一些问题的解答，我们会提供这样的数据）。
报表展示：报表的实时指标的结果会落到Mysql库中，报表系统会直接读取MySQL作为指标的展示。

这些组件其实各有优势：比如 Presto 直联 Hive，不需要做其他的操作，就可以做一些自主分析；ClickHouse单表查询性能好。但是随着架构演变，数仓集成了特别多组件，带来了以下痛点：

组件太多，维护多套组件的运维成本是比较高。
各组件的 SQL 语法存在差异，特别是 ClickHouse不支持标准 SQL，所以开发维护任务的成本也会比较高。
同一指标数据因为在多套系统都存在，需要确保计算的结果和口径的一致性，数据对齐成本也是比较高。
指标结果数据是落在Mysql中的，有一些维度比较多的数据，其结果数据量是比较大的，需要对 MySQL 通过分表去支持数据的存储和查询。但当数据量达到一定量级，即使分表，查询性能也比较差，导致报表系统时间上响应会比较慢。

1.2 组件诉求

为了解决以上痛点，需要选择统一的OLAP引擎，该引擎至少要满足以下要求：

数据秒级写入，低延迟毫秒级响应
复杂场景多表关联查询性能好
运维简单，方便扩展
支持高并发点查
易用性强，开发简单方便

对比调研了市面上一些组件，希望用一款存算一体的组件去优化我们的整个架构。首先，ClickHouse 的使用和运维比较困难，并且多表关联的性能比较差，所以我们没有选择 ClickHouse。我们又对比了 StarRocks 和 Doris，因为StarRocks在性能上会更好，所以我们最终选择了 StarRocks 作为统一的 OLAP引擎。

二、StarRocks 的特点和优势

2.1 极致的查询性能

StarRocks 是有着极致的查询性能的，主要得益于以下的这几点：

分布式执行 MPP：一条数据/一条查询请求会被拆分成多个物理的执行单元，可以充分利用所有节点的资源，这样对于查询性能是一个很好的提升。
列式存储引擎：对于大多数的 OLAP 引擎来说的话，基本会选择列式存储，因为很多的 OLAP 场景当中，计算基本上只会涉及到部分列的一些提取，所以相对于“行存”来说，列存只读取部分列的数据，可以极大的降低磁盘 IO。
全面向量化引擎：StarRocks所有算子都实现了向量化，向量化简单理解就是它可以消除程序循环的优化，是实现了 Smid 的一个特性，也就是当对一列数据进行相同的操作的时候，可以使用单条指令去操作多条数据，这是一个在 CPU 寄存器层面实行的对数据并行操作的优化。
CBO 优化器：在多表查询或者一些复杂查询的情况下，同一条sql会有不同的执行计划，不同计划之间的执行性能的差异可能会差几个量级，需要一款更好的优化器，才能够选择出相对更优的一个执行计划，从而提升查询效率。

2.2 丰富的导入方式

StarRocks 有丰富的导入方式，对接一些外部组件时，可以通过这些导入方式去直接完成数据的导入，极大节省开发时间。

2.3 StarRocks 的优势特点

运维简单：右侧这个图是 StarRocks 一个简单的架构图，只有FE和 BE 两种组件，不依赖于外部组件，运维简单，并且也方便扩缩容。
丰富的数据模型：StarRocks 支持明细、聚合、更新、主键4种数据模型，同时它还支持物化视图，方便我们针对不同的场景去选择合适的数据模型。
简单易用：StarRocks 兼容 MySQL 协议，支持标准的 SQL 语法，不需要太多的学习成本就可以去直接使用它。
支持多种外部表：StarRocks 支持多种外部表，比如 MySQL、ElasticSearch、Hive、StarRocks（这里指另一个集群的 StarRocks）等，跨集群、跨组件的关联查询也无需数据的导入，可以直接建立外部表，基于多个数据源去做关联查询。

三、多维分析的运用场景

3.1 实时计算场景 / 家长监控中心

例如上图的需求：提供有各个未成年账号的一些实时的在线数据，或者是充值数据。右侧图是这一需求的数据流转图：读取Kafka数据，通过Flink清洗、转换后实时写入StarRocks，再通过 Data API 的方式去提供给小程序使用。因为跨部门协作，所以用Data API 的方式去提供数据比较安全。

同时也有一条离线覆盖的线路，Flink 计算难免会有一些上报的数据存在网络延迟，部分数据的计算可能会有一些差异，所以我们最终要用离线数据去覆盖实时数据，确保离线实时两条链路的数据一致性。

3.2 实时更新模型选择

StarRocks中提供了两种模型可以用于数据的更新，这两种组件的内部机制是有所区别的，所以使用场景也不太一样。

3.2.1 更新模型UNIQUE

内部是使用 Merge on Read 的方式去实现数据的更新的，也就是说 StarRocks 在底层操作的时候不会去更新数据，但是会在查询的时候实时去合并版本，所以同一主键的数据会存储多个版本；这样的好处是在写入的时候会非常流畅，但是也有坏处，在频繁导入数据的时候，主键会存在多个版本的数据，这对于查询性能会有所影响。

3.2.2 主键模型PRIMARY

内部使用的是Delete and Insert（删除并更新）的方式，StarRocks 会将主键存于内存中，在数据写入的时候，会去内存中找到这条数据，然后执行一个标记删除的操作，之后会把新的数据插入进去，最后合并时只需要过滤掉那些标记删除的数据就可以了，它的查询性能会比更新模型更高。

上文提到的需求，对实时性要求是比较高，数据更新特别频繁，因此我们会优先考虑查询性能，最终选择主键模型去作为表的数据模型。

3.3 主键模型不能使用Delete方式删除数据

前文【3.1】提到离线覆盖实时的一个操作，使用场景是当我们在数据有一些差异的时候，需要用离线数据覆盖实时数据。使用 StarRocks 的主键模型进行数据删除时，只能够通过 Stream Load、Broker Load、Routine Load 等这三种导入的方式去删除数据，这是非常不方便的，导入时需要先提供一个标志位（如下图），去标明这是 Upsert 还是 Delete。对于直接写 SQL 语句去删除数据是非常不友好的。

基于StarRocks主键模型能够更新数据的特性，可以选择使用软删除的方式去标记删除。先把这些需要删除的数据查询出来，再变更它的一个删除标志位。

StarRocks的更新模型也是支持删除操作的，我们为什么选择主键模型，而不是选择更新模型呢？主要考虑到以下三点情况：

（1）上文提到的需求，对实时性要求是比较高，数据更新特别频繁，所以用更新模型的查询性势必会有所下降。

（2）更新模型的删除也是有一些限制的，在删除条件比较复杂的情况下也是无法删除的。

比如：只能根据“排序列”去删除，或者是删除条件只能用与 AND 不能用或 OR。

（3）我们会用离线数据去覆盖实时数据，这两份数据其实是非常相近的，只会有很少的不一致，所以我们删除的冗余也是很少的。