OLTP、OLAP与HTAP、HSAP详解

HTAP、HSAP是OLAP与OLTP综合需求驱动下的新的数据库系统，既满足事务处理，又满足大规模分析查询，并且是基于一套系统下实现。

本节首先我们要了解服务于分析的区别。相当多从应用角度对数据处理分类的划分，大致可以分为Transaction交易于Analysis分析两大类，一类位于企业数据架构的上游用于生产数据；一类位于企业数据架构的下游用于数据价值的利用。

概念

OLTP：On-Line Transtion Processing 联机事务处理过程。也成为面向交易的处理过程，其基本特征是前台接收用户数据可以立即传送到计算中心进行处理，并在很短的时间内给出处理结果，是对用户操作快速响应的方式之一。OLTP可以理解为日常的业务系统，像ERP、OA、CRM这些系统，这些业务系统主要是管理企业的基本业务流程，对数据的处理方式主要是以增、删、改为主，但是查询的SQL结构相对比较为简单。
OLAP：On-Line Analytical Processing 联机分析处理。主要关注数据分析而非实时事务处理。它允许用户对大量历史数据进行复杂的查询和分析，以揭示隐藏在数据中的模式和趋势。数据仓库是OLAP系统的核心组成部分，用户存储和管理这些历史数据。它可以让分析人员能够迅速、一致、交互的从各个方面观察信息，以达到深入理解数据的目的。它具有FASMI（Fast Analysis of Shared Multidimensional Information），即共享多维信息的快速分析的特征。
- Fast：快速性，指系统能在数秒内对用户的多数分析要求做出反应；
- Analysis：可分析性，指用户无需编程就可以定义新的专门计算，将其作为分析的一部分，并以用户所希望的方式给出报告；
- Multi-Dimensional：多维性，指提供对数据分析的多维视图和分析；
- Information：信息性，指能及时获得信息，并且管理大容量信息；
HSAP：Hybrid Serving & Analytical processing 服务分析混合负载的分布式数据系统。
- HSAP要求极高的实时数据载入吞吐量。每秒数千万、上亿甚至更高的数据载入能力，同时这些数据对服务与分析来讲必须是实时可消费（秒级、压秒级）的；
- HSAP要求极高并发、极高性能的简单查询能力。需要轻松支撑每秒数千万甚至上亿简单查询，并且延迟极低；
- HSAP要求相对高的并发、极致性能的复杂分析能力。也就是说HSAP要有传统MPP架构OLAP数据库（如GP）的同等能力；
- HSAP的上述一个特性是混合负载的，对用户来讲就是一套系统实现的。
HTAP： Hybrid Transaction & Analytical processing 。HTAP简单理解就是OLAP与OLTP业务都统一在一套数据库系统内完成。HTAP数据库相对于传统TP数据库又TP所不具备的计算引擎，可以加速SQL执行效率，而HTAP数据库基于传统AP数据库，又有AP所不具备的事务引擎，能做到所写即可见，数据具有高时效性。它打破了事务处理和分析之墙，它支持更多的信息和“实时业务”的决策。

HSAP的出现是为了满足企业对“大数据”的需求，也就是说HTAP虽然同时满足了交易类数据的分析查询需求，但对更大范围的大数据，比如来自日志等非交易系统（用户行为）的数据，则不能很好的满足。因为HTAP系统设计的基石和优势是执行hi细粒度的分布式事务，交易型数据往往以大量分布式小事务的方式写入HTAP系统。而来自日志等系统的数据，大多并没有分布式事务的需求，以HTAP系统来处理他们，显然带来了不必要的开销，从而降低了系统效能。

HSAP需求采用一套复杂的技术栈组合来完成，例如Flink+Hbase或者Hive+Druid等

OLAP与OLTP对比

	OLTP	OLAP
用户	操作人员、底层管理人员	决策人员、高级管理人员
数据结构	采用行存储方式，适用于实时事务处理	采用列存储方式，适用于数据分析
数据库	关系型数据库：Mysql、Oracle，E-R模型	数据仓库：hive 星型模型或雪花模型
性能要求	高吞吐、低延迟	当前及历史数据
数据一致性	强调数据的强一致性，通过ACID属性确保每个事务的完整执行	一致性相对要求低一些，更注重查询和分析性能
读写操作	处理大量的插入、更新和删除的操作，需要快速完成	更注重复杂的查询和分析操作，允许较长的响应时间
性能优化	通过缓存、分区和负载均衡等技术提高性能	通过索引、分区和并行处理等技术优化查询性能

