一种基于分布式数据仓库的社保数据联机分析处理系统的制作方法

本发明涉及联机分析处理和分布式存储领域，尤其是指一种基于分布式数据仓库的社保数据联机分析处理系统。

背景技术：

随着信息化技术的不断发展完善，政府、企业等机构累积产生了大量业务数据，如何从这类数据中提取有用信息，便于判断形势，对未来发展作出决策，成为决策者关心的重要问题。企业级别的系统应用往往达到了TB、PB甚至更高的数据量，而对于决策者而言，重要的决策参考信息常常就被淹没在其中。目前十分通用的做法是，从海量数据中提炼出有助于决策分析的数据信息，存放到数据变动相对较小的数据仓库中，作为对海量数据进行筛选后的数据环境。再基于数据仓库的数据，进行联机分析处理，得到相关的决策信息。我国的社会保障信息化管理虽然经过多年的发展完善，但当下对五种社会保障信息系统的管理，仍然很难与其他现有独立系统有效交互，更不用说直接进行操作。事务同步和数据共享程度较低，明显影响劳动和社会保障信息的使用效率。

联机分析处理(OLAP)是一个将原始数据转化为贴近用户所理解的业务维度的，提供从各种可能地视角观察信息的软件技术，便于分析师、管理者和执行者来快速、一致、交互地访问数据。OLAP的功能特点是提供动态多维的分析整合企业数据，支持终端用户分析和定位活动，包括各个维度的计算和建模应用，通过层次结构和成员进行趋势分析，对子集切片细致查看，钻取到更深的层次，旋转到新的维度进行可见的区域比较等。

传统的数据仓库一般采用集中式结构化数据存储方式，单节点运行计算，配置起来比较简单，对结构化数据的处理速度也比较快，同时，受服务器硬件性能的影响也比较大。但是在社保数据应用中，往往要对多张数据表中成千上万条数据进行综合查询，传统数据仓库的性能越来越难以满足这类复杂的查询需求。随着数据量的积累，数据仓库迟早会有需要扩容的时候，而传统数据仓库由于采用集中式存储方式，扩容的代价是巨大的，往往需要将原有存储介质整体替换。

对于数据仓库的查询，往往是对海量数据的范围查询，并不需要太高的实时性，对于查询任务的处理也可以分批次进行，因此数据仓库系统特别适合使用分布式数据解决方案。

对海量社保数据的多维查询分析，查询速度是评价系统性能的关键因素，针对多维立方体查询的优化，有几个比较常见的优化方法：存储过程，索引技术，物化视图。存储过程对针对特定的查询创建查询语句群，将语句经过编译优化并存储在数据库中，以此来优化查询效率，但是在分布式文件系统中，很少见有对于存储过程、索引技术的支持，这些技术对于分布式文件系统也并不适用。而物化视图则是一种典型的用空间换取时间的方法，通过建立实体视图达到减少表连接消耗时间的目的，在本文所依据项目中，由于涉及到多种社会保障服务，为每个服务建立物化视图将会带来时间信息、地理信息等方面的巨大冗余，因此这种方法也是不尽如人意的。

根据数据存储方式，联机分析处理可以分为三类：关系型OLAP、多维OLAP、混合型OLAP：

关系型OLAP将数据存储在关系数据库中，就像传统数据表一样，不同的是，它还会定义一批实视图，与业务数据一同存储在数据库中，这与传统关系型数据库只存储视图的定义结构截然不同。这样做的原因在于定义使用频率比较高，计算量比较大的查询作为实视图可以很大程度上减少查询所需要的耗时。

多维OLAP将多维数据在物理上存储为多维数组格式，因此也被成为物理OLAP。而关系型OLAP主要通过一些中间软件实现立方体，被称为虚拟OLAP。

混合型OLAP目前为止尚没有一个完全清晰的定义，但是显然，它不是单纯的将ROLAP和MOLAP组合起来，应当结合具体的业务逻辑，将两种OLAP的优点有机地组合起来。

