本文翻译自：HTAP is Dead，文章中的观点仅供批判参考。
这篇博客的灵感源自Jordan Tigani题为“大数据已死”的博客。Jordan和我曾在SingleStore共同构建过一款HTAP数据库。
美好旧时光（八十年代）
回溯八十年代，一个关系型数据库就能搞定一切。白天处理交易（OLTP），晚上生成报告（OLAP）。像Oracle V2和 IBM DB2这样的数据库在同一系统上运行OLTP和OLAP；这主要是因为数据集仍然能装进几块磁盘，而且计算资源极其昂贵。
那时没人称之为混合事务/分析处理（HTAP）；它就是数据库本身。
大分裂（九十年代）
随着企业数据量激增，提出的问题也愈发复杂，数据库开始显露出其局限性。
要知道，事务型和分析型工作负载的方向是背道而驰的。OLTP需要微秒级的插入和单行查找，而OLAP则要求全表扫描和大规模聚合。这导致了持续的资源争用：分析消耗了本应用于低延迟事务的I/O和缓存资源，反之亦然。
解决方案？隔离工作负载。到 2000 年代初，“大分裂”开始了。
存储架构的分化（2000年代）
这场分裂背后的一个关键技术驱动因素是存储架构。OLTP 系统为行式存储（快速写入 + 点查询）进行了优化。而 OLAP 系统则选择列式存储以实现高效的扫描和聚合。
到 2000 年代中期，这种分化已成为行业标准。数据库先驱 Michael Stonebraker 在其论文《“One Size Fits All”：An Idea Whose Time Has Come and Gone》中标志了这一转变。数据库开始分裂成专门的引擎。
OLTP 和 OLAP 双双抛弃 SQL（2000年代–2010年代）
水平扩展进一步使OLTP和OLAP分离。
早期的分布式OLTP数据库（如MongoDB等NoSQL引擎）完全放弃了SQL和分析能力。在分析领域，则采用了MapReduce和数据湖架构（Hadoop/HDFS）：牺牲了传统RDBMS的严格一致性等特性以换取海量吞吐。
意外的和解（2010年代）
在2010年代，两股截然不同的数据库运动势头渐起：
- NewSQL（Spanner, CockroachDB, Vitess）：主张OLTP应保持基于SQL。
- 云数据仓库（Redshift, Snowflake）：主张OLAP应在具有更强一致性保证的SQL系统上进行。
理论上，这些系统服务于截然不同的工作负载。但在底层，它们有很多共同点：分布式、MPP式执行引擎和SQL。孤立地看，OLTP和OLAP系统在架构原则的许多方面已经趋同。有一个巨大的不同点：存储引擎。
我们不禁自问：如果能在同一个数据库中同时结合行存储和列存储引擎会怎样？
于是，HTAP 诞生（2014）
2014 年，Gartner提出了HTAP（混合事务和分析处理）这一术语：下一代重要的数据库架构。
其目标是弥合操作型系统和分析型系统之间的鸿沟。这对于定价、欺诈检测和个性化推荐等新兴工作负载是必需的。即使在业务层面，决策者也想要“此刻”的数据。早期的HTAP系统证明这是可行的。嗯，很大程度上是可行的……
SingleStoreDB 结合了内存行存储、基于磁盘的列存储和向量化执行引擎——在一个单一系统中支持快速的扫描、查找、过滤、聚合和更新。随着时间的推移，我们发现借助现代硬件，仅列存储本身就能处理大量令人惊讶的OLTP风格查询，包括点查找和低延迟访问模式。
TiDB 则走了另一条路，将其TiKV行存储与基于ClickHouse的独立列式引擎配对——维护两份数据副本来服务两种工作负载。
所以，问题应该解决了，对吧？如同七十年代的数据天堂，唉。
云数据仓库成为唯一赢家（2020年代）
云数据仓库显然已经胜出。NewSQL运动停滞了……而HTAP呢？它从未得到应有的关注。尽管取得了真正的技术进步，它始终未能达到产品市场契合（PMF）。
- 替换XXX的OLTP系统真的、真的非常困难。看看DBEngines的排名就知道了：Oracle和SQL Server仍然稳坐第一和第三把交椅。
- 大多数工作负载不需要分布式OLTP。硬件变得更快更便宜。一台性能强劲的单机就能处理绝大多数事务型工作负载。Cursor和OpenAI背后就靠一个单机PostgreSQL实例支撑。你也完全没问题。
- 云原生架构偏爱共享磁盘（shared-disk），而非无共享（shared-nothing）。当NewSQL系统要求快速的本地存储（甚至内存持久性）时，云平台却朝着对象存储和弹性计算的方向推进。
- OLTP和OLAP由不同的团队负责。OLTP归产品工程团队所有；OLAP属于数据团队。他们的目标很少一致。没人会因为“整合技术栈”而获得晋升。
你的数据栈构成了HTAP数据库（当下）
云也开启了从紧密耦合的仓库向构建在对象存储之上的模块化数据湖的转变。
为了摆脱传统的仓库/数据库束缚，数据团队开始组装自己定制的系统。由“同类最佳”的构建模块组成：
- OLTP系统和流处理器作为WAL（预写日志）
- Iceberg等开放表格式充当存储引擎
- Spark和Trino等查询引擎负责执行
- ClickHouse或Elastic等实时系统起到索引的作用
即使在今天解耦的数据栈中，核心需求依然如故：在新鲜的事务数据上执行快速的OLAP查询。现在，这通过一个由流处理管道、云数据湖和实时查询层构成的网络来实现。
这仍然是HTAP；但通过组合（composition）而非数据库的整合（consolidation）来实现。它归结为以下问题：
- 如何将 WAL 应用到我的存储引擎？ 即：如何高效地从我的OLTP系统CDC（变更数据捕获）到数据湖？
- 能否在数据湖上构建一个成本更低的索引，并保持同步？ 即：如何将实时数据摄取到湖中？或者如何用PostgreSQL或Elastic的功能来查询湖数据？
我们这个时代的HTAP挑战，归根结底是让湖仓（lakehouse）具备实时能力。
在投入了我最宝贵的十年光阴，先是开创它、后又试图挽救它之后，作为一款数据库产品的HTAP已死。
但让它的精神永存吧。
