作者：何朝洋

原文来源： https://tidb.net/blog/da6fe78a

TiDB是一种典型的HTAP数据库，即交易分析混合负载型DB，目前已经成为一种流行的新型数据库代表，具有隔离性、实时性、一致性“三性合一”的优秀特性，同时随着版本的迭代，AP的能力在逐渐增强。HTAP不仅概念很火，并且也在逐渐成为除OLTP、OLAP之外，越来越多数据库用户新的选型规范。然而，现阶段，又存在一些现象：一是一夜之间，所有的数据库都变成了HTAP数据库；二是除了“能同时承载交易与分析SQL”这一极易模糊的理解之外，基本没有清晰明确的界定；自然而然，对HTAP的应用场景，也是八仙过海，各式各样，并不清晰的。这些，都导致HTAP有成为一种噱头的趋势。

1. HTAP的界定

这里认为，HTAP既然要成为一种新的标准与规范，就必须有尽量明确界定。而达此目的的最基本原则，就是它在技术上 必须有不同于过去经典数据库的能力（不应该只是分布式），并且必须对客户的数字化进程带来创新与升级，这同时包括业务架构、应用架构、数据架构与技术架构等层面 。面向这一原则，其定义与界定可以持续探讨，而本文仅提出如下几点以供参考：

（1）HTAP在技术架构与设计目标上不应该等同于经典Oracle与MySQL，或分布式后的类Oracle与MySQL，因为如果经典Oracle与MySQL也算是HTAP的话（用“能同时承载交易与分析SQL”来衡量，那肯定是），HTAP的定义，就毫无意义；

（2）HTAP数据库的交易与分析任务的执行，应该能做到用户透明使用且有互不影响的基础，而不应该是AP多了大幅影响TP，TP多了大幅影响AP，经典Oracle与MySQL正是如此；

（3）HTAP不应该面向数仓类纯OLAP的需求。也就是说，其对企业数据架构的提升，现阶段不应该以摒弃数据仓库体系为目标；

（4）现在的HTAP数据库，应该是分布式数据库。

如果用以上标准来界定的话，就可以很明确的判定：除TiDB之外，很多其它号称HTAP的数据库，其实并不是真正的HTAP。

2. TiDB HTAP应用场景

前面说过，TiDB这种真正的HTAP特性给客户带来的，应该是业务与架构的创新与提升，而不仅仅是替换或者性能的提高。由此出发，本文认为TiDB HTAP的应用场景主要集中如下两个方面：

（1）分析能力内嵌的业务系统（Analytic-Embeded OLTP）

有了HTAP的能力，未来的交易型业务系统，都应该在业务交易侧，就天生拥有分析的能力，并且不影响交易的性能与数据的一致性。如风控、营销或者其它原来需要在后台数据平台端通过数据迁移与同步才能完成的能力，相当一部分，可以迁移到业务系统侧实时完成，成为业务系统内在的功能，使其本身就能完成一定程度的业务闭环，这必然是技术驱动现代业务发展的重要方向。

未来的业务系统应该以此标准来设计，这对现代交易系统的业务能力改造与升级有很大的意义。

（2） 以“用”为核的数据服务超市（Data SuperStore）

大多数的数据仓库（Data Warehouse）体系，都是为“管”而生的，应用很难享受到数据的红利。绝大多数的企业，在花大量精力建立了数据仓库（Data Warehouse）体系后，业务系统与人员大多只能通过“请求技术人员协助完成”及“把数据导到业务系统来”两种方式来使用数据，这种应用与数据分隔的现象是大多数企业过去很长一段时间及至今都极为关注的痛点。

面向数据消费，在现有数据平台之上，建立以“用”为核，以“管”为基的数据服务平台，即数据中台这一概念的正确解释，已经成为很多企业规划与实施的重点创新与升级应用之一。它不同于Data WareHouse是为了存与管，而是为了让全企业的用户能将数据（准确讲是面向业务整理后的数据资产，因不是本文重点，这里不作赘述）当作超市的商品一样自由选择与消费，从而让全企业享受到数据的红利，因此，这里认为称之为数据服务超市（Data SuperStore）更为恰当。然而，抛开数据资产体系建立等架构与模型层面的内容不说，应该用什么样的数据库来承载这个SuperStore呢？

面向数据消费的 SuperStore，即要承载来自全企业的大量、高并发的服务型查询需求（QPS的TP型），也要承载大量探索型的统计分析需求（AP型），这种要求显然不是纯OLAP数据库，也不是纯OLTP数据库能满足的，显然又必须是弹性分布式的。因此，过去相当多的数据服务平台，都是采用多种类型数据库，组合满足不同需求来设计的。那么，以TiDB为典型代表的HTAP数据库，就应该是该场景的最佳选择。