过去一个月里，堪称国产数据库又一高光时刻。
这边厢PingCAP刚刚发布面向企业级核心场景、具备完整 HTAP 能力的分布式数据库TiDB 5.0 版本；那边厢OceanBase也紧跟着推出3.0版本，主攻方向亦是HTAP分布式数据库，在GitHub Oceanbase标注自己为“ The leading Scalable HTAP Database” , 并且又玩了一把TPC-H打榜第一的套路（后续：其成绩很快被超过）。
可能有人会质疑TPC-C和TPC-H的测试价值，毕竟这是两个历史悠久的测试标准，参考价值成疑。OceanBase如果能在TPC-DS上取得好成绩会更有说服力。不过OceanBase自带阿里&蚂蚁光环，属于招黑体质，一举一动都容易引来争议，但敢于在国际舞台亮剑，何尝不是国产数据库的荣耀，所以也无须过于苛刻。
闲言少叙，PingCAP和OceanBase把HTAP这个词彻底带火了。5月28日宣布开源计划的阿里云PolarDB也谈及HTAP，连Oracle上周都发了一篇HTAP的文章。PingCAP近年来一直都是HTAP信徒，大力宣传无可厚非；而OceanBase从传统意义上讲，大家普遍认为它聚焦在OLTP数据库领域，为何这次也大张旗鼓的喊出HTAP口号？
个中玄机，还得从HTAP的历史说起。
HTAP（Hybrid Transaction and Analytical Processing，混合事务和分析处理）就是能够将在线事务处理(On-Line Transactional Processing，简称OLTP) 和在线数据分析 (On-Line Analytical Processing，简称OLAP) 请求在同一个数据库系统中完成。
正所谓天下大势，分久必合合久必分。此话放在数据库领域一样适用。HTAP的确不是一个很新的概念，纵观数据库五十余年的发展历程，OLTP和OLAP两种需求在其中经历了漫长的融合-分离-再融合的过程。
2005年，Gartner正式提出了HTAP这一概念，并且迅速引起了一些企业的关注，被视为是未来数据发展的重要趋势之一。转眼到了2014年，Gartner又对HTAP数据库给出了明确的定义：即需要同时支持OLTP和OLAP场景，基于创新的计算存储框架，在同一份数据上保证事务的同时支持实时分析，省去费时的ETL过程。
彼时，正是大数据兴起之际，人们对于数据及其价值有着重新的认识与认知；另一方面，多核处理器、闪存等硬件技术的高速发展，也让人们逐渐意识到数据库设计是时候重新设计了，在同一数据库处理OLTP和OLAP请求的可行性大幅提升。
所以，作为国产数据库的两大代表，PingCAP和OceanBase齐刷刷瞄准HTAP，的确是摸准了时代的脉搏。但今天的HTAP已经与过去大不相同，数据资源、数据消费习惯以及数据架构的颠覆性变化，既赋予了HTAP新时代的内涵，也让HTAP承担起更重大的责任。
为什么HTAP会变得如此炎手可热？
原因始终绕不开一个“数”字。如果仔细研究Gartner关于HTAP的定义，我们会发现“同时支持OLTP和OLAP、创新计算存储框架、去掉ETL”这几大关键词都跟“数据”密切相关，其背后是数据资源、数据消费习惯以及数据架构颠覆性的改变。
首先，数据产生方式、规模、速度与过去大不同。以行为和机器产生的非结构化/半结构化数据正在成为数据增长的主力军，这些数据无论是数据规模、密集度、产生速度都远超交易型的结构化数据；这也直接驱动着HTAP场景在未来会更加丰富化。
其次，实时性的数据消费正在成为新常态，数据消费的人群规模、场景丰富程度迅速增加，无论是最终消费者，还是企业员工都有数据消费需求，驱动着OLTP场景与OLAP场景互相渗透，彼此之间的界限变得模糊。
例如，一个快消品的调研员，会通过手持终端设备随时随地了解产品销售情况和预测销售趋势，进而根据数据做出相应决策；一个基金经理往往需要随时根据客户资产净值、交易频次变化、金融产品销售情况等一系列数据服务，来有针对性进行营销决策……而这些决定常常需要几分钟甚至几秒钟内完成，实时性需求成为新一代HTAP的刚需。
过去，OLTP场景仅仅负责产生数据，数据往往需要搬运到数据仓库或者机器学习平台进行数据消费，数据消费人群也仅仅是数据仓库管理员、决策层等少数人群；现在，在数据驱动型场景大幅增加的加持下，人人都是随时随地的数据消费者，极大推动OLTP场景与OLAP场景的融合。
第三，数据驱动型场景的井喷式出现，让计算与数据两个角色出现变化，过去一直都是以计算为核心，而数据驱动型场景则是以数据为核心，核心角色的转变意味着数据架构将发生彻底改变。
所以这就涉及到一个核心问题：即在OLTP场景和OLAP场景加速融合的趋势下，在架构层到底是Move Data还是Move Code。过去，OLTP场景产生数据之后，往往需要通过ETL将数据导入到数据仓库，然后在数据仓库中建模、ODS、建立报表，如果涉及到需要应用到机器学习，还需要将数据导入到机器学习平台，数据移动次数已经足够频繁。现在，OLTP场景和OLAP场景加速融合，BI呈现和AI操作服务实时化，数据互相移动将更加频繁，这无疑对于数据架构带来极大挑战。
关于数据移动，AWS有一个经典的描述：AWS认为随着数据量的不断增加，数据的往来移动操作变得越来越困难，称之为“数据重力”现象。要想解决“数据重力”现象，AWS的做法类似Move Data，针对每个场景有专用数据库，并且集成Athena、Glue等工具集，让ETL等移动操作更加集成化、自动化和高效化。这种模式比较适合大型互联网企业，拥有比较强大的技术团队。
另一种则是Move Code，通过HTAP这种融合的数据平台，在一份数据上同时支撑业务系统运行并实现OLAP 场景，缩短数据移动路径，让数据不再搬家，就地实现OLTP场景和OLAP场景的融合。这个更符合大多数企业，尤其是企业数字化转型的需求。
本质上，HTAP的做法更具变革性，打破了OLTP场景和OLAP场景之间过去传统的分界线，大幅提升大数据体系下数据实时处理和分析计算能力；另一方面，通过分布式架构，也彻底解决了过去困扰传统数据库、数据仓库多年的性能、扩展性，实时性等难题。
但HTAP虽好，但实现起来却没有那么简单。这里不能不提PingCAP，其在HTAP上的战略布局显然更快人一步，随着TiDB 5.0的发布，也标志着国产数据库厂商在HTAP领域占领先机。
事实上，不光是PingCAP和OceanBase在搞HTAP，Oracle、GreenPlum这些传统数据库时代的大咖也在聚焦HTAP。
都是HTAP，哪些才是真正代表着HTAP的趋势呢？
其一，产品架构上需要对未来做好准备，HTAP本质上已经开始逐渐演变成一体化数据服务平台，其多元化场景决定了绝非是OLTP和OLAP简单叠加，如果通过OLTP架构外扩实现OLAP，显然只能算权宜之计，不能代表面向未来的架构。用户在分布式数据库和大数据技术的融合也产生了广泛意义的HTAP的需求，长远来看，HTAP会成为数字化时代一种普遍性的需求。
以PingCAP为例，其TiDB 4.0就是一款为HTAP而设计的分布式数据库，到了5.0版本，在TiFlash引入MPP模式与多项企业级特性的增加，使得TiDB 5.0发展为“一栈式数据服务平台”。
其二，开源生态决定基础，数据库作为重要的基础软件，HTAP数据库未来需要在成百上千的场景中打磨，过去那种封闭模式不管是技术迭代还是用户增长都是举步维艰，走向开放开源的生态之路已经是大势所趋。比如，TiDB5.0发布会“TiDB+FIink”的混合架构突破了狭义HTAP的范围，开启了“分布式数据+大数据技术栈”的HTAP生态模式。
未来，将开源战略作为核心战略、构建高度活跃的开源社区将会是HTAP数据库的长远目标。
其三，拥抱云是未来，需要支持云原生架构，充分利用云原生技术轻量化、松耦合、灵活度高等优势，另外还实现跨云与多云部署。
同样，TiDB 5.0在这方面也做出了榜样，基于云原生架构的TiDB 5.0能够充分发挥云资源的能力，PingCAP在海外市场推出了TiDB Cloud服务，坚定拥抱云路线。国内也有很多客户在云原生架构中采用TiDB构建云原生技术栈。
既然HTAP如此火热，那么它会取代以Oracle为代表的关系型数据库或者传统数据仓库么？
在笔者看来，HTAP虽然不是一个很新的概念，却是一个新的蓝海市场，它代表着数据驱动型场景井喷之后，用户在数据处理、消费整个需求的迭代升级，HTAP的兴起意味着一个新的数据库蓝海市场正在逐步形成。
因此，单纯的谈论HTAP点对点的取代关系型数据库或者传统数据仓库其实并无太大意义，HTAP也不应该成为国产化替代的一个“借口”，它更像一条新的数据库赛道，给予了像PingCAP、OceanBase这些后起之秀更多市场机会，让它们看到了抓住新需求的机遇，以及打破数据库市场垄断局面的希望。
从更大的范围来看，新一代HTAP，正在成为分布式数据库与大数据栈融合的明珠，我们甚至可以预见，未来的HTAP不再是数据库的一个技术术语，而是成为一种以融合简化方式构建数据栈的一种方式。
总体来看，HTAP现在很火，市场既有像PingCAP这样具有前瞻性的新锐数据库创新企业，也有OceanBase这种自带光环的明星数据库公司，还有Oracle这样的大鳄，未来竞争必然会愈发激烈。对于中国数据库厂商而言，路很长、未来很远，砥砺前行，且行且珍惜。
