CN107092627A - 记录的列状存储表示 - Google Patents
记录的列状存储表示 Download PDFInfo
- Publication number
- CN107092627A CN107092627A CN201710015074.6A CN201710015074A CN107092627A CN 107092627 A CN107092627 A CN 107092627A CN 201710015074 A CN201710015074 A CN 201710015074A CN 107092627 A CN107092627 A CN 107092627A
- Authority
- CN
- China
- Prior art keywords
- data
- record
- column
- value
- shaped band
- 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
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/22—Indexing; Data structures therefor; Storage structures
- G06F16/221—Column-oriented storage; Management thereof
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/24—Querying
- G06F16/242—Query formulation
- G06F16/243—Natural language query formulation
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/24—Querying
- G06F16/245—Query processing
- G06F16/2458—Special types of queries, e.g. statistical queries, fuzzy queries or distributed queries
- G06F16/2465—Query processing support for facilitating data mining operations in structured databases
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/30—Information retrieval; Database structures therefor; File system structures therefor of unstructured textual data
- G06F16/36—Creation of semantic tools, e.g. ontology or thesauri
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F17/00—Digital computing or data processing equipment or methods, specially adapted for specific functions
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F40/00—Handling natural language data
- G06F40/20—Natural language analysis
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F40/00—Handling natural language data
- G06F40/30—Semantic analysis
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F40/00—Handling natural language data
- G06F40/40—Processing or translation of natural language
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- Databases & Information Systems (AREA)
- Data Mining & Analysis (AREA)
- Computational Linguistics (AREA)
- Artificial Intelligence (AREA)
- Software Systems (AREA)
- Mathematical Physics (AREA)
- General Health & Medical Sciences (AREA)
- Audiology, Speech & Language Pathology (AREA)
- Health & Medical Sciences (AREA)
- Fuzzy Systems (AREA)
- Probability & Statistics with Applications (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
计算机系统访问数据记录的集合。该集合中的每个记录包括多个数据值以及从该多个数据值标识出相对应数据值的语义的多个数据元素。一个或多个数据记录中的每个包括相同数据元素的多个实例,并且包括对应于该相同数据元素的多个实例的数据值。该计算机系统生成列状条带的集合。该列状条带集合包括来自数据记录集合中的每个数据记录的数据值。该列状条带集合中的每个列状条带包括对应于来自记录集合中的每个记录的具体数据元素的所有数据值。
Description
本申请是国际申请号为PCT/US2011/031123、国际申请日为2011年04月04日、进入中国国家阶段日期为2012年10月29日、国家申请号为201180021717.9、发明名称为“记录的列状存储表示”的发明专利申请的分案申请。
相关申请的交叉引用
本申请要求于2010年4月5日提交的第61/321106号美国临时申请和于2010年4月7日提交的第61/321688号美国临时申请的权益。
技术领域
本文档总体上描述了用于生成并处理记录的列状存储表示的技术、方法、系统和机制。
背景技术
本公开总体上涉及大规模分析数据处理。这样的数据处理在网络公司中且跨产业已经变得非常普遍,尤其是由于使得能够采集大量商业关键数据的低成本存储。将该数据放在分析师和引擎的指尖已经显得越来越重要;交互响应时间经常在数据探测、监视、在线消费者支持、快速成形、数据管线调试和其它任务中形成质量差异。按规模执行交互式数据分析要求高度并行、例如,使用当今的商品磁盘在一秒钟内读取一兆兆字节的压缩数据将需要数万个磁盘。类似地,CPU密集查询可能需要在数千个核上运行以在数秒之内完成。
发明内容
这里公开了一种用于数据分析的可扩展、交互式ad-hoc查询系统。通过将多级执行树与列状逐句布局相结合,所描述的系统和方法能够运行诸如整合查询之类的快速且高效的查询。描述了用于嵌套记录的列状存储表示,所述嵌套记录是可以在许多网络规模和科学数据集中使用的流行数据模型。依据一个实施例,记录被分解为列条带,每个列被编码为块的集合,每个块包含字段值以及重复和定义级别信息。级别信息使用字段写入器(writer)的树生成,其结构与记录模式中的字段层级相匹配。可以有效地使用有限状态机从列状数据组成记录,该有限状态机读取字段数据以及每个字段的级别信息并且将值顺序附加至输出记录。如果仅字段的子集需要被获取,则能够构造其执行更为廉价更为简单的有限状态机。此外通过利用列状存储表示存储诸如约束信息之类的附加元数据,能够支持附加类型的查询。
多级服务树被用来执行查询。在一个实施例中,根服务器接收传入的查询,从表读取元数据,并且将该查询路由至服务树中的下一级别。叶服务器与存储层进行通信并且访问本地存储上的数据,其中所存储的数据能够被复制,并且读取列状表示中嵌套数据的条带。每个服务器可以具有对应于物理查询执行计划的内部执行树,其包括对输入列进行扫描并且发出利用级别信息进行注释的聚集和标量函数的结果的迭代器集合。在另一个实施例中,提供查询分派器,其基于查询的属性对它们进行调度并且平衡负载。查询分派器在一个服务器变得明显比其它服务器更慢或者当副本(replica)变为无法访问时提供容错。查询分派器能够计算叶服务器上的执行线程的处理时间的直方图并且当处理时间占用不成比例的时间量时重新调度至另一个服务器。
可以就地对列状数据进行查询。将列状数据在普通存储层上维护并且提供机制以对来自列状数据的记录进行整合支持对记录结构的数据进行分析的数据管理工具的可操作性。该系统可以为数个处理器的规模并且能够快速读取大量数据。在某些实例中,特定实施例能够被实施为实现以下的一种或多种优势。嵌套数据可以在原地进行操作,以使得数据可以被访问而并不利用数据库管理系统加载该数据。可以以比其它分析程序所需的时间有所减少的执行时间来执行嵌套数据的查询。在普通存储层上实现的列状存储数据结构使得多个不同分析程序能够访问该列状存储数据结构。
作为所附权利要求以及以上描述中所描述实施例的备选,本发明也可以通过以下实施例之一进行描述:
实施例1针对一种计算机实施的方法。该方法包括由计算系统访问存储在计算机存储器中的数据记录的集合,该数据记录集合中的每个记录包括多个数据值以及标识出来自该多个数据值的对应数据值的语义的多个数据元素,该数据记录集合中的一个或多个数据记录中的每个包括相同数据元素的多个实例,并且包括对应于该相同数据元素的多个实例的数据值。该方法进一步包括由计算机系统生成列状条带的集合,该列状条带集合包括来自数据记录集合中的每个数据记录的数据值,该列状条带集合中的每个列状条带包括对应于来自记录集合中的每个记录的具体数据元素的所有数据值。
实施例2针对实施例1的方法。该方法进一步包括由计算系统且对于列状条带集合中的每个列状条带中的每个数据值生成识别来自该数据记录集合的相应数据记录中的相应数据值的位置的数据。
实施例3针对实施例2的方法,其中该数据由重复值和定义值所构成。
实施例4针对实施例2至3中任一项的方法。该方法进一步包括从(i)列状条带集合中的列状条带,和(ii)数据来重构仅包含来自该数据记录集合中的记录的数据元素子集的记录集合。
实施例5针对实施例1至4中任一项的方法,进一步包括生成该列状条带集合中的每个特定数据值的重复值,以与该列状条带集合中的数据值一起存储,其中每个特定数据元素的路径包括对该特定数据元素的任意一个或多个父数据元素;其中每个特定数据值的重复值标识出对应于特定数据值的特定数据元素的路径中最近重复的数据元素;其中特定数据元素的路径中的该最近重复过的数据元素是在包括该特定数据值的特定数据记录的分析期间在特定数据元素的路径中第二次遇到的数据元素,该分析从特定数据值在特定数据记录中的位置向上朝着特定数据记录的开始进行。
实施例6针对实施例1至5中任一项的方法,其中该数据元素集合中所包括的数据元素中的每个特定数据元素与包括对该特定数据元素的任意一个或多个父数据元素的相应路径相关联。该方法进一步包括生成该数据记录集合中的每个特定路径或特定路径部分的定义值,以与该列状条带中的数据值一起存储。特定路径或特定路径的部分的定义级别标识出该特定路径或路径的部分中所包括的数据元素的数量。
实施例7针对实施例1至6中任一项的方法。该方法进一步包括由计算系统从数据源集合接收信息,每个数据源包括未根据模式而结构化的信息。该方法进一步包括由计算系统通过根据该模式对每个数据源中的信息进行结构化而生成该数据记录集合中的每个数据记录。
实施例8针对实施例1至7中任一项的方法。该方法进一步包括由计算系统执行对该列状条带集合的查询。该方法进一步包括由计算系统且响应于查询的执行而输出新的列状条带,该新的列状条带包括来自由该查询所标识出的列状条带集合的列状条带的值的子集。
实施例9针对实施例8的方法。其中执行该列状条带集合的查询而并不将该列状条带集合中所包括的数据值加载到数据库中。
实施例10针对实施例1至9中任一项的方法,其中该列状条带集合的至少第一列状条带包括多个数据块,该多个数据块中的至少一些数据块中的每个包括定义了在每个块的值中所找到的值类型的声明值,从而使得在执行第一列状条带的查询时,该计算系统避免不包括由该查询所指定的数据值的一个或多个数据块。
实施例11针对实施例1至10中任一项的方法,其中该列状条带集合的第一列状条带包括来自该数据记录集合中的对应于该数据记录集合中的第一数据元素的实例的数据记录中的所有数据值,作为第一数据值。该第一列状条带在存储器中连续存储多个第一数据值,其中多个第一数据值在多个第一数据值存储在该数据记录集合中的数据记录中时,并不在存储器中连续存储。
实施例12针对实施例1至11中任一项的方法,其中该数据记录集合中的至少一个数据记录包括根据嵌套数据模型所存储的数据元素和对应的数据值。
实施例13针对实施例1至12中任一项的方法,其中第一数据记录包括第一数据元素和第二数据元素,第一数据元素是第二数据元素的父数据元素,并且第二数据元素是第一数据元素的子数据元素。第一列状条带包括对应于第一数据记录中的第一数据元素的数据值以及对应于该数据记录集合中的第一数据元素的实例的所有其它数据值。第二列状条带包括对应于第一数据记录中的第二数据元素的数据值以及对应于该数据记录集合中的第二数据元素的实例的所有其它数据值。
其它实施例包括存储指令的相对应计算机可读存储设备,当上述指令被一个或多个处理设备(例如,可编程计算机处理器)所执行时,执行根据以上所描述的实施例1至13中任一项的操作。其它实施例包括系统和装置,其包括所描述的存储指令的计算机可读存储设备,当被一个或多个处理设备所执行时,上述指令执行根据以上所描述的实施例1至13中任一项的操作。
附图和以下的描述中给出了一个或多个实施例的细节。本发明的其它特征、目标和优势将由于描述和附图以及权利要求而明显。
附图说明
图1图示了嵌套数据按照记录的(record-wise)对比列状表示。
图2图示了两个样本嵌套记录及其模式。
图3图示了样本嵌套记录的列状条带表示。
图4是用于将记录划分为列的算法。
图5图示了用于执行完整的记录聚集的自动机。
图6图示了用于从两个字段聚合记录的自动机,以及该自动机所产生的记录。
图7用于构建记录聚合自动机的算法。
图8是用于从列状数据整合记录的算法。
图9描绘了执行投影、选择和记录内聚合的样本查询。
图10图示了服务器节点内的系统架构和执行。
图11是图示实验研究中所使用的数据集的表。
图12是图示可在从本地磁盘进行读取时可能发生的性能崩溃的图。
图13是图示MapReduce和所描述系统在面向列状对比面向记录的存储上的执行的图。
图14是图示作为两个聚合查询的服务树级别的函数的执行时间的图。
图15是图示处理时间的直方图的图。
图16是图示当系统规模使用前k个查询从1000缩放为4000个节点时的执行时间的图。
图17是图示作为每个板块(tablet)的处理时间的函数的所处理表的百分比的图。
图18是图示每月工作负载中的查询响应时间分布的图。
图19是用于生成并处理嵌套记录的列状存储表示的系统的框图。
图20是用于生成列状数据的示例过程的流程图。
图21是作为客户端或者作为一个或多个服务器的可以用来实现本文中所描述的系统和方法的计算设备的框图。
各图中同样的附图标记指代同样的要素。
具体实施方式
本文档描述了用于生成并处理记录的列状存储表示的技术、方法、系统和机制。作为说明,组织可以在嵌套信息的记录中存储来自网页的数据。该嵌套信息可以以列状数据存储格式进行编译,其使得能够使用多级执行树进行有效的数据查询。列状数据可以被重新整合为记录以便输入到对面向记录的数据进行操作的分析程序。
更具体地,每个记录可以是定义记录的格式的模式的实例化,其中记录依据模式而创建。例如,模式可以标识出用于存储关于网页的信息的各个字段以及用于以记录及其相对应值对字段进行组织的结构。当生成用于描述网页特征的记录时,针对每个字段,记录可以包括数据元素和相对应的值。数据元素可以依据模式中的定义来定义值的语义。术语数据元素和字段在本文档中可以互换使用。字段还指数据元素和相对应值的组合。
特定记录可以无需包括模式所定义的所有字段。因此,模式可以充当可以从中为特定记录选择字段的“模板”。例如,模式可以包括用于关于网页中的视频内容的信息的字段。如果网页并不包括视频内容,则对应于该网页的记录可以不包括来自模式的定义与网页上的视频相关的信息的字段。因此,一些字段可以是“可选的”。
然而,记录中的一些字段可能是“要求的”。例如,模式中的“要求”字段可以是提供网页的文档的资源位置的统一资源定位符(URL)。由于可以从资源位置获取每个网页文档(即,存在可用于每个文档的URL)并且由于字段可能被要求对网页上的信息进行进一步处理(例如,确定内容是否已经改变),所以字段可能是要求的。
字段还可能是“可重复的”。处于模式中并且被定义为可重复的字段可以在模式的实例化中(即,在记录中)反复在该模式所定义的位置进行重复。例如,模式可以包括用于定义链接至网页的文档的字段。该模式可以仅指定该字段单次,但是可以指示该字段是可重复的(例如,由于若干文档可以链接至特定网页)。因此,网页的记录可以包括标识出链接网页的值的多个字段。重复字段可以位于相同级别并且嵌套在记录中的父字段之下(如以下更为详细讨论的)。
模式的字段(以及因此是记录中的字段)可以是嵌套的。换句话说,在一些字段可以是被称之为父字段、祖父母字段等的其它字段的孩子。在一些示例中,子节点是模式中在紧随父节点之后的一对开放或闭合花括号之内所找到的节点。然而,可以对嵌套利用其它实施方式(例如,使用字段的开始标签和字段的结束标签)。因此,除了处于最高级别的字段(例如,并非任何其它字段的孩子的字段)之外,每个字段都可以具有父字段。
嵌套对于将信息组织为概念上相关的信息块是有帮助的。返回之前的示例,模式可以包括“Video”字段。“Video”字段可以包括可以标识出视频特征(例如,视频有多长,视频的格式以及视频的分辨率)的若干子节点。因此,当记录被构建时,如果它们的父节点没有出现,则子节点可以不被置于记录之中。换句话说,并不包括视频的网页的记录可以不包括“视频长度”字段,因为记录并不包括“Video”字段(即“VideoLength”的父亲)。使得能够观看并编辑记录的应用程序可以在视觉上嵌套来自于父节点的从属孩子(即,将孩子缩排(indent)在父字段的右侧)。
对数百万的记录进行分析可能是耗时的。在一些示例中,用户对来自单个字段的数据感兴趣,但是每个记录都必须以其整体进行访问。例如,用户可以请求分析程序对数百万记录中的每一个进行检查以识别与包括不长于十分钟并且具有“高”分辨率的视频的网页相关联的记录。由于每个记录可以被存储为单独的数据结构,所以每个完整记录可能需要被加载到数据库管理系统中以便查询该记录以确定记录是否包括视频长度和分辨率的特定组合。
这样加载每个单独记录在执行任务所需的服务器数量以及完成查询所必需的时间量方面都可能是过于昂贵的。通过将跨数百万记录所选择的特定记录的所有值一起存储在存储器的连续部分中能够明显节约时间。来自若干记录但是针对特定字段的值的这种存储被称作列状存储(columnar storage)。与之相比,特定记录的信息被连续存储在存储器中的示例被称作面向记录的存储。
然而,针对嵌套记录的列状存储显现出特别的困难。记录中的字段可以通过其路径进行标识,该路径可以包括字段和父字段的列举(例如,GrandParent.Parent.Child)。由于路径中的一个或多个字段可以重复,所以可能存在具有相同路径名称的若干字段实例。因此,当查看特定字段的列状数据的连续列举时,需要机制来标识出哪些值属于哪些记录,以及对于包括特定路径的多个值的那些记录而言值在记录中的相应位置是什么。换而言之,给定列状结构的值序列,需要机制来从值中重构记录的结构。
用于对来自列状数据的记录的结构进行重构的机制包括对于列状数据中的每个值存储“重复”级别和“定义”级别。每个“级别”可以是表示数字的比特序列。例如,“级别”3可以由两个比特(例如,“11”)来表示。在另一个示例中,“级别”5可以由三个比特(例如“101”)来表示。
针对特定值所存储的“重复”级别指示值路径中最近重复过的字段。作为说明,可以针对具有路径“Video.Resolution.Width”的字段存储一列值。重复级别“1”可以指示“Video”字段最近被重复过,而重复级别“2”可以指示“Resolution”字段最近被重复过。最近重复可以指示从记录中的值的如下位置起,路径“Video.Resolution.Width”中的哪个字段首先达到两次计数(例如,哪个字段首先被遇到两次),从该位置选择该值并且向上朝着文档的开始而工作。
例如,从“Width”值的位置向上工作,每个字段被遇到一次。找出每个字段的第二实例需要行进至下一个相邻嵌套字段的深度(以及可能行进至另外的嵌套)。因此,可能遇到并不包括任何“Resolution”孩子的“Video”字段(例如,因为“Resolution”字段是可选字段或重复字段)。因此,“Video”字段已经被遇到两次并且因此是最近重复的字段。重复级别“1”被指定给该值。
重复级别“0”可以指示该字段并不包括最近重复的值(例如,其在上下扫描期间已经在记录中被第一次遇到)。在各种示例中,路径中的“要求”字段并不具有重复级别。例如,如果“Resolution”字段对于“Video.Resolution.Width”路径而言是必需的,则分辨率级别的范围可以为“0”或“1”。由于其在“Video”字段出现时一直出现在记录中,所以“Resolution”可以不具有级别。因此,如果“Resolution”被指定为级别“2”,则其一直在“Video”之前被遇到,并且因此可以永远不被指定以级别“1”。因此,不包括所要求字段的重复级别可以使得能够减少不同分辨率级别的数量,并且可以减少表示分辨率级别的比特数量。
如果以上示例中的字段“Width”是“可选”或“重复”字段,则记录可能不会一直包括“Width”字段的值。因此,“Video.Resolution.Width”路径的值列可以使用一种机制来指定何时在记录中找到“Video”或“Video.Resolution”路径,而“Width”字段还没有在该记录中被实例化。该机制可以包括在数据的“Video.Resolution.Width”列中存储记录中的每个“Video”或“Video.Resolution”字段的“定义”级别而无论“Width”字段是否被实例化。“定义”级别可以指示有多少在“Video.Resolution.Width”路径中可能(例如,由于字段为可选或可重复的)缺失的字段实际存在。
因此,如果字段“Video”出现在记录中但是没有实例化相对应的“Resolution”孩子,则可以在“Video.Resolution.Width”列中记录定义级别“1”。如果字段“Video.Resolution”出现在记录中,但是没有实例化相对应的“Width”孩子,则可以记录定义级别“2”。如果字段“Video.Resolution.Width”出现在记录中,则可以记录定义级别“3”。
这样,可以对记录中的每个数据元素路径或数据元素路径的一部分生成定义级别。例如,路径“Video.Resolution.Width”可以具有定义级别“3”,其标识出路径“Video.Resolution.Width”中所包括的数据元素的数量。作为另一个示例,路径“Video.Resolution”可以具有定义级别“2”,其标识出路径“Video.Resolution”中所包括的数据元素的数量,即使“Width”数据元素没有在数据记录中被实例化。
因此,无论“定义”级别(其表示可能未定义但是实际上已经定义的字段的数目)何时小于所能够定义的字段的数目,都可以标识出“Width”字段没有出现。
在各种示例中,“定义”级别是布尔值而不是整数。可以在了解哪个所包含对象未定义并不重要的情况下使用布尔值而不是整数。例如,“Video.Resolution.Width”路径的Width字段的值的定义级别可以为“空”,其中系统无需了解哪个父字段被实例化。“重复”级别和“定义”级别的组合可以使得记录的结构能够被重新构建。
特定字段(例如,“Video.Resolution.Width”字段)的数据列可以包括来自多个记录的该字段的值、相对应的重复和定义级别(承认一些“缺失”值可能具有重复和定义级别)和报头信息。在一些示例中,值被连续且相邻存储。换句话说,如果一个“Video.Resolution.Width”字段的值为“700”并且下一个“Video.Resolution.Width”字段的值为800,则如存储器中所存储的该列的一部分可以读出“700800”。在该示例中,列中的报头可以标识出每个值具有固定宽度(例如,用来保存数字700和800的固定二进制表示)。
在一些示例中,所存储值可以由串进行表示。例如,“Width”字段的实例可以包括值“Small”和“Medium”。在一些示例中,各种串的值可以为固定长度(例如,可以将空值添加至“Small”值的开头或结尾以使得串与“Medium”值的长度相同)。然而,在一些示例中,每个所存储的串在串的开头部分可以包括标识出串的长度的标识符。例如,“small”值可以包括指示该串为五个数位长度(或者相对应的二进制比特数目)的标识符。
由于值可以在列状条带中连续存储,所以“重复”和“定义”级别可以被存储在列状条带的开头。在一些示例中,“重复”和“定义”级别针对特定值(无论是被实例化还是缺失)而成对存储。作为说明,可以在字节的前四个比特中存储重复级别3,并且可以在字节的后四个比特中存储定义级别1。报头中的下一个字节可以包括记录中的下一个字段实例(或者后续记录中的第一个实例)的重复级别和定义级别。
用来表示重复和定义级别的比特的数量可以基于最大级别的值。例如,如果最大重复级别为3,则重复级别可以利用两个比特来表示。如果最大重复级别为4,则重复级别可以利用三个比特来表示。报头可以包括标识出重复和定义级别的长度的信息。
在各种示例中,重复级别可以在存储器中连续存储,并且定义级别可以在存储器中连续存储(例如,并不成对)。在各种示例中,重复和定义级别可以与其相对应的值(如果值被实例化)一起存储在组中。换句话说,列状条带中的信息序列可以读出为Value1:RepetitionLevel1:DefinitionLevel1:
Value2:RepetitionLevel2:DefinitionLevel2,等等。
列状条带可以被压缩为信息块。例如,每个列状条带可以被划分为一组块,其中每个块包括其自己各自的报头。第一块可以包括来自160万个值的条带中的前800000个值而第二块可以包括后800000个值。块的报头可以包括重复和定义级别以及可以用来帮助对该块所表示的列状条带部分进行分析并重构该列状条带的附加信息。
在一些示例中,块报头包括“Assertion”值,其定义在块的值中所找到的数据的类型。例如,“Video.Resolution.Width”字段的块可以不包括任何列出“Large”宽度分辨率的值。因此,“Assertion”值可以指示该值仅包括“Small”和“Medium”值。如果对包括“High”宽度分辨率视频的记录执行查询,则所描述的块可以被查询系统所避免。
本文档中所描述的系统可以对列状条带执行查询而并不将列状条带中的信息重构为记录,并且并不将来自列状条带的信息加载到数据库中(例如,并不使用“插入”子句)。因此,可以就地访问数据,这可以以量级次序提供计算分析时间的节约。
查询系统可以采用被用于对关系数据库进行查询的许多子句。然而,可以采用特定于非关系数据的另外的子句。例如,WITHIN子句可以允许对单个记录或者记录的一部分之内的字段的多个实例执行运算。然而,关系数据库可能无法在一行中存储多于一个的单个字段实例(例如,记录的表示)。因此,对于关系数据库的查询基本上无法执行记录“内”的查询。
作为WITHIN子句的示例,特定字段的值可以相乘。假设查询指令请求针对特定记录将“MutualFund.InterestRate”的所有值相乘在一起(其中每个记录可以针对特定的账户持有者)。查询系统可以找到单个记录内的所有“MutualFund.InterestRate”值并且将它们一起相乘。
可以特定于非关系嵌套数据的另一个子句示例是OMIT IF子句。该子句可以使得在满足特定条件的情况下对记录进行过滤以去除字段实例(例如,可以创建去除了指定字段的新的列状条带或记录)。作为说明,可以对列出雇员薪水的值条带进行查询,并且可以使用OMIT IF子句生成去除了薪水高于$90000的雇员的新条带。
1.介绍
可以使用商品及其的共享集群来执行大规模的并行计算。参见L.A.Barroso和U.Holzle.The Datacenter as a Computer:An Introduction to the Design ofWarehouse-Scale Machines.Morgan&Claypool Publishers,2009。集群可以托管共享资源的大量分布式应用,具有大幅变化的工作负载,并且在具有不同硬件参数的机器上运行。分布式应用中的个体计算机器可能花费远比其它机器更长的多的时间来执行给定任务,或者可能由于故障或者集群管理系统所进行的抢占而永远不会完成。因此,对掉队者(例如,具有明显延迟的计算任务)和故障进行处理可能实现快速执行和故障容错。参见G.Cazjkowshi.Sorting 1PB with MapReduce.Official Google Blog,Nov.2008.位于http://googleblog.blogspot.com/2008/11/sorting-1pb-with-mapreduce.ht ml。
网络和科学计算中所使用的数据经常是非关联的。因此,灵活的数据模型在这些领域中可能是有益的。编程语言、分布式系统所交换的消息、网络业务日志等中所使用的数据结果可能使得其自身呈现嵌套表示。例如,数据的嵌套表示可以包括均包括若干子字段级别的多个字段。一些子字段可以包括相对应的数据。对这样的处于网络规模的数据进行归一化和重新组合在计算上会是昂贵的。嵌套数据模型在主要网络公司成为了一些结构化数据处理的基础。
本文档描述了一种在商业机器的共享集群上支持对非常大的数据集进行交互式分析的系统。不同于传统的数据库,其能够就地对嵌套数据进行操作。就地是指“原地”访问数据的能力,例如在如Google File System的分布式文件系统中(参见S.Ghemawat,H.Gobioff和S.-T.Leung.The Google File System.In SOSP,2003),或者如Bigtable的另一存储层面(参见F.Chang,J.Dean,S.Ghemawat,W.C.Hsieh,D.A.Wallach,M.Burrows,T.Chandra.A.Fikes和R.Gruber.Bigtable:A Distributed Storage System forStructured Data.In OSDI,2006)。
该系统能够对这样的数据执行许多查询,其可以常规地要求MapReduce工作的顺序,但是仅用部分执行时间。参见J.Dean和S.Ghemawat.MapReduce:Simplified DataProcessing on Large Clusters.In OSDI,2004。所描述的系统可以结合MapReduce使用以对MapReduce管线的输出进行分析或者快速建立较大计算的原型。使用该系统的示例包括:
·网络日志和所爬取的网络文档的分析;
·在线市场所提供的应用的安装数据;
·应用产品的故障数据(crash data);
·多媒体回放统计;
·根据图书扫描的OCR结果;
·垃圾邮件分析;
·地图瓦片的调试;
·所管理Bigtable实例中的板块迁移;
·在分布式构建系统上运行的测试的结果;
·对于成百上千磁盘的磁盘I/O统计;
·跨若干数据中心的MapReduce工作的执行日志;以及
·代码库中的符号和依赖关系。
所描述的系统建立在来自网络搜索和并行数据库管理系统的思想之上。首先,其架构建立在分布式搜索引擎中所使用的服务树(serving tree)的概念之上。参见J.Dean.Challenges in Building Large-Scale Information Retrieval Systems:Invited Talk.In WSDM,2009。如同网络搜索请求那样,查询对树进行下推并且在每个步骤进行重写。通过聚合从树的较低级别所接收的回复而对查询的结果进行整合。
第二,所描述的系统提供了高级的、类似SQL的语言来表达ad hoc查询。与诸如Pig(参见C.Olston,B.Reed,U.Srivastava,R.Kumar和A.Tomkins.Pig Lain:a Not-so-Foreign Language for Data Processing.In SIGMOD,2008。)和Hive(Hive.http://wiki.apache.org/hadoop/hive,2009)之类的层相比,该查询系统执行本地查询而并不将它们转换为MapReduce工作。
最后,所描述的系统使用列状条带的表示,这使得其能够从次级存储读取较少数据并且由于较为廉价的压缩而减少CPU成本。用于分析关系数据的列存储(D.J.Abadi,P.A.Boncz和S.Harizopoulos.Column-Oriented Database Systems.VLDB,2(2),2009)并未被相信已经扩展至嵌套数据模型。所描述的列状存储格式可以被MapReduce、Sawzall(参见R.Pike,S.Dorward,R.Griesemer和S.Quinlan.Interpreting the Data:ParallelAnalysis with Sawzall.Scientific Programming,13(4),2005)和FlumeJave(参见C.Chambers,A.Raniawla,F.Perry,S.Adams,R.Henry,R.Bradshaw和N.Weizenbaum.FlumeJave:Easy,Efficient Data-Parallel Pipelines.In PLDI,2010)所支持。
在第4部分中,本文档描述了针对嵌套数据的列状存储格式。给出了用于将嵌套记录分解为列并对它们进行重新整合的算法。
在第5部分中,描述了用于对以列状存储器格式进行存储的数据进行处理的查询语言。该查询语言以及该语言的执行被设计为对列状条带化的嵌套数据进行有效操作而并不要求对嵌套记录进行重构。
在第6部分中,提供了在网络搜索服务系统中用于数据库处理的应用执行树的说明。对有效应答聚合查询的好处进行了解释。
在第7部分中,给出了在系统实例上进行的实验。
第2部分:示例情形
假设网络搜索公司的工程师Alice想到了用于从网页提取新的信号类型。她运行曲折通过(crank through)包括来自网页的内容的输入数据,并且产生包含新信号的数据集合的MapReduce工作,该数据集合以数百万记录存储在分布式文件系统中。为了对她的实验结果进行分析,她启动本文档所描述的系统并且执行若干交互式命令:
DEFINE TABLE t AS/path/to/data/*
SELECT TOP(signal1,100),COUNT(*)FROM t
Alice的命令在数秒内执行。她运行几个其它查询以使她自己相信她的算法奏效。她找出了信号1中的不规律性并且通过编写FlumeJava程序进行更深的挖掘,该程序对她的输出数据集合执行更为复杂的分析计算。一旦问题被修复,她就设置对传入的输入数据继续进行处理的管线。她规划了跨各个维度对其管线的结果进行聚合的几个预先录制的(canned)SQL查询,并且将它们添加到交互式控制台(例如,与服务相关的对服务进行解释并且对关于服务的统计进行细化的网页)。最后,她将其新的数据集合登记在目录中从而其它工程师能够快速定位并查询该数据集合。
以上情形可能要求查询处理器和其它数据管理工具之间的交互操作。这样的交互操作的第一要素是共用的存储层。Google File System是一个可以使用的这样的分布式存储层。Google File System对跨数千台机器以及数万个磁盘的非常大的复制数据集进行管理。
复制尽管在故障硬件的情况下也有助于保存数据,并且在存在落后者的情况下获得快速的响应时间。高性能的共享存储层是就地数据管理的关键性使能因素。其允许对数据进行访问而没有耗时的加载阶段,而加载阶段对于分析数据处理中的数据库使用而言是主要的阻力(其中在数据库管理系统能够加载数据并执行单次查询之前经常可能运行数十次MapReduce分析)。例如,当数据库管理系统被用来分析数据时,数据库可能需要使用“插入”命令而被加载以数据。而所描述的系统可以不需要这样的加载。作为所增加的好处,可以使用标准工具对文件系统中的数据进行方便地操纵,例如传输至另一个集群,改变访问特权,或者基于文件名标识数据子集以用于分析。
用于构建可交互操作的数据管理组件的第二要素是共享的存储格式。列状存储被用于扁平(flat)关系数据,但是将列状存储适用于嵌套数据模型进行适配的关系数据,允许该技术被应用于网络数据。图1图示了数据结构中嵌套字段的所有值被连续存储的思想。例如,在嵌套数据的面向列的表示中,数据结构内特定嵌套字段(例如,字段A.B.C)的所有值彼此相邻存储,并且在存储器中连续存储。因此,可以从存储获取字段A.B.C的值,而并不读取来自字段A.E的值以及来自字段A.B.D的值。
此外,数据结构的不同实例(例如,“记录”)中相同的特定字段的值可以连续存储。例如,记录“r1”的字段A.B.C的值与记录“r2”的相同字段的值相邻存储。与之相反,在嵌套数据的“面向记录”的表示中,特定记录内所有字段的值被连续存储。换句话说,特定字段的数据值并不被串在一起。
所描述的列状存储格式所面临的挑战在于如何保存所有结构信息并且能够从任意的字段子集来重构记录。本文档接下来讨论可以从其填写列状存储格式的字段的数据模型,并且随后转向用于对列状存储进行处理的算法以及对列状存储中的数据的查询处理。
第3部分:数据模型
该部分对所描述系统所使用的数据模型进行描述并且介绍随后使用的一些术语。所描述的协议缓冲器数据模型在分布式系统的上下文中进行组织并且可用作开源实现。参见(Protocol Buffers:Developer Guide。可在
http://code.google.com/apis/protocolbuffers/docs/overview.html获得)。该数据模型基于强类型的嵌套记录。其抽象语法由
τ=dom|<A1:τ[*|?],...,An:τ[*|?]>
所给出,其中τ是原子类型或记录类型。dom中的原子类型包括整数、浮点数、串等。记录由一个或多个字段所构成。记录中的字段i具有名称Ai以及可选的多重性标签。重复字段(*)可以在记录中多次出现。它们被解释为值列表,即字段在记录中出现的顺序是有意义的。可选字段(?)可以从记录中缺失。否则,字段是必需的(例如,必须确切地出现一次)。
作为图示,图2描绘了定义记录类型“Document”的模式,其表示网络文档。该模式定义使用协议缓冲器语法。“Document”具有必需的整数“Docld”和可选的“Links”,其包含保存其它网页的“Docld”的“Forward”和“Backward”条目的列表。“Document”可以具有多个“Name”,其可以是可以通过其引用文档的不同URL。“Name”包含“Code”和(可选的)“Country”配对的序列。图2还示出了符合该模式的两个样本记录r1和r2。记录结构使用缩进进行概括。图2中的样本记录r1和r2被用来解释本文通篇的算法。该模式中所定义的字段形成了树形层级。嵌套字段的完整路径使用带点注释形式来进行注释,例如,Name.Language.Code是图2中所描绘的“Code”字段的完整路径名称。
嵌套数据模型支持一种用于对结构化数据进行串行化的平台中立的可扩展机制。代码生成工具对诸如C++或Java的不同编程语言产生绑定。跨语言的可交互操作能力使用记录的标准二进制线上(on-the-wire)表示来获得,其中字段值在它们出现在记录中时被顺序布局。以这种方式,以Java编写的MapReduce程序能够使用来自经由C++库所展现的数据源的记录。因此,如果记录以列状表示进行存储,则将它们快速整合可以有助于与MapReduce和其它数据处理工具的交互操作。
第4部分:嵌套列状存储
如图1所示,目标是连续存储给定字段的所有值以提高检索效率。在该部分中,解决了列状格式的记录结构的无损表示(第4.1部分),快速编码(第4.2部分)以及有效记录整合(第4.3部分)的挑战。
第4.1部分:重复和定义级别值
值的连续列表并不单独传递记录的结构。给定在记录中重复的字段的两个值,系统可能无法确定该值在哪个“级别”重复(例如,两个值是来自不同记录还是来自相同记录)。同样,如果任选字段从记录中缺失,则值不能单独表达哪些封闭记录被明确定义而哪些则不是。因此引入了重复和定义级别的概念。图3包括对图1中所描绘的样本记录中的原子字段的重复和定义级别进行概括的表。
重复级别。考虑图2中的字段“Code”,其在记录“r1”中出现了三次。“en-us”和“en”在第一个“Name”字段内,而“en-gb”则处于第三个“Name”字段中。为了将这些出现在列状结构中进行区分,将重复级别附加至要以列状结构进行存储的每个值。重复级别指示值在字段路径中的哪个重复字段处重复。例如,字段路径Name.Language.Code包含两个重复的字段“Name”和“Language”。因此,Code的重复级别范围处于0和2之间。级别0表示新记录的开始,级别1表示在“Name”字段最近的重复,而级别2则表示在“Language”字段最近的重复。
作为为字段确定级别的说明,可以对记录“r1”从上至下进行扫描。值“en-us”被首先遇到并且可以执行检查以标识Name.Language.Code路径中在记录中最近重复的字段。在该示例中,还没有字段重复,并且因此重复级别为0。对于Name.Language.Code路径而言,接下来遇到值“en”,并且字段“Language”被识别为最近重复过的字段。例如,从值“en”向上扫描,Name.Language.Code路径中第一个重复的字段是“Language”。因此,重复级别为2(例如,因为“2”对应于“Language”字段,原因在于“Language”是Name.Language.Code路径中重复的第二个字段)。最后,在遇到值“en-gb”时,字段“Name”最近重复过(“Language”字段在Name之后仅出现一次),从而重复级别为1。换句话说,值的重复级别可以是表示最近重复的字段的数字。因此,记录“r1”中Code值的重复级别为0,2,1。
注意,记录“r1”中的第二个“Name”字段并不包含字段“Code”的任何值。为了确定“en-gb”作为字段“Name”的第三实例内嵌套的字段的值出现而并不处于第二实例中,当值“en”和“en-gb”以列状结构进行存储时在它们之间加入NULL值(见图3)。“Code”是“Language”字段的必需子字段,从而“Code”字段的值缺失的事实暗示了“Language”字段也没有定义。总体而言,确定嵌套记录的存在所达到的级别可以要求附加信息。
定义级别。字段中具有路径“p”的每个值,特别是每个NULL值,具有“定义级别”,其指定了有多少路径“p”中可能未定义的字段(例如,由于该字段是可选的或重复的)实际出现在在记录中。为了说明,观察记录“r1”没有针对“Links”字段的“Backward”字段。而且,字段“Links”被定义(在级别1)。为了保存该信息,具有定义级别1的NULL值被添加至“Links.Backward”列。
换句话说,为“Links.Backward”路径指定级别1指示作为可选或重复的“1”字段(即,“Links”字段)被定义在包括两个字段的路径中,这两个字段是可选或重复的(即,“Links”字段和“Backward”字段)。因此,定义“1”指示“Backward”字段没有被实例化。类似地,记录“r2”中缺失出现的“Name.Language.Country”携带定义级别1,而其在记录“r1”中缺失的出现则分别具有定义级别2(在“Name.Language”内)和1(在“Name”内)。对以上进行概括的编码过程可以无损地保存记录结构。
编码。如存储器中所存储的那样,对应于特定字段的每个列可以与报头一起存储,该报头包括重复和定义值的连续列表,随后为实质性值的连续列表。每个重复和定义值可以作为比特序列进行存储(例如,在单个字节中)。例如,一个字节的前四个比特可以被用来表示特定值的重复级别,而后四个比特可以被用来表示定义级别。在一些示例中,报头可以包括多个比特的长度的定义,从而可以不使用定界符。因此,可以仅使用必要的比特。例如,如果最大定义级别为3,则可以使用每个定义级别两个比特。
因此,单个字段(例如,“Name.Language.Code”字段)的列状数据的表示可以与字节序列一起存储在存储器中,该字节序列表示相对应值序列的重复和定义级别,随后为值序列。然而,NULL值可以不被明确存储,因为它们可以通过分析定义级别来确定。例如,小于字段路径中的重复和可选字段数量的任何定义级别都可以表示NULL。因此,系统可以能够确定应当在连续值的列表中的何处插入或推断NULL值。在一些示例中,并不针对一直被定义的值存储定义级别。类似地,重复级别可以仅在要求的情况下才存储。例如,定义级别0暗示了重复级别0,从而后者可以被省略。实际上,参考图3中所图示的结构,可以不对“Docld”字段存储级别。
列状数据在存储器中的表示可以被分解为块集合。每个块可以包括包头以及随后的字段值的列表,该报头包括重复和定义级别信息。每个报头可以包括“约束”值,其指示块中可允许的值范围。因此,所描述的系统可以标识出哪些块包括系统感兴趣的数据。约束还可以指示值的其它属性,例如,该值是否已经被存储。通常,“约束”可以被认为是关于在块中找到什么类型的值的“声明”。每个块可以被压缩。
第4.2部分:将记录划分为列
以上描述给出了以列状格式的记录结构编码。挑战是如何有效产生具有重复和定义级别的列状条带。以下提供计算重复和定义级别的基本算法。该算法递归到记录结构中并且为每个字段值计算级别。如之前所说明的,即使在字段值缺失的情况下也需要计算重复和定义级别。许多数据集合是稀疏的,并且拥有具有数千字段的模式但是仅有其中百来个在给定记录中被使用可能并非是不同寻常的。为了产生列状条带,创建字段写入器(writer)的树,其结构域模式中的字段层级相匹配。基本思想是在字段写入器具有自己的数据时更新它们,并且除非绝对必要否则并不尝试将父状态向树下传播。为此,子写入器从其父继承级别。子写入器在添加新值的任何时候与其父级别进行同步。
图4示出了一种用于将记录分解为列的示例算法。过程“DissectRecord”传递了“RecordDecoder”的一个实例,其被用来遍历二进制编码的记录。“FieldWriters”形成于输入模式同构的树形层级。根“FieldWriter”针对新记录而被送至该算法,其中“repetitionLevel”被设置为0。“DissectRecord”过程的主要工作是保持当前的“repetitionLevel”。通过当前写入器的树位置将当前的“definitionLevel”唯一确定为字段路径中的任选和重复字段的数目之和。
该算法的while循环(第5行)在给定记录中所包含的所有院子和记录赋值字段上进行迭代。集合“seenFields”对字段是否已经在记录中被看到进行追踪。子重复级别“chRepetitionLevel”被设置为最近重复字段的重复级别,否则缺省为其父级别(第9-13行)。该过程在嵌套记录上被递归调用(第18行)。
文档以上所引用的“FieldWriters”对界别进行累加并且将它们惰性地(lazily)传播至较低级别的写入器。这可以由保持(重复,定义)级别序列的每个非叶写入器所执行。每个写入器还具有与之相关联的“版本”编号。简单指出,写入器版本在级别增加的任何时候以一递增。孩子记住它们与之同步的最后父版本就足够了。如果子写入器曾得到其自己的(非空)值,则其通过取得新的级别而将其状态与父进行同步,并且仅在随后添加新的数据。
由于输入数据可以具有数千字段和数百万的记录,所以将所有级别存储在存储器中可能是不可行的。一些级别可以临时存储在磁盘上的文件中。为了对空的(子)记录进行无损编码,非原子字段(诸如图2中的Name.Language)可能需要具有其自己的列状条带,其仅包含级别但是没有非空值。
第4.3部分:记录整合
从列状数据有效整合记录(例如,记录“r1”和“r2”)对于面向记录的数据处理工具(例如,Map Reduce)是关键的。给定字段的子集,目标是对原始记录进行重构就像它们仅包含所选择字段,而所有其它字段都被剥离。关键思想是要创建有限状态机(FSM),其读取字段值以及每个字段的级别,并且将值顺序附加至输出记录。FSM状态对应于每个所选择字段的字段读取器。状态变换利用重复级别进行标记。一旦读取器取得值,则查看下一个重复级别以决定要使用什么样的下一个读取器。针对每个记录对FSM从开始到结尾状态遍历一次。
图5示出了对我们所运行的示例中使用第4.1部分中所描述的块作为输入来重构完整记录的FSM。在该示例中,节点利用字段进行标记并且边缘利用重复级别进行标记。开始状态为“Docld”。一旦“Docld”值被读取,FSM就变换至“Links.Backward”状态。在所有重复的“Backward”值都已经被用尽之后,FSM跳转至“Links.Forward”,等等。
为了概述如何构建FSM变换,令“l”为当前字段读取器针对字段“f”所返回的下一个重复级别。在模式树(例如,图2中的模式)中的“f”开始,其祖先被发现在级别“l”重复并且选择该祖先内的第一个叶字段“n”。这提供了FMS变换(‘f’;‘l’)→n。例如,令“l”=1为‘f’=‘Name.Language.Country’所读取的下一个重复级别。其具有重复级别“1”的祖先为Name,其第一个叶字段为‘n’=‘Name.Url’。
如果仅需要对字段的子集进行获取,则可以构建执行较为廉价的较简单的FSM。图6描绘了用于读取字段“Docld”和“Name.Language.Country”的FSM。该图示出了自动机所产生的输出记录“s1”和“s2”。注意,编码和整合算法保留了字段“Country”的封闭结构。这对于需要访问例如第二个Name的第一个Language中出现的Country的应用来说是重要的。在XPath中,这可以对应于对类似/Name[2]/Language[1]/Country的表达式进行评估的能力。
构造FSM的过程。图7示出了用于构造执行记录整合的有限状态机的算法。该算法取应当填充于记录中的字段作为输入,其顺序为它们在模式中出现的顺序。该算法使用两个字段的“共同重复级别”的概念,这是它们的最低共同祖先的重复级别。例如,“Links.Backward”和“Links.Forward”的共同重复级别等于1。第二个概念是“屏障”的概念,这是序列中当前字段之后的下一个字段。直观(intuition)的是在于每个字段试图被逐个处理直至达到屏障并且需要跳转至之前看到的字段。
该算法由三个步骤所构成。在步骤1(第6-10行),向后处理共同重复级别。这些被保证是非增加的。对于所遇到的每个重复级别,取出序列最左侧的字段—这是在“FieldReader”返回该重复级别时要变化至的字段。在步骤2,填充间隙(第11-14行)。该间隙是因为并非所有的重复级别都出现在第8行中所计算的共同重复级别中而出现的。在步骤3(第15-17行),针对所有级别的变换都被设置为等于或低于屏障级别以跳转至屏障字段。如果“FieldReader”产生了这样的级别,则可以继续构建嵌套记录并且可能无需跳离屏障。
整合记录过程。(图8所示的)整合记录过程取“FieldReader”以及(隐含地)具有读取器之间的状态变换的FSM的集合作为输入。换句话说,该算法在FSM和列状数据上进行操作并且输出所构建的记录。变量读取器在主例程中保持当前“FieldReader”(第4行)。变量读取器保持其值被附加至记录并且可用于图7所示的所有三个过程的最后读取器。主要的while循环处于第5行。从当前读取器取得下一个值。如果该值通过查看其定义级别而确定不为NULL,则被整合的记录在方法“MoveToLevel”中与当前读取器的记录结构同步,并且字段值被附加至该记录。否则,可以对记录结构进行调节而并不附加任何值—这可以在出现空记录时进行。在第12行,使用“完整定义级别”。回想定义级别因子来考虑所必需的字段(只算重复和可选字段)。完整定义级别将所有字段都纳入考虑。
过程“MoveToLevel”将记录从“lastReader”的状态变换为“nextReader”的状态(参见第22行)。例如,假设“lastReader”对应于图2中的“Links.Backward”而“nextReader”是“Name.Language.Code”。以该顺序,该方法终止嵌套记录Links并且开始新的记录Name和Language。过程“ReturnsToLevel”(第30行)是“MoveToLevel”的对应方,其仅终止当前记录而并不开始任何新的记录。
在其线上表示中,记录被布局为后跟字段值的字段标识符的配对。与XML相类似(实际的二进制编码可以有所不同),嵌套记录可以被认为具有“开放标签”和“闭合标签”。“开始”记录的描述是指写入开放标签,而“终止”记录则是指写入闭合标签。
第5部分:查询语言
所描述的系统可以采用基于SQL并且被设计为可在列状嵌套存储上有效实施的查询语言。这里对该查询语言的各个方面进行描述。每个类似SQL的语句(以及其所转换为的代数算子)取一个或多个嵌套表及其模式(例如,如第4.1部分中所描述的,表示表的列状数据的压缩块的集合)作为输入,并且产生嵌套表(例如,列状数据的修改实例)及其输出模式。图9描绘了执行投影、选择和记录内聚合的样本查询。该查询在来自图2的表t={r1,r2}上进行评估。字段使用路径表达式来进行引用。虽然该查询中不存在记录构建器(constructor),但是该查询产生嵌套结果。
为了解释该查询的行为,考虑选择操作(WHERE子句)。将嵌套记录认为是带标签的树,其中每个标签对应于字段名称。选择算子剪除该树中并不满足指定条件的分支。因此,仅保留了其中定义了“Name.Url”并且以“http”开始的那些嵌套记录。接下来,考虑投影。SELECT子句中的每个标量表达式以与该表达式中所使用的重复最多的输入字段相同的嵌套级别而发出(emit)值。从而,串连接表达式以输入模式中的“Name.Language.Code”的级别发出“Str”值。
COUNT表达式说明了记录内聚合。该聚合在每个“Name”子记录之内进行,并且对于每个“Name”发出作为非负64位整数(uint64)的“Name.Language.Code”出现数目。因此,WITHIN声明使得能够进行行内聚合。换句话说,相同名称的记录可以被聚合在相同记录中或者相同孩子下。与之相比,可能无法对嵌套数据进行操作的SQL就无法对行内记录进行操作。
该语言支持嵌套的子查询、记录间和记录内聚合、top-k、联合、用户定义函数等。这些特征汇总的一些在实验部分进行讨论。作为一个附加示例,所描述的查询语言包括OMIT IF声明,其能够过滤值的行内群组。例如,数千个记录中的每一个可以包括若干重复的“Cost”字段,它们均包括数字值。查询语言的用户可能想要在字段中的值之和超过数目“20”的情况下丢掉所有记录。因此,用户可以采用OMIT IF声明来生成每个记录中加总的“Cost”等于或小于二十的记录的列表。
第6部分:查询执行
树形架构。所描述的系统使用多级服务树来执行查询(见图10)。根服务器接收传入的查询,从表读取元数据,并且将查询路由至服务树中的下一个级别。叶服务器与存储层进行通信或者访问本地磁盘上的数据。在所描述系统中进行操作的许多查询是单次扫描聚合;因此,本文档关注于对那些进行解释并且将它们用于下一部分中的实验。考虑以下的简单聚类:
SELECT A,COUNT(B)FROM T GROUP BY A
当根服务器接收到以上查询时,其确定包括表“T”的所有板块并且将该查询重写如下,其中板块即表的水平分区:
SELECT A,COUNT(B)FROM T GROUP BY A
表UNION ALL...是发送至处于服务树的级别1处的节点1,...,n的查询的结果:
是“T”中被服务器“l”以级别“1”所处理的板块的解体分区。每个服务级别执行类似的重写。最终,该查询到达叶,其对“T”中的板块进行并行扫描。在向上的途中,中间服务器执行部分结果的并行聚合。以上所给出的执行模型非常适于返回小型和中等大小的结果的聚合查询,而这是非常普遍的交互式查询类型。
查询分配器。所描述的系统是多用户系统,例如可以同时执行若干查询。查询分配器基于查询的优先级对它们进行调度并且平衡负载。另一个角色是在一个服务器变得远比其它服务器更慢地多或者板块副本变得无法访问时提供容错。
每个查询中所处理的数据量经常大于可用于执行的处理单元的数量,该处理单元被称作时隙。时隙对应于叶服务器上的执行线程。例如,均使用8个线程的3000个叶服务器的系统具有24000个时隙。从而,能够通过对每个时隙指定大约5个板块来对跨度为100000个板块的表进行处理。在查询执行期间,如果板块采用不成比例的长时间来进行处理,则系统在另一个服务器上对该板块重新进行调度。一些板块可能需要被多次重新分配。
叶服务器读取列状表示中嵌套数据的条带。每个条带中的块被异步地预先取出;预读高速缓存通常获得95%的命中率。板块通常进行三路赋值。当叶服务器无法访问一个板块副本时,其转向另一个副本。
查询分配器尊重(honor)指定返回结果之前必须扫描的板块最小百分比的参数。如以下所描述的,将这样的参数设置为较低值(例如,98%而不是100%)经常能够使得执行明显加速,特别是在使用较小的复制因子时。
如图7的右手侧所描绘的,每个服务器可以具有内部执行树。内部树对应于物理查询执行计划,包括标量表达式的评估。优选地,对大多数标量函数生成具体类型的代码。基本执行计划由一组迭代器所构成,它们步伐一致地对输入列进行扫描并且发出利用正确的重复和定义级别进行注释的聚类和标量函数的结果,这在查询执行期间完全绕过了记录整合。
所描述系统所进行诸如top-k和不同计数(count-distinct)的一些查询使用已知的单次扫描算法返回近似结果。
第7部分:实验数据
该部分给出了所描述系统在若干数据集合上的实验评估,并且检验了列状存储对于嵌套数据的有效性。研究中所使用的数据集合的属性在图11中进行了概括。以未压缩的非复制形式,数据集合占据了大约一千兆字节的空间。除了一个被双路复制的表之外,所有表被三路复制,并且包含从100K至800K个可变大小的板块。该部分以检验单台机器上的基本数据访问特性作为开始,随后示出列状存储如何惠及MapReduce执行,并且最后集中于所描述系统的性能。在常规商业操作期间,实验在两个数据中心中许多其它应用之外运行的系统实例上进行。以下所使用的表和字段名称被匿名处理。
本地磁盘。在第一个实验中,通过扫描包含大约300K行的表T1的1GB片段进行扫描来检查列状存储相对面向记录的存储性能权衡(见图12)。数据存储在本地磁盘上并且在压缩列状表示中占用大约375MB。面向记录的格式使用更严重的压缩却在磁盘上产生了大约相同的大小。该实验在具有提供70MB/s读取带宽的磁盘的双核Intel机器上进行。所有的报告时间都是冷却的;OS高速缓存在每次扫描之前都被冲刷。
图12示出了五幅图,图示了针对字段子集读取并解压缩数据,以及整合并解析记录所用的时间。图(a)-(c)概括了列状存储的结果。这些示图中的每个数据点是通过对30次运行的测量进行平均而获得的,在其中的每个中随机选择给定基数的列集合。图(a)示出了读取和解压缩时间。图(b)加上了对来自列的嵌套记录进行整合所需的时间。图(c)示出了要用多久将记录解析为强类型的C++数据结构。
图(d)-(e)描绘了用于访问面向记录的存储上的数据的时间。图(d)示出了读取和解压缩时间。大块时间花费在解压缩中;实际上,压缩数据能够以大约一半的时间从磁盘进行读取。如图(e)所指示的,解析在读取和解压缩时间上加上了另外的50%。这些成本针对所有字段,包括不需要的字段,进行支付。
当读取数个列时,列状表示的增益可能大约为一个数量级。用于列状嵌套数据的获取时间可以随字段的数量线性增长。记录整合和解析可能是昂贵的,可能均为执行时间的两倍。在其它数据集合上观察到类似的趋势。一个自然的问题是要询问示图的顶端和底部在哪里相交,即按照记录的存储在哪里开始优于列状存储。按照经验,交叉点会位于数十个字段但是跨数据集合而变化,并且取决于是否需要记录整合。
Map Reduce和所描述系统。接下来说明MapReduce和所描述系统对于列状相比面向记录的数据的执行。在这种情况下,访问单个字段并且性能增益最为显著。针对多个列的执行时间可以使用图12的结果进行推断。在该实验中,对表“T1”中字段“txtField”中的项的平均数目进行计数。MapReduce执行使用以下Sawzall程序来进行:
numRecs:table sum of int;
numWords:table sum of int;
emit numRecs<-1;
emit numWords<-CountWords(input.txtField);
记录的数目存储在变量“numRecs”中。对于每个记录,“numWords”增加“CountWords”函数所返回的“input.txtField”中项的数目。在该程序执行之后,平均的项频率可以被计算为numWords=numRecs。在SQL中,该计算被表达为:
Q1:SELECT SUM(CountWords(textile))/COUNT(*)FROM T1
图13示出了对数规模上的两个MapReduce工作和所描述系统的执行时间。两个MapReduce工作在3000个工作者(例如,服务器)上运行。类似地,本系统的3000节点实例被用来执行查询Q1。所描述的系统和列上MapReduce读取0.5TB的压缩列状数据,相比之下,记录上的MapReduce则读取了87TB。如图12所图示的,MapReduce通过从面向记录切换至列状存储而在效率上有量级的增益(从数小时到数分钟)。通过使用所描述系统则实现了另一个量级(从数分钟到数秒)。
服务树拓扑。在下一个实验中,图示了服务树深度对于查询执行时间的影响。在表T2上执行两个GROUP BY查询,每个都使用数据上的单次扫描来执行。表T2包含240亿的嵌套记录。每个记录具有包含数字量的重复字段item。字段item.amount在数据集合中重复大约400亿次。第一查询通过country对项数量进行加总:
Q2:SELECT country,SUM(item.amount)FROM T2
GROUP BY country
其返回数百条记录并且从磁盘读取大约60GB的压缩数据。下一个查询利用选择条件对文本字段域执行GROUP BY。其读取大约180GB并且产生大约110万个不同的域:
Q3:SELECT domain,SUM(item.amount)FROM T2
WHERE domain CONTAINS’.net’
GROUP BY domain
图14示出了作为服务器拓扑的函数的每个查询的执行时间。在每种拓扑中,叶服务器的数量保持恒定为2900,从而可以假设相同的累积扫描速度。在2级拓扑中(1:2900),单个根服务器直接与叶服务器进行通信。对于3个级别,使用1:100:2900的设置,即100个中间服务器的额外级别。4级拓扑为1:10:100:2900。
当在服务树中使用3个级别时,查询Q2在3秒内运行并且没有从额外的级别诸多地获益。与之相比,Q3的执行时间由于有所增加的平行而减半。以2个级别,Q3脱离图表,因为根服务器需要对从数千个节点所接收的结果进行近似顺序地聚合。该实验图示了返回许多群组的聚合如何可以从多级服务树获益。
每板块直方图。图15示出了针对Q2和Q3的具体运行板块多快得到叶服务器的处理。在板块被电镀用于在可用时隙中执行时的点开始测量时间,即排除了工作队列中等待所花费的时间。该测量方法以因子析出了同时执行的其它查询的效果。每个直方图下的面积对应于100%。如图15所指示的那样,Q2(或Q3)99%的板块在一秒(或两秒)内得到处理。
记录内聚合。作为另一个实验,当其在表T3上运行时检验查询Q4的性能。该查询说明了记录内聚合:其对所有记录进行计数,其中记录中出现的a.b.c.d值的总和大于a.b.p.q.r值的总和。字段以不同级别的嵌套进行重复。由于列状条带,仅从磁盘读取了(70TB中的)13GB,并且查询以15秒完成。在不支持嵌套的情况下,在T3上运行该查询将会是昂贵的。
Q4:SELECT COUNT(c1>c2)FROM
(SELECT SUM(a.b.c.d)WITHIN RECORD AS c1,
SUM(a.b.p.q.r)WITHIN RECORD AS c2FROM T3)
可扩展性。以下实验说明了系统在万亿记录的表上的可扩展性。以下所示出的查询Q5选择前20个aid以及它们在表T4中出现的数目。以下查询扫描4.2TB的压缩数据。
Q5:SELECT TOP(aid,20),COUNT(*)FROM T4
WHERE bid={value1}AND cid={value2}
该查询使用系统的四种配置来执行,范围从1000至4000个节点。执行时间处于图16中。在每次运行中,总过所花费的CPU时间是近似相同的,大约为300K秒,而用户所感知的时间则随系统大小的增加而近似线性地减少。该结果提示较大的系统在资源使用方面可以向较小系统一样有效,但是允许更快的执行。
掉队者(Straggler)。掉队者可能是例如由于执行任务的机器具有操作问题或该机器在处理给定以更高优先级的任务时并非足够积极而没有被执行的任务(例如,对板块进行处理)。以下的查询Q6在万亿行的表T5上执行。与其它数据集合相比,T5被双路复制。因此,掉队者延缓了执行的可能性更高,原因在于由于对工作进行重新调度的机会更少。
Q6:SELECT COUNT(DISTINCT a)FROM T5
查询Q6读取1TB的压缩数据。所检索字段的压缩比大约为10。如图17中所指示的,99%的板块的处理时间低于每时隙每板块5秒。然而,当在2500个节点的系统上执行时,小部分板块占用更长时隙,将查询响应时间从小于一分钟减缓为数分钟。下一部分对实验结果进行概括。
第8部分:观察
图18在对数规模上示出了所描述系统典型的按月工作负载中的查询响应时间分布。如图18所指示的那样,大多数查询在10秒内被处理,良好地处于交互范围内。一些查询已经在繁忙集群中获得了接近每秒钟1000亿记录的扫描吞吐量,并且在专用机器上甚至更高。以上所给出的实验数据建议以下观察:
·能够在数个记录的磁盘驻留数据集合上以交互式速度执行基于扫描的查询;
·对于包含数千节点的系统可以实现列和服务器数量近似线性的可扩展性;
·MapReduce可以向DBMS一样从列状存储获益;
·记录整合和解析是昂贵的。(查询处理层之上的)软件层可以被优化以直接消费面向列的数据;
·MapReduce和查询处理可以以互补的方式使用,一个层的输出能够提供另一个层的输入;
·在多用户环境中,较大系统能够从规模经济获益同时提供质量更好的用户体验;
·如果相对准确性对速度有所妥协是可接受的,则查询可以更早终止但是仍看到大多数数据;以及
·网络规模的数据集合的块可以被快速扫描,虽然到最后数个百分点可能会增加处理时间的量。
图19是用于生成嵌套记录的列状存储表示并对其进行处理的系统的框图。记录生成器1904生成来自数据源1920的嵌套数据的记录和模式1902。列生成器1908接收记录1906和模式1902输入并且输出表示记录1906中的数据但是为列状格式的列状条带。列状数据1910可以由查询系统1912就地进行查询以便产生输出列1914的不同集合。列状数据1910还可以被记录整合器1916整合回到记录形式。记录整合器所输出的记录1918中的每个包括来自集合1906中的原始记录的字段的子集。输出记录1918可以通过基于记录的数据分析程序(例如,MapReduce)对其进行操作。
更具体地,数据源1920可以包括实质上非结构化的数据。实质上非结构化意味着该数据可以包括表示结构的元素,但是整个信息谱可能没有被类似地结构化。作为说明,数据源1920可以包括数百万网站中每一个的源代码。虽然每个网站包括一定程度的结构,但是每个网站的内容并非基于共用模式所生成。标准可以总体上对站点的格式进行管理,但是字段的内容和放置并没有通过单种模式在每个和各个网站之间进行规定。在一些示例中,数据源1920中的信息并不存储在共用存储层1922中,而是直接从互联网上的外部源拉取。
模式1902定义了可以包含在数据源中的信息的共用结构。如本文档之前所描述的,模式1902能够要求某些信息字段并且可以允许其它信息字段作为可选的进行存储。
记录生成器1904接收模式1902以及来自数据源1920的信息作为输入。记录生成器1904从数据源1920取得信息并且将全部或部分信息结构化为符合模式1902的记录的单独实例。例如,在数据源1920可以包括来自网页的实质上非结构化的数据时,记录生成器1904可以从每个网页选择数条信息以针对特定记录1906而包括于其中。
因此,每个记录1906可以包括根据模式1902结构化的数据。结构数据可以包括字段,其可以表示数据值的语音以及数据值的结构关系。因此,可以参考模式以获得数据值的附加定义信息(例如,数字存储的数据值实际表示什么或者在网页上表示什么以及与其它值的关系)。
每个记录1906可以包括嵌套字段和数据值。嵌套记录可以包括多于一个的相同名称或路径的字段。然而,具有相同名称或路径的字段在结构上可以位于特定记录中的不同位置。例如,模式所定义的单个字段可能能够重复多次。另外,字段可以具有子字段(即,嵌套字段)。因此,特定字段可以在记录的顶级进行重复,并且字段的每次重复可以包括或可以不包括特定子字段。换句话说,记录可以在记录的一些部分中包括子字段的实例,但是在记录的其它部分中则不包括。
记录1906的集合可以被转换为列状数据1910以加速记录中信息的处理。例如,如果集合1906中的记录量为数十亿,并且每个记录可以包括数百个不同字段,则记录的分析可能是时间密集的,而其中需要少量字段上的信息是所需要的。这是因为集合1906中的每个记录与来自该记录的其它信息一起存储。也就是说,每个记录在存储器的连续部分中被分组在一起(例如,如图1的嵌套数据的“面向记录”的描绘中所图示的那样)。
与之相比,列状数据1910包括列,每个列存储模式1902中单个字段的信息(例如,如图1中嵌套数据的“面向列”的描绘中所图示的那样)。因此,如果字段为一字节长,则用于字段的列可以为数十亿字节(例如,每个记录一个字节)而不是数十亿记录(例如,其中每个记录的大小可能为一兆字节)的量级。列生成器1908的操作在第4.2部分“将记录划分为列”中更为详细地进行了描述。列状数据1910的存储格式在第4.1部分“重复和定义级别”中更为详细地进行了描述。
列状数据1910可以使用查询系统1912直接进行查询。换句话说,列状数据1910可以在不将数据加载到数据库中的情况下进行查询。当执行查询时,查询系统可以接收列状数据的表作为输入。在一些示例中,查询系统还接收模式1902作为输入。列状条带可以与模式存储在一起以进行数据的自行描述。查询系统允许对列状数据执行操作以便生成输出信息的列1914。输出列1914可以包括如特定查询所确定的列状数据1910中所表示的值的子集。在一些示例中,查询系统输出记录1918而不是列1914,或者除了列1914之外还输出记录1918。
例如,查询系统1912可以接收第一查询,并且作为响应,可以通过选择数据列并生成输出列的集合进行解析,该输出列提供具有一个或多个视频的所有网页的标题以及每个网页的视频数目。查询系统可以接收第二查询,并且作为响应输出输出列的第二集合,其提供最近十五分钟内所生成的每个网页的URL。来自列1910的其它信息可以不包括在对应于特定查询1914的输出列的集合中。
作为列状数据1910存储的数据可能需要由并不对列状数据进行操作而是对记录进行操作的分析服务进行访问。因此,记录整合器1916可以接收列状数据以及来自列状数据的整合记录作为输入。对记录进行整合的处理在第4.3部分“记录整合”中更为详细地进行了描述。
虽然记录在集合1906中可能已经是可用的,但是记录整合器1916使得能够生成包括集合1906中的记录的字段子集的记录集合。例如,该集合中的记录可以包括数千个不同字段。用户可能想要运行仅需要来自两个字段而非所有记录的知识的面向记录的分析程序。因此,记录整合器1916可以生成仅包括所请求字段上的信息的记录集合。以这种方式,能够针对不同分析或针对不同分析程序开发多个输出记录集合1918。对较小记录的分析会比必须对集合1906中可能找到的较大记录进行遍历的分析更为快速。
以上对系统1900的操作的描述图示了记录集合1906包括依据模式1902进行格式化的记录并且从该类似结构的数据的单个集合生成列状数据1910的示例。在各种示例中,多个模式1902可以被用来生成包括许多不同结构的记录的集合1906的记录集合。然而,每个记录可以在报头中标识出记录生成中所使用模式的类型。类似地,可以对许多类似结构的记录的集合中的每一个中的每个字段生成列状条带。每个列状条带不仅可以指示字段名,而且还指示列状数据与之相关联的模式(即,用来对从其生成该列状数据的记录进行格式化的模式)。
图20是用于生成列状数据的示例过程的流程图。该过程可以由系统1900的组件来执行。
在框2002,生成记录的集合。记录的生成可以由记录生成器1904来执行。(例如,来自数据源1920的)非结构化数据可以被编译为模式1902所定义的标准化记录格式。记录可以被存储在集合1906中。
在框2004,访问集合1906中的记录。例如,列生成器1908从记录集合1906接收数据作为输入。
在框2006,确定是否要针对附加字段生成列状条带。例如,要对集合1906中所存储的记录集合中的每个字段(并且因此为模式1902中的每个记录及其子集)生成条带。在该说明中,还没有形成条带,并且因此存在要对其生成条带的字段。因此,该过程进行至2008以便对特定字段执行操作。如果所有条带都已经被生成(例如,已经为记录集合1906中的每个字段生成了条带),则该过程可以结束。
在框2008,为特定字段生成值列表。例如,可以对每个记录进行遍历并且为特定字段生成值列表。
在框2010,为特定字段生成重复级别。例如,列生成器1908可以通过确定字段的路径中最近重复的字段而为列表中的每个值确定重复级别。
在框2012,为特定字段生成定义级别。例如,列生成器1908可以为每个值(如以上更为详细描述的,包括“缺失的”值)确定定义级别。
在框2014,针对特定字段整合列状条带。在各种示例中,重复和定义级别被置于条带报头中的成对分组中。该值列表可以被置于条带体之中。
在框2016,将列状条带分解为可以被压缩的块。每个块可以包括一组值及其相对应的重复和定义级别。随后,在框2006执行是否要对附加字段生成列状条带的确定。如果没有附加的列状条带有待生成,则该过程结束。
图20所描绘的过程是用于生成列状条带的示例过程。预见到对于该过程的变化。例如,各框的操作可以并非如流程图中所描绘的顺序执行。多个字段的条带可以一次生成。重复级别和定义级别可以在从记录获得每个值时被生成。列状条带可以不作为整体生成。相反,可以从条带生成每个块并且对他们进行独立压缩。因此,该流程图可以表示用于理解条带生成的概念性机制而并非旨在作为限制。用于生成列状数据的过程在图4的算法中进行了描绘,其可以并不对应于关于图20所描述的操作。
图21是可被用来实现这里所描述的系统和方法的计算设备2100、2150的框图。计算设备2100旨在表示各种形式的数字计算机,诸如膝上计算机、台式机、工作站、个人数字助理、服务器、刀锋服务器、大型机和其它适当计算机。计算设备2150旨在表示各种形式的移动设备,诸如个人数字助理、移动电话、智能电话和其它类似的计算设备。此外,计算设备2100或2150可以包括通用串行总线(USB)闪存驱动。USB闪存驱动可以存储操作系统和其它应用。USB闪存驱动可以包括诸如无线传送器或USB连接器之类的可以插入另一计算设备的USB端口的输入/输出组件。这里所示出的组件、其连接和关系以及其功能仅旨在进行示例,而并非旨在对本文档中所描述和/或要求保护的发明的实现进行限制。
计算设备2100包括处理器2102、存储器2104、存储设备2106、连接到存储器2104和高速扩展端口2110的高速接口2108,以及连接到低速总线2114和存储设备2106的低速接口2112。组件2102、2104、2106、2108、2110和2112中的每个使用各种总线进行互连,并且可以安装在共用主板上,或者以其它适宜方式进行安装。处理器2102能够处理指令以便在计算设备2100内执行,该指令包括存储在存储器2104中或者存储设备2106上以在诸如耦合到高速接口2108的显示器2116的外部输入/输出设备上显示用于GUI的图形信息的指令。在其它实现中,可适当地使用多个处理器和/或多个总线,以及多个存储器和存储器类型。而且,多个计算设备2100可以与提供各部分必要操作的每个设备进行连接(例如,作为服务器组、刀锋服务器分组或多处理器系统)。
存储器2104存储计算设备2100内的信息。在一种实现中,存储器2104是一个或多个易失性存储单元。在另一实现中,存储器2104是一个或多个非易失性存储单元。存储器2104还可以是其它形式的计算机可读介质,诸如磁盘或光盘。
存储设备2106能够为计算设备2100提供大型存储。在一种实现中,存储设备2106可以是或者可包含计算机可读介质,诸如软盘设备、硬盘设备、光盘设备、磁带设备、闪存或其它类似固态存储设备、或者设备阵列,包括存储域网络或其它配置中的设备。计算机程序产品可有形实现在信息载体中。所述计算机程序产品还可包含指令,当被执行时,所述指令执行诸如以上所描述的一个或多个方法。所述信息载体是计算机或机器可读介质,诸如存储器2104、存储设备2106、处理器2102上的存储器。
高速控制器2108管理用于计算设备2100的带宽密集操作,而低速控制器2112管理较低带宽密集的操作。这样的功能分配仅是示例性的。在一种实现中,高速控制器2108耦合到存储器2104、显示器2116(例如,通过图形处理器或加速器),并且耦合到可接受各种扩展卡(未示出)的高速扩展端口2110。在所述实现中,低速控制器2112耦合到存储设备2106和低速扩展端口2114。可以包括各种通信端口(例如,USB、蓝牙、以太网、无线以太网)的低速控制端口2114可耦合到一个或多个输入/输出设备,诸如键盘、指点设备、扫描仪,或者例如通过网络适配器耦合到诸如交换机和路由器之类的联网设备。
如图所示,计算设备2100能够以各种不同形式来实现。例如,其可以实现为标准服务器2120,或者这种服务器群组中的多次器。其还可以被实现为机架式服务器系统2124的一部分。此外,其还可以在诸如膝上计算机2122的个人计算机中实现。备选地,来自计算设备2100的组件可以与诸如设备2150的移动设备(未示出)中的其它组件相结合。每个这样的设备可包含一个或多个计算设备2100、2150,并且整个系统可由多个彼此通信的计算设备2100、2150所构成。
除其它组件之外,计算设备2150包括处理器2152、存储器2164、诸如显示器2154之类的输入/输出设备、通信接口2166和收发器2168。设备2150还可提供以诸如微驱动器或其它设备的存储设备以提供附加存储。每个组件2150、2152、2164、2154、2166和2168使用各种总线进行互连,并且若干组件可装配在共用主板上或者以其它适宜方式进行安装。
处理器2152能够执行计算设备2150内的指令,包括存储在存储器2164中的指令。所述处理器可被实现为包括单独且多个的模拟和数字处理器的芯片的芯片组。此外,处理器可以使用任意数量的架构来实现。例如,处理器410可以是CISC(复杂指令集计算机)处理器、RISC(精简指令集计算机)处理器或MISC(最小指令集计算机)处理器。例如,所述处理器可提供用于设备2150的其它组件的协同,诸如用户接口控件、设备2150所运行的应用程序以及设备2150所进行的无线通信。
处理器2152可以通过耦合到显示器2154的控制接口2158和显示器接口2156与用户进行通信。显示器2154例如可以是TFT LCD(薄膜晶体管液晶显示器)显示器或OLED(有机发光二极管)显示器,或者其它适当的显示技术。显示器接口2156可以包括用于驱动显示器2154向用户呈现图形和其它信息的适当电路。控制接口2158可以从用户接收命令并且对其进行转以便向处理器2152进行提交。此外,可提供与处理器2152进行通信的外部接口2162,从而使得设备2150能够与其它设备进行近域通信。例如,外部接口2162在一些实现中可提供有线通信,或者在其它实现中提供无线通信,并且也可使用多个接口。
存储器2164存储计算设备2150内的信息。存储器2164可以实现为一个或多个计算机可读介质或媒体、一个或多个易失性存储器单元或者一个或多个非易失性存储器单元。也以提供扩展存储器2174并通过扩展接口2172连接到设备2150,例如,所述扩展接口2172可以包括SIMM(单列存储组模)卡接口。这样的扩展存储器2174可为设备2150提供额外的存储空间,或者还可以为设备2150存储应用程序或其它信息。特别地,扩展存储器2174可以包括指令以执行或补充以上所描述的过程,并且还可以包括安全信息。例如,扩展存储器2174由此可被提供作为设备2150的安全模块,并且可利用允许对设备2150进行安全使用的指令进行编程。此外,可经由SIMM卡提供安全应用程序以及附加信息,诸如以不可破坏的方式在SIMM卡上设置识别信息。
例如,如以下所描述的那样,所述存储器可以包括闪存和/或NVRAM存储器。在一种实现中,计算机程序产品有形实现在信息载体中。所述计算机程序产品还可包含指令,当被执行时,所述指令执行诸如以上所描述的一个或多个方法。所述信息载体是计算机或机器可读介质,诸如存储器2164、扩展存储器2174、处理器2152上的可例如通过收发器2168或外部接口2162上进行接收的存储器。
设备2150可通过通信接口2166进行无线通信,必要时,所述通信接口2166包括数字信号处理电路。通信接口2166可在各种模式或协议下提供通信,除其它之外,所述模式或协议诸如GSM语音呼叫、SMS、EMS或MMS消息发送、CDMA、TDMA、PDC、WCDMA、CDMA2000或GPRS。例如,这样的通信可通过射频收发器2168进行。此外,诸如可使用蓝牙、WiFi或其它这样的收发器(未示出)进行短范围通信。此外,GPS(全球定位系统)接收器模块2170可为设备2150提供附加的导航和位置相关的无线数据,其可由设备2150上运行的应用程序适当使用。
设备2150还使用音频编解码器2160进行可听通信,所述音频编解码器2160接收来自用户的话音信息并且将其转换为可用的数字信息。音频编解码器2160同样可以诸如通过扬声器,例如在设备2150的听筒中,为用户生成可听声音。这样的声音可以包括来自语音电话呼叫的声音,可以包括录制的声音(例如,语音消息、音乐文件等),并且还可以包括设备2150上运行的应用程序所生成的声音。
如图所示,计算设备2150可以以多种不同方式来实现。例如,其可以实现为移动电话2180。其还可以实现为智能电话2182、个人数字助理或其它类似移动设备的一部分。
这里所描述的系统和技术的各种实现可以以数字电路、集成电路、专门设计的ASIC(专用集成电路)、计算机硬件、固件、软件和/或其组合来实现。这些各种实现可以包括一个或多个计算机程序中的实现,所述计算机程序可在包括至少一个可编程处理器的可编程系统上执行和/或解释,所述可编程系统可以为专用或通用,其耦合以从存储设备、至少一个输入设备以及至少一个输出设备接收数据和指令并且向其传送数据和指令。
这些计算机程序(也称作程序、软件、软件应用程序或代码)包括用于可编程处理器的机器指令,并且能够以高级程序化和/或面向对象编程语言来实现,和/或以汇编/机器语言来实现。如这里所使用的那样,术语“机器可读介质”、“计算机可读介质”是指用来向可编程处理器提供机器指令和/或数据的任意计算机程序产品、装置和/或设备(例如,磁碟、光盘、存储器、可编程逻辑设备PLD),其包括接收机器指令作为机器可读信号的机器可读介质。术语“机器可读信号”是指被用来为可编程处理器提供机器指令和/或数据的任意信号。
为了提供与用户的交互,这里所描述的系统和技术可在具有用于向用户显示信息的显示设备(例如,CRT(阴极射线管)或LCD(液晶显示器)监视器)和用户能够通过其为计算机提供输入的键盘和指点设备(例如,鼠标或轨迹球)的计算机上实现。也可以使用其它类型的设备来提供与用户的交互;例如,提供给用户的反馈可以为任意形式的传感器反馈(例如,视觉反馈、听觉反馈或触觉反馈);并且来自用户的输入可以以任意形式接收,包括声音、话音或触觉输入。
这里所描述的系统和技术可在计算系统中实现,所述计算系统包括后端组件(例如,数据服务器),或者其包括中间件组件(例如,应用服务器),或者其包括前端组件(例如,具有用户能够通过其与这里所描述的系统和技术的实施方式进行交互的图形用户界面或网络浏览器的客户端计算机),或者这些后端、中间件或前端组件的任意组合。所述系统的组件可通过任意形式的介质或数字数据通信(例如,通信网络)进行互连。通信网络的示例包括局域网(LAN)、广域网(WAN)、(具有ad-hoc或静态成员的)对等网络、网格计算基础设施和互联网。
该计算系统可以包括客户端和服务器。客户端和服务器通常彼此远离并且典型地通过通信网络进行交互。客户端和服务器的关系源自于在各自计算机上运行的计算机程序并且具有彼此的客户端-服务器关系。
虽然以上已经对一些实现进行了详细描述,但是其它修改也是可能的。此外,可以使用用于生成并处理嵌套记录的列状存储表示的其它机制。此外,图中所描绘的逻辑流程并不要求所示出的特定顺序或序列顺序来实现所期望的结果。可以提供其它步骤,或者可以从所描述的流程中删除步骤,并且可以向所描述的系统添加其它组件或者从中去除组件。因此,其它实现处于以下权利要求的范围之内。
Claims (14)
1.一种计算机实现的方法,包括:
由计算系统访问存储在计算机存储器中的数据记录集合,所述数据记录集合中的至少一些记录包括多个数据值以及标识出来自所述多个数据值的对应数据值的语义的多个数据元素,所述数据记录集合中的一个或多个数据记录中的每个包括相同数据元素的多个实例,并且包括对应于所述相同数据元素的所述多个实例的数据值;
由所述计算系统生成列状条带集合,所述列状条带集合包括来自所述数据记录集合中的数据记录的所述数据值,所述列状条带集合中的每个列状条带包括对应于来自所述记录集合中的记录的具体数据元素的数据值;
由所述计算系统针对所述列状条带集合中每个列状条带中的所述数据值中的至少一些生成以下数据:所述数据标识出来自所述数据记录集合的相应数据记录中的相应数据值的位置。
2.根据权利要求1所述的方法,其中所述数据由重复值和定义值所构成。
3.根据权利要求1至2中任一项所述的方法,进一步包括根据(i)所述列状条带集合中的所述列状条带,和(ii)所述数据来重构仅包含来自所述数据记录集合中的所述记录的数据元素的子集的记录集合。
4.根据权利要求1至2中任一项所述的方法,进一步包括生成所述列状条带集合中至少一些特定数据值的重复值,以与所述列状条带集合中的所述数据值一起存储,
其中每个特定数据元素的路径包括对所述特定数据元素的任意一个或多个父数据元素;
其中每个特定数据值的所述重复值标识出对应于所述特定数据值的所述特定数据元素的所述路径中最近重复过的数据元素;
其中所述特定数据元素的所述路径中的所述最近重复过的数据元素是在包括所述特定数据值的特定数据记录的分析期间在所述特定数据元素的所述路径中第二次遇到的数据元素,所述分析从所述特定数据值在所述特定数据记录中的位置向上朝着所述特定数据记录的开始进行。
5.根据权利要求1至2中任一项所述的方法,其中所述数据元素集合中所包括的所述数据元素中的每个特定数据元素与包括对所述特定数据元素的任意一个或多个父数据元素的相应路径相关联;
进一步包括生成所述数据记录集合中的至少一些特定路径或所述特定路径的部分的定义值,以与所述列状条带中的所述数据值一起存储;
其中所述至少一些特定路径或所述特定路径的部分的定义级别标识出所述特定路径或路径的部分中所包括的数据元素的数量。
6.根据权利要求1至2中任一项所述的方法,进一步包括:
由所述计算系统从数据源集合接收信息,每个数据源包括未根据模式而结构化的信息;以及
由所述计算系统通过根据所述模式对至少一些所述数据源中的所述信息进行结构化而生成所述数据记录集合中的至少一些所述数据记录。
7.根据权利要求1至2中任一项所述的方法,进一步包括:
由所述计算系统执行对所述列状条带集合的查询;以及
由所述计算系统且响应于所述查询的执行而输出新的列状条带,所述新的列状条带包括来自由所述查询所标识出的所述列状条带集合的列状条带的值的子集。
8.根据权利要求7所述的方法,其中执行所述列状条带集合的所述查询而并不将所述列状条带集合中所包括的所述数据值加载到数据库中。
9.根据权利要求1至2中任一项所述的方法,其中所述列状条带集合的至少第一列状条带包括多个数据块,所述多个数据块中的至少一些数据块中的每个包括定义了在每个块的值中所找到的值类型的声明值,从而使得在执行所述第一列状条带的查询时,所述计算系统避免不包括由所述查询所指定的数据值的一个或多个数据块。
10.根据权利要求1至2中任一项所述的方法,其中:
所述列状条带集合的第一列状条带包括来自所述数据记录集合中的对应于所述数据记录集合中的第一数据元素的实例的数据记录中的数据值,作为第一数据值;并且
所述第一列状条带在存储器中连续存储多个所述第一数据值,其中所述多个第一数据值在所述多个第一数据值存储在所述数据记录集合中的数据记录中时,并不在存储器中连续存储。
11.根据权利要求1至2中任一项所述的方法,其中所述数据记录集合中的至少一个数据记录包括根据嵌套数据模型所存储的数据元素和对应的数据值。
12.根据权利要求1至2中任一项所述的方法,其中:
第一数据记录包括第一数据元素和第二数据元素,所述第一数据元素是所述第二数据元素的父数据元素,并且所述第二数据元素是所述第一数据元素的子数据元素;
第一列状条带包括对应于所述第一数据记录中的所述第一数据元素的数据值以及对应于所述数据记录集合中的所述第一数据元素的实例的其它数据值;并且
第二列状条带包括对应于所述第一数据记录中的所述第二数据元素的数据值以及对应于所述数据记录集合中的所述第二数据元素的实例的其它数据值。
13.根据权利要求1至2中任一项所述的方法,其中所述数据能够与所述列状条带一起用于重构所述数据记录集合。
14.一种计算机实现的设备,包括:
用于由计算系统访问存储在计算机存储器中的数据记录集合的装置,所述数据记录集合中的至少一些记录包括多个数据值以及标识出来自所述多个数据值的对应数据值的语义的多个数据元素,所述数据记录集合中的一个或多个数据记录中的每个包括相同数据元素的多个实例,并且包括对应于所述相同数据元素的所述多个实例的数据值;
用于由所述计算系统生成列状条带集合的装置,所述列状条带集合包括来自所述数据记录集合中的数据记录的所述数据值,所述列状条带集合中的每个列状条带包括对应于来自所述记录集合中的记录的具体数据元素的数据值;
用于由所述计算系统针对所述列状条带集合中每个列状条带中的所述数据值中的至少一些生成以下数据的装置,所述数据标识出来自所述数据记录集合的相应数据记录中的相应数据值的位置。
Applications Claiming Priority (5)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US32110610P | 2010-04-05 | 2010-04-05 | |
US61/321,106 | 2010-04-05 | ||
US32168810P | 2010-04-07 | 2010-04-07 | |
US61/321,688 | 2010-04-07 | ||
CN201180021717.9A CN103003813B (zh) | 2010-04-05 | 2011-04-04 | 记录的列状存储表示 |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201180021717.9A Division CN103003813B (zh) | 2010-04-05 | 2011-04-04 | 记录的列状存储表示 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN107092627A true CN107092627A (zh) | 2017-08-25 |
CN107092627B CN107092627B (zh) | 2021-02-26 |
Family
ID=44027534
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201710015074.6A Active CN107092627B (zh) | 2010-04-05 | 2011-04-04 | 记录的列状存储表示 |
CN201180021717.9A Active CN103003813B (zh) | 2010-04-05 | 2011-04-04 | 记录的列状存储表示 |
Family Applications After (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201180021717.9A Active CN103003813B (zh) | 2010-04-05 | 2011-04-04 | 记录的列状存储表示 |
Country Status (8)
Country | Link |
---|---|
EP (1) | EP2556446B1 (zh) |
KR (1) | KR101785959B1 (zh) |
CN (2) | CN107092627B (zh) |
CA (1) | CA2795525C (zh) |
DE (2) | DE112011101200T5 (zh) |
GB (1) | GB2492720A (zh) |
HK (1) | HK1243202A1 (zh) |
WO (1) | WO2011126995A1 (zh) |
Families Citing this family (14)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US9037615B2 (en) | 2010-05-14 | 2015-05-19 | International Business Machines Corporation | Querying and integrating structured and unstructured data |
EP2780834B1 (en) | 2011-11-14 | 2020-07-08 | Google LLC | Processing changes to distributed replicated databases |
US9367293B2 (en) | 2012-06-18 | 2016-06-14 | International Business Machines Corporation | System and method for compiler assisted parallelization of a stream processing operator |
CN103793316B (zh) * | 2012-10-29 | 2017-06-23 | 腾讯科技(深圳)有限公司 | 确定软件性能的方法和系统 |
US10885001B2 (en) | 2013-01-17 | 2021-01-05 | International Business Machines Corporation | System and method for assigning data to columnar storage in an online transactional system |
WO2014145230A1 (en) * | 2013-03-15 | 2014-09-18 | Recent Memory Incorporated | Object-oriented data infrastructure |
CN104424314B (zh) * | 2013-09-06 | 2019-06-11 | Sap欧洲公司 | 对列状表数据库的数据库操作 |
GB2524074A (en) | 2014-03-14 | 2015-09-16 | Ibm | Processing data sets in a big data repository |
JP6287441B2 (ja) * | 2014-03-26 | 2018-03-07 | 日本電気株式会社 | データベース装置 |
CN104270257B (zh) * | 2014-09-10 | 2017-11-07 | 烽火通信科技股份有限公司 | 基于pb和xpath的网元级网管业务配置适配系统及方法 |
US10409799B2 (en) | 2015-10-19 | 2019-09-10 | International Business Machines Corporation | Supporting updatable repeated values over variable schema |
CN106713394A (zh) * | 2015-11-16 | 2017-05-24 | 华为技术有限公司 | 一种数据传输方法和装置 |
US11226985B2 (en) | 2015-12-15 | 2022-01-18 | Microsoft Technology Licensing, Llc | Replication of structured data records among partitioned data storage spaces |
CN105701199B (zh) * | 2016-01-08 | 2019-04-26 | 广东电网有限责任公司信息中心 | 一种数据依赖的数据质量检测方法及装置 |
Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN1195812A (zh) * | 1997-04-04 | 1998-10-14 | 国际商业机器公司 | 利用程序地址非连续历史记录的预测超高速缓存装入 |
US20090006399A1 (en) * | 2007-06-29 | 2009-01-01 | International Business Machines Corporation | Compression method for relational tables based on combined column and row coding |
Family Cites Families (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7213017B2 (en) | 2000-03-17 | 2007-05-01 | Microsoft Corporation | Systems and methods for transforming query results into hierarchical information |
-
2011
- 2011-04-04 DE DE112011101200T patent/DE112011101200T5/de active Pending
- 2011-04-04 KR KR1020127028880A patent/KR101785959B1/ko active IP Right Grant
- 2011-04-04 CA CA2795525A patent/CA2795525C/en active Active
- 2011-04-04 GB GB1219795.0A patent/GB2492720A/en not_active Withdrawn
- 2011-04-04 DE DE202011110863.9U patent/DE202011110863U1/de not_active Expired - Lifetime
- 2011-04-04 CN CN201710015074.6A patent/CN107092627B/zh active Active
- 2011-04-04 CN CN201180021717.9A patent/CN103003813B/zh active Active
- 2011-04-04 WO PCT/US2011/031123 patent/WO2011126995A1/en active Application Filing
- 2011-04-04 EP EP11713457.7A patent/EP2556446B1/en active Active
-
2018
- 2018-02-22 HK HK18102580.2A patent/HK1243202A1/zh unknown
Patent Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN1195812A (zh) * | 1997-04-04 | 1998-10-14 | 国际商业机器公司 | 利用程序地址非连续历史记录的预测超高速缓存装入 |
US20090006399A1 (en) * | 2007-06-29 | 2009-01-01 | International Business Machines Corporation | Compression method for relational tables based on combined column and row coding |
Non-Patent Citations (1)
Title |
---|
DANIEL J.ABADI EL AT.: "SW-Store:a vertically partitioned DBMS for Semantic Web data management", 《THE VLDB JOURNAL》 * |
Also Published As
Publication number | Publication date |
---|---|
CN103003813B (zh) | 2017-02-15 |
CA2795525A1 (en) | 2011-10-13 |
CA2795525C (en) | 2018-03-13 |
EP2556446B1 (en) | 2018-12-12 |
DE202011110863U1 (de) | 2017-01-13 |
HK1243202A1 (zh) | 2018-07-06 |
KR101785959B1 (ko) | 2017-10-17 |
DE112011101200T5 (de) | 2013-01-17 |
CN103003813A (zh) | 2013-03-27 |
CN107092627B (zh) | 2021-02-26 |
EP2556446A1 (en) | 2013-02-13 |
GB2492720A (en) | 2013-01-09 |
KR20130084599A (ko) | 2013-07-25 |
GB201219795D0 (en) | 2012-12-19 |
WO2011126995A1 (en) | 2011-10-13 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN103003813B (zh) | 记录的列状存储表示 | |
EP2572289B1 (en) | Data storage and processing service | |
US10176225B2 (en) | Data processing service | |
KR101365832B1 (ko) | 데이터 액세스 계층 클래스 생성기 | |
US20090171999A1 (en) | System and Methodology for Parallel Stream Processing | |
WO2016029018A2 (en) | Executing constant time relational queries against structured and semi-structured data | |
CN107766402A (zh) | 一种楼盘字典云房源大数据平台 | |
CN103177094A (zh) | 一种物联网数据清洗方法 | |
Mishra et al. | Challenges in big data application: a review | |
Sinthong et al. | AFrame: Extending DataFrames for large-scale modern data analysis (Extended Version) | |
Dhanda | Big data storage and analysis | |
Cai et al. | Research on tracking and tracing bitcoin fund flows | |
Aivalis | Big data technologies | |
Alzaidi et al. | Benchmarking redis and hbase nosql databases using yahoo cloud service benchmarking tool | |
Cheah | Quality, retrieval and analysis of provenance in large-scale data | |
Zheng et al. | Speeding up processing data from millions of smart meters | |
Sarkar | Learning Spark SQL | |
Sanaboyina | Performance evaluation of time series databases based on energy consumption | |
Gupta et al. | Role of Big Data in e-Healthcare Application for Managing a Large Amount of Data | |
Hellman | Study and Comparison of Data Lakehouse Systems | |
Urbano | DOZER: a scalable and fault-tolerant streaming engine for Seraph queries evaluation | |
Rodrigues | Experimental evaluation of big data querying tools | |
Bernaschi et al. | Forensic disk image indexing and search in an HPC environment | |
Shrivastava et al. | Pruthak: mining and analyzing graph substructures | |
Gluck | FAWN-DLi: A data library for a fast array of wimpy nodes |
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: American California Applicant after: Google limited liability company Address before: American California Applicant before: Google Inc. |
|
REG | Reference to a national code |
Ref country code: HK Ref legal event code: DE Ref document number: 1243202 Country of ref document: HK |
|
GR01 | Patent grant | ||
GR01 | Patent grant |