CN107220310A - 一种数据库数据管理系统、方法及装置 - Google Patents

一种数据库数据管理系统、方法及装置 Download PDF

Info

Publication number
CN107220310A
CN107220310A CN201710331389.1A CN201710331389A CN107220310A CN 107220310 A CN107220310 A CN 107220310A CN 201710331389 A CN201710331389 A CN 201710331389A CN 107220310 A CN107220310 A CN 107220310A
Authority
CN
China
Prior art keywords
data
database
server cluster
stored
analysis task
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN201710331389.1A
Other languages
English (en)
Inventor
李珂
董润莎
苏飞
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
China United Network Communications Group Co Ltd
Original Assignee
China United Network Communications Group Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by China United Network Communications Group Co Ltd filed Critical China United Network Communications Group Co Ltd
Priority to CN201710331389.1A priority Critical patent/CN107220310A/zh
Publication of CN107220310A publication Critical patent/CN107220310A/zh
Pending legal-status Critical Current

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/25Integrating or interfacing systems involving database management systems
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/21Design, administration or maintenance of databases

Landscapes

  • Engineering & Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Data Mining & Analysis (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

本申请实施例提供一种数据库数据管理系统、方法及装置,涉及数据库领域,用以解决现有的数据库架构无法满足现有大数据的存储与分析需求的问题。该系统包括:数据库数据管理装置、至少一个第一数据库和每个第一数据库对应的第一服务器集群、以及至少一个第二数据库及每个第二数据库对应的第二服务器集群,其中:数据库数据管理装置,与第一服务器集群互联,用于获取至少一个数据,将每个数据分别存储至与其数据类型相匹配的第一服务器集群中;第一服务器集群,用于对其存储的数据进行数据分析,得到第一数据分析结果;第二服务器集群,与第一服务器集群互联,用于存储第一数据分析结果。

Description

一种数据库数据管理系统、方法及装置
技术领域
本申请涉及数据库领域,尤其涉及一种数据库数据管理系统、方法及装置。
背景技术
随着大数据时代的来临,大数据分析应运而生,大数据分析被广泛应用于通信行业的基础设施建设优化、网络运营管理和优化、市场精准营销以及客户管理等方面。而作为大数据分析基础的数据库技术,也因此被广泛使用。
现有的数据库包括三种:OldSQL数据库、NoSQL数据库以及NewSQL数据库。其中,每种数据库用于存储不同类型的数据。具体的,OldSQL数据库适用于处理结构化的数据,具有很好的数据库ACID特性;NoSQL数据库适用于处理非结构化及价值密度低的数据;NewSQL数据库适用于处理结构化以及价值密度高的数据,还适用于处理大规模复杂分析任务的数据。
但是,现有的大数据分析数据库架构大多是使用某一种单一的数据库架构,或者使用某一种特定的数据库,从而仅能支持某种特定类型的数据的存储和分析,同时,由于现有的数据具有数据量大、增长速度快、数据类型多样以及价值密度稀疏的特点。因此,现有的数据库架构无法满足现有大数据的存储与分析需求。例如,OldSQL数据库不支持非结构化的数据,在数据处理性能方面存在局限性;NoSQL数据库不支持结构化数据,价值密度高的数据,且事务性应用差,即NoSQL数据库在分析数据时,若该数据被调取查询时,则会导致数据库对该数据进行错误分析,得到错误的分析结果;NewSQL数据库不支持非结构化数据,且在数据存储和扩展方面成本高。
发明内容
本申请提供的实施例提供一种数据库数据管理系统、方法及装置,用以解决现有的数据库架构无法满足现有大数据的存储与分析需求的问题。
为达到上述目的,本申请的实施例采用如下技术方案:
第一方面,提供一种数据库数据管理系统,包括:数据库数据管理装置、至少一个第一数据库和每个第一数据库对应的第一服务器集群、以及至少一个第二数据库及每个第二数据库对应的第二服务器集群,其中:
所述数据库数据管理装置,与所述第一服务器集群互联,用于获取至少一个数据,将每个数据分别存储至与其数据类型相匹配的第一服务器集群中;
所述第一服务器集群,用于对其存储的数据进行数据分析,得到第一数据分析结果;
所述第二服务器集群,与所述第一服务器集群互联,用于存储所述第一数据分析结果。
可选的,所述至少一个第一数据库包括:用于处理不存在大规模复杂分析任务的数据的第一类数据库和用于处理存在大规模复杂分析任务的数据的第二类数据库;
所述数据库数据管理装置,还用于判定所述至少一个数据中每个数据是否存在大规模复杂分析任务;
所述数据库数据管理装置在将每个数据分别存储至其数据类型对应的第一数据库的第一服务器集群中时,具体用于:
将所述至少一个数据中不存在大规模复杂分析任务的数据存储至其数据类型对应的第一类数据库的第一服务器集群中进行数据分析,并将所述至少一个数据中存在大规模复杂分析任务的数据存储至其数据类型对应的第二类数据库的第一服务器集群中进行数据分析。
可选的,所述至少一个第一数据库包括:用于处理不存在大规模复杂分析任务的数据的第一类数据库和用于处理存在大规模复杂分析任务的数据的第二类数据库;
所述数据库数据管理装置在将每个数据分别存储至其数据类型对应的第一数据库的第一服务器集群中时,具体用于:将每个数据分别存储至其数据类型对应的第一类数据库的第一服务器集群中;
所述第一类数据库的第一服务器集群,还用于判定其存储的数据是否存在大规模复杂分析任务,并将其存储的存在大规模复杂分析任务的数据同步至所述第二类数据库的第一服务器集群中进行数据分析。
可选的,所述数据库数据管理装置在将每个数据分别存储至与其数据类型相匹配的第一服务器集群中时,具体用于:
确定第一数据的价值密度情况和所述第一数据的数据源的数据结构;
从所述至少一个第一数据库中,确定出与所述第一数据的价值密度情况相匹配且支持所述第一数据的数据源的数据结构的目标第一数据库;
将所述第一数据存储至所述目标第一数据库对应的第一服务器集群中;
其中,所述第一数据为所述至少一个数据中的其中一个。
第二方面,提供一种数据库数据管理方法,应用于第一方面提供的系统,包括:
数据库数据管理装置获取至少一个数据,将每个数据分别存储至与其数据类型相匹配的第一数据库对应的第一服务器集群中,以便所述第一服务集群对其存储的数据分析,得到第一数据分析结果,并将所述第一数据分析结果存储至第二数据库的第二服务器集群中。
可选的,所述至少一个第一数据库包括:用于处理不存在大规模复杂分析任务的数据的第一类数据库和用于处理存在大规模复杂分析任务的数据的第二类数据库;
所述将每个数据分别存储至与其数据类型相匹配的第一数据库对应的第一服务器集群中之前,还包括:
判定所述至少一个数据中每个数据是否存在大规模复杂分析任务;
所述在将每个数据分别存储至其数据类型对应的第一数据库的第一服务器集群中,包括:
将所述至少一个数据中不存在大规模复杂分析任务的数据存储至其数据类型对应的第一类数据库的第一服务器集群中进行数据分析,并将所述至少一个数据中存在大规模复杂分析任务的数据存储至其数据类型对应的类数据库的第一服务器集群中进行数据分析。
可选的,所述至少一个第一数据库包括:用于处理不存在大规模复杂分析任务的数据的第一类数据库和用于处理存在大规模复杂分析任务的数据的第二类数据库;
所述在将每个数据分别存储至其数据类型对应的第一数据库的第一服务器集群中,包括:
将每个数据分别存储至其数据类型对应的第一类数据库的第一服务器集群中,以便所述第一类数据库的第一服务器集群判定其存储的数据是否存在大规模复杂分析任务,并将其存储的存在大规模复杂分析任务的数据同步至所述第二类数据库的第一服务器集群中进行数据分析。
可选的,所述数据库数据管理装置将每个数据分别存储至与其数据类型相匹配的第一服务器集群中,包括:
确定第一数据的价值密度情况和所述第一数据的数据源的数据结构;
从所述至少一个第一数据库中,确定出与所述第一数据的价值密度情况相匹配且支持所述第一数据的数据源的数据结构的目标第一数据库;
将所述第一数据存储至所述目标第一数据库对应的第一服务器集群中;
其中,所述第一数据为所述至少一个数据中的其中一个。
第三方面,提供一种数据库数据管理装置,包括:
获取模块,用于获取至少一个数据;
处理模块,用于将每个数据分别存储至与其数据类型相匹配的第一数据库对应的第一服务器集群中,以便所述第一服务集群对其存储的数据分析得到第一数据分析结果,并将所述第一数据分析结果存储至第二数据库的第二服务器集群中。
可选的,所述至少一个第一数据库包括:用于处理不存在大规模复杂分析任务的数据的第一类数据库和用于处理存在大规模复杂分析任务的数据的第二类数据库;
所述处理模块,还用于判定所述至少一个数据中每个数据是否存在大规模复杂分析任务;
所述处理模块在将每个数据分别存储至其数据类型对应的第一数据库的第一服务器集群中时,具体用于:
将所述至少一个数据中不存在大规模复杂分析任务的数据存储至其数据类型对应的第一类数据库的第一服务器集群中进行数据分析,并将所述至少一个数据中存在大规模复杂分析任务的数据存储至其数据类型对应的第二类数据库的第二服务器集群中进行数据分析。
可选的,所述至少一个第一数据库包括:用于处理不存在大规模复杂分析任务的数据的第一类数据库和用于处理存在大规模复杂分析任务的数据的第二类数据库;
所述处理模块在将每个数据分别存储至其数据类型对应的第一数据库的第一服务器集群中时,具体用于:
将每个数据分别存储至其数据类型对应的第一类数据库的第一服务器集群中,以便所述第一类数据库的第一服务器集群判定其存储的数据是否存在大规模复杂分析任务,并将其存储的存在大规模复杂分析任务的数据同步至所述第二类数据库的第一服务器集群中进行数据分析。
可选的,所述处理模块在将每个数据分别存储至与其数据类型相匹配的第一服务器集群中时,具体用于:
确定第一数据的价值密度情况和所述第一数据的数据源的数据结构;
从所述至少一个第一数据库中,确定出与所述第一数据的价值密度情况相匹配且支持所述第一数据的数据源的数据结构的目标第一数据库;
将所述第一数据存储至所述目标第一数据库对应的第一服务器集群中;
其中,所述第一数据为所述至少一个数据中的其中一个。
本申请提供的方案,通过将多种数据库进行联合部署,数据与数据分析结果存储至不同的数据库,以便数据分析结果再被调取查询时,不会对数据分析过程产生影响,具体的,本申请根据数据的数据类型将每个数据分别存储至与其数据类型相匹配的第一数据库对应的第一服务器集群中,以便第一服务集群对其存储的数据分析得到第一数据分析结果,并将第一数据分析结果存储至第二数据库的第二服务器集群中。这样通过对多种数据库进行联合部署,形成互补,消除自身的局限,从而满足对现有的具有数据量大、增长速度快、数据类型多样与价值密度稀疏特点的数据进行合理的存储与分析。
附图说明
为了更清楚地说明本申请实施例的技术方案,下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图仅仅是本申请的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其他的附图。
图1为本申请实施例提供的一种数据库数据管理系统的系统架构图;
图2为本申请实施例提供的另一种数据库数据管理系统的系统架构图;
图3为本申请实施例提供的一种数据库数据管理方法的方法流程图;
图4为本申请实施例提供的另一种数据库数据管理方法的方法流程图;
图5为本申请实施例提供的一种数据库数据管理装置的结构示意图。
具体实施方式
下面将结合本申请实施例中的附图,对本申请实施例中的技术方案进行描述。
本申请中,“示例性的”或者“例如”等词用于表示作例子、例证或说明。本申请实施例中被描述为“示例性的”或者“例如”的任何实施例或设计方案不应被解释为比其它实施例或设计方案更优选或更具优势。确切而言,使用“示例性的”或者“例如”等词旨在以具体方式呈现相关概念。本申请中,“的(英文:of)”,“相应的(英文:corresponding,relevant)”和“对应的(英文:corresponding)”有时可以混用,应当指出的是,在不强调其区别时,其所要表达的含义是一致的。
图1为本申请实施例提供的数据库数据管理系统的系统架构图,如图1所示,该系统包括:数据库数据管理装置11、至少一个第一数据库12和每个第一数据库12对应的第一服务器集群13、以及至少一个第二数据库14及每个第二数据库14对应的第二服务器集群15,其中:
数据库数据管理装置11,与第一服务器集群互联,用于获取至少一个数据,将每个数据分别存储至与其数据类型相匹配的第一服务器集群13中。
第一服务器集群13,用于对其存储的数据进行数据分析,得到第一数据分析结果。
第二服务器集群15,与第一服务器集群13互联,用于存储第一数据分析结果。
其中,上述数据的数据类型包括但不限于:数据价值密度情况和数据的数据源结构。示例性的,通信行业大数据分析涉及到的数据源主要包括:B侧用户消费账单、语音通话详单、数据业务详单等数据;无线网络性能相关的关键性能指标(英文:Key PerformanceIndicator,缩写:KPI)、测量报告(英文:Measurement Report,缩写MR)、路测等数据;基础工参的基站、网格、扇区、小区、铁塔、交通干线等数据;核心网侧用户上网业务相关的Gn、Iu-PS、CDR、DPI等数据;网元设备产生的信令、日志等数据。示例性的,本申请需要管理和存储的数据来源包括:计费系统、设备网管系统、挂表采集传输、网络优化系统等。
例如,目前通用的数据库包括:NewSQL数据库、OldSQL数据库和NoSQL数据库。其中,NewSQL数据库,通常使用Vertica集群架构,数据存储扩展成本较高,不支持非结构化和半结构化数据,适用于高价值密度的数据,具有大数据分析性能;OldSQL数据库,通常使用Oracle\MySQL集群架构,不支持非结构化和半结构化数据,适用于低价值密度的数据,存在很大的局限性,且在大数据复杂分析方面存在很大的不足;NoSQL数据库,通常使用Hadoop集群架构,不支持结构化数据,适用于低价值密度的数据。
其中,上述的Hadoop集群架构的分布式文件系统HDFS有高容错性和高吞吐量的特点,适合那些有着超大数据集的应用场景,为海量数据提供了存储;底层提供的MapReduce采用分而治之的思想将数据处理任务分布至各个节点上进行,并提供了Hive、Impala等查询引擎进行复杂的数据分析操作;同时,Hadoop集群架构具有可靠、高效、高扩展等优点。
Vertica集群架构是一种分布式MPP列式数据库,可以分布式运行在多台服务器上,提供高性能的分析处理能力。其中,列式存储和计算,适用于按列的高速查询,比行式存储的数据库有了很大的提升。Vertica集群提供标准化的接口和灵活的部署方式,可以方便的与Hadoop集群集成;Vertica可以根据用户查询特性优化存储结构和查询算法进一步提升查询性能,更加适用于复杂分析和即席查询等应用场景。
在具体现实时,本申请可以将NoSQL数据库和NewSQL数据库作为第一数据库,将OldSQL数据库作为第二数据库。之所以将分析结果存储至OldSQL数据库,是由于传统的OldSQL数据库为小型的关系型数据库,适合作为web应用的底层数据库,且部署简单、速度快、总体拥有成本低。
可选的,本申请中的至少一个第一数据库包括:用于处理不存在大规模复杂分析任务的数据的第一类数据库和用于处理存在大规模复杂分析任务的数据的第二类数据库。在具体实现时,由于现有的NewSQL数据库具备大数据分析性能,且存储和扩展成本较高,因此,本申请可以将NewSQL数据库作为第二类数据库,将NoSQL数据库作为第一类数据库。
基于此,在一种示例中,若第一数据库中的第一类数据库和第二类数据库均可进行数据存储和数据分析时,则:
数据库数据管理装置11,还用于判定至少一个数据中每个数据是否存在大规模复杂分析任务。
数据库数据管理装置11在将每个数据分别存储至其数据类型对应的第一数据库12的第一服务器集群13中时,具体用于:
将至少一个数据中不存在大规模复杂分析任务的数据存储至其数据类型对应的第一类数据库的第一服务器集群13中进行数据分析,并将至少一个数据中存在大规模复杂分析任务的数据存储至其数据类型对应的第二类数据库的第一服务器集群15中进行数据分析。
在另一种实例中,若第一数据库中第二类数据库仅对存在大规模复杂分析任务的数据进行数据分析时,则:
数据库数据管理装置在将每个数据分别存储至其数据类型对应的第一数据库的第一服务器集群中时,具体用于:将每个数据分别存储至其数据类型对应的第一类数据库的第一服务器集群中。
第一类数据库的第一服务器集群13,还用于判定其存储的数据是否存在大规模复杂分析任务,并将其存储的存在大规模复杂分析任务的数据同步至第二类数据库的第一服务器集群14中进行数据分析。
在具体实现时,若第一数据库以NewSQL数据库和NoSQL数据库为例,第二数据库以OldSQL数据库为例。由于NewSQL数据库的Vertica集群专门处理大规模的复杂任务,因此,这里将NewSQL数据库作为第二类数据库,NoSQL数据库作为第一类数据库。具体的,若存储在NoSQL数据库的Hadoop集群的数据有大规模处理不了的复杂分析任务,则需要同步至NewSQL数据库的Vertica集群中处理。即当NoSQL数据库的Hadoop集群的Impala内存受限无法完成分析的任务,或Impala分析的性能满足不了分析需求(比如分析个任务花了1天)时,则将需要分析的数据同步至NewSQL数据库的Vertica集群,以提高分析处理效率。同时,由于Vertica集群的存储成本高,因此,Hadoop集群在将需要分析的数据同步至Vertica集群之前,会使用其中的Impala对这些数据进行预处理(例如聚合、分组、预计算等手段),以缩小数据大小,减少NewSQL数据库的存储成本。当然,若不考虑该问题,则可以将存在大规模复杂分析任务的数据直接存储至NewSQL数据库的Vertica集群中,进行数据分析。
在一种示例中,数据库数据管理装置11在将每个数据分别存储至与其数据类型相匹配的第一服务器集群中时,具体用于:
确定第一数据的价值密度情况和第一数据的数据源的数据结构;
从至少一个第一数据库12中,确定出与第一数据的价值密度情况相匹配且支持第一数据的数据源的数据结构的目标第一数据库;
将第一数据存储至目标第一数据库12对应的第一服务器集群13中;
其中,第一数据为至少一个数据中的其中一个。
为了方便说明,本实施例以OldSQL数据库、NoSQL数据库以及NewSQL数据库这三种数据库来进行说明,图2为对应的数据库数据管理系统的系统架构图,具体的,数据引入层和数据存储分析层将使用Hadoop+Vertica混合数据库的方式进行部署;而分析结果存储层采用分布式MySQL和Oracle RAC两套OldSQL数据库混合的方式进行部署以满足不同种类的上层应用的展示。
参照图2,由图2可知,该系统架构由四层组成,由下至上依次包括:数据源引入层、数据存储分析层、分析结果存储层以及应用展示层,其中:
1、数据引入层
数据引入层,首先会对本申请需要分析和存储的异构多源的数据建立相应的传输通道,消除数据噪声、冗余和不一致性,然后,针对原始数据进行提取,剔除冗余数据,提高数据质量,降低数据的传输和存储压力,之后会对预处理的数据进行解析,完成数据的转换和清洗工作,实现数据的规范化统一,最后将规范化的数据进行加载入库。
数据引入层将数据源分为两大类型:具有较低价值密度、非结构化和半结构化的海量数据;具有较高价值密度、结构化、复杂分析任务的数据。数据引入层将获取到的无线侧、基础工参、Gn、Iu-PS、信令等低价值密度或者非结构化数据,利用Hadoop集群中Hive组件对于数据提取、转化和加载方面的优势,将数据写入Hadoop底层的HDFS存储中,而B侧账单、详单、CDR等高价值密度的结构化数据,以及需要使用复杂算法进行深度挖掘和分析的数据直接通过编写C++程序完成ETL操作,将数据分布式存储到Vertica集群各个服务器节点中;另外,Hadoop集群和Vertica集群支持双向数据同步,支持对Hadoop集群存储的数据价值提纯后同步至Vertica进行进一步的分析,Vertica得出的分析结果也可以同步至Hadoop集群用于后续的关联查询。即Hadoop集群处理不了的存在大规模复杂分析任务的数据经过预处理后同步至Vertica集群处理,而Vertica集群得出的分析结果有可能是Hadoop集群中需要有后续关联查询的,所以需要对分析后的结果进行同步。因此可以将Vertica集群中存储的历史数据或者是冷数据同步到Hadoop集群中进行持久化存储,这样Vertica集群中的这些数据就可以删除,腾出空间存储最新的热数据。
2、数据存储分析层
数据源经过规范化后分别存储在Hadoop集群和Vertica集群中,并根据存储的数据完成相应的分析任务。
Hadoop集群中Hive、Impala和HBase都可以直接对存储在HDFS中的数据进行处理,其中Hive是Hadoop集群上的数据仓库,擅长进行海量批处理查询;Impala是基于内存的实时交互式MPP查询引擎,能够低延迟的查询PB级数据;HBase则是构建在Hadoop之上的分布式面向列存储的数据库系统。
现有的Hadoop集群中的Hive、Impala和HBase在Hadoop集群中,都使用HDFS作为底层的存储,并通过YARN负责各组件之间的资源调度,同时,使用ZooKeeper来维护和同步配置数据的集中服务,为集群提供稳定的服务,并且负责HBase的元数据管理,Impala使用Hive的元数据管理组件,但Impala在计算时不需要调用MapReduce框架,而是运算在内存中的MPP查询引擎,因此速度比Hive快很多。
对于海量数据的复杂分析任务,Impala负责数据的预处理和预统计,将处理过的数据同步至Vertica集群进行进一步的复杂分析。另外,由于Hadoop集群的存储成本要比Vertica集群小,且提供强大的冗余备份机制,因此Vertica集群生成的价值数据将同步至Hadoop集群中进行持久化存储。
数据存储分析层的分任务的协调和调度由专门的任务调度服务器处理,根据定义好的任务处理周期,检查任务处理基础条件和依赖关系,实现分析任务的并发执行和任务进度的控制。
3、分析结果存储层
由于OldSQL数据库的MySQL和Oracle RAC这两套数据库间存在同步机制,实现结果的冗余备份。MySQL是一个小型的关系型数据库,适合作为web应用的底层数据库,且部署简单、速度快、总体拥有成本低;Oracle的引入则是由于它可移植性好、使用广泛且功能强大,大数据时代之前大部分数据分析使用的都是Oracle数据库,因此数据同步机制实现简单且成熟。
数据存储分析层生成的分析结果,通过以Sqoop、GoldenGate等数据库同步技术,以数据库表的形式高效的同步至分析结果存储层。将上层应用访问到的结果表与数据分析层分离,分析任务的调度不影响上层应用的展示,保证系统的高可用性。通过建立单独的分析结果存储数据库,实现Hadoop集群所不具备的关系型数据库的ACID特性(原子性、一致性、隔离性和持久性)。结果库中的结果表支持增量扩展,可以通过分区存储等方式汇总周期性的结果表至汇总表。
部署配套的同步任务调度服务器,周期性的扫描分析结果存储层生成的结果表,将最新的结果表同步至分析结果存储层,保证结果表在多个数据库之间的一致性,并生成相应的同步日志,便于对任务进行监控和管理。
4、应用展示层
应用展示层基于分析结果存储层存储的各种结果表进行上层应用的开发和展示,提供WEB应用、GIS应用、APP、数据集市等多种形式的大数据服务,用于指导通信行业的基础设施建设优化、网络运营管理和优化、市场精准营销、客户关系管理等,实现大数据价值的变现。
下面说明本申请实施例提供的与上文所提供的系统实施例相对应的方法实施例。需要说明的是,下述方法实施例中相关内容的解释,均可以参考上述系统实施例。
本申请实施例提供的数据库数据管理方法的执行主体可以为上文系统中的数据库数据管理装置,或者用于执行上述数据库数据管理方法的电子设备。其中,数据库数据管理装置可以为上述电子设备中的中央处理器(英文:Central Processing Unit,缩写:CPU)或者可以为上述电子设备中的控制单元或者功能模块。
基于图1、2所示的系统架构,本申请实施例提供一种数据库数据管理方法,如图3所示,该方法包括:
201、获取至少一个数据。
202、将每个数据分别存储至与其数据类型相匹配的第一数据库对应的第一服务器集群中,以便第一服务集群对其存储的数据分析,得到第一数据分析结果,并将第一数据分析结果存储至第二数据库的第二服务器集群中。
可选的,上述的至少一个第一数据库包括:用于处理不存在大规模复杂分析任务的数据的第一类数据库和用于处理存在大规模复杂分析任务的数据的第二类数据库。
基于此,在一种示例中,若第一数据库中的第一类数据库和第二类数据库均可进行数据存储和数据分析时,则:
在步骤202之前,还包括如下步骤:
S11、判定至少一个数据中每个数据是否存在大规模复杂分析任务。
基于步骤S11,步骤202具体包括如下内容:
S12、将至少一个数据中不存在大规模复杂分析任务的数据存储至其数据类型对应的第一类数据库的第一服务器集群中进行数据分析,并将所述至少一个数据中存在大规模复杂分析任务的数据存储至其数据类型对应的第二类数据库的第一服务器集群中进行数据分析。
在另一种示例中,若第一数据库中第二类数据库仅对存在大规模复杂分析任务的数据进行数据分析时,则:
步骤202具体包括如下步骤:
S21、将每个数据分别存储至其数据类型对应的第一类数据库的第一服务器集群中,以便第一类数据库的第一服务器集群判定其存储的数据是否存在大规模复杂分析任务,并将其存储的存在大规模复杂分析任务的数据同步至第二类数据库的第一服务器集群中进行数据分析。
示例性的,步骤202具体包括如下步骤:
S31、确定第一数据的价值密度情况和第一数据的数据源的数据结构。
S32、从至少一个第一数据库中,确定出与第一数据的价值密度情况相匹配且支持第一数据的数据源的数据结构的目标第一数据库。
S33、将第一数据存储至目标第一数据库对应的第一服务器集群中。
其中,第一数据为至少一个数据中的其中一个。
若以图2所示的系统架构为例,其对应的数据库数据管理方法的方法流程图如图4所示,参照图4所示,该数据库数据管理方法的方法流程如下所述:
1、根据数据来源不同,建立相应的传输通道,获取通信行业大数据分析使用到的各种异构多源的数据。
2、判断获取到的数据的价值密度情况,若是高价值密度的数据则跳至步骤(4),否则继续执行步骤(3)。
3、低价值密度的数据统一存储在Hadoop集群的HDFS中,使用Hive完成数据的提取、转换和加载工作,以数据库表的形式实现数据的规范化入库。
4、判断高价值密度的数据是否属于Vertica集群无法处理的非结构化数据,若是则返回执行步骤(3),否则继续执行步骤(5)。
5、高价值密度的结构化数据统一存储在Vertica集群中,通过C++程序完成数据的提取、转换和加载工作,以数据库表的形式实现数据的规范化入库。
6、判断Hadoop集群中存储的数据是否涉及到Impala分析引擎无法完成的大规模复杂分析任务,若存在则跳至步骤(8),否则继续执行步骤(7)。
7、使用Impala分析引擎对Hadoop集群中存储的数据进行分析,并生成相应的分析结果集。
8、通过Impala分析引擎,完成大规模复杂分析任务数据源的预处理,以结构化数据的形式同步至Vertica集群。
9、Vertica集群完成存储在集群内以及从Hadoop集群同步过来存在大规模复杂分析任务的数据的分析任务,并生成相应的分析结果集。
10、判断Hadoop集群和Vertica集群中存储的结果集是否用于前台的WEB界面展示,若否则跳至步骤(12),是则继续执行步骤(11)。
11、使用分布式MySQL作为前台WEB应用的后台数据库,从Hadoop集群和Vertica集群中同步前台展示所需的分析结果集。
12、对于事务型较强的应用以及和已有系统融合等应用场景,使用Oracle RAC作为后台数据库,从Hadoop和Vertica集群中同步前台展示所需的分析结果集。
下面说明本申请实施例提供的与上文所提供的方法实施例相对应的装置实施例。需要说明的是,下述装置实施例中相关内容的解释,均可以参考上述方法实施例。
图5示出了上述实施例中所涉及的数据库数据管理装置的一种可能的结构示意图,参照图5、该装置包括:获取模块31和处理模块32,其中:获取模块31用于支持数据库数据管理装置执行图3中的步骤201;处理模块22用于支持数据库数据管理装置执行图3中的步骤202。进一步的,上述的处理模块还用于支持数据库数据管理装置执行上文中的步骤S11、S12、S21、以及步骤S31、S32、S33。其中,上述方法实施例涉及的各步骤的所有相关内容均可以援引到对应功能模块的功能描述,在此不再赘述。此外,上述处理模块32,还用于存储该装置的程序代码和数据。
在硬件实现上,上述的获取模块31、处理模块32可以是处理器。上述数据库数据管理装置所执行的动作所对应的程序均可以以软件形式存储于该装置的存储器中,以便于处理器调用执行以上各个模块对应的操作。
通过以上本申请所提供的几个实施例,应该理解到,所揭露的装置和方法,可以通过其它的方式实现。例如,以上所描述的装置实施例仅仅是示意性的,例如,所述模块的划分,仅仅为一种逻辑功能划分,实际实现时可以有另外的划分方式,例如多个单元或组件可以结合或者可以集成到另一个系统,或一些特征可以忽略,或不执行。
本申请中的处理器可以是一个处理器,也可以是多个处理元件的统称。例如,可以为CPU,也可以为其他通用处理器、数字信号处理器(英文:digital signal processing,缩写:DSP)、专用集成电路(英文:application specific integrated circuit,缩写:ASIC)、现场可编程门阵列(英文:field-programmable gate array,缩写:FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等,其可以实现或执行结合本申请公开内容所描述的各种示例性的逻辑方框,模块和电路。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。所述处理器也可以是实现计算功能的组合,例如包含一个或多个微处理器组合,DSP和微处理器的组合等等。
结合本申请公开内容所描述的方法的步骤可以硬件的方式来实现,也可以是由处理器执行软件指令的方式来实现。软件指令可以由相应的软件模块组成,软件模块可以被存放于随机存取存储器(英文:random access memory,缩写:RAM)、闪存、只读存储器(英文:read only memory,缩写:ROM)、可擦除可编程只读存储器(英文:erasableprogrammable ROM,缩写:EPROM)、电可擦可编程只读存储器(英文:electrically EPROM,缩写:EEPROM)、寄存器、硬盘、移动硬盘、只读光盘(CD-ROM)或者本领域熟知的任何其它形式的存储介质中。一种示例性的存储介质耦合至处理器,从而使处理器能够从该存储介质读取信息,且可向该存储介质写入信息。当然,存储介质也可以是处理器的组成部分。处理器和存储介质可以位于ASIC中。
最后应说明的是:以上所述的具体实施方式,对本申请的目的、技术方案和有益效果进行了进一步详细说明,所应理解的是,以上所述仅为本申请的具体实施方式而已,并不用于限定本申请的保护范围,凡在本申请的技术方案的基础之上,所做的任何修改、等同替换、改进等,均应包括在本申请的保护范围之内。

Claims (12)

1.一种数据库数据管理系统,其特征在于,包括:数据库数据管理装置、至少一个第一数据库和每个第一数据库对应的第一服务器集群、以及至少一个第二数据库及每个第二数据库对应的第二服务器集群,其中:
所述数据库数据管理装置,与所述第一服务器集群互联,用于获取至少一个数据,将每个数据分别存储至与其数据类型相匹配的第一服务器集群中;
所述第一服务器集群,用于对其存储的数据进行数据分析,得到第一数据分析结果;
所述第二服务器集群,与所述第一服务器集群互联,用于存储所述第一数据分析结果。
2.根据权利要求1所述的系统,其特征在于,所述至少一个第一数据库包括:用于处理不存在大规模复杂分析任务的数据的第一类数据库和用于处理存在大规模复杂分析任务的数据的第二类数据库;
所述数据库数据管理装置,还用于判定所述至少一个数据中每个数据是否存在大规模复杂分析任务;
所述数据库数据管理装置在将每个数据分别存储至其数据类型对应的第一数据库的第一服务器集群中时,具体用于:
将所述至少一个数据中不存在大规模复杂分析任务的数据存储至其数据类型对应的第一类数据库的第一服务器集群中进行数据分析,并将所述至少一个数据中存在大规模复杂分析任务的数据存储至其数据类型对应的第二类数据库的第一服务器集群中进行数据分析。
3.根据权利要求1所述的系统,其特征在于,所述至少一个第一数据库包括:用于处理不存在大规模复杂分析任务的数据的第一类数据库和用于处理存在大规模复杂分析任务的数据的第二类数据库;
所述数据库数据管理装置在将每个数据分别存储至其数据类型对应的第一数据库的第一服务器集群中时,具体用于:将每个数据分别存储至其数据类型对应的第一类数据库的第一服务器集群中;
所述第一类数据库的第一服务器集群,还用于判定其存储的数据是否存在大规模复杂分析任务,并将其存储的存在大规模复杂分析任务的数据同步至所述第二类数据库的第一服务器集群中进行数据分析。
4.根据权利要求1-3任一项所述的系统,其特征在于,所述数据库数据管理装置在将每个数据分别存储至与其数据类型相匹配的第一服务器集群中时,具体用于:
确定第一数据的价值密度情况和所述第一数据的数据源的数据结构;
从所述至少一个第一数据库中,确定出与所述第一数据的价值密度情况相匹配且支持所述第一数据的数据源的数据结构的目标第一数据库;
将所述第一数据存储至所述目标第一数据库对应的第一服务器集群中;
其中,所述第一数据为所述至少一个数据中的其中一个。
5.一种数据库数据管理方法,其特征在于,应用于权利要求1-4任一项所述的系统,包括:
数据库数据管理装置获取至少一个数据,将每个数据分别存储至与其数据类型相匹配的第一数据库对应的第一服务器集群中,以便所述第一服务集群对其存储的数据分析,得到第一数据分析结果,并将所述第一数据分析结果存储至第二数据库的第二服务器集群中。
6.根据权利要求5所述的方法,其特征在于,所述至少一个第一数据库包括:用于处理不存在大规模复杂分析任务的数据的第一类数据库和用于处理存在大规模复杂分析任务的数据的第二类数据库;
所述将每个数据分别存储至与其数据类型相匹配的第一数据库对应的第一服务器集群中之前,还包括:
判定所述至少一个数据中每个数据是否存在大规模复杂分析任务;
所述在将每个数据分别存储至其数据类型对应的第一数据库的第一服务器集群中,包括:
将所述至少一个数据中不存在大规模复杂分析任务的数据存储至其数据类型对应的第一类数据库的第一服务器集群中进行数据分析,并将所述至少一个数据中存在大规模复杂分析任务的数据存储至其数据类型对应的类数据库的第一服务器集群中进行数据分析。
7.根据权利要求5所述的方法,其特征在于,所述至少一个第一数据库包括:用于处理不存在大规模复杂分析任务的数据的第一类数据库和用于处理存在大规模复杂分析任务的数据的第二类数据库;
所述在将每个数据分别存储至其数据类型对应的第一数据库的第一服务器集群中,包括:
将每个数据分别存储至其数据类型对应的第一类数据库的第一服务器集群中,以便所述第一类数据库的第一服务器集群判定其存储的数据是否存在大规模复杂分析任务,并将其存储的存在大规模复杂分析任务的数据同步至所述第二类数据库的第一服务器集群中进行数据分析。
8.根据权利要求5-7任一项所述的方法,其特征在于,所述数据库数据管理装置将每个数据分别存储至与其数据类型相匹配的第一服务器集群中,包括:
确定第一数据的价值密度情况和所述第一数据的数据源的数据结构;
从所述至少一个第一数据库中,确定出与所述第一数据的价值密度情况相匹配且支持所述第一数据的数据源的数据结构的目标第一数据库;
将所述第一数据存储至所述目标第一数据库对应的第一服务器集群中;
其中,所述第一数据为所述至少一个数据中的其中一个。
9.一种数据库数据管理装置,其特征在于,包括:
获取模块,用于获取至少一个数据;
处理模块,用于将每个数据分别存储至与其数据类型相匹配的第一数据库对应的第一服务器集群中,以便所述第一服务集群对其存储的数据分析得到第一数据分析结果,并将所述第一数据分析结果存储至第二数据库的第二服务器集群中。
10.根据权利要求9所述的装置,其特征在于,所述至少一个第一数据库包括:用于处理不存在大规模复杂分析任务的数据的第一类数据库和用于处理存在大规模复杂分析任务的数据的第二类数据库;
所述处理模块,还用于判定所述至少一个数据中每个数据是否存在大规模复杂分析任务;
所述处理模块在将每个数据分别存储至其数据类型对应的第一数据库的第一服务器集群中时,具体用于:
将所述至少一个数据中不存在大规模复杂分析任务的数据存储至其数据类型对应的第一类数据库的第一服务器集群中进行数据分析,并将所述至少一个数据中存在大规模复杂分析任务的数据存储至其数据类型对应的第二类数据库的第二服务器集群中进行数据分析。
11.根据权利要求9所述的装置,其特征在于,所述至少一个第一数据库包括:用于处理不存在大规模复杂分析任务的数据的第一类数据库和用于处理存在大规模复杂分析任务的数据的第二类数据库;
所述处理模块在将每个数据分别存储至其数据类型对应的第一数据库的第一服务器集群中时,具体用于:
将每个数据分别存储至其数据类型对应的第一类数据库的第一服务器集群中,以便所述第一类数据库的第一服务器集群判定其存储的数据是否存在大规模复杂分析任务,并将其存储的存在大规模复杂分析任务的数据同步至所述第二类数据库的第一服务器集群中进行数据分析。
12.根据权利要求9-11任一项所述的装置,其特征在于,所述处理模块在将每个数据分别存储至与其数据类型相匹配的第一服务器集群中时,具体用于:
确定第一数据的价值密度情况和所述第一数据的数据源的数据结构;
从所述至少一个第一数据库中,确定出与所述第一数据的价值密度情况相匹配且支持所述第一数据的数据源的数据结构的目标第一数据库;
将所述第一数据存储至所述目标第一数据库对应的第一服务器集群中;
其中,所述第一数据为所述至少一个数据中的其中一个。
CN201710331389.1A 2017-05-11 2017-05-11 一种数据库数据管理系统、方法及装置 Pending CN107220310A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201710331389.1A CN107220310A (zh) 2017-05-11 2017-05-11 一种数据库数据管理系统、方法及装置

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201710331389.1A CN107220310A (zh) 2017-05-11 2017-05-11 一种数据库数据管理系统、方法及装置

Publications (1)

Publication Number Publication Date
CN107220310A true CN107220310A (zh) 2017-09-29

Family

ID=59944083

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201710331389.1A Pending CN107220310A (zh) 2017-05-11 2017-05-11 一种数据库数据管理系统、方法及装置

Country Status (1)

Country Link
CN (1) CN107220310A (zh)

Cited By (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107679192A (zh) * 2017-10-09 2018-02-09 中国工商银行股份有限公司 多集群协同数据处理方法、系统、存储介质及设备
CN107707659A (zh) * 2017-10-11 2018-02-16 郑州云海信息技术有限公司 一种大数据分析方法和系统
CN108932309A (zh) * 2018-06-15 2018-12-04 上海陆家嘴国际金融资产交易市场股份有限公司 跨平台数据库管理方法、装置、计算机设备和存储介质
CN109145053A (zh) * 2018-08-01 2019-01-04 阿里巴巴集团控股有限公司 数据处理方法和装置、客户端、服务器
CN109254989A (zh) * 2018-08-27 2019-01-22 北京东软望海科技有限公司 一种基于元数据驱动的弹性etl架构设计的方法及装置
CN109388651A (zh) * 2018-09-19 2019-02-26 中国联合网络通信集团有限公司 一种数据处理方法和装置
CN109408593A (zh) * 2018-10-16 2019-03-01 国家电网有限公司 一种数据库管理系统、装置及方法
CN110032571A (zh) * 2019-04-18 2019-07-19 腾讯科技(深圳)有限公司 业务流程处理方法、装置、存储介质及计算设备
CN110175207A (zh) * 2019-05-30 2019-08-27 深圳供电局有限公司 一种基于Hadoop和Spark的可扩展性大数据分析平台
CN112732669A (zh) * 2020-12-31 2021-04-30 北京达佳互联信息技术有限公司 一种数据处理方法和装置
CN114185488A (zh) * 2021-11-29 2022-03-15 广东财经大学 一种大数据集群的存储优化方法及系统
CN114238521A (zh) * 2022-02-25 2022-03-25 梅州客商银行股份有限公司 银行核心系统数据库的高可用部署方法、装置和电子设备
CN114860349A (zh) * 2022-07-06 2022-08-05 深圳华锐分布式技术股份有限公司 数据加载方法、装置、设备及介质

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2010056121A1 (en) * 2008-11-17 2010-05-20 Consumentenbond Method for obtaining additional online information
CN105631028A (zh) * 2015-12-30 2016-06-01 中国农业银行股份有限公司 一种数据库集群功能实现方法和系统

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2010056121A1 (en) * 2008-11-17 2010-05-20 Consumentenbond Method for obtaining additional online information
CN105631028A (zh) * 2015-12-30 2016-06-01 中国农业银行股份有限公司 一种数据库集群功能实现方法和系统

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
WANGSHFA: "NewSQL、NoSQL与OldSQL之混合部署应用方案", 《CSDN博客 HTTPS://BLOG.CSDN.NET/WANGSHFA/ARTICLE/DETAILS/43308575》 *
洪福成: "大数据专栏:数据库分析及应用", 《新IT领航 WWW.H3C.COM/CN/D_201511/901094_30008_0.HTM》 *
赖小婷: "NewSQL、NoSQL与OldSQL之混合部署方案", 《搜狐滚动 ROLL.SOHU.COM/20131223/N392264384.SHTML》 *

Cited By (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107679192A (zh) * 2017-10-09 2018-02-09 中国工商银行股份有限公司 多集群协同数据处理方法、系统、存储介质及设备
CN107707659A (zh) * 2017-10-11 2018-02-16 郑州云海信息技术有限公司 一种大数据分析方法和系统
CN108932309A (zh) * 2018-06-15 2018-12-04 上海陆家嘴国际金融资产交易市场股份有限公司 跨平台数据库管理方法、装置、计算机设备和存储介质
US11563805B2 (en) 2018-08-01 2023-01-24 Advanced New Technologies Co., Ltd. Method, apparatus, client terminal, and server for data processing
CN109145053A (zh) * 2018-08-01 2019-01-04 阿里巴巴集团控股有限公司 数据处理方法和装置、客户端、服务器
CN109145053B (zh) * 2018-08-01 2021-03-23 创新先进技术有限公司 数据处理方法和装置、客户端、服务器
CN109254989A (zh) * 2018-08-27 2019-01-22 北京东软望海科技有限公司 一种基于元数据驱动的弹性etl架构设计的方法及装置
CN109254989B (zh) * 2018-08-27 2020-11-20 望海康信(北京)科技股份公司 一种基于元数据驱动的弹性etl架构设计的方法及装置
CN109388651A (zh) * 2018-09-19 2019-02-26 中国联合网络通信集团有限公司 一种数据处理方法和装置
CN109388651B (zh) * 2018-09-19 2020-11-10 中国联合网络通信集团有限公司 一种数据处理方法和装置
CN109408593A (zh) * 2018-10-16 2019-03-01 国家电网有限公司 一种数据库管理系统、装置及方法
CN110032571A (zh) * 2019-04-18 2019-07-19 腾讯科技(深圳)有限公司 业务流程处理方法、装置、存储介质及计算设备
CN110175207A (zh) * 2019-05-30 2019-08-27 深圳供电局有限公司 一种基于Hadoop和Spark的可扩展性大数据分析平台
CN112732669A (zh) * 2020-12-31 2021-04-30 北京达佳互联信息技术有限公司 一种数据处理方法和装置
CN112732669B (zh) * 2020-12-31 2024-03-19 北京达佳互联信息技术有限公司 一种数据处理方法和装置
CN114185488A (zh) * 2021-11-29 2022-03-15 广东财经大学 一种大数据集群的存储优化方法及系统
CN114185488B (zh) * 2021-11-29 2024-07-26 江苏钟吾大数据发展集团有限公司 一种大数据集群的存储优化方法及系统
CN114238521A (zh) * 2022-02-25 2022-03-25 梅州客商银行股份有限公司 银行核心系统数据库的高可用部署方法、装置和电子设备
CN114860349A (zh) * 2022-07-06 2022-08-05 深圳华锐分布式技术股份有限公司 数据加载方法、装置、设备及介质

Similar Documents

Publication Publication Date Title
CN107220310A (zh) 一种数据库数据管理系统、方法及装置
Nasir et al. The power of both choices: Practical load balancing for distributed stream processing engines
US9946780B2 (en) Interpreting relational database statements using a virtual multidimensional data model
Gupta et al. Cloud computing and big data analytics: what is new from databases perspective?
CN109155763B (zh) 数据流上的数字信号处理
CN104885077B (zh) 利用归档的关系管理连续查询
CN109753531A (zh) 一种大数据统计方法、系统、计算机设备及存储介质
CN107679192A (zh) 多集群协同数据处理方法、系统、存储介质及设备
Besta et al. Practice of streaming processing of dynamic graphs: Concepts, models, and systems
Ngu et al. B+-tree construction on massive data with Hadoop
Hasani et al. Lambda architecture for real time big data analytic
CN105550268A (zh) 大数据流程建模分析引擎
CN106126601A (zh) 一种社保大数据分布式预处理方法及系统
CN102662639A (zh) 一种基于Mapreduce的多GPU协同计算方法
CN104239377A (zh) 跨平台的数据检索方法及装置
Feick et al. Fundamentals of real-time data processing architectures lambda and kappa
CN104111936A (zh) 数据查询方法和系统
US20160070754A1 (en) System and method for microblogs data management
Ding et al. ComMapReduce: An improvement of MapReduce with lightweight communication mechanisms
Wong et al. Parallel analytics as a service
Miller et al. Open source big data analytics frameworks written in scala
CN113468166B (zh) 元数据处理方法、装置、存储介质及服务器
CN101620600A (zh) 一种海量数据的处理方法
CN106294805A (zh) 数据处理方法及装置
CN104268158A (zh) 一种结构化数据分布式索引及检索方法

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
RJ01 Rejection of invention patent application after publication

Application publication date: 20170929

RJ01 Rejection of invention patent application after publication