CN114647716A

CN114647716A - 一种泛化数据仓库

Info

Publication number: CN114647716A
Application number: CN202210516778.2A
Authority: CN
Inventors: 杨伟伟; 郑贵德; 李景瑞
Original assignee: Tianjin Nankai University General Data Technologies Co ltd
Current assignee: Tianjin Nankai University General Data Technologies Co ltd
Priority date: 2022-05-13
Filing date: 2022-05-13
Publication date: 2022-06-21
Anticipated expiration: 2042-05-13
Also published as: CN114647716B

Abstract

本发明提供了一种泛化数据仓库，在传统数据仓库技术基础上设计了：虚拟数据对象、实时数据处理、跨引擎统一数据查询；虚拟数据对象类似数据视图，虚拟数据对象能够与多源异构数据源及其它虚拟对象建立映射关系；实时数据处理在传统数据仓库批数据处理分析的基础上增加实时数据操作区，对增量数据进行实时处理；跨引擎统一数据查询具备异构数据库查询能力，支持多种数据库查询引擎及非结构化数据查询引擎。本发明所述的一种泛化数据仓库，总体上通过数据服务层、数据加工层及数据基础层三个逻辑层及实时数据操作区架构形式，实现了数据仓库的泛化能力，扩展了数据仓库对大数据的适应性。

Description

一种泛化数据仓库

技术领域

本发明属于泛化数据库技术领域，尤其是涉及一种泛化数据仓库。

背景技术

数据仓库已经广泛深入应用于各行各业的数据分析，传统数据仓库只支持结构化数据，而且缺乏实时分析能力，随着大数据技术及应用的快速发展，业务管理决策分析应用对数据仓库提出了更高要求，在数据源上，像文本、图数据、流数据等非结构化数据未来也将成为重要数据来源；在数据加工处理上，一些分析应用也需要对数据源的变化及时反馈，实现实时分析。泛化数据仓库是在传统数据仓库的基础上，通过架构设计，同时引入了数据湖的一些特点，扩展了数据仓库支持的数据类型，增强实时数据分析的能力，更好支持新一代业务应用、商业智能及人工智能的需求。

数据仓库经过很多年的实际应用，其关键技术及应用环境已经发生很大变化，一些新的大数据应用现有的数据库无法满足，因此本发明提出的泛化数据仓库，通过数据仓库架构的优化，以更加敏捷、迅速地反应源数据变化，同时提供实时处理服务。

发明内容

有鉴于此，本发明旨在提出一种泛化数据仓库，以解决背景技术中存在的问题，现有的数据库无法接入多种数据，以及数据库缺乏实时分析能力，无法实现人工智能的需求的问题。

为达到上述目的，本发明的技术方案是这样实现的：

一种泛化数据仓库，包括：数据基础层，用于接入多种类型的数据库的数据，并将接入的全量数据进行存储，将接入的增量数据接入到实时数据操作区；

实时数据操作区，用于对接入的增量数据进行实时处理；

数据加工层，用于对存储的全量数据进行批处理；

数据服务层，用于对实时数据操作区内接入的增量数据实时处理的结果，以及数据加工层存储的全量数据批处理的结果进行发布；

数据服务层根据业务查询指令，对多种类型的数据库进行查询，实现跨引擎统一数据查询；

通过构建数据基础层与数据集服务层之间的数据映射关系，及数据加工层与数据服务层之间的数据映射关系形成虚拟数据对象。

进一步的，数据加工层对数据加工采用以下方法：首先对数据做聚合操作，然后加工形成明细事实数据和维表数据，并构建业务数据模型，最后根据构建的业务数据模型生成公共指标汇总数据。

进一步的，实时数据操作区对数据基础层接入的多种类型数据库内的数据处理时，在规定时间内，通过实时计算分析，并传输给数据服务层与对应类型数据库内批处理的数据合并，提供综合数据服务。

实时数据操作区包括：数据捕获组件、数据投递组件、管理组件；

数据捕获组件，用于从数据基础层以事务为单位抽取增量数据，并进行解析，从已提交的事务中过滤出需要同步数据，将同步数据写入消息队列组件中,并进一步封装成Puredata格式的数据；