OLAP与OLTP查询具体有哪些差异

OLTP查询一般仅涉及单表，点查为主，返回的是记录本身或该记录的多个列。即使是范围查询，基本上也会通过limit来限制返回的记录数。

实时性要求高。几年前的银行汇款都是隔天才到账，限制分分钟到账的节奏，说明现在银行的实时处理能力大大增加了，
数据量不是很大，生产库上的数据量一般不会太大，而且会及时做响应的数据处理与转移；
交易一般是确定的，比如银行存取款的金额肯定是确定的，所以OLTP对确定的数据进行存取
高并发，并且要求满足ACID原则，比如两个人同时操作一个银行卡账户，比如大型购买网站秒杀活动时上万的QPS。

OLAP则不同，表中单条记录本身并不是查询所关心的，比较典型的特点包括由聚合类算子、涉及多表关联。这些操作都非常消耗计算资源，而且数据仓库相比数据库在数据量上大很多，因此，OLAP类查询经常表现为cpu-bound而不是io-bound。

实时性要求不是很高，比如最常见的应用就是天级别的更新数据，然后出对应的数据报表
数据量大，因为OLAP支持的时动态查询，所以用户也许要通过将很多数据统计后才能得到想要的信息，例如时间序列分析等
OLAP系统的重点时通过数据提供决策支持，所以查询一般都是动态的，自定义的。所以在OLAP中，维度的概念非常重要，一般会将用户所有关心的维度数据，存储对应的数据平台

OLAP与OLTP是否可以统一起来

目前的趋势是将OLAP与OLTP相融合，在同一个系统中同时提供TP和AP的两种服务，即HTAP或者HSAP产品，国内的数据库创业公司PingCAP的TiDB就比较好。

但是由于两者服务类型相差较大，完全融合是很难的，如何解决AP业务对要求更高实时性和稳定性的TP业务带来的影响，如何同时提供两种服务且两种服务与业界其他系统相比具备足够竞争力，这些都是很大的挑战。

在目前的HTAP系统中，一般通过存储层的数据多副本来进行针对AP和TP业务的不同方式的优化，使用多个副本来以行存方式更好的满足TP业务，通过增加一个副本来以列存方式为AP业务提供服务。

在存储系统上，配置独立的计算/查询系统，分别满足TP和AP不同的要求。比如TP系统很重要的一点就是事务的ACID，而AP系统更加关心分布式并行查询的能力。

OLAP数据立方体及其常见操作

钻取（Drill-down）：是往更细粒度深挖。从上一层到下一层，即深入该层内部，比如数据中可以分为计算机、数理化、文史地理等。
上卷（Roll-up）：与钻取往深度挖相反，即从细粒度数据向上层聚合，如江苏省、上海市和浙江省的销售数据进行汇总查看江浙沪地区的销售数据。上面的钻取和上卷通常是改变维度的粒度。
切片（Slice）：选择维中特定的值进行分析，比如只选择电子产品的销售数据，或者浙江一个省粒度进行分析；
切块（Dice）：选择维度中给特定区间的数据或者某批特定值进行分析，比如选择2010年第一季度到2010年第二季度的销售数据。与切片不同的是，切块的粒度更大，会选择一个维度中某个区间或者范围的值，而不是仅仅是某个值。
旋转（Pivot）：维度的位置呼唤，就像是二维表的行列转换。旋转并为较少或增加要分析的样本。而是根据不同的目的，改变了分析的角度。

OLAP与OLTP总结

OLTP即联机事务处理，就是我们经常说的关系数据库，增删改查就是我们经常应用的东西，这是数据库的基础；

OLAP即联机分析处理，是数仓的核心部分，所谓的数据仓库就是对于大量已经由OLTP形成的数据的一种分析型的数据库，用于处理商业智能、决策支持等重要的决策信息；数据仓库是在数据库应用到一定程序之后而对历史数据的加工和分析，读取更多，更新较少。

