通过 DML 和物化视图在数仓内构建处理数据流

随着 update 和 delete 功能的完善和存储引擎功能的增多，未来还会考虑添加 merge into 语法的支持。我们认为 DML 功能的完善是实时数据分析从 ETL 模式向 ERT 模式演化的一个重要的前提。在 ERT 模式下，原始数据可以直接导入数仓或者目前更加流行的互仓，通过 DML 和物化视图在数仓内构建处理数据流，可以极大地简化数据流的构建难度和成本。

​

#03

未来规划

1、主键与排序键分离

一个表的 key 代表了两方面的属性，一是数据的组织方式（存储顺序）。不同的排序方式，意味着不同的查询类型的加速作用。二是数据集的唯一约束。通过唯一约束保证导入数据的唯一性，不丢不重，以及可以通过主键定位到某一行来进行更新和删除操作。还有一个额外的作用是分布式数据库一般是有很多个分片的，需要通过 key 来将数据分布到不同的分片，所以 key 必须是不可变的。

在目前的主键模型中，可以认为 sort key 和 primary key 是统一在一起的，实现会更简单。数据的排序方式可以加速查询，但是如果按照主键排序，就丧失了这对这些查询的优化的机会。比如图中的表主键是 id，如果按照 id 排序，对 city 过滤的查询就需要去扫描全表或者依赖其他一些二级索引加速过滤。如果把 sort key 和 primary key 拆分开，创建表时可以指定 sort key 和 primary key 不一样，id 作为主键负责更新的唯一约束。city 作为 sort key 负责数据的存储顺序，可以加速查询。

​

目前 StarRocks 各种的表模型，包括 suplicate key、aggregate key、uniq key 都是标准 SQL 表模型的几种特殊表现形式。统一到一种语法表达之后，对用户来说，我们整个系统只有一种表，其概念和数据模型是和标准的数据库模型是非常类似的，这样是最容易理解的，并且可以进一步提升整个 StarRocks 的易用性。

2、部分列更新与导入接口 

目前部分列更新只支持固定列的更新，同一个导入事务中所有行的更新的列必须完全的一致，这就对上游数据造成了很大的一个限制。因为很多应用场景并不是简单的一个多表交应，比如说图中表达的两种这个部分列更新的一个模式。左边是完全静态的部分列更新的支持方式，目前我们是支持的。但是右边的这种任意列更新的方式目前还是不支持的。原因是目前整个导入数据流程都是以向量化的方式去实现的，向量化要求数据是整齐的列存储的方式的表达。那如果强行使用列存的方式组织任意列更新的导入，就会有很多额外的开销，并不高效。

比如一个 1000 列的大宽表，如果每行仅更新其中的一列，如果使用列存组织，这个空间膨胀会非常大。最合适的方式还是回归行存的方式组织，这样就需要对整个导入流程增加一个行存的数据流，工程量会大一些。

​

比较有趣的是，最初我们最初导入部分的数据组方式就是行存的，但是我们为了优化性能，专门把它改成了列存方式，行存的方式逐渐就废弃掉了。那没想到就是随着这个需求和产品的演进，行存方式重新变得重要起来了。

3、物化视图

目前主键模型并不支持 rollup 和物化视图，而 rollup 功能也非常有限，其本质上是一种聚合类的，不需要中间状态的物化视图。StarRocks 新一代的物化视图架构会支持一些更高级的功能，包括透明查询加速、离线的全量构建和实时的增量构建等等。

我们主要关注的就是物化视图对存储引擎层面的一些新需求。一是增量物化视图的构建需要能够提供表的一个增量修改数据。那么我们认为它是一种类似 binlog 的概念，对表的所有写操作都要生成一份日志，里面记录了哪些行被删除掉，哪些行被添加，类似 MySQL 中的 binlog。另外一个是维护物化视图的算子，通常是需要一个状态存储的，并且这个状态存储是需要可持久化的，那也需要存储引擎提供状态存储的支持。其他的查询加速对存储运行也会有新的需求。