关于HTAP与HSAP

交易分析混合负载HTAP方兴未艾时，同时，还有一个新的概念在业界流转，即HSAP，Hybrid Serving & Analytical processing 服务分析混合负载。

1. 概念

在讨论HSAP之前，首先需要了解其概念中对服务与分析的区分。相当多从应用角度对数据处理分类的划分，大致分为Transaction交易与Analysis分析两大类，一类位于企业数据架构的上游用于生产数据，一类位于企业数据架构的下游用于数据价值的利用。而HSAP则对位于下游的数据价值利用进行了进一步的区分：简单查询与复杂的分析查询，前者涉及的数据范围小，实质上是传统TP系统擅长的点查，或者简单聚合查询，后者涉及的数据范围大，需要扫描大量数据，实质上是传统AP系统擅长的分析类查询。在HSAP的概念中，将简单点查称为“数据服务”，将”复杂查询“称为“分析”，而两者的混合负载就称为HSAP，这就是HSAP概念的解释。

2. HSAP需求分析

初看起来，HSAP的需求，HTAP也能实现：Transaction交易机制满足QPS类点查需求，Analysis分析机制满足复杂查询需求。而在标准的HTAP数据库（一般是指分布式数据库，不包括那些自称是HTAP但实际是传统单体数据库架构的产品）中，一般都存在两套技术机制，即基于行存的交易机制与基于列存的分析机制，两者采用分离且实时一致的存储引擎，或者统一且行列混布的共享存储引擎。

但为什么又会有HSAP的提法呢？其核心的原因实际上来源于：HSAP的出现是为了满足企业对“大数据”的需求。也就是说，HTAP虽然同时满足交易类数据的分析查询需求，但对更大范围的大数据，比如来自日志等非交易系统（用户行为）的数据，则不能很好的满足。因为HTAP系统设计的基石和优势是支持细粒度的分布式事务，交易型数据往往以大量分布式小事务的方式写入HTAP系统。而来自日志等系统的数据，大多并没有分布式事务的需求，以HTAP系统来处理它们，显然会带来不必要的开销，从而降低了系统效能；更重要的是，这类非交易型大数据的体量，要比交易数据大的多，甚至是好几个数据级，这就带来了HSAP系统的另一个技术要求：动辄每秒钟数千万甚至上亿条事件的极高吞吐数据实时写入，包括海量单条与低频批量。只有能够与HTAP一样，实时的承载大数据+交易数据的写入，并在秒级甚至亚秒级就能被服务与分析所消费，而不是需要一个冗长的离线ETL过程，HSAP的概念才真正有意义。

相当长一段时间以来，企业面向这种HSAP的需求都是采用一套复杂的技术栈组合来完成的，例如用Flink+HBase+Hive/Druid等等形成一个集成系统，其间不可避免的数据孤岛、数据同步、一致性等问题对开发与运维都带来了巨大的复杂性，而HSAP即是用一套系统来满足这种要求。

在如上讨论中，分布式是一个隐含的条件，因为弹性与扩展需求是不言而喻的，这里就不再赘述。

3. HSAP技术特性

至此，关于HSAP不仅是概念清楚了，即“服务分析混合负载的分布式数据系统”，而且对其技术特性与要求也清楚了：

1. HSAP要求极高的实时数据载入吞吐量。每秒数千万、上亿甚至更高的数据载入能力，同时这些数据对服务与分析来讲必须是实时可消费（秒级、亚秒级）的；
2. HSAP要求极高并发、极高性能的简单查询能力，需要轻松支撑每秒数千万甚至上亿次简单查询，并且延迟极低；
3. HSAP要求相对高并发、极致性能的复杂分析能力。也就是说，HSAP要具有传统MPP架构OLAP数据库（如GP）的同等能力；
4. HSAP的上述一个特性是混合负载的，对用户来讲是一套系统实现的。

4. HSAP与HTAP

再来看看HSAP与HTAP的区别。本质上，HSAP的出现，是因为在应对更大数量的非交易型大数据需求时，HTAP中Transaction的分布式小事务能力，其实是不需要的，但却会带来不必要的开销。从而，HSAP为了满足这一类的需求，对HTAP中的分布式小事务能力进行了妥协，从而带来了吞吐、性能的提升，这实际上是继Hadoop类大数据系统与分布式事务型数据库之后，CAP理论的又一产出。

这样看来，HSAP与HTAP都会成为企业数据架构中不可或缺的重要组成部分，而在应对有规模企业，特别是当互联网/物联网应用不断扩大时，企业分析查询对大数据有着越来越高的需求，那么这时，HSAP就有了其更加不可或缺的作用。而对HTAP数据库来讲，虽然在技术实现上并不会太简单，但从本质上讲，HTAP在对其分布式事务能力进行妥协后，应该也有同时具备HSAP能力的潜能。