CN102831120A

CN102831120A - 一种数据处理方法及系统

Info

Publication number: CN102831120A
Application number: CN2011101606301A
Authority: CN
Inventors: 张书彬; 赵彦荣; 郭玮; 李均; 赵伟; 洪坤乾; 徐钊
Original assignee: Tencent Technology Shenzhen Co Ltd
Current assignee: Tencent Technology Shenzhen Co Ltd; Tencent Cloud Computing Beijing Co Ltd
Priority date: 2011-06-15
Filing date: 2011-06-15
Publication date: 2012-12-19
Anticipated expiration: 2031-06-15
Also published as: CN102831120B

Abstract

本发明公开了一种数据处理方法及系统，包括：在基于映射/化简框架完成对结构化查询语言查询的处理和计算，数据存储任务由分布式文件系统完成的数据处理中，将数据表定义为采用哈希分区的方式，并在哈希分区中存储数据；在确定所需执行的查询为连接查询或分组查询，且源数据表为哈希分区数据表、连接键或分组键为分区列时，将该查询修改为在映射端以哈希分区为单位的连接查询或分组查询后执行查询。本发明可以减小连接查询和分组查询的开销，实现节约网络带宽、磁盘带宽和网络资源，提高了计算效率。

Description

一种数据处理方法及系统

技术领域

本发明涉及一种数据处理方法及系统。

背景技术

对于基于Map/Reduce（映射/化简）框架对SQL（Structured Query Language，结构化查询语言）查询进行处理和计算的数据处理系统来说，数据存储任务由分布式文件系统完成。在Map/Reduce框架中，针对客户端提交的数据处理任务，可以首先将该数据处理任务拆分成若干个Map任务，分配到不同的机器上执行，每一个Map任务将查询输入文件的一部分作为自己的输入，并通过计算生成中间文件；与此同时，系统会生成若干个Reduce任务，并分配到不同的机器上执行，从而将Map任务生成的中间文件拉取到相应的Reduce任务本地进行计算处理后，汇总到最终的输出文件中去。

在该种数据处理系统处理的SQL查询中，Join（连接）查询和Groupby（分组）查询占较多的比重。在进行Join查询时，通常需要使用一个完整的Map/Reduce作业来完成。具体地，在Map阶段，各个Map任务分别读取参与Join计算的两个（或多个）数据表的部分数据，并将读取到的数据按照要连接的key（键）分别转发到相应的Reduce任务上去；在Reduce阶段，Reduce任务在获取Map任务转发的键值对后，根据键值对所属的数据表进行分类并按key进行排序，生成与上述两个数据表分别对应的两个键值对的有序列表，并对两个有序列表进行连接操作。

在对数据表进行Groupby操作时，Map/Reduce框架需要通过Map任务从数据表中读取数据，并根据Groupby键将读取到的数据分发到Reduce任务，Groupby键相同的键值对映射到同一个Reduce任务，从而在Reduce任务中对排好序的键值对执行Groupby操作。

此外，为了方便、快速地读取数据表中用户查询涉及到的列，有些该种数据处理系统支持对数据表中的数据的按列存储，因此，对于同一个数据表中的数据而言，即使位于同一行，也可能因为属于不同列而位于不同的文件中，从而被分布式文件系统保存到不同的节点上。因此，对采用列存储的数据表进行查询时，可能需要从多个节点读取数据，进行查询和最后结果的整合。

现有技术存在以下不足：

现有技术在进行Join查询和Groupby查询时开销比较大，以及查询按列存储的数据表时开销较大。

发明内容

本发明所解决的技术问题在于提供了一种数据处理方法及系统，用以减小Join查询和Groupby查询的开销，以及对列存储数据表的查询开销，提高数据处理系统的计算效率。

本发明实施例中提供了一种数据处理方法，包括如下步骤：

在基于映射/化简Map/Reduce框架完成对查询的处理和计算的数据处理中，将数据表定义为采用哈希Hash分区的方式，并在Hash分区中存储数据；

在确定所需执行的查询为连接查询或分组查询，且源数据表为Hash分区数据表、连接键或分组键为分区列时，将该查询修改为在Map端以Hash分区为单位的连接查询或分组查询后执行查询。

本发明实施例中提供了一种数据处理系统，包括：

存储引擎，用于在基于Map/Reduce框架完成对查询的处理和计算的数据处理中，将数据表定义为采用哈希Hash分区的方式，并在Hash分区中存储数据；

查询引擎，用于在确定所需执行的查询为连接查询或分组查询，且源数据表为Hash分区数据表、连接键或分组键为分区列时，将该查询修改为在Map端以Hash分区为单位的连接查询或分组查询后执行查询。

本发明有益效果如下：

