事务处理方法、装置、计算设备及存储介质与流程

1.本技术涉及数据库技术领域，特别涉及一种事务处理方法、装置、计算设备及存储介质。


背景技术：

2.随着数据库技术的发展，在数据仓库、大数据分析等场景中，通常会采用基于htap(hybrid transaction/analytical processing，混合交易/分析处理)架构的数据处理系统。在htap系统内包括oltp(on-line transaction processing，在线交易处理)集群和olap(on-line analytical processing，在线分析处理)集群，oltp集群用于处理短时用户交易型事务，具有事务执行时间短、并发度高等特点，对单位时间吞吐量要求较高；olap集群用于处理复杂分析型事务，具有事务执行时间长、资源占用多、处理的数据量大等特点。
3.在上述htap系统中，olap集群和oltp集群之间配置有数据迁移模块，用来将oltp集群内最新的相关数据迁移到olap集群中，以保证olap集群和oltp集群对数据分析和处理的一致性，换言之，传统的htap系统仅支持对最新数据提供在线交易和分析功能。


技术实现要素：

4.本技术实施例提供了一种事务处理方法、装置、计算设备及存储介质，能够并不局限于仅对最新数据提供分析功能、而是针对全时态的时间轴上的任一个查询时间段提供在线实时分析和处理服务。该技术方案如下：
5.一方面，提供了一种事务处理方法，该方法包括：
6.从目标事务的查询时间段中确定第一时刻，所述第一时刻为对符合所述目标事务的数据查询条件的历史态数据最近一次完成转储的时刻；
7.基于所述历史态数据，获取全量分析结果，所述全量分析结果为基于所述目标事务的分析语义对所述历史态数据进行处理所得的结果；
8.基于从所述第一时刻起至所述查询时间段的结束时刻之间在所述历史态数据对应的当前态数据上发生的变更，获取增量分析结果，所述增量分析结果为基于所述分析语义对所述变更得到的数据进行处理所得的结果；
9.基于所述全量分析结果和所述增量分析结果，获取所述目标事务的目标分析结果。
10.一方面，提供了一种事务处理装置，该装置包括：
11.确定模块，用于从目标事务的查询时间段中确定第一时刻，所述第一时刻为对符合所述目标事务的数据查询条件的历史态数据最近一次完成转储的时刻；
12.第一获取模块，用于基于所述历史态数据，获取全量分析结果，所述全量分析结果为基于所述目标事务的分析语义对所述历史态数据进行处理所得的结果；
13.第二获取模块，用于基于从所述第一时刻起至所述查询时间段的结束时刻之间在所述历史态数据对应的当前态数据上发生的变更，获取增量分析结果，所述增量分析结果
为基于所述分析语义对所述变更得到的数据进行处理所得的结果；
14.第三获取模块，用于基于所述全量分析结果和所述增量分析结果，获取所述目标事务的目标分析结果。
15.在一种可能实施方式中，所述第一获取模块包括：
16.查询单元，用于查询是否缓存对第二时刻可见的第一历史态数据的中间分析结果，所述第二时刻为所述查询时间段的开始时刻到所述第一时刻之间的任一时刻；
17.确定单元，用于在已缓存所述中间分析结果的情况下，将所述中间分析结果确定为所述全量分析结果；
18.第一生成单元，用于在未缓存所述中间分析结果的情况下，生成对所述第一时刻可见的第二历史态数据的所述全量分析结果。
19.在一种可能实施方式中，所述第一生成单元包括：
20.确定子单元，用于确定所述第二历史态数据的冷热等级，所述冷热等级用于表征在目标时间段内对在所述第二历史态数据上发生操作的频繁程度；
21.读取子单元，用于从与所述冷热等级对应的存储设备中，读取所述第二历史态数据；
22.处理子单元，用于基于所述分析语义，对所述第二历史态数据进行处理，得到所述全量分析结果。
23.在一种可能实施方式中，所述确定子单元用于：
24.获取所述目标时间段内对所述第二历史态数据的访问次数；
25.获取所述目标时间段内对所述第二历史态数据对应的当前态数据的修改次数；
26.基于所述访问次数和所述修改次数，确定所述冷热等级。
27.在一种可能实施方式中，冷热等级不同的历史态数据存储在不同的存储设备或者同一存储设备的不同存储介质中。
28.在一种可能实施方式中，所述第二获取模块包括：
29.获取单元，用于基于所述变更产生的日志，获取所述变更得到的数据；
30.第二生成单元，用于比较主键标识相同的历史态数据和变更得到的数据，生成所述增量分析结果。
31.在一种可能实施方式中，所述增量分析结果包括变更前的分析结果和变更后的分析结果，所述第二生成单元用于：
32.对主键标识相同的历史态数据和变更得到的数据，确定发生变更的字段；
33.如果所述数据查询条件不涉及所述发生变更的字段，跳过具有所述主键标识的数据；
34.如果所述数据查询条件涉及所述发生变更的字段，对所述第一时刻可见的第二历史态数据，生成所述变更前的分析结果；对所述结束时刻可见的变更得到的目标数据，生成所述变更后的分析结果。
35.在一种可能实施方式中，所述第三获取模块用于：
36.将所述全量分析结果减去所述变更前的分析结果，得到第一分析结果；
37.将所述第一分析结果加上所述变更后的分析结果，得到所述目标分析结果。
38.在一种可能实施方式中，所述确定模块还用于：
39.当所述目标事务未指定所述查询时间段的开始时刻时，将符合所述数据查询条件的数据的最新版本的生效时刻确定为所述开始时刻；
40.当所述目标事务未指定所述查询时间段的结束时刻时，将当前时刻之前距离所述当前时刻达到实时程度参数的时刻确定为所述结束时刻，所述实时程度参数用于表征数据库系统内的分析型事务处理的数据所支持的最大延时。
41.在一种可能实施方式中，所述第二获取模块还用于：
42.从所述结束时刻开始，每间隔第一目标时长，获取一次所述第一目标时长内发生变更的目标增量分析结果；
43.缓存获取到的各个目标增量分析结果。
44.在一种可能实施方式中，所述第三获取模块还用于：
45.每间隔第二目标时长，基于上一次的全量分析结果与所述第二目标时长内产生的各个目标增量分析结果，获取本次的全量分析结果。
46.一方面，提供了一种计算设备，该计算设备包括一个或多个处理器和一个或多个存储器，该一个或多个存储器中存储有至少一条计算机程序，该至少一条计算机程序由该一个或多个处理器加载并执行以实现如上述任一种可能实现方式的事务处理方法。
47.一方面，提供了一种存储介质，该存储介质中存储有至少一条计算机程序，该至少一条计算机程序由处理器加载并执行以实现如上述任一种可能实现方式的事务处理方法。
48.一方面，提供一种计算机程序产品或计算机程序，所述计算机程序产品或所述计算机程序包括一条或多条程序代码，所述一条或多条程序代码存储在计算机可读存储介质中。计算设备的一个或多个处理器能够从计算机可读存储介质中读取所述一条或多条程序代码，所述一个或多个处理器执行所述一条或多条程序代码，使得计算设备能够执行上述任一种可能实施方式的事务处理方法。
49.本技术实施例提供的技术方案带来的有益效果至少包括：
50.通过针对目标事务确定查询时间段，并以第一时刻作为查询时间段内的一个时间点分界线，对第一时刻之前的历史态数据计算出一个全量分析结果，对第一时刻之后变更得到的数据计算出一个增量分析结果，将全量分析结果和增量分析结果两者结合，最终得到目标分析结果，使得针对全时态的时间轴上的任一个查询时间段，都能够提供在线实时分析和处理服务，而并不局限于仅对最新数据提供分析功能，从而大大提升了htap系统或htasp系统等数据库系统的事务处理性能。
附图说明
51.为了更清楚地说明本技术实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本技术的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还能够根据这些附图获得其他的附图。
52.图1是本技术实施例提供的一种htap系统的实施环境架构图；
53.图2是本技术实施例提供的一种事务处理流程的逻辑框图；
54.图3是本技术实施例提供的一种事务处理方法的实施环境示意图；
55.图4是本技术实施例提供的一种事务处理方法的流程图；
56.图5是本技术实施例提供的一种历史态数据与冷热温数据的关系示意图；
57.图6是本技术实施例提供的一种主从副本机制内增加实时分析从副本的原理性示意图；
58.图7是本技术实施例提供的一种冷热数据的存储模型的原理性示意图；
59.图8是本技术实施例提供的一种全时态的数据记录的存储形态原理图；
60.图9是本技术实施例提供的一种事务处理方法的流程图；
61.图10是本技术实施例提供的一种实时分析模型的原理性流程图；
62.图11是本技术实施例提供的一种流式计算模型的数据记录的存储形态的原理性示意图；
63.图12是本技术实施例提供的一种htasp系统的实施环境架构图；
64.图13是本技术实施例提供的一种冷热数据的访问量比例和数据量分布的统计图；
65.图14是本技术实施例提供的一种事务处理装置的结构示意图；
66.图15是本技术实施例提供的一种计算设备的结构示意图；
67.图16是本技术实施例提供的一种计算设备的结构示意图。
具体实施方式
68.为使本技术的目的、技术方案和优点更加清楚，下面将结合附图对本技术实施方式作进一步地详细描述。
69.本技术中术语“第一”“第二”等字样用于对作用和功能基本相同的相同项或相似项进行区分，应理解，“第一”、“第二”、“第n”之间不具有逻辑或时序上的依赖关系，也不对数量和执行顺序进行限定。
70.本技术中术语“至少一个”是指一个或多个，“多个”的含义是指两个或两个以上，例如，多个第一位置是指两个或两个以上的第一位置。
71.在介绍本技术实施例之前，需要引入一些云技术领域内的基本概念。
72.云技术(cloud technology)：是指在广域网或局域网内将硬件、软件、网络等系列资源统一起来，实现数据的计算、储存、处理和共享的一种托管技术，也即是基于云计算商业模式应用的网络技术、信息技术、整合技术、管理平台技术、应用技术等的总称，可以组成资源池，按需所用，灵活便利。云计算技术将变成云技术领域的重要支撑。技术网络系统的后台服务需要大量的计算、存储资源，如视频网站、图片类网站和更多的门户网站。伴随着互联网行业的高度发展和应用，将来每个物品都有可能存在自己的识别标志，都需要传输到后台系统进行逻辑处理，不同程度级别的数据将会分开处理，各类行业数据皆需要强大的系统后盾支撑，均能通过云计算来实现。
73.云存储(cloud storage)：是在云计算概念上延伸和发展出来的一个新的概念，分布式云存储系统(以下简称存储系统)是指通过集群应用、网格技术以及分布存储文件系统等功能，将网络中大量各种不同类型的存储设备(存储设备也称之为存储节点)通过应用软件或应用接口集合起来协同工作，共同对外提供数据存储和业务访问功能的一个存储系统。
74.数据库(database)：简而言之可视为一种电子化的文件柜——存储电子文件的处所，用户可以对文件中的数据进行新增、查询、更新、删除等操作。所谓“数据库”是以一定方
式储存在一起、能与多个用户共享、具有尽可能小的冗余度、与应用程序彼此独立的数据集合。
75.以下，对本技术实施例所涉及的术语进行解释说明。
76.计算设备：即计算节点或计算引擎节点，主要完成sql(structured query language，结构化查询语言)层的计算功能，亦可称为sql引擎(sql engine)。换言之，计算设备是指数据库(通常指集群数据库，对于单机数据库来说单机设备本身就是一个计算设备)中用来处理用户特定计算请求(简称用户请求)，并主要负责执行用户请求的节点设备。
77.存储设备：即存储节点或存储引擎节点(storage engine)，主要完成事务(transaction)及存储功能。换言之，存储设备是指数据库中用来处理存储数据记录，并完成事务执行与提交的节点。
78.在线交易处理(on-line transaction processing，oltp)系统：在线交易处理系统主要用来处理短时内用户发起的交易型事务，交易型事务的特征为：事务执行时间短、并发度高，因此对于在线交易处理系统在单位时间内的吞吐量要求高。
79.在线分析处理(on-line analytical processing，olap)系统：在线分析处理系统，主要用来处理复杂的分析型事务，分析型事务的特征为：事务执行时间长、对于资源的占用较多、处理的数据量大。
80.混合交易/分析处理(hybrid transaction/analytical processing，htap)系统：这是一种混合在线交易和在线分析这两种负载的数据处理系统，可看作是一种融合系统，期望在一个系统内既支持交易型事务也支持分析型事务。
81.混合交易/分析/流式计算处理(hybrid transaction/analytical/stream processing，htasp)系统：是指基于htap系统，引入流式计算能力的数据处理系统。
82.抽取-转换-加载(extract-transform-load，etl)：用来描述将数据从源端经过抽取和转换以加载至目的端的过程。etl方式较常用在数据仓库，但etl可操作的对象并不限于数据仓库。
83.paxos算法：是莱斯利
·
兰伯特(leslie lamport)于1990年提出的一种基于消息传递且具有高度容错特性的共识(consensus)算法。
84.raft算法：是一种用于替代paxos的共识算法。相比于paxos算法来说，raft算法的目标是提供更清晰的逻辑分工，使得raft算法本身能被更好地理解，同时raft算法的安全性更高，并能提供一些额外的特性。raft算法能为在计算机集群之间部署有限状态机提供一种通用方法，并确保集群内的任意节点在某种状态转换上保持一致。
85.在介绍本技术实施例之前，需要引入一些数据库技术中的基本概念：
86.本技术实施例涉及的数据库存储有多个数据表，每个数据表可以用于存储数据记录。其中，该数据库可以为基于mvcc(multi-version concurrency control，多版本并发控制)的任一类型的数据库。在本技术实施例中，对该数据库的类型不作具体限定。需要说明的是，上述数据库中的数据基于状态属性，可以包括三种状态：当前态、过渡态和历史态，该三种状态合称为“数据的全态”，简称全态数据，全态数据中的各个不同状态属性，可以用于标识数据在其生命周期轨迹中所处的状态。
87.当前态(current state)：数据记录的最新版本的数据，是处于当前阶段的数据。处于当前阶段的数据的状态，称为当前态。
88.过渡态(transitional state)：不是数据记录的最新版本也不是历史版本，处于从当前态向历史态转变的过程中，处于过渡态的数据，称为半衰数据。
89.历史态(historical state)：数据记录在历史上的一个状态，其值是旧值，不是当前值。处于历史阶段的数据的状态，称为历史态。一个数据记录的历史态，可以有多个，反映了数据的状态变迁的过程。处于历史态的数据，只能被读取而不能被修改或删除。
90.需要说明的是，在mvcc机制下，数据的上述三种状态均存在，在非mvcc机制下，数据可以只存在历史态和当前态。在mvcc或封锁并发访问控制机制下，事务提交后的数据的新值处于当前态。以mvcc机制为例，当前活跃事务列表中最小的事务之前的事务生成的数据，其状态处于历史态。在封锁并发访问控制机制下，事务提交后，提交前的数据的值变为历史态的值，即数据记录的旧值处于历史态。而被读取的版本上尚有活跃事务(非最新相关事务)在使用，而由于最新相关事务修改了数据记录的值，其最新值已经处于一个当前态，被读取到的值相对当前态已经处于一个历史状态，因此，其数据状态介于当前态和历史态之间，所以称为过渡态。
91.例如，mvcc机制下，用户表(user表)的a账户余额从10元充值变为20元，然后消费了15元变为5元，此时金融b机构读取数据做检查事务一直进行中，a之后又充值20元变为25元，则25元为当前态数据，b正在读取到的5元为过渡态，其余的两个值20、10是历史上存在过的状态，都是历史态数据。
92.数据记录的可见性：数据记录的可见与否(即数据记录的可见性)是针对于事务而言的，某一条数据记录可能针对一些事务可见，针对一些事务不可见。在本技术实施例中，涉及到判断处于历史态的数据记录(即历史态数据)是否在目标事务的查询时间段内可见，相关的可见性判断算法将在后续的实施例中说明，这里不做赘述。
93.在传统的htap系统中包括oltp集群和olap集群，oltp集群用于处理短时用户交易型事务，olap集群用于处理复杂分析型事务。在olap集群和oltp集群之间配置有数据迁移模块，用来将oltp集群内最新的相关数据迁移到olap集群中，以保证olap集群和oltp集群对数据分析和处理的一致性。由于在oltp集群对数据记录进行变更之后，不提供对历史态数据的存储功能，即当一条数据记录从旧值修改为新值，旧值会被新值直接覆盖，此后olap集群如果收到一个对被修改的数据记录的分析型事务，需要通过数据迁移模块把oltp集群中最新版本的数据记录同步到olap集群中，然后在同步后的数据记录上进行分析和处理，换言之，传统的htap系统仅支持对最新数据提供在线交易和分析功能，无法针对时间轴上指定的任一时间点或时间段内的历史态数据提供在线分析功能。
94.有鉴于此，本技术实施例提供一种事务处理方法，针对htap系统内存储的各个数据记录，提供在时间维度上全态数据的保存功能，即，在htap系统内保存所有的当前态数据、过渡态数据和历史态数据，当一条数据记录被修改之后，最新版本的数据记录(当前态数据)和转变为历史版本的数据记录(历史态数据)都会被存储到存储集群的存储设备中，并且在htap系统中还通过流式计算处理引擎，对外提供流式分析和处理功能，融合了流式计算处理引擎的htap系统也称为htasp系统。
95.换言之，基于全时态数据的时间维度，提供一种融合流式计算处理引擎的htasp系统，在整个htasp系统中oltp集群和olap集群能够使用同一份全时态数据完成交易或分析，并且大大降低了由于数据迁移模块导致的oltp集群和olap集群的耦合，使得oltp集群和
olap集群各自在处理事务时互相隔离、互不影响。
96.进一步的，由于对每一条数据记录都增加了时间维度的相关信息，使得olap集群不止支持对最新版本的数据记录进行分析的功能，而且用户在自定义在线分析的实时程度参数之后，能够以记录级的细粒度来在历史态数据上进行分析，并且用户在自定义增量分析结果的时间窗和全量分析结果的计算周期之后，能够每隔一个计算周期进行一次全量分析，在每个计算周期内每隔一个时间窗进行一次增量分析，即提供并行计算和流式计算在最小粒度上的结合，实现了在同一份全时态数据上构建htasp系统并对外提供高质量的数据服务的功能。
97.需要说明的是，本技术实施例可应用于htap系统、htasp系统等各类支持混合交易/分析的数据处理系统，此外，本技术实施例还可应用于一种基于区块链技术的数据库系统(以下简称为“区块链系统”)，上述区块链系统在本质上属于一种去中心化式的分布式数据库系统，采用共识算法保持区块链上不同计算设备所记载的账本数据一致，通过密码算法保证不同计算设备之间账本数据的加密传送以及不可篡改，通过脚本系统来拓展账本功能，通过网络路由来进行不同计算设备之间的相互连接。
98.在区块链系统中可以包括一条或多条区块链，区块链是一串使用密码学方法相关联产生的数据块，每一个数据块中包含了一批次网络交易的信息，用于验证其信息的有效性(防伪)和生成下一个区块。示意性地，在htap系统下，由各个已完成的交易型事务的日志记录作为账本数据，并构建区块链系统，在每个计算设备中各自存储一批次的网络交易信息(即日志记录)，将网络交易信息上链之后能够实现任意时刻的历史交易信息(历史态数据)的可追溯性。
99.区块链系统中计算设备之间可以组成点对点(peer to peer，p2p)网络，p2p协议是一个运行在传输控制协议(transmission control protocol，tcp)协议之上的应用层协议。在区块链系统中，任一计算设备可以具备如下功能：1)路由，计算设备具有的基本功能，用于支持计算设备之间的通信；2)应用，用于部署在区块链中，根据实际业务需求而实现特定业务，记录实现功能相关的数据形成账本数据，在账本数据中携带数字签名以表示数据来源，将账本数据发送至区块链系统中的其他计算设备，供其他计算设备在验证账本数据来源以及完整性成功时，将账本数据添加至临时区块中，其中，应用实现的业务可以包括钱包、共享账本、智能合约等；3)区块链，包括一系列按照先后的时间顺序相互接续的区块，新区块一旦加入到区块链中就不会再被移除，区块中记录了区块链系统中计算设备提交的账本数据。
100.在一些实施例中，每个区块中可以包括本区块存储交易记录的哈希值(本区块的哈希值)以及前一区块的哈希值，各区块通过哈希值连接形成区块链，另，区块中还可以包括有区块生成时的时间戳等信息。
101.图1是本技术实施例提供的一种htap系统的实施环境架构图。参见图1，在htap系统100中包括oltp集群110和olap集群120。
102.oltp集群110用于提供在线交易功能，在oltp集群110中包括多个tp计算节点，该tp计算节点用于处理交易型事务，当交易型事务对数据记录修改完毕，会将产生的历史态数据通过存储接口转储到分布式文件系统130中。每个tp计算节点都配置有各自的数据库引擎，每个tp计算节点可以是单机设备或者一主两备集群设备等，本技术实施例不对tp计
算节点的类型进行具体限定。
103.olap集群120用于提供在线分析功能，在olap集群120中包括多个ap计算节点，该ap计算节点用于处理分析型事务，该分析型事务包括但不限于：查询历史态数据或者在查询得到的历史态数据上进一步处理以得到某个分析结果，例如，金融场景下，该分析型事务t1为用户查询过去一个月内的账单流水总额，则这一分析型事务t1需要从分布式文件系统130中查询用户过去一个月内进行交易记录，并对花费的金额进行求和(sum)，得到的账单流水总额就是该分析型事务t1的分析结果，又例如，智慧交通场景下，该分析型事务t2为用户查询过去一周内某市内每个行政区域中新增停车位的总量，则这一分析型事务t2需要以该市内的每个行政区域为单位，从分布式文件系统130中查询每个行政区域内新增停车位的插入记录，并对插入的新增停车位的数量进行求和(sum)，得到的每个行政区域内新增停车位的总量所构成的集合就是分析型事务t2的分析结果。
104.oltp集群110和olap集群120都能够通过存储接口访问到分布式文件系统130，oltp集群110、olap集群120两者均能够和分布式文件系统130之间通过有线或无线通信方式进行直接或间接地连接，本技术实施例对此不进行具体限定。
105.分布式文件系统130能够对oltp集群110和olap集群120提供无限存储功能，分布式文件系统130中包括多个存储节点即存储设备，可按照冷热等级对全时态数据进行分区，将冷热等级相同的数据划分到相同分区下的存储设备中进行存储，或者，将冷热等级相同的数据划分到相同分区下的存储设备的同一种存储介质中进行存储。例如，该分布式文件系统130包括但不限于：hdfs(hadoop distributed file system，hadoop分布式文件系统)、ceph(一种linux系统下的分布式文件系统)、alluxio(一种基于内存的分布式文件系统)等。
106.在一些实施例中，由于tp计算设备提供在线交易功能，当任一交易型事务提交完成的时刻，在生成新的当前态数据的同时，也会生成与该当前态数据所对应的历史态数据，而由于历史态数据会占用较多存储空间，而历史态数据又具有保存价值，因此会将历史态数据转储到分布式文件系统中对应的存储设备上面进行持久化存储，在对历史态数据转储完毕之后，tp计算节点可删除本次转储的历史态数据，以清理更多的存储空间。
107.在一些实施例中，当tp计算节点将历史态数据成功转储到存储设备上之后，还可将本次转储的历史态数据的元数据注册到元数据(meta data，md)管理器中，便于存储设备基于该元数据管理器统计已储备的历史态数据的元信息。
108.在一些实施例中，用户负载到达htap系统100后，数据库引擎对该用户负载(即用户事务，包括交易型事务或者分析型事务)进行解析，基于sql路由(structured query language router，sql router，简称sr)层中提供的查询语句、查询操作的语义和元数据，将该用户负载路由到oltp集群110或olap集群120中进行处理。例如，oltp集群110主要提供对当前态数据的查询和修改服务，olap集群120则主要提供对历史态数据的查询和分析服务(不支持修改或删除历史态数据)。其中，查询操作的语义是根据查询语句分析得到的操作意图，例如，where子句的条件可以表示where子句的意图。
109.在上述架构中，每个tp计算节点或ap计算节点(统称为计算节点)所对应的一个或多个数据库的数据库实例集合称为一个set(集合)，可选地，如果计算节点为单机设备，那么该单机设备的数据库实例为一个set，如果计算节点为一主两备集群设备，那么该计算节
点的set为主机数据库实例以及两个备机数据库实例的集合，此时基于云数据库(cloud database)的强同步技术来保证主机的数据与备机的副本数据之间的一致性，可选地，每个set支持线性扩容，以应付大数据场景下的业务处理需求。
110.在一些实施例中，oltp集群110或olap集群120通过分布式协调系统(例如zookeeper)实现对tp计算节点或ap计算节点的管理，例如通过zookeeper使得某一个tp计算节点或ap计算节点失效(也即是将该tp计算节点或ap计算节点从oltp集群110或olap集群120中删除)。
111.在一些实施例中，上述htap系统100可整体视为一个对外提供混合交易和分析功能的服务器，服务器可以是独立的物理服务器，或者是多个物理服务器构成的服务器集群或者分布式系统，或者是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、cdn(content delivery network，内容分发网络)、以及大数据和人工智能平台等基础云计算服务的云服务器。
112.在一些实施例中，用户负载是用户由终端向htap系统100发起的用户事务，其中，用户侧的终端也称为用户设备、终端设备、用户终端、移动终端、智能终端、通信设备等。可选地，终端的设备类型包括：智能手机、平板电脑、笔记本电脑、台式计算机、智能音箱、智能手表、车载终端、智能家电、智能语音交互设备等，但并不局限于此。
113.以下，对本技术实施例的系统架构下事务的逻辑流程进行介绍。
114.图2是本技术实施例提供的一种事务处理流程的逻辑框图，如200所示，在本技术实施例所适用的htap系统中，htap系统接收到用户发起的一个sql语句，将该sql语句输入到查询解析器(query parser)中，先后对该sql语句进行词法分析(lexical analysis)、句法分析(syntax analysis)、时态翻译(temporal translation)和语义检查(semantic check)。在句法分析和时态翻译过程中，需要先对查询语句(select query)按照查询树进行重写，再将重写后的查询语句输入到优化器(optimizer)中进行查询优化，接着从事务状态管理器(transaction status manager)中对该查询语句的查询事务申请一个事务状态(transaction status)，再将优化器输出的查询语句和事务状态管理器输出的事务状态一起输入到执行器(executor)中进行查询执行。
115.在htap系统的存储集群(例如分布式文件系统)中，将当前态数据和历史态数据分别存储在不同的存储设备中。例如，将冷热等级较高(例如访问频率和修改频率都很高)的数据记录存储在当前态数据存储设备中，随着时间的推移，如果当前态数据存储设备中的部分数据记录的冷热等级下降，可将冷热等级下降的该部分数据记录通过etl方式进行抽取、转换，并最终加载到历史态数据存储设备中进行持久化存储。可选地，历史态数据存储设备可对加载到的历史态数据进行压缩，比如对某一条数据记录的各个历史版本，仅存储一部分历史版本的全量数据，剩余的另一部分历史版本以与上一个全量数据之间的增量数据的方式进行存储。
116.在上述处理流程中，每一条数据记录都从插入到更新，完整的保留了按照时间维度排列的各个版本(包括当前版本和一个或多个历史版本)，这些各个版本的数据反映了从插入数据记录以来相关事务每一次对该数据记录进行的操作，通过在全时态数据的基础上搭建htap系统或者htasp系统，能够只基于一套全时态数据实现htap系统或者htasp系统，并且使得oltp集群和olap集群在运行时基于用户设定的实时程度参数，来最大化地降低
oltp集群和olap集群的耦合程度，即最小化oltp集群和olap集群之间的相互影响。
117.进一步的，通过全时态数据，能够很方便地向htap系统引入流式计算能力以转变成htasp系统，并且能够在记录级别对数据记录的各个版本按照时间轴进行细粒度地划分，从而以更小粒度来划分实时分析的大任务，提高更高水平的扩张能力。
118.进一步的，以时间窗为基础，为整个htap系统或者htasp系统提供全量与增量合并得到分析结果的执行模式，能够最大程度上节约计算资源，提高olap集群的分析处理能力。
119.进一步的，在分布式数据库集群中，通过以数据块(block)为单位来对历史态数据进行转储，能够减少转储历史态数据而对oltp集群所造成的影响，从而保证不影响oltp集群的正常工作。
120.图3是本技术实施例提供的一种事务处理方法的实施环境示意图，如图3所示，示出了一种基于htap架构的实时分析系统或实时分析模型，由于在该实时分析系统中引入了全时态数据，原本传统htap是不支持在历史态数据上做分析的，且每次对当前态数据都需要进行全量分析(相当于一层计算模式)，但本技术实施例提供的实时分析系统，由于实现了历史态数据的转储，从而支持在历史态数据上做分析，且无需每次对当前态数据都进行全量分析，而是能够转换成之前在某个时间点计算的全量分析结果作为基线，结合从该时间点到实时分析事务所指定的时间点(如果用户未指定，可根据系统的实时程度参数来计算得到)计算的增量分析结果，合并得到最终的目标分析结果，即提供了一种两层实时分析模型。
121.在该实时分析系统中，包含计算层310和分层分布式共享存储系统320，在计算层310中包括oltp集群311和olap集群312，oltp集群311通常针对在当前态数据和过渡态数据上发起的短时交易型事务提供在线交易功能，olap集群312通常针对在历史态数据上发起的复杂分析型事务提供在线分析功能。oltp集群311和olap集群312两者均能够访问到分层分布式共享存储系统320中存储的全时态数据，示意性地，按照全时态数据的冷热等级，将系统内所有的数据划分为如下几种分区：热数据、温数据、冷数据等。在后续实施例中将对冷热等级的划分方式进行详细介绍，这里不做赘述。
122.在一些实施例中，如果到达olap集群312的分析型事务不涉及到热数据，那么在该分析型事务的执行过程中无需与oltp集群311产生任何交互。可选地，如果到达olap集群312的分析型事务涉及到热数据，并且这部分最新修改的热数据尚未转储到分层分布式共享存储系统320中，那么olap集群312则根据该分析型事务的业务需求，以时态为条件(即查询时间段)从olap集群311中查询尚未转储的热数据。
123.图4是本技术实施例提供的一种事务处理方法的流程图。参见图4，该实施例适用于htap系统、htasp系统或者区块链系统等支持实时分析的数据处理系统，该事务处理方法由olap集群中的任一计算设备执行，该实施例包括下述步骤：
124.401、计算设备从目标事务的查询时间段中确定第一时刻，该第一时刻为对符合该目标事务的数据查询条件的历史态数据最近一次完成转储的时刻。
125.其中，该目标事务是任一种可能的分析型事务，例如，该分析型事务包括但不限于：查询事务，只读事务，或者在查询结果上进行分析或处理的事务等。例如，金融场景下一种示例性的分析型事务为：查询用户过去一个月内的账单流水总额；又例如，智慧交通场景下一种示例性的分析型事务为：查询过去一周内某市内每个行政区域中新增停车位的总
量。
126.其中，该查询时间段是由一个开始时刻和一个结束时刻所构成的时间区间。该查询时间段的开始时刻或结束时刻可由用户请求来自定义，如果用户请求中未定义开始时刻或结束时刻，则由数据库引擎来对目标事务配置该查询时间段。
127.其中，该第一时刻是指所有符合该目标事务的数据查询条件的历史态数据最近一次完成转储的时刻，该数据查询条件是解析该目标事务的sql语句得到的，上述转储过程是指：将oltp集群产生的该历史态数据迁移到存储集群的存储设备上进行存储。
128.在一些实施例中，用户在终端上登录应用客户端，触发应用客户端生成用户请求，例如，金融场景下，用户请求为请求查询用户在过去一个月内的账单流水总额，又例如，智慧交通场景下，用户请求为请求查询过去一周内某市内每个行政区域中新增停车位的总量，本技术实施例不对用户请求的类型进行具体限定。应用客户端在生成用户请求之后，可调用api(application programming interface，应用程序编程接口)将该用户请求发送至计算设备，比如，该api可以是mysql api(一种关系型数据库系统提供的api)。
129.在一些实施例中，计算设备接收应用客户端的任一用户请求，解析该用户请求的头字段，当该头字段指示该用户请求为分析型事务时，解析该用户请求的数据字段，得到该用户请求中携带的sql语句(例如select query语句等)，将该sql语句到查询解析器中，通过该查询解析器对该sql语句进行词法分析、句法分析、时态翻译和语义检查，得到该sql语句的数据查询条件和分析语义(比如，求和、求平均、排序等)，另外，如果sql语句中指定了查询时间段的开始时刻，则获取该开始时刻，如果sql语句中指定了查询时间段的结束时刻，则获取该结束时刻。接着，基于该sql语句构建对应的该目标事务，计算设备为该目标事务创建一个进程或线程，或者复用已创建的某个进程或线程，并通过该进程或线程来处理该目标事务。
130.示意性地，当该目标事务指定了该查询时间段的开始时刻时，则以目标事务指定的开始时刻为准，当该目标事务未指定该查询时间段的开始时刻时，可选地，以目标事务所查询的数据的最新版本的生效时刻为准，也即将符合该数据查询条件的数据的最新版本的生效时刻确定为该开始时刻，当涉及到查询多个数据的时候，对每个数据都以各自最新版本的生效时刻来选择对应的可见版本进行分析即可，可选地，以目标事务所查询的数据的插入版本的生效时刻为准，也即将符合该数据查询条件的数据的插入版本的生效时刻确定为该开始时刻，当涉及到查询多个数据的时候，对每个数据都以各自插入版本的生效时刻来选择对应的可见版本进行分析即可，本技术实施例对开始时刻的确定方式不进行具体限定。
131.示意性地，当该目标事务指定了该查询时间段的结束时刻时，则以目标事务指定的结束时刻为准，当该目标事务未指定该查询时间段的结束时刻时，可选地，获取数据库系统内的实时程度参数，该实时程度参数用于表征数据库系统内的分析型事务处理的数据所支持的最大延时，换言之，该数据库系统可允许使用多久之前的历史态数据来进行分析，比如，设定实时程度参数为1小时，则代表数据库系统允许以1小时之前的历史态数据来进行分析。可选地，该实时程度参数由管理用户来进行自定义设置，如果管理用户没有设置过实时程度参数，则采用数据库系统的默认值(例如1秒)，其中该默认值也是可以进行修改的，本技术实施例对此不进行具体限定。在获取到实时程度参数之后，基于该实时程度参数来
确定该结束时刻，可选地，将当前时刻之前距离该当前时刻达到实时程度参数的时刻确定为该结束时刻，本技术实施例不对结束时刻的确定方式进行具体限定。
132.在基于上述方式确定了开始时刻和结束时刻之后，即可得到从开始时刻到结束时刻所构成的查询时间段，可选地，该查询时间段是一个闭区间，即该查询时间段既包括左端点的开始时刻也包括右端点的结束时刻，或者，该查询时间段是一个左闭右开的时间区间，即该查询时间段包括左端点的开始时刻，但不包括右端点的结束时刻，其中，左闭右开的时间区间的特定在于：对于开始时刻来说，恰好在开始时刻生效的数据是可见的，对于结束时刻来说，恰好在结束时刻生效的数据是不可见的，这一点是用于判断辅助数据的可见性。可选地，由用户指定该查询时间段是否包含右端点的结束时刻，如果指定包含该结束时刻，则该查询时间段为闭区间，如果指定不包含该结束时刻，则该查询时间段为左闭右开的时间区间，如果用户未指定是否包含该结束时刻，可默认包含该结束时刻，即默认该查询时间段为闭区间。
133.在一些实施例中，计算设备在确定该查询时间段和该数据查询条件之后，由于oltp集群会周期性地将自身交易型事务所产生的历史态数据迁移到存储集群的存储设备中进行持久化存储，上述迁移历史态数据的过程就是对历史态数据进行转储的过程，由于每次进行转储时通常会产生相关的记录，比如在存储集群的元信息管理器中记载本次转储的历史态数据有哪些，或者专门维护一张表来记录每次转储的完成时间，因此很容易能够查询到所有符合该目标事务的数据查询条件的历史态数据最近一次完成转储的时刻(即第一时刻)。
134.402、计算设备基于该历史态数据，获取全量分析结果，该全量分析结果为基于该目标事务的分析语义对该历史态数据进行处理所得的结果。
135.在一些实施例中，以第一时刻为界限，可将查询时间段划分为两个子区间，从开始时刻到第一时刻构成的第一子区间，和从第一时刻到结束时刻构成的第二子区间，将第一子区间的全量分析结果和第二子区间的增量分析结果进行合并，即可得到最终的目标分析结果。
136.在一些实施例中，由于数据库系统内可能会缓存有从开始时刻到第一时刻之间的第二时刻下的中间分析结果，根据可见性判断算法，此时只需要将已缓存的中间分析结果和第二子区间的增量分析结果进行合并，即可得到最终的目标分析结果，即无需重复计算出第一时刻下的全量分析结果。
137.可选地，查询是否缓存对第二时刻可见的第一历史态数据的中间分析结果，该第二时刻为该查询时间段的开始时刻到该第一时刻之间的任一时刻，接着，在已缓存该中间分析结果的情况下，将该中间分析结果确定为该全量分析结果；在未缓存该中间分析结果的情况下，生成对该第一时刻可见的第二历史态数据的该全量分析结果。其中，关于可见性判断算法、生成全量分析结果的方式将会在下一个实施例中详细说明，这里不再赘述。
138.在上述过程中，通过判断是否缓存了中间分析结果，能够在已缓存有中间分析结果的情况下，避免重复计算出第一时刻下的全量分析结果，因此能够大大节约计算设备的计算资源。
139.403、计算设备基于从该第一时刻起至该查询时间段的结束时刻之间在该历史态数据对应的当前态数据上发生的变更，获取增量分析结果，该增量分析结果为基于该分析
语义对该变更得到的数据进行处理所得的结果。
140.由于第一时刻是对应的历史态数据最近一次完成转储的时刻，那么代表第一时刻起到结束时刻之间的数据都尚未从oltp集群转储到存储集群中，因此，需要先从oltp集群中获取到对应变更产生的日志，对变更产生的日志进行回放，获取到对应变更得到的数据，接着，比较主键标识相同的历史态数据和变更得到的数据，并按照目标事务的sql语句的分析语义对比较结果进行处理，生成该增量分析结果。其中，该增量分析结果只代表与上一次全量分析结果之间发生的变化，而并非是新一次计算所得的全量分析结果。
141.在上述过程中，通过对变更得到的数据仅获取增量分析结果，而无需获取全量分析结果，由于增量分析结果所需分析的数据量较少、且耗时较少，因此能够大大节约计算设备的计算开销和处理资源。
142.404、计算设备基于该全量分析结果和该增量分析结果，获取该目标事务的目标分析结果。
143.在一些实施例中，该增量分析结果包括变更前的分析结果和变更后的分析结果，因此，在合并全量分析结果和增量分析结果时，需要将该全量分析结果减去该变更前的分析结果，得到第一分析结果；将该第一分析结果加上该变更后的分析结果，得到该目标分析结果。
144.在上述过程中，通过全量计算和增量计算结合以获取最终分析结果的方式，能够将传统的单层计算模型转换为两层实时分析模型，能够适配于基于全时态数据库的htap系统或htasp系统，且能够节约整个系统内的计算资源。
145.上述所有可选技术方案，能够采用任意结合形成本公开的可选实施例，在此不再一一赘述。
146.本技术实施例提供的方法，通过针对目标事务确定查询时间段，并以第一时刻作为查询时间段内的一个时间点分界线，对第一时刻之前的历史态数据计算出一个全量分析结果，对第一时刻之后变更得到的数据计算出一个增量分析结果，将全量分析结果和增量分析结果两者结合，最终得到目标分析结果，使得针对全时态的时间轴上的任一个查询时间段，都能够提供在线实时分析和处理服务，而并不局限于仅对最新数据提供分析功能，从而大大提升了htap系统或htasp系统等数据库系统的事务处理性能。
147.进一步的，通过全量计算和增量计算结合以获取最终分析结果的方式，能够将传统的单层计算模型转换为两层实时分析模型，能够适配于基于全时态数据库的htap系统或htasp系统，且能够节约整个系统内的计算资源。
148.在上述实施例中，总体介绍了htap系统或htasp系统下，某一时刻新到一个分析型的目标事务，ap计算节点是如何对目标事务生成目标分析结果的，在本技术实施例中，将结合对数据库命令的扩展、冷热等级和全时态数据的关联、基于冷热等级的存储模型、可见性判断算法等，分别详细介绍实时分析模型和流式计算模型。
149.以下，将对基于全时态数据库搭建的htap系统或htasp系统下，数据库命令的扩展方式进行说明。
150.(1.1)设置实时程度参数的命令
151.其中，该实时程度参数用于表征数据库系统内的分析型事务处理的数据所支持的最大延时，换言之，该数据库系统可允许使用多久之前的历史态数据来进行分析，比如，设
定实时程度参数为1小时，则代表数据库系统允许以1小时之前的历史态数据来进行分析。
152.上述设置实时程度参数的命令，使得管理用户能够根据自身的sla(service level agreement，服务级别协议)需求来确定当前数据库进行在线分析的程度(即按需设置当前数据库的实时程度参数)。
153.可选地，实时程度参数的单位包括：秒、分钟或小时，此外，当实时程度参数设置为0时表示采用实时分析结果，需要感知当前交易系统(即oltp集群)的最新数据的变化，如果管理用户没有设置实时程度参数，可为当前数据库将实时程度参数配置为默认值，该默认值为大于或等于0的任一数值，例如，默认值为1s(秒)。
154.示意性地，以real_time_analyzing_degree来表示实时程度参数，则查看当前数据库的实时程度参数的命令如下述代码所示：
[0155][0156]
上述代码示出了一种针对当前数据库的实时程度参数的查看命令，能够看出，所显示的当前用户设置的实时程度参数为1秒，代表实时粒度与最新数据延迟1秒，也即，ap计算节点(即计算设备)能够从与最新数据相差1秒的历史版本或者过渡态版本的数据来进行在线分析。
[0157]
示意性地，以real_time_analyzing_degree来表示实时程度参数，则设置当前数据库的实时程度参数的命令如下述代码所示：
[0158]
set real_time_alalyzing degree＝5s；
[0159]
上述代码示出了一种针对当前数据库的实时程度参数的设置命令，能够看出，这条设置命令的含义是：允许比最新数据延迟5秒的数据版本来作为ap计算节点进行分析的数据版本。
[0160]
以下是针对上述设置命令的测试代码：
[0161]
mysql[test]》set real_time_analyzing_degree＝5s；
[0162]
0row in set(0.00sec)
[0163]
通常情况下，管理用户不会设置太大的实时程度参数，因此实时程度参数越大，代表ap计算设备进行分析的数据版本与最新版本之间的延时越大，因此，本技术实施例以秒级单位的实时程度参数为例进行说明。但管理用户可根据自身sla需求，修改为分钟单位、小时单位等粒度，再让olap集群来确定本次查询所需使用的所有数据版本。
[0164]
(1.2)设置时间窗大小的命令
[0165]
时间窗大小是指：在ap计算节点或流式计算节点上运行的流式计算引擎(或流式
计算模型)以多大的步长来计算增量分析结果。
[0166]
换言之，修改时间窗大小的命令主要是用来调节最小划分的时间窗大小，流式计算引擎会按照时间窗大小，来启动对于每个时间窗内的各个数据版本的划分与增量分析结果的计算。
[0167]
可选地，时间窗大小的单位包括：秒、分钟或小时，用户可自定义设置一个时间窗大小，但对于数据库引擎来说，会以1秒为最小的时间窗单元，从而将用户设置的时间窗大小划分为多个秒级的时间窗单元，换言之，用户设置的时间窗大小为最小的时间窗单元的整数倍，如果管理用户没有设置时间窗大小，可为当前数据库将时间窗大小配置为默认值，该默认值为大于0的任一数值，例如，默认值为1s(秒)。需要说明的是，当管理用户设置的时间窗大小大于系统最小的时间窗单元时，系统会按照最小的时间窗单元来进行数据的划分，但是只会在达到管理用户指定的时间窗大小时才进行增量分析结果的计算。
[0168]
示意性地，以time_window来表示时间窗大小，则查看当前数据库的时间窗大小的命令为show time_window；，如下述代码所示：
[0169][0170][0171]
示意性地，以time_window来表示时间窗大小，则设置当前数据库的时间窗大小的命令为set time_window；，如下述代码所示：
[0172]
mysql[test]》set time_window＝5s；
[0173]
0row in set(0.00sec)
[0174]
(1.3)设置全量分析结果的计算周期的命令
[0175]
全量分析结果的计算周期也即全量分析结果的计算频率，该计算周期用来定义在流式计算引擎中每隔多长时间计算一次全量分析结果。
[0176]
可选地，管理用户可根据业务特点定义一个全量分析结果的计算周期，通过定期发起一次全量分析结果的计算，能够减少在每一次生成目标分析结果时，由于全量分析结果太旧，导致中间需要合并的增量分析结果太多，从而导致计算性能下降的情况发生。换言之，能够保证每次生成目标分析结果时，与上一次的全量分析结果之间需要合并的增量分析结果是适配于业务特点的。
[0177]
可选地，全量分析结果的计算周期的单位包括：秒、分钟或小时，用户可自定义设置一个全量分析结果的计算周期，但对于数据库引擎来说，会以1秒为最小的时间窗单元，从而将用户设置的全量分析结果的计算周期划分为多个秒级的时间窗单元，换言之，用户设置的全量分析结果的计算周期为最小的时间窗单元的整数倍，如果管理用户没有设置全量分析结果的计算周期，可为当前数据库将全量分析结果的计算周期配置为默认值，该默
认值为大于0的任一数值，例如，默认值为1分钟，全量分析结果的计算周期的默认值通常会比增量分析结果的时间窗大小的默认值要大，这是因为系统不希望频繁进行全量分析结果的计算，当然，管理用户可根据自身的业务情况来调整设置的全量分析结果的计算周期(当前也支持调整默认值)，可选地，还可根据性能监控模块来感知当前的全量分析结果的计算周期是否会导致资源使用的波动，从而来自适应调节全量分析结果的计算周期，即，当前系统较为繁忙时，调大全量分析结果的计算周期，即降低全量分析结果的计算频率，当前系统较为空闲时，调小全量分析结果的计算周期，即提高全量分析结果的计算频率。需要说明的是，当管理用户设置的全量分析结果的计算周期大于系统最小的时间窗单元时，系统会按照最小的时间窗单元来进行数据的划分，但是只会在达到管理用户指定的全量分析结果的计算周期时才进行全量分析结果的计算。
[0178]
示意性地，以full_analazy_result_period来表示全量分析结果的计算周期，则查看当前数据库的全量分析结果的计算周期的命令为show ful l_analazy_result_period；，如下述代码所示：
[0179][0180]
示意性地，以full_analazy_result_period来表示全量分析结果的计算周期，则设置当前数据库的全量分析结果的计算周期的命令为set full_analazy_result_period；，如下述代码所示：
[0181]
mysql[test]》set full_analazy_result_period＝1m；设置全量分析结果的计算周期为1分钟；
[0182]
0row in set(0.00sec)
[0183]
(1.4)设置冷热等级的划分标准的命令
[0184]
其中，冷热等级用于表征在目标时间段内对在历史态数据上发生操作的频繁程度，由于该发生的操作包括但不限于读操作即查询或访问操作和写操作即修改或更新操作，因此，可基于目标时间段内对历史态数据的访问次数以及对历史态数据对应的当前态数据的修改次数，来综合确定出每个版本的历史态数据的冷热等级。
[0185]
可选地，管理用户可根据自身的业务系统情况来定义冷热等级的划分标准，即，管理用户自定义将什么样的数据划分到哪一种冷热等级。在一个示例性，按照发生操作的频繁程度从高到低，包括如下几类冷热等级：热数据、温数据、冷数据和归档数据，并分别设定每种冷热等级的划分标准，并按照冷热等级对全时态数据进行分区，将冷热等级相同的数据划分到相同分区下的存储设备中进行存储，或者，将冷热等级相同的数据划分到相同分区下的存储设备的同一种存储介质中进行存储，从而达到最好的数据库使用效果与最低廉
的数据库使用成本。
[0186]
示意性地，以hot_cold_data_level来表示冷热等级的划分标准，则查看当前数据库的冷热等级的划分标准的命令为show hot_cold_data_level；，意思是当某一时态的数据在规定时间段的访问次数小于指定值时，将会转储到下一个级别的存储设备或存储介质中，如下述代码所示：
[0187][0188]
基于上述示例，可知管理用户能够从两个维度指定冷热等级的划分标准，即，基于一定周期内(如数小时、1天、1周、1月、1年等，最小到1秒)对于某一条数据记录的修改和/或访问次数，来确定本条数据记录是否需要转储到下一个级别的存储设备或存储介质中。
[0189]
示意性地，以hot_cold_data_level来表示冷热等级的划分标准，则设置当前数据库的冷热等级的划分标准的命令为set hot_cold_data_lev el；，用于由管理用户根据自身业务需求来自定义转储标准。
[0190]
在一个示例性场景中，按照上述格式可修改冷热等级的划分标准，详细命令略，如果管理用户并未设置冷热等级的划分标准，可提供一种默认的冷热等级的划分标准，例如，按照如下方式划分为4个冷热等级：热数据(1天内频繁修改的数据，例如1天内修改次数＞100次)、温数据(1月内被修改次数一般，但会被访问，例如10次＜1月内修改次数＜50次，同时1月内访问次数＞50次)、冷数据(1年内数据不会被修改，但是会被访问，例如1年内访问次数＜10次)以及归档数据(超过1年没有被访问的数据)。上述默认的冷热等级划分标准也可被管理用户进行修改，本技术实施例对此不进行具体限定。
[0191]
需要说明的是，上述(1.1)-(1.4)的所有命令，都能够通过数据库启动参数配置文件中进行定义，并且，也能够在数据库运行过程中，由管理用户根据业务特点和实际资源情况来设置更为合适的值，上述所有参数都人工动态调整或者系统自适应调整，不需要停止数据库的服务。
[0192]
以下，将介绍在某一种可能的冷热等级的划分标准下，历史态数据与冷、温、热数据的关联关系：
[0193]
图5是本技术实施例提供的一种历史态数据与冷热温数据的关系示意图，如500所示，由于冷热等级的划分标准是由在一段目标时间段内发生的访问次数和/或修改次数来衡量的，使得在全时态数据库下，自然实现了历史态数据与冷数据和温数据的对应关系。即，由于热数据是指短期内(如1天)被频繁修改的数据记录，这代表着热数据对应于当前态数据和过渡态数据，对冷数据和温数据相对来说几乎不会被修改，只会被访问，因此温数据对应于历史态数据，冷数据对应于更旧的历史态数据。
[0194]
可选地，随着时间的推移，过渡态数据也会被转储为历史态数据。比如，全时态数据库会周期性启动转储算法，将过渡态数据从热数据对应的存储设备转储到温数据对应的存储设备(用于存储历史态数据)，当过渡态数据转储完毕后，热数据对应的存储设备可直接丢弃已转储完毕的过渡态数据，以节约更多的存储空间。
[0195]
可选地，当前态数据和过渡态数据都对应于热数据，而对于历史态数据，可根据用户特征来定义多个冷热级别，以满足自身业务特定的需求，比如，对历史态数据，划分为3个冷热级别：温数据、冷数据和归档数据。当任一数据一旦被转储为历史态数据之后，将会变为只读数据，即系统不允许修改历史态数据，即防止篡改历史态数据，以保护历史态数据的安全性。
[0196]
可选地，也可以将修改频率较高的当前态数据和过渡态数据对应于热数据，将修改频率较低的当前态数据和过渡态数据对应于温数据，将历史态数据划分为冷数据和归档数据，上述图5仅仅是给出一种将全时态数据和冷热等级下的数据之间的关联关系，但并不局限于图5所示的关联关系。
[0197]
可选地，当前态数据和过渡态数据，都对应于现在活跃的数据记录，当数据记录不断发生修改，就会持续产生最新版本的数据记录；当数据记录一段时间段内(目标时间段内)持续没有被修改或被访问，就会被转储为历史态数据(如冷数据)，如果在冷数据的等级下，仍然持续没有被访问，那么数据记录会因为最新的历史态数据的不断老化，会被转储成更冷的数据(如归档数据)。
[0198]
可选地，对全时态数据库中所有的当前态数据，增加一个修改标记信息来统计修改次数，此外，对所有的当前态数据、过渡态数据和历史态数据，都增加一个访问标记信息来统计访问次数，从而能够方便地判定每条数据记录是否需要被转储到下一个级别的存储设备上。
[0199]
以下，将介绍数据状态转换与主从副本机制相结合后，如何运用在htap或htasp系统中的原理。
[0200]
图6是本技术实施例提供的一种主从副本机制内增加实时分析从副本的原理性示意图，如600所示，在分布式系统的存储集群(即存储引擎)中，为了防止某一存储设备故障而导致存储设备上的所有数据不可用，通常会引入主从副本机制，即，对每一份数据(即主副本)都保存有至少一个从副本，以保证即使主副本宕机，仍然可以在从副本上提供相关数据服务。在本技术实施例中以一主两备机制为例，对每个主副本都保存有两个从副本，主从副本之间通过paxos或raft等一致性协议来保证数据一致性，从而来提升整个存储集群的数据可靠性。在paxos或raft等一致性协议下，会将数据表中的数据记录划分为一个个较小
的管理单元，比如数据块block、数据区域region、数据页page等，本技术实施例对此不进行具体限定。
[0201]
而在本技术实施例中，会在存储集群的每一组主从副本中，额外引入一个实时分析从副本，主从副本会按照传统方式来读写数据，并将相关数据都写到热数据对应的存储设备中，而实时分析从副本则只负责同步数据，但不会参与到主副本的选举流程中，这是由于某些一致性协议可能会定期重新选举主副本导致的选举流程，并且实时分析从副本也不会参与一致性协议下的任何投票流程(即不参与一致性协议下的多数派达成)。
[0202]
实时分析从副本所在的节点设备，用于提供历史态数据的转储功能，换言之，能够将历史态数据的转储功能从主副本迁移到实时分析从副本，这样能够减去主副本所在节点设备的计算压力，从而彻底解耦oltp集群和olap集群之间的相互影响。
[0203]
可选地，实时分析从副本与主副本或其他两个从副本之间可具有较大的延迟，通过一致性协议进行日志的追赶，使得最终实时分析从副本能够获取主副本上所有版本的所有数据，使得对于现在的oltp集群的干扰最低。
[0204]
可选地，实时分析从副本并不一定每次都从主副本来拉取数据，而是可根据主从副本各自的忙闲情况，选择最有利的副本(如最空闲的副本)来进行同步，从而使得实时分析副本的同步任务对oltp集群的影响最小化。
[0205]
可选地，实时分析从副本将某些访问频率或修改频率较低的数据转储为历史态数据之后，可周期性地清理掉已转储完毕的数据(主副本和其他从副本也可以同步清理掉)，比如，对1天内修改次数小于50次且访问次数小于100次的数据，则转储到历史态数据对应的存储设备中，然后直接删除转储完毕的数据。
[0206]
以下，将对本技术实施例的冷热数据的存储模型进行介绍。
[0207]
图7是本技术实施例提供的一种冷热数据的存储模型的原理性示意图，如700所示，由于上面介绍过，针对全时态数据库中数据表，增加了冷热等级的划分标准hot_cold_data_level这一参数，以下，将以划分为热数据、温数据、冷数据、归档数据这4种冷热等级为例，介绍如何基于4种冷热等级来存储对应的数据。
[0208]
在参数初始化阶段，管理用户可利用上述(1.4)中提供的相关命令，在集群建立的时候按照自身的业务特点来设置热数据、温数据、冷数据、归档数据各自的划分标准，需要说明的是，本技术实施例并不局限于划分为4个等级，且并不限定每个等级的划分标准，管理用户可细分为任意数量的等级，并设置任意的划分标准。
[0209]
可选地，在设定了冷热等级的划分标准的基础上，后续在创建数据表时，系统会自动将数据表按照数据的冷热等级来进行分区，将数据表划分到对应分区下的存储设备中进行存储。此外，存储设备的后台线程也会定期判断数据的冷热等级是否发生变化，当冷热等级发生变化时，需要将数据转储到相应的分区的其他存储设备中。
[0210]
可选地，在判断数据的冷热等级是否发生变化时，按照不同的划分标准，分别启动对于不同分区下存储的数据的后台存储处理任务，例如，扫描每个分区存储的全部数据，判断数据记录的各个版本是否符合转储到下一个存储级别的条件，如果符合转储的条件，需要将符合的各个版本的数据记录移动到对应的存储分区当中，其中，全时态数据会保留所有数据记录的所有版本，并且历史版本是不可修改的，历史版本的数据记录会逐步从热数据分区被迁移到温数据分区、冷数据分区，最终会被迁移到归档数据分区(仅保存但通常不
会被访问)。
[0211]
可选地，在系统运行时，管理用户可随时更改或者系统自动动态调整冷热等级的划分标准，无需进行停机。当冷热等级的划分标准发生变化时，存储设备的后台线程会根据负载情况来对自身的分区情况进行调整。例如，增加一个分区时，先添加相应的新分区，然后对相邻分区的数据进行调整；又例如，减少一个分区时，虽然减少了一个已有分区，但是并不会删除被减少的分区中存储的数据，因此需要将被删除的分区内的数据迁移到相邻的分区中之后，再删除被指定的分区；又例如，修改一个分区时，后台线程会将不符合当前分区的划分标准的数据迁移到相邻分区中，例如将温数据分区的划分标准从访问次数小于100次修改为访问次数小于90次，那么在温数据分区中，原本访问次数在90～100之间的数据将需要迁移到热数据分区中。
[0212]
以下，对数据记录的可见性判断算法进行介绍。
[0213]
由于全时态数据库中对每个数据记录都引入了时间维度，因此olap集群中计算设备的查询计算模型也需要进行重构，以提供本技术实施例的高效、低资源使用率的实时分析计算能力，并且支持提供一个基于时间窗粒度的流式计算引擎的基础查询执行模型。
[0214]
关系型数据库通常提供的数据服务，都会转变为对于用户提交的sql语句的处理，由于历史态数据不允许被修改或删除，是只读数据，因此本技术实施例涉及的计算语句只有查询(select)语句，其他的增删改语句都只需要按照sql：2011时态标准中关于数据提取的语义实现即可。因此，由于select语句一定会涉及到判断数据记录的可见性，因此下面将描述数据记录的可见性判断算法。
[0215]
图8是本技术实施例提供的一种全时态的数据记录的存储形态原理图，如800所示，横轴代表时间轴，从左到右代表时间流逝，以数据库中存储的记录1、记录2和记录3为例，说明从t1～t4这四个时刻下各条记录的可见版本。
[0216]
记录1(record 1，r1)：r1是在时间轴的最左侧插入数据库的，插入时的插入版本为v1，在t1之前的某个时刻r1被修改，因此第一条线段代表r1.v1(r1的v1版本)的生命周期，该生命周期代表了对应版本的有效时间，这一有效时间可基于用户定义的有效时间来决定，也可以基于数据的事务时间来决定。接下来的三条线段分布代表r1.v2、r1.v3、r1.v4各自的生命周期。
[0217]
分析可知，在t1时刻，r1的可见版本为v2；在t2时刻，v2版本正好结束，由于时间连续性，v3版本的生命周期的左端值等于v2版本的生命周期的右端值，因此t2时刻，r1的可见版本为v3；在t3时刻，仍然处于v3的生命周期内，因此r1的可见版本为v3；在t4时刻，处于v4的生命周期内，因此r1的可见版本为v4。
[0218]
记录2(record 2，r2)：r2在整个时间轴上表现为一条射线，代表r2在时间轴的最左侧插入数据库之后，没有被修改过，一直处于r2.v1版本。
[0219]
分析可知，在t1、t2、t3和t4时刻下，r2的可见版本均为v1。
[0220]
记录3(record 3，r3)：r3在t1时刻之后插入数据库，因此t1时刻时还没被插入，t1时刻不可见，然后在t1时刻和t2时刻之间的某个时刻被删掉了，因此在t2时刻之后已被删除，t2时刻之后也不可见。
[0221]
分析可见，在t1、t2、t3和t4时刻下，r3均不可见。
[0222]
在一些实施例中，数据记录的每个版本的生命周期采用一个左闭右开的时间区间
来标识，例如，r1.v1[2020-08-09 12:30:30,2020-08-19 22:15:30)表示记录r1在2020-08-09 12:30:30插入，并在2020-08-19 22:15:30失效。
[0223]
下面对单一时刻(即某一时间点)的数据可见性判断算法进行说明：
[0224]
在t1时刻，假设一个查询事务来扫描数据，在t1时刻对该查询事务来说，可见的数据记录为r1.v2和r2.v1，由于记录r3在t1时刻尚未插入，因此记录r3还不存在，自然也不可见。
[0225]
在t2时刻，假设一个查询事务来扫描数据，在t2时刻对该查询事务来说，可见的数据记录为r1.v3和r2.v1，由于记录r3在t2时刻之前已被删除，因此记录r3数据不存在，自然也不可见。需要说明的是，由于数据记录的每个版本的生命周期具有左开右闭的区间属性，因此t2时刻下r1.v3可见。
[0226]
在t3时刻，假设一个查询事务来扫描数据，在t3时刻对该查询事务来说，可见的数据记录为r1.v3和r2.v1，记录r3已经被删除因此不可见。
[0227]
在t4时刻，假设一个查询事务来扫描数据，在t4时刻对该查询事务来说，可见的数据记录为r1.v4和r2.v1，记录r3已经被删除因此不可见。
[0228]
通过上述单一时刻的数据可见性判断算法，可知每个时间点上的查询事务只能看到某条数据记录的一个版本，但有一些查询事务并非是针对时间点发起的，而是有可能指定了一个查询时间段，因此，下面对某一时间段(即查询时间段)的数据可见性判断算法进行说明：
[0229]
假设某一查询时间段划分为如下的4个连续的时间段：[min_time,t1)，[t1,t3)，[t3,t2)，[t2,current_time]，如果某一个查询事务指定了一个查询时间段(或称为有效时间区间、事务时间区间等)，那么针对该查询时间段，数据记录的可见性判断算法如下。
[0230]
示意性地，假设查询事务的select query语句为：
[0231]
select sum(a)from t1 for system_time from time1 to time2 where a》1；
[0232]
其中，time1是指上述查询时间段的左端值(即min_time)，time2是指上述查询时间段的右端值(即current_time)。
[0233]
对于单个时间段来说，其可见性判断算法表达为：确定单个时间段的右端值，在该单个时间段的右端值上按照单一时刻的数据可见性判断算法，来判断出相对该单个时间段可见的数据版本。
[0234]
对于单个时间段拆分为多个时间段组合的情况，比如将单个时间段[min_time,current_time]拆分为[min_time,t1)、[t1,t3)、[t3,t2)和[t2,current_time]这4个时间段，也即[min_time,current_time]-》[min_time,t1)，[t1,t3)，[t3,t2)，[t2,current_time]。
[0235]
此时，对该多个时间段中最左端的时间段，按照单一时间段的可见性判断算法来判断出可见的数据版本；对该多个时间段中最右端的时间段，查找到每个数据记录最新可见的记录版本值，并找到最左端的记录版本值，再对这两个版本的数据记录执行一个多层次查询结果的修正算法，来保证查询结果的正确性；在最右端的时间段为左闭右开区间的情况下，如果上述最右端的时间段中看到的版本与上述最左端的时间段中看到的版本一致，则跳过本数据记录，视本数据记录为不可见，在最右端的时间段为闭区间的情况下，这个时候以最右端的时间段的右端值下的可见版本作为本条记录的可见值。
[0236]
在上述相关内容的支持基础上，在本技术实施例中将详细介绍htap系统或htasp系统中olap集群中的计算设备如何基于实时分析模型来提供高效的实时分析性能。
[0237]
图9是本技术实施例提供的一种事务处理方法的流程图。参见图9，该实施例适用于htap系统、htasp系统或者区块链系统等支持实时分析的数据处理系统，该事务处理方法由olap集群中的任一计算设备执行，该实施例包括下述步骤：
[0238]
901、计算设备解析用户请求，得到该用户请求对应的目标事务的数据查询条件、分析语义和查询时间段。
[0239]
在一些实施例中，计算设备接收应用客户端的任一用户请求，解析该用户请求的头字段，当该头字段指示该用户请求为分析型事务时，解析该用户请求的数据字段，得到该用户请求中携带的sql语句(例如select query语句等)，将该sql语句到查询解析器中，通过该查询解析器对该sql语句进行词法分析、句法分析、时态翻译和语义检查，得到该sql语句的数据查询条件和分析语义(比如，求和、求平均、排序等)，另外，如果sql语句中指定了查询时间段的开始时刻，则获取该开始时刻，如果sql语句中指定了查询时间段的结束时刻，则获取该结束时刻。接着，基于该sql语句构建对应的该目标事务，计算设备为该目标事务创建一个进程或线程，或者复用已创建的某个进程或线程，并通过该进程或线程来处理该目标事务。
[0240]
示意性地，当该目标事务指定了该查询时间段的开始时刻时，则以目标事务指定的开始时刻为准，当该目标事务未指定该查询时间段的开始时刻时，可选地，以目标事务所查询的数据的最新版本的生效时刻为准，也即将符合该数据查询条件的数据的最新版本的生效时刻确定为该开始时刻，当涉及到查询多个数据的时候，对每个数据都以各自最新版本的生效时刻来选择对应的可见版本进行分析即可，可选地，以目标事务所查询的数据的插入版本的生效时刻为准，也即将符合该数据查询条件的数据的插入版本的生效时刻确定为该开始时刻，当涉及到查询多个数据的时候，对每个数据都以各自插入版本的生效时刻来选择对应的可见版本进行分析即可，本技术实施例对开始时刻的确定方式不进行具体限定。
[0241]
示意性地，当该目标事务指定了该查询时间段的结束时刻时，则以目标事务指定的结束时刻为准，当该目标事务未指定该查询时间段的结束时刻时，可选地，获取数据库系统内的实时程度参数，该实时程度参数用于表征数据库系统内的分析型事务处理的数据所支持的最大延时，换言之，该数据库系统可允许使用多久之前的历史态数据来进行分析，比如，设定实时程度参数为1小时，则代表数据库系统允许以1小时之前的历史态数据来进行分析。可选地，该实时程度参数由管理用户来进行自定义设置，如果管理用户没有设置过实时程度参数，则采用数据库系统的默认值(例如1秒)，其中该默认值也是可以进行修改的，本技术实施例对此不进行具体限定。在获取到实时程度参数之后，基于该实时程度参数来确定该结束时刻，可选地，将当前时刻之前距离该当前时刻达到实时程度参数的时刻确定为该结束时刻，本技术实施例不对结束时刻的确定方式进行具体限定。
[0242]
在基于上述方式确定了开始时刻和结束时刻之后，即可得到从开始时刻到结束时刻所构成的查询时间段，可选地，该查询时间段是一个闭区间，即该查询时间段既包括左端点的开始时刻也包括右端点的结束时刻，或者，该查询时间段是一个左闭右开的时间区间，即该查询时间段包括左端点的开始时刻，但不包括右端点的结束时刻，其中，左闭右开的时
间区间的特定在于：对于开始时刻来说，恰好在开始时刻生效的数据是可见的，对于结束时刻来说，恰好在结束时刻生效的数据是不可见的，这一点是用于判断辅助数据的可见性。可选地，由用户指定该查询时间段是否包含右端点的结束时刻，如果指定包含该结束时刻，则该查询时间段为闭区间，如果指定不包含该结束时刻，则该查询时间段为左闭右开的时间区间，如果用户未指定是否包含该结束时刻，可默认包含该结束时刻，即默认该查询时间段为闭区间。
[0243]
902、计算设备从该查询时间段中确定第一时刻，该第一时刻为对符合该目标事务的数据查询条件的历史态数据最近一次完成转储的时刻。
[0244]
在一些实施例中，计算设备在确定该查询时间段和该数据查询条件之后，由于oltp集群会周期性地将自身交易型事务所产生的历史态数据迁移到存储集群的存储设备中进行持久化存储，上述迁移历史态数据的过程就是对历史态数据进行转储的过程，由于每次进行转储时通常会产生相关的记录，比如记录一下上一次同步的日志的位点(checkpoint)，或者在存储集群的元信息管理器中记载本次转储的历史态数据有哪些，或者专门维护一张表来记录每次转储的完成时间，因此很容易能够查询到所有符合该目标事务的数据查询条件的历史态数据最近一次完成转储的时刻(即第一时刻)。
[0245]
需要说明的是，上述对历史态数据进行转储的过程，可基于之前实施例中涉及的在主从副本机制上增加的实时分析从副本，从而能够降低历史态数据转储任务对oltp集群内交易性能的影响。
[0246]
903、计算设备查询是否缓存对第二时刻可见的第一历史态数据的中间分析结果，该第二时刻为该查询时间段的开始时刻到该第一时刻之间的任一时刻。
[0247]
在一些实施例中，以第一时刻为界限，可将查询时间段划分为两个子区间，从开始时刻到第一时刻构成的第一子区间[开始时刻,第一时刻)，和从第一时刻到结束时刻构成的第二子区间[第一时刻,结束时刻]，将第一子区间的全量分析结果和第二子区间的增量分析结果进行合并，即可得到最终的目标分析结果。换言之，将一个查询时间段的分析工作，划分为针对两个子区间(即两个时间段)的分析工作。需要说明的是，本技术实施例以第二子区间为闭区间为例进行说明，但可由用户指定该查询时间段是否包含右端值的结束时刻，如果指定包含该结束时刻，则该第二子区间为闭区间，如果指定不包含该结束时刻，则该第二子区间为左闭右开区间，如果用户未指定是否包含该结束时刻，可默认包含该结束时刻，即默认第二子区间为闭区间。
[0248]
在一些实施例中，由于数据库系统内可能会缓存有从开始时刻到第一时刻之间的第二时刻下的中间分析结果，根据可见性判断算法，如果查询时间段被划分为超过两个时间段，那么只需要考察最左端的时间段和最右端的时间段，就能够判断出数据记录的可见版本，从而在可见版本上进行分析和处理。因此，如果以第一时刻和第二时刻为界限，将查询时间段划分为三个子区间：[开始时刻,第二时刻)、[第二时刻,第一时刻)、[第一时刻,结束时刻]，只需要将已缓存的[开始时刻,第二时刻)的中间分析结果和第二子区间[第一时刻,结束时刻]的增量分析结果进行合并，即可得到最终的目标分析结果，即无需重复计算出第一时刻下的全量分析结果。
[0249]
在一些实施例中，计算设备在查询该中间分析结果时，根据该目标事务的数据查询条件，确定出之前的历史事务是否针对相同的数据查询条件进行过分析，如果未命中之
前任一历史事务的数据查询条件，进入下述步骤904-b；如果命中之前任一历史事务的数据查询条件，则从缓存区中以被命中的该历史事务的事务id(identification，标识)为索引，查询是否缓存有与该索引对应的全量分析结果，如果命中任一已缓存的全量分析结果，将被命中的全量分析结果确定为该中间分析结果，进入下述步骤904-a，如果未命中所有缓存的全量分析结果，则确定未缓存该中间分析结果，进入下述步骤904-b。
[0250]
在一些实施例中，在查询是否缓存对第二时刻可见的第一历史态数据的中间分析结果之后，在已缓存该中间分析结果的情况下，执行下述步骤904-a；在未缓存该中间分析结果的情况下，执行下述步骤904-b。
[0251]
在上述过程中，通过判断是否缓存了中间分析结果，能够在已缓存有中间分析结果的情况下，避免重复计算出第一时刻下的全量分析结果，因此能够大大节约计算设备的计算资源。
[0252]
904-a、在已缓存该中间分析结果的情况下，计算设备将该中间分析结果确定为全量分析结果。
[0253]
也即是说，如果缓存了从开始时刻到第一时刻之间任一第二时刻的中间分析结果，那么直接将以该中间分析结果作为全量分析结果，而无需对全量分析结果进行冗余计算，能够大大节约计算设备的计算资源。
[0254]
904-b、在未缓存该中间分析结果的情况下，计算设备生成对该第一时刻可见的第二历史态数据的全量分析结果。
[0255]
在一些实施例中，如果未缓存该中间分析结果，那么计算设备需要运用单一时间段可见性判断算法，从该历史态数据中，判断出对第一子区间[开始时刻,第一时刻)可见的第二历史态数据，也即是说，仅针对第一子区间[开始时刻,第一时刻)的右端值第一时刻，执行单一时刻的可见性判断算法，从而确定出该第二历史态数据。
[0256]
在从各个版本的历史态数据中，确定出第二历史态数据之后，基于上述步骤901中解析得到的分析语义，对该第二历史态数据进行该分析语义所对应的处理，得到该全量分析结果。比如，分析语义为对某个字段值求平均值，那么需要对各个第二历史态数据对应字段的value值求平均值，又例如，分析语义为对某个字段值求和，那么需要将各个第二历史态数据对应字段的value值相加，以获取相加得到的和值。
[0257]
在上述步骤903-904a或904b中，计算设备基于该历史态数据，获取全量分析结果，该全量分析结果为基于该目标事务的分析语义对该历史态数据进行处理所得的结果，从而能够将步骤904-a或904-b的全量分析结果与下述步骤905的增量分析结果合并，得到最终的目标分析结果，即将单层计算模型转换为全量+增量的双层计算模型。
[0258]
在一些实施例中，由于htap系统或htasp系统的存储集群可按照冷热等级的划分标准，划分为对应的分区，并在各个分区内的存储设备中存储对应冷热等级的历史态数据。换言之，冷热等级不同的历史态数据存储在不同的存储设备或者同一存储设备的不同存储介质中。因此，计算设备在读取该第二历史态数据时，先确定该第二历史态数据的冷热等级，该冷热等级用于表征在目标时间段内对在该第二历史态数据上发生操作的频繁程度；再从与该冷热等级对应的存储设备中，读取该第二历史态数据。
[0259]
在一些实施例中，计算设备在确定该第二历史态数据的冷热等级时，获取该目标时间段内对该第二历史态数据的访问次数，获取该目标时间段内对该第二历史态数据对应
的当前态数据的修改次数，基于该访问次数和该修改次数，确定该冷热等级。其中，该目标时间段是指管理用户设定的当前数据库下冷热等级的划分标准中需要判断的时间段(例如1天、1月、1年等)。
[0260]
可选地，由于在介绍上述冷热等级的划分标准时，提到过对全时态数据库中所有的当前态数据，增加一个修改标记信息来统计修改次数，此外，对所有的当前态数据、过渡态数据和历史态数据，都增加一个访问标记信息来统计访问次数，因此，只要对每个第二历史态数据(实际上是在第一时刻下该历史态数据的可见版本)，查询该第二历史态数据对应的当前态数据的修改标记信息，即可得到该修改次数，查询该第二历史态数据自身的访问标记信息，即可得到该访问次数。
[0261]
可选地，在获取到访问次数和修改次数之后，基于当前数据库的冷热等级的划分标准，查看该访问次数和修改次数落入到哪一种冷热等级的划分标准下的取值区间中，即可确定出该第二历史态数据的冷热等级。
[0262]
905、计算设备基于从该第一时刻起至该查询时间段的结束时刻之间在该历史态数据对应的当前态数据上发生的变更，获取增量分析结果，该增量分析结果为基于该分析语义对该变更得到的数据进行处理所得的结果。
[0263]
由于第一时刻是对应的历史态数据最近一次完成转储的时刻，那么代表第一时刻起到结束时刻之间的数据都尚未从oltp集群转储到存储集群中，因此，需要先从oltp集群中获取到对应变更产生的日志，对变更产生的日志进行回放，获取到对应变更得到的数据，接着，比较主键标识相同的历史态数据和变更得到的数据，并按照目标事务的sql语句的分析语义对比较结果进行处理，生成该增量分析结果。其中，该增量分析结果只代表与上一次全量分析结果之间发生的变化，而并非是新一次计算所得的全量分析结果。
[0264]
在上述过程中，通过对变更得到的数据仅获取增量分析结果，而无需获取全量分析结果，由于增量分析结果所需分析的数据量较少、且耗时较少，因此能够大大节约计算设备的计算开销和处理资源。
[0265]
在一些实施例中，该增量分析结果包括变更前的分析结果和变更后的分析结果，计算设备在比较主键标识相同的历史态数据和变更得到的数据的时候，需要先对主键标识相同的历史态数据和变更得到的数据，确定发生变更的字段，需要说明的是，这里主键标识相同的历史态数据和变更得到的数据，是指针对具有该主键标识的数据记录在不同时刻进行变更时产生的不同版本，比如，对记录r1的历史态v1版本和最新变更得到的v4版本，确定发生变更的字段。
[0266]
进一步的，在确定发生变更的字段的基础上，如果该数据查询条件不涉及该发生变更的字段，代表目标事务所查询的字段没有变化，因此可跳过具有该主键标识的数据，比如，如果记录r1的v1版本和v4版本之间发生变化的是字段c1，而其余字段没有变化，此时数据查询条件所查询的是字段c2，代表第一时刻到结束时刻之间没有增量变化，那么直接跳过记录r1即可；如果该数据查询条件涉及该发生变更的字段，那么需要分别计算一个变更前的分析结果和一个变更后的分析结果，也即是说，对该第一时刻可见的第二历史态数据，生成该变更前的分析结果，对该结束时刻可见的变更得到的目标数据，生成该变更后的分析结果，例如，如果记录r1的v1版本和v4版本之间发生变化的是字段c1，恰好数据查询条件所查询的也是字段c1，那么记录r1需要参与到增量计算中，因此，在统计到所有需要参与增
量计算的记录之后，需要对各个记录的字段c1的旧值计算变更前的分析结果，对各个记录的字段c1的新值计算变更后的分析结果。
[0267]
906、计算设备基于该全量分析结果和该增量分析结果，获取该目标事务的目标分析结果。
[0268]
在一些实施例中，该增量分析结果包括变更前的分析结果和变更后的分析结果，因此，在合并全量分析结果和增量分析结果时，需要将该全量分析结果减去该变更前的分析结果，得到第一分析结果；将该第一分析结果加上该变更后的分析结果，得到该目标分析结果。
[0269]
在上述过程中，通过全量计算和增量计算结合以获取最终分析结果的方式，能够将传统的单层计算模型转换为两层实时分析模型，能够适配于基于全时态数据库的htap系统或htasp系统，且能够节约整个系统内的计算资源。
[0270]
上述所有可选技术方案，能够采用任意结合形成本公开的可选实施例，在此不再一一赘述。
[0271]
本技术实施例提供的方法，通过针对目标事务确定查询时间段，并以第一时刻作为查询时间段内的一个时间点分界线，对第一时刻之前的历史态数据计算出一个全量分析结果，对第一时刻之后变更得到的数据计算出一个增量分析结果，将全量分析结果和增量分析结果两者结合，最终得到目标分析结果，使得针对全时态的时间轴上的任一个查询时间段，都能够提供在线实时分析和处理服务，而并不局限于仅对最新数据提供分析功能，从而大大提升了htap系统或htasp系统等数据库系统的事务处理性能。
[0272]
进一步的，通过全量计算和增量计算结合以获取最终分析结果的方式，能够将传统的单层计算模型转换为两层实时分析模型，能够适配于基于全时态数据库的htap系统或htasp系统，且能够节约整个系统内的计算资源。
[0273]
在上述实施例中，详细介绍了htap系统或htasp系统等数据库系统的事务处理流程，而在本技术实施例中，将结合一个具体的数据查询语句，来详细描述olap集群中的计算设备是如何通过实时分析模型来获取目标分析结果的。
[0274]
图10是本技术实施例提供的一种实时分析模型的原理性流程图，如1000所示，将介绍在实时程度参数real_time_analyzing degree设置为1秒的情况下，系统某一时刻进来一条数据查询语句(即目标事务为查询事务)，计算设备会如何对该数据查询语句进行处理。假设该数据查询语句为：
[0275]
select sum(a)from t1 where a》1；
[0276]
在一些实施例中，用户可在该数据查询语句中增加对应的时间语法来限定查询的目标数据集，假设用户和一些通常的分析查询一样没有对设置任何时间态信息，那么本条数据查询语句的在线实时分析流程(即实时计算算法)包括：
[0277]
步骤1、开始执行分析查询。
[0278]
在步骤1中，需要针对该查询事务进行事务时间范围的增加，例如，首先，确定实时程度参数real_time_analyzing_degree的值，即确定用户对于olap集群的实时性要求(假设real_time_analyzing_degree设置为1秒)，即可将该数据查询语句修改为：
[0279]
select sum(a)from t1 for system_time from min_time to current_time
–
real_time_analyzing_degree where a》1；
[0280]
其中，min_time是指查询时间段的开始时刻，current_time是指当前时刻，current_time
–
real_time_analyzing_degree是指查询时间段的结束时刻。
[0281]
步骤2、判断是否在warm层有一个中间计算(即中间分析结果)？如果warm层有中间计算，进入步骤4；如果warm层没有中间计算，进入步骤3。
[0282]
在开始执行查询分析前，先判断一下之前是否有保存的warm层的中间计算结果(即中间分析结果)，这里warm层是指温数据所在的存储分区，即在存储集群中温数据所在分区下的存储设备中查询是否缓存该中间分析结果。
[0283]
需要说明的是，基于上述4层冷热等级的划分方式，通常实时分析的查询事务发生在hot和warm层(即大部分分析型事务都需要访问热数据和/或温数据)，cold和archive层数据主要是用来分离存储过旧的历史态数据(即分析型事务通常不会访问冷数据和/或归档数据，这些冷数据和/或归档数据只是为了分离出来以减轻存储压力)。
[0284]
步骤3、分两段查询执行，进入步骤7。
[0285]
如果warm层中没有中间分析结果，代表之前的查询事务没有执行过对应数据的分析任务，或者之前的查询事务虽然执行了对应数据的分析任务，但是用户没有选择保存中间分析结果，因此，需要重新生成一个warm层的全量分析结果。
[0286]
换言之，将上述数据查询语句中的单个查询时间段[min_time,current_time
–
real_time_analyzing_degree]转换为如下两段时间段：[min_time,time1)和[time1,current_time
–
real_time_analyzing_degree]，其中，time1为由上述实施例中涉及的实时分析从副本通过数据转储程序，将主副本或其他从副本的实时数据通过后台线程转储到存储集群对应分区的存储设备上的最新时间段，也即，time1是指第一时刻(对符合该目标事务的数据查询条件的历史态数据最近一次完成转储的时刻)。需要说明的是，实时分析从副本中存储的数据中可能包括部分warm层的温数据(因为可能有一部分warm数据尚未转储完毕，但是并不影响对查询事务的分析计算)。
[0287]
步骤4、分三段查询执行，进入步骤5。
[0288]
如果warm层中有中间分析结果，那么将上述数据查询语句中的单个查询时间段[min_time,current_time
–
real_time_analyzing_degree]转换为如下三段时间段：[min_time,timew)，[timew,time1)和[time1,current_time
–
real_tim e_analyzing_degree],根据之前介绍的多个时间段的可见性判断算法，最终只需要对最左端的时间段[min_time,timew)和最右端的时间段[time1,current_ti me
–
real_time_analyzing_degree]这两个时间段进行计算。
[0289]
步骤5、直接获取之前保存的warm层的全量分析结果(即中间分析结果)，进入步骤6。
[0290]
步骤6、计算增量部分的增量分析结果，进入步骤8。
[0291]
换言之，计算[time1,current_time
–
real_time_analyzing_degree]这部分变更得到的数据的结果集，增量计算所操作的该变更得到的数据通常处于hot层(通常是热数据)，当然，如果用户对olap集群设置的实时程度参数real_time_analyzing_degree比较大，说明用户对实时性要求不高，那么可能会导致增量计算所操作的该变更得到的数据落入到warm层中，此时对该变更得到的数据的增量计算将完全在warm层中能够完成，而无需与oltp集群中hot层的相关tp计算节点进行交互，相当于本查询事务对于hot层的tp业务没
有任何影响，能够完全解耦。
[0292]
步骤7、并行计算warm层的全量分析结果和hot层的增量分析结果，进入步骤8。
[0293]
根据步骤3所介绍的，可并行启动对上述两个时间段各自的分析结果的计算流程，并行计算相较于串行计算具有更高的计算效果。
[0294]
首先，在warm层计算[min_time,time1)这一时间段的全量分析结果，并且，在计算得到该全量分析结果之后，如果用户设置保存该全量分析结果，那么将会在warm层中保存该全量分析结果，以备后续同类的查询事务参考，即将本次的全量分析结果缓存，以作为后续同类的查询事务在步骤2所查询的中间分析结果。可选地，warm层中可周期性地重新发起一次全量计算，避免由于长时间不进行全量计算，导致上一次的全量计算太旧，因此存在太多的数据变更导致所需要计算的数据集太大，所导致的查询性能降低的情况。
[0295]
其次，在hot层计算[time1,current_time
–
real_time_analyzing_deg ree]这一时间段内变更得到的数据的结果集(即增量分析结果)。
[0296]
步骤8、将warm层的全量分析结果和hot层的增量分析结果进行合并，得到目标分析结果。
[0297]
换言之，将worm层的全量分析结果和hot层变更得到的数据的结果集(即增量分析结果)进行合并，得到目标分析结果。
[0298]
步骤9、返回本次查询结果，即返回合并得到的目标分析结果。
[0299]
步骤10、实时分析结束。
[0300]
在本技术实施例中，通过对worm层的全量分析结果和hot层的增量分析结果进行合并，提供一种两段式的实时计算模型，能够最大程度的降低oltp集群和olap集群之间的耦合程度，即，olap集群在进行实时分析时，只需要通过实时分析从副本来扫描oltp集群hot层中发生变更的数据即可，并且，如果用户不需要很高的实时性，有可能warm层的温数据就能够满足实时分析的计算要求，此时就无需访问hot层中的热数据，这种情况下对oltp集群是完全解耦的，此外，由于warm层中缓存的中间计算结果是能够复用的，因此能够最大程度的节约计算资源。
[0301]
在上述实施例的步骤7和步骤8中，涉及到对变更得到的数据计算增量分析结果，以及最终将全量分析结果和增量分析结果进行合并，在本技术实施例中，将详细描述这部分增量分析结果的计算方式，和全量+增量分析结果的合并方式，下面进行说明。
[0302]
在实时计算模型中，将实时计算任务分解为全量+增量两层计算模式，通过在warm层生成一个全量分析结果，同时支持对该全量分析结果进行缓存以达到多次复用，来降低计算资源因为重复计算造成的浪费。同时，也因为将变更得到的数据这部分的计算量控制在一个合理的程度，使得整个系统的实时分析能力对用户呈现出最优表现，提高了用户体验。
[0303]
基于之前的针对多个时间段的可见性判断算法，可知worm层的全量计算的时间段是指多个时间段中最左端的时间段，hot层的增量计算的时间段是指多个时间段中最右端的时间段。
[0304]
首先，计算或者获取到warm层的全量分析结果，如果已缓存有中间分析结果，则直接获取该中间分析结果为全量分析结果，如果没有缓存中间分析结果，那么需要重新计算出一个全量分析结果。
[0305]
接着，对于变更得到的数据来说，由于需要分别计算变更前的分析结果和变更后的分析结果，变更前的分析结果是指各个记录的旧值，由于增量计算的时间段的左端值是第一时刻，因此上述旧值就是指在第一时刻的可见版本的相关字段值，变更后的分析结果是指各个记录的新值，由于增量计算的时间段的右端值是结束时刻(即当前时刻减去实时程度参数所得的时刻)，因此上述新值就是指在结束时刻的可见版本的相关字段值。需要说明的是，为了使得主键标识相同的数据记录的各个新旧版本相对于，可在计算时对每个版本都添加标识信息row_id，使得对同一条数据记录进行多次变更所得的各个版本都具有相同的row_id。对变更得到的数据中的任一条记录，确定该记录在第一时刻的可见版本和在结束时刻的可见版本，并确定两个可见版本之间发生变更的字段，然后执行如下操作：
[0306]
(a)如果发生变更的字段，在查询事务的数据查询语句中不使用，忽略本条记录；
[0307]
(b)如果发生变更的字段，和查询事务的数据查询语句相关，那么，针对每一条记录的旧值重新计算一个变更前的分析结果；针对每一条记录的新值重新计算一个变更后的分析结果。
[0308]
最后，将warm层的全量分析结果和(b)中对新旧值分别计算的变更前的分析结果和变更后的分析结果进行合并，也即，从warm层的全量分析结果中将(b)中变更前的分析结果减去，然后在对减去所得的分析结果加上(b)中变更后的分析结果，得到最终的目标分析结果，此时变更合并算法结束。
[0309]
在一些实施例中，在上述htap系统的基础上，还可提供高效的流式实时分析的计算能力，以将htap系统转换为htasp系统，从而达到最快速、最高效的完成实时分析计算，以将对系统内部计算资源的使用降到最低，从而提高系统的资源利用率。
[0310]
示意性地，针对上述目标事务，在流式计算引擎中，如果开启流式计算模式，假设目标事务的目标分析结果是流式计算中的第一个全量分析结果，那么，从该目标事务的查询时间段的结束时刻开始，每间隔第一目标时长(即是指之前实施例涉及的时间窗大小)，获取一次该第一目标时长内发生变更的目标增量分析结果；缓存获取到的各个目标增量分析结果。进一步的，每间隔第二目标时长(即是指之前实施例涉及的全量分析结果的计算周期)，基于上一次的全量分析结果与该第二目标时长内产生的各个目标增量分析结果，获取本次的全量分析结果。
[0311]
下面，将对增量+全量的流式计算模型进行介绍。
[0312]
图11是本技术实施例提供的一种流式计算模型的数据记录的存储形态的原理性示意图，如1100所示，对每一条数据记录，随着事务对数据记录的变更操作，会保存整个时间轴上变更得到的各个版本，因此，通过一个个的时间窗，能够在时间轴上将数据记录的各个版本框在各自所属的时间窗内，其中，时间窗大小即第一目标时长可由之前实施例涉及的扩展命令来进行设置和查看，对每个时间窗内数据记录的可见版本进行增量计算，得到目标增量分析结果，此外，可基于全量分析结果的计算周期即第二目标时长，能够每间隔该计算周期划分一条时间线，并合并相邻的两条时间线中的各个时间窗内的所有目标增量分析结果，最终得到本次的全量分析结果。全量分析结果和增量分析结果的计算方式与之前实施例中的计算方式相同，这里不再赘述。
[0313]
图12是本技术实施例提供的一种htasp系统的实施环境架构图，如图12所示，在该实时分析系统中，包含计算层1210和分层分布式共享存储系统1220，在计算层1210中包括
oltp集群1211、olap集群1212和流式计算集群1213，oltp集群1211通常针对在当前态数据和过渡态数据上发起的短时交易型事务提供在线交易功能，olap集群1212通常针对在历史态数据上发起的复杂分析型事务提供在线分析功能。其中，流式计算集群1213可集成在olap集群1212内部，比如，对olap集群1212中的部分或全部ap计算节点加载流式计算引擎，以同时提供常规分析功能和流式分析功能。流式计算集群1213用于基于上述流式计算模型，定期进行增量计算和全量计算，从而源源不断输出连续时间段内的全量分析结果和实时分析结果，使得整个htasp系统具有很高的事务分析性能。
[0314]
oltp集群1211、olap集群1212和流式计算集群1213三者均能够访问到分层分布式共享存储系统1220中存储的全时态数据，示意性地，按照全时态数据的冷热等级，将系统内所有的数据划分为如下几种分区：热数据、温数据、冷数据、归档数据等，之前已经对冷热等级的划分标准进行过介绍，这里不再赘述。
[0315]
由于在流式计算模型中，是定期进行全量分析结果的获取，并在相邻的两次全量计算之前，以时间窗为单元来不断进行增量分析结果的获取，但由于需要不断进行全量+增量的流式计算，因此，可选地，针对用户指定了进行流式计算的分析型事务才提供流式计算功能，例如，用户在数据查询语句中添加stream字段以指定开始流式计算。
[0316]
在一些实施例中，可由系统宏观分析各个用户发起的查询事务的规律，如果用户每间隔一段时间就会发起某一类相似的查询事务(比如每个月的还款日之前查询本月总的账单流水)，那么可按照时间维度，根据用户发起的历史查询事务和历史查询事务所查询的数据特征，来创建针对该用户的查询业务的流式计算模型。在流式计算模型中，通过全量分析结果的计算周期将全时态数据进行第一层次的划分，在每个计算周期内，对各个变更得到的数据，按照查询的数据特征进一步细化出多个时间窗来进行增量分析结果的计算，从而提升计算能力的水平扩展性。需要说明的是，如果一个计算周期内的数据变更不多的话，那么可对本计算周期划分较少的时间窗或者不划分时间窗，而是直接对两个计算周期内的所有变更得到的数据进行增量计算。
[0317]
示意性地，流式计算模型包括如下步骤：
[0318]
步骤1、启动流式计算。
[0319]
例如，第一个时间窗为实时计算的最左端的时间段，即流式计算的发起事务所指定的查询时间段中最左端的时间段，此时对该发起事务会计算出第一个启示的全量分析结果。
[0320]
步骤2、对后续的每一个时间窗，判定可见的数据变更集合(即本时间窗内的变更操作所得的数据构成的集合)，并对数据变更集合计算增量分析结果，但不做合并操作。
[0321]
步骤3、每当到达全量分析结果的计算周期时，基于上一次的全量分析结果，和从上一次全量分析结果到当前时刻之间产生的所有增量分析结果，依次进行合并，得到本次的全量分析结果。
[0322]
步骤4、当用户针对正在进行流式计算的相关数据发起新到的查询事务时，首先，找到最近的一次全量分析结果作为基础，接着，对该上一次的全量分析结果，依次合并之后的所有完整的时间窗的增量分析结果，最后，再合并从最后一个时间窗开始到下发该查询事务的时刻之间发生变更得到的数据的增量分析结果(这部分数据的时间跨度小于一个时间窗，因此需要单独计算)。
[0323]
步骤5、返回新到的查询事务的合并结果。
[0324]
在本技术实施例中，流式分析算法能够将实时分析计算转变为以时间窗为单位的少量的增量计算，并且随着时间窗的后移，和将任意计算周期内的各个增量分析结果与上一次的全量分析结果合并，得到新一次的全量分析结果，从而能够以较为稳定可预估的常数执行时间，来完成用户已经构建了流式计算的实时分析结果，并且，流式计算的计算效率不会因为数据量的增大而发生变化，几乎能够保持在一个很小且稳定的执行时间内，同时可根据系统资源的忙闲程度，与用户发起查询业务的周期变化，来自动调整时间窗和计算周期的大小，来进一步地优化htasp系统的资源使用效率。
[0325]
在上述各个实施例中，分别介绍了htap系统、htasp系统对分析型事务的处理流程，主要涉及全量+增量两层计算模型和流式计算模型，而在一些实施例中，在根据冷热等级的划分标准，将全时态数据划分为不同冷热程度的数据之后，还可基于数据的冷热程度，来优化存储集群的存储模型。
[0326]
图13是本技术实施例提供的一种冷热数据的访问量比例和数据量分布的统计图，如1300所示，可发现，一个月内8％的活跃数据量，承担了91％的访问量，而一年以外的冷数据的访问量只占用了全部访问量的1％。因此，为了更好地构建基于全时态数据库的htap系统或htasp系统的分布式架构，使得系统能够持续对外提供稳定的访问质量，可根据数据的冷热等级的不同，将具有不同访问频率的数据存储在不同级别的存储介质中，从而既能够达到用户的sla性能要求，又能够降低数据库的存储成本，从而提供高品质、低成本的存储解决方案。
[0327]
示意性地，针对热、温、冷、归档这4类数据采取如下的4层存储模型：
[0328]
热数据：存储在增强型ssd(solid state disk，固态硬盘)磁盘中，并基于raft一致性协议保存一个主副本和两个从副本，确保数据的高可用性和高可靠性；
[0329]
温数据：存储在ssd磁盘中，并基于raft一致性协议保存一个主副本和两个从副本，确保数据的高可用性和高可靠性；
[0330]
冷数据：使用cos(cloud object storage，云对象存储)方式进行云存储，sata(serial advanced technology attachment，串行ata即串口硬盘)盘是一种廉价的存储设备，可以纠删码的方式进行冗余存储，提高12个9的可靠性。其中，12个9的可靠性是指：由于在每条记录存储的时候增加了纠删码，使得记录不需要存储多个副本也能够保持高容错、不丢失的效果，由于只增加了一些冗余校验来减少历史态数据的容量综合，因此带来了99.9999999999％的可靠性，即指存在0.0000000001％的丢失数据的概率，并且即便磁盘出现坏道，也可以根据上述纠删码来计算其余部分，从而算出来出错部分的内容。
[0331]
归档数据：使用cas(content-addressable storage，内容寻址存储)方式进行云存储，sata盘是廉价的存储设备，能够以极低成本保存归档数据，并采用纠删码方式替代多副本方式，能够提高存储密度，并使用可编程关闭电源的硬盘。
[0332]
基于上述存储模型，用于可根据自身业务特定，灵活设定冷热等级的划分标准hot_cold_data_level参数，从而为对应冷热等级的数据配置合适的存储介质。
[0333]
在上述各个实施例中，基于全时态数据库构建了一种能够支持对任意时间段的在线分析功能的htap系统，且在htap系统的基础上提供流式计算能力即htasp系统，通过对全态数据的时间维度的充分利用，能够有效将oltp集群和olap集群解耦，使得oltp集群在主
副本上对最新数据提供在线交易和分析功能，olap集群在实时分析从副本和历史态数据上提供在线分析和处理功能，使得两个集群针对同一份数据能够相互独立地计算和运行。此外，管理用户可根据自己的业务需求，确定在线分析的实时程度参数，从而既能够满足业务需求，又能够量化oltp集群和olap集群之间允许的最大延时。
[0334]
进一步的，引入了全量+增量计算的实时分析模式，能够最大程度节约计算资源的使用，以达到最好的实时分析效果，并且，由于时间态是针对每一条记录级别的，从而能够以记录粒度的时间态，对各个记录增加时间窗维度的划分，以结合原有的数据特征对外提供流式计算能力，从而达到记录级别的最小粒度的任务划分，提升了计算效率。
[0335]
进一步的，用户可自定义冷热等级的划分标准，以提升数据库系统整体的服务能力，并通过多级不同存储设备不同存储介质的分区存储，降低了数据库系统整体的使用成本，由于全时态数据每次修改都会产生一条对应的历史记录(即历史态数据)，利用这一特性，如果一定时间内数据记录没有发生修改，只需要将历史态数据(冷数据)转储到更加廉价、低速的存储设备上，即能够实现在数据库系统内既保存全量历史态数据，又能够将冷数据与热数据分离，保证了系统处理性能的稳定性，同时数据库的使用成本能够以一个较低的增幅，来匹配数据的爆炸式增长。
[0336]
图14是本技术实施例提供的一种事务处理装置的结构示意图，请参考图14，该装置包括：
[0337]
确定模块1401，用于从目标事务的查询时间段中确定第一时刻，该第一时刻为对符合该目标事务的数据查询条件的历史态数据最近一次完成转储的时刻；
[0338]
第一获取模块1402，用于基于该历史态数据，获取全量分析结果，该全量分析结果为基于该目标事务的分析语义对该历史态数据进行处理所得的结果；
[0339]
第二获取模块1403，用于基于从该第一时刻起至该查询时间段的结束时刻之间在该历史态数据对应的当前态数据上发生的变更，获取增量分析结果，该增量分析结果为基于该分析语义对该变更得到的数据进行处理所得的结果；
[0340]
第三获取模块1404，用于基于该全量分析结果和该增量分析结果，获取该目标事务的目标分析结果。
[0341]
本技术实施例提供的装置，通过针对目标事务确定查询时间段，并以第一时刻作为查询时间段内的一个时间点分界线，对第一时刻之前的历史态数据计算出一个全量分析结果，对第一时刻之后变更得到的数据计算出一个增量分析结果，将全量分析结果和增量分析结果两者结合，最终得到目标分析结果，使得针对全时态的时间轴上的任一个查询时间段，都能够提供在线实时分析和处理服务，而并不局限于仅对最新数据提供分析功能，从而大大提升了htap系统或htasp系统等数据库系统的事务处理性能。
[0342]
在一种可能实施方式中，基于图14的装置组成，该第一获取模块1402包括：
[0343]
查询单元，用于查询是否缓存对第二时刻可见的第一历史态数据的中间分析结果，该第二时刻为该查询时间段的开始时刻到该第一时刻之间的任一时刻；
[0344]
确定单元，用于在已缓存该中间分析结果的情况下，将该中间分析结果确定为该全量分析结果；
[0345]
第一生成单元，用于在未缓存该中间分析结果的情况下，生成对该第一时刻可见的第二历史态数据的该全量分析结果。
[0346]
在一种可能实施方式中，基于图14的装置组成，该第一生成单元包括：
[0347]
确定子单元，用于确定该第二历史态数据的冷热等级，该冷热等级用于表征在目标时间段内对在该第二历史态数据上发生操作的频繁程度；
[0348]
读取子单元，用于从与该冷热等级对应的存储设备中，读取该第二历史态数据；
[0349]
处理子单元，用于基于该分析语义，对该第二历史态数据进行处理，得到该全量分析结果。
[0350]
在一种可能实施方式中，该确定子单元用于：
[0351]
获取该目标时间段内对该第二历史态数据的访问次数；
[0352]
获取该目标时间段内对该第二历史态数据对应的当前态数据的修改次数；
[0353]
基于该访问次数和该修改次数，确定该冷热等级。
[0354]
在一种可能实施方式中，冷热等级不同的历史态数据存储在不同的存储设备或者同一存储设备的不同存储介质中。
[0355]
在一种可能实施方式中，基于图14的装置组成，该第二获取模块1403包括：
[0356]
获取单元，用于基于该变更产生的日志，获取该变更得到的数据；
[0357]
第二生成单元，用于比较主键标识相同的历史态数据和变更得到的数据，生成该增量分析结果。
[0358]
在一种可能实施方式中，该增量分析结果包括变更前的分析结果和变更后的分析结果，该第二生成单元用于：
[0359]
对主键标识相同的历史态数据和变更得到的数据，确定发生变更的字段；
[0360]
如果该数据查询条件不涉及该发生变更的字段，跳过具有该主键标识的数据；
[0361]
如果该数据查询条件涉及该发生变更的字段，对该第一时刻可见的第二历史态数据，生成该变更前的分析结果；对该结束时刻可见的变更得到的目标数据，生成该变更后的分析结果。
[0362]
在一种可能实施方式中，该第三获取模块1404用于：
[0363]
将该全量分析结果减去该变更前的分析结果，得到第一分析结果；
[0364]
将该第一分析结果加上该变更后的分析结果，得到该目标分析结果。
[0365]
在一种可能实施方式中，该确定模块1401还用于：
[0366]
当该目标事务未指定该查询时间段的开始时刻时，将符合该数据查询条件的数据的最新版本的生效时刻确定为该开始时刻；
[0367]
当该目标事务未指定该查询时间段的结束时刻时，将当前时刻之前距离该当前时刻达到实时程度参数的时刻确定为该结束时刻，该实时程度参数用于表征数据库系统内的分析型事务处理的数据所支持的最大延时。
[0368]
在一种可能实施方式中，该第二获取模块1403还用于：
[0369]
从该结束时刻开始，每间隔第一目标时长，获取一次该第一目标时长内发生变更的目标增量分析结果；
[0370]
缓存获取到的各个目标增量分析结果。
[0371]
在一种可能实施方式中，该第三获取模块1404还用于：
[0372]
每间隔第二目标时长，基于上一次的全量分析结果与该第二目标时长内产生的各个目标增量分析结果，获取本次的全量分析结果。
[0373]
上述所有可选技术方案，能够采用任意结合形成本公开的可选实施例，在此不再一一赘述。
[0374]
需要说明的是：上述实施例提供的事务处理装置在处理事务时，仅以上述各功能模块的划分进行举例说明，实际应用中，能够根据需要而将上述功能分配由不同的功能模块完成，即将计算设备的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。另外，上述实施例提供的事务处理装置与事务处理方法实施例属于同一构思，其具体实现过程详见事务处理方法实施例，这里不再赘述。
[0375]
图15是本技术实施例提供的一种计算设备的结构示意图，如图15所示，以计算设备为终端1500为例进行说明。可选地，该终端1500的设备类型包括：智能手机、平板电脑、mp3播放器(moving picture experts group audio layer iii，动态影像专家压缩标准音频层面3)、mp4(moving picture experts group audio layer iv，动态影像专家压缩标准音频层面4)播放器、笔记本电脑或台式电脑。终端1500还可能被称为用户设备、便携式终端、膝上型终端、台式终端等其他名称。
[0376]
通常，终端1500包括有：处理器1501和存储器1502。
[0377]
可选地，处理器1501包括一个或多个处理核心，比如4核心处理器、8核心处理器等。可选地，处理器1501采用dsp(digital signal processing，数字信号处理)、fpga(field－programmable gate array，现场可编程门阵列)、pla(programmable logic array，可编程逻辑阵列)中的至少一种硬件形式来实现。在一些实施例中，处理器1501包括主处理器和协处理器，主处理器是用于对在唤醒状态下的数据进行处理的处理器，也称cpu(central processing unit，中央处理器)；协处理器是用于对在待机状态下的数据进行处理的低功耗处理器。在一些实施例中，处理器1501集成有gpu(graphics processing unit，图像处理器)，gpu用于负责显示屏所需要显示的内容的渲染和绘制。一些实施例中，处理器1501还包括ai(artificial intelligence，人工智能)处理器，该ai处理器用于处理有关机器学习的计算操作。
[0378]
在一些实施例中，存储器1502包括一个或多个计算机可读存储介质，可选地，该计算机可读存储介质是非暂态的。可选地，存储器1502还包括高速随机存取存储器，以及非易失性存储器，比如一个或多个磁盘存储设备、闪存存储设备。在一些实施例中，存储器1502中的非暂态的计算机可读存储介质用于存储至少一个程序代码，该至少一个程序代码用于被处理器1501所执行以实现本技术中各个实施例提供的事务处理方法。
[0379]
在一些实施例中，终端1500还可选包括有：外围设备接口1503和至少一个外围设备。处理器1501、存储器1502和外围设备接口1503之间能够通过总线或信号线相连。各个外围设备能够通过总线、信号线或电路板与外围设备接口1503相连。具体地，外围设备包括：射频电路1504、显示屏1505、摄像头组件1506、音频电路1507、定位组件1508和电源1509中的至少一种。
[0380]
外围设备接口1503可被用于将i/o(input/output，输入/输出)相关的至少一个外围设备连接到处理器1501和存储器1502。在一些实施例中，处理器1501、存储器1502和外围设备接口1503被集成在同一芯片或电路板上；在一些其他实施例中，处理器1501、存储器1502和外围设备接口1503中的任意一个或两个在单独的芯片或电路板上实现，本实施例对此不加以限定。
[0381]
射频电路1504用于接收和发射rf(radio frequency，射频)信号，也称电磁信号。射频电路1504通过电磁信号与通信网络以及其他通信设备进行通信。射频电路1504将电信号转换为电磁信号进行发送，或者，将接收到的电磁信号转换为电信号。可选地，射频电路1504包括：天线系统、rf收发器、一个或多个放大器、调谐器、振荡器、数字信号处理器、编解码芯片组、用户身份模块卡等等。可选地，射频电路1504通过至少一种无线通信协议来与其它终端进行通信。该无线通信协议包括但不限于：城域网、各代移动通信网络(2g、3g、4g及5g)、无线局域网和/或wifi(wireless fidelity，无线保真)网络。在一些实施例中，射频电路1504还包括nfc(near field communication，近距离无线通信)有关的电路，本技术对此不加以限定。
[0382]
显示屏1505用于显示ui(user interface，用户界面)。可选地，该ui包括图形、文本、图标、视频及其它们的任意组合。当显示屏1505是触摸显示屏时，显示屏1505还具有采集在显示屏1505的表面或表面上方的触摸信号的能力。该触摸信号能够作为控制信号输入至处理器1501进行处理。可选地，显示屏1505还用于提供虚拟按钮和/或虚拟键盘，也称软按钮和/或软键盘。在一些实施例中，显示屏1505为一个，设置终端1500的前面板；在另一些实施例中，显示屏1505为至少两个，分别设置在终端1500的不同表面或呈折叠设计；在再一些实施例中，显示屏1505是柔性显示屏，设置在终端1500的弯曲表面上或折叠面上。甚至，可选地，显示屏1505设置成非矩形的不规则图形，也即异形屏。可选地，显示屏1505采用lcd(liquid crystal display，液晶显示屏)、oled(organic light-emitting diode，有机发光二极管)等材质制备。
[0383]
摄像头组件1506用于采集图像或视频。可选地，摄像头组件1506包括前置摄像头和后置摄像头。通常，前置摄像头设置在终端的前面板，后置摄像头设置在终端的背面。在一些实施例中，后置摄像头为至少两个，分别为主摄像头、景深摄像头、广角摄像头、长焦摄像头中的任意一种，以实现主摄像头和景深摄像头融合实现背景虚化功能、主摄像头和广角摄像头融合实现全景拍摄以及vr(virtual reality，虚拟现实)拍摄功能或者其它融合拍摄功能。在一些实施例中，摄像头组件1506还包括闪光灯。可选地，闪光灯是单色温闪光灯，或者是双色温闪光灯。双色温闪光灯是指暖光闪光灯和冷光闪光灯的组合，用于不同色温下的光线补偿。
[0384]
在一些实施例中，音频电路1507包括麦克风和扬声器。麦克风用于采集用户及环境的声波，并将声波转换为电信号输入至处理器1501进行处理，或者输入至射频电路1504以实现语音通信。出于立体声采集或降噪的目的，麦克风为多个，分别设置在终端1500的不同部位。可选地，麦克风是阵列麦克风或全向采集型麦克风。扬声器则用于将来自处理器1501或射频电路1504的电信号转换为声波。可选地，扬声器是传统的薄膜扬声器，或者是压电陶瓷扬声器。当扬声器是压电陶瓷扬声器时，不仅能够将电信号转换为人类可听见的声波，也能够将电信号转换为人类听不见的声波以进行测距等用途。在一些实施例中，音频电路1507还包括耳机插孔。
[0385]
定位组件1508用于定位终端1500的当前地理位置，以实现导航或lbs(location based service，基于位置的服务)。可选地，定位组件1508是基于美国的gps(global positioning system，全球定位系统)、中国的北斗系统、俄罗斯的格雷纳斯系统或欧盟的伽利略系统的定位组件。
[0386]
电源1509用于为终端1500中的各个组件进行供电。可选地，电源1509是交流电、直流电、一次性电池或可充电电池。当电源1509包括可充电电池时，该可充电电池支持有线充电或无线充电。该可充电电池还用于支持快充技术。
[0387]
在一些实施例中，终端1500还包括有一个或多个传感器1510。该一个或多个传感器1510包括但不限于：加速度传感器1511、陀螺仪传感器1512、压力传感器1513、指纹传感器1514、光学传感器1515以及接近传感器1516。
[0388]
在一些实施例中，加速度传感器1511检测以终端1500建立的坐标系的三个坐标轴上的加速度大小。比如，加速度传感器1511用于检测重力加速度在三个坐标轴上的分量。可选地，处理器1501根据加速度传感器1511采集的重力加速度信号，控制显示屏1505以横向视图或纵向视图进行用户界面的显示。加速度传感器1511还用于游戏或者用户的运动数据的采集。
[0389]
在一些实施例中，陀螺仪传感器1512检测终端1500的机体方向及转动角度，陀螺仪传感器1512与加速度传感器1511协同采集用户对终端1500的3d动作。处理器1501根据陀螺仪传感器1512采集的数据，实现如下功能：动作感应(比如根据用户的倾斜操作来改变ui)、拍摄时的图像稳定、游戏控制以及惯性导航。
[0390]
可选地，压力传感器1513设置在终端1500的侧边框和/或显示屏1505的下层。当压力传感器1513设置在终端1500的侧边框时，能够检测用户对终端1500的握持信号，由处理器1501根据压力传感器1513采集的握持信号进行左右手识别或快捷操作。当压力传感器1513设置在显示屏1505的下层时，由处理器1501根据用户对显示屏1505的压力操作，实现对ui界面上的可操作性控件进行控制。可操作性控件包括按钮控件、滚动条控件、图标控件、菜单控件中的至少一种。
[0391]
指纹传感器1514用于采集用户的指纹，由处理器1501根据指纹传感器1514采集到的指纹识别用户的身份，或者，由指纹传感器1514根据采集到的指纹识别用户的身份。在识别出用户的身份为可信身份时，由处理器1501授权该用户执行相关的敏感操作，该敏感操作包括解锁屏幕、查看加密信息、下载软件、支付及更改设置等。可选地，指纹传感器1514被设置终端1500的正面、背面或侧面。当终端1500上设置有物理按键或厂商logo时，指纹传感器1514能够与物理按键或厂商logo集成在一起。
[0392]
光学传感器1515用于采集环境光强度。在一个实施例中，处理器1501根据光学传感器1515采集的环境光强度，控制显示屏1505的显示亮度。具体地，当环境光强度较高时，调高显示屏1505的显示亮度；当环境光强度较低时，调低显示屏1505的显示亮度。在另一个实施例中，处理器1501还根据光学传感器1515采集的环境光强度，动态调整摄像头组件1506的拍摄参数。
[0393]
接近传感器1516，也称距离传感器，通常设置在终端1500的前面板。接近传感器1516用于采集用户与终端1500的正面之间的距离。在一个实施例中，当接近传感器1516检测到用户与终端1500的正面之间的距离逐渐变小时，由处理器1501控制显示屏1505从亮屏状态切换为息屏状态；当接近传感器1516检测到用户与终端1500的正面之间的距离逐渐变大时，由处理器1501控制显示屏1505从息屏状态切换为亮屏状态。
[0394]
本领域技术人员能够理解，图15中示出的结构并不构成对终端1500的限定，能够包括比图示更多或更少的组件，或者组合某些组件，或者采用不同的组件布置。
[0395]
图16是本技术实施例提供的一种计算设备的结构示意图，该计算设备1600可因配置或性能不同而产生比较大的差异，该计算设备1600包括一个或一个以上处理器(central processing units，cpu)1601和一个或一个以上的存储器1602，其中，该存储器1602中存储有至少一条计算机程序，该至少一条计算机程序由该一个或一个以上处理器1601加载并执行以实现上述各个实施例提供的事务处理方法。可选地，该计算设备1600还具有有线或无线网络接口、键盘以及输入输出接口等部件，以便进行输入输出，该计算设备1600还包括其他用于实现设备功能的部件，在此不做赘述。
[0396]
在示例性实施例中，还提供了一种计算机可读存储介质，例如包括至少一条计算机程序的存储器，上述至少一条计算机程序可由终端中的处理器执行以完成上述各个实施例中的事务处理方法。例如，该计算机可读存储介质包括rom(read-only memory，只读存储器)、ram(random-access memory，随机存取存储器)、cd-rom(compact disc read-only memory，只读光盘)、磁带、软盘和光数据存储设备等。
[0397]
在示例性实施例中，还提供了一种计算机程序产品或计算机程序，包括一条或多条程序代码，该一条或多条程序代码存储在计算机可读存储介质中。计算设备的一个或多个处理器能够从计算机可读存储介质中读取该一条或多条程序代码，该一个或多个处理器执行该一条或多条程序代码，使得计算设备能够执行以完成上述实施例中的事务处理方法。
[0398]
本领域普通技术人员能够理解实现上述实施例的全部或部分步骤能够通过硬件来完成，也能够通过程序来指令相关的硬件完成，可选地，该程序存储于一种计算机可读存储介质中，可选地，上述提到的存储介质是只读存储器、磁盘或光盘等。
[0399]
以上所述仅为本技术的可选实施例，并不用以限制本技术，凡在本技术的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本技术的保护范围之内。