数据投递组件，用于解析数据捕获组件中封装的Puredata格式的数据，从消息中间件获取同步数据并写入解析后的Puredata格式的数据中；

管理组件，用于对数据捕获组件及数据投递组件进行控制, 数据捕获组件和数据投递组件启动过程中如果有错误会将错误信息发送到管理组件并退出服务。

进一步的，全量数据和增量数据类型包括：结构化数据、文本文件数据、NOSQL数据。

进一步的，数据基础层对不同数据类型接入时分别采用不同的处理方法，具体包括：

对于增量数据接入时，通过带有时间戳的CDC工具实现实时获取；

数据接入接口接入结构化数据时，通过数据同步及日志同步导入数据；

接入文本文件数据时，通过FTP或操作脚本导入到数据仓库的分布式文件***；

接入NOSQL数据时采用***自带或第三方工具导入相应***。

进一步的，虚拟数据对象包含全量数据的组合汇聚的计算公式。

进一步的，跨引擎统一数据查询包括：解析标准 SQL、跨引擎统一调度、引擎间关联数据存储与运算、插件扩展服务、数据交换中的一个或多个；

解析标准SQL：用于接收用户发来跨数据源的SQL指令，将接收到的SQL指令转换为对应数据库内各引擎支持的指令；在解析标准SQL单元的基础上，扩展部分DDL语句的方言,提供统一查询语言访问各引擎；

跨引擎统一调度：提供对数据的统一调度能力，根据业务需要对多引擎上的数据进行调度，透明地实现跨引擎的数据关联；

跨引擎统一调度按照工作流程间的依赖关系调度执行引擎，贯穿业务处理的全流程，从数据资源的整合、加工到后续的数据处理和结果输出；

引擎间关联数据存储与运算：负责数据的关联运算，根据执行计划将参与的数据进行本地化存储；

插件扩展服务：通过可动态扩展的插件体系架构，实现下层数据查询引擎的动态扩展；插件扩展服务支持Oracle，MySql、国产数据库以及Hive、Spark和HBase非关系型数据库；

数据交换：用于不同的数据库处理引擎间，建立数据交换通道，提供引擎间共享接口，支持引擎间多对多的高效数据交换机制。

一种泛化数据仓库实现方法，包括以下步骤：

S1、数据基础层部署SQL数据库***、分布式NOSQL数据库***，利用两个数据库***接入不同的类型的全量数据或增量数据；

S2、实时数据操作区，用于对数据基础层接入的增量数据进行实时处理，处理结果为数据服务层提供数据；

S3、数据加工层基于数据基础层接入的不同的类型的全量数据或增量数据，进一步加工处理，加工处理过程中引进虚拟数据，利用虚拟数据聚合异构数据；

S4、数据服务层根据实时数据操作区、数据加工层提供的不同类型的全量数据或增量数据生成分析指标，供用户查询。

进一步的，步骤S1中SQL数据库***支持、扩展数据库子***；

分布式NOSQL数据库***支持文档数据、图数据，以及支持接入各种非结构化数据。

进一步的，步骤S2中加工处理包括数据质量保证处理、数据聚合处理、中间表及事实表生成处理、指标统计处理、数据建模处理。

相对于现有技术，本发明所述的一种泛化数据仓库具有以下优势：

（1）本发明所述的一种泛化数据仓库，通过数据基础层、数据加工层、数据服务层及一个实时数据操作区的架构形式，实现了本数据库支持多类型数据接入，可以为分析应用提供广泛的、多视角的数据源，以及为用户查询时提供实时数据处理可便于对用户的操作进行加速处理。

（2）本发明所述的一种泛化数据仓库，包括虚拟数据对象，通过虚拟数据对象，增加存储数据的灵活度，及时响应数据源变化,减少数据移动和冗余。

（3）本发明所述的一种泛化数据仓库，全量数据处理与增量数据处理，两种处理方式便于对数据的全量查询、数据的实时处理，便于数据的加速处理为应用提供实时响应服务。

（4）本发明所述的一种泛化数据仓库，统一跨引擎查询为分析应用提供多源数据高效支持。

附图说明

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