在本发明实施例提供的技术方案中，在基于Map/Reduce框架完成对SQL查询的处理和计算，数据存储任务由分布式文件系统完成的数据处理中，将数据表定义为采用Hash分区的方式，并在Hash分区中存储数据；在确定所需执行的查询为Join查询或Groupby查询，且源数据表为Hash分区数据表、连接键或分组键为分区列时，将该查询修改为在Map端以Hash分区为单位的Join查询或Grouby查询后执行查询。本方案中，为分布式数据仓库增加Hash分区的分区方式，将数据按照Hash分区键映射到不同的Hash分区保存，由于键相等的数据均已被映射到同一个Hash分区中，因此，对于Join查询和Groupby查询而言，可以将Hash分区作为Map任务的划分依据，每个Hash分区由一个Map任务处理，在Map端完成数据的处理操作，从而达到节约网络带宽、磁盘带宽和网络资源，提高计算效率的目的。

附图说明

图1为本发明实施例中的数据处理方法实施流程示意图；

图2为本发明实施例中的数据表入库时的Hash分区流程示意图；

图3为本发明实施例中的数据协同摆放示意图；

图4为本发明实施例中的新节点加入时的数据协同摆放示意图；

图5为本发明实施例中的Join查询转换为Map端进行的Join计算的实施流程示意图；

图6为本发明实施例中的以数据表a和数据表b为例的Join查询转换为Map端进行的Join计算的实施流程示意图；

图7为本发明实施例中的以数据表a和数据表b为例的Join查询流程图；

图8为本发明实施例中的数据处理系统结构示意图。

具体实施方式

发明人在发明过程中注意到：

由于Map/Reduce结构的基本工作原理的内在原因，导致其在查询中比重较多的连接（Join）查询和分组（Groupby）查询需要通过网络拉取大量的数据并在Reduce端进行计算。而在集群系统中网络带宽是比较稀缺的资源，并且，Reduce任务的执行开销也相对较大。因此，如果能把在应用中使用较多的Join查询和Groupby查询转换成在Map端进行的计算将在很大程度上节约带宽、计算资源和磁盘I/O。

因此，发明人认为：通过实现Hash分区，将数据分而治之是在Map端完成计算的必要手段。

而就Join计算而言，通过实现Hash分区，可以将Join计算转换为Map端进行的计算，因为相同的键（key）值（需要与Hash分区的分区key一致）必然位于同一个Hash分区中，而且，还可以通过控制Hash分区的数目控制Map Join计算的粒度来进一步优化对计算资源的利用。

就Groupby计算而言，通过Hash分区，可以将相关的key集中到同一个Hash分区中，此外，通过入库操作，可以将相同key的数据有序的存放在一起，这可以看做Groupby操作的预处理操作。

最后，通过Hash分区以及本发明实施例中将提供的Co-Location（协同摆放）功能，可以实现数据的统一摆放，属于同一Hash分区的数据可以摆放到相同的节点上，此时再进一步通过有效地调度手段，可以将任务调度到数据所在的节点可以使得在Map端完成Join操作和Groupby操作时的效率更高，网络I/O更少。Co-Location功能还能优化对采用列存储方式的数据表的查询性能。

基于以上发明构思，下面将结合本发明中的附图对本发明的具体实施方式进行说明。

图1为数据处理方法实施流程示意图，如图所示，在基于Map/Reduce框架完成对SQL查询的处理和计算，数据存储任务由分布式文件系统完成的数据处理中，可以包括如下步骤：

步骤101、将数据表定义为采用Hash分区的方式，并在Hash分区中存储数据；

步骤102、在确定所需执行的查询为Join查询或Groupby查询，且源数据表为Hash分区数据表、连接键或分组键为分区列时，将该查询修改为在Map端以Hash分区为单位的Join查询或Grouby查询后执行查询。

一个市场上可买到的可在其上实现本发明（以及相关发明）实施例的基于查询引擎、Map/Reduce计算框架和分布式文件系统相关技术提供海量数据存储和计算服务的分布式数据仓库解决方案是来自腾讯公司的TDW（Tencent distributed Data Warehouse，腾讯分布式数据仓库）。在下述实施方式说明中将主要以TDW为例进行说明，以TDW为例进行具体说明是因为腾讯公司在数据处理业务上的领导地位所决定的，该方案也是目前许多分布式数据仓库的主要解决方案之一，当以其为例时，经过相应的改进后便可以很容易的用于其他具有相同工作原理的数据处理系统。然而注意，尽管相关发明和本发明的讨论大多都是关于TDW的，但具有创造性的概念适用于提供类似功能的其他类型的数据处理框架，因此对TDW的引用仅作为示例而不起限制的作用。

具体的，TDW是一套符合腾讯的业务需求的、使用基于查询引擎、Map/Reduce计算框架和分布式文件系统相关技术提供海量数据存储和计算服务的分布式数据仓库解决方案，也是目前许多分布式数据仓库的主要解决方案之一。分布式数据仓库中经常需要对T/P级的海量数据进行分析处理，这些数据逻辑上通常以表（Table）的形式展现给用户，具体存储格式可以是文本文件、结构化存储文件或者列存储文件。为了方便查找和分类，数据表可能采用范围分区（Range Partition）或者列表分区（List Partition）的方式组织，分区层次可能是单层或者两层。

