CN110162515A

CN110162515A - 一种解耦合的弹性数据仓库架构

Info

Publication number: CN110162515A
Application number: CN201910362554.9A
Authority: CN
Inventors: 伍浩文; 白童心; 须成忠
Original assignee: Shenzhen Institute of Advanced Technology of CAS
Current assignee: Shenzhen Institute of Advanced Technology of CAS
Priority date: 2019-04-30
Filing date: 2019-04-30
Publication date: 2019-08-23
Also published as: WO2020220717A1

Abstract

本发明涉及数据仓库领域，具体涉及一种解耦合的弹性数据仓库架构。包括：数据仓库前端，用于使用PostgreSQL作为数据仓库前端的基础，处理进出数据、提供控制和查询用户界面及管理底层存储；数据仓库后端，用于可扩展和弹性的资源管理、单个或并发查询；分离数据仓库中间件，用于使用Dex协调数据仓库前端和数据仓库后端之间的消息传递和数据传输。通过将数据管理和数据计算功能相分离，以实现独立的可扩展性，探索了云的弹性数据仓库体系结构。数据仓库前端接收数据、管理存储并提供高可用性。数据仓库后端用于数据分析的查询。通过分离数据管理和数据计算，本发明可以在单一的数据仓库中获得弹性。

Description

一种解耦合的弹性数据仓库架构

技术领域

本发明涉及数据仓库领域，具体而言，涉及一种解耦合的弹性数据仓库架构。

背景技术

随着云在提供共享和管理的IT基础设施方面越来越受欢迎，如今的公司迫切希望将其数据平台资产转移到云上，以减少设备、公用设施和维护支出。将数据仓库移动到云端是当今公司考虑的一种经济高效的数据管理趋势。为了充分实现经济目标，云数据仓库系统应该能够调整其资源配置，以适应不断变化的工作负载需求。然而，传统的数据仓库体系结构不够灵活，不允许按需资源控制，这严重限制了云提供商和用户的优化总成本和保持期望所需的服务质量。

数据仓库已经存在几十年了，它的主要架构已经从对称多处理器(SMP)转变为大规模并行处理器(MPP)。然而，云计算和大数据的出现需要一种新的范式变革，这种变革比以前的范式更为紧迫和具有破坏性。目前的MPP数据仓库静态地安装在少数不共享的计算机节点上。这种架构无法利用云的多功能和强大的功能进行计划和资源分配，从而阻碍用户和云提供商实现预期的性能、服务质量和预算控制目标。

传统上，由于良好的可扩展性，MPP在数据仓库中得到了普及。但是，这种可扩展性几乎只在安装时提供。在安装之前，工作负载和数据量的类型是非常清楚的。但对于MPP数据仓库，很难支持异构工作负载，计算密集型算法和细粒度资源管理。有了云，现代业务工作流程的波动性质是不可避免的。首先，工作流程必须处理多样化的数据源。传统上，数据仓库设置为分析从内部数据源集成的数据。在云时代，分析数据的可能性越来越大，来自各种各样的应用程序，并且速度差别很大。此外，分析请求由外部客户按需进行。当在短时间内提交大量请求时，系统承受着很大的压力来处理它们。在这种情况下，扩展计算资源的能力对于保证服务质量至关重要。其次，分析将采用更复杂和迭代的算法，这些算法比传统的分析工作负载需要更多的计算能力。数据挖掘和机器学习方面的现代算法已经成功地实现了识别模式和发现商业数据中的有效数据，现代分析使用高级算法来推动应用，例如个性化推荐，欺诈检测和业务决策。因此，数据仓库中将运行比以往更多的CPU密集型工作负载。

基于上述观察，可以认为弹性即能够独立自适应地扩展系统组件的能力，是云数据仓库应该支持的主要属性。但是建立一个弹性数据仓库对于当前数据仓库软件设计的限制并不是一个简单的任务，它假设一个对称模型，其中每个节点连接一个本地存储，所有节点都是同构的。在MPP设置中，使用强耦合模型处理系统会对性能产生积极影响。但在云配置中，该软件设计成为性能和成本效益的障碍。为了获得所需的弹性，软件必须支持一定程度的计算和存储分离，以便在工作负载需要时可以添加更多的计算资源。

