CN106933935A - 任务存储方法和装置 - Google Patents

任务存储方法和装置 Download PDF

Info

Publication number
CN106933935A
CN106933935A CN201511034188.2A CN201511034188A CN106933935A CN 106933935 A CN106933935 A CN 106933935A CN 201511034188 A CN201511034188 A CN 201511034188A CN 106933935 A CN106933935 A CN 106933935A
Authority
CN
China
Prior art keywords
data
information
task
amount information
condition
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.)
Granted
Application number
CN201511034188.2A
Other languages
English (en)
Other versions
CN106933935B (zh
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.)
Beijing Gridsum Technology Co Ltd
Original Assignee
Beijing Gridsum Technology 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 Beijing Gridsum Technology Co Ltd filed Critical Beijing Gridsum Technology Co Ltd
Priority to CN201511034188.2A priority Critical patent/CN106933935B/zh
Publication of CN106933935A publication Critical patent/CN106933935A/zh
Application granted granted Critical
Publication of CN106933935B publication Critical patent/CN106933935B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

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/22Indexing; Data structures therefor; Storage structures
    • G06F16/221Column-oriented storage; Management thereof
    • 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/22Indexing; Data structures therefor; Storage structures
    • G06F16/2282Tablespace storage structures; Management thereof
    • 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/27Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
    • G06F16/278Data partitioning, e.g. horizontal or vertical partitioning

Landscapes

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

Abstract

本发明公开了一种任务存储方法和装置。其中,该方法包括:获取待存储的任务集合;根据每个任务数据对应的数据量信息,从预设的元数据中确定每个任务数据对应的分组信息;根据每个任务数据对应的分组信息和分区信息,从预先配置的外部数据文件中读取每个任务数据相应的存储位置;将任务集合中的每个任务数据分别存储到每个任务数据相应的存储位置。本发明解决了现有技术中任务数据按类型信息存在分布式数据库中,会产生碎文件导致系统性能低下的技术问题。

Description