下面对各要点的具体实施方式进行说明。

一、在Hash分区中存储数据的处理。

实施中，在Hash分区中存储数据时，可以按如下方式进行处理。

数据按照Hash分区键映射到不同的Hash分区保存，Hash分区键为常用的Join键或Groupby键。

具体的，在数据入库时，可以根据数据的Hash分区键（例如，列）计算数据的Hash值，并根据计算得到的Hash值将数据映射并存放到对应的Hash分区，Hash值相同的数据被映射到同一个Hash分区中。使用Hash分区的数据表会将Hash分区作为一个目录层次，将相应的数据表根据Hash分区进行分割后，分别保存到不同的Hash分区目录中。Hash分区可以完全对应用透明，用户无法获知Hash分区的具体划分方式，通常无法专门针对某一个Hash分区进行查询，也无法指定对某个Hash分区的数据或者元数据进行修改。

以TDW为例，TDW系统中允许按照Range（范围）或List（列表）对数据表进行分区，根据Hash分区的特点和含义，可以认为Hash分区可以作为最低一级分区。因此，可以将Hash分区作为最低一级分区。具体地，如果数据表含有两级分区，则Hash分区可以作为二级分区；如果数据表只有一级分区，则该分区可以是Range分区或List分区，也可以是Hash分区。

与TDW系统现有的分区方法不同，本发明实施例中的Hash分区需要进行Reduce端的计算。假设数据表的一级分区是Range分区或List分区，二级分区是Hash分区，图2为数据表入库时的Hash分区流程示意图，如图所示，可以包括以下步骤：

步骤201，创建使用Hash分区的数据表。

具体地，针对入库数据，可以在数据仓库中预先创建使用Hash分区的数据表table1_t，table1_t在创建完毕后的初始状态为空表，用于按照Hash分区存储入库数据。

步骤202，接口机接收用户上传的源数据文件。

其中，接口机位于TDW系统和用户之间，用户可以通过接口机上传源数据文件和下载查询结果，源数据文件中包含入库数据。

步骤203，TDW创建关联源数据文件的外表。

具体地，可以在TDW中创建与源数据文件关联的外表ext_table0，并将源数据文件中的入库数据映射到该外表中。

步骤204，向查询引擎提交用于数据入库的SQL语句。

其中，查询引擎可以为TDW系统中的独立节点，可以通过ETL（Extract-Transform-Load，抽取-转换-装载）模块向查询引擎发送SQL语句，该语句用于将外表中的入库数据导入到经过Hash分区的数据表中，可以具体为：from ext_table0 insert into table1_t select *；其中，ext_table0为外表，table1_t为经过Hash分区的数据表。

步骤205，查询引擎将SQL语句转换为Map/Reduce任务，并将该任务转发给Map/Reduce框架中的主控节点。

其中，Map/Reduce任务可以包含多个Map任务和Reduce任务。

步骤206，主控节点将接收到的Map/Reduce任务分配到多个从节点。

其中，主控节点与从节点一起构成TDW系统的Map/Reduce框架（即计算引擎），其中，主控节点可以为TDW系统中的独立节点，用于接收查询引擎发送的数据处理任务，并将该任务分配到从节点；从节点用于执行主控节点分配的任务。

步骤207，从节点执行主控节点分配的任务，将外表中的入库数据导入到经过Hash分区的数据表中。

具体地，接收到主控节点分配的Map任务的从节点为Map端，接收到主控节点分配的Reduce任务的从节点为Reduce端。Map端根据自身对应的Map任务从外表读取数据，并根据Hash分区键确定读取到的数据行对应的Reduce任务；Reduce端根据自身对应的Reduce任务，从Map端拉取归其处理的键值对，抽取键值对中的Hash分区键，并根据该Hash分区键计算数据的Hash值，根据计算得到的Hash值确定数据所归属的Hash分区，将该数据写入到对应的分区目录。

在上述执行Map/Reduce任务的过程中，每个Reduce任务可以对应相同数量的Hash分区，以便每个Reduce任务可以尽可能处理相当的数据量，因此，Reduce任务的数目可以小于或等于Hash分区数，且可以整除Hash分区数，也就是说，一个Reduce任务可以对一个或多个Hash分区进行写操作。

此外，实施中，在Hash分区中存储数据时，还可以进一步包括：

在入库的Map/Reduce作业中将Hash分区键设置为Map/Reduce任务的sort key。

具体的，在数据入库的Map/Reduce作业中，还可以将Map/Reduce任务的排序键（sort key）设置为Hash分区键，由于排序键用于对Map任务计算得到的中间结果进行排序，通过将排序键设置为Hash分区键，可以对同一Hash分区内的数据对应的中间结果使用同一排序键进行排序，实现数据的按序存放。

二、数据协同摆放（Co-Location）策略。

实施中，进一步的，还可以将同一Hash分区的数据或保存到不同列存储文件的同一逻辑文件的数据存放在相同的节点。