在认识到这一阻碍后，一些数据库供应商已经开始重新设计云计算的数据仓库。Azure SQL数据仓库是Microsoft Azure云上可用的大规模数据仓库服务。Azure SQL基于Microsoft SQL服务器，适用于支持关系数据和非关系数据。Azure SQL通过Azure Blob存储服务存储和访问其所有数据。由于物理分离，不仅存储和计算独立，而且计算也可以暂停，以便用户只需为存储付费。

发明内容

本发明实施例提供了一种解耦合的弹性数据仓库架构，以至少解决现有数据仓库无法将数据管理和数据计算进行分离的技术问题。

根据本发明的实施例，提供了一种解耦合的弹性数据仓库架构，包括：

数据仓库前端，用于使用PostgreSQL作为数据仓库前端的基础，处理进出数据、提供控制和查询用户界面及管理底层存储；其中在管理底层存储中在名为xschema的PostgreSQL扩展中实现所有分片逻辑；

数据仓库后端，用于可扩展和弹性的资源管理、单个或并发查询；其中资源分配分两个阶段进行，第一个阶段是在安装时，总资源最初是从云端分配；第二个阶段是在集群设置之后，用户可以在会话启动时传递参数；并使用Spark SQL作为底层查询引擎；

分离数据仓库中间件，用于使用Dex协调数据仓库前端和数据仓库后端之间的消息传递和数据传输。

进一步地，Dex中间件包括：Dex服务器、PostgreSQL适配器和Spark适配器，并通过Dex通信API运行，Dex通信API提供了一个中间层，其中：

PostgreSQL适配器用于转换数据库查询，与Dex服务器通信，然后从后端群集转换返回的响应；

Dex服务器用于维护查询上下文，监视会话状态转换并通过Dex通信API提供Dex服务；

Spark适配器用于接受并解析Dex requests，将Dex请求转换为Spark计算任务，一旦响应准备好，就将其发送回Dex服务器。

进一步地，Dex互操作是在Dex服务器中围绕Dex Context管理的有状态服务，内部工作由PostgreSQL和Spark之间交换的消息驱动；Dex Context分别支持单后端和多后端两种设置，对于单后端设置，Dex Context通过Dex Context API代理PostgreSQL后端进程与Spark之间的通信；启动新的会话时，客户端应用程序首先通过向Dex服务器提交连接请求来创建或重用Dex Context实例，一旦设置了Dex Context，客户端应用程序就可以使用DexContext API开始调用服务；Dex Context还支持多个后端，当在单个会话中连接多个后端时，Dex服务器引用了Dex上下文管理器，其中的每个会话都将一个Dex Context指定给一个后端；

PostgreSQL适配器在PostgreSQL扩展中实现，提供Dex通信API接口的客户端库，还包括用于将数据库队列转换为Dex请求以及将结果转换回PostgreSQL数据记录的内部函数；

Spark适配器将Dex请求解析为相应的Spark函数，开始执行任务并返回最终结果。

进一步地，数据仓库前端处理进出数据中，对于数据集成，选择支持各种数据源，包括本地和网络文件系统、关系数据库和非关系数据库；并通过数据摄取驱动程序来处理特定类型的数据源；

数据仓库前端提供控制和查询用户界面中，用户界面继承了SQL语法，并作为系统控制和交互查询的统一门户；

数据仓库前端管理底层存储中通过分片控制器在指定的主节点上运行；所有用户数据都存储在数据节点上；系统管理员通过分片注册和释放数据节点，用户为分布式事实表定义分区方案；

数据仓库前端管理底层存储中通过分析服务接口供用户在后端启动分析工作负载；并通过在PostgreSQL中重新进行解析和规划。

进一步地，数据仓库后端为由软件栈管理的计算机集群，数据仓库层被指定为不同的功能，包括资源分配、任务调度和查询组合。

进一步地，在数据仓库后端中对于单个查询，执行效率由查询优化器和执行框架共同决定；对于并发运行的许多查询，总体执行效率要求涉及任务调度程序。

进一步地，数据仓库后端使用Spark SQL作为底层查询引擎中，数据仓库后端为特定服务器群集，只有一个由YARN管理的相应Spark安装，连接到同一后端的多个会话是独立维护的；单独的Spark会话由不同的Spark作业提供服务。