图1为本发明实施例所述的泛化数据仓库总体架构示意图；

图2为本发明实施例所述的泛化数据仓库总体架构逻辑实现框架图；

图3为本发明实施例所述的泛化数据仓库全量和增量数据处理示意图；

图4为本发明实施例所述的泛化数据仓库数据源接入示意图；

图5为本发明实施例所述的泛化数据仓库增量数据接入示意图；

图6为本发明实施例所述的泛化数据仓库虚拟数据对象构成示意图；

图7为本发明实施例所述的泛化数据仓库跨引擎查询示意图；

图8为本发明实施例所述的泛化数据仓库数据加工逻辑实现框架图；

图9为本发明实施例所述的泛化数据仓库数据服务逻辑实现框架图；

图10为本发明实施例所述的实时数据操作区逻辑架构图；

图11为本发明实施例所述的实时数据操作区处理过程流程图；

图12为本发明实施例所述的同步数据流程图；

图13为本发明实施例所述的金融业务泛化数据仓库示例图。

具体实施方式

需要说明的是，在不冲突的情况下，本发明中的实施例及实施例中的特征可以相互组合。

在本发明的描述中，需要理解的是，术语“中心”、“纵向”、“横向”、“上”、“下”、“前”、“后”、“左”、“右”、“竖直”、“水平”、“顶”、“底”、“内”、“外”等指示的方位或位置关系为基于附图所示的方位或位置关系，仅是为了便于描述本发明和简化描述，而不是指示或暗示所指的装置或元件必须具有特定的方位、以特定的方位构造和操作，因此不能理解为对本发明的限制。此外，术语“第一”、“第二”等仅用于描述目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”等的特征可以明示或者隐含地包括一个或者更多个该特征。在本发明的描述中，除非另有说明，“多个”的含义是两个或两个以上。

在本发明的描述中，需要说明的是，除非另有明确的规定和限定，术语“安装”、“相连”、“连接”应做广义理解，例如，可以是固定连接，也可以是可拆卸连接，或一体地连接；可以是机械连接，也可以是电连接；可以是直接相连，也可以通过中间媒介间接相连，可以是两个元件内部的连通。对于本领域的普通技术人员而言，可以通过具体情况理解上述术语在本发明中的具体含义。

下面将参考附图并结合实施例来详细说明本发明。

实施例1

如图1至图3所示，一种泛化数据仓库，包括：数据基础层、数据加工层、数据服务层、实时数据操作区；

数据基础层，用于接入多种类型的数据库的数据，并将接入的全量数据进行存储，将接入的增量数据接入到实时数据操作区；

实时数据操作区，用于对接入的增量数据进行实时处理；

数据加工层，用于对存储的全量数据进行批处理；

通过构建数据基础层与服务层之间的数据映射关系，及数据加工层与数据服务层之间的数据映射关系形成虚拟数据对象。

1）数据基础层

如图4所示，数据基础层需要同时支持SQL数据库、NOSQL数据库和分布文件***。

考虑到当前SQL数据库之间的数据交换效率比较高，所以，数据基础层仍需要部署SQL数据库，但需要支持大规模数据、可扩展的数据库***，比如MPP数据库，以支撑来自不同来源的历史数据。

数据基础层也需要部署NOSQL数据库、分布文件***，以支持NOSQL数据、文档数据等海量数据，NOSQL数据库的底层通常采用分布文件***作为支撑。分布文件***还直接接入各种非结构化数据。

文档数据根据业务规则，抽取转化为结构化数据并转存到SQL数据库。同时，对于使用频率较低的SQL数据采用近线方式，转移到分布式文件***中。

结构化数据源接入数据基础层采用各种ETL工具及日志增量同步工具，NOSQL数据采用自带工具接入，其它数据直接导入分布式文件***。

数据基础层，通过ETL、CDC及实时数据导入工具，接入各种数据源，该层的数据与源数据结构基本保持一致，数据接入还包括数据清洗、加载、转换、和数据质量处理，数据基础层需要支持结构化、非结构化数据。非结构化数据主要指 Key-value stores键值数据、Table-oriented 面向表列数据、Document-oriented面向文档数据、Graph-oriented 面向图论的图数据及文本数据。

