重建 OLAP 体系

重建 OLAP 体系，重视数据加工的时效性，正是近年来大数据技术的主要发展方向。Kappa 架构就是新体系的代表：

在 Kappa 架构中，原来的批量文件传输方式完全被 Kafka 替代，通过流计算系统完成数据的快速加工，数据最终落地到 Serving DB 中提供查询服务。这里的 Serving DB 泛指各种类型的存储，可以是 HBase、Redis 或者 MySQL。

要注意的是，Kappa 架构还没有完全实现，因为在实践中流计算仍然无法替代批量计算，Serving DB 也无法满足各种类型的分析查询需求。

未来，Kappa 架构需要在两方面继续完善：流计算能力的增强，这需要用到 Kafka 和 Flink 等软件；Serving DB 即时计算能力的增强，这就寄希望于 OLAP 数据库的突破，就像 ClickHouse 已经做的那样。

总的来说，新的 OLAP 体系试图提升即时运算能力，去除批量 ETL，降低数据延迟。这个新体系是流计算的机遇，也是 OLAP 数据库的自我救赎。

新建 HTAP 系统

Gartner 用 HTAP 来描述一种新型数据库，它打破了 OLTP 和 OLAP 之间的隔阂，在一个数据库系统中同时支持事务型数据库场景和分析型数据库场景。

OLAP 是海量数据要追求高吞吐量，而 OLTP 是少量数据更重视低延迟，所以它们计算引擎的侧重点不同。

业界有两个不同的解决思路：

Spanner 使用的融合性存储 PAX（Partition Attributes Across），试图同时兼容两类场景。
TiDB4.0 版本中的设计，在原有行式存储的基础上，新增列式存储，并通过创新性的设计，保证两者的一致性。

Spanner：存储合一

NSM （行式存储）

NSM（N-ary Storage Model）就是行式存储，也是 OLTP 数据库默认的存储方式。顾名思义，行式存储的特点是将一条数据记录集中存在一起，这种方式更加贴近于关系模型。

OLAP 系统，用户一次查询通常只访问其中的少量字段，查询出的多数字段其实是无用的，也就是说大量 I/O 操作都是无效的，大量无效数据的读取，又会造成 CPU 缓存的失效，进一步降低了系统的性能。

DSM（列式存储）

列式存储就是将所有列集中存储，不仅更加适应 OLAP 的访问特点，对 CACHE 也更友好。

列式存储的问题是写入开销更大，这是因为根据关系模型，在逻辑上数据的组织单元仍然是行，改为列式存储后，同样的数据量会被写入到更多的数据页（page）中，而数据页直接对应着物理扇区，那么磁盘 I/O 的开销自然增大了。

列式存储的第二个问题，就是很难将不同列高效地关联起来。毕竟在多数应用场景中，不只是使用单列或单表数据，数据分散后，关联的成本会更高。

PAX

数据：

存储：

PAX 增加了 minipage 这个概念，是原有的数据页下的二级单位，这样一行数据记录在数据页上的基本分布不会被破坏，而相同列的数据又被集中地存储在一起。PAX 本质上还是更接近于行式存储，但它也在努力平衡记录内局部性和记录间局部性，提升了 OLAP 的性能。

miniPage里面是按列存储，整体看miniPage是按行存储。

TiFlash：存储分离

TiDB 展现了一种不同的思路，介于 PAX 和传统 OLAP 体系之间，那就是 OLTP 和 OLAP 采用不同的存储方式，物理上是分离的，然后通过创新性的复制策略，保证两者的数据一致性。

通过Raft协议进行节点间数据同步，实现数据一致性。在原有Leader、Foller上增加一个Learner。通过增加Leaner实现异步复制。

Learner 每次接到请求后，首先要确认本地的数据是否足够新，而后才会执行查询操作。

怎么确认足够新呢？ Learner 会拿着读事务的时间戳向 Leader 发起一次请求，获得 Leader 最新的 Commit Index，就是已提交日志的顺序编号。然后，就等待本地日志继续 Apply，直到本地的日志编号等于 Commit Index 后，数据就足够新了。而在本地 Region 副本完成同步前，请求会一直等待直到超时。

TiFlash 的存储引擎 Delta Tree，它参考了 B+ Tree 和 LSM-Tree 的设计，分为 Delta Layer 和 Stable Layer 两层，其中 Delta Layer 保证了写入具有较高的性能。

此文章为6月Day18学习笔记，内容来源于极客时间《分布式数据库30讲》

HTAP是不是赢者通吃的游戏