CN107016071B

CN107016071B - 一种利用简单路径特征优化树状结构数据的方法及系统

Info

Publication number: CN107016071B
Application number: CN201710178692.2A
Authority: CN
Inventors: 陈世敏; 王智义
Original assignee: Institute of Computing Technology of CAS
Current assignee: Institute of Computing Technology of CAS
Priority date: 2017-03-23
Filing date: 2017-03-23
Publication date: 2019-06-18
Anticipated expiration: 2037-03-23
Also published as: CN107016071A

Abstract

本发明提出利用简单路径特征优化的树状结构数据处理方法及系统，该方法包括步骤1，设置简单路径，其中所述简单路径为在数据定义的语法树中，从根节点到叶子节点最多只存在一个多值的域的路径；步骤2，通过在扁平行式结构数据中存储所述的简单路径上叶子节点的信息，获取路径上完整的嵌套结构；步骤3，在对列式数据查询过程中，需要将其组装为行式结构数据，通过简单路径的优化可以简化数据中的层次关系：仅通过叶子节点既可表示从根节点到叶子节点的路径而忽略路径中所有的非叶子节点。本发明中通过分析常见的半结构化数据，定义简单路径的概念，利用简单路径对STEED的数据存储、列式数据组装和查询过程进行了优化，提高了相关操作和功能的效率。

Description

一种利用简单路径特征优化树状结构数据的方法及系统

技术领域

本发明涉及数据处理技术领域，特别涉及一种利用简单路径特征优化树状结构数据的方法及系统。

背景技术

随着计算机网络和大数据处理技术的发展，传统关系型数据已经越来越不能满足网络和大数据环境下对数据定义和使用的要求，而以JSON和Protocol Buffers为代表的半结构化数据因为既能够充分的表达编程语言中对象(Object)的数据，同时还能够根据数据的格式变化对原有的数据格式进行修改和扩充，故而其在实际环境中被广泛的使用。

树状结构数据的定义：

T_value＝T_primitive|T_object|T_array

T_primitive＝string|number|boolean|null

Record＝T_object

如上所示，树状结构数据定义如下：

1.树状结构数据中的值可以是以下的3种：

object结构的数值；array结构的数值；原子类型的数值；

2.object结构的数值由花括号包括，内部由多个键值对(key value pair)对构成，键值对的个数可以是任意多个，但是要求不能有重复的key存在在object结构的对象中；

3.array结构的数据由方括号包括，内部由多个值(value)构成，值的个数可是任意多个，且可能会有重复的值出现；

4.原子类型的数据可以是字符串(string)，数值(number)，布尔值(boolean)和空(null)等；

5.如上2中所述的键值对中，键的取值只能是(string)类型的。

6.每一个树状结构的数据都是object结构的。

常见的数据的来源由以下几个方面：

1)数据资料(Data Feeds)

以twitter为代表的在网络中使用JSON格式对数据进行传输。用户及相关API程序可以通过监听相应的端口获得相应的数据更新。由于其数据内容丰富、结构相对复杂、数据来源比较稳定并且提供的数据量足够大，故本发明的实验和数据分析的过程中主要基于twitter数据集。如下，本发明分析了对twitter数据中的嵌套层次和重复域的个数进行了相应的分析。

2)在线数据服务(Online Data Service)

使用JSON格式的数据进行在线的数据服务。常见的类型为传输客户端的相应操作内容和返回对应的操作结果等。本发明研究了不同来源的在线数据服务的半结构化数据，例如雅虎(Yahoo)，新浪微博和IMDB等。通常用户可以使

叶子节点层次	没有重复域	1个重复域	多余2个重复域	总计
					1	16	0	0	16
2	61	2	0	33
					3	51	21	4	76
4	1	19	4	24
					5	0	12	0	12
6	0	12	0	12
					总计	129	66	8	203

用JSON根据一定API接口格式编辑数据服务的需求，发送给相应的数据服务器之后，解析JSON格式的返回数据从而完成一次数据服务。

本发明中对微博API的在线数据服务进行了相关的分析如图1所示。

本发明重点分析了其路径中包含的重复的域的个数：图中黑色部分为从根到叶子节点没有重复域的路径，浅色部分为仅有1个重复域的路径，白色部分为有2个以上重复域的路径。本发明中使用统计直方图的方式显示其构成的比例：大部分语法树中从根到叶子节点的路径最多只有1个重复的域。3)通信协议

本发明分析了Apache Hadoop和Hadoop HBase中通信相关的协议格式，其使用的是Protocol Buffers定义的半结构化数据进行通信相关的数据传输。在以上的系统中，定义了多种不同类型的半结构化通信格式，用于不同机器间的相互通信和控制。大部分用于通信的半结构化数据的格式十分简单。

本发明中对Apache Hadoop的通信协议进行了相关的分析如图2所示。

本发明重点分析了其路径中包含的重复的域的个数：图2中黑色部分为从根到叶子节点没有重复域的路径，浅色部分为仅有1个重复域的路径，白色部分为有2个以上重复域的路径。本发明中使用统计直方图的方式显示其构成的比例：大部分语法树中从根到叶子节点的路径最多只有1个重复的域。

4)公用数据集

通过分析DBpedia和data.gov中的数据，其使用JSON格式的数据进行公用数据集的存储。但是区别于传统意义上的半结构化数据文件，这些数据集中的数据仅由一条JSON数据组成。这条记录主要分为两部分：第一部分由一个嵌套子结构(JSON中的object)构成，存储了之后数据集合中数据的格式；第二部分则由一个数组存储每条记录的内容，且每条记录均为没有嵌套的结构。本发明可以很轻松的将这条记录拆分成数据定义和数据内容两部分，进而使用传统的半结构化数据处理的方法进行处理。

5)传感器数据

最新的传感器平台，例如Arduino,Dragon Board,Beagle Bone等，均能够产生和处理JSON类型的数据。本发明分析了以上来源的数据，发现其数据内部的格式更加的简单：数据中所有域的嵌套深度最多为2且最多只会有一个多值域出现在从根到叶子节点的路径上。

但是现阶段已有的数据处理系统不能对以上来源的JSON格式的半结构化数据进行很好的处理：既能够提供完整功能的前提下，同时各项操作有较好的性能。本发明分析了大量支持半结构化数据管理系统，其对半结构化数据的处理思路主要有以下三点：

1)扩展传统的关系型数据库的功能

例如PostgreSQL和Oracle等，将JSON等半结构化数据以文本或者内部编码的二进制格式的以一个连续的数据块的形式存储关系型数据库的表中。在进行相应的查询操作时，调用内部的解析函数对数据块中的内容进行解析，读取需要的域中的数据值。接下来调用关系型数据库中的运算函数对其进行相应的查询操作。