数据基础层还包括数据接入接口：

数据接入接口是从数据源接入数据，数据接入首先需要存储在数据基础层，数据基础层需要支持各种数据源的存储。

与传统数据仓库不同，泛化数据仓库不仅需要接入结构化数据，还要接入文档、文本、图数据等。由于每种数据类型都有其特性，故此针对不同的数据类型采用不同的数据接入方法以提高接入效率。

结构化数据接入技术已经成熟，而且效率很高，通过数据同步或日志同步根据预置的业务内容抽取；增量数据通过带有时间戳的CDC工具实现增量抽取；文本文件数据通过FTP或基本操作脚本导入到分布式文件***；NOSQL数据采用***自带或第三方工具导入相应***。

总的来说，数据接入采用ETL及CDC工具完成。接入功能同时还具备：预置的公式，函数，数据汇总和计算能力、支持分区技术、支持数据清洗转换、支持元数据的集成。

2）数据加工层

是在数据基础层的基础上，首先对数据做聚合操作，然后加工形成明细事实数据和维表数据，并构建业务数据模型，最后根据构建的业务数据模型生成公共指标汇总数据。为了能够加工处理异构数据和非结构化数据，数据加工层还支持异构数据查询，同时通过虚拟数据对象映射，快速反映数据源的更新变化；

数据加工层基于数据基础层，根据业务需求对基础层的数据进一步加工，加工过程包括：对数据进行转换数据质量、对数据进行做数据聚合操作，生成中间表及事实表生，对数据的指标统计、数据建模等。这些工作通过数据库内置脚本或者使用工具完成；数据加工层也含盖历史数据，加工处理的数据量很大，但数据已经结构化，故此，这层可采用SQL数据库存储，由于加工处理的数据量很大，需要采用分布式SQL数据库，比如MPP数据库；

数据加工层引进虚拟数据对象，映射数据库的下层或跨层的数据源，或下层的虚拟数据对象。为了直接获得广泛的数据源，数据加工层支持跨引擎数据查询并能够聚合异构数据；

数据加工层实现示意图，如图8所示；

数据加工层，用于对数据做聚合操作，加工形成明细事实数据、维表数据并构建业务数据模型，生成公共指标汇总数据；数据服务层，根据数据加工层构建的数据模型综合批处理与实时处理、聚合数据与虚拟数据对象。

3）数据服务层

数据服务层将根据业务模型，生成分析指标，提供实现批处理分析和实时处理分析，支持商业智能分析和AI分析，该层还提供目录服务及数据API服务。

数据服务层是面向主题的，为上层用于提供查询或数据API服务，在这一层主要实现查询计算，特别是在跨引擎查询上，更需要有较高的计算能力支撑。数据服务层建议使用内存数据库，同时引入异构并行计算及RMDA等技术，提高计算能力。

数据服务层实现示意图如图9所示；

数据服务层接入虚拟数据对象、聚合数据或源数据，综合全量数据、增量数据通过查询或搜索引擎提高查询服务，也提供数据API接口，为应用提供分析数据指标，满足业务应用需求。

数据服务层还包括跨引擎数据查询模块：

跨引擎数据查询为了支持多源多类型数据加工处理，泛化数据仓库需要具备异构数据查询能力，能够支持多种数据库查询引擎及非结构化数据查询引擎。

4）实时数据操作区

用于将数据基础层接入的增量数据的各种类型数据实时计算处理，实现实时分析；

如图10所示，实时数据操作区包括：数据捕获组件、数据投递组件、管理组件；

其中，写入手段中的写数据组件支持批量***，支持主键方式更新及删除数据；如果用户在同步时不手动指定表的主键，对于更新及删除将采用全列作为默认主键进行更新及删除。

管理组件，用于对数据捕获组件及数据投递组件进行控制, 数据捕获组件和数据投递组件启动过程中如果有错误会将错误信息发送到管理组件并退出服务；管理组件收到错误信息后会停止其他已经启动未停止的服务。

实时数据操作区的工作流程如下：