内存数据库系统是指将数据库的全部或大部分数据放在内存中的数据库系统，内存数据库中数据是常驻内存，处理前不需要从磁盘读取数据，处理后也不需要将结果写回磁盘，节省了磁盘I/O的时间，一般都具有很高的查询性能,适合要求快速响应的系统。本发明针对的海量社保数据无法完全存储在内存当中，但针对社保数据对五险一金操作比较多的特性，我们从海量社保数据中提取出常见的如医疗金、失业金、养老金等类目的数据模型，将这些常用模型用NoSQL内存数据库作为存储空间，使其常驻内存，实现对常用业务数据的快速存取。

当前国内外关于大数据联机分析处理的研究成果多种多样，但至今未见针对社保应用海量数据实现的多级分布式的联机分析处理方法及系统。针对海量社保数据，研究一个真正实用、可靠的数据统计分析方法及系统，保证实际应用中社保数据存储的可靠性、查询的实时性是本发明的重点。

技术实现要素：

本发明的目的在于克服现有技术的不足，提供一种基于分布式数据仓库的社保数据联机分析处理系统，针对海量社保数据，能够快速响应查询请求，提升查询效率。

为实现上述目的，本发明所提供的技术方案，如下：

一种基于分布式数据仓库的社保数据联机分析处理系统，从上至下划分为4层，包括：

展示层，是用户与多维分析服务器进行交互的层次，将分析计算的结果展现给用户，而该展示层主要通过前端工具提供服务，通过查询接口得到多维分析结果，其实现的查询接口，在建立连接时，能够像注册JDBC驱动一样注册连接驱动，通过通用接口Connection加载指定的OLAP驱动，随后获取连接，获取连接后，通过创建声明对象执行查询得到结果；

维度层，主要对MDX语句进行解析，并使用解析后的语句执行查询计算；一个MDX查询在得到最终结果之前，往往需要经过数次迭代求值计算，并对每次的计算结果汇总处理；在该维度层中，首先，计算结果集中每个轴包含的成员列表，再计算需要聚集计算的单元格，最后将聚集计算请求批量提交到星状层；MDX查询结果能够在维度层中缓存，如果用户需要对查询结果作进一步操作，系统就不需要重新处理完整的查询请求，能够直接在维度层中缓存的查询结果基础上进行处理，得到新的查询结果，从而提高解析查询的效率；

星状层，主要对聚集结果的缓存进行管理；该星状层处理维度层发出的提取聚集结果请求，在收到请求后，首先在缓存的聚集结果中搜索，如果请求结果存在，或缓存中现有结果能够经过计算后生成请求对应的结果，就能够直接从缓存中提取或者计算生成结果；如果不能通过缓存提供请求结果，则将请求转化为SQL查询，提交给存储层处理；星状层获得存储层的计算结果后，再将结果加入缓存；

存储层，负责接收星状层发出的SQL语句，在数据仓库中执行，并将结果返回给星状层；存储层作为永久存储，以数据仓库为基础，拥有全部的业务数据；作为高速缓存的NoSQL内存数据库，则存储着常用的社保业务数据。

所述存储层使用了嵌套型的列式存储方式，构造了一个基于列的索引树，能够将同一列的重复数据进行压缩，查询时读取以压缩格式存储的每一列数据，并消耗CPU解压数据；列式查询对于重复率高的数据列能够快速跳过，对于海量社保数据的查询能够大幅减少查询消耗时间；通过对社保海量数据按关键列进行分区存储的优化方法，还能够进一步提高查询命中率，增强海量数据查询的实时性。

本发明与现有技术相比，具有如下优点与有益效果：

1、本发明结合多种数据分析模型的优点，提出一种基于分布式数据仓库的社保数据联机分析处理系统。该系统的数据仓库通过分布式文件系统实现，而分布式文件系统集群由云计算平台统一管理，实现资源的负载均衡。系统通过功能上的多层分发，实现了对存储海量数据的分布式数据仓库的统一查询接口，以类似JDBC的查询方式，完成对于数据立方体多个维度的操作。