实施中，上述Hash分区只是在逻辑上实现了相关数据的聚合，为了实现从逻辑聚合到物理聚集的转变，还可以进一步使用数据协同摆放技术，具体地，在向分布式文件系统存放数据块时，可以按照Hash分区或逻辑文件为单位进行数据协同摆放，将同一Hash分区的数据块存放到相同的节点上；对于没有保存到Hash分区中的列存储文件，可以将属于同一个逻辑文件（但可能属于不同列存储文件）的数据块存放到同一个节点，从而达到相关数据的物理聚合。TDW系统的数据协同摆放功能可以对用户完全透明。

TDW系统管理的数据位于分布式文件系统中，分布式文件系统包括主节点和数据节点，其中，数据节点用于存储数据，主控节点可以为分布式文件系统中的独立节点，用于控制数据节点存储数据。分布式文件系统中数据节点可以同时是Map/Reduce框架中的从节点，即，该节点既可以存储数据，也可以处理数据。分布式文件系统中的文件可以被分割成定长的数据块，该数据块为申请存储空间和存放数据的基本单位。当客户端向分布式文件系统中存放数据时，主节点将随机地将新数据块的副本保存到不同的节点上。为了实现数据的协同摆放，TDW系统可以根据新申请的数据块所属的Hash分区编号或者列存储文件的路径名的hash值（对Hash分区数取模），利用下面实施例中提出的“顺环一致性Hash算法”确定该数据块的副本摆放位置。也就是说，TDW系统的Co-Location功能能够在不牺牲分布式文件系统的可靠性的前提下，保证了数据的合理摆放。

“顺环一致性Hash算法”是根据数据处理系统的特点对“一致性Hash算法”的简化而成的。“一致性Hash算法”原本是为了解决网络中热点问题，它只考虑了单个数据，而“顺环一致性Hash算法”将支持多个副本的存放。“顺环一致性Hash算法”更为简单高效，而且支持虚拟节点的概念，即将一个实节点影射为多个虚拟节点，这些虚拟节点可以比较均匀的分布在环上。因此，当新节点加入时，虚拟节点上的数据可以比较均匀的转移到新的节点上；当有节点失效时，可以将该节点上的数据副本迁移到某个虚节点上，待节点恢复后再迁移回原节点，从而保证不牺牲数据的副本数目。

具体的，在进行“顺环一致性Hash算法”处理时，可以进一步包括：

将数据节点分为实节点和虚节点，一个实节点映射为多个虚节点；

对每个数据节点计算出该节点的Hash值，并将其配置到一个Hash环上，该Hash环的长度等于系统统一配置的Hash分区数；

主节点分配数据块副本的存放位置时，确定该数据块的Hash值；

根据数据块的Hash值沿Hash环将数据块映射到距离其最近的节点上，在数据块需要保持多个副本时，则顺环选取与副本数相同的节点并将数据副本保存到这些节点上。

具体实施中，为了实现数据协同摆放，当客户端向分布式文件系统中存放数据时，分布式文件系统中的主节点可以根据正在写入的数据块的Hash值和数据节点的Hash值确定该数据块的存放位置。其中，数据节点的Hash值可以保存在主节点的配置文件中，可以是根据数据节点的IP地址计算得到，也可以是管理人员人为设定的。主节点可以根据各个数据节点的Hash值，将数据节点配置到Hash环上。数据节点可以均匀分布在Hash环上，该Hash环的长度可以为系统统一配置的Hash分区数。

Hash环中的数据节点可以在逻辑上划分为实节点和虚拟节点，一个实节点可以映射为多个虚拟节点，虚拟节点可以均匀地分布在Hash环上。针对不同的数据块，存放该数据块的数据节点可以是实节点，也可以是虚拟节点。当新的数据节点加入Hash环时，虚拟节点上的数据可以均匀地转移到该数据节点上；当数据节点失效时，可以将该数据节点上的数据迁移到其他的虚拟节点上，并在该数据节点恢复后，将之前迁移到其他虚拟节点的数据迁移回该数据节点，从而保证数据的副本数目不受影响。

主节点分配数据块的存放位置时，可以计算该数据块的Hash值，并根据数据块的Hash值以及数据节点的Hash值，沿Hash环的顺时针方向将数据块映射到与Hash值最接近的数据节点上。对于Hash分区中的数据块而言，该数据块的Hash值为该数据块对应的Hash分区号；对于没有使用Hash分区的列存储文件而言，主节点可以根据客户端提供的文件名确定其文件类型，将数据块所属文件的路径名去除列标签，再对去除列标签后的路径名进行Hash运算，并将得到的Hash结果对Hash分区数取模，即可得到数据块的Hash值。

如果需要对数据块保存多个副本，可以根据数据块的Hash值与数据节点的Hash值之间的关系，沿Hash环的顺时针方向选取Hash值最接近的、与副本数相同数量的数据节点，并将数据块保存到选取的数据节点上。若所选取的节点为虚拟节点，且该虚拟节点所对应的实节点上已经存放了该数据块的一个副本，则跳过该虚拟节点，继续寻找下一个节点。若选取的数据节点出现磁盘满或节点异常等状况，则沿Hash环的顺时针方向跳过该数据节点，继续寻找下一个数据节点。