HTAP

HTAP数据库简单理解就是OLAP与OLTP业务都统一的在一套数据库系统里完成。HTAP数据库相对于传统TP数据库有TP所不具备的计算引擎，可以加快SQL的执行效率，而HTAP数据库基于传统AP数据库，又有AP所不具备的事务引擎，能做到所写即可见，数据具有高时效性。

HTAP型数据库具备的技术点：

TP/AP型数据时效性：简单说，就是业务的TP查询和AP查询看到总是“同一份数据”，不会有明显的延迟。目前比较成熟的Mysql主备同步机制能保证数据延迟达到毫秒级或压秒级，用户几乎不会察觉，并且同步准确性非常高，这笔依赖于异步的外部数据同步系统的可靠性要高得多；
TP/AP稳定性与高可用：TP与AP两者互相隔离，保证各自的稳定可靠是HTAP的基本要求。要做到这一点，可以基于独立部署进行物理隔离，也可以基于链路隔离以及备库字典容灾与切换方案进行隔离；
跨业务库的关联查询：跨业务库关联分析是HTAP常见场景，这要求HTAP查询引擎能基于MYSQL协议对接不同类型的Mysql存储；
复杂SQL处理能力：除了要有强大的优化器以外，MPP计算引擎和Streaming计算引擎等加速SQL执行的手段也必须要有的。

HTAP的技术架构图：引擎层和存储层

橙色一层是存储层，这层一般都是HTAP分库分表的Mysql实例（云上就是RDS实例），通常每一个物理分库都会配一主多备保证高可用。灰色的一层是引擎层，引擎层使用集群提供高可用，集群的每一个节点都是无状态的server节点。Server里包含了用于处理Mysql协议的网络模块、查询优化器以及一整套TP引擎对应的执行算子。

通常业务OLTP类的sql在Server的TP引擎内完成全部执行。但如果业务的sql是OLAP类的复杂Sql，引擎层会将SQL对应的物理查询计划发到右侧的FireWorker引擎进行计算；

Fireworks是一个基于Spark的具有DAG能力并行执行引擎，它能够进行MPP计算及Streaming计算，Fireworks内部的每一个Worker会主动连用户mysql的备库获取数据并进行计算。

链路隔离方案的架构：引擎层和存储层

在存储层默认用Mysql的一主多备来实现。像TP引擎会默认只访问主库，这样数据可以保持数据一致性。而Fireworks引擎默认只允许访问应用的备库，这样业务在存储层AP流量和TP是天然的物理隔离，保证互相不受干扰。

由于备库承载的是OLAP类的Sql，Sql通常是相当的复杂性，备库被打垮是高概率事件，所以，HTAP能在多备库之间实施自动的容灾和切换，这样就算一台备库宕机了，另一个备库也可以继续提供服务，从而高可用。

在引擎上，通常建议业务将OLTP流量用主实例承载，业务的OLAP流量用只读实例来承载，这样业务的AP和TP业务就能在引擎上也能实现物理隔离，从而保证各自的稳定性和高可用。

查询优化器架构

PreOptimizer，sql的很多rewriter操作会在这个阶段完成，产生出一份经过简单SQL改写的逻辑计划；
Optimizer，这个阶段优化器会进行很多常见算子优化（例如，Predicate Inference/Operator Pushdown Join Cluster、Join Reorder等），然后再产生出一份经过优化后的逻辑计划；
PostOptimizer，这个阶段HTAP作为分布式查询引擎所特有的阶段。这个阶段中，优化器会基于SQL的查询条件进行分库分表的Sharding计算，然后再针对特定分片重做类似上一阶段的Partition-aware的优化操作。

原则上，优化器会尽可能地算子下推到物理存储，这样可以大大减少引擎成本地执行压力以及中间数据地网络传输代价，从而提升执行效率。

对于一些诸如必须要跨多个物理分片地或跨多个逻辑库才能完成计算地算子（如跨库JOIN），他们没有办法下推物理存储，优化器会自动采用MPP地执行策略，直接将物理计划发给Fireworks引擎做MPP计算。