进一步地，数据仓库有多个Spark集群作为后端；Spark集群具有不同的大小和配置；在Spark集群中，任何会话可以指定自己的资源需求；

数据仓库后端的资源管理中将所有后端信息记录在共享目录中，该共享目录存储在PostgreSQL主服务器上，并且可以被所有Dex Context引用；可以根据特权用户的请求添加、删除或选择数据仓库后端；

数据仓库后端包括后端会话管理器，后端会话管理器与主目录共享公共信息，该主目录维护所有活动会话的超集；后端会话管理器上的每个会话仅存储会话特定的元数据；该元数据包括有关数据仓库前端、数据仓库后端和网络连接的重要事实；元数据将用于请求处理，一旦接收并解析了前端请求，就会生成ReqStruct类型的请求数据结构，此时需要查找会话元数据以识别请求中出现的输入和功能；数据仓库前端和数据仓库后端之间的通信是使用高速异步网络I/O库的ZeroMQ来实现。

进一步地，Spark适配器负责处理来自Dex中间件的请求；当收到前端请求时，该请求会被转换为Spark命令，包括已解除的SQL查询或Spark函数，以及定义辅助RDD的pro-logue和epilogue命令；Duo SQL支持两种类型的分析请求：一种是SQL查询，另一种是UDF调用；每个Dex请求在其标头中对其类型进行编码。

进一步地，在Spark SQL中，JdbcRDD用于从远程数据库导入数据的标准API；JdbcRDD允许并行连接到单个表的多个分区，增强了对分片数据库的支持,是一个shard的JBDCRDD；使用DuoRDD，Spark执行程序可以并行地从多个分片节点加载。

本发明实施例中的解耦合的弹性数据仓库架构，通过将数据管理和数据计算功能相分离，以实现独立的可扩展性，探索了云的弹性数据仓库体系结构。数据仓库前端接收数据、管理存储并提供高可用性。数据仓库后端用于数据分析的查询。通过分离数据管理和数据计算，本发明可以在单一的数据仓库中获得弹性。

附图说明

此处所说明的附图用来提供对本发明的进一步理解，构成本申请的一部分，本发明的示意性实施例及其说明用于解释本发明，并不构成对本发明的不当限定。在附图中：

图1为本发明中DuoSQL的体系结构示意图；

图2为本发明中Dex作为中间件进行数据协调的结构示意图；

图3为本发明中新Spark API扩展了JdbcRDD的过程图；

图4为本发明中Duo SQL系统执行流程图。

具体实施方式

为了使本技术领域的人员更好地理解本发明方案，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分的实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都应当属于本发明保护的范围。

需要说明的是，本发明的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本发明的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

作为优选的技术方案中，Dex中间件包括：Dex服务器、PostgreSQL适配器和Spark适配器，并通过Dex通信API运行，Dex通信API提供了一个中间层，其中：

作为优选的技术方案中，Dex互操作是在Dex服务器中围绕Dex Context管理的有状态服务，内部工作由PostgreSQL和Spark之间交换的消息驱动；Dex Context分别支持单后端和多后端两种设置，对于单后端设置，Dex Context通过Dex Context API代理PostgreSQL后端进程与Spark之间的通信；启动新的会话时，客户端应用程序首先通过向Dex服务器提交连接请求来创建或重用Dex Context实例，一旦设置了DexContext，客户端应用程序就可以使用Dex Context API开始调用服务；Dex Context还支持多个后端，当在单个会话中连接多个后端时，Dex服务器引用了Dex上下文管理器，其中的每个会话都将一个Dex Context指定给一个后端；

作为优选的技术方案中，数据仓库前端处理进出数据中，对于数据集成，选择支持各种数据源，包括本地和网络文件系统、关系数据库和非关系数据库；并通过数据摄取驱动程序来处理特定类型的数据源；

作为优选的技术方案中，数据仓库后端为由软件栈管理的计算机集群，数据仓库层被指定为不同的功能，包括资源分配、任务调度和查询组合。

