HTAP与OLAP&OLTP、TPC-C 、TPC-H和TPC-DS
HTAP是近些年来比较火的一个概念，下面就聊聊其前世今生及技术特点。
1. 数据应用类别
1).OLTP
联机事务处理OLTP
（On-Line Transaction Processing）
OLTP是事件驱动、面向应用的，也称为面向交易的处理过程。其基本特征是前台接收的用户数据可以立即传送到计算中心进行处理，并在很短的时间内给出处理结果，是对用户操作的快速响应。例如银行类、电子商务类的交易系统就是典型的OLTP系统。其具备以下特点：
- 直接面向应用，数据在系统中产生。
- 基于交易的处理系统。
- 每次交易牵涉的数据量很小；对响应时间要求非常高。
- 用户数量非常庞大，其用户是操作人员，并发度很高。
- 数据库的各种操作主要基于索引进行。
- 以SQL作为交互载体。
- 总体数据量相对较小。
2).OLAP
联机实时分析OLAP
（On-Line Analytical Processing）
OLAP是面向数据分析的，也称为面向信息分析处理过程。它使分析人员能够迅速、一致、交互地从各个方面观察信息，以达到深入理解数据的目的。其特征是应对海量数据，支持复杂的分析操作，侧重决策支持，并且提供直观易懂的查询结果。例如数据仓库是其典型的OLAP系统。其具备以下特点：
- 本身不产生数据，其基础数据来源于生产系统中的操作数据
- 基于查询的分析系统；复杂查询经常使用多表联结、全表扫描等，牵涉的数量往往十分庞大
- 每次查询设计的数据量很大，响应时间与具体查询有很大关系
- 用户数量相对较小，其用户主要是业务人员与管理人员
- 由于业务问题不固定，数据库的各种操作不能完全基于索引进行
- 以SQL为主要载体，也支持语言类交互
- 总体数据量相对较大
3).OTHER
除了传统的OLTP、OLAP类，近些年来针对数据的使用又有些新特点，我将其归入了“其他”类。
- 多模 随着业务“互联网化”和“智能化”的发展以及架构 “微服务”和“云化”的发展，应用系统对数据的存储管理提出了新的标准和要求，数据的多样性成为突出的问题。早期数据库主要面对结构化数据的处理场景。后面随着业务的发展，逐渐产生了对非结构化数据的处理需求。包括结构化数据、半结构化(JSON、XML等)数据、文本数据、地理空间数据、图数据、音视频数据等。多模，正是指单一数据库支持多种类型数据的存储与处理。
- 流式 流式处理(实时计算)，是来源于对数据加工时效性的需求。数据的业务价值随着时间的流失而迅速降低，因此在数据发生后必须尽快对其进行计算和处理。传统基于周期类的处理方式，显然无法满足需求。随着移动互联网、物联网和传感器的发展导致大量的流式数据产生。相应地出现了专有的流式数据处理平台，如Storm、Kafka等。近些年来，很多数据库开始支持流式数据处理，例如MemSQL、PipelineDB。有些专有流式数据处理平台开始提供SQL接口，例如KSQL基于Kafka提供了流式SQL处理引擎。
- 高阶 随着对数据使用的深入，数据的使用不再仅仅以简单的增删改查或分组聚合类操作，而对于其更为高阶的使用也逐步引起大家的重视。例如使用机器学习、统计分析和模式识别等算法，对数据进行分析等。
对比 — OLAP vs OLTP
2. 数据处理模式
面对上述复杂多变的应用场景，数据应用的多种类别，是由单一平台处理，还是由不同平台来处理呢？一般来说，专有系统的性能将比通用系统性能高一到两个数量级，因而不同的业务应采用不同的系统。但正如古人说“天下大势、分久必合、合久必分”，在数据处理领域也有一种趋势，由单一平台来处理。这里选择的核心在于如何来辩证看待需求和技术。它们是一对矛盾体，当这对矛盾缓和时，数据处理领域将更趋向于整合；而当这对矛盾尖锐时，数据处理领域将趋于分散。就软硬件技术发展现状和当前需求来看，未来整合的趋势更为明显。集成数据平台将能满足绝大多数用户的场景，只有极少数企业需要使用专有系统来实现其特殊的需求。
1).分散式（专有平台）
目前比较常规的方式，是采用多个专有平台，来针对不同场景进行数据处理。因此是跨平台的，因此是有个数据传输的过程。这之中会带来两个问题：数据同步、数据冗余。数据同步的核心是数据时效性问题，过期的数据往往会丧失价值。常见的做法如下:
OLTP系统中的数据变化，通过日志的形式暴露出来；通过消息队列解耦传输；后端的ETL消费拉取，将数据同步到OLAP中。整个链条较长，对于时效性要求较高的场景是个考验。此外，数据在链条中流动，是存在多份的数据冗余保存。在常规的高可用环境下，数据会进一步保存多份。因此这里面隐藏了比较大的技术、人力成本以及数据同步成本。而且横跨如此之多的技术栈、数据库产品，每个技术栈背后又需要单独的团队支持和维护，如DBA、大数据、基础架构等。这些都蕴含着巨大的人力、技术、时间、运维成本。正是出于在满足各种业务需求的同时，提高时效性，减低数据冗余、缩短链条等，收敛技术栈就变得很重要。这也是通用类平台解决方案，诞生的出发点。
2).集中式（通用平台）
用户厌倦了为不同的数据处理采用不同的数据处理系统，更倾向于采用集成数据处理平台来处理企业的各种数据类型。对于融合了联机事务处理和联机实时分析的场景，也就是下面所谈到的HTAP。此类通用平台方案具备下面优点：
- 通过数据整合避免信息孤岛，便于共享和统一数据管理。
- 基于SQL的数据集成平台可提供良好的数据独立性，使应用能专注于业务逻辑，不用关心数据的底层操作细节。
- 集成数据平台能提供更好的实时性和更全的数据，为业务提供更快更准的分析和决策。
- 能够避免各种系统之间的胶合，企业总体技术架构简单，不需要复杂的数据导入/导出等，易于管理和维护。
- 便于人才培养和知识共享，无须为各种专有系统培养开发、运维和管理人才。
3. HTAP
HTAP数据库（Hybrid Transaction and Analytical Process，混合事务和分析处理）。2014年Gartner的一份报告中使用混合事务分析处理(HTAP)一词描述新型的应用程序框架，以打破OLTP和OLAP之间的隔阂，既可以应用于事务型数据库场景，亦可以应用于分析型数据库场景。实现实时业务决策。这种架构具有显而易见的优势：不但避免了繁琐且昂贵的ETL操作，而且可以更快地对最新数据进行分析。这种快速分析数据的能力将成为未来企业的核心竞争力之一。
1).技术要点
- 底层数据要么只有一份，要么可快速复制，并且同时满足高并发的实时更新。
- 要满足海量数据的容量问题，在存储、计算都具有很好的线性扩展能力。
- 具有很好的优化器，可满足事务类、分析类的语句需求。
- 具备标准的SQL，并支持诸如二级索引、分区、列式存储、向量化计算等技术。
2).重点技术 – 行列存储
行存储（Row-based）：对于传统的关系型数据库，比如甲骨文的OracleDB和MySQL，IBM的DB2、微软的SQL Server等，一般都是采用行存储（Row-based）行。在基于行式存储的数据库中，数据是按照行数据为基础逻辑存储单元进行存储的，一行中的数据在存储介质中以连续存储形式存在。
列式存储（Column-based）是相对于行式存储来说的，新兴的Hbase、HP Vertica、EMC Greenplum 等分布式数据库均采用列式存储。在基于列式存储的数据库中，数据是按照列为基础逻辑存储单元进行存储的，一列中的数据在存储介质中以连续存储形式存在。
传统的行式数据库，是按照行存储的，维护大量的索引和物化视图无论是在时间（处理）还是空间（存储）面成本都很高。而列式数据库恰恰相反，列式数据库的数据是按照列存储，每一列单独存放，数据即是索引。只访问查询涉及的列，大大降低了系统I/O，每一列由一个线来处理，而且由于数据类型一致，数据特征相似，极大方便压缩。
3).重点技术 – MPP
MPP (Massively Parallel Processing)，即大规模并行处理，在数据库非共享集群中，每个节点都有独立的磁盘存储系统和内存系统，业务数据根据数据库模型和应用特点划分到各个节点上，每台数据节点通过专用网络或者商业通用网络互相连接，彼此协同计算，作为整体提供数据库服务。非共享数据库集群有完全的可伸缩性、高可用、高性能、优秀的性价比、资源共享等优势。简单来说，MPP是将任务并行的分散到多个服务器和节点上，在每个节点上计算完成后，将各自部分的结果汇总在一起得到最终的结果。下面以典型的MPP产品Greenplum架构为例。
4).重点技术 – 资源隔离
OLTP、OLAP类两者对资源的使用特点不同，需要在资源层面做好隔离工作，避免相互影响。常见的通过定义资源队列的方式，指定用户分配队列，起到资源隔离的作用。
5).HTAP产品
下图是网站找到的数据库产品分类图，针对HTAP类的可参考对象线上的相关产品。当然这只是一家之言，仅供参考！
TPC-C 、TPC-H和TPC-DS区别
TPC-C:
TPC Benchmark C于1992年7月获得批准，是一个在线事务处理（OLTP）基准。 与TPC-A等以前的OLTP基准测试相比，TPC-C更复杂，因为它具有多种事务类型，更复杂的数据库和整体执行结构。 TPC-C涉及五个不同类型和复杂性的并发事务的混合，这些事务可以在线执行或排队等待延迟执行。 该数据库由九种类型的表组成，具有广泛的记录和人口规模。 TPC-C以每分钟事务数（tpmC）衡量。 虽然基准描述了批发供应商的活动，但TPC-C并不限于任何特定业务领域的活动，而是代表必须管理，销售或分销产品或服务的任何行业。
TPC-H:
TPC Benchmark™H（TPC-H）是决策支持基准。 它由一套面向业务的即时查询（ad-hoc）和并发数据修改组成。 选择查询和填充数据库的数据具有广泛的行业相关性。 该基准测试说明了决策支持系统，该系统可检查大量数据，执行高度复杂的查询并为关键业务问题提供答案。 TPC-H报告的性能指标称为TPC-H每小时综合查询性能指标（QphH @ Size），它反映了系统处理查询能力的多个方面。 这些方面包括执行查询时所选择的数据库大小，单个流提交查询时的查询处理能力以及多个并发用户提交查询时的查询吞吐量。 TPC-H价格/性能指标
http://TPC.org官方提供的有测试包。
TPC-H是一款面向商品零售业的决策支持系统测试基准，它定义了8张表，22个查询，遵循SQL92；TPC-H基准的数据库模式遵循第三范式。新兴的数据仓库开始采用新的模型，如星型模型、雪花模型。TPC-H已经不能精准反映当今数据库系统的真实性能。为此，TPC组织推出了新一代的面向决策应用的TPC-DS 基准。
TPC-DS
TPC-DS是决策支持的基本测试，提供了决策支持系统的通用见面方式，包括数据查询和数据维护。TPC-DS基准测试提供了通用决策支持系统的性能评估。基准测试的结果衡量了单用户模式下的响应时间，多用户模式下的查询吞吐量，特定操作系统和硬件的数据维护性能，在受限复杂的环境下数据处理系统、支持多用户决策。TPC-DS基准测试为用户提供相关的 客观性能数据。TPC-DS v2则支持新兴技术如大数据 进行性能测试。
http://tpc.org 官方也提供规范和测试包。
TPC-DS采用星型、雪花型等多维数据模式。它包含7张事实表，17张纬度表平均每张表含有18列。其工作负载包含99个SQL查询，覆盖SQL99和2003的核心部分以及OLAP。这个测试集包含对大数据集的统计、报表生成、联机查询、数据挖掘等复杂应用，测试用的数据和值是有倾斜的，与真实数据一致。可以说TPC-DS是与真实场景非常接近的一个测试集，也是难度较大的一个测试集。
TPC-DS的这个特点跟大数据的分析挖掘应用非常类似。Hadoop等大数据分析技术也是对海量数据进行大规模的数据分析和深度挖掘，也包含交互式联机查询和统计报表类应用，同时大数据的数据质量也较低，数据分布是真实而不均匀的。因此TPC-DS成为客观衡量多个不同Hadoop版本以及SQL on Hadoop技术的最佳测试集。这个基准测试有以下几个主要特点：
- 一共99个测试案例，遵循SQL’99和SQL 2003的语法标准，SQL案例比较复杂
- 分析的数据量大，并且测试案例是在回答真实的商业问题
- 测试案例中包含各种业务模型（如分析报告型，迭代式的联机分析型，数据挖掘型等）
- 几乎所有的测试案例都有很高的IO负载和CPU计算需求
结论：
TPC-C是针对OLTP的测试，TPC-H和TPC-DS则是针对OLAP的测试，在新兴的HATP数据库兴起是则TPC-C、TPC-H和TPC-DS都需要进行测试测试验证，不过大部分数据库目前对TPC-DS的99个SQL查询支持尚不完善。
来源：https://blog.csdn.net/CYH_job/article/details/103710181?spm=1001.2101.3001.6661.1&utm_medium=distribute.pc_relevant_t0.none-task-blog-2%7Edefault%7ECTRLIST%7ERate-1-103710181-blog-124722903.pc_relevant_multi_platform_featuressortv2removedup&depth_1-utm_source=distribute.pc_relevant_t0.none-task-blog-2%7Edefault%7ECTRLIST%7ERate-1-103710181-blog-124722903.pc_relevant_multi_platform_featuressortv2removedup&utm_relevant_index=1
