关于 HTAP 数据库应用场景的一些想法

随便写写下午与好朋友讨论的思路。

昨天发了一篇文章讨论的是关系型数据库的变化数据如何同步到数据仓库层面，类似于 MySQL 的 binlog 日志同步到数据仓库进行 OLAP 分析。OLTP环境下的数据库数据同步到OLAP环境下的数据仓库，解决方案逃不过三种类型:

1. 使用 select 语句全量定时同步到数据仓库；
2. 基于 binlog 日志，一条一条的在数据仓库复现操作；
3. 基于 binlog 日志，使用SQL实现 Merge 的方式同步到数据仓库。

昨天的文章选择了第三种，主要原因是因为基于 Hadoop 生态圈下的，可以在百亿乃至千亿级别数据量级，且QPS和TPS达到几十万上百万条每秒的场景下，很难会有一个数据库产品能实现上述解决方案2，这里的数据库原先使用的是 Kudu，显然没有达到预想的效果。

PS：Kudu 并没有官方宣传文稿说的那么优秀，在百万级和千万级的数据量级下会有很好的表现，但是数据量再多性能就急剧下降了。

所以目前我们这一部分的架构如下图：

Oracle 数据库或者是 MySQL 数据库的变化数据会通过 OGG 的方式传输到 Kafka 上，Kafka 的数据会按照一定的规范解析成二维表形式，然后执行一系列 SQL，最终实现 Oracle 或者是 MySQL 数据库在 HDFS 上的数据仓库的复现。

这种架构的最大的缺点就是放弃了实时性，而且引入了额外的复杂性，需要维护这么多套产品。如果需要实时分析的话，就要基于 Kafka 数据引入 Spark Streaming 和 Flink 等产品。

那么有没有改进的措施呢？下午和朋友讨论后，提出可以使用 HTAP 数据库尝试下，如果有钱的话，数据仓库可以使用 Greenplum 数据库（当然这个就不考虑了）。

如果使用 HTAP 数据库的话，那架构图就可以变成下面那样：

虽然组件没有减少，但是业务可以基于 HTAP 进行实时分析了，不像之前那样为了实时分析引入额外的复杂性，比如要写 Spark Streaming 和 Flink 代码，只需要写 SQL 就行。

考虑到 HTAP 数据库和 HDFS 存储和计算成本，还是需要把 HTAP 数据库同步到 HDFS 上进行存储，并且进行复杂的关联分析。

最完美的还是希望能有一个数据库可以无损的实现 HDFS 和数据库本身的联合查询。

那么问题来了，又有哪一款 HTAP 数据库可以存储千亿级别的数据量，并且可以支持 QPS 和 TPS 几十万上百万条每秒呢？我觉得还需要进行调研和进一步测试。

最后补充两点：

1. 为什么数据库数据同步到数据仓库会有 QPS 呢？因为我们的数据库同步不仅仅只有基于主键的值更新、插入和删除，还有对主键的更新操作。在进行主键更新操作时，就需要先基于旧主键执行 select 语句查出这一行数据，然后在内存里对主键进行更新，再删除数据库里的旧主键的数据，最后插入新主键的数据。
2. 为什么不直接使用 HTAP 数据库替代 Oracle 和 MySQL 数据库呢？这里就牵扯到企业内部的业务复杂性了，也基于生产环境和分析环境的资源绝对隔离情况等原因，导致依然需要类似于 Kafka 之类的消息中间件传递数据库变化数据。