HTAP 已死

本文翻译自：《HTAP is Dead》

这篇博客受到Jordan Tigani文章《Big Data is Dead》的启发。

旧时代的岁月（70年代）

上世纪70年代，一个关系型数据库可以完成所有任务。白天处理事务（OLTP），晚上生成报表（OLAP）。像Oracle V2和IBM DB2这样的数据库在同一系统上运行OLTP和OLAP，主要是因为数据集仍然可以装在几个磁盘上，而计算资源昂贵。

没有人称之为混合事务/分析处理（HTAP）；它只是数据库而已。

重大分歧（80年代）

随着企业拥有更多数据，并提出更复杂的问题，数据库开始显示出它的局限性。

事务型和分析型工作负载是朝着相反的方向发展的。OLTP需要微秒级的插入和单行查找，而OLAP则需要全表扫描和大规模的聚合。这导致了持续的争用；分析型工作负载消耗I/O和缓存，这些资源对于低延迟的事务型工作负载来说是必需的，反之亦然。

解决方案是什么？隔离这些工作负载。到20世纪80年代初，这种“巨大分歧”已经开始出现。

存储的分离（90年代）

推动这种分歧的一个关键技术因素是存储架构。OLTP系统针对基于行的存储进行了优化（快速写入 + 点查询）。而OLAP系统则选择基于列的存储，以实现高效的扫描和聚合。

到2000年代中期，这种分离已经成为行业标准。数据库先驱迈克尔·斯托纳布勒（Michael Stonebraker）在他的论文《One Size Fits All：An Idea Whose Time Has Come and Gone》中标志着这一转变，该论文发表在ACM Digital Library上（https://dl.acm.org/doi/abs/10.1145/3226595.3226636）。数据库开始分裂成专门的引擎。

OLTP 和 OLAP 都放弃了 SQL（2000–2010 年代）

横向扩展推动了 OLTP 和 OLAP 之间的距离进一步拉大。

早期的分布式 OLTP 数据库（如 MongoDB 这类 NoSQL 引擎）完全摒弃了 SQL 和分析能力。在分析领域，我们看到了 MapReduce 和数据湖架构（Hadoop/HDFS）的采用：以牺牲传统关系型数据库的严格一致性为代价，换取巨大的吞吐量。

意想不到的和解（2010 年代）

在 2010 年代，两种不同的数据库运动逐渐兴起：

1. NewSQL（Spanner、CockroachDB、Vitess）。OLTP 应该保持基于 SQL。
2. 云数据仓库（Redshift、Snowflake）。OLAP 应该运行在具有更强一致性保证的 SQL 系统上。

从表面看，这些系统服务于完全不同的工作负载。但在底层，它们有很多共同点：分布式、MPP 风格的执行，以及 SQL。孤立来看，OLTP 和 OLAP 系统已经收敛于许多相同的架构原则。唯一一个大的不同点是：存储引擎。

我们问自己：如果可以将行存储引擎和列存储引擎结合到一个数据库中，会怎样？

没错，就是 HTAP (2014)

2014年，Gartner 引入 术语 HTAP（混合事务和分析处理）：下一代数据库架构。

目标是缩小操作系统和分析系统之间的差距。这对于新兴的工作负载，如定价、欺诈检测和个人化，都是必要的。即使在企业层面，决策者也希望获得实时数据。早期的 HTAP 系统展示了这是可以实现的。不过，大部分情况是如此。

SingleStoreDB 结合了内存中的行存储、基于磁盘的列存储以及向量化执行引擎——在一个系统中支持快速扫描、查找、过滤、聚合和更新。随着时间的推移，我们发现，在现代硬件的支持下，仅列存储就可以处理大量OLTP风格的查询，包括点查找和低延迟的访问模式。

TiDB 采取了不同的路线，将其TiKV行存储与基于ClickHouse的独立列式引擎相结合——保持数据的两个副本以服务两种工作负载。

所以，这样应该就是全部了，对吧？70年代的数据乌托邦，唉，终究还是落空了。

云数据仓库是2020年代的唯一赢家

云数据仓库显然胜出。NewSQL运动停滞了……HTAP呢？它从未获得应有的关注。尽管有真正的技术进步，但它仍然处于预产品市场契合状态。

1. 替换一个人的OLTP系统真的非常困难。 请相信DBEngines的说法：Oracle和SQL Server仍然分别排在第1和第3位。

2. 大多数工作负载并不需要分布式OLTP。 硬件变得更快且更便宜了。单台性能强大的机器就可以处理大多数事务型工作负载。Cursor和OpenAI都是由单台Postgres实例驱动的。你完全没问题。

3. 云原生架构更倾向于共享磁盘，而不是共享无磁盘。 虽然NewSQL系统需要快速的本地存储（甚至需要内存持久性），但云平台则更倾向于对象存储和弹性计算。

4. OLTP和OLAP由不同的团队负责。 OLTP由产品工程团队负责；OLAP属于数据团队。激励机制很少一致。没有人因为“整合堆栈”而被晋升。

你的数据栈构成了HTAP数据库（今天）

云技术也开始推动从紧密耦合的数据仓库向基于对象存储的模块化数据湖转变。

在试图摆脱传统数据仓库/数据库的模式时，数据团队开始自行构建定制系统。这些系统由“最佳组件”构成：

1. OLTP系统和流处理器作为WAL
2. 开放表格格式如Iceberg作为存储引擎
3. 查询引擎如Spark和Trino用于执行
4. 实时系统如ClickHouse或Elastic作为索引

即使在今天解耦的数据栈中，需求依然不变：在最新的交易数据上实现快速的OLAP查询。这现在通过一系列流式管道、云数据湖和实时查询层的网络实现。

它仍然是HTAP；但通过数据库的组合而非整合来实现。这归结为诸如：

1. 如何将WAL应用到我的存储引擎上？ AKA: 如何高效地从OLTP系统将数据同步到数据湖？

2. 我能否在我的数据湖上构建一个低成本的索引，并保持同步？ AKA: 如何将实时数据摄入到湖中？或者如何使用Postgres或Elastic功能查询湖中的数据？

我们当前的HTAP挑战归根结底是让湖仓成为实时准备的系统。

在花费了我最好的10年时间，先是创立，然后是拯救之后，HTAP作为一种数据库已经死了。

但让精神继续存在。