以下通过具体的实例对数据协同摆放进行详细的叙述，图3为数据协同摆放示意图，如图3所示，系统统一配置的Hash分区数为400，则Hash环的长度也定义成400，且TDW系统中的数据节点数为n1，则可以将n1个数据节点根据Hash值分别均匀映射为0-399中的一个序号，数据节点的序号可以分别为0、5、......、s、s+t、s+t+p，Hash分区1-5中的数据块可以保存到节点5上，Hash分区s+1到s+t中的数据块将保存到节点s+t上。为了支持数据的备份存储，假定对每个数据块均保存c个副本，则可以在节点s之后的节点s+t和s+t+p等（c-1）个数据节点上，对节点s上保存的数据进行备份。为了提供更好的容灾能力，在将数据节点映射为Hash环上的序号时，可以将IP地址相邻的数据节点随机分布到Hash环上，使得同机架或者同批次的数据节点的下架不会对数据的完整性构成影响。

当向TDW系统中加入新的数据节点时，可以按照节点序号将新的数据节点均匀插入到原有的数据节点中，并完成数据的重新分布。图4为新节点加入时的数据协同摆放示意图，如图4所示，假定新的数据节点的序号为s+t/2，位于节点s和节点s+t之间，则可以将Hash分区s+1到s+t/2的数据从节点s+t上复制到节点s+t/2中，受到影响的节点将是局部的、有限的。

如果节点s+t/2暂时不可用，则可以将该节点上的数据块副本统一迁移到节点s+t上，也可以利用原有的实节点虚拟出新的虚节点s+t/2，由新的s+t/2节点负责存放原节点s+t/2上的数据副本，待原节点s+t/2恢复后将该数据副本重新交由原节点s+t/2负责。上述数据迁移可以是渐进进行的，以免带来太大的网络负担和节点负担。

上述实施例说明了对Hash分区利用顺环一致性Hash算法进行Co-Location数据存放的方式。对于列存储文件，客户端在申请新的数据块的时候，主节点根据客户端提供的文件名可以判断出该文件是一个列存储文件，则可以取文件的路径名去除列标签后的Hash值并对环长度求模，从而将其映射到Hash环上，同样可以进行数据的Co-Location摆放。

三、Hash Map Join。

Hash Map Join功能在本申请中是指以Hash分区为单位在Map端完成Join查询计算，以期提高计算效率，节约网络带宽、磁盘带宽和计算资源。该功能可以与Hash分区以及Co-Location功能一起为分布式数据仓库实现了高效的Join查询操作解决方法。Hash分区是实现Hash Map Join的必要条件，而Co-Location是为了进一步提高性能的措施。

下面先介绍将Join查询转换为Map端进行的Join计算的实施过程。

通过对数据表的数据进行Hash分区，具有相同Hash分区键的数据位于同一个Hash分区中，通过将Hash分区作为Map任务的划分依据，可以使得每个Map任务处理一个Hash分区中的数据，将Join查询转换为Map端进行的Join计算，图5为Join查询转换为Map端进行的Join计算的实施流程示意图，具体流程如图5所示，包括以下步骤：

步骤501，查询引擎获取用户提示信息，根据该用户提示信息确定当前的Join查询为Map端的Join操作。

具体地，查询引擎可以获取用户写入的用户提示信息，该用户提示信息可以通过SQL语句的形式表达，用户可以通过用户提示信息请求进行Map端的Join操作。

步骤502，查询引擎判断参与Join查询的两个数据表是否均对相同的列进行了Hash分区且Hash分区数相同，如果判断结果为是，则执行步骤504；否则，执行步骤503。

步骤503，按照常规流程对两个数据表执行Join查询。

具体地，查询引擎可以针对两个数据表，生成基于Join查询的Map/Reduce任务，并将该任务转发给Map/Reduce框架中的主控节点。主控节点将接收到的Map/Reduce任务分配到多个从节点，由从节点执行Map/Reduce任务，完成Join查询。

步骤504，查询引擎根据Hash分区数生成Map端的Join计算任务。

具体地，查询引擎可以将每个Hash分区作为一个计算单位，生成Map端的Join计算任务，该Map端的Join计算任务的个数可以与Hash分区数相同，每个Join计算任务负责针对同一个Hash分区进行Join计算。属于同一个Hash分区的数据可以作为一个分片（split），交由同一个Map端的Join计算任务来处理。例如，数据表a和数据表b都只有一级Hash分区，同一个Hash分区Hash-XXXX内的数据由同一个Map计算任务进行Join计算，如图6所示。

步骤505，查询引擎将Map端的Join计算任务发送给Map/Reduce框架中的主控节点。

步骤506，主控节点将Map端的Join计算任务分配给多个从节点。

