CN108763559B - 一种基于大数据的数据存储方法、系统、设备及存储介质 - Google Patents
一种基于大数据的数据存储方法、系统、设备及存储介质 Download PDFInfo
- Publication number
- CN108763559B CN108763559B CN201810560730.5A CN201810560730A CN108763559B CN 108763559 B CN108763559 B CN 108763559B CN 201810560730 A CN201810560730 A CN 201810560730A CN 108763559 B CN108763559 B CN 108763559B
- Authority
- CN
- China
- Prior art keywords
- data
- computing cluster
- data storage
- supertable
- columns
- 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.)
- Active
Links
Images
Abstract
本发明公开了一种基于大数据的数据存储方法:根据业务参数以及各个计算集群的硬件参数,为每个计算集群规划各自存储的数据列数;在虚拟数据库中构建包含每个计算集群中存储的每一列数据的超级表格SuperTable,并根据每个计算集群各自存储的数据列数,将SuperTable纵向切分为多个目标列表Cabinet;构建路由信息,以使得在对SuperTable中的任意列进行读写操作时定位到相应的计算集群中。应用本发明所提供的方法,可以对具有任意列数的海量数据进行存储,实现了数据存储列表的宽度的无限拓展。本发明还公开了具有相应技术效果的基于大数据的数据存储系统、设备及存储介质。
Description
技术领域
本发明涉及大数据技术领域,特别是涉及一种基于大数据的数据存储方法、系统、设备及存储介质。
背景技术
现今的社会高速发展,随着云时代的来临,大数据也越来越受到关注,在越来越多的领域中,大数据都得到了广泛的应用。
大数据的一个显著特点便是数据量非常大,例如物联网数据就是一种海量的并且仍在爆发性增长的大数据。对于这些海量数据,为了节约物理存储空间以及提升数据分析效率,通常采用的是在关系型数据库中的列式存储的方式。
例如Vertica作为一种代表性的列式数据库存储模型,相比于传统行式数据库引擎,有10至50倍性能提升,但其目前支持的表宽度最多为1600列。还有一种主要的存储方式是使用BigTable存储模型,其表宽能够达到百万级别。但对于海量的数据而言,该表宽仍旧不足。例如一个720万的地级市,智能电表的数量达到了150万,如果为每个量测设备分配一列,将各列数据存储在同一数据列表中,就能够消除列与列之间的连接(JOIN)计算的开销,进而满足海量数据的高效存储与高性能分析的要求,但BigTable存储模型的表宽度远低于量测设备的数量,即BigTable存储模型的列数仍旧不足。
综上所述,如何设计一种针对大数据的数据存储方法,使得数据存储模型的列数满足海量数据的要求,是目前本领域技术人员急需解决的技术问题。
发明内容
本发明的目的是提供一种基于大数据的数据存储方法、系统、设备及存储介质,使得数据存储模型的列数满足海量数据的要求。
为解决上述技术问题,本发明提供如下技术方案:
一种基于大数据的数据存储方法,包括:
根据业务参数以及各个计算集群的硬件参数,为每个所述计算集群规划各自存储的数据列数;
在虚拟数据库中构建包含每个所述计算集群中存储的每一列数据的超级表格SuperTable,并根据每个所述计算集群各自存储的所述数据列数,将所述SuperTable纵向切分为多个目标列表Cabinet;
构建路由信息,以使得在对所述SuperTable中的任意列进行读写操作时定位到相应的计算集群中,所述路由信息中包括每个所述Cabinet各自对应的所述计算集群的信息,以及每个所述Cabinet与所述SuperTable之间的映射关系。
优选的,在所述构建路由信息之后,还包括:
接收目标读写指令;
通过解析所述目标读写指令,并根据所述路由信息生成针对待读写的一个或多个所述Cabinet的目标执行指令;
根据所述目标执行指令进行数据的读写。
优选的,所述根据所述目标执行指令进行数据的读写,包括:
当确定出的待读写的所述Cabinet为多个时,将所述目标执行指令分解为与待读写的所述Cabinet数量相同的多个子目标执行指令,各个所述子目标执行指令与各个待读写的所述Cabinet一一对应;
将各个所述子目标执行指令分别发送至对应于各个待读写的所述Cabinet的计算集群中进行数据的读写。
优选的,所述业务参数包括:业务数据的列的数量,采集所述业务数据的频率,采集所述业务数据的吞吐量。
优选的,所述各个计算集群的硬件参数包括:各个计算集群各自的磁盘每秒并发IO数量,各个所述计算集群各自的内存大小,各个所述计算集群各自的内存吞吐量。
优选的,所述计算集群与所述Cabinet之间的数量对应关系为1:1的对应关系。
优选的,所述路由信息中还包括:各个所述计算集群的访问方式信息。
一种基于大数据的数据存储系统,包括:
计算集群规划模块,用于根据业务参数以及各个计算集群的硬件参数,为每个所述计算集群规划各自存储的数据列数;
Cabinet构建模块,用于在虚拟数据库中构建包含每个所述计算集群中存储的每一列数据的超级表格SuperTable,并根据每个所述计算集群各自存储的所述数据列数,将所述SuperTable纵向切分为多个目标列表Cabinet;
路由信息构建模块,用于构建路由信息,以使得在对所述SuperTable中的任意列进行读写操作时定位到相应的计算集群中,所述路由信息中包括每个所述Cabinet各自对应的所述计算集群的信息,以及每个所述Cabinet与所述SuperTable之间的映射关系。
一种基于大数据的数据存储设备,包括:
存储器,用于存储数据存储程序;
处理器,用于执行所述数据存储程序以实现上述任一项所述的基于大数据的数据存储方法的步骤。
一种计算机可读存储介质,所述计算机可读存储介质上存储有数据存储程序,所述数据存储程序被处理器执行时实现上述任一项所述的基于大数据的数据存储方法的步骤。
应用本发明实施例所提供的技术方案,包括:根据业务参数以及各个计算集群的硬件参数,为每个计算集群规划各自存储的数据列数;在虚拟数据库中构建包含每个计算集群中存储的每一列数据的超级表格SuperTable,并根据每个计算集群各自存储的数据列数,将SuperTable纵向切分为多个目标列表Cabinet;构建路由信息,以使得在对SuperTable中的任意列进行读写操作时定位到相应的计算集群中,路由信息中包括每个Cabinet各自对应的计算集群的信息,以及每个Cabinet与SuperTable之间的映射关系。
在虚拟数据库中构建的SuperTable包含了每个计算集群中存储的每一列数据,即SuperTable包含了所有的存储数据,对于计算集群中的每一列数据,都可以根据路由信息在SuperTable进行相应的定位,也就消除了列与列直接的连接计算的开销。而由于将SuperTable纵向切分为多个目标列表Cabinet,使得SuperTable的列数由Cabinet的数量以及各个Cabinet中包含的列数决定。SuperTable纵向切分的次数并不限定,也即并不限定Cabinet的数量,每个Cabinet有着与之对应的进行数据存储的计算集群,因此不论SuperTable中的列数有多少,均可以通过一定次数的纵向切分,使得SuperTable被切分为各个Cabinet以便由相应的计算集群进行存储。因此,本申请中的方案通过对构建的SuperTable进行列方向的切分,使得可以对具有任意列数的海量数据进行存储,也即实现了数据存储列表的宽度的无限拓展,即SuperTable的表宽的无限拓展。
附图说明
为了更清楚地说明本发明实施例或现有技术中的技术方案,下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图仅仅是本发明的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其他的附图。
图1为本发明中一种基于大数据的数据存储方法的实施流程图;
图2为本发明中SuperTable的一种存储模型示意图;
图3为本发明中路由表的一种结构示意图;
图4为本发明中的Cabinet1的存储物理表的结构示意图;
图5为本发明中的Cabinet2的存储物理表的结构示意图;
图6为本发明中一种基于大数据的数据存储系统的结构示意图;
图7为本发明中一种基于大数据的数据存储设备的结构示意图。
具体实施方式
本发明的核心是提供一种基于大数据的数据存储方法,可以对具有任意列数的海量数据进行存储,也即实现了数据存储列表的宽度的无限拓展。
为了使本技术领域的人员更好地理解本发明方案,下面结合附图和具体实施方式对本发明作进一步的详细说明。显然,所描述的实施例仅仅是本发明一部分实施例,而不是全部的实施例。基于本发明中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例,都属于本发明保护的范围。
申请人发现,BigTable采用的是Key-value的实现机制,设计上支持一维拓展,即可以将数据存储表进行横向切割,将属于同一列的不同部分分别存储在不同的计算节点上,但不能进行数据存储表的二维拓展,即需要将所有的列都存放在一台物理服务器上,自然,受限于该台物理服务器的内存以及磁盘IO带宽等瓶颈,BigTable的存储方式中数据存储表的列的数量自然是有限的,即对于物联网数据这类爆发性增长的数据而言,BigTable的表宽不能满足要求。
请参考图1,图1为本发明中一种基于大数据的数据存储方法的实施流程图,该方法包括以下步骤:
S101:根据业务参数以及各个计算集群的硬件参数,为每个计算集群规划各自存储的数据列数。
根据业务参数以及各个计算集群的硬件参数,为每个计算集群规划各自存储的数据列数,指的是各个计算集群各自存储的数据列数要符合业务参数的要求以及各个计算集群的硬件参数的要求。具体的,各个计算集群各自存储的数据列数的总和可以等于业务所需存储的数据总列数,并且考虑到业务量的变动,还可以留有一定的裕度,即对于任一计算集群而言,该计算集群还富余有一定量的存储能力以存储更多列数据。针对任一计算集群,该计算集群存储的数据列数要符合该计算集群的硬件参数的要求,即为该计算集群规划其需要存储的数据列数时,不能超出该计算集群所能够存储的最大的数据列数,并且考虑到各种扰动因素,规划时也要留有相应的裕度,即为该计算集群规划的进行存储的数据列数通常会小于其理论上能够存储的最大的数据列数。
计算集群的硬件参数决定了该计算集群能够支撑的最大的列的数量,为该计算集群规划的进行存储的数据列数自然要小于等于该最大列数量,具体的数值可以根据实际情况进行设定和调整,并不影响本发明的实施。例如在服务器运行稳定,业务量也较为稳定的场合中,可以将该计算集群进行存储的数据列数规划地略小于最大列数量。
由于每个Cabinet有着与之对应的计算集群,因此规划每个计算集群各自存储的数据列数,也就是在规划各个Cabinet的列的数量。通常来说,计算集群与Cabinet之间的数量对应关系为1∶1的对应关系,因此后文中均以每个Cabinet与唯一的计算集群对应来进行说明。
一个计算集群能够支撑的最大列数量受到多个参数的影响,不妨定义:T表示内存中缓存数据全部持久化到磁盘的周期,单位为秒。B表示在T周期内预设的每个列每次连续写入的最大数据块大小,单位为byte/次。M表示指定的Cabinet总共列的数量,单位为个。S表示每秒每列新增字节数量,单位为byte/秒。C表示缓存内存大小,单位为byte。L表示磁盘每秒并发I/O数量,即IOPS(Input/Output Operations Per Second,每秒进行读写操作的次数),单位为次/秒。W表示内存吞吐数据量,单位为byte/秒。δ表示写放大倍数。μ表示缓存分配到SuperTable的比例。λ表示磁盘I/O带宽分配给SuperTable的比例。γ表示分配给SuperTable的I/O带宽再分配给写入负载的比例。
如果要达到最大的写入负载,则要求:T时间范围内持久化到磁盘数据量等于T时间范围内新增数据量,写入后及时清空缓存;磁盘IOPS预设的写入块大小应等于B。因此可以得到:T×L×B=T×M×S×δ。即M=LB/Sδ。其中,δ在不同的存储体系架构下有所不同,通常计算方法是δ=实际写入数据量/应该写入数据量。并且在具体的实施环境中,S、δ、λ以及γ这四个量可以为已知量或可根据经验数据进行确定。因此,M的大小取决于LB的大小,特别是B的大小决定了计算集群能够支撑的最大的数据列数。在一般的存储环境中,L×B表达的是不同大小的B对应最大磁盘吞吐能力,并且一般当B≥128KB的时候,L×B就接近了磁盘吞吐最大能力,也就是顺序I/O的能力。
需要指出的是,在一些具体实施场景中,通过设定B的大小以决定计算集群能够支撑的最大数据列时,还需要考虑其他硬件参数对最大支撑列的影响。例如通常考虑以下4个硬件参数对计算集群的最大支撑列的影响。
缓存大小C=μ×M×B=LBμB/Sδ,通常来说,数据库系统分配给读写缓存的空间是有限的,在缓存空间有限时,提高B会使得M降低。
内存吞吐量W=μ×M×S,由于SuperTable的写入场景中,内存写是随机写,在运行时内存能支撑的带宽通常远小于顺序写场景下内存的带宽,因此,当列的数量与每秒新增加数据量S达到一定阈值的时候,内存吞吐量将成为设计计算集群的最大支持列的瓶颈。
磁盘每秒并发I/O数量L≥δM/T,由于B对L的大小有直接影响,通常,在同样存储硬件条件下,例如SSD、HDD等硬件条件下,B越小,L越大。由于需要使得L≥δM/T,也就意味着B越小,对存储硬件的要求就越小。
缓存周期T=B/S,T决定了缓存数据持久化到硬盘的时间,当出现机器宕机时,即使系统有日志以保护数据的安全,如果T过高,数据长时间不持久化,会导致恢复系统工作的时间非常长。
S102:在虚拟数据库中构建包含每个计算集群中存储的每一列数据的超级表格SuperTable,并根据每个计算集群各自存储的数据列数,将SuperTable纵向切分为多个目标列表Cabinet。
虚拟数据库是由数据联邦演进而来的数据整合、统一访问的技术,通过该技术,可以实现多个异构数据库在不必物理集中的情况下虚拟成一个逻辑数据库,并支持以SQL语义对所整合异构数据库的无缝访问。本申请中,在虚拟数据库中构建超级表格SuperTable,SuperTable中包含有每个计算集群中存储的每一列数据,即SuperTable的列数等于业务中的总的数据列数。将SuperTable进行纵向切分,切分为任意数量的Cabinet,可参阅图2,图2为SuperTable存储模型示意图。图2中,Cabinet相当于一定数量的Si连续的列。例如SuperTable中共有20万列,纵向切分后,将第一列至第五万列作为Cabinet1,第五万零一列至第十五万列作为Cabinet2,第十五万零一列至第二十万列作为Cabinet3。
通常,每个Cabinet对应唯一的计算集群,一个计算集群可以由一个或多个存储设备构成,对于每个Cabinet而言,均支持横向切割,即可以与现有技术中的横向切割方式相同。在Cabinet内部,考虑到计算负载均衡等因素,当计算集群为多个存储设备构成时,这些存储设备通常为相同的配置。但不同的Cabinet之间,即不同的计算集群之间,配置可以不同,以使得本申请的方案支持异构的计算集群部署,更好地复用遗留资产。
S103:构建路由信息,以使得在对SuperTable中的任意列进行读写操作时定位到相应的计算集群中,路由信息中包括每个Cabinet各自对应的计算集群的信息,以及每个Cabinet与SuperTable之间的映射关系。
由于路由信息中包括每个Cabinet各自对应的计算集群的信息,以及每个Cabinet与SuperTable之间的映射关系,也就是说,路由信息确定了Cabinet中的列与SuperTable中的列的一一对应关系,因此针对SuperTable中的任意一列数据,均可以确定出该列数据所在的Cabinet。并且根据Cabinet与计算集群之间的对应关系,可以确出Cabinet中的任意列对应的计算集群。当对SuperTable中的任意列进行读写操作时,通过路由信息即可定位到相应的计算集群中。
路由信息可以为路由表的形式,例如可以将Cabinet中的列与SuperTable中的列的对应信息作为路由表1,将Cabinet与计算集群之间的对应关系记录为路由表2,并不影响本发明的实施。可参阅图3,为本发明中路由表的一种结构示意图,图3中的路由表记录了Cabinet中的列与SuperTable中的列的对应关系。
在本发明的一种具体实施方式中,路由信息可以具体包括:ColumnFamilyID:列族,例如对“量测设备维度”进行标识时,量测设备包含的“量测属性维度”即为该列族中的列;CabinetID:唯一标识指定数据库集群管理的连续列族(也即连续列),每个Cabinet对应唯一的数据库计算集群;CFOffsetInCabinet:指定列族在指定的Cabinet上的偏移量;ColumnRangePerCabinet:指定Cabinet包含的连续列范围,一般为所含各个列族列数量的总和;ClusterID:唯一标识对应指定Cabinet的数据库计算集群,与Cabinet一一对应。
应用本发明实施例所提供的方法,包括:根据业务参数以及各个计算集群的硬件参数,为每个计算集群规划各自存储的数据列数;在虚拟数据库中构建包含每个计算集群中存储的每一列数据的超级表格SuperTable,并根据每个计算集群各自存储的数据列数,将SuperTable纵向切分为多个目标列表Cabinet;构建路由信息,以使得在对SuperTable中的任意列进行读写操作时定位到相应的计算集群中,路由信息中包括每个Cabinet各自对应的计算集群的信息,以及每个Cabinet与SuperTable之间的映射关系。
在虚拟数据库中构建的SuperTable包含了每个计算集群中存储的每一列数据,即SuperTable包含了所有的存储数据,对于计算集群中的每一列数据,都可以根据路由信息在SuperTable进行相应的定位,也就消除了列与列直接的连接计算的开销。而由于将SuperTable纵向切分为多个目标列表Cabinet,使得SuperTable的列数由Cabinet的数量以及各个Cabinet中包含的列数决定。SuperTable纵向切分的次数并不限定,也即并不限定Cabinet的数量,每个Cabinet有着与之对应的进行数据存储的计算集群,因此不论SuperTable中的列数有多少,均可以通过一定次数的纵向切分,使得SuperTable被切分为各个Cabinet以便由相应的计算集群进行存储。因此,本申请中的方案通过对构建的SuperTable进行列方向的切分,使得可以对具有任意列数的海量数据进行存储,也即实现了数据存储列表的宽度的无限拓展,即SuperTable的表宽的无限拓展。
在本发明的一种具体实施方式中,在步骤S103之后,还包括以下三个步骤:
步骤一:接收目标读写指令;
步骤二:通过解析目标读写指令,并根据路由信息生成针对待读写的一个或多个Cabinet的目标执行指令;
步骤三:根据目标执行指令进行数据的读写。
可以由客户端发送目标读写指令,虚拟数据库接收该目标读写指令。通常,用户只有通过虚拟数据库才可见SuperTable,所有I/O访问都是针对SuperTable。目标读写指令通常可以为SQL指令,并且可以由虚拟数据库的SQL解析器对SQL指令进行解析,并根据路由信息,由执行计划生成器生成相应的目标执行指令,将目标执行指令发送至相应的计算集群中即可进行数据的读写。
数据的读写可以包括数据的采集,数据的录入,数据的删除等多种数据的操作方式,对于大数据而言,特别是物联网数据,对计算集群中的数据列进行数据采集是常见的操作。并且对于物联网数据而言,数据的连接计算(JOIN)通常只发生在“时间戳”这一列,本申请中在设计SuperTable时将各列数据的时间戳对齐,也就消除了数据连接的计算开销。例如在一种具体实施方式中,将SuperTable中每一列作为量测设备的一个属性,例如将1号量测设备一年中每天的最高温度数据作为第一列,将2号量测设备一年中每天的最高温度数据作为第二列,且两列的时间戳对齐,则在一个Cabinet内部,可以消除表内各个量测设备之间的JOIN操作,提升执行效率,在进行跨Cabinet的多个数据列之间的基于时间戳的JOIN运算时,可以使用Spark SQL的机制,抽取参与计算的Cabinet的时间戳一列进行比对,找到对应的行,然后再转化为对每个Cabinet相关列的Sequence scan与filter运算。
在具体实施时,上述步骤三具体可以为:
当确定出的待读写的Cabinet为多个时,将目标执行指令分解为与待读写的Cabinet数量相同的多个子目标执行指令,各个子目标执行指令与各个待读写的Cabinet一一对应;
将各个子目标执行指令分别发送至对应于各个待读写的Cabinet的计算集群中进行数据的读写。
目标读写指令可以为SQL指令,当确定出的待读写的Cabinet为多个时,可以由执行计划生成器生成针对每个待读写的Cabinet的目标执行指令Sub SQL,之后将目标执行指令Sub SQL分解为多个子目标执行指令,并由执行引擎将各个子目标执行指令发送至相应的计算集群中。
便于理解,以两个Cabinet组成的SuperTable作为例子进行详细说明,每个Cabinet含有5万列。图4为该实施例的Cabinet1的存储物理表的结构示意图,图5为该实施例的Cabinet2的存储物理表的结构示意图。不妨设共有10万个测点,每个测点每秒钟写入一个测量数据CUR_VAL,每一个测试有一个额定的最大阈值LIMIT_VALUE,当测量数据超过阈值,标识为一次越限。当需要统计出1000010001,1060020301这两个测点在2017年这一年中每一天的越限次数并排序时。SQL语句可以如下:
SELECT CAST(OCCUR_TIME AS DATE)T,COUNT(1)NUM/*基于日期的分组计数*/
FROM BIGTABLE A JOIN SECINFO B ON A.SEC_ID=B.ID/*联合查询*/
WHERE A.SEC_ID IN(1000010001,1060020301)/*指定的测点*/
AND A.CUR_VAL>B.LIMIT_VALUE/*越限*/
AND A.OCCUR_TIME>'2017-01-01 00:00:00'AND A.OCCUR_TIME<'2018-01-0100:00:00'
GROUP BY T/*基于日期的分组*/
ORDER BY T/*排序*/
由于1000010001,1060020301这两个测点对应的数据分布在不同的Cabinet所包含的表中,分别是YC_TABLE_1的C2953列以及YC_TABLE_2的C22923列,且第一个测点的阈值为360,第二个测点的阈值为650,因此到达两个Cabinet表的Sub SQL如下:
发给Cabinet1的第一个测点1000010001的Sub SQL为:
SELECT
CAST(TS AS DATE),
COUNT(1),
1AS KI
FROM YC_TABLE_1
WHERE
(360.000000<C2953)AND C2953IS NOT NULL
AND(TS>'2017-01-01 00:00:00')AND(TS<'2018-01-01 00:00:00')
GROUP BY CAST(TS AS DATE)
相应的,发给Cabinet2的第二个测点1060020301的Sub SQL为:
SELECT
CAST(TS AS DATE),
COUNT(1),
1AS KI
FROM YC_TABLE_1
WHERE
(360.000000<C2953)AND C2953IS NOT NULL
AND(TS>'2017-01-01 00:00:00')AND(TS<'2018-01-01 00:00:00')
GROUP BY CAST(TS AS DATE)
在本发明的一种具体实施方式中,业务参数包括:业务数据的列的数量,采集业务数据的频率,采集业务数据的吞吐量。
通常,对于具体的业务需要,可以在预先设定好计算集群的数量之后,根据业务参数确定各个计算集群需要进行存储的数据的列数,进而确定出计算集群的硬件配置。例如,业务要求为:指定Cabinet需要支持一百万列,数据每秒采集一次,吞吐每秒100万测点数据/节点,那么,如果使M=1000000,单测点每秒增加数据量16Byte以保证精度,使用LSM机制的存储引擎,写放大倍数δ=1,预设磁盘B=4KB,实际缓存分配系数μ=3,那么需要:
内存缓存周期T=B/S=4096/16=256秒;磁盘IOPS要求L≥δM/T=1×1000000/256=3900;内存吞吐量为1000000×16B=16MB/s;内存缓存大小C=3×1000000×4096=12GB;即使得计算集群配置这样的参数,即可满足该种情况下的业务需求。
在本发明的一种具体实施方式中,路由信息中还包括:各个计算集群的访问方式信息。具体可以为数据库访问用户的信息,各端口信息,计算集群的各个主机地址信息等。
相应于上面的方法实施例,本发明实施例还提供了一种基于大数据的数据存储系统,下文描述的基于大数据的数据存储系统与上文描述的一种基于大数据的数据存储方法可相互对应参照。
参见图6所示,为本发明中一种基于大数据的数据存储系统的结构示意图,该系统包括:
计算集群规划模块601,用于根据业务参数以及各个计算集群的硬件参数,为每个计算集群规划各自存储的数据列数;
Cabinet构建模块602,用于在虚拟数据库中构建包含每个计算集群中存储的每一列数据的超级表格SuperTable,并根据每个计算集群各自存储的数据列数,将SuperTable纵向切分为多个目标列表Cabinet;
路由信息构建模块603,用于构建路由信息,以使得在对SuperTable中的任意列进行读写操作时定位到相应的计算集群中,路由信息中包括每个Cabinet各自对应的计算集群的信息,以及每个Cabinet与SuperTable之间的映射关系。
在本发明的一种具体实施方式中,还包括:
目标读写指令接收模块,用于接收目标读写指令;
解析模块,用于通过解析目标读写指令,并根据路由信息生成针对待读写的一个或多个Cabinet的目标执行指令;
读写模块,用于根据目标执行指令进行数据的读写。
在本发明的一种具体实施方式中,读写模块,具体用于:
当确定出的待读写的Cabinet为多个时,将目标执行指令分解为与待读写的Cabinet数量相同的多个子目标执行指令,各个子目标执行指令与各个待读写的Cabinet一一对应;
将各个子目标执行指令分别发送至对应于各个待读写的Cabinet的计算集群中进行数据的读写。
相应于上面的方法和系统实施例,本发明实施例还提供了一种基于大数据的数据存储设备,下文描述的基于大数据的数据存储设备与上文描述的一种基于大数据的数据存储方法和系统可相互对应参照。
参见图7所示,为本发明中一种基于大数据的数据存储设备的结构示意图,该设备包括:
存储器701,用于存储数据存储程序;
处理器702,用于执行数据存储程序以实现上述任一实施例中的基于大数据的数据存储方法的步骤。
相应于上面的方法、系统和设备实施例,本发明实施例还提供了一种计算机可读存储介质,该计算机可读存储介质上存储有数据存储程序,该数据存储程序被处理器执行时实现上述任一实施例中的基于大数据的数据存储方法的步骤,此处不重复说明。
本说明书中各个实施例采用递进的方式描述,每个实施例重点说明的都是与其它实施例的不同之处,各个实施例之间相同或相似部分互相参见即可。对于实施例公开的系统、设备及计算机可读存储介质而言,由于其与实施例公开的方法相对应,所以描述的比较简单,相关之处参见方法部分说明即可。
专业人员还可以进一步意识到,结合本文中所公开的实施例描述的各示例的单元及算法步骤,能够以电子硬件、计算机软件或者二者的结合来实现,为了清楚地说明硬件和软件的可互换性,在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行,取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能,但是这种实现不应认为超出本发明的范围。
本文中应用了具体个例对本发明的原理及实施方式进行了阐述,以上实施例的说明只是用于帮助理解本发明的技术方案及其核心思想。应当指出,对于本技术领域的普通技术人员来说,在不脱离本发明原理的前提下,还可以对本发明进行若干改进和修饰,这些改进和修饰也落入本发明权利要求的保护范围内。
Claims (10)
1.一种基于大数据的数据存储方法,其特征在于,包括:
根据业务参数以及各个计算集群的硬件参数,为每个所述计算集群规划各自存储的数据列数;
在虚拟数据库中构建包含每个所述计算集群中存储的每一列数据的超级表格SuperTable,并根据每个所述计算集群各自存储的所述数据列数,将所述SuperTable纵向切分为多个目标列表Cabinet;
构建路由信息,以使得在对所述SuperTable中的任意列进行读写操作时定位到相应的计算集群中,所述路由信息中包括每个所述Cabinet各自对应的所述计算集群的信息,以及每个所述Cabinet与所述SuperTable之间的映射关系。
2.根据权利要求1所述的基于大数据的数据存储方法,其特征在于,在所述构建路由信息之后,还包括:
接收目标读写指令;
通过解析所述目标读写指令,并根据所述路由信息生成针对待读写的一个或多个所述Cabinet的目标执行指令;
根据所述目标执行指令进行数据的读写。
3.根据权利要求2所述的基于大数据的数据存储方法,其特征在于,所述根据所述目标执行指令进行数据的读写,包括:
当确定出的待读写的所述Cabinet为多个时,将所述目标执行指令分解为与待读写的所述Cabinet数量相同的多个子目标执行指令,各个所述子目标执行指令与各个待读写的所述Cabinet一一对应;
将各个所述子目标执行指令分别发送至对应于各个待读写的所述Cabinet的计算集群中进行数据的读写。
4.根据权利要求1所述的基于大数据的数据存储方法,其特征在于,所述业务参数包括:业务数据的列的数量,采集所述业务数据的频率,采集所述业务数据的吞吐量。
5.根据权利要求1所述的基于大数据的数据存储方法,其特征在于,所述各个计算集群的硬件参数包括:各个计算集群各自的磁盘每秒并发IO数量,各个所述计算集群各自的内存大小,各个所述计算集群各自的内存吞吐量。
6.根据权利要求1所述的基于大数据的数据存储方法,其特征在于,所述计算集群与所述Cabinet之间的数量对应关系为1∶1的对应关系。
7.根据权利要求1至6任一项所述的基于大数据的数据存储方法,其特征在于,所述路由信息中还包括:各个所述计算集群的访问方式信息。
8.一种基于大数据的数据存储系统,其特征在于,包括:
计算集群规划模块,用于根据业务参数以及各个计算集群的硬件参数,为每个所述计算集群规划各自存储的数据列数;
Cabinet构建模块,用于在虚拟数据库中构建包含每个所述计算集群中存储的每一列数据的超级表格SuperTable,并根据每个所述计算集群各自存储的所述数据列数,将所述SuperTable纵向切分为多个目标列表Cabinet;
路由信息构建模块,用于构建路由信息,以使得在对所述SuperTable中的任意列进行读写操作时定位到相应的计算集群中,所述路由信息中包括每个所述Cabinet各自对应的所述计算集群的信息,以及每个所述Cabinet与所述SuperTable之间的映射关系。
9.一种基于大数据的数据存储设备,其特征在于,包括:
存储器,用于存储数据存储程序;
处理器,用于执行所述数据存储程序以实现权利要求1至7任一项所述的基于大数据的数据存储方法的步骤。
10.一种计算机可读存储介质,其特征在于,所述计算机可读存储介质上存储有数据存储程序,所述数据存储程序被处理器执行时实现如权利要求1至7任一项所述的基于大数据的数据存储方法的步骤。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201810560730.5A CN108763559B (zh) | 2018-05-25 | 2018-05-25 | 一种基于大数据的数据存储方法、系统、设备及存储介质 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201810560730.5A CN108763559B (zh) | 2018-05-25 | 2018-05-25 | 一种基于大数据的数据存储方法、系统、设备及存储介质 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN108763559A CN108763559A (zh) | 2018-11-06 |
CN108763559B true CN108763559B (zh) | 2021-10-01 |
Family
ID=64002156
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201810560730.5A Active CN108763559B (zh) | 2018-05-25 | 2018-05-25 | 一种基于大数据的数据存储方法、系统、设备及存储介质 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN108763559B (zh) |
Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN1719422A (zh) * | 2005-08-18 | 2006-01-11 | 北京中星微电子有限公司 | 一种存储器文件数据虚拟存取方法 |
CN102479200A (zh) * | 2010-11-26 | 2012-05-30 | 金蝶软件(中国)有限公司 | 一种多维度动态数据表生成方法、装置及终端 |
CN103020139A (zh) * | 2012-11-21 | 2013-04-03 | 用友软件股份有限公司 | 数据表扩展系统和数据表扩展方法 |
CN105303305A (zh) * | 2015-10-15 | 2016-02-03 | 武汉大学 | 一种插件式业务流程家族的协同演化方法 |
CN106649455A (zh) * | 2016-09-24 | 2017-05-10 | 孙燕群 | 一种大数据开发的标准化系统归类、命令集系统 |
Family Cites Families (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US9501483B2 (en) * | 2012-09-18 | 2016-11-22 | Mapr Technologies, Inc. | Table format for map reduce system |
-
2018
- 2018-05-25 CN CN201810560730.5A patent/CN108763559B/zh active Active
Patent Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN1719422A (zh) * | 2005-08-18 | 2006-01-11 | 北京中星微电子有限公司 | 一种存储器文件数据虚拟存取方法 |
CN102479200A (zh) * | 2010-11-26 | 2012-05-30 | 金蝶软件(中国)有限公司 | 一种多维度动态数据表生成方法、装置及终端 |
CN103020139A (zh) * | 2012-11-21 | 2013-04-03 | 用友软件股份有限公司 | 数据表扩展系统和数据表扩展方法 |
CN105303305A (zh) * | 2015-10-15 | 2016-02-03 | 武汉大学 | 一种插件式业务流程家族的协同演化方法 |
CN106649455A (zh) * | 2016-09-24 | 2017-05-10 | 孙燕群 | 一种大数据开发的标准化系统归类、命令集系统 |
Non-Patent Citations (1)
Title |
---|
一致性哈希算法在数据库集群上的拓展应用;赵飞等;《成都信息工程学院学报》;20150227;第30卷(第1期);第52-58页 * |
Also Published As
Publication number | Publication date |
---|---|
CN108763559A (zh) | 2018-11-06 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US11960464B2 (en) | Customer-related partitioning of journal-based storage systems | |
US10740308B2 (en) | Key_Value data storage system | |
US10346434B1 (en) | Partitioned data materialization in journal-based storage systems | |
CN103902623B (zh) | 用于在存储系统上存取文件的方法和系统 | |
US9424274B2 (en) | Management of intermediate data spills during the shuffle phase of a map-reduce job | |
US20190026042A1 (en) | Deduplication-Aware Load Balancing in Distributed Storage Systems | |
US8868576B1 (en) | Storing files in a parallel computing system based on user-specified parser function | |
US9940356B2 (en) | Efficient join-filters for parallel processing | |
EP2199935A2 (en) | Method and system for dynamically partitioning very large database indices on write-once tables | |
JP2017507426A (ja) | 半構造データスキーマのトランスペアレントディスカバリ | |
WO2017131791A1 (en) | Log event cluster analytics management | |
US11321302B2 (en) | Computer system and database management method | |
KR20100070968A (ko) | 클러스터 데이터 관리 시스템 및 클러스터 데이터 관리 시스템에서 병렬 처리를 이용한 데이터 복구 방법 | |
CN111427847B (zh) | 面向用户自定义元数据的索引与查询方法和系统 | |
CN106570113B (zh) | 一种海量矢量切片数据云存储方法及系统 | |
CN104536908B (zh) | 一种面向单机的海量小记录高效存储管理方法 | |
JP6269140B2 (ja) | アクセス制御プログラム、アクセス制御方法、およびアクセス制御装置 | |
CN113468107A (zh) | 数据处理方法、设备、存储介质及系统 | |
Grandi et al. | Frame-sliced partitioned parallel signature files | |
CN109325011A (zh) | 基于区块链的数据存储、处理、分享方法及系统 | |
CN108763559B (zh) | 一种基于大数据的数据存储方法、系统、设备及存储介质 | |
WO2016175880A1 (en) | Merging incoming data in a database | |
Barbuzzi et al. | Parallel bulk Insertion for large-scale analytics applications | |
CN113360551B (zh) | 一种靶场中时序数据的存储与快速统计方法及系统 | |
Wu et al. | Indexing blocks to reduce space and time requirements for searching large data files |
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 | ||
GR01 | Patent grant | ||
GR01 | Patent grant |