任务存储方法和装置
技术领域
本发明涉及数据库领域,具体而言,涉及一种任务存储方法和装置。
背景技术
现有技术中,针对多个用户,做数据分析时,一个用户可能对应一个profile(用户配置文件),或是一堆profile(数据分析的相应网站唯一字段)。用户既希望在查看单网站数据时能获得很高的分析能力,又希望能将所有profile数据放在一起,来查看整个站群的相关数据,这就发生了一个矛盾,将所有数据放在同一个数据库里,会导致在查询单网站时,由于有其它站群网站的数据干扰,影响了查询速度。
对于很多站群来说,有很多的小网站,其数据量极少,如果仅按相应的prfile网站对数据库中的数据表进行分区的话,会导致很多的碎文件,这在大数据领域是需要避免的,会导致分布式任务的不均匀,同时任务量会暴增,影响整个集群的效率,无论是存储还是查询都会影响,如果小文件数过多,会导致hadoop生态群的hdfs(Hadoop Distributed FileSystem,Hadoop分布式文件系统)崩溃。
针对现有技术中任务数据按类型信息存在分布式数据库中,会产生碎文件导致系统性能低下的技术问题,目前尚未提出有效的解决方案。
发明内容
本发明实施例提供了一种任务存储方法和装置,以至少解决现有技术中任务数据按类型信息存在分布式数据库中,会产生碎文件导致系统性能低下的技术问题。
根据本发明实施例的一个方面,提供了一种任务存储方法,包括:获取待存储的任务集合,其中,任务集合包括:多个任务数据,以及每个任务数据对应的数据量信息和分区信息;根据每个任务数据对应的数据量信息,从预设的元数据中确定每个任务数据对应的分组信息,其中,将数据量信息为第一数据量的任务数据确定为碎片数据,将数据量信息为第二数据量的任务数据确定为普通数据,普通数据和碎片数据对应的不同的分组信息,第一数据量小于第二数据量,元数据用于保存每个数据量信息和每个分组信息的对应关系;根据每个任务数据对应的分组信息和分区信息,从预先配置的外部数据文件中读取每个任务数据相应的存储位置;将任务集合中的每个任务数据分别存储到每个任务数据相应的存储位置。
根据本发明实施例的另一方面,还提供了一种任务存储装置,包括:第一获取单元,用于获取待存储的任务集合,其中,任务集合包括:多个任务数据,以及每个任务数据对应的数据量信息和分区信息;第一确定单元,用于根据每个任务数据对应的数据量信息,从预设的元数据中确定每个任务数据对应的分组信息,其中,将数据量信息为第一数据量的任务数据确定为碎片数据,将数据量信息为第二数据量的任务数据确定为普通数据,普通数据和碎片数据对应的不同的分组信息,第一数据量小于第二数据量,元数据用于保存每个数据量信息和每个分组信息的对应关系;第一读取单元,用于根据每个任务数据对应的分组信息和分区信息,从预先配置的外部数据文件中读取每个任务数据相应的存储位置;存储单元,用于将任务集合中的每个任务数据分别存储到每个任务数据相应的存储位置。
在本发明实施例中,在获取到待存储的多个任务数据,以及每个任务数据对应的数据量信息和分区信息之后,根据每个任务数据对应的数据量信息,从预设的元数据中确定每个任务数据对应的分组信息,并根据每个任务数据对应的分组信息和分区信息,从预先配置的外部数据文件中读取每个任务数据相应的存储位置,将任务集合中的每个任务数据分别存储到每个任务数据相应的存储位置。因此,本方案通过根据数据量信息确定预设的分组信息,进一步根据分组信息获取外部数据文件中的存储位置,保证在查询大数据量任务数据不会受到其它大数据量任务数据的影响,又保证在查询多个任务数据时,各分区文件不会有碎文件产生,不会导致性能低下,从而解决了现有技术中任务数据按类型信息存在分布式数据库中,会产生碎文件导致系统性能低下的技术问题。
附图说明
此处所说明的附图用来提供对本发明的进一步理解,构成本申请的一部分,本发明的示意性实施例及其说明用于解释本发明,并不构成对本发明的不当限定。在附图中:
图1是根据本发明实施例的一种任务存储方法的流程图;
图2是根据本发明实施例的一种任务存储装置的示意图;
图3是根据本发明实施例的一种可选的任务存储装置的示意图;
图4是根据本发明实施例的一种可选的任务存储装置的示意图;
图5是根据本发明实施例的一种可选的任务存储装置的示意图;
图6是根据本发明实施例的一种可选的任务存储装置的示意图;以及
图7是根据本发明实施例的一种可选的任务存储装置的示意图。
具体实施方式
为了使本技术领域的人员更好地理解本发明方案,下面将结合本发明实施例中的附图,对本发明实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅仅是本发明一部分的实施例,而不是全部的实施例。基于本发明中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例,都应当属于本发明保护的范围。
需要说明的是,本发明的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象,而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换,以便这里描述的本发明的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外,术语“包括”和“具有”以及他们的任何变形,意图在于覆盖不排他的包含,例如,包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元,而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。
首先,在对本申请实施例进行描述的过程中出现的部分名词或术语适用于如下解释:
Parquet为一种列存储格式,是目前很流行的一种列式存储文件,在分布式实时查询引擎里,多用做外部存储文件,如Impala,hive等,本申请实施例均以impala查询引擎进行举例说明。
ETL:Extract-Transform-Load简称,用来描述将数据从来源端经过抽取(extract)、转换(transform)、加载(load)至目的端的过程。ETL是构建数据仓库的重要一环,用户从数据源抽取出所需的数据,经过数据清洗,最终按照预先定义好的数据仓库模块,将数据假造到数据仓库中取。
实施例1
根据本发明实施例,提供了一种任务存储方法实施例,需要说明的是,在附图的流程图示出的步骤可以在诸如一组计算机可执行指令的计算机系统中执行,并且,虽然在流程图中示出了逻辑顺序,但是在某些情况下,可以以不同于此处的顺序执行所示出或描述的步骤。
图1是根据本发明实施例的一种任务存储方法的流程图,如图1所示,该方法包括如下步骤:
步骤S102,获取待存储的任务集合,其中,任务集合包括:多个任务数据,以及每个任务数据对应的数据量信息和分区信息。
具体地,上述任务数据可以是网站profile数据,每个网站数据对应的类型信息可以是网站标识,例如profi leid,每个网站数据对应的分区信息可以是时间天,例如date。
步骤S104,根据每个任务数据对应的数据量信息,从预设的元数据中确定每个任务数据对应的分组信息,其中,将数据量信息为第一数据量的任务数据确定为碎片数据,将数据量信息为第二数据量的任务数据确定为普通数据,普通数据和碎片数据对应的不同的分组信息,第一数据量小于第二数据量,元数据用于保存每个数据量信息和每个分组信息的对应关系。第一数据量可以为数据量范围,第二数据量也相应的为数据量范围,且第一数据量的上限阈值小于第二数据量的下限阈值。
具体地,上述分组信息可以是profilegroup。
可选地,可以通过预先设定元数据,将大的profile(即上述的普通数据)进行单独划分,将同一站群里小众profile(即上述的碎片数据)均放置在一起,从而既保证在查询大profile时不会有站群内其它大数据量profile的影响,又保证在查询整个站群数据时,各分区文件不会有碎文件产生,不会导致性能低下,在查询小profile的数据时,虽然会比单独按profile分区所需要加载的数据要多一些,但由于其数据量本身很小,和其放在一起的都是小众profile,实则对性能的影响很小。
步骤S106,根据每个任务数据对应的分组信息和分区信息,从预先配置的外部数据文件中读取每个任务数据相应的存储位置。
具体地,上述外部数据文件可以是Parquet文件,存储位置可以是数据库中各数据表分区后的数据库分区。
可选地,Parquet文件可以通过以下方式进行构造:采用按profile进行目录分割,即以“/…/profilegroup/date/Parquet Files”的形式进行目录存储,在ETL阶段对数据进行上述分流,并写入到对应的子目录去。
步骤S108,将任务集合中的每个任务数据分别存储到每个任务数据相应的存储位置。
在一种可选的方案中,在获取到需要存储的多个任务数据,以及每个任务数据对应的数据量信息和分区信息之后,预设的元数据中确定每个任务数据对应的分组信息,并从预先配置的Parquet文件中读取与每个任务数据的分组信息和分区信息对应的数据仓库分区,将每个任务数据定向存储到对应的数据仓库分区中。
例如,获取到的网站数据对应的数据量信息profile和分区信息date为profile=125和date=20151125,根据profile读取元数据中该网站数据对应的profilegroup为profilegroup=default,根据profilegroup和date读取Parquet文件中相应的分区目录,确定每个网站数据对应的数据仓库分区,即数据库分区为profilegroup=default,date=20151125,将获取到的网站数据定向存储到相应的数据库分区中。
通过本申请上述实施例,在获取到待存储的多个任务数据,以及每个任务数据对应的数据量信息和分区信息之后,根据每个任务数据对应的数据量信息,从预设的元数据中确定每个任务数据对应的分组信息,并根据每个任务数据对应的分组信息和分区信息,从预先配置的外部数据文件中读取每个任务数据相应的存储位置,将任务集合中的每个任务数据分别存储到每个任务数据相应的存储位置。因此,本方案通过根据数据量信息确定预设的分组信息,进一步根据分组信息获取外部数据文件中的存储位置,保证在查询大数据量任务数据不会有受到其它大数据量任务数据的影响,又保证在查询多个任务数据时,各分区文件不会有碎文件产生,不会导致性能低下,从而解决了现有技术中任务数据按类型信息存在分布式数据库中,会产生碎文件导致系统性能低下的技术问题。
根据本申请上述实施例,在步骤S104,根据每个任务数据对应的数据量信息,从预设的元数据中确定每个任务数据对应的分组信息之前,上述方法还包括如下步骤:
步骤S1042,获取所有任务数据的数据量信息。
步骤S1044,从所有的数据量信息中获取数据量信息为第一数据量的至少一个数据量信息,将至少一个数据量信息对应第一分组信息。
步骤S1046,从所有的数据量信息中获取数据量信息为第二数据量的任意一个数据量信息,将任意一个数据量信息对应第二分组信息。
在一种可选的方案中,可以通过预先设定元数据,为每个profile添加profilegroup的映射,指定每个profile属于哪个profilegroup的分区。通过虚拟的profile分组字段:profilegroup,来进行分区的划分,可随时进行相应分区划分的更改,将大数据量的profile进行单独划分,将同一站群里小数据量的profile均放置在一起。
根据本申请上述实施例,在步骤S106,根据每个任务数据对应的分组信息和分区信息,从预先配置的外部数据文件中读取每个任务数据相应的存储位置之前,上述方法还包括如下步骤:
步骤S112,构建用于存储待存储的任务集合的数据库,其中,数据库包含多张数据表。
步骤S114,根据预设分区条件,将数据库中的多张数据表进行划分,得到多个存储位置,其中,预设分区条件包括:分组条件和分区条件。
具体地,上述分组条件可以是profilegroup,分区条件可以是date,与外部数据文件的构造规则相同。
步骤S116,将预设分区条件和多个存储位置的对应关系保存在预先配置的外部数据文件中。
在一种可选的方案中,构建用于存储任务集合的包含多张数据表的数据库,将数据库中的多张数据表按profi legroup和date进行分区,得到多个存储位置,并在外部数据文件中保存每个存储位置和profilegroup和date的对应关系。
例如,数据表1中可以用来存储profilegroup=default,date=20151125的profile,数据表2中可以用来存储profilegroup=default,date=20151126的profile,数据表3中可以用来存储profilegroup=default-picc,date=20151126的profi le。
此处需要说明的是,可以默认所有的网站profile都属于default这个分组profileGroup,具体地程序如下:
create external table FactSession(...)
partitioned by(year INT,month INT,day INT,profileGroup string)
STORED AS PARQUET
alter table FactSession add partition(year=2015,month=1,day=1,profileGroup=default)
location'hdfs://server/wddata/2015/1/1/default'--*includes allprofile ids。
同大数据现有情况一样,所有的profile在同一个分区,不做区分。现有的测试结果表明,在绝大多数情况下,这样的性能已经足够好。ETL正常运行时,所有profile一同处理。每天处理的命令类似:
spark-wd-etl-profile all-daterange 2015-1-1~2015-1-1-partitioncount24。
但如果我们事先知道某profile体量较大,希望独立分区时,可在profile的metadata中设置profileGroup:
{
ProfileId:333,
ProfileName:"人保",
ProfileGroup:"default-picc",//默认是"default"
}
这样该分区独立进行输出,不在default范畴内:
/wddata/2015/1/1/default --all profiles except 333
/wddata/2015/1/1/default-picc --333
所以我们可以通过人工在metadata中来维护某profile的分区字段,但关键在于,绝大多数的profile,是在default分区中的,我们仅为需要特殊处理的一些profile进行人工独立分区。所以,分区数量不会膨胀。
根据本申请上述实施例,步骤S114,根据预设分区条件,将数据库中的多张数据表进行划分,得到多个存储位置,包括如下步骤:
步骤S1142,将数据库中包含的多张数据表按照分组条件划分为多个存储分区。
步骤S1144,将多个存储分区中每个存储分区按照分区条件划分为多个存储位置。
在一种可选的方案中,在构建用于存储任务集合的包含多张数据表的数据库之后,将数据库中的多张数据表按profilegroup划分为多个存储分区,并将每个存储分区按date划分为多个存储位置。
例如,构建后的数据库包含5个数据表,即数据表1,数据表2,数据表3,数据表4和数据表5,可以按profilegroup划分为两个存储分区,profilegroup=default的分区包含数据表1,数据表2和数据表4,profilegroup=default-picc的分区包含数据表3和数据表5。将profilegroup=default的分区按date划分为2个存储位置,date=20151125的存储位置包含数据表1,date=20151126的存储位置包含数据表2和数据表4;profilegroup=default-picc的分区按date划分为2个存储位置,date=20151125的存储位置包含数据表3,date=20151126的存储位置包含数据表5。
根据本申请上述实施例,在步骤S108,将任务集合中的每个任务数据分别存储到每个任务数据相应的存储位置之后,上述方法还包括如下步骤:
步骤S122,在进行数据查询的过程中,获取输入的查询条件集合,其中,查询条件集合包括:多个查询条件,以及每个查询条件包含的查询数据量信息和查询分区信息。
步骤S124,根据每个查询条件包含的查询数据量信息,从预设的元数据中确定每个查询条件对应的分组信息。
步骤S126,根据每个查询条件包含的分组信息和查询分区信息,从预先配置的外部数据文件中读取每个查询条件相应的存储位置。
步骤S128,从每个查询条件相应的存储位置中读取多个查询条件的数据信息。
在一种可选的方案中,当一个分组信息对应一个数据量信息,即将profile进行独立分区时,在进行数据查询的过程中,在获取到多个查询条件之后,可以根据每个查询条件的查询数据量信息,从预设的元数据中确定每个查询条件对应的分组信息,并根据每个查询条件对应的分组信息和每个查询条件的查询分区信息,从外部数据文件中读取每个查询条件相应的存储位置,获取每个查询条件对应的数据信息。
例如,获取到的查询数据量信息和查询分区信息为profileid=125和date=20151125,则根据查询数据量信息profileid=125从元数据中确定该查询条件对应的分组信息profilrgroup=default,根据得到的分组信息profilrgroup=default和查询分区信息date=20151125,从Parquet文件中确定存储位置/…/default/20151125,从存储位置中读取相应的数据信息。
根据本申请上述实施例,在步骤S108,将任务集合中的每个任务数据分别存储到每个任务数据相应的存储位置之后,上述方法还包括如下步骤:
步骤S132,在进行数据查询的过程中,获取输入的查询条件集合,其中,查询条件集合包括:多个查询条件,以及每个查询条件包含的查询数据量信息,查询类型信息和查询分区信息。
步骤S134,根据每个查询条件包含的查询数据量信息,从预设的元数据中确定每个查询条件对应的分组信息。
步骤S136,根据每个查询条件包含的查询类型信息,查询分区信息和每个查询条件对应的分组信息,从预先配置的外部数据文件中读取每个查询条件相应的存储位置。
步骤S138,从每个查询条件相应的存储位置中读取多个查询条件的数据信息。
在一种可选的方案中,当一个数据量信息对应多个分组信息时,在进行数据查询的过程中,在获取到多个查询条件之后,可以根据每个查询条件的查询数据量信息,从预设的元数据中确定每个查询条件对应的分组信息,并根据每个查询条件对应的分组信息和每个查询条件的查询类型信息以及查询分区信息,从外部数据文件中读取每个查询条件相应的存储位置,获取每个查询条件对应的数据信息。
此处需要说明的是,当仅使用分组信息和分区信息进行查询,无法得到查询条件的数据信息,需要在查询的时候结合类型信息。
通过本申请上述实施例,在查询时,可以根据元数据里存储的各profile对应的profilegroup的信息进行相应的分区条件添加,即动态添加profilegroup的条件,应用分区隔离的特性,加快单个profile的查询速度,同时也保持着对整站数据查询的方式。
此处需要说明的是,ProfileGroup分区可以不仅仅划分一个default,也可以采用分行业的方法,将ProfileGroup进行分区,例如可以将ProfileGroup分区为default-auto,default-finance,default-gov和default-newmedia。这样,当profile.ProfileGroup.StartsWith("default")时,sqlbuilder可以生成profileGroup=default-xxx的过滤,提升查询性能。也可以一开始就为一个大客户(如一个solution)建立单独的profilegroup(如default-picc),以便sqlbuilder根据metadata生成分区过滤进行加速。需要注意的是,使用SqlBuilder进行加速的先决条件为:profile.ProfileGroup.StartsWith("default")。若不满足,意味着profile数据可能跨越多个profileGroup分区,此时不能依靠当前profilegroup分区进行过滤和加速。这可约定为系统的一个规约。
拥有多个default分区的另一个好处,是数据重导中数据擦除步骤的性能会更好一些。
下面以某个位于default分区中的profile数据需要重新处理的情况为例进行说明。假设需要重新处理的profile为2230,已处理的全部数据是2014/1/1-2014/12/31,但2014/12/1日起存在bug,需要修复。
此时,若需重导2230的数据,把2230这个profile metadata中的profileGroup从"default"改为"2230-rerun"。然后,仅仅需要重新处理该profile的某一时间段的日志就可以了:从日志parquet中取出该profile日志,自2014/12/1起使用fix了bug的新ETL进行处理:
spark-wd-etl -profile 2230-daterange 2014-12-1~2014-12-31-partitioncount 8
需要注意的是,重导时partitioncount可设为较小的值如4或8,以防止过多小碎片文件产生。
这样所有的新数据都会写入/wddata/2014/month/day/2230-rerun中(ETL会自动根据profile的profilegroup配置写入对应分区)。
第二步,是将原default目录中2230的脏数据进行擦除,可以使用impala的sql脚本过滤掉2230的数据,并导入一临时位置(高旭已经测试过相关逻辑,在测试集群上全profile基础上作过滤一天数据约为20min+,可以接受):
create table all-except-2230 like parquet
'hdfs:/wd_data/2014/12/1/default/part-r-0.parquet' partitioned by(year INT,month INT,day INT,profileGroup STRING)
stored as parquet LOCATION'hdfs://server/some/tmp/address';
insert overwrite table all-except-2230
partition(year=2014,month=12,day=1,profileGroup='default')
select
trackerversion,profileid,gridsumid,userid,clientsessionid,serversessionid,servertime,clientip,clienthour,clientdayofweek,clienttimezone,referrerurl,referrerhostname,sourcetype,socialmedia,channelname,searchengine,searchpag eindex,keywords,adid,adcampaign,adchannel,adgroup,adsource,admedium,adkeyw ords,adcontent,ispaidtraffic,sessionproperty1,sessionproperty2,sessionprop erty3,sessionproperty4,sessionproperty5,sessionproperty6,sessionproperty7,sessionproperty8,sessionproperty9,sessionproperty10,screenresolution,color depth,flashversion,silverlightversion,javaenabled,cookieenabled,oslanguage,osbrief,osdetail,browserbrief,browserdetail,dotnetversion,ismobile,device brand,devicetype,devicename,geocode,country,province,city,district,longitu de,latitude,isp,isbounced,isnewvisitor,pvcount,sessionduration,dayssincela stvisit,isecomconverted,ifsitesearched from FactSession where profileid!=333。
随后可将位于/wddata/year/month/day/default的脏数据相关文件删掉,并将过滤后的parquet文件(即all-except-333表)从临时位置迁回/wddata/year/month/day/default相关目录即可。
此时,查询已经能够返回正常结果(因为查询不包括profileGroup字段)。处理好的2230的数据可以暂时呆在自己的2230-rerun目录,2230也继续可以使用2230-rerun分区一段时间,作充分的观察和测试。
最后一步,为了让2230的数据仅属于一个profileGroup分区(有利于sqlbuilder生成profileGroup查询进行加速),可选择将2230的profileGroup设回default,并把2230-rerun下文件按天拷贝至default相关目录下,这样2230-rerun目录可以删除,数据重导完成。
实施例2
根据本发明实施例,提供了一种任务存储装置实施例,图2是根据本发明实施例的一种任务存储装置的示意图,如图2所示,该装置包括:第一获取单元21,第一确定单元23,第一读取单元25和存储单元27。
其中,第一获取单元21用于获取待存储的任务集合,其中,任务集合包括:多个任务数据,以及每个任务数据对应的数据量信息和分区信息。
具体地,上述任务数据可以是网站profile数据,每个网站数据对应的数据量信息可以是该网站数据的数据量大小,每个网站数据对应的分区信息可以是时间天,例如date。
第一确定单元23用于根据每个任务数据对应的数据量信息,从预设的元数据中确定每个任务数据对应的分组信息,其中,将数据量信息为第一数据量的任务数据确定为碎片数据,将数据量信息为第二数据量的任务数据确定为普通数据,普通数据和碎片数据对应的不同的分组信息,第一数据量小于第二数据量,元数据用于保存每个数据量信息和每个分组信息的对应关系。
具体地,上述分组信息可以是profilegroup。
可选地,可以通过预先设定元数据,将大的profile(即上述的普通数据)进行单独划分,将同一站群里小众profile(即上述的碎片数据)均放置在一起,从而既保证在查询大profile时不会有站群内其它大数据量profile的影响,又保证在查询整个站群数据时,各分区文件不会有碎文件产生,不会导致性能低下,在查询小profile的数据时,虽然会比单独按profile分区所需要加载的数据要多一些,但由于其数据量本身很小,和其放在一起的都是小众profile,实则对性能的影响很小。
第一读取单元25用于根据每个任务数据对应的分组信息和分区信息,从预先配置的外部数据文件中读取每个任务数据相应的存储位置。
具体地,上述外部数据文件可以是Parquet文件,存储位置可以是数据库中各数据表分区后的数据库分区。
可选地,Parquet文件可以通过以下方式进行构造:采用按profile进行目录分割,即以“/…/profilegroup/date/Parquet Files”的形式进行目录存储,在ETL阶段对数据进行上述分流,并写入到对应的子目录去。
存储单元27用于将任务集合中的每个任务数据分别存储到每个任务数据相应的存储位置。
在一种可选的方案中,在获取到需要存储的多个任务数据,以及每个任务数据对应的数据量信息和分区信息之后,预设的元数据中确定每个任务数据对应的分组信息,并从预先配置的Parquet文件中读取与每个任务数据的分组信息和分区信息对应的数据仓库分区,将每个任务数据定向存储到对应的数据仓库分区中。
例如,获取到的网站数据对应的数据量信息profile和分区信息date为profile=125和date=20151125,根据profile读取元数据中该网站数据对应的profilegroup为profilegroup=default,根据profilegroup和date读取Parquet文件中相应的分区目录,确定每个网站数据对应的数据仓库分区,即数据库分区为profilegroup=default,date=20151125,将获取到的网站数据定向存储到相应的数据库分区中。
通过本申请上述实施例,在获取到待存储的多个任务数据,以及每个任务数据对应的数据量信息和分区信息之后,根据每个任务数据对应的数据量信息,从预设的元数据中确定每个任务数据对应的分组信息,并根据每个任务数据对应的分组信息和分区信息,从预先配置的外部数据文件中读取每个任务数据相应的存储位置,将任务集合中的每个任务数据分别存储到每个任务数据相应的存储位置。因此,本方案通过根据数据量信息确定预设的分组信息,进一步根据分组信息获取外部数据文件中的存储位置,保证在查询大数据量任务数据不会有受到其它大数据量任务数据的影响,又保证在查询多个任务数据时,各分区文件不会有碎文件产生,不会导致性能低下,从而解决了现有技术中任务数据按类型信息存在分布式数据库中,会产生碎文件导致系统性能低下的技术问题。
根据本申请上述实施例,如图3所示,上述装置还包括:第二获取单元31,第一处理单元33和第二处理单元35。
其中,第二获取单元31用于获取所有任务数据的数据量信息。
第一处理单元33用于从所有的数据量信息中获取数据量信息为第一数据量的至少一个数据量信息,将至少一个数据量信息对应第一分组信息。
第二处理单元35用于从所有的数据量信息中获取数据量信息为第二数据量的任意一个数据量信息,将任意一个数据量信息对应第二分组信息。
在一种可选的方案中,可以通过预先设定元数据,为每个profile添加profilegroup的映射,指定每个profile属于哪个profilegroup的分区。通过虚拟的profile分组字段:profilegroup,来进行分区的划分,可随时进行相应分区划分的更改,将大数据量的profile进行单独划分,将同一站群里小数据量的profile均放置在一起。
根据本申请上述实施例,如图4所示,上述装置还包括:构建单元41,第三处理单元43和保存单元45。
其中,构建单元41用于构建用于存储待存储的任务集合的数据库,其中,数据库包含多张数据表。
第三处理单元43用于根据预设分区条件,将数据库中的多张数据表进行划分,得到多个存储位置,其中,预设分区条件包括:分组条件和分区条件。
具体地,上述分组条件可以是profilegroup,分区条件可以是date,与外部数据文件的构造规则相同。
保存单元45用于将预设分区条件和多个存储位置的对应关系保存在预先配置的外部数据文件中。
在一种可选的方案中,构建用于存储任务集合的包含多张数据表的数据库,将数据库中的多张数据表按profi legroup和date进行分区,得到多个存储位置,并在外部数据文件中保存每个存储位置和profilegroup和date的对应关系。
例如,数据表1中可以用来存储profilegroup=default,date=20151125的profile,数据表2中可以用来存储profilegroup=default,date=20151126的profile,数据表3中可以用来存储profilegroup=default-picc,date=20151126的profi le。
此处需要说明的是,可以默认所有的网站profile都属于default这个分组profileGroup,具体地程序如下:
create external table FactSession(...)
partitioned by(year INT,month INT,day INT,profileGroup string)
STORED AS PARQUET
alter table FactSession add partition(year=2015,month=1,day=1,profileGroup=default)
location'hdfs://server/wddata/2015/1/1/default'--*includes allprofile ids。
同大数据现有情况一样,所有的profile在同一个分区,不做区分。现有的测试结果表明,在绝大多数情况下,这样的性能已经足够好。ETL正常运行时,所有profile一同处理。每天处理的命令类似:
spark-wd-etl-profile all-daterange 2015-1-1~2015-1-1-partitioncount24。
但如果我们实现知道某profile体量较大,希望独立分区时,可在profile的metadata中设置profileGroup:
{
ProfileId:333,
ProfileName:"人保",
ProfileGroup:"default-picc",//默认是"default"
}
这样该分区独立进行输出,不在default范畴内:
/wddata/2015/1/1/default --all profiles except 333
/wddata/2015/1/1/default-picc --333
所以我们可以通过人工在metadata中来维护某profile的分区字段,但关键在于,绝大多数的profile,是在default分区中的,我们仅为需要特殊处理的一些profile进行人工独立分区。所以,分区数量不会膨胀。
根据本申请上述实施例,如图5所示,第三处理单元43包括:第一处理模块51和第二处理模块53。
其中,第一处理模块51用于将数据库中包含的多张数据表按照分组条件划分为多个存储分区。
第二处理模块53用于将多个存储分区中每个存储分区按照分区条件划分为多个存储位置。
在一种可选的方案中,在构建用于存储任务集合的包含多张数据表的数据库之后,将数据库中的多张数据表按profilegroup划分为多个存储分区,并将每个存储分区按date划分为多个存储位置。
例如,构建后的数据库包含5个数据表,即数据表1,数据表2,数据表3,数据表4和数据表5,可以按profilegroup划分为两个存储分区,profilegroup=default的分区包含数据表1,数据表2和数据表4,profilegroup=default-picc的分区包含数据表3和数据表5。将profilegroup=default的分区按date划分为2个存储位置,date=20151125的存储位置包含数据表1,date=20151126的存储位置包含数据表2和数据表4;profilegroup=default-picc的分区按date划分为2个存储位置,date=20151125的存储位置包含数据表3,date=20151126的存储位置包含数据表5。
根据本申请上述实施例,如图6所示,上述装置还包括:第三获取单元61,第二确定单元63,第二读取单元65和第三读取单元67。
其中,第三获取单元61用于在进行数据查询的过程中,获取输入的查询条件集合,其中,查询条件集合包括:多个查询条件,以及每个查询条件包含的查询数据量信息和查询分区信息。
第二确定单元63用于根据每个查询条件包含的查询数据量信息,从预设的元数据中确定每个查询条件对应的分组信息。
第二读取单元65用于根据每个查询条件包含的分组信息和查询分区信息,从预先配置的外部数据文件中读取每个查询条件相应的存储位置。
第三读取单元67用于从每个查询条件相应的存储位置中读取多个查询条件的数据信息。
在一种可选的方案中,当一个分组信息对应一个数据量信息,即将profile进行独立分区时,在进行数据查询的过程中,在获取到多个查询条件之后,可以根据每个查询条件的查询数据量信息,从预设的元数据中确定每个查询条件对应的分组信息,并根据每个查询条件对应的分组信息和每个查询条件的查询分区信息,从外部数据文件中读取每个查询条件相应的存储位置,获取每个查询条件对应的数据信息。
例如,获取到的查询数据量信息和查询分区信息为profileid=125和date=20151125,则根据查询数据量信息profileid=125从元数据中确定该查询条件对应的分组信息profilrgroup=default,根据得到的分组信息profilrgroup=default和查询分区信息date=20151125,从Parquet文件中确定存储位置/…/default/20151125,从存储位置中读取相应的数据信息。
根据本申请上述实施例,如图7所示,上述装置还包括:第四获取单元71,第三确定单元73,第四读取单元75和第五读取单元77。
其中,第四获取单元71用于在进行数据查询的过程中,获取输入的查询条件集合,其中,查询条件集合包括:多个查询条件,以及每个查询条件包含的查询数据量信息,查询类型信息和查询分区信息。
第三确定单元73用于根据每个查询条件包含的查询数据量信息,从预设的元数据中确定每个任务数据对应的分组信息。
第四读取单元75用于根据每个查询条件包含的查询类型信息,查询分区信息和每个查询条件对应的分组信息,从预先配置的外部数据文件中读取每个查询条件相应的存储位置。
第五读取单元77用于从每个查询条件相应的存储位置中读取多个查询条件的数据信息。
在一种可选的方案中,当一个数据量信息对应多个分组信息时,在进行数据查询的过程中,在获取到多个查询条件之后,可以根据每个查询条件的查询数据量信息,从预设的元数据中确定每个查询条件对应的分组信息,并根据每个查询条件对应的分组信息和每个查询条件的查询类型信息以及查询分区信息,从外部数据文件中读取每个查询条件相应的存储位置,获取每个查询条件对应的数据信息。
此处需要说明的是,当仅使用分组信息和分区信息进行查询,无法得到查询条件的数据信息,需要在查询的时候结合类型信息。
通过本申请上述实施例,在查询时,可以根据元数据里存储的各profile对应的profilegroup的信息进行相应的分区条件添加,即动态添加profilegroup的条件,应用分区隔离的特性,加快单个profile的查询速度,同时也保持着对整站数据查询的方式。
上述任务存储装置包括处理器和存储器,上述第一获取单元,第一确定单元,第一读取单元和存储单元等均作为程序单元存储在存储器中,由处理器执行存储在存储器中的上述程序单元。上述预设的元数据、预置的外部数据文件都可以存储在存储器中。
处理器中包含内核,由内核去存储器中调取相应的程序单元。内核可以设置一个或以上,通过调整内核参数解析文本内容。
存储器可能包括计算机可读介质中的非永久性存储器,随机存取存储器(RAM)和/或非易失性内存等形式,如只读存储器(ROM)或闪存(flash RAM),存储器包括至少一个存储芯片。
本申请还提供了一种计算机程序产品的实施例,当在数据处理设备上执行时,适于执行初始化有如下方法步骤的程序代码:获取待存储的任务集合,其中,任务集合包括:多个任务数据,以及每个任务数据对应的数据量信息和分区信息;根据每个任务数据对应的数据量信息,从预设的元数据中确定每个任务数据对应的分组信息,其中,将数据量信息为第一数据量的任务数据确定为碎片数据,将数据量信息为第二数据量的任务数据确定为普通数据,普通数据和碎片数据对应的不同的分组信息,第一数据量小于第二数据量,元数据用于保存每个数据量信息和每个分组信息的对应关系;根据每个任务数据对应的分组信息和分区信息,从预先配置的外部数据文件中读取每个任务数据相应的存储位置;将任务集合中的每个任务数据分别存储到每个任务数据相应的存储位置。
上述本发明实施例序号仅仅为了描述,不代表实施例的优劣。
在本发明的上述实施例中,对各个实施例的描述都各有侧重,某个实施例中没有详述的部分,可以参见其他实施例的相关描述。
在本申请所提供的几个实施例中,应该理解到,所揭露的技术内容,可通过其它的方式实现。其中,以上所描述的装置实施例仅仅是示意性的,例如所述单元的划分,可以为一种逻辑功能划分,实际实现时可以有另外的划分方式,例如多个单元或组件可以结合或者可以集成到另一个系统,或一些特征可以忽略,或不执行。另一点,所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口,单元或模块的间接耦合或通信连接,可以是电性或其它的形式。
所述作为分离部件说明的单元可以是或者也可以不是物理上分开的,作为单元显示的部件可以是或者也可以不是物理单元,即可以位于一个地方,或者也可以分布到多个单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
另外,在本发明各个实施例中的各功能单元可以集成在一个处理单元中,也可以是各个单元单独物理存在,也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现,也可以采用软件功能单元的形式实现。
所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时,可以存储在一个计算机可读取存储介质中。基于这样的理解,本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来,该计算机软件产品存储在一个存储介质中,包括若干指令用以使得一台计算机设备(可为个人计算机、服务器或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括:U盘、只读存储器(ROM,Read-Only Memory)、随机存取存储器(RAM,Random Access Memory)、移动硬盘、磁碟或者光盘等各种可以存储程序代码的介质。
以上所述仅是本发明的优选实施方式,应当指出,对于本技术领域的普通技术人员来说,在不脱离本发明原理的前提下,还可以做出若干改进和润饰,这些改进和润饰也应视为本发明的保护范围。

Claims (10)

1.一种任务存储方法,其特征在于,包括:
获取待存储的任务集合,其中,所述任务集合包括:多个任务数据,以及每个任务数据对应的数据量信息和分区信息;
根据所述每个任务数据对应的数据量信息,从预设的元数据中确定所述每个任务数据对应的分组信息,其中,将所述数据量信息为第一数据量的任务数据确定为碎片数据,将所述数据量信息为第二数据量的任务数据确定为普通数据,所述普通数据和所述碎片数据对应的不同的分组信息,所述第一数据量小于所述第二数据量,所述元数据用于保存每个数据量信息和每个分组信息的对应关系;
根据所述每个任务数据对应的分组信息和分区信息,从预先配置的外部数据文件中读取所述每个任务数据相应的存储位置;
将所述任务集合中的每个任务数据分别存储到所述每个任务数据相应的存储位置。
2.根据权利要求1所述的方法,其特征在于,在根据所述每个任务数据对应的数据量信息,从预设的元数据中确定所述每个任务数据对应的分组信息之前,所述方法还包括:
获取所有任务数据的数据量信息;
从所有的数据量信息中获取所述数据量信息为所述第一数据量的至少一个数据量信息,将所述至少一个数据量信息对应第一分组信息;
从所有的数据量信息中获取所述数据量信息为所述第二数据量的任意一个数据量信息,将所述任意一个数据量信息对应第二分组信息。
3.根据权利要求1所述的方法,其特征在于,在根据所述每个任务数据对应的分组信息和分区信息,从预先配置的外部数据文件中读取所述每个任务数据相应的存储位置之前,所述方法还包括:
构建用于存储所述待存储的任务集合的数据库,其中,所述数据库包含多张数据表;
根据预设分区条件,将所述数据库中的多张数据表进行划分,得到多个存储位置,其中,所述预设分区条件包括:分组条件和分区条件;
将所述预设分区条件和所述多个存储位置的对应关系保存在所述预先配置的外部数据文件中。
4.根据权利要求3所述的方法,其特征在于,根据预设分区条件,将所述数据库中的多张数据表进行划分,得到多个存储位置包括:
将所述数据库中包含的多张数据表按照所述分组条件划分为多个存储分区;
将所述多个存储分区中每个存储分区按照所述分区条件划分为所述多个存储位置。
5.根据权利要求1所述的方法,其特征在于,在将所述任务集合中的每个任务数据分别存储到所述每个任务数据相应的存储位置之后,所述方法还包括:
在进行数据查询的过程中,获取输入的查询条件集合,其中,所述查询条件集合包括:多个查询条件,以及每个查询条件包含的查询数据量信息和查询分区信息;
根据所述每个查询条件包含的查询数据量信息,从预设的元数据中确定所述查询条件对应的分组信息;
根据所述每个查询条件对应的分组信息和所述每个查询条件包含的查询分区信息,从所述预先配置的外部数据文件中读取所述每个查询条件相应的存储位置;
从所述每个查询条件相应的存储位置中读取所述多个查询条件的数据信息。
6.根据权利要求1所述的方法,其特征在于,在将所述任务集合中的每个任务数据分别存储到所述每个任务数据相应的存储位置之后,所述方法还包括:
在进行数据查询的过程中,获取输入的查询条件集合,其中,所述查询条件集合包括:多个查询条件,以及每个查询条件包含的查询数据量信息,查询类型信息和查询分区信息;
根据所述每个查询条件包含的查询数据量信息,从预设的元数据中确定所述每个查询条件对应的分组信息;
根据所述每个查询条件包含的所述查询类型信息,所述查询分区信息和所述每个查询条件对应的分组信息,从所述预先配置的外部数据文件中读取所述每个查询条件相应的存储位置;
从所述每个查询条件相应的存储位置中读取所述多个查询条件的数据信息。
7.一种任务存储装置,其特征在于,包括:
第一获取单元,用于获取待存储的任务集合,其中,所述任务集合包括:多个任务数据,以及每个任务数据对应的数据量信息和分区信息;
第一确定单元,用于根据所述每个任务数据对应的数据量信息,从预设的元数据中确定所述每个任务数据对应的分组信息,其中,将所述数据量信息为第一数据量的任务数据确定为碎片数据,将所述数据量信息为第二数据量的任务数据确定为普通数据,所述普通数据和所述碎片数据对应的不同的分组信息,所述第一数据量小于所述第二数据量,所述元数据用于保存每个数据量信息和每个分组信息的对应关系;
第一读取单元,用于根据所述每个任务数据对应的分组信息和分区信息,从预先配置的外部数据文件中读取所述每个任务数据相应的存储位置;
存储单元,用于将所述任务集合中的每个任务数据分别存储到所述每个任务数据相应的存储位置。
8.根据权利要求7所述的装置,其特征在于,所述装置还包括:
第二获取单元,用于获取所有任务数据的数据量信息;
第一处理单元,用于从所有的数据量信息中获取所述数据量信息为所述第一数据量的至少一个数据量信息,将所述至少一个数据量信息对应第一分组信息;
第二处理单元,用于从所有的数据量信息中获取所述数据量信息为所述第二数据量的任意一个数据量信息,将所述任意一个数据量信息对应第二分组信息。
9.根据权利要求7所述的装置,其特征在于,所述装置还包括:
构建单元,用于构建用于存储所述待存储的任务集合的数据库,其中,所述数据库包含多张数据表;
第三处理单元,用于根据预设分区条件,将所述数据库中的多张数据表进行划分,得到多个存储位置,其中,所述预设分区条件包括:分组条件和分区条件;
保存单元,用于将所述预设分区条件和所述多个存储位置的对应关系保存在所述预先配置的外部数据文件中。
10.根据权利要求9所述的装置,其特征在于,所述第三处理单元包括:
第一处理模块,用于将所述数据库中包含的多张数据表按照所述分组条件划分为多个存储分区;
第二处理模块,用于将所述多个存储分区中每个存储分区按照所述分区条件划分为所述多个存储位置。
CN201511034188.2A 2015-12-31 2015-12-31 任务存储方法和装置 Active CN106933935B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201511034188.2A CN106933935B (zh) 2015-12-31 2015-12-31 任务存储方法和装置

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201511034188.2A CN106933935B (zh) 2015-12-31 2015-12-31 任务存储方法和装置

Publications (2)

Publication Number Publication Date
CN106933935A true CN106933935A (zh) 2017-07-07
CN106933935B CN106933935B (zh) 2019-12-10

Family

ID=59444657

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201511034188.2A Active CN106933935B (zh) 2015-12-31 2015-12-31 任务存储方法和装置

Country Status (1)

Country Link
CN (1) CN106933935B (zh)

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109284290A (zh) * 2018-09-20 2019-01-29 佛山科学技术学院 一种基于分布式储存空间的数据读取方法
CN109445724A (zh) * 2018-10-12 2019-03-08 森大(深圳)技术有限公司 打印内存管理方法、装置及设备
CN110569129A (zh) * 2019-09-12 2019-12-13 北京明略软件系统有限公司 资源分配方法及装置、存储介质、电子装置
CN110874383A (zh) * 2018-08-30 2020-03-10 阿里巴巴集团控股有限公司 数据处理方法、装置及电子设备
CN111782632A (zh) * 2020-06-28 2020-10-16 百度在线网络技术(北京)有限公司 数据处理方法、装置、设备和存储介质
CN112233727A (zh) * 2020-10-29 2021-01-15 北京诺禾致源科技股份有限公司 数据分区存储方法及装置
CN113515520A (zh) * 2021-03-26 2021-10-19 北京达佳互联信息技术有限公司 数据管理方法、装置、服务器及存储介质

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101080710A (zh) * 2004-08-24 2007-11-28 塞门铁克操作公司 映象数据存储装置写时间映射
US20100088389A1 (en) * 2008-10-02 2010-04-08 International Business Machines Corporation Periodic shuffling of data fragments in a peer-to-peer data backup and archival network
CN102541858A (zh) * 2010-12-07 2012-07-04 腾讯科技(深圳)有限公司 基于映射和规约的数据均衡性处理方法、装置及系统
CN102682015A (zh) * 2011-03-15 2012-09-19 中国科学院声学研究所 一种面向高清媒体的嵌入式文件存储结构及存储方法
US20130262520A1 (en) * 2012-03-29 2013-10-03 Oracle International Corporation Overloading r language constructs with database engine constructs

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101080710A (zh) * 2004-08-24 2007-11-28 塞门铁克操作公司 映象数据存储装置写时间映射
US20100088389A1 (en) * 2008-10-02 2010-04-08 International Business Machines Corporation Periodic shuffling of data fragments in a peer-to-peer data backup and archival network
CN102541858A (zh) * 2010-12-07 2012-07-04 腾讯科技(深圳)有限公司 基于映射和规约的数据均衡性处理方法、装置及系统
CN102682015A (zh) * 2011-03-15 2012-09-19 中国科学院声学研究所 一种面向高清媒体的嵌入式文件存储结构及存储方法
US20130262520A1 (en) * 2012-03-29 2013-10-03 Oracle International Corporation Overloading r language constructs with database engine constructs

Cited By (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110874383A (zh) * 2018-08-30 2020-03-10 阿里巴巴集团控股有限公司 数据处理方法、装置及电子设备
CN110874383B (zh) * 2018-08-30 2023-05-05 阿里云计算有限公司 数据处理方法、装置及电子设备
CN109284290B (zh) * 2018-09-20 2022-04-26 佛山科学技术学院 一种基于分布式储存空间的数据读取方法
CN109284290A (zh) * 2018-09-20 2019-01-29 佛山科学技术学院 一种基于分布式储存空间的数据读取方法
CN109445724B (zh) * 2018-10-12 2022-03-01 森大(深圳)技术有限公司 打印内存管理方法、装置及设备
CN109445724A (zh) * 2018-10-12 2019-03-08 森大(深圳)技术有限公司 打印内存管理方法、装置及设备
CN110569129A (zh) * 2019-09-12 2019-12-13 北京明略软件系统有限公司 资源分配方法及装置、存储介质、电子装置
CN111782632A (zh) * 2020-06-28 2020-10-16 百度在线网络技术(北京)有限公司 数据处理方法、装置、设备和存储介质
WO2022000851A1 (zh) * 2020-06-28 2022-01-06 百度在线网络技术(北京)有限公司 数据处理方法、装置、设备和存储介质
US11847161B2 (en) 2020-06-28 2023-12-19 Baidu Online Network Technology (Beijing) Co., Ltd. Data processing method and apparatus, device, and storage medium
CN112233727A (zh) * 2020-10-29 2021-01-15 北京诺禾致源科技股份有限公司 数据分区存储方法及装置
CN112233727B (zh) * 2020-10-29 2024-01-26 北京诺禾致源科技股份有限公司 数据分区存储方法及装置
CN113515520A (zh) * 2021-03-26 2021-10-19 北京达佳互联信息技术有限公司 数据管理方法、装置、服务器及存储介质

Also Published As

Publication number Publication date
CN106933935B (zh) 2019-12-10

Similar Documents

Publication Publication Date Title
CN106933935A (zh) 任务存储方法和装置
CN105094707B (zh) 一种数据存储、读取方法及装置
US9256665B2 (en) Creation of inverted index system, and data processing method and apparatus
CN106708841B (zh) 网站访问路径的聚合方法和装置
CN106844132A (zh) 集群服务器的故障修复方法和装置
CN106933897A (zh) 数据查询方法和装置
CN106649368A (zh) 数据存储方法、装置和数据查询方法、装置
CN107391506A (zh) 用于查询数据的方法和装置
CN110175730A (zh) 一种基于大数据的政府政策智能与企业匹配的系统及方法
CN106294886A (zh) 一种从HBase中全量抽取数据的方法及系统
CN103116641B (zh) 获取排序的统计数据的方法及排序装置
CN104915388B (zh) 一种基于谱聚类和众包技术的图书标签推荐方法
CN106776891A (zh) 一种文件存储的方法和装置
CN106933644A (zh) 数据处理方法和装置
CN106933927A (zh) 数据表的连接方法和装置
CN107729330B (zh) 获取数据集的方法和装置
CN106933919A (zh) 数据表的连接方法及装置
CN106649385B (zh) 基于HBase数据库的数据排序方法和装置
EP1510935A1 (en) Mapping a data from a data warehouse to a data mart
CN106933918A (zh) 数据表的查询方法和装置
CN110119396A (zh) 数据管理方法及相关产品
CN105989124B (zh) Sqlite文件恢复自增主键值的方法及其系统
CN106933934A (zh) 数据表的连接方法和装置
CN106933920A (zh) 会话的筛选方法和装置
CN106933904A (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
CB02 Change of applicant information
CB02 Change of applicant information

Address after: 100083 No. 401, 4th Floor, Haitai Building, 229 North Fourth Ring Road, Haidian District, Beijing

Applicant after: Beijing Guoshuang Technology Co.,Ltd.

Address before: 100086 Cuigong Hotel, 76 Zhichun Road, Shuangyushu District, Haidian District, Beijing

Applicant before: Beijing Guoshuang Technology Co.,Ltd.

GR01 Patent grant
GR01 Patent grant