2)NoSQL数据处理系统

内部使用更加灵活的方式对半结构化数据进行二进制的编码，例如MongoDB等。其优势在于能够实现对原生的半结构化数据进行解析、存储和查询操作，具有较强的数据存储和查询优势。其在实现的过程中，根据半结构化数据的结构特点，新定义了或者扩展了一些查询相关的操作。

3)列式数据格式对数据进行处理

Google Protocol Buffers和Apache Hive+Parquet支持对半结构化数据进行数据的处理和查询等操作。相较于以上两类基于行式数据的数据处理系统，列式数据处理系统能够在大部分情况下能够提供更好的查询分析性能，但是其内部实现更加的复杂：内部通常使用列簇的形式对数据进行存储。对于半结构化数据解析和查询操作的实现有较高的难度。

现阶段以上3种实现半结构化数据处理系统的方法均存在不同程度的问题。

1)扩展已有的关系型数据库支持半结构化数据的处理相当低效

通过分析现阶段可支持半结构化数据处理的关系型数据库，发现大部分的数据库都没有针对半结构化数据的结构和数据特点进行对应的数据编码和优化。其主要是将半结构化数据存储为文本数据块的形式，通过其内部实现的一些数据解析函数对文本类型的数据块进行解析，从而得到每条记录中需要的信息。这样在数据库中直接存储文本类型的JSON格式数据浪费了大量的空间。

同时在数据查询的过程中，需要大量的字符串比较和查询操作，从而极大的限制了数据处理的效率。根据本发明已有的研究，虽然很多系统支持半结构化数据的运算，但是当数据量增加时，其查询的运行时间往往太长而导致其难以满足实时性的要求。

关系型数据库同时还不能很好的支持半结构化数据中一些新的结构特点。例如直接支持对嵌套和重复域的语法定义、扩展SQL查询语法支持半结构化数据结构特点。

2)NoSQL数据处理系统对数据的编码和查询效率不够好

本发明分析并研究了被广泛使用的NoSQL数据处理系统MongoDB。由于JSON数据语义的灵活性，MongoDB内部定义了冗余且繁琐的数据编码格式。研究中发现，其编码的效率十分低下，在大部分情况下，其编码后的数据文件会大于原有的文本格式的数据。数据内部的编码并没有有效的减少JSON文本数据中的冗余信息，相反在查询过程中还会带来额外的性能消耗。这就使得其数据处理的性能相对有限，尤其是对于海量数据的处理。

同时，这些NoSQL数据处理系统由于其内部设计的局限性导致其有些操作无法执行。例如，MongoDB中无法高效的完整实现SQL中的join连接运算(虽然在最新版本中加入了相关的类似的运算符，但是依然没有完全满足SQL中定义的join连接运算且执行的效率太低)。

3)列式数据格式处理数据

在关系型数据库中，列式数据库的存储和查询性能一般都会优于行式数据库。这是因为其在查询过程中不需要读取并处理记录中和当前查询无关的域的数据。但是其内部原理复杂、功能实现相对困难。

类似的，在支持对半结构化数据处理的系统中，使用列式数据进行存储和查询的系统内部也更加复杂。大部分使用行式数据的管理系统中对JSON内部格式没有语法的限制，既其数据的内容不需要预先的定义、在使用过程中数据的结构可以不断的衍变。但是对于列式的数据管理系统而言，需要预先给出列式数据的定义(Schema)且在使用过程中无法动态变化数据的结构。这就极大的限制了半结构化数据的灵活性。

此外，现阶段也没有很多的基于列式数据的半结构化数据处理系统可供用户选择。可供用户使用的列式系统现阶段只有基于Java实现的Apache Hive+Parquet。由于Java编程语言的限制，其查询的效率还有进一步优化的空间。而其运行的平台需要ApacheHadoop和HDFS的支持，所以系统初始化和运行的代价都很高。

本发明在进行对半结构化数据进行处理等相关研究时，发现现有的三种可行性方案均因对半结构化数据处理时对数据结构和实现的局限性导致的。

首先，半结构化数据中内部的结构特点导致对其的数据处理不能通过扩展关系型数据库得到。两者对于数据格式有不同的假设，所以在使用关系型数据库处理半结构化数据时会产生更高的代价以至于难以承受。所以本发明重新设计并实现了面向于半结构化数据数据处理系统，使得其能满足对复杂结构的半结构化数据的处理。

其次，考虑到半结构化数据定义的灵活及使用过程中可能会出现结构变化等特点，现阶段大部分NoSQL数据管理系统直接使用类本文结构的数据对其进行存储。这就导致了其存储效率太低且查询时的取值过程代价很高。在本发明的设计中，从数据中提取的结构存储在Schema语法定义中，在数据中仅保留最少的结构信息。这样就简化了数据中重复的结构信息，同时也使得针对数据内容的一些查询优化成为可能。

最后，现阶段基于JAVA实现的列式半结构化存储需要很多基础模块的支持，例如文件存储系统、调度系统等。这些都会导致其对系统的功能和使用有一些额外的限制且会导致其执行的效率不高。本发明基于C/C++实现的本数据处理系统(STEED)完全独立开发，这就使得系统从成整体进行优化成为可能；也不会有诸如需要预先对数据的格式进行定义且无法改变等由于平台而产生的限制。

发明内容

针对现有技术的不足，本发明提出一种利用简单路径特征优化树状结构数据的方法及系统。

本发明提供一种利用简单路径特征优化的树状结构数据处理方法，包括：

步骤1，设置简单路径，其中所述简单路径为在树状结构数据定义的语法树中，从根节点到叶子节点最多只存在一个多值的域的路径；

步骤2，通过存储所述简单路径中叶子节点的相关结构信息，从树状结构数据定义的语法树中获取完整的路径结构信息；

步骤3，在使用列式结构数据进行查询的过程中，使用简单路径对列式结构数据到行式结构数据的组装过程进行优化：简化行式结构数据中的嵌套关系，仅通过叶子节点表示从根节点到叶子节点的路径而忽略路径中所有的非叶子节点。

利用半结构化数据定义中叶子节点的相关信息从语法树中获得整个路径的结构信息。

对列式结构树状数据组装为行式结构数据之前，对待组装的每一条列式结构的路径按照叶子节点的ID进行相应的排序，之后，依次按照顺序从每个列式数据读取器中读取中每条记录所有的列数据项，依次将读出的数值与相关的结构信息写入到组装的结果中。

对于语法树中的非简单路径，依然按照树状结构数据典型的使用多层嵌套结构表示其结构和数据的方法进行存储。

还包括：

1)当语法树中从根节点到叶子节点的路径上没有重复节点的域：仅需要存储叶子节点的ID与相应域的数值；