步骤507，从节点执行Map端的Join计算任务，并对计算结果进行汇总，得到Join查询结果。

具体地，作为Map端，各个从节点执行主控节点分配的Join计算任务，并将计算结果保存到同一个目录中，通过该目录对Join计算任务的计算结果进行汇总，汇总结果即为Join查询结果。

利用TDW的Co-Location功能，两个数据表的相同Hash分区的所有数据位于同一个节点上，通过将Map任务调度到数据所在的节点将能进一步提高Hash Map Join的计算效率和性能，节省网络带宽和计算资源。

由图6可见，Hash Map Join算法中的每个Map任务将负责处理同一个Hash分区中的所有文件，而在Map/Reduce框架中，一般地，每个Map任务通常只负责处理一个分布式文件系统数据块（file split）。通过实现新的输入格式类，Hash Map Join允许将属于同一个Hash分区的所有文件作为一个分片（split），都交由同一个Map任务来处理。

上述实施例说明了在单个Map Join任务中的实施流程。假定用户在SQL语句的提示中指出，数据表a为小表，数据表b为大表（即流式表）。按照Map Join算法，小表的数据将首先被读取，最后读取大表的同一Hash分区的数据。图7为本发明实施例中的以数据表a和数据表b为例的Join查询流程图；在上述流程中，Map端的Join计算流程如图7所示，可以包括以下步骤：

步骤701，Map端读取参与Join查询的数据表中的数据。

具体地，在执行Join计算任务时，Map端可以通过获取用户提示信息，或者对参与计算的两个数据表的大小进行比较的方式，确定数据量较大的数据表（即，大表）和数据量较小的数据表（即，小表）。Map端可以先读取小表中的数据，再从大表（流式表）中读取与上述小表中的数据位于同一Hash分区的数据。假定用户在SQL语句的用户提示信息中指出，数据表a为小表，数据表b为大表，则在执行Map端的Join计算任务时，Map端先读取数据表a中的数据，再从数据表b中读取与数据表a中的数据位于同一Hash分区的数据。

步骤702，Map端判断读取到的数据是否来自小表，如果判断结果为是，则执行步骤703；否则，执行步骤706。

步骤703，Map端检查内存容器是否已满，如果未满，则执行步骤704；否则执行步骤705。

步骤704，Map端将读取到的数据放入内存容器。

需要说明的是，在执行完本步骤后，继续执行步骤706。

步骤705，Map端将读取到的数据存入硬盘文件。

步骤706，Map端从内存容器或硬盘文件中选择与读取到的数据的Join键相同的小表数据，将读取到的Join键相同的两部分数据进行Join计算，并将计算结果存入分布式文件系统。

需要说明的是，在执行Map端的Join计算任务的过程中，可以使用Hash Map内存容器保存小表数据，以提高查找数据的效率；也可以利用有序列表对内存容器和硬盘文件中的数据进行组织存放，即，按照Join键对内存容器和硬盘文件中的数据进行排列，可以按照Join键对大表数据进行有序的读取，并且能够非常容易地在内存容器或者硬盘文件中查找到与大表数据匹配的小表数据，使得Join计算简单高效，且节约内存资源。

此外，对于具备数据协同摆放功能的TDW系统而言，参与Join查询的两个数据表中的同一Hash分区的所有数据存放在同一个数据节点上，通过将Map任务调度到存储有与该Map任务对应的Hash分区的数据的节点，在调度时，具体可以根据数据所在的位置和该节点是否有空闲任务槽进行来调度。该方式能够提高Join查询的计算效率和性能，节省网络带宽和计算资源。

四、Hash Map Groupby。

Hash Map Groupby功能在本申请中是指以Hash分区为单位在Map端完成Groupby查询计算，以期提高计算效率，节约网络带宽、磁盘带宽和计算资源。该功能可以与Hash分区以及Co-Location功能一起为分布式数据仓库实现了高效的Groupby查询操作解决方法。

基于Hash分区进行Groupby查询的处理流程与上述Join查询的处理流程类似，不同之处在于，Groupby查询只处理一个数据表，通常会根据Groupby键对该数据表进行分组，并根据分组结果进行汇总计算。在数据入库时，可以根据Groupby键对数据进行Hash分区，属于同一个分组的键值对（Groupby键相同的一组值）位于同一个Hash分区中。因此，在进行Groupby查询时，可以以Hash分区为单位将同一个Hash分区中所有数据交由同一个Map任务处理。

此外，在数据入库时，还可以将Groupby键作为Map/Reduce任务的排序键，可以保证Groupby键相同的数据有序地汇聚在一起，Map端进行分组操作时，只需要顺序读入数据并对数据进行分组即可，简化了计算流程，提高了计算效率。

在对数据表中的数据进行Hash分区和数据协同摆放之后，Join查询和Groupby查询中的每个Map任务所需的全部数据被保存到相同的数据节点上。为了最大程度上利用数据协同摆放的优势，Map/Reduce框架还可以对Map任务根据数据存放位置进行调度。

五、基于数据摆放位置的Map任务调度的实施。