实时数据操作区以事务为单位，从数据基础层抽取增量数据，将抽取的增量数据统一封装为Puredata格式的数据；使用Protobuf协议将数据格式中的内容按照事务进行处理，在数据服务层执行并提交，可根据客户的业务需求，实现增量数据从数据基础层到数据服务层实时响应。

Puredata格式的数据格式，是一个封装消息的数组集合，数据格式实例如下：“xxxx；xxxxx；xxxxx；……”，其中，xxxx表示数据的二进制数数组；

使用Protobuf协议将数据格式中的内容按照事务进行处理，在实时数据操作区的目标端执行并提交，实时数据操作区的源端与目标端可保持数据实时；整个处理过程有更高的转化效率，时间效率和空间效率是JSON的3-5倍。

如图11所示，具体处理流程：

1）管理组件Manager通过读取配置文件中的同步对象，验证源和目标的元数据是否匹配；

2）数据捕获组件Capture通过标准JDBC从数据基础层采用并行挖掘方式获取增量数据，以自定义Puredata格式放入内存队列；

并将队列中获取数据进行事务还原，并对事务进行排序，将排序好的事务进行格式化处理，本地进行保存；

3）数据捕获组件Capture发送到消息队列，数据投递组件delivery负责解析本地保存的Puredata数据格式，并采用广播的方式，支持并行处理的写入模式，大幅提升同步写入性能。

如图12所示，同步数据过程如下：

实时数据操作区包括两个同步工具，两个同步工具同时启动，正在工作的RTSyncR1 服务出现故障时，由RTSync R2 服务快速接管，且保证数据不丢失；其中，同步工具可包括多个；实现方式如下：

1、同时启动RTSync R1 和RTSync R2，仅有一个处于工作状态，同时由Zookeeper记录工作状态信息；

2、当RTSync R1断网、断电等导致服务不可用时，自动Failover到RTSync R2上；

3、管理员恢复RTSync R1；后续若RTSync R2断网、断电等导致服务不可用时，自动Failover到RTSync R1上。

实时数据操作区，还可采用SPAEK或Lambda数据技术，以采用Lambda大数据技术为例，把接入数据拆分成两类，分别做批处理和实时处理，并行实现批量数据处理和实时数据处理功能，并可进一步将批量数据预处理结果和实时数据处理结果合并，提供综合数据服务；这样，既能满足传统分析需求也能满足传统数据仓库没有提供的实时数据处理；

将Lambda大数据架构拆分成三层：Batch Layer，Speed Layer和Serving Layer。其中，Batch Layer负责数据集存储以及全量数据集的预查询。Speed Layer主要负责对增量数据进行计算，生成Realtime Views。Serving Layer用于响应用户的查询请求，它将Batch Views和Realtime Views的结果进行合并，得到最后的结果，返回给用户。

根据Lambda架构思路，泛化数据仓库可通过增量数据处理来加快处理响应速度，如图5所示，增量数据处理：在数据存储层可通过CDC（Change Data Capture）工具或流存取工具及消息队列对增量数据进行存储和处理。

实时数据操作区，在泛化数据仓库不仅面向多数据类型，同时也在实时能力上扩展传统数据仓库能力。

泛化数据仓库，是在传统数据仓库设计中引入了虚拟数据对象、实时数据处理、跨引擎数据查询功能；

如图6所示，虚拟数据对象可以映射（含Join、Union及汇聚计算）到全量数据，及其它的虚拟数据对象，全量数据包括结构化数据的对象、增量数据对象、非结构化对象。

全量数据对象或增量数据对象可以是各种数据表、事实表、维度表、视图等，非结构化对象可以转换加载非结构化数据，同时虚拟数据对象还可以对接其它虚拟数据对象，进一步增加虚拟数据对象的灵活度。

传统数据仓库逻辑上通常分为多层，数据从接入到应用需要经过逐层加工，下层包含了上层数据加工所需要的全量数据，这种加工过程，虽然保持了应用层的相对稳定。但数据需要在各层移动，冗余程度高，容易引起数据在各层的不一致性，增加维护工作量，同时，由于数据需要经过各层的加工过程，上层应用无法快速感知数据源的变化，因此本专利通过虚拟数据对象解决此问题。