2、本发明使用了嵌套型的列式存储方式，嵌套数据类型的特点是一个记录中的列除了可以是原语类型以外，还可以是List,Map,Set这样的复杂类型。在行式存储中一行的多列是连续的写在一起的，在列式存储中数据按列分开存储，将数据划分成一个个的数据文件的行组，查询时读取以压缩格式存储的每一列数据，并消耗CPU解压数据。列式存储方式十分适用于经常对少数列进行批量查询OLAP分析应用，当面对海量数据时，列式查询可以极大减少查询需要扫描的数据量，从而提升查询效率。该技术应用在社保大数据平台当中的结果表明它能够使多维数据统计分析应用快速响应海量社保数据的查询请求，得到实时多维分析结果。

附图说明

图1为社保数据联机分析处理系统结构图。

图2为社保数据联机分析处理系统层次图。

图3为引入了内存数据库的社保业务数据库结构图。

图4为行、列存储方式查询测试时间对比图。

图5为社保大数据公共服务平台系统架构图。

具体实施方式

下面结合具体实施例对本发明作进一步说明。

如图1和图2所示，本实施例所述的社保数据联机分析处理系统，主要是基于分布式数据仓库(作为社保数据统计分析的存储空间)，该系统的数据仓库是通过分布式文件系统实现，而分布式文件系统集群由云计算平台统一管理，实现资源的负载均衡。系统通过功能上的多层分发，实现了对存储海量数据的分布式数据仓库的统一查询接口，以类似JDBC的查询方式，完成对于数据立方体多个维度的操作。该社保数据联机分析处理系统在逻辑上从上至下划分为4层：

展示层，是用户与多维分析服务器进行交互的层次，将分析计算的结果展现给用户。展示层主要通过前端工具提供服务，通过查询接口得到多维分析结果。本发明实现的查询接口，在建立连接时，可以像注册JDBC驱动一样注册连接驱动，它通过通用接口Connection加载指定的OLAP驱动，随后获取连接。获取连接后，通过创建声明对象执行查询得到结果。

维度层，主要对MDX语句进行解析，并使用解析后的语句执行查询计算。一个MDX查询在得到最终结果之前，往往需要经过数次迭代求值计算，并对每次的计算结果汇总处理。维度层首先计算结果集中每个轴包含的成员列表，再计算需要聚集计算的单元格，最后将聚集计算请求批量提交到星状层。MDX查询结果可以在维度层中缓存，如果用户需要对查询结果作进一步操作，系统就不需要重新处理完整的查询请求，可以直接在维度层中缓存的查询结果基础上进行处理，得到新的查询结果，进而大大提高解析查询的效率。

星状层，主要对聚集结果的缓存进行管理。星状层处理维度层发出的提取聚集结果请求，在收到请求后，星状层首先在缓存的聚集结果中搜索，如果请求结果存在，或缓存中现有结果可以经过计算后生成请求对应的结果，就可以直接从缓存中提取或者计算生成结果。如果不能通过缓存提供请求结果，则将请求转化为SQL查询，提交给存储层处理。星状层获得存储层的计算结果后，再将结果加入缓存。

存储层，负责接收星状层发出的SQL语句，在数据仓库中执行，并将结果返回给星状层。存储层作为永久存储，以数据仓库为基础，拥有全部的业务数据；作为高速缓存的NoSQL内存数据库，则存储着常用的社保业务数据。

传统的分布式文件系统，采用批处理方式执行任务，实时性能表现不够好。本发明系统针对此种弊端，其存储层采取多级列式存储方式，达到优化数据查询分析效率的目的。引入了内存数据库的社保业务数据库结构在原有磁盘数据库之上，增加了一层内存数据库，将需要快速访问的表由磁盘数据库缓存到内存数据库。内存数据库承担日常的五险一金业务处理工作，联机分析处理应用使用JDBC进行访问。磁盘数据库只完成少量工作，并兼具容灾功能，内存数据库和磁盘数据库之间进行数据同步,实现两个数据库的一致性。同时，为保证高可用性，内存数据库以双机热备方式进行工作。附图3是引入了内存数据库的社保业务数据库结构图。