2)当语法树中从根节点到叶子节点的路径上只有一个重复节点的域：按照以下两种结构进行存储：

a)将每个重复域的数值都作为一个独立的值存储在扁平的行式结构数据中，所以，数据中会有多项有相同ID的值，其个数决定于重复域中其值的个数；

b)将重复的域作为一个整体存储在扁平的行式结构数据中，其中数据中仅有一个重复域的ID表示其在数据中多次出现的值，且所述重复域是由一个数组形式的结构表示多个数值；

3)语法树从根节点到叶子节点的路径上有多个重复的节点：使用默认的树状数据存储结构，其中在扁平结构的数据中存储的ID为路径上嵌套层次为1的ID，其对应的偏移量指向存储完整嵌套结构的位置。

本发明还提出一种利用简单路径特征优化的树状结构数据处理系统，包括：

简单路径模块，用于设置简单路径，其中所述简单路径为在树状结构数据定义的语法树中，从根节点到叶子节点最多只存在一个多值的域的路径；

获取数据模块，用于通过存储所述简单路径中叶子节点的相关结构信息，从树状结构数据定义的语法树中获取完整的路径结构信息；

组装模块，用于在使用列式结构数据进行查询的过程中，使用简单路径对列式结构数据到行式结构数据的组装过程进行优化：简化行式结构数据中的嵌套关系，仅通过叶子节点表示从根节点到叶子节点的路径而忽略路径中所有的非叶子节点。

还包括：

由以上方案可知，本发明的优点在于：

1，半结构化数据的行式存储结构；实现对半结构化数据的行式二进制存储，使其能够完整的表达半结构化数据的语义并适应其数据定义变化的特点。此外，要求其结构简单、易于表达，具有较高的存储效率；

2，半结构化数据的列式存储结构；实现对半结构化数据的列式二进制存储，使其能够使用列式存储完整表达半结构化数据的结构。要求其能够表达半结构化数据复杂的结构特点并高效的存储数据的内容；

3，半结构化数据行式和列式两种格式的相互转化实现；使用解析和组装算法实现二进制行式和列式数据相互转化；

4，半结构化数据定义的语法树实现；使用树形结构存储数据中结构的定义信息；

5，对半结构化数据进行查询操作；使用行式及列式数据对其进行类SQL的查询操作；

6，基于半结构化数据的特点，扩展SQL的查询语法；由于半结构化数据中存在多值域，定义“ANY”、“ALL”和路径表达式解决查询过程中的数据歧义性的问题；

7，基于半结构化数据中简单路径的优化；简单路径是指从根节点到叶子节点上最多只存在一个多值域。本发明发现常见的半结构化数据中存在大量这样的结构，提出并实现了针对这样结构的存储和查询优化，极大的提高了查询的效率。

如附图4所示，本发明使用不同大小的数据集进行了数据已经加载到内存中(hotcached)和数据还没有加载到内存中(cold cached)的查询分析实验。实验中，本发明使用不同的SQL查询语句以得到相应的运算操作的性能对比，包括project映射，filter过滤，group分组，sort排序和join连接操作。

根据图4所示的查询性能，在cold cached数据没有加载到内存的实验中，STEED相对于Hive+Parquet有4.1到17.8倍的性能加速比，相对于MongoDB有55.9到105.2倍的加速比，相对于PostgreSQL有33.8到1294倍的加速比；而在hot cached的实验中，STEED对MongoDB有19.5到59.3倍的加速比，对Hive+Parquet有19.5到59.3倍的加速比，对PostgreSQL有16.9到392倍的加速比。附录中详细列出了本发明的各个查询操作的查询语句。

附图说明

图1微博API定义的JSON数据格式分析；

图2Apache Hadoop通信协议的相关分析；

图3是steed的组成模块图；

图4是steed的查询性能对比图；

图5是Protocol Buffers建立语法树的过程图；

图6是行式数据复合类型结构示意图；

图7是列式数据存储结构示意图；

图8是列式数据优化存储结构示意图；

图9是steed各查询操作示意图；

图10是分组操作运算过程中存储结构示意图；

图11是经过优化的行式存储结构示意图；

图12是可供选择的行式存储结构的优化方案示意图。

具体实施方式

鉴于以上现有技术的不足，本发明重新设计并实现了一个半结构化数据处理系统STEED。以下介绍了STEED系统的整体架构并简要介绍每一个模块的功能需求，之后分析这几个模块间的接口定义，同时简要说明STEED内部是如何处理和存储数据。

如图3所示，STEED主要由三个模块构成：

(1)数据解析模块：

读取文本数据，并将其解析为行式或者列式的二进制格式数据，存储在数据存储模块中。在数据解析的过程中，动态生成语法树，存储半结构化数据的定义。对JSON格式的数据进行解析时，由于其没有定义相应的数据格式(语法树，schema tree)，所以本发明只能在解析数据的过程中动态生成数据格式的定义；而对Protocol Buffers格式的数据，文本格式的数据和数据相关的定义会在数据解析前一同被提供，所以本发明在解析文本格式的数据前可以根据其定义建立语法树。根据语法树中域的定义，本发明将文本结构的数据转化为行式及列式的二进制格式数据。

(2)数据存储模块：

存储了经过数据解析模块生成的行式及列式二进制文件。其在内部可以实现对这两种格式数据的相互转换，以及将其直接输出为文本格式的JSON数据。在STEED系统中，本发明还根据行式和列式数据存储的特点对其存储结构进行了一定的优化，使之能够有较高的存储和查询效率。

(3)查询分析模块：

基于行式及列式格式的数据，对半结构化数据进行查询操作，包括projector映射，filter过滤，group分组，sort排序和join连接等。当STEED需要执行一次查询时，先由Query Parser查询解析器根据查询语句中的内容生成此次查询所需建立的操作树(Operator Tree)，树中的每一个节点都是一个SQL操作。数据在操作树中按照从叶子到根节点的顺序完成各个部分的运算直至到达根节点完成此次查询操作。本发明还实现了一些操作的多线程版本，支持projector映射，filter过滤和group分组等操作。

STEED系统一共分为三个模块，接下来本发明将逐一介绍每个模块的实现细节和过程。

第1部分数据解析模块

这一部分详细介绍了STEED的数据解析模块的实现细节和内部的关键算法，同时根据半结构化数据的结构特点，说明了STEED是如何分别针对JSON和Protocol Buffers解析并建立语法树的过程。

1.1数据解析模块结构概述

数据解析模块主要由以下三部分构成：

(1)Data Type数据类型：

