OLTP系统以小的事务以及小的查询为主，系统评估主要看其每秒执行的Transaction以及Execute SQL的数量。一般而言，单个数据库每秒处理的Transaction往往超过几百个，或者是几千个，Select语句的执行量每秒几千甚至几万个。
OLAP系统也叫DSS决策支持系统，即数据仓库。由于一条语句的执行时间可能会非常长，读取的数据也非常多，所以不采用执行量作为考核标准，考核的标准通常是磁盘子系统的吞吐量(带宽)，如能达到多少MB/s的流量。
HTAP数据库(hybrid transaction and analytical process，混合事务和分析处理)是Gartner在2014年提出的新型应用程序框架，打破了OLTP和OLAP之间的隔阂，既可以应用于事务型数据库场景，亦可以应用于分析型数据库场景，实现实时业务决策。这种架构可以避免繁琐且昂贵的ETL操作，而且可以更快地对最新数据进行分析，从而成为企业的核心竞争力之一。
虽然OLTP和OLAP的考核标准不一样，但2种业务都是金融的核心需求，特别是在大数据背景下，如果能基于相同的数据存储运行2种业务，将大大降低构建OLAP数据仓库的成本，提高数据的应用价值。
CBase是西北工业大学和交通银行自主研发的面向金融应用的分布式关系数据库[1]，基于阿里巴巴的分布式数据库OceanBase，已经在交通银行上线应用。目前CBase主要面向OLTP业务，不支持OLAP业务。因此针对历史数据的查询、分析及统计则需要重新进行数据的导入导出，利用其他分析引擎如Spark进行分析统计。为了更好地支持分析业务，并复用现有的存储引擎，需要研究在CBase之上添加OLAP的查询引擎，为分析业务提供支持。
为此，本文提出了一种基于分布式数据库CBase的HTAP方案，在CBase和Spark之间建立一个适配层，将CBase与Spark分析引擎结合起来，实现OLTP与OLAP功能，并对适配层的数据传输进行优化，提高AP分析效率。
1 国内外研究现状 1.1 原生HTAP数据库数据库系统一般可以按照负载类型分成操作型数据库(operational support system)和决策型数据库(decision support system)。操作型数据库主要用于应对日常流水类业务，即面向消费者类的业务；决策型数据库主要应对的是企业报表类、可视化等统计类业务，即面向企业类的业务。
在目前的HTAP数据库研究中，出现了许多原生HTAP数据库，所谓原生，就是在同一集群中，可以同时完成OLTP与OLAP的分析工作。
BatchDB是一种为混合OLTP和OLAP工作负载设计的内存数据库引擎[2]。该系统可有效处理具有强大性能隔离功能的OLTP和OLAP混合工作负载。BatchDB依赖于主次复制形式，其中主副本处理OLTP工作负载，并且更新传播到处理OLAP工作负载的辅助副本。可以从OLAP副本的OLTP副本中高效地提取并应用更新，从而给整体执行时间带来很小的开销。
L-Store是一个基于谱系的存储架构[3]，旨在处理OLTP和OLAP的混合工作负载，并且支持多个L-Store节点提供可伸缩性和弹性。此系统通过引用新颖的、基于谱系的存储体系架构，在单个统一引擎中结合了事务处理和分析工作负载的实时处理，以事务一致的方式开发了一种无竞争的懒惰的列数据分阶段从写优化(适用于OLTP)到读优化形式(适用于OLAP)的方法。
DL-Store是一个分布式的HTAP数据处理引擎[4]，DL-Store是在L-Store的基础上提出的基于分布式谱系的数据存储系统，旨在处理分布式环境中的大量更新工作负载，DL-Store将数据进行分区，并将数据分布在许多L-Store节点上。此系统的设计弥补了以往数据存储系统的不足，引入基于谱系的存储体系结构，该体系结构可在本机多版本的列存储模型上实现无竞争的更新机制，以便将稳定的数据从写入优化的列布局(即OLTP)中延迟并独立地转移到读取优化的列布局(即OLAP)。
TBase是腾讯数据平台团队在开源的PostgreSQL基础上研发的企业级分布式HTAP数据库管理系统，具备高性能可扩展的分布式事务能力，支持RC和RR 2种隔离级别。TBase把OLTP和OLAP处理进行融合，在一套数据库系统中同时完成2种操作，降低业务复杂度和业务成本。通过资源隔离技术，TBase实现了HTAP中关键的资源隔离技术，同时实现了HTAP方案。
这些原生的HTAP数据库均有同样的特点：所有的OLTP与OLAP工作都在一个集群中完成，在进行OLAP分析时，难免会影响OLTP的性能。因此，进行了研究后，出现了许多集成第三方平台的HTAP研究。
相比于这些原生HTAP数据库而言，本文设计的分布式数据库CBase的HTAP方案通过构建一个适配层，并且完成与第三方数据分析平台的连接，可以有效地将上层的数据计算平台与底层的数据存储平台分离开来，在进行OLAP分析的同时对OLTP的影响降至最低，既方便维护，又可以减少开发成本，提高可扩展性。
1.2 集成第三方平台的HTAP数据库由于在同一集群中同时进行了OLTP与OLAP工作会对性能造成影响，因此，出现了许多集成第三方平台的HTAP数据库，通过集成Storm、Flink及Spark等平台来实现OLAP分析。
TiDB是一款开源、云原生、MySQL兼容的分布式数据库，通过自研的TiSpark接口将OLTP和OLAP功能相结合，采用一份存储同时处理OLTP & OLAP，避免了传统繁琐的ETL过程，可以处理混合事务和分析处理(HTAP)工作负载。
Wildfire是一个用于大数据的HTAP系统[5]，使用可扩展Spark API和用于SQL查询的Catalyst优化器来实现了本系统的HTAP。对Wildfire的所有请求均通过Spark API。集群中的大多数节点仅执行分析请求，仅需要普通服务器硬件。其他功能更强大的节点具有更快的本地持久性存储和更多的内核，可提高并行性，同时处理事务和分析查询这些节点中的数据流。
过去的HTAP数据库系统把所有数据都存在主存中，来实现同时处理OLTP和TiDB，为了降低占用空间而不影响性能，是一种混合优化主存数据库，通过把冷数据分配到较少开销的次分配空间中。使用负载驱动，以Pareto-optimal allocations算法为基础，同时使用了再分配数据成本模型，可以决定哪些数据允许保留在主存中，以此来提高HTAP系统的分析效率。
T-plotter是协调OLAP和OLTP模型的新数据结构[6]，可促进数据重建和对多个不同结构的索引访问。该结构通过实现数据的垂直碎片化来实现数据库系统的OLAP分析功能，垂直片段化是一种用于在集中式或分布式体系结构中有效执行OLAP模型的技术，该技术用于调用表中的某些列，有效提高了OLAP查询效率。
由于第三方平台有很多选择，面向流式的开源数据处理框架包括Storm、Flink及Spark等，要对这些框架进行分析，选择出适配CBase的数据处理框架。在Storm中，需要设计一个实时计算结构，这个结构会被提交至集群，master节点为worker节点分配代码，所有的worker节点负责对数据进行计算分析。而Storm框架一次只能处理一个数据流，效率相对较低[7-11]。
Flink框架是针对流数据和批数据的计算框架，实现了批数据的处理[9]。但在工程实现时，不同的job可能被分配在同一个进程内，会影响其他job的稳定性，对AP分析结果会产生误差，最终影响设计方案的测试结果。Apache Spark不像Storm那样一次处理一个数据流；相反，在处理数据流之前它会对数据流进行分段切分，并生成相应的RDD(弹性分布式数据集)，可以通过任意函数或窗口进行转换，实现计算的并行操作[8, 10-11]。其次，Spark不会出现job的进程分配问题，不会影响job执行的稳定性。因此，本文设计方案选择Spark API作为上层数据计算框架。
本文对分布式数据库的HTAP设计更简便且容易实现，省去了一系列嵌入及维护工作，直接在下层通过适配层连接Spark节点，通过适配层将所有缓存数据传输至各个Spark节点，即可进行AP分析。本文设计方案的实现弥补了当前CBase对OLAP分析功能的缺失，并且为所有Spark节点的数据存储提供了空间。同时，各个组件之间是相互独立的，适配层与最下层的CBase相互剥离，且与最上层的Spark分析API相互剥离，并不会由于某个组件的版本更新或者换代后，发生无法识别或宕机的后果，独立性极强。为使用后的维护提供了便捷的保障。
2 面向CBase的HTAP方案 2.1 CBase架构CBase可以划分为4个模块：主控服务器RootServer、更新服务器UpdateServer、基准数据服务器ChunkServer以及合并服务器MergeServer。
CBase内部按照时间线将数据划分为基准数据和增量数据，基准数据是只读的，所有的修改更新到增量数据中，系统内部通过合并操作定期将增量数据融合到基准数据中。CBase整体架构如图 1所示。
|
| 图 1 CBase总体架构 |
·客户端
客户端是用户和CBase交互的接口，使用方式和MySQL数据库相同，支持SQL交互以及JDBC和ODBC交互。
·RootServer
管理集群中的所有服务器，Tablet数据分布以及副本管理。RootServer一般为一主一备，主备之间数据强同步。
·UpdateServer
存储CBase系统的增量数据。UpdateServer一般为一主一备，目前在每个集群内部，同一时刻只允许主UpdateServer提供写服务。
·ChunkServer
存储OceanBase系统的基准数据。基准数据一般存储2份或者3份，可配置。
·MergeServer
接收来自客户端的SQL请求，经过词法分析、语法分析、查询优化等一系列操作后转发给相应的ChunkServer或者UpdateServer, 并将来自多台ChunkServer返回的结果合并后返回给客户端。
2.2 CBase的HTAP方案分析根据CBase的架构，支持HTAP功能可以考虑3种方案：
1) Spark通过JDBC连接到CBase；
2) Spark直接分析CBase导出的CSV文件；
3) 分析TiSpark的功能类推到CBase。
第一种方案为Spark通过JDBC连接到CBase，进行持久化及全表遍历操作后，对CBase中的数据进行AP分析。此方案的优点是JDBC连接方法简单高效，且分析的数据具有一定的实时性，保证了数据的可靠；缺点是预处理操作有些繁琐，但并不妨碍最终的结果。
Spark通过JDBC连接CBase的操作十分简单，可以使用简单的方法将数据从CBase上迁移到Spark做数据分析，使数据库的数据分析与事务处理分别处于不同的引擎上。
第二种方案为Spark直接分析CBase导出的CSV文件。此方案的优点是Spark分析CSV文件操作较为简单，但要保证AP分析效率，文件内的数据也应进行上述的持久化和全表遍历操作。CBase自身具有数据的导入导出功能，基于此项，可以将需要进行AP分析的数据导出为CSV文件，Spark对这些CSV文件进行数据分析。但是由于导出的CSV文件是以select语句作为数据导出的基准，数据的过滤及其他操作必须在导出过程完成，导出后的CSV文件无法按照过滤规则等进行更改。
虽然Spark读取CSV文件操作简单，但Spark与CBase并未直接建立连接，是一个断层。并且CBase数据库数据导出的消耗及数据读取的时延都是不可避免的，并且由于是直接读取数据文件，只能整个文件完全读取，不能进行filter以及聚合下推等操作，数据的过滤以及分析需要完全由Spark执行，对于Spark内存的要求会非常高，并且将数据分析的所有压力都推及Spark计算引擎，会明显降低Spark分析的性能与效率。
CBase导出的CSV文件实际上是从ChunkServer中导出的历史数据，并不是一种实时数据。若是对于实时性没有十分严格的要求，就可以通过导出历史数据为CSV文件进行数据分析，但是考虑到数据的实时性，若采用这种方法则只能分析历史数据，不能集合实时的增量数据进行分析，则不能满足数据分析的实时性。
由于导出的CSV文件中并不是实时数据而是历史数据，这并不能满足OLAP要求的实时性。
第三种方案为分析TiSpark的功能类推到CBase中。此方案的优点有很多，将TiSpark的功能类推到CBase中，既可以保证数据的实时性，又可以省掉方案一中繁琐的预处理操作，且预估实验结果与此次结果并不会有很大差异；但此方案的缺点也很明显，升级维护的工作量会非常巨大。
首先，如果CBase需要实现Spark on ChunkServer，同样需要根据Spark方面的接口改写逻辑计划、物理计划以及某些算子的实现，并且需要根据CBase的语法规则schema形式进行类型转换及schema转换。CBase的数据类型与存储格式完全不同，如果需要进行数据对接必须要进行schema的桥接。这样做的最终目的是完成一个SQL解析的过程以及部分查询优化的功能。
其次，CBase需要改写Spark SQL传出的计划使其适合于CBase的流程，schema的适配与自动获取，各种下推操作的实现包括过滤、谓词下推和聚合下推(目前CBase支持的下推操作)等，但是若要完成这一薄层的构建具有十分可观的工作量，完成这一步类似于重新构建CBase读写流程以及CBase的计划部分，并且需要在这一层完成指定的下推操作。
最后，由于直接通过Spark接口开发，项目需要随着Spark的升级换代而进行更新，此方案的工作量巨大。因此，本次设计不选用此方案作为最终设计方案。
本次设计将方案一与方案二结合起来，共同构建出一个适配层，其功能同时满足方案一与方案二的需求。既可以通过连接池将SQL语句传送到Spark AP分析引擎中，又可以发送通过CBase导出的CSV文件至Spark AP分析引擎中进行OLAP分析。
在适配层中，对SQL传输执行部分做了一部分优化，提高AP分析效率，具体设计在第3节中阐述。
3 面向CBase的HTAP方案的实现 3.1 总体架构综合了2种设计方案的优缺点，设计了一个适配层来完成CBase与Spark之间的交互，实现CBase的HTAP设计，数据流可以以2种形式传送至Spark中进行AP分析，分别为CSV数据文件及JDBC传送SQL语句的方式。因此设计的总体架构如图 2所示。
|
| 图 2 CBase的HTAP方案总体架构 |
CBase是进行OLAP操作的数据的来源，所有的数据都是存储在CBase中，需要通过封装好的Scala程序从CBase中取出放到Spark中进行持久化处理后，方可进行OLAP分析。
在整个架构中，数据最初存储在最底层CBase的ChunkServer节点中，使用TPC-H工具将测试数据导入至CBase中；通过封装好的Scala程序，将所有测试数据从CBase中取出，此处的数据可以通过JDBC连接，把数据发送到Spark的master节点上；或者可以通过导出CBase的CSV文件，将CSV文件进行随机分片，分别发送给Spark的master节点中；最后Spark内部会将所有数据进行分片与节点分配，分别发送给集群中的不同worker节点进行计算。
在整个架构的中间层即为适配层，其上层结构为Spark，下层结构为CBase。这个适配层的作用为实现上层SparkAP分析引擎与下层CBase分布式存储引擎的通信交互，并实现数据的传输。
适配层可以与Spark分析引擎及CBase分布式存储引擎剥离开来；设计为剥离的形式可以提供维护的便捷，若将适配层的设计嵌入至Spark或CBase中时，当Spark或CBase进行版本升级或更新时，若源码发生改变，则嵌入到Spark或CBase中的内容同样需要升级或更新，此种情况来看，维护需要耗费许多精力。
在适配层中，可以通过2种形式进行数据的传输。第一种为CSV文件的传输。CBase可以将某个数据库中的所有数据导出至指定的CSV文件中，通过适配层可以将CSV文件分片传送至Spark节点中，而后通过master节点的分配将分片传送至相应的worker节点中进行AP分析工作。由于CSV文件不需要进行JDBC连接池的连接，此种方式在传输效率中表现较好。第二种方式为执行的SQL通过JDBC连接池传送至Spark的master节点中。在此方式中，可以实现执行SQL的传输，且在此部分中实现了opt优化组件。由于Spark SQL组件的SQL语法解析与CBase的SQL语法解析有一定的差距，所以有些SQL语句需要进行语法解析及下推操作的变换，而opt优化组件可以实现这一点，将CBase传送的SQL语句转化为可以完美适配Spark SQL的SQL语句。并且，此优化组件可以指定数据行按range切分，且根据元数据保存的分布信息与指定数据行的数据建立精准的连接，同时减少了网络传输的开销，提高了传输效率和AP分析效率。在后文的测试部分，本文仅选用了第二种方式来完成CBase的HTAP方案的实现，由于CSV文件存储的并不是实时数据，而是历史数据，不能保证数据的实时性，相对于第一种方案而言，第二种方案符合实际的业务需求，因此后文的实验均使用第二种方案即JDBC来进行。
Spark和CBase各有特点，CBase作为一款成熟的分布式数据库，可以为数据存储提供稳定有效的服务，所有AP分析所需数据均可以存储在CBase的ChunkServer中，待需要时取出通过JDBC传送至Spark中即可进行相应的AP分析工作。而Spark的主要功能为数据计算及分析，但其并没有一个稳定的数据存储服务来支撑其运转。对于CBase而言，Spark的数据分析服务完全可以满足其缺失的AP分析功能；且对于Spark而言，CBase的数据存储可以为其提供稳定的数据存放位置。两个组件相互合作可以达到更好的效果。
因此，本文设计了一个适配层，用于实现Spark与CBase 2个组件的交互及数据传输。本层将Spark与CBase及本层相互剥离开，实现了各组件的分离维护及更新。此举避免了由于Spark或CBase的升级换代导致的嵌入组件失效，且完成了部分SQL处理的优化工作。实现了CBase的AP分析功能，且完善了Spark的数据存储，为其交互提供了稳定的保障。
适配层的实现流程如图 3所示，具体步骤为：①通过JDBC将CBase与Spark连接起来，若连接成功则进行下一步操作，失败则返回；②将每个数据表分别注册为对应的DataFrame；③每个DataFrame分别注册为对应的临时表；④每个临时表进行数据的持久化操作，将所有数据持久化到内存中；⑤若持久化成功则进行Query的执行并记录执行结果，若失败则考虑是否为内存不足的问题。
|
| 图 3 HTAP方案实现流程图 |
环境条件允许的情况下，尽可能使用内存足够的环境来完成。若数据量过大因此对内存大小的要求过大的话，可以采用其他的持久化方法来完成。Spark中提供了不同的持久化策略，包括全部持久化到内存中、全部持久化到磁盘中以及部分持久化到内存部分持久化到磁盘中这3种不同的持久化策略。若数据量过大导致数据不足以全部放进内存中时，可以采用最后一种持久化策略，即部分内存部分磁盘的持久化方法，虽然这种持久化的效率要略低于全部持久化到内存中，但这种策略可以有效地减少对内存的压力，将数据分散存储到内存和磁盘中。另一种解决方案为将所有数据进行分批处理，然后对结果进行合并。
3.2 测试环境本次的测试机器配置如表 1所示，性能测试采用了TPC-H基准的8张表和22个查询，数据量从1G到3G增长，主要观察数据增长过程中性能的变化情况。
| 操作系统 | Red Hat Enterprise Linux Server release 6.2 |
| 内核版本号 | Linux version 2.6.32-220.el6.x86_64 |
| 内存 | 32G |
| CBase版本 | CBase Version: 0.4.2.21单集群 |
| Java版本 | 1.8.0_21 |
| Hadoop版本 | 2.7.7分布式3节点 |
| Spark版本 | 2.4.3分布式3节点 |
| Scala版本 | 2.13.0 |
| TPC-H数据量 | 1G，2G，3G |
在CBase环境下测试时，单节点相对于多节点分布式来说执行效率更高，因此选择了单机部署CBase。而Spark采用了1个master节点和2个worker节点的部署策略，实现了分布式AP分析。由于在分布式配置的Spark中进行AP分析会产生网络传输开销，若在分布式配置的Spark中AP分析的效率高于单机部署的CBase的AP分析效率，则完全可以得到结论，适配层的作用是突出且明显的。
为了保证测试环境的稳定性，防止数据库缓存以及操作系统导致的缓存影响实验结果，在导入数据之前要对CBase进行rebuild操作，此操作的目的是清空数据库中的所有数据及缓存。完成rebuild后再对所有测试数据进行导入，从而保证数据库中的数据是干净、不冗余的。对于操作系统的缓存问题，在测试前清理其余无用的进程，保证仅有CBase与Spark相关进程处于运行状态，从而保证测试环境的稳定性，并且在测试过程中会进行多次实验，采用试验的平均值来降低干扰性能的因素。
3.3 测试结果本次测试使用第一种连接方案，即JDBC连接CBase获取数据库中数据信息，且使用编写Scala程序的方式提交到Spark运行程序对执行性能进行测试。下面将对实验结果进行比较分析。
3.3.1 Spark未持久化与CBase的结果对比在将数据从CBase传送到Spark后，需要进行一步持久化操作，即将Spark收到的所有数据，均持久化到内存中。
首先，进行第一版初次测试，使用内存为16G的虚拟机，实验数据为1G数据量，通过Spark-submit将已经封装好的jar包提交到Spark中运行，此时并没有进行RDD的持久化到内存的操作，且未进行Spark-submit的参数调优，得到了Spark未进行持久化及全表遍历的测试结果。由于本次实验结果与CBase结果差距过大，所以每条SQL语句只进行了3次实验，用3次实验的平均值与CBase的运行结果相比较。可以明显看出，在未进行持久化和全表遍历操作的情况下，Spark的性能远不如CBase。用柱状图的形式来表达，测试结果如图 4所示。
|
| 图 4 Spark未持久化与CBase结果对比 |
由图 4可以明显看出，未进行持久化及全表遍历的Spark执行SQL效率要远不如CBase，以任意一条SQL语句为例，未进行持久化的Spark执行效率及执行时间要远远超出CBase本身的执行时间，这违背了本文研究的初衷，因此需要测试持久化及全表遍历后的Spark执行效率。在下一节中将对比是否进行持久化对Spark分析数据速度的影响。
3.3.2 Spark未持久化与持久化的结果对比此次测试目的是比较Spark是否持久化对分析数据速度的影响，持久化过程包括全表遍历，将所有表中的所有数据持久化到内存中；以及提交Scala程序命令的参数调优。以此结果来判断是否持久化对数据分析效率的影响。
由图 4可以看出，未进行持久化和全表遍历得到的结果和CBase的结果相比执行效率存在过大差异，Spark对SQL的操作时间过长，远远超出对实验结果的期望。在经过研究与探讨分析后，发现Spark中的load的数据并没有存储在内存中，而是从磁盘中读取出来，再进行分析。对此，可以将已经load在Spark中的数据再进行一次持久化操作，将数据转为在内存中存储，这样再对RDD进行Spark SQL操作，即可直接从内存中读取数据来进行分析，比从磁盘中读取数据分析花费的时间要少很多。在进行上述持久化和全表遍历操作后，我们又进行了第二次测试，得到了1G数据量的数据在Spark中执行SQL操作的效率。
将对比结果绘制成柱状图表示，如图 5所示。
|
| 图 5 Spark未持久化与持久化结果对比 |
从图 5中可以清楚地看出，未进行持久化和全表遍历操作时Spark执行SQL操作花费的时间普遍在30 s以上，最高的甚至达到了370余秒，这个时间与SQL中的聚合函数涉及表的大小与多少有关，而且每一条SQL语句，持久化和全表遍历后的执行时间均远小于未进行持久化的执行时间。这证明了Spark在对数据表进行load及遍历的时间，占了提交一次任务总时间的绝大一部分比例，而这正是Spark的优势所在，将数据存储在内存中，需要读取数据时直接从内存中读取，这样比磁盘读取效率高得多。因此，在以下所有实验中，均采用将RDD数据持久化到内存中和进行全表遍历的方法来完成测试。
由于在Spark中，对数据进行持久化是一次性操作，即每次导入数据后，只需在第一次使用Spark之前对数据进行一次持久化，即可实现将CBase中的数据持久化到内存中；故将此持久化操作视为进行测试之前的预处理操作，因此在后面的对比测试中，并未将持久化的时间计入各个Query执行所消耗时间中。
3.3.3 1 G数据Spark与CBase的结果对比下面将对数据量为1G的测试项进行测试，每条SQL语句均进行5次测试，最终计算出每条SQL语句执行的平均值，测试结果，如图 6所示。
|
| 图 6 Spark与CBase 1G数据性能对比 |
由图 6可以清晰地看出，经过持久化和全表遍历后，Spark对每一条SQL语句的操作效率都要优于CBase本身，相对于CBase效率的提升，最低的也有4倍左右的提升(Q13)，而最高的提升达46倍(Q17)。Spark对每一条SQL语句执行性能的提升与SQL语句本身的结构有关，有些SQL语句(大查询)较多，提升较大；而有些SQL语句(小查询)较多，提升较小。总体来看，Spark的性能要远远优于CBase。
3.3.4 2G数据Spark与CBase的结果对比下面将对数据量为2G的测试项进行测试，测试步骤与1G数据量相同，测试后得出结果，并绘制出性能对比柱状图以方便观察实验结果并进行分析。
从图 7可以看出，经过持久化和全表遍历后，Spark对每一条SQL语句的操作效率都要优于CBase本身，且相对于1G数据来说，每条语句执行时间无论是Spark还是CBase都要相对慢一点。对于大查询Q9，CBase的查询执行时间甚至达到了425.444 s，而经过持久化和全表遍历处理后，Spark的查询执行时间仅为12.010 s，相比CBase本身而言缩短了35倍左右时间。提升最低的为Q16，提升了大约4倍。提升最高的为Q17，大约提升57倍。总的来说，Spark的AP性能要优于CBase。
|
| 图 7 Spark与CBase 2G数据性能对比 |
下面将对数据量为3G的测试项进行测试，测试步骤与1G、2G数据量相同，测试结果如图 8所示。
|
| 图 8 Spark与CBase 3G数据性能对比 |
如图 8所示，经过持久化和全表遍历后，与1G和2G数据量的结果相同，Spark执行每条SQL操作的效率都要优于CBase，对于最大查询语句Q9来说，CBase每次执行Q9需要花费平均715.562 s约12 min，这样的效率过低导致分析速度过慢，对数据量更大的数据库来说，成本太大不方便进行大数据量的AP分析；而反观Spark，可能在预处理操作时，全表遍历的过程会稍微花费一点时间，但这种花费是有收益的，节省了在Spark上执行SQL语句的时间，且收益可观，执行Q9语句，Spark平均只用了14.594 s，是CBase执行时间的约1/50，执行效率有巨大提升。
4 结论本文在CBase的基础上提出了一种HTAP方案，设计了一个适配层，将上层AP分析引擎Spark与下层数据存储引擎CBase相连接，实现了其组件间的交互，将存储在CBase中的数据通过JDBC驱动或CSV数据文件传送至Spark节点中，通过提交Scala程序的方法对CBase中存储的数据进行AP分析，实现了CBase分布式数据库的HTAP方案。对不同数据量测试得到结果进行分析，结果表明: 本文所提出的适配层方案可以在CBase稳定存储的基础上，合理高效地进行AP分析，且易于维护，为分布式数据库提供了可行的HTAP方案。
| [1] | 刘文洁, 李戬勃, 李战怀, 等. 一种面向金融应用的海量分布式关系数据库[J]. 华中科技大学学报, 2019, 47(2): 121-126. |
| [2] | DARKO Makreshanski, JANA Giceva, CLAUDE Barthels, et al. BatchDB: efficient isolated execution of hybrid OLTP+OLAP workloads for interactive applications[C]//Proceedings of the 2017 ACM International Conference on Management of Data, New York, 2017 |
| [3] | SADOGHI M, BHATTACHERJEE S, BHATTACHARJEE B, et al. L-store: a real-time OLTP and OLAP system[C]//Proceedings of the 21st International Confcrence on Extendirg Database Technology, 2018 |
| [4] | ZHANG K, SADOGHI M, JACOBSEN H. DL-store: a distributed hybrid OLTP and OLAP data processing engine[C]//IEEE 36th International Conference on Distributed Computing Systems, 2016: 769-770 |
| [5] | RONALD Barber, VIJAYSHANKAR Raman, RICHARD Sidlc, et al. Wildfire: HTAP for big data[M]. Encyclopedia of Big Data Technologies, 2019. |
| [6] | BOISSIER M, SCHLOSSER R, UFLACKER M. Hybrid data layouts for tiered HTAP databases with pareto-optimal data placements[C]//IEEE 34th International Conference on Data Engineering, 2018 |
| [7] | CHAALAL Hichem, TRAVERS Nicolas, BELBACHIR Hafida. T-plotter: a new data structure to reconcile OLAP and OLTP Models[J]. Multiagent and Grid Systems, 2019, 1: 237-257. |
| [8] | HEDJAZI M A, KOURBANE I, GENC Y, et al. A comparison of hadoop, spark and storm for the task of large scale image classification[C]//2018 26th Signal Processing and Communications Applications Conference, Izmir, 2018 |
| [9] | MARKL V. Mosaics: stratosphere, flink and beyond[C]//IEEE International Conference on Data Engineering, 2017 |
| [10] | KAMIL Jerábek, ONDREJ Rysary. Big data network flow processing using apache spark[C]//Proceedings of the 6th Conference on the Engineering of Computer Based Systems, 2019 |
| [11] | CHINTAPALLI S, DAGIT D, EVANS B, et al. Benchmarking streaming computation engines: storm, flink and spark streaming[C]//IEEE International Parallel & Distributed Processing Symposium Workshops, 2016 |