列式存储相对于行式存储，具有如下优势：

1、列式存储可以跳过大量不符合筛选条件的数据，只读取需要的数据，降低IO数据量。

2、压缩编码可以减少表占用的空间，由于同一列的数据类型一致，可以使用压缩编码进一步节省空间。

3、列式存储支持向量运算，能获得更好的扫描性能。

关系型数据的列式存储，可以将数据按照列直接排列，不需要引入其他概念，也不会造成数据丢失。而本发明系统具体采用的是另一种存储方式——嵌套型的列式存储。嵌套数据类型的特点是一个记录中的列除了可以是原语类型以外，还可以是List,Map,Set这样的复杂类型。在行式存储中一行的多列是连续的写在一起的，在列式存储中数据按列分开存储，将数据划分成一个个的数据文件的行组，查询时读取以压缩格式存储的每一列数据，并消耗CPU解压数据。列式存储方式十分适用于经常对少数列进行批量查询OLAP分析应用，当面对海量数据时，列式查询可以极大减少查询需要扫描的数据量，从而提升查询效率。

采用列存储格式存储数据，对于OLAP常见的在少数几个列进行聚集运算的特性，列存储格式可以通过关键列的筛选，极大减少需要扫描的数据量，从而提升查询效率。本发明列式存储与传统行式存储查询效率对比如附图4所示，测试数据为3000w条记录，分别对不同数量的字段进行max()聚集函数操作。字段数量的变化，对于行存储格式影响较小，所消耗时间基本保持稳定；而对于列存储格式，查询中涉及的字段越多，耗费的时间也越大。这也印证了前文描述的行、列存储的设计思想。在查询的字段达到50个时，列存储方式的耗时上升到了15秒左右，而行存储方式仍然维持在30秒左右。考虑到本系统查询设计的字段一般在10个甚至5个以内，列存储方式在查询性能上带来的提升是显著的。

为了测试本实施例上述的社保数据联机分析处理系统的应用效果，我们将这一技术应用到某社保大数据平台当中。该社保大数据公共服务平台的系统架构图如附图5所示。该系统上实现的联机分析处理系统主要包括四部分：一是负责数据存储的列式分布式文件系统；二是负责响应请求的Web服务器；三是负责构建查询任务的查询分析服务器；四是实际访问数据仓库的数据处理服务器。以上服务器均建立在云存储平台，通过云平台实现资源的负载均衡。

其中Web服务器负责接收响应用户提交的请求以及用户界面的交互。例如用户提交一个OLAP查询分析请求到服务器，Web服务器解析请求并转发到查询分析服务器，获取返回的结果，并以图表报表的形式显示到前端页面。查询分析服务器负责响应执行多维查询分析的任务，通过运行OLAP引擎得到查询结果，并将结果集返回。数据处理服务器负责响应执行数据预处理、实际访问操作数据仓库的任务，对于任何涉及到数据仓库的访问操作，均由数据处理服务器执行并返回结果。用户在支持主流浏览器的终端上登陆网站，即可开始使用本系统。

对于联机分析处理的性能考量，主要从执行查询分析的效率上体现。为验证OLAP查询性能，在列式分布式文件系统上按照查询维度的划分，分别进行均值、计数、求和三个最常见的聚集计算的点查询和范围查询测试。本次测试共五组测试数据集，大小依次为1000万条、2000万条、4000万条、8000万条、1亿6000万条数据，以下实验都是基于这五组数据测试得出的结果。

可以看到，对单一维度点查询，三种聚集函数的表现基本一致，在数据量达到上亿条时，仍能在38秒内完成查询；对单一维度范围查询，相对单点查询耗时稍微多一些，在数据量达到上亿条时，响应时间在51秒内；对二维求交查询，相对一维查询耗时更多，但在数据量达到上亿条时，仍能在80秒内完成查询。

以上所述实施例只为本发明之较佳实施例，并非以此限制本发明的实施范围，故凡依本发明之形状、原理所作的变化，均应涵盖在本发明的保护范围内。