由于Map/Reduce框架仅能保证尽可能将Map任务调度到数据所在的节点上进行。但是，由于进行了基于Hash分区的协同数据摆放，Hash Map Join和Hash Map Groupby查询中每个Map任务所需的全部数据已经被保存到相同的节点上，因此，为了最大程度上利用数据协同摆放的优势，在Map/Reduce框架下还可以进一步提供更强的Map任务调度限制。

因此，实施中，还可以进一步包括：

在Join和Groupby 查询的生命期中，首先优先调度执行数据所在节点有空闲Map任务槽的那些Map任务；

如果列表中的每个Map任务数据所在的那几个节点都没有空闲的Map任务槽，则将逐个判断待调度Map任务数据所在节点正在执行的Map任务的执行进度；

如果执行进度高于特定阀值且预期任务完成时间早于特定阀值，则该Map任务将等待直到数据副本所在的节点空闲再调度到该节点上执行，否则，在其他邻近的空闲节点上调度执行该Map任务。

具体地，在Join查询和Groupby查询的生命期内，如果Map任务所需的数据所在的节点上有空闲的Map任务槽，则优先将该Map任务调度到该节点上执行；如果每个Map任务所需的数据所在的节点上都没有空闲的Map任务槽，则逐个确定待调度的Map任务所需的数据所在的节点上正在执行的Map任务的执行进度，如果节点上正在执行的Map任务的执行进度高于第一预设阀值且任务预期完成时间早于第二预设阀值，则在该节点空闲后，将待调度的Map任务调度到该节点上执行；否则，将待调度的Map任务调度到其他邻近的空闲节点上执行。通过上述任务调度流程，能够有效地利用数据的存放位置，提高计算效率。

可见，通过Hash分区将Join查询和Groupby查询转换成在Map端完成数据的处理操作，能够节约网络带宽、计算资源和磁盘I/O，提高计算效率。通过控制Hash分区的数目，可以控制在Map端的Join计算的粒度，从而优化对计算资源的利用。此外，数据协同摆放功能支持多个数据副本的存放，能够在不牺牲分布式文件系统的可靠性的前提下，保证了数据的合理摆放。通过数据协同摆放，将计算任务分配到该任务所需的数据存放的节点，可以提高Join查询和Groupby查询的计算效率。上述数据协同摆放也可以优化TDW系统中的其他类型的查询操作。当然，实施本发明的实施例的任一产品并不一定需要同时达到以上所述的所有优点。

基于同一发明构思，本发明实施例中还提供了一种数据处理系统，由于该系统解决问题的原理与一种数据处理方法相似，因此该系统的实施可以参见方法的实施，重复之处不再赘述。

图8为数据处理系统结构示意图，如图所示，在系统中可以包括：

存储引擎801，用于在基于Map/Reduce框架完成对SQL查询的处理和计算，数据存储任务由分布式文件系统完成的数据处理中，将数据表定义为采用Hash分区的方式，并在Hash分区中存储数据；

查询引擎802，用于在确定所需执行的查询为Join查询或Groupby查询，且源数据表为Hash分区数据表、连接键或分组键为分区列时，将该查询修改为在Map端以Hash分区为单位的Join查询或Grouby查询后执行查询。

实施中，存储引擎还可以进一步用于在Hash分区中存储数据时，将数据按照Hash分区键映射到不同的Hash分区保存，Hash分区键为常用的Join键或Groupby键。

实施中，存储引擎还可以进一步用于在Hash分区中存储数据时，在入库的Map/Reduce作业中将Hash分区键设置为Map/Reduce任务的sort key。

实施中，存储引擎还可以进一步用于将同一Hash分区的数据或保存到不同列存储文件的同一逻辑文件的数据存放在相同的节点。

实施中，存储引擎还可以进一步用于将数据节点分为实节点和虚节点，一个实节点映射为多个虚节点；对每个数据节点计算出该节点的Hash值，并将其配置到一个Hash环上，该Hash环的长度等于系统统一配置的Hash分区数；在主节点分配数据块副本的存放位置时，确定该数据块的Hash值；根据数据块的Hash值沿Hash环将数据块映射到距离其最近的节点上，在数据块需要保持多个副本时，则顺环选取与副本数相同的节点并将数据副本保存到这些节点上。

实施中，还可以进一步包括：计算引擎803，用于在Join和Groupby 查询的生命期中，首先优先调度执行数据所在节点有空闲Map任务槽的那些Map任务；如果列表中的每个Map任务数据所在的几个节点都没有空闲的Map任务槽，则将逐个判断待调度Map任务数据所在节点正在执行的Map任务的执行进度；如果执行进度高于特定阀值且预期任务完成时间早于特定阀值，则该Map任务将等待直到数据副本所在的节点空闲再调度到该节点上执行，否则，在其他邻近的空闲节点上调度执行该Map任务。

为了描述的方便，以上所述装置的各部分以功能分为各种引擎、模块或单元分别描述。当然，在实施本发明时可以把各引擎、模块或单元的功能在同一个或多个软件或硬件中实现。