用于描述和定义JSON和Protocol Buffers文本数据中域的二进制数据类型。STEED系统中定义了一些基本的数据类型，例如int，double，string等。对于JSON格式的数据，只需要将文本数据的值映射到系统内部的数据类型即可；而对于Protocol Buffers而言，使用其schema定义的数据复合数据类型对STEED默认的数据类型进行相应的转换，以供稍后建立语法树的过程使用。

(2)Schema Tree数据语法树：

建立半结构化数据的定义，既语法树。

对于Protocol Buffers的文本数据，在解析数据前首先根据其schema定义文件中对schema定义动态生成语法树。在数据解析过程中，定义的语法树的内容和结构保持不变。

JSON格式的数据则需要本发明在数据解析的过程中根据其数据中的格式和内容动态生成此语法树的定义。本发明假设每个域中数值的类型都保持不变，同时数组中的每个元素的值的类型都是相同的。

STEED存储了每个数据集对应的语法树定义。在查询分析模块中，STEED将按照语法树中数据的定义对数据集进行相应的查询操作。

(3)Parser：

用于将文本格式的半结构化数据拆分成为键值对(key value pairs)的形式，并稍后解析成STEED内部定义的行式或者列式的存储结构。对于Protocol Buffers数据，在解析的过程只需要按照语法树的定义对数据进行格式的转换；而对于JSON格式的数据，本发明在解析的过程中还需要分析数据中是否出现新定义的域，进而对现有的语法树进行修改。

1.2Data Type类型

1.2.1STEED支持的基本数据类型

STEED系统内部定义了一些二进制格式的数据，用于行式和列式格式数据的存储和运算：

1)整形数：TypeInt(8/16/32/64)分别表示8/16/32/64位的整形数；

2)浮点数：Type(Float/Double)分别表示float和double类型的浮点数；

3)字符串：TypeString表示的字符串；

4)时间戳：TypeTimeStamp表示时间戳，内部用TypeInt64具体实现。

以上的这些数据类型均可支持对其值的判空，本文和二进制数据的相互转化，比较操作等。

1.2.2JSON数据类型的转化

JSON定义了其数据中每个域中数据可能的类型。本发明将其定义的每个数据类型映射成STEED的对应的内部数据类型，如下表所示：

对于基本的数据类型，直接将JSON定义的类型映射成为STEED内部的基本数据类型；而对于JSON中object和array这些嵌套的复杂数据类型，STEED内部也定义了其对应的行列存储的方式，具体的存储方式请见下一章数据存储模块。

1.2.3Protocol Buffers数据类型的转化

与JSON相似，Protocol Buffers也定义一些内部基本的数据类型。在STEED的内部实现中，本发明直接将这些基本的数据类型转化为C++中的类型(C++Type)，并将其值存储在解析后的结果中。参见https://developers.google.com/protocol-buffers/docs/proto3#scalar。

此外，Protocol Buffers的schema中还可以定义复合的数据类型message。使用复合数据类型，本发明可以定义多层嵌套的数据格式定义。同时，在复合类型的定义中，本发明可以选择域的赋值属性，既required一定会出现的域，optional可能会出现的域和repeated会重复出现的域。

1.3语法树(Schema Tree)

在这一小节中，本发明将介绍STEED是如何使用语法树(Schema Tree)描述半结构化数据的。同时还会介绍在解析过程中是如何针对JSON和Protocol Buffers的数据以及结构特点建立语法的。

1.3.1语法树的定义

半结构化数据存在以下一些结构特点：

1)数据中存在大量的嵌套结构：每个域的定义是有深度的，和传统的关系型扁平的数据相比更加的复杂；

2)数据中的很多多值域：在一条记录中，可能会有很多个值对其中的某个域进行复制。

3)数据中存在大量的稀疏域：大量的域在大部分的数据中并没有被赋值，而使用传统的关系型数据库以表的方式对其进行处理会使得存储和查询十分的低效。

为了能够高效的描述半结构化数据中每个域的以上特点，同时提高行式和列式的存储以及查询效率，本发明按照如下的定义了填充半结构化数据中语法树的每一个节点：

节点中不但描述了节点本身的相关信息：数据类型，嵌套层次和域中可能被赋值的个数等；还通过SchemaNode语法节点ID将节点相互的关联，形成树型结构。接下来本发明将分别介绍如何在解析过程中为JSON和Protocol Buffers分别建立语法树。

1.3.1JSON语法树的建立

由于JSON并没有数据相关的定义，所以本发明只能在解析数据的过程中通过数据动态的建立语法树。在这里，本发明假设每个域的值的类型是不会改变的且数组中的成员类型都是一致的。在建立语法树的过程中，本发明只需要根据数据中值的类型确定其值的类型。另一方面。由于JSON数据中的每个域在记录中是否出现都是不确定的，所以本发明将值为array的JSON的域定义为repeated重复出现的，其余节点均定义为optional不一定会出现。在解析过程中，STEED需要先根据parent父亲节点ID和field name对应的域名通过符号表查找有无相关的结构定义。如果没有这个节点的定义，则向Schema Tree语法树中添加相关的节点；否则则对这个节点的值进行解析，详细的解析过程请见下一小节。

1.3.2Protocol Buffers语法树的建立，如图5所示：

如下例所示，Protocol Buffers在proto文件中会定义message作为新的数据类型。其中包含的每个域既可以是基本的数据类型，也可以是其他的复合类型的数据。本发明在建树的过程中，首先解析proto文件，扩展新的数据类型；之后再按照用户指定的根节点(root)将这些数据类型的定义逐一扩展并组装成为数据结构的语法树(Schema Tree)。之后本发明就可以按照语法树的定义逐一对每一条文本数据进行解析。

1.4数据解析

在这一小节中，本发明将介绍STEED的数据解析算法。这里本发明忽略了系统中许多底层基础类的实现，仅列出了和文本格式数据解析相关的算法。

由于半结构化数据分别定义了两种复合的数据结构，既对象(object)和数组(array)，所以在解析的过程中，本发明对这两种不同的复合结构使用不同的方法对其分别进行解析。另一方面，对于行式和列式二进制数据的输出，JSON和Protocol Buffers在本发明实现的过程中是一致的，所以接下来本发明首先分别介绍在JSON和Protocol Buffers的解析算法，再说明稍后是如何将其数据输出为二进制行式和列式的数据。

1.4.1JSON数据解析过程算法

如下的算法所示，本发明这里对原子数据类型和复合数据类型采用不同的策略进行解析：对于原子类型的数据，本发明直接根据其文本格式的值转化为二进制格式的数据进行存储或输出；对于复合结构的数据，本发明需要分析并解析其结构直至所有的孩子域都是原子数据类型。之后再按照其行式或者列式

的存储结构将其写入到存储文件中。对JSON文本格式的数据解析过程中，本发明需要对每一个域进行比对，判断其是否是新增的节点，进而修改既有的语法树。

