10亿+/秒！看阿里如何搞定实时数仓高吞吐实时写入与更新

导读：Hologres（原交互式分析）是阿里云自研的一站式实时数仓，这个云原生系统融合了实时服务和分析大数据的场景，全面兼容PostgreSQL协议并与大数据生态无缝打通，能用同一套数据架构同时支持实时写入实时查询以及实时离线联邦分析。它的出现简化了业务的架构，为业务提供实时决策的能力，让大数据发挥出更大的商业价值。在本文中，我们将会介绍数据实时入仓所面临的挑战，以及Hologres为了应对这些挑战在技术原理上的创新和演进，支撑实时数仓的高吞吐实时写入与更新，加速业务数据探索。

数据实时入仓所面临的挑战：高性能、可更新、大规模

大数据场景下，实时数据如何写入实时数仓永远是一个比较大的话题，根据业务场景需求，常见的写入类型有：

1、Append only：传统日志类数据（日志、埋点等）中，记录（Record）和记录之间没有关联性，因此新来的记录只需要append到系统中就好了。这是传统大数据系统最擅长的一种类型。

2、Insert or Replace：根据设置的主键（Primary Key, PK）进行检查，如果系统中不存在此PK，就把这行记录append进系统; 如果存在，就把系统中旧的记录用新的记录整行覆盖。典型的使用场景有：

a.上游数据库通过Binlog实时同步，这种写入就是Insert or Replace。

b.Flink的结果实时写出。Flink持续刷新结果，需要Insert or Replace的写目标表。

c.Lambda架构下的离线回刷。Lambda架构下离线链路T+1回刷实时结果表中昨天的记录。

3、Insert or Update：通常使用在多个应用更新同一行数据的不同字段，实现多个数据源的JOIN。如果这行记录存在，各个应用直接根据PK去update各自的字段；但如果这行记录不存在，那么第一个要写入这行记录的应用就需要INSERT这行记录。典型的使用场景：

a.画像类应用。这类应用在实时风控、实时广告投放等非常常见。上游多个Flink Job实时计算画像的不同维度，并实时写入到同一行记录的不同字段中。

b.实时离线数据整合。在需要同时用到实时和离线计算的场合，把同一个PK的实时和离线结果放在同一行记录的不同字段中，就可以方便的同时取到实时和离线的计算结果。

下文中，我们把Insert or Replace和Insert or Update统称为Upsert。

而要保持非常高效的写入性能，实时数仓技术都面临着非常大的挑战，典型的挑战有以下几个方面：

挑战一：Merge on Read还是Merge on Write?

Upsert模式下，新旧数据的合并发生在什么时候，如果希望查询性能好，那么肯定希望合并发生在写入时（Merge on Write）。这样，在系统中任何时刻任一主键都只有一条记录；而如果希望写入性能好，那么就是写入不做合并，查询时再做合并（Merge on Read）。这对于查询是非常不友好的，极大限制查询性能。

Merge on Read原理示例：

Merge on Write原理示例：

挑战二：是否支持主键（Primary Key）模型？

实时数仓在数据模型上是不是支持主键对于Upsert的实时写入是至关重要的。如果没有主键，在写入侧数据的更新就很容易退化成全表更新，性能非常差，在查询侧，Merge On Read也无从做起。

挑战三：是否保证写入的Exactly Once？

如果上游因为failover等因素导致写入重复执行，能不能保证系统中只有一条记录（