作为优选的技术方案中，在数据仓库后端中对于单个查询，执行效率由查询优化器和执行框架共同决定；对于并发运行的许多查询，总体执行效率要求涉及任务调度程序。

作为优选的技术方案中，数据仓库后端使用Spark SQL作为底层查询引擎中，数据仓库后端为特定服务器群集，只有一个由YARN管理的相应Spark安装，连接到同一后端的多个会话是独立维护的；单独的Spark会话由不同的Spark作业提供服务。

作为优选的技术方案中，数据仓库有多个Spark集群作为后端；Spark集群具有不同的大小和配置；在Spark集群中，任何会话可以指定自己的资源需求；

作为优选的技术方案中，Spark适配器负责处理来自Dex中间件的请求；当收到前端请求时，该请求会被转换为Spark命令，包括已解除的SQL查询或Spark函数，以及定义辅助RDD的pro-logue和epilogue命令；DuoSQL支持两种类型的分析请求：一种是SQL查询，另一种是UDF调用；每个Dex请求在其标头中对其类型进行编码。

作为优选的技术方案中，在Spark SQL中，JdbcRDD用于从远程数据库导入数据的标准API；JdbcRDD允许并行连接到单个表的多个分区，增强了对分片数据库的支持,是一个shard的JBDCRDD；使用DuoRDD，Spark执行程序可以并行地从多个分片节点加载。

在本发明具体实施例中，本发明探讨了一种将数据管理和数据计算分离的体系结构。通过将这两个部分分开，系统获得了更多的弹性和适应性。为了实现，本发明构建了一个基于PostgreSQL和Spark的原型系统DuoSQL。同时本发明使用TPC-H基准来验证系统。实验结果表明，该解耦算法具有很大的性能潜力。

本发明通过将数据管理和数据计算功能相分离，以实现独立的可扩展性，探索了云的弹性数据仓库体系结构。数据仓库前端(数据管理单元)接收数据、管理存储并提供高可用性。数据仓库后端(数据计算单元)用于数据分析的查询。通过分离数据管理和数据计算，本发明可以在单一的数据仓库中获得弹性，这是一种现有系统所不具备的特性。相比之下，Microsoft Azure云数据库只允许跨多个数据仓库进行弹性处理。本发明使数据仓库在面对不断变化的工作负载需求时具有更强的适应性。本发明使用一个RDBMS和一个具有SQL支持的内存集群计算引擎来实现该体系结构。具体来说，本发明基于PostgreSQL和Spark构建了一个名为DuoSQL的原型系统。首先，本发明提出了一种云数据仓库架构，它可以解耦数据管理和数据计算，从而在单个数据仓库中实现弹性。其次，本发明基于PostgreSQL和Spark构建了一个名为DuoSQL的原型系统，实验结果显示出很好的性能潜力。

本发明公开了一种解耦合的弹性数据仓库架构，为使本发明的目的及技术方案更加清楚明确，以下参照附图并举实例对本发明进一步详细说明。应当理解，此处所描述的具体实施例仅用以解释本发明，并非用于限定本发明。

弹性数据仓库架构，基于弹性配置，主要从存储平台和计算平台的弹性配置出发，再辅助于通信中间件。弹性数据仓由以下几个方面来介绍：

1.1体系结构：

图1显示了DuoSQL的体系结构。整个体系结构将数据管理前端和数据计算后端结合起来。只要选择满足设计目标的子系统，体系结构就支持前端和后端的各种子系统。为了集成前端和后端，需要一个内部操作中间件来管理网络工作连接、用户会话、请求代理、查询翻译和数据传输。

1.2内部设计：

1.2.1前端

如图1左侧所示，前端是数据仓库的数据管理组件，其主要职责如下：

(1)处理进出数据。对于数据集成，前端可以选择支持各种数据源，例如本地和网络文件系统、关系数据库和非关系数据库。可能需要数据摄取驱动程序来处理特定类型的数据源。

(2)提供控制和查询用户界面。用户界面继承了SQL语法，并作为系统控制和交互查询的统一门户。

(3)管理底层存储。当受管数据的大小太大，不适合本地存储时，切分是不可避免的。对于一个OLAP数据库，切分严重地使查询计划和执行复杂化。因此，针对分片数据的查询规划的复杂性从数据管理单元转移到了数据计算单元。

