关于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能力的潜能。

你可能感兴趣的:(大数据,分布式数据库,数据库,big,data,database)