对于半结构化数据中的嵌套结构(上文本框左部分)，首先将同层的域拆分成为“键值对”的形式，之后再按照每个键值对分别进行分析。之后分析每个键的定义是否曾经出现过，若没有出现则更新相应的Schema Tree，同时在Schema Tree中记录对应域的值。之后按照Schema Tree中每个节点记录的值递归进行解析：如果是复合的数据类型，则调用相应的复合结构解析函数继续解析；如果是简单类型的值，则直接将其输出到最后的结果中去。

而对于多值域的数组(上文本框右部分)，由于其表示同一个域的多个重复出现的值，所以本发明仅需要依次调用相应的解析函数对其内容进行解析而不用分析其对schematree的修改。

1.4.2Protocol Buffers数据解析过程算法

对于Protocol Buffers格式的数据而言，文本格式数据的解析过程相对于Protocol Buffers更加简单：由于其在数据解析之前已经定义了数据的格式，所以本发明在解析的过程中不需要检查和修改语法树，仅需要对记录中每个域的值分别进行解析即可。具体的解析方法和JSON类似：复合类型调用相应的解析函数进行解析；简单类型则直接将其值输出到结果中。

1.4.3行式和列式数据的输出算法

在解析的过程中，STEED可以将数据解析成为行式或者列式的二进制格式。这里本发明将介绍其输出为行式或列式格式数据的具体过程：

(1)行式复合类型数据输出算法：

如以上算法所示，对于object和array的复合数据类型，行式结构的数据分别使用其行式结构的对象对每一个域的值进行添加直至整条记录完成了解析。

(2)列式复合类型数据输出算法：

相对于行式结构的数据文件输出，列式结构数据输出的过程中仅需要将其叶子节点上具体的值及其结构信息直接输出到文件中。所以在解析的过程中，本发明不需要保留语义上的的object和array的结构，仅记录其结构相关信

息并输出到列式存储的文件中。这样就会使得输出二进制格式的过程相对简单和高效。

第2部分数据存储模块

在数据解析模块完成数据行式或者列式的解析后，数据存储模块对解析的结果进行存储和一定的结构转换，如行式和列式格式的相互转换，将二进制格式的数据直接以文本格式进行输出等。在这一章中，本发明首先介绍和行式和列式二进制数据的底层存储结构。之后，基于Google Dremel的组装算法，本发明还将说明STEED是如何实现列式结构的数据转化为行式结构数据的组装算法。

2.1行式存储结构概述

在前一章解析过程的描述中，本发明使用原子类型的二进制格式对其数据进行存储；而另两种复合结构object对象和array数组，本发明则按照如图6的方法格式进行存储：

行式和列式的存储结构比较类似，主要由以下的几部分组成：

(1)Header Information结构头信息：记录这个存储结构的相关信息，如存储结构的大小，其中包含的元素个数等。

(2)(ID)OFFSET Array ID和偏移量数组：对于object对象而言，本发明需要标记其中每个域的id用于表示其值的存在；而对于array数组，其中的每个值都是相同的域的赋值，所以其仅保留了每个值的offset偏移量信息。

(3)Value Array数值的数组：行式的存储结构都将values重复出现的数值存储为数组的形式进行存储，其中值的类型既可以是原子类型的数据，也可以是复合类型的数据。在object对象中，由于表示的是不同域的赋值，所以每个值的类型可以不相同；但在array数组中，表示的是相同域的多个赋值，所以这里本发明默认每个值的类型都是相同的。根据之前每个值的offset偏移量信息，本发明可以对任意的域的值进行随机访问。

2.2列式存储结构概述

列式存储结构相对于行式结构相对复杂，本发明定义了如下的相关概念用于在列式结构上表示并存储其结构信息：

(1)Repetition Level:Repeated value repeat at which field in thefield’s path.数据中的重复是在哪一个层次上进行的重复。

(2)Definition Level:Number of field in the path could be undefinedbut present.数据中可以省略的域(optional和repeated)有几层是出现的。

关于列式结构的数据如何使用这些相关的信息进行列式到行式数据转换的过程详解下一小节，这里本发明仅介绍其在行式结构数据中的存储结构。

CAB(Column Align Block)是本发明列式存储的基本单元。在解析过程中，每个值(value)都会产生一条Column Item(列数据项)存储在CAB中。因为半结构化数据中会有很多重复的域,每个重复的域可能会导致一条记录中会有多条Column Item插入到CAB中。本发明为了提高存储和查询的效率，对CAB使用record id对齐的方式进行存储，每个CAB都存储相同多的record记录而不考虑具体的column item的条数。

图7中列出了CAB的具体的结构图。主要由以下四部分构成：

(1)Header头信息：用于描述CAB的相关信息，包括其大小和存储的记录条数等。

(2)Repetition Array数组:用于记录每条Column Item的repetition值。因为repetition的最大值为每个域的最大深度，所以这里本发明使用若干bit代替整数来存储其值。通过对数据内容的分析，本发明总结了以下几种template来对其可能出现的模式进行总结和优化，如图8所示。

a)None Repeated非重复的域:嵌套层次中没有可以重复的域，记录中这个域最多只有一个值，既没有重复赋值的情况。STEED在解析的过程中如果某些域没有值时会插入null使得每条记录能够自然对齐。这样，每条记录有且只有一条column item在对应的列式数据文件中。因此，本发明在存储结构中省略了这个数组。

b)Single Repeated只会在某个嵌套层次进行重复：嵌套层次中有且仅有一个可以重复的层次。本发明仅需要标记每条记录的第一条Column Item(Record Boundary)。所以本发明仅需要1bit去标记每条记录的第一条Column Item或者其唯一重复的嵌套层次。

c)Multi Repeated会在多个嵌套层次进行重复：如果从根到叶子节点中存在多个可以重复的域，本发明就需要多个比特指出其重复的域。

在对数据进行了具体的分析后，本发明发现绝大部分的域都是最多只会在一层上重复。所以通过使用这3个template模板进行存储，本发明的列式存储结构提高了存储和操作的效率。

(3)Value Area数值区域：这一部分记录了全部Column Item的值。对于变长和定长的两种数据格式，本发明使用了两种不同的存储策略：

a)定长的数据类型：每个数据的长度一样，所以本发明在Header中记录了每个值所占用的空间，每次只需要移动固定的长度即可读取下一个数值；不需要额外的offset数组。

b)变长的数据类型：每个数据的长度不一样，所以本发明需要在offset数组中记录每个值的存储位置；对于值的内容大量重复的域(例如用户语言等)，我们仅存储一个具体的变长值，通过在不同的column item中复用该具体值的offset提高其存储的效率。

2.3行式和列式格式转换算法

