过去一个月里，堪称国产数据库又一高光时刻。
这边厢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：鱼和熊掌可兼得
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因数而变
为什么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领域占领先机。
都是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将是新蓝海
既然HTAP如此火热，那么它会取代以Oracle为代表的关系型数据库或者传统数据仓库么？
在笔者看来，HTAP虽然不是一个很新的概念，却是一个新的蓝海市场，它代表着数据驱动型场景井喷之后，用户在数据处理、消费整个需求的迭代升级，HTAP的兴起意味着一个新的数据库蓝海市场正在逐步形成。
因此，单纯的谈论HTAP点对点的取代关系型数据库或者传统数据仓库其实并无太大意义，HTAP也不应该成为国产化替代的一个“借口”，它更像一条新的数据库赛道，给予了像PingCAP、OceanBase这些后起之秀更多市场机会，让它们看到了抓住新需求的机遇，以及打破数据库市场垄断局面的希望。
从更大的范围来看，新一代HTAP，正在成为分布式数据库与大数据栈融合的明珠，我们甚至可以预见，未来的HTAP不再是数据库的一个技术术语，而是成为一种以融合简化方式构建数据栈的一种方式。
总体来看，HTAP现在很火，市场既有像PingCAP这样具有前瞻性的新锐数据库创新企业，也有OceanBase这种自带光环的明星数据库公司，还有Oracle这样的大鳄，未来竞争必然会愈发激烈。对于中国数据库厂商而言，路很长、未来很远，砥砺前行，且行且珍惜。
免责声明：此文内容为第三方自媒体作者发布的观察或评论性文章，所有文字和图片版权归作者所有，且仅代表作者个人观点，与 无关。文章仅供读者参考，并请自行核实相关内容。投诉邮箱：editor@fromgeek.com。
免责声明：本网站内容主要来自原创、合作伙伴供稿和第三方自媒体作者投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。任何单位或个人认为本网站中的网页或链接内容可能涉嫌侵犯其知识产权或存在不实内容时，应及时向本网站提出书面权利通知或不实情况说明，并提供身份证明、权属证明及详细侵权或不实情况证明。本网站在收到上述法律文件后，将会依法尽快联系相关文章源头核实，沟通删除相关内容或断开相关链接。