1.2.2后端

后端是进行实际分析计算的地方。它是一个完全由软件栈管理的计算机集群，以保证效率和灵活性。在这个软件栈中，数据仓库层被指定为不同的功能，如资源分配、任务调度和查询组合。这些层一起用于以下两个目的：

(1)可扩展和弹性的资源管理。资源分配分两个阶段进行。第一个阶段是在安装时，总资源最初是从云端分配的。第二个阶段是在集群设置之后，用户可以在会话启动时传递参数，如工作线程数、核心和内存总量。通过允许两阶段分配，系统提供粗粒度和细粒度资源弹性。

(2)查询效率。后端的中心任务是尽可能快地完成提交的查询。对于单个查询，执行效率由查询优化器和执行框架共同决定。对于并发运行的许多查询，总体执行效率要求涉及任务调度程序。为提高大数据分析学的查询效率，进行了大量的工作。建立一个以现有技术为基础的原型系统。

总之，后端应确保有效处理单个和并发运行的查询。有了这个目标，许多现代分布的计算框架，如Apache Spark SQL和Apache CalcTITE，在一个合格的资源管理器(如Apache Yarn)的帮助下，可以用作后端的软件基础。

1.2.3中间件

中间件是支持分离数据仓库的关键组件。在上层，它为前端和后端提供了接口和语义抽象，以便相互通信。在较低级别，它指导客户端和服务器之间的消息交换和数据传输。中间件的设计和实施应解决以下问题：

(1)数据和接口抽象。RDBMS使用SQL管理结构化数据，而大多数大数据平台使用命令式语言接口处理非结构化数据。要跨异构系统进行通信和互操作，需要首先制定数据模型和查询接口的通用抽象。

(2)大数据集。为了以可扩展的方式管理存储并促进对相关表的查询，数据集通常在关键列上进行分片或分区，以分布在多个服务器上。对中间件进行锐化的意义在于，数据分区(可能具有不同的分区方案)应该从数据抽象、通信协议到底层数据传输机制的所有层上协同处理。

(3)数据传输。大型数据集不仅挑战存储管理，还挑战网络上的数据传输。在数据分析计算期间，后端需要从前端集群传输数据。在这个过程中，网络IO可能很容易成为瓶颈。

下面以具体实施过程对本发明继进行详细描述。

2.1前端

Duo SQL使用PostgreSQL作为前端的基础。使PostgreSQL脱颖而出的优势在于它对编写数据库扩展的出色支持。实际上，大多数Duo SQL的前端逻辑都是在PostgreSQL扩展中实现的，大多数用户界面函数都是UDF中的形式。

分片：如前所述，大数据集的管理存储需要分片支持。虽然PostgreSQL严格来说是一个关系型数据库，并且本身不支持分片，但有几个用于分片的开源扩展可以作为参考。具体来说，本发明的解决方案基于pg_shardman。本发明在名为xschema的PostgreSQL扩展中实现所有分片逻辑。在扩展内部，一组分片控制器功能和分片目录表定义如下。

FUNCTIONS

xschema.add_data_node

xschema.remove_data_node

xschema.partition_table

xschema.rebalance_partitions

CATALOG

xschema.data_nodes

xschema.data_tables

xschema.data_partitions

xschema.data_replicas

…

分片控制器在指定的主节点上运行。所有用户数据都存储在数据节点上。通过分片，系统管理员可以注册和释放数据节点以便数据传播，而用户可以为分布式事实表定义分区方案。

分析服务接口：本发明还需要一个接口，供用户在后端启动分析工作负载。最终，通过在PostgreSQL中重新进行解析和规划，可以使服务调用对用户透明。目前，Duo SQL分析服务是通过一组UDF调用的，包括连接到后端，运行SQL查询和调用远程函数的函数。

2.2中间件

本发明使用如图2的Dex作为中间件来协调前端和后端之间的消息传递和数据传输。Dex最初设计为连接异构数据平台(如PostgreSQL和Spark)的互操作框架。在现有技术中，Dex不支持分片前端，也不完全利用Spark的SQL查询引擎。本发明在Duo SQL中对它进行调整以支持两者。