在这一部分中本发明将介绍在存储模块行式和列式文件相互转化的算法。对于行式数据文件而言，每一个半结构化数据集在解析完成之后都会生成一个行式数据文件存储所有记录中的全部域值和相关的结构信息。另一方面，对于列式数据文件而言，每个文本数据集会产生若干个列式存储文件。每个域都会产生一个列式存储文件存储全部记录的这个域的所有的值。这样在运行过程中，存储模块就需要实现存储数据的行列格式转换操作。同时，也需要实现满足直接将数据输出为JSON文本格式的需求。

2.3.1行式到列式的数据解析

行式结构数据到列式结构数据的转换过程与文本结构数据解析的过程相似，这里不再赘述。由于在解析过程中不需要对文本数据的结构进行字符的匹配，而使用已经解析好的行式的object或array的存储结构；同时不需要进行文本格式数据到二进制的格式转换，行式到列式结构转换的效率要明显优于字符解析的效率。

2.3.2列式到行式的数据组装

将列式数据文件按照一定的规则组装成行式格式的文件就可以完成列式结构的数据转化为行式结构的数据。基于Google Dremel的组装算法，这里本发明在STEED内部使用类似的算法完成对列式文件的组装。具体算法如下所示：

在组装过程中，STEED按照有限状态自动机的顺序和Column Item中的repetitionvalue从Column Reader(列式数据读取器)中读取Column Item，之后再根据definitionvalue判断并输出相应的嵌套层次信息。当读取的最后一个Column Reader读完本条记录的最后一个Column Item时，既遍历完成所有的Column Reader，Assembler组装器就完成了一条记录的组装。Assembler组装器会不断的运行，直到所有的记录都完成组装，此时所有的Column Reader都应读取到文件结尾EOF。

在以下的算法中，除了具体的组装过程AssembleRecd，move和return两个函数分别使用definition value判断数据的嵌套层次的结构信息。

在如下的伪代码中，本发明需要从根节点开始使用深度优先算法遍历schematree，之后按照其叶子节点出现的顺序对列式文件进行排序，按照排序后的顺序依次读取各个列式文件中column item的内容。根据读取的的column item的内容，本发明可以控制数据嵌套的层次结构信息：首先输出当前列中表示嵌套结构的相关信息，之后将值输出到待组装的行式结构中，然后再判断要跳转并读取的下一个列文件，最后从下一列中预读一条column item判断需要返回的嵌套层次的层次并输出相关的结构信息。当所有的列式文件都至少完成一次的读取后，本发明就完成了一条记录的组装。重复以上的过程，直到所有的列式文件都读完，本发明就完成了对整个数据集合的组装。

第3部分查询分析模块

基于行式和列式结构的数据，STEED可以进行类似于SQL的查询分析。但是相比于传统的表结构的关系型数据，半结构化数据的由于其存在嵌套和多值域而导致其在查询时会存在一定的歧义。为此本发明扩展了查询的语法，使其在一定程度上能够消除数据歧义。本发明还实现了SQL中一些基本的运算，如projector映射，filter过滤，group by分组和sort排序等。在本章中，本发明首先介绍针对半结构化数据的扩展后的语义。之后，针对系统中已经实现的多种半结构化数据的运算，本发明会依次介绍其实现的具体算法。

3.1SQL针对半结构化数据的语义扩展

传统的关系型数据使用表结构存储扁平的数据：所有的值都在同一层，不存在嵌套子结构；每个域有且只有一个数值能给其赋值；在设计表时会拆分表，使其不会存在大量的稀疏的域。而对于半结构化数据而言，其以上的这些特点都不适用。而为了支持半结构化数据的操作，本发明新定义了如下的一些运算符：

(1)“.”：用于间隔域的路径表达式中的嵌套层次。

(2)“any”：表示重复的域中任意的一个数值；

(3)“all”:表示重复的域中所有的数值。

输出的结果本发明有多重的选项：

(1)JSON格式的数据：

(2)忽略嵌套结构的类JSON数据；

3.2STEED支持的运算类型

如图9所示，STEED支持基于行式和列式数据的多种类型的运算。在各个operator之间，数据使用pull的方式依次流动，直到在顶层的output operator完成从二进制的到文本格式数据的转换。接下来，本发明会依次介绍其内部的各种实现细节。

3.2.1Row From Operator(行式数据读取运算)

STEED从行式的数据文件中读取一整条行式结构的数据。由于每一条记录在行式数据文件中是按照记录为单位进行的存储，每条记录都是以Row Object行式对象为存储的格式进行存储的。所以在读取记录时，本发明每次都从行式二进制数据文件中读取一个RowObject行式对象依次进行读取，直到到达文件结尾EOF。

3.2.2Schema Filter(Where or Having Clause)Operator(基于schema定义的where和having字句中的过滤运算)

在这个Operator中，本发明对行式数据进行filter过滤操作。这个操作可以用于STEED在读取行式数据之后，对其进行where字句中的条件进行判断；而在group by字句中生成新的行式的数据之后，也可以使用其对aggregation聚集的结果进行过滤操作。

在具体的filter过滤操作过程中，本发明定义了RowCondition(行式条件类)用于判断记录中相关的域是否满足每一个谓词(predicate)的条件。具体的判断过程如下所示：

本发明首先对where字句进行解析，将每一个谓词实例化为可以进行数据比较的对象：可以从行式数据结构中读取数据；之后对读取的值进行比较，判断每个谓词(predicate)的真值，决定其是否通过这个operator中的条件运算。

3.2.3Project Operator(映射运算)

在行式结构的数据中本发明存储了每条记录中所有的域，但是大部分的查询语句仅需要一些域的值即可。这样在整个的查询过程中，就会有大量的于查询无关的域的数据在各operator运算间拷贝了多次。这些额外的内存拷贝会降低本发明查询的效率。所以本发明对行式结构的数据实现了projector运算用于提取和查询相关的域，这样在拷贝过程中仅拷贝了查询相关的域从而提高了查询的效率。

在运算过程中，本发明使用调用递归函数应对半结构化数据中的嵌套结构。在每一个域中，本发明分别读取原数据中该域的赋值，对其进行解析之后仅将和查询相关的域写入到运算的结果中。这样就能忽略行式数据中大量的无关的域，提高查询过程的效率。对于多值域，如果其在叶子节点重复，STEED仅需要直接拷贝这个域的数组中连续存储的多个值。如果在非叶子节点重复，则对以每一个数组中的子结构分别递归及解析。需要注意的是，在提取子树的过程中，本发明仅保留了被赋值的子树；既，如果这个子树中的相关的域没有被赋值，则在projector的结果中这个子树将不会被保留。

3.2.4Assemble Operator(列式到行式数据的组装运算)

