由 dawei 数据实时入仓所面临的挑战：高性能、可更新、大规模
大数据场景下，实时数据如何写入实时数仓永远是一个比较大的话题，根据业务场景需求，常见的写入类型有：
Append only：传统日志类数据（日志、埋点等）中，记录（Record）和记录之间没有关联性，因此新来的记录只需要append到系统中就好了。这是传统大数据系统最擅长的一种类型。
Insert or Replace：根据设置的主键（Primary Key, PK）进行检查，如果系统中不存在此PK，就把这行记录append进系统; 如果存在，就把系统中旧的记录用新的记录整行覆盖。典型的使用场景有：
上游数据库通过Binlog实时同步，这种写入就是Insert or Replace。
Flink的结果实时写出。Flink持续刷新结果，需要Insert or Replace的写目标表。
Lambda架构下的离线回刷。Lambda架构下离线链路T+1回刷实时结果表中昨天的记录。
而要保持非常高效的写入性能，实时数仓技术都面临着非常大的挑战，典型的挑战有以下几个方面：
挑战一：Merge on Read还是Merge on Write?
Upsert模式下，新旧数据的合并发生在什么时候，如果希望查询性能好，那么肯定希望合并发生在写入时（Merge on Write）。这样，在系统中任何时刻任一主键都只有一条记录；而如果希望写入性能好，那么就是写入不做合并，查询时再做合并（Merge on Read）。这对于查询是非常不友好的，极大限制查询性能。
挑战二：是否支持主键（Primary Key）模型？
实时数仓在数据模型上是不是支持主键对于Upsert的实时写入是至关重要的。如果没有主键，在写入侧数据的更新就很容易退化成全表更新，性能非常差，在查询侧，Merge On Read也无从做起。
挑战三：如何支持超大的数据量和超高的RPS实时写入（每秒记录数，Record Per Second）？
如果数据量小，写入RPS要求低，一个传统的数据库就能很好的解决这个问题。但是在大数据场景下，当RPS达到几十万几百万时，如何更好支持数据的实时写入？同时，如果目标表中已经有海量数量（十亿、百亿甚至更多）时，Upsert要求访问和订正已有数据，这时是否还能支持高性能的Upsert?