Dex中间件由三个主要组件组成，Dex服务器、PostgreSQL适配器和Spark适配器，通过Dex通信API运行。PostgreSQL适配器转换数据库查询，与Dex服务器通信，然后从后端群集转换返回的响应。Dex服务器维护查询上下文，监视会话状态转换并通过Dex通信API提供Dex服务。Spark适配器接受并解析Dex requests，将Dex请求转换为一系列Spark计算任务，一旦响应准备好，就将其发送回Dex服务器。Dex通信API提供了一个中间层，使终端系统能够与纯隔离和抽象进行通信。

Dex Context：Dex互操作是在Dex服务器中围绕Dex Context管理的有状态服务。内部工作由PostgreSQL和Spark之间交换的消息驱动。Dex Context分别支持单后端和多后端的两种设置。对于单后端设置，Dex Context通过Dex Context API代理PostgreSQL后端进程与Spark之间的通信。要启动新的会话，客户端应用程序必须首先通过向Dex服务器提交连接请求来创建或重用Dex Context实例。一旦设置了Dex Context，客户端应用程序就可以使用Dex Context API开始调用服务。Dex Context还支持多个后端。与单个后端情况相比，当在单个会话中连接多个后端时，Dex服务器需要能够维持所有状态。当然，这引入了Dex上下文管理器，它确保每个会话将一个Dex Context指定给一个后端。

PostgreSQL Adapter：PostgreSQL适配器在PostgreSQL扩展中实现。它用作提供Dex通信API接口的客户端库。它还包括用于将数据库队列转换为Dex请求以及将结果转换回PostgreSQL数据记录的内部函数。

Spark Adapter：Spark Adapter是Spark中的一个模块，它将Dex请求解析为相应的Spark函数，开始执行任务并返回最终结果。

2.3后端

Duo SQL的后端使用Spark SQL作为底层查询引擎。本发明始终将后端称为特定服务器群集，无论是虚拟还是物理分配。在一个后端群集中，只有一个由YARN管理的相应Spark安装。然而，连接到同一后端的多个会话是独立维护的。在Spark领域，单独的Spark会话由不同的Spark作业提供服务。

弹性：后端弹性以多个级别提供。首先，数据仓库可以有多个Spark集群作为后端。其次，Spark集群可以具有不同的大小和配置。第三，在Spark集群中，任何会话也可以指定自己的资源需求，例如总执行程序内存和核心数。

后端管理：Duo SQL将所有后端信息记录在共享目录中，该目录存储在PostgreSQL主服务器上，并且可以被所有Dex Context引用。由于Duo SQL是一个解决耦合的系统，因此可以根据特权用户的请求添加、删除或选择后端。

会话管理：后端会话管理器与主目录共享一些公共信息，该目录维护所有活动会话的超集。后端上的每个会话仅存储会话特定的元数据。此元数据包括有关前端、后端和网络连接的重要事实，例如，分片节点、数据库名称、分片表、分区、Spark上的可用功能、数据库连接字符串和ZeroMQ处理程序。元数据将用于请求处理。一旦接收并解析了前端请求，就会生成ReqStruct类型的请求数据结构。此时，需要查找会话元数据以识别请求中出现的输入和功能。前端和后端之间的通信是使用ZeroMQ实现的，ZeroMQ是一个高速异步网络I/O库。

请求处理：Spark Adapter负责处理来自Dex中间件的请求。当收到前端请求时，它可能会被转换为一系列Spark命令，可能包括已解除的SQL查询或Spark函数，以及一些定义辅助RDD的pro-logue和epilogue命令。Duo SQL支持两种类型的分析请求：一种是SQL查询，另一种是UDF调用。每个Dex请求在其标头中对其类型进行编码。请求处理器使用此信息来确定如何翻译请求内容。

并行数据传输：对于像Duo SQL这样的解耦合系统，几乎总是依赖于通过网络批量传输数据。对于分析大型数据集，并行传输可以显著减少总执行时间。在Spark SQL中，JdbcRDD是用于从远程数据库导入数据的标准API。JdbcRDD的一个功能是允许并行连接到单个表的多个分区，从而实现并行数据传输。但是，JdbcRDD的并行连接功能不适用于分片数据库。为了克服这一挑战，如图3所示，本发明开发了一个名为DuoRDD的新Spark API，它扩展了JdbcRDD，增强了对分片数据库的支持,是一个shard的JBDCRDD。使用DuoRDD，Spark执行程序可以并行地从多个分片节点加载。