在这个operator运算过程中，STEED完成了将查询相关的域从行式结构数据转化为列式结构数据的组装过程。具体的组装算法请见之前。STEED首先通过Query Parser查询语句解析器解析需要执行的SQL语句得到所有和查询相关的域，使用其建立一个有限状态自动机(FSM)以控制在组装过程中行式结构数据的读取顺序。之后按照先前的组装算法完成从列式到行数数据的格式转换，这里不再赘述。

3.2.5Column Filter Operator(提供过滤操作的列式到行式数据的组装运算)

相比于Assembler operator(列式到行式数据的组装运算)，Column FilterOperator(提供过滤操作的列式到行式数据的组装运算)不但实现了列式结构到行式结构的组装，还能在组装过程中对每个记录进行filter过滤操作。由于在查询过程中，where子句会过滤掉一些不满足条件的记录，所以如果本发明在组装过程中不组装这些无效的记录，会极大的提高查询效率。所以在查询过程中，本发明每次读取一个CAB进行filter过滤操作并设立相应的bit map位图记录其比较的结果，最后根据记录的结果中再决定是否进行组装。

3.2.6Join Operator(连接运算)

STEED中使用hash join(哈希连接)实现连接操作，现阶段仅支持两个表的连接操作。在执行这个操作的过程中，STEED根据其中一个数据集记录中的join key具体值计算其对应的哈希值并将整条记录存储在哈希表中。稍后遍历另一个数据集合，查找具有相同hash key哈希键的对应哈希表中的位置(bucket)。之后将这两个行式结构的数据进行合并，并等待这条记录被pull(拉)到上一层的operator运算。现阶段STEED并没有使用关系型数据库中查询优化器进行优化，故而在查询过程中建议将较小的数据集作为from子句中第一个出现的数据集，以得到较高的存储效率。

3.2.7Group Operator(分组运算)

在查询操作现阶段所支持的内部操作中，Group分组是最复杂的操作。本发明将会介绍在运算过程中一些新定义的类，并对相应的执行过程进行分析。和join operator连接操作类似，group operator分组操作使用hash table哈希表存储相应的group key分组的键值。在运算的过程中，首先由从行式结构的数据中读取数据，计算其hash key哈希值并添加到哈希表中。之后再根据需要判断其有无aggregation聚集运算对hash value哈希值中的内容进行运算。其中hash value哈希值的数据存储结构如图10所示：

本发明首先定义了HashValueItemContainer用于存储每个在哈希表中的每一个存储单元(bucket)，哈希表中具体的value值为指向这些HashValueItem的地址。每个这样的对象都有如图10所示的结构：

(1)本发明首先在中间层保存记录存储的具体地址和每个需要计算的aggregation聚集的内容。

(2)在Block Buffer对象中，存储了被保存的记录的实际内容。需要指出的是，这些记录除了那些grouped field基于值进行分组的域，都是没有被赋值的表示aggregation聚集结果的域。当整个group分组运算完成之后，本发明再将aggregation聚集的结果输入到相应的位置，并等待结果被上层的其他operator操作pull拉起。

3.2.8Order Operator(排序操作)

对于order by排序操作运算，本发明需要将所有的记录存储到buffer缓存中，之后对其比较排序。考虑到内存空间分配效率的问题，本发明每次仅向操作系统申请固定大小的内存，这样可以省去realloc重新分配内存中过程中内存拷贝的代价。同时，为了避免在排序过程中多次拷贝数据的代价，本发明在比较过程中使用一个数组记录每条记录的起始地址并在排序过程中改变指针在数组中的位置。最终达到对这个数组顺序访问时，访问到的记录都是满足排序要求的结果。

此外根据排序的条件，本发明定义了comparer比较器用比较记录，其按照如下的方式进行运算：

(1)这个comparer比较器可以从行式存储结构中读取所有域的数值用于比较操作。

(2)为了提高比较效率，本发明如下实现了比较及输出的过程：

a)在每条记录中保留了8字节存储第一个需要比较的域中数据的高8位。对于所有的数值类型而言，这个空间足以存储其对应的值而不需要复杂的对行式结构的数据进行取值；对于字符串而言，前8位的比较在大多数情况下也能得到确定的比较结果。所以在比较过程中，本发明先使用缓存的这8字节进行比较。当数据的类型为字符串且前缀的比较相同时，本发明才会进行下一步比较。

b)使用comparer比较器根据需要排序的域的顺序，依次取值并进行排序，直到得到比较的结果。

c)具体的比较函数的实现本发明使用STL::sort函数进行比较。

d)在比较过程中没有对记录的本身进行数据拷贝，只修改了记录输出顺序的指针数组，这样避免了内存的多次拷贝操作。而在被上层operator操作pull拉数据的过程中，本发明也仅提供了对应的指针，以提高其数据处理的效率。

第4部分利用简单路径特征优化树状结构数据的方法及系统

在这一部分中，本发明根据现有多种数据来源的相关数据，总结并归纳出了简单路径的概念，并且在STEED中利用该特征进行了查询优化

4.1简单路径的定义

在分析了多种不同来源的数据，我们发现在各数据集的语法树中，存在着大量的从根到叶子节点最多只有一个重复域的路径。本发明在查询的过程中可以利用这些数据中的结构特点优化查询过程、提高查询效率。所以，本发明对简单路径定义如下：在数据集的语法树中，从根到叶子节点的路径上最多只能存在一个域(语法树中的某个节点)是多值的，我们称这样的路径为简单路径。STEED中可以利用简单路径对树状结构数据进行存储及查询过程相关的优化。

4.2半结构化数据行式存储的结构

如前所述，STEED在行式存储结构中为了准确表达树状结构数据中的层次信息使用了相对复杂存储结构。经过分析，本发明认为从数据的表达上看，已经不能对其进行进一步的优化和改进。但是通过以上简单路径的分析可知，本发明可以通过简化数据中存储的结构信息以提高数据在系统内部的表示效率，使得其解析和查询的效率有进一步的提升。本发明设想的更好的行式存储结构如图11所示:对于简单路径的数据，STEED可以在数据中仅存储叶子节点(域)的相关结构信息来代替原有的嵌套存储结构来指代相应的路径。而使用简单路径进行优化之后，STEED可以利用数据中叶子节点的相关信息从系统中的语法树(Schema Tree)获得整个路径上所有节点的相关信息。这样，STEED通过简化数据中存储的结构信息提高了行式数据的表达效率和查询的执行效率。

4.3Flatten Assemble(扁平行式结构组装器)

STEED在数据的组装过程中，需要花费大量代价来恢复数据的层次结构。如前所述，在大多数的数据集中的域中重复的层次都不超过2层，所以数据中绝大部分的值都可以利用简单路径进行相应的优化。而STEED中对于简单路径的域的组装过程则更加的简便：

