大部分基于MPP架构的Olap分析DB，对于频繁更新的场景支撑都不是太友好，但业务系统的逻辑特别是核心的交易逻辑决定了频繁更新的场景是软件中最常见的应用场景，一直以来在大数据应用过程中，这个问题都困扰着大多数的开发人员。

针对Olap分析型DB与业务场景的冲突，有些产品已经做出了改进，提供了支持更新数据的技术实践。比如StarRocks。

具体是怎么做的？我们来看看SR的表模型。

SR的表模型提供了4种不同的数据模型，具体为明细模型、聚合模型、更新模型、主键模型，下面分析一下：

明细模型 (Duplicate Key Model)：只能追加数据，不能修改历史数据。这样适应的场景就很明显了，即具有非常强的时序性的日志分析类场景，日志产生记录，发生了就不会再改变，一直追加，比较好的支撑起了行为分析和部分业务场景的分析。由于日志具备不精确的特征，分析的结果往往与实际的业务是不完全等值的，当然一般行业日志分析结果也不需要精准，具备1%左右偏差的特征。在明细模型中，为了提升分析性能，一般会建立排序键，在日志分析的场景中，一般设置的排序键为事件类型和事件时间，这样分析某时间范围的某一类事件时，性能将会得到比较大的提升。但要注意的是，明细模型中没有唯一键，即使是排序键，也是可以重复的。同时，针对索引的处理，也是落盘存储的。

基于上述特征，感觉明细模型不会应用得太广泛，事实恰恰相反，目前明细模型其实是应用最广泛的数据模型，当然需要进行“额外”的处理才行。比如通过业务主键进行数据的维护，保证数据的准确性，具体为开发人员需要自己维护业务主键的唯一性以保证业务逻辑处理过程中的正确性，实现时采取基于业务主键Delete-Insert的模式，保证业务数据明细记录的准确（不重复）和最终分析结果的准确。采取业务加持后，明细模型成为了最广泛应用的数据模型，常常应用于离线数据处理的场景中。

聚合模型 (Aggregate Key Model)：对于汇总分析统计的场景，可以创建为聚合模型。聚合模型将自动根据排序键，进行指标列的汇总，从而达到查询时少扫描明细行（IO）以提升性能的目的。对于聚合模型，排序列必须唯一，且不能修改，这个对于在业务应用中比较困难，特别是对于一些历史遗留系统。核心原因是此种模型不支持Update模式，只能采取Delete-Insert模式，严格来说只能是Insert追加模式。

为什么只能是Insert模式，举个例子：比如基于City列进行人数聚合，深圳有100人（即插入了100条明细记录），聚合的深圳的总人数是100，后来发现有一条明细记录的数据的City列出错不是深圳而是广州，需要删除一条城市是广州的一条明细，聚合最终结果为深圳总人数是99人，如果要得到正确的99人的结果，只能是将深圳的聚合100的记录删除，然后重新导入99条深圳的明细记录才能完成此数据的修改，无法通过删除一条出错记录，将深圳总人数调整为99人。基于上述例子可以看出聚合模型基于排序键删除的是聚合后的记录，不能删除明细的记录，如果聚合明细记录的维度字段有调整，就会出现上述例子的情况，聚合模型严格来说是Insert追加模式的。基于此种模式，聚合模型的应用非常有限。

更新模型(Unique Key Model)：更新模型其实是聚合模型的一种特殊形式，聚合函数为Replace，即返回具有相同主键的一组数据的最新记录。由于采取的Replace函数，数据其实是没有做聚合的，是明细数据。每一条明细数据，都会有多个版本的记录，查询时返回最新版本的数据，Delete删除时，所有版本都会删除掉。更新模型依然是追加模式，由于有多个版本，查询时会有比较多的开销，性能上不是太优。

主键模型(Primary Key Model)：最后是主键模型，是在1.19版本后增加的，与更新模型类似，但解决了更新模型中最核心的真正更新的逻辑问题，前面已经说过更新模型名称说是更新，但其实也是追加数据的模式。在主键模型中，采取的则是真正的更新模式，非常适合实时和频繁更新的场景，由于不会像更新模型保留多个版本的信息，查询效率也得到很大提升，理论上可以达到3~10倍的提升，具体要看SQL的复杂度。

主键模型对于频繁增删改查的交易业务场景比较适合，特别适合大数据场景中的实时的增量数据更新场景，相信会成为实时的主流应用数据模型。当然代价也是有的，由于主键模型的索引是放内存，相较索引落盘的明细模型更占内存。用硬件换性能也是大数据优化的一种常见模式，所以在设计主键模型时，最好有冷热数据的考虑，比如考虑按时间分区，同时主键模型的表的量级不能太大，一般不要超过亿级，否则对内存的消耗会非常大，当然内存充足的可以不考虑。最后主键模型采取的Update模式（也是Delete-Insert模式），基于表的主键进行数据的更新操作（主键具备唯一性），不需要明细模型需要研发人员自己进行逻辑上的操作。

因此依据主键模型的特点，包括不限于Update更新机制（Delete-Insert模式）确保了数据的唯一规范支持谓词下推，加上内存索引机制，查询时不需要读合并等策略，查询性能得到很大的提升，同时对于实时流数据的处理支撑比较好，后续应该是比较主流的一种数据模型。

结论：总的来说，4种数据模型各有其特征，个人认为聚合模型、更新模型后续的应用场景会比较有限，明细模型和主键模型应该是后续的主流，明细模型应用于更新比较少的批量的大数据离线场景，主键模型应用于更新频繁流式的大数据实时场景，离线和实时都得到比较好的支撑。