由上述实施例可见，在本发明实施例提供的技术方案中，为分布式数据仓库增加Hash分区的分区方式，将数据按照Hash分区键映射到不同的Hash分区保存。由于键相等的数据均已被映射到同一个Hash分区中，因此，对于Join查询和Groupby查询而言，可以将Hash分区作为Map任务的划分依据，每个Hash分区由一个Map任务处理，在map端完成数据的处理操作，从而达到节约网络带宽、磁盘带宽和网络资源，提高计算效率的目的。

进一步的，还可以以Hash分区或逻辑文件（针对列存储格式）为单位进行数据的协同摆放（Co-Location），也就是说，将属于同一个Hash分区的数据存放到同一个节点上，如果列存储文件没有保存到Hash分区中，则把属于同一个逻辑文件的所有列存储文件摆放到同一个节点上。通过这种数据的协同摆放，可以达到进一步提高Hash Map Join和Hash Map Groupby计算效率的目的。这种数据的协同摆放也可以优化其他相似的查询。此外，通过尽可能将计算任务分配到数据所在的节点，最大程度的利用数据协同摆放的优点。

本领域内的技术人员应明白，本发明的实施例可提供为方法、系统、或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质（包括但不限于磁盘存储器、CD-ROM、光学存储器等）上实施的计算机程序产品的形式。

本发明是参照根据本发明实施例的方法、系统（设备）、和计算机程序产品的流程图和／或方框图来描述的。应理解可由计算机程序指令实现流程图和／或方框图中的每一流程和／或方框、以及流程图和／或方框图中的流程和／或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和／或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和／或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和／或方框图一个方框或多个方框中指定的功能的步骤。

尽管已描述了本发明的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例作出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本发明范围的所有变更和修改。

显然，本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发明的精神和范围。这样，倘若本发明的这些修改和变型属于本发明权利要求及其等同技术的范围之内，则本发明也意图包含这些改动和变型在内。

Claims

1.一种数据处理方法，其特征在于，包括如下步骤：

2.如权利要求1所述的方法，其特征在于，在Hash分区中存储数据，包括：

将数据按照Hash分区键映射到不同的Hash分区保存，Hash分区键为连接键或分组键。

3.如权利要求1所述的方法，其特征在于，在Hash分区中存储数据时，进一步包括：

在入库的Map/Reduce作业中将Hash分区键设置为Map/Reduce任务的排序键。

4.如权利要求1所述的方法，其特征在于，进一步包括：

将同一Hash分区的数据或保存到不同列存储文件的同一逻辑文件的数据存放在相同的节点。

5.如权利要求1所述的方法，其特征在于，进一步包括：

在主节点分配数据块副本的存放位置时，确定该数据块的Hash值；

6.如权利要求1至5任一所述的方法，其特征在于，进一步包括：

在连接和分组查询的生命期中，首先优先调度执行数据所在节点有空闲Map任务槽的Map任务；

如果列表中的每个Map任务数据所在的节点都没有空闲的Map任务槽，则将逐个判断待调度Map任务数据所在节点正在执行的Map任务的执行进度；

7.一种数据处理系统，其特征在于，包括：

8.如权利要求7所述的系统，其特征在于，查询引擎进一步用于在Hash分区中存储数据时，将数据按照Hash分区键映射到不同的Hash分区保存，Hash分区键为常用的连接键或分组键。

9.如权利要求7所述的系统，其特征在于，查询引擎进一步用于在Hash分区中存储数据时，在入库的Map/Reduce作业中将Hash分区键设置为Map/Reduce任务的排序键。

10.如权利要求7所述的系统，其特征在于，存储引擎进一步用于将同一Hash分区的数据或保存到不同列存储文件的同一逻辑文件的数据存放在相同的节点。

11.如权利要求7所述的系统，其特征在于，存储引擎进一步将数据节点分为实节点和虚节点，一个实节点映射为多个虚节点；对每个数据节点计算出该节点的Hash值，并将其配置到一个Hash环上，该Hash环的长度等于系统统一配置的Hash分区数；在主节点分配数据块副本的存放位置时，确定该数据块的Hash值；根据数据块的Hash值沿Hash环将数据块映射到距离其最近的节点上，在数据块需要保持多个副本时，则顺环选取与副本数相同的节点并将数据副本保存到这些节点上。

12.如权利要求7至11任一所述的系统，其特征在于，进一步包括：

计算引擎，用于在连接和分组查询的生命期中，首先优先调度执行数据所在节点有空闲Map任务槽的Map任务；如果列表中的每个Map任务数据所在的节点都没有空闲的Map任务槽，则将逐个判断待调度Map任务数据所在节点正在执行的Map任务的执行进度；如果执行进度高于特定阀值且预期任务完成时间早于特定阀值，则该Map任务将等待直到数据副本所在的节点空闲再调度到该节点上执行，否则，在其他邻近的空闲节点上调度执行该Map任务。