使用Flatten Assembler扁平行式结构组装器忽略默认二进制数据中的层次关系，既仅使用叶子节点表示从根节点到叶子节点的路径而忽略路径中所有的非叶子节点。这样，本发明就实现了将行式结构数据的嵌套层次限制为一层的目的，从而在数据查询的过程中节约了数据在内存中的空间消耗并且提高了数据的查询效率。

具体的组装算法如上所示：

在组装之前，需要对待组装的每一个列按照叶子节点的ID进行相应的排序。之后，依次按照顺序读取每个Column Reader中每条记录的所有Column Item，依次将读出的数值和相关的结构信息写入到组装的结果中去。这里由于组装的结果仅保留了一个嵌套的层次，所以在组装过程中STEED只需要将每个域的值追加到当前的对象中，而不需要考虑组装结果的嵌套关系。

4.4扁平行式数据的存储结构

本发明中，STEED在查询过程使用扁平结构的行式数据进行查询和存储等方面的优化。对于语法树中的非简单路径，由于STEED需要识别数据中不同嵌套层次的多值域，本发明继续使用系统默认的树状结构数据的表达方法。而对于简单路径，本发明使用如图11的结构对其进行存储或组装：

1)语法树中从根到叶子节点的路径上没有重复节点的域：扁平数据存储结构中仅需要存储叶子节点的ID和相应域的数值；

2)语法树中从根到叶子节点的路径上只有一个重复节点的域：扁平数据存储结构中可以按照以下两种结构进行输出，详见图12：

a)将每个重复域的数值都作为一个具体的值存储在扁平结构中----数据中会有多项有相同ID的值，其个数决定于重复域的个数；

b)将重复的域作为一个整体存储在扁平结构中----数据中仅有一个重复域的ID表示其具体的值，而这个域是由一个数组形式的结构表示多个数值。

3)语法树从根到叶子节点的路径上有多个重复的节点：扁平数据存储结构无法表达路径上多个可重复的域的数值是在哪一层上发生的重复，本发明中继续使用原有的默认的树状数据存储结构----扁平结构的数据中依然使用叶子节点的ID，但是相应的值为偏移量，指向存储完整嵌套结构的位置。

本发明提出一种利用简单路径特征优化树状结构数据的系统，包括：

简单路径模块，用于设置简单路径，其中所述简单路径为在数据集的语法树中，从根节点到叶子节点，最多只能存在一个多值的域的路径；

获取数据模块，用于通过存储所述简单路径中叶子节点的相关结构信息，获取原有嵌套存储结构中的数据；

组装模块，用于对所述简单路径中叶子节点进行组装，其中忽略默认二进制数据中的层次关系，仅通过叶子节点表示从根节点到叶子节点的路径而忽略路径中所有的非叶子节点。

利用数据集中叶子节点的相关信息从语法树中获得整个简单路径上所有节点的相关信息。

在组装之前，对待组装的每一个列数据按照叶子节点的ID进行相应的排序，之后，依次按照顺序读取每个Column Reader中每条记录的所有Column Item，依次将读出的数值与相关的结构信息写入到组装的结果中。

对于语法树中的非简单路径，识别数据中各嵌套层次的多值域。

本发明系统使用如图11的结构进行存储或组装，具体如下所示：

2)当语法树中从根节点到叶子节点的路径上只有一个重复节点的域：按照以下两种结构进行输出：

a)将每个重复域的数值都作为一个具体的值存储在扁平结构中，其中，数据中会有多项有相同ID的值，其个数决定于重复域的个数；

b)将重复的域作为一个整体存储在扁平结构中，其中数据中仅有一个重复域的ID表示其具体的值，且所述重复域是由一个数组形式的结构表示多个数值；

3)语法树从根节点到叶子节点的路径上有多个重复的节点：使用默认的树状数据存储结构，其中扁平结构的数据中依然使用叶子节点的ID，ID表示为偏移量，指向存储完整嵌套结构的位置。

Claims

1.一种利用简单路径特征优化树状结构数据的方法，其特征在于，包括：

2.如权利要求1所述的利用简单路径特征优化的树状结构数据处理方法，其特征在于，利用半结构化数据定义中叶子节点的相关信息从语法树中获得整个路径的结构信息。

3.如权利要求1所述的利用简单路径特征优化的树状结构数据处理方法，其特征在于，对列式结构树状数据组装为行式结构数据之前，对待组装的每一条列式结构的路径按照叶子节点的ID进行相应的排序，之后，依次按照顺序从每个列式数据读取器中读取中每条记录所有的列数据项，依次将读出的数值与相关的结构信息写入到组装的结果中。

4.如权利要求1所述的利用简单路径特征优化树状结构数据的方法，其特征在于，对于语法树中的非简单路径，依然按照树状结构数据典型的使用多层嵌套结构表示其结构和数据的方法进行存储。

5.如权利要求3所述的利用简单路径特征优化的树状结构数据处理方法，其特征在于，包括：

1)当语法树中从根节点到叶子节点的路径上没有多值节点的域：仅需要存储叶子节点的ID与相应域的数值；

2)当语法树中从根节点到叶子节点的路径上只有一个多值节点的域：按照以下两种结构进行存储：

3)语法树从根节点到叶子节点的路径上有多个多值节点的域：使用默认的树状数据存储结构，其中在扁平结构的数据中存储的ID为路径上嵌套层次为1的ID，其对应的偏移量指向存储完整嵌套结构的位置。

6.一种利用简单路径特征优化的树状结构数据处理系统，其特征在于，包括：

7.如权利要求6所述的利用简单路径特征优化树状结构数据的系统，其特征在于，利用半结构化数据定义中叶子节点的相关信息从语法树中获得整个路径的结构信息。

8.如权利要求6所述的利用简单路径特征优化树状结构数据的系统，其特征在于，对列式结构树状数据组装为行式结构数据之前，对待组装的每一条列式结构的路径按照叶子节点的ID进行相应的排序，之后，依次按照顺序从每个列式数据读取器中读取中每条记录所有的列数据项，依次将读出的数值与相关的结构信息写入到组装的结果中。

9.如权利要求6所述的利用简单路径特征优化树状结构数据的系统，其特征在于，对于语法树中的非简单路径，依然按照树状结构数据典型的使用多层嵌套结构表示其结构和数据的方法进行存储。

10.如权利要求8所述的利用简单路径特征优化树状结构数据的系统，其特征在于，包括：

3)语法树从根节点到叶子节点的路径上有多个多值的节点：使用默认的树状数据存储结构，其中在扁平结构的数据中存储的ID为路径上嵌套层次为1的ID，其对应的偏移量指向存储完整嵌套结构的位置。