万籁 “俱寂” 时，一家知名 IT 研究与顾问咨询机构的发声，给关系型数据库这个平静的池塘丢了颗巨石：2014 年，Gartner 正式提出了 HTAP 这个概念。
Gartner’s definition in 2014: utilizes in-memory computing technologies to enable concurrent analytical and transaction processing on the same in-memory data store.<br /><br /> Gartner’s new definition in 2018: supports weaving analytical and transaction processing techniques together as needed to accomplish the business task.
可以看到，Gartner 重点强调了使用内存技术实现 HTAP 的可行性，并表示 HTAP 将为巨大的业务创新创造机会，增量市场空间巨大。
一石卷起千层浪，陷入半沉寂的关系型数据库技术，好像迎来了春天。那个时候，商业智能（BI）已经开始广泛渗入到众多企业的营销业务体系里了，处理数据的业务分析部门对实时处理和运维最简化的需求越来越重要，HTAP 方案的提出自然迅速地引起了行业的强势关注，因为这玩意儿光是听起来就省心省力，诱惑很大。
我们正在做的 StoneDB，就是对标 Oracle MySQL HeatWave 的一款开源版实时一体化 HTAP 数据库。
HTAP 流派
上图是清华大学李国良教授团队梳理的 HTAP 数据库的发展时间线。我们这里再举几个大家耳熟能详的企业：像数据库巨头 Oracle 去年就推出了 MySQL HeatWave，没错，Oracle 官方已经明确表示了，做 HeatWave 的目的就是为了支持 HTAP，在最近的 Oracle CloudWorld 大会上还官宣了 MySQL HeatWave Lakehouse；Google 在 HTAP 上也动作频频，除了搞 F1 Lightning 以外，在今年 5 月 12 日的 Google I/O 2022 开发者大会还宣布了云原生 HTAP 数据库 AlloyDB for PostgreSQL；紧接着，所有云数仓都想打的知名厂商 SnowFlake 也在 6 月 14 日的用户大会 Snowflake Summit 2022 上官宣正式推出 HTAP 存储引擎 Unistore；数据库独角兽 SingleStore（前身为 MemSQL） 也早就在 HTAP 领域上频频发声，顶会论文都发了。国际上的这些大厂和独角兽都在搞 HTAP，国内的更不用说了，阿里、百度、腾讯、华为、字节和众多新兴创业公司（包括咱们 StoneDB），以及老牌数据库厂商都开始宣传自己的一些产品可以实现或者主攻 HTAP。Gartner 之前在报告里预测说，到 2024 年，HTAP 数据库会被广泛用到各行各业中，现在看来，真的是有这种势头了。
显而易见，HTAP 这俩马车的车轮已经压在了数据库行业的历史轨迹上，正在滚滚向前，势不可挡。但是，随着越来越多的厂商正式加入赛道，对于 HTAP 架构的技术实现，自然产生了一些分化。
我们之前在文章《深度干货！一篇 Paper 带您读懂 HTAP》中有做介绍，这篇报告里提到，至少有四种不同的架构方式可以实现 HTAP。
目前 HTAP 大致有四种实现方式：
-
方案 1（一套系统一套存储）：在一个系统里用一种数据格式满足两种业务需求；
-
方案 2（一套系统两套存储）：一个系统里同时存在行存储和列存储，行存储上的更新会定期导入到列存储里转换成列存储格式；
-
方案 3（两套系统两套存储）：系统里同时存在 OLTP 与 OLAP 两套引擎，分别写入和读取行存储和列存储；
-
方案 4（多套系统松耦合）：不同的异构系统之间，通过独立的插件服务对数据进行准实时同步，对外呈现 HTAP 能力。