示例图4来演示如何在系统中执行用户请求。步骤1：用户提交一个包含PostgreSQL请求的SQL。然后，步骤2是接口调用上下文API来执行相应的请求。如果用户在执行请求时提交多个请求，Duo SQL将为其他请求创建另一个上下文。然后步骤3是中间件适配器，分析用户发起的请求，根据不同的功能生成不同的ReqStruct。第四步是Spark适配器对中间件适配器发送的请求进行分析，执行请求并返回结果，其中还包括来自PostgreSQL集群的Spark请求数据。在Spark适配器上，Duo SQL在多线集群管理上启动了Spark作业。所有ReqStruct都在这个Spark作业中处理，以减少Spark作业启动的时间。最后，最终的执行结果将返回到下一个级别，直到返回到用户。系统各个组件之间的交互反映在过程中。通过中间件的设计，PostgreSQL和Spark之间没有直接的交互。

本发明的创新技术点及有益效果至少在于：

1.其中解耦合、资源弹性配置和后端多样性的三者综合运用。在系统中，前后端通过消息中间件来传递，同时前后端的资源弹性配置，前端是通过分布式数据库管理系统完成，后端通过Yarn资源管理器完成的。选择不同的后端系统时，可以利用到不同的后台特性，目前可以用到Spark的相关特性。

2.本发明通过解耦合数据管理和计算来提出弹性数据仓库架构。本发明通过使用Dex互操作中间件，将一个分片的PostgreSQL数据库作为前端和一个Spark集群作为后端来构建一个原型系统Duo SQL。本发明通过将它与具有和不具有并行查询支持的独立PostgreSQL进行比较来评估Duo SQL的性能潜力。本发明运行具有不同工作负载和输入类型的测试实验。结果表明，Duo SQL不仅具有明显的性能优势，而且还具有出色的稳健性。

本发明提出的一种解耦合的弹性数据仓库架构，其优点在于三个重要的特性：解耦合、弹性和多样性。解耦合，本发明的设计是把计算和存储完全分离的设计。其次，弹性是本发明最大的考虑点。弹性，即能够独立自适应地扩展系统组件的能力，是云数据仓库应该支持的主要属性。另外它还可以利用后端的多样性，来多样化数据仓库，比如本发明中使用的Spark，那么此次实验就利用到来Spark的内存迭代式计算等等特点，本发明是可以由用户来确定使用不同的后端的。

采用OLAP数据分析基准测试TPC-H和机器学习算法验证了本发明系统结构的有效性。在TPC-H的实验中，本发明和非存储计算分离的情况下的结构作了对比，包括了30、50、75规模因子下的TPC-H实验。在机器学习算法中，本发明和ApahceMADlib框架下的PostgreSQL作了聚类算法对比，数据来自UCI的skin_noskin数据集和KGEE数据集。实验的结果来看，都基本优于现有结构。

上述本发明实施例序号仅仅为了描述，不代表实施例的优劣。

在本发明的上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其他实施例的相关描述。

在本申请所提供的几个实施例中，应该理解到，所揭露的技术内容，可通过其它的方式实现。其中，以上所描述的系统实施例仅仅是示意性的，例如单元的划分，可以为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，单元或模块的间接耦合或通信连接，可以是电性或其它的形式。

作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本发明各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可为个人计算机、服务器或者网络设备等)执行本发明各个实施例方法的全部或部分步骤。而前述的存储介质包括：U盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、移动硬盘、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述仅是本发明的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本发明的保护范围。

Claims

1.一种解耦合的弹性数据仓库架构，其特征在于，包括：

数据仓库后端，用于可扩展和弹性的资源管理、单个或并发查询；其中资源分配分两个阶段进行，第一个阶段是在安装时，总资源最初是从云端分配；第二个阶段是在集群设置之后，用户在会话启动时传递参数；并使用Spark SQL作为底层查询引擎；

