上周六，在 130 期 Infra Meetup 直播间，我司联合创始人兼 CTO 黄东旭为大家解读了 VLDB 2020 HTAP Session 的三篇精彩论文。以下是文字回顾，enjoy~
Infra Meetup No.130
《当我们在谈论 HTAP 时我们在谈论什么》
黄东旭 | 联合创始人兼 CTO
论文简介
🔺《F1 Lightning: HTAP as a Service》
本篇论文介绍了 Google 针对内部的 OLTP 数据库 （F1，spanner 等），增加 了 HTAP 服务。它实现了一个分布式系统 Lighting，架构图如下图：Changepump 来捕获 OLTP 数据库的事务 log，然后将按照事务聚集的 log 通过 Change subscriber 分发到每个 table partition，接着每个 partition 将相关的 log 排序后 apply 到本 partition，具体是内存和地盘中的 deltas，最后 AP 客户端通过 log-structured merge reader 读取到数据。这个架构本质上是一个分布式的 CDC，它捕获分布式的事务日志，然后又 shuffle 到每个 partition。
它定义了一个新的 read semantics：safe timestamps，在此 timestamps 之前所有的 log 都 apply 到 Lighting，类似于一种近实时的 snapshot read，因为它比 OLTP 那边提供的 snapshot isolation 稍微滞后一点。通过他们线上数据来看，这个 gap 在 3-5 min 左右。
具体的 apply 过程是把 memory 中 按 B-tree 组织的 log deltas （行存格式）存成 PAX 格式到磁盘。
Lighting 的问题：
1. 分布式 CDC 过程比较复杂，是代价最高的部分，导致时间延迟高，并且容易出错；
2. CDC 后 apply 到 Lighting 中的数据理论上是要跟 OLTP 库中的数据保持一致（table ，index和 view），但是这个并没有实质性/理论上的保证；
3. TP 和 AP 通过不同的 client 访问，没有统一，对用户不透明。
🔺《Replication at the Speed of Change – a Fast, Scalable Replication Solution for Near Real-Time HTAP Processing》
本篇论文阐述了 IBM 如何把通用 CDC 做成专用的事务 log 同步，从而提高速度。论文看起来是针对一个 TP 大机到一个 AP 大机，所以本质上是一个单机对单机事务 log 的 redo（没有涉及分布式需要考虑的问题，比如 log 分发）。它把 TP 库中并发事务的日志读到 AP 机器上进行 apply。
AP 查询保证读到进入系统是 log position 所对应的数据，时间延迟在 6s 左右。Apply 过程是将每个 table [partition] 上的一小撮 delta 构造成 delete/insert 语句应用 table。客户端是统一的。
问题：
1. 针对单机 TP 定制的事务 log redo，没看到 scale 等优化；
2. 如何保证异地 redo log 保持跟主库的一致性？
🔺《TiDB: A Raft-based HTAP Database》
AP 读具有强快照隔离性，获取最新数据的延迟一般在 1s 以内。
Apply 是将日志 deltas apply 到每个 partition 的 delta tree 中，提供高的读写性能。
问题：
SQL engine 目前没有 MPP，需要 TiSpark 来补充（WIP）。
论文对比
论文 [3] 跟前面两篇最大的不同在于 storage 层进行 Raft log 复制，而非 [1,2] 中的事务日志复制。这种方法的优势有以下几点：
1. 基于复制状态机，天然地保证数据一致性和正确性，这点是复制事务日志回放机制最欠缺的。
2. Raft log 直接复制 TP 事务执行完成的结果，不像事务日志那样还得在异地 redo，流程相对简单可控。
3. Raft log 复制并回放的耗时少，同步数据更快，那么 AP 端能够获得更新鲜的数据。
4. Raft log 得益于复制状态机的容错机制，有效处理异常情况。
总结
从行存的事务型主库中复制出一个列存副本库是当下 HTAP 一种普遍的选择。具体复制事务日志，还是事务层下面的存储层的日志是两种不同的选择。复制事务日志回放已经在 2017 年 VLDB 中 HANA ATR 中提出，而这个思想在 F1 和 DB2 进一步实现。而利用共识算法的复制状态机机制扩展一个列存副本是 TiDB 首次提出并实现，具有更高的创新性。从技术上来说，回放数据变动的日志比事务产生的日志更加先进，因为后者中的事务在主库和从库数据上都 apply 一次，而前者直接是同步主库事务 apply 之后的结果。从产品效果来说，回放数据变动的日志比事务产生的日志具有更高的数据一致性以及新鲜度。