虚拟数据对象类似数据视图，虚拟数据对象能够与多源异构数据源及其它虚拟对象建立映射关系；从而使一些需要快速响应的应用数据不必经过数据加工的层层上移及聚合。虚拟数据对象的数据源可直接来数据库的下层或跨层的多源数据。

实时数据处理：以事务为单位，从数据基础层抽取增量数据，将抽取的增量数据统一封装为Puredata格式的数据；使用Protobuf协议将数据格式中的内容按照事务进行处理，在数据服务层执行并提交，可根据客户的业务需求，实现增量数据从数据基础层到数据服务层实时响应。

如图7所示，跨引擎统一数据查询：具备异构数据查询能力，支持多种数据库查询引擎及非结构化数据查询引擎；

为了支持多源多类型数据应用支撑，提供异构数据查询，融合异构数据库查询引擎及非结构化数据查询引擎，提供高效的统一查询服务。实现多源数据的综合分析。

跨引擎统一数据查询包括解析标准 SQL、跨引擎统一调度、引擎间关联数据存储与运算、插件扩展服务、数据交换中的一个或多个；

1）解析标准 SQL ，接收用户发来SQL指令，用于接收用户发来跨数据源的SQL指令，将接收到的SQL指令转换为对应数据库内各引擎支持的指令；在解析标准SQL单元的基础上，扩展部分DDL语句的方言,提供统一查询语言访问各引擎；

2）跨引擎统一调度，

提供对数据的统一调度能力，根据业务需要对多引擎上的数据进行调度，透明地实现跨引擎的数据关联；统一调度按照工作流程间的依赖关系有序、自动地调度执行，它将贯穿业务处理的全流程，从数据资源的整合、加工到后续的数据处理和结果输出。

3）引擎间关联数据存储与运算，当SQL涉及到有多个引擎需要进行数据关联时，负责数据的关联运算，根据执行计划将参与的数据进行本地化存储，从而减少运算过程中拉数据的过程，确保运算的性能。

4）插件扩展服务，通过可动态扩展的插件体系架构，实现下层数据查询引擎的动态扩展。支持Oracle，MySql、国产数据库以及Hive、Spark和HBase等非关系型数据库等。

5）数据交换，在不同的数据库处理引擎间，建立数据交换通道，提供引擎间共享接口，支持引擎间多对多的高效数据交换机制，以充分发挥跨多个引擎的优势。通过统一的事务机制保证迁移数据的一致性。

实施例2：

一种泛化数据仓库实现方法，包括以下步骤：

S1、数据基础层部署SQL数据库***、分布式NOSQL数据库***，利用两个数据库***接入不同的数据；

S2、数据加工层基于数据基础层接入的不同的数据，进一步加工处理，加工处理过程中引进虚拟数据对象，可利用虚拟数据对象聚合异构数据；

S3、数据服务层根据数据基础层接入的不同的数据类型生成分析指标，提供实现批处理分析和实时处理分析，供用户查询；

S4、实时数据操作区根据用户查询过程中发出的业务类型，进行不同类型的数据实施处理。

步骤S1中SQL数据库支持大规模数据、可扩展的数据库子***；

分布式NOSQL数据库***支持文档数据、图数据，支持接入各种非结构化数据。

步骤S2中加工处理包括数据质量保证处理、数据轻度聚合处理、中间表及事实表生成处理、指标统计处理、数据建模处理。

实施3：

如图13所示，泛化数据仓库，是适应大数据发展的新一代的数据仓库，是在传统数据仓库技术的基础上，重点发展了对多类型数据的支持以及实时数据分析的能力，从而更加广泛适应未来复杂数据环境的变化。

基于泛化数据仓库架构设计技术，基于金融业务的典型泛化数据仓库平台构建示范如图13所示；

目前，示范平台采用如图所示的成熟产品和工具构建泛化数据仓库，能够满足业务对多类型数据的采集、加工和应用，同时，全量数据分析和实时数据分析性能也可以满足业务需要。未来，随着技术的发展，泛化数据仓库也可以采用更加高效的其它产品和工具。