2.根据权利要求1所述的解耦合的弹性数据仓库架构，其特征在于，Dex中间件包括：Dex服务器、PostgreSQL适配器和Spark适配器，并通过Dex通信API运行，Dex通信API提供了一个中间层，其中：

3.根据权利要求2所述的解耦合的弹性数据仓库架构，其特征在于，Dex互操作是在Dex服务器中围绕Dex Context管理的有状态服务，内部工作由PostgreSQL和Spark之间交换的消息驱动；Dex Context分别支持单后端和多后端两种设置，对于单后端设置，Dex Context通过Dex Context API代理PostgreSQL后端进程与Spark之间的通信；启动新的会话时，客户端应用程序首先通过向Dex服务器提交连接请求来创建或重用DexContext实例，一旦设置了Dex Context，客户端应用程序就使用Dex Context API开始调用服务；Dex Context还支持多个后端，当在单个会话中连接多个后端时，Dex服务器引用Dex上下文管理器，其中的每个会话都将一个Dex Context指定给一个后端；

4.根据权利要求1所述的解耦合的弹性数据仓库架构，其特征在于，数据仓库前端处理进出数据中，对于数据集成，选择支持各种数据源，包括本地和网络文件系统、关系数据库和非关系数据库；并通过数据摄取驱动程序处理特定类型的数据源；

数据仓库前端提供控制和查询用户界面，用户界面继承了SQL语法，并作为系统控制和交互查询的统一门户；

数据仓库前端管理底层存储通过分片控制器在指定的主节点上运行；所有用户数据都存储在数据节点上；系统管理员分片注册和释放数据节点，用户为分布式事实表定义分区方案；

数据仓库前端管理底层存储通过分析服务接口供用户在后端启动分析工作负载；并通过在PostgreSQL中重新进行解析和规划。

5.根据权利要求1所述的解耦合的弹性数据仓库架构，其特征在于，数据仓库后端为由软件栈管理的计算机集群，数据仓库层被指定为不同的功能，包括资源分配、任务调度和查询组合。

6.根据权利要求1所述的解耦合的弹性数据仓库架构，其特征在于，在数据仓库后端中对于单个查询，执行效率由查询优化器和执行框架共同决定；对于并发运行的多个查询，总体执行效率还涉及任务调度程序。

7.根据权利要求3所述的解耦合的弹性数据仓库架构，其特征在于，数据仓库后端使用Spark SQL作为底层查询引擎，数据仓库后端为特定服务器群集，只有一个由YARN管理的相应Spark安装，连接到同一后端的多个会话是独立维护的；单独的Spark会话由不同的Spark作业提供服务。

8.根据权利要求7所述的解耦合的弹性数据仓库架构，其特征在于，数据仓库有多个Spark集群作为后端；Spark集群具有不同的大小和配置；在Spark集群中，任何会话均可指定自己的资源需求；

数据仓库后端包括后端会话管理器，后端会话管理器与主目录共享公共信息，该主目录维护所有活动会话的超集；后端会话管理器上的每个会话仅存储会话特定的元数据；该元数据包括有关数据仓库前端、数据仓库后端和网络连接的重要事实；所述元数据用于请求处理，一旦接收并解析了前端请求，就会生成ReqStruct类型的请求数据结构，此时要查找会话元数据以识别请求中出现的输入和功能；数据仓库前端和数据仓库后端之间的通信使用高速异步网络I/O库的ZeroMQ来实现。

9.根据权利要求8所述的解耦合的弹性数据仓库架构，其特征在于，Spark适配器负责处理来自Dex中间件的请求；当收到前端请求时，该请求被转换为Spark命令，包括已解除的SQL查询或Spark函数，以及定义辅助RDD的pro-logue和epilogue命令；Duo SQL支持两种类型的分析请求：一种是SQL查询，另一种是UDF调用；每个Dex请求在其标头中对其类型进行编码。

10.根据权利要求9所述的解耦合的弹性数据仓库架构，其特征在于，在Spark SQL中，JdbcRDD用于从远程数据库导入数据的标准API；JdbcRDD允许并行连接到单个表的多个分区，增强对分片数据库的支持,是一个shard的JBDCRDD；使用DuoRDD，Spark执行程序并行地从多个分片节点加载。