在数据接入上，平台使用kettle、RTSync等ETL工具接入结构化数据源，kettle是开源的ETL工具，RTsync是GBase的数据库日志同步工具。对于NOSQL数据源，平台采用Flume+kafka+flink以及FTP工具接入数据；

在基础数据存储层，结构化数据统一存储在分布式大规模数据库 GBase 8a MPP中，GBase 8a MPP支持PB级数据存储。NOSQL数据存储在HBase及HDFS中。HDFS可以支持超大规模的数据存储；

在数据加工层，分别实现全量和增量处理，为了加快全量数据处理速度，在数据加工层生成了物化数据视图，分析数据可以预先经过计算并存入数据视图。数据加工处理还采用了PowerDesigner建模工具，实现业务建模；

在数据服务层，平台通过GBase UP，实现跨引擎查询，跨引擎查询融合了数据各种异构查询引擎，来自GBase 8a、Oracle、MySQL等不同数据源数据，都可以通过统一查询语言进行查询。

在实时数据操作区，平台采用了Flume进行实时数据采集，采集数据被送入Kafaka消息队列，由实时处理分析工具Flink进行实时加工，加工结果统一提供给数据服务层，为应用提供实时和流数据处理服务。

随着云和分布式存储技术的发展，当前存储技术已经有很大提升，泛化数据仓库在计算能力上将来会面临更多挑战。传统数据仓库实现实时分析比较困难，而虚拟数据对象对计算能力要求也很高。所以，未来泛化数据仓库需要对性能做进一步优化。包括各种索引技术、缓存技术、冗余策略、调度策略、SQL优化、预计算，以及基于硬件的并行计算加速等。

以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims

1.一种泛化数据仓库，其特征在于包括：

实时数据操作区，用于对接入的增量数据进行实时处理；

数据加工层，用于对存储的全量数据进行批处理；

通过构建数据基础层与数据服务层之间的数据映射关系，及数据加工层与数据服务层之间的数据映射关系形成虚拟数据对象。

2.根据权利要求1所述的一种泛化数据仓库，其特征在于：数据加工层对数据加工采用以下方法：首先对数据做聚合操作，然后加工形成明细事实数据和维表数据，并构建业务数据模型，最后根据构建的业务数据模型生成公共指标汇总数据。

3.根据权利要求1所述的一种泛化数据仓库，其特征在于：实时数据操作区对数据基础层接入的多种类型数据库内的数据处理时，在规定时间内，通过实时计算分析，并传输给数据服务层与对应类型数据库内批处理的数据合并，提供综合数据服务。

4.根据权利要求1所述的一种泛化数据仓库，其特征在于：实时数据操作区包括：数据捕获组件、数据投递组件、管理组件；

5.根据权利要求1所述的一种泛化数据仓库，其特征在于：全量数据和增量数据类型包括结构化数据、文本文件数据、NOSQL数据中的一种或多种。

6.根据权利要求5所述的一种泛化数据仓库，其特征在于：数据基础层对不同数据类型接入时分别使用不同的处理方法，具体包括：

接入NOSQL数据时采用***自带或第三方工具导入相应***。

7.根据权利要求1所述的一种泛化数据仓库，其特征在于：跨引擎统一数据查询包括：解析标准 SQL、跨引擎统一调度、引擎间关联数据存储与运算、插件扩展服务、数据交换中的一个或多个；

跨引擎统一调度：用于提供对数据的统一调度能力，根据业务需要对多引擎上的数据进行调度，透明地实现跨引擎的数据关联；

8.一种泛化数据仓库实现方法，基于权利要求1-7任一所述的一种泛化数据仓库，其特征在于包括以下步骤：

S3、数据加工层基于数据基础层接入的不同的类型的全量数据或增量数据，进一步加工处理，加工处理过程中引进虚拟数据对象，利用虚拟数据聚合异构数据；

9.根据权利要求8所述的一种泛化数据仓库实现方法，其特征在于：步骤S1中SQL数据库***支持、扩展数据库子***；

10.根据权利要求8所述的一种泛化数据仓库实现方法，其特征在于：步骤S2中加工处理包括数据质量保证处理、数据聚合处理、中间表及事实表生成处理、指标统计处理、数据建模处理。