CN106549990A

CN106549990A - 一种分布式数据的处理方法和系统

Info

Publication number: CN106549990A
Application number: CN201510599863.XA
Authority: CN
Inventors: 杜川; 李闪; 段培乐; 魏蒲萌; 孙敬
Original assignee: Alibaba Group Holding Ltd
Current assignee: Alibaba Group Holding Ltd
Priority date: 2015-09-18
Filing date: 2015-09-18
Publication date: 2017-03-29
Also published as: WO2017048924A1; EP3353671A1; US20170083579A1; EP3353671A4

Abstract

本申请实施例提供了一种分布式数据的处理方法和系统，其中，所述的方法包括：碎片节点接收客户端针对某一个表上传的数据；碎片节点将所述数据存储至所述表对应的存储目录中；当存储成功时，碎片节点将所述数据发送至相连的每个流式计算节点进行流式计算，使得数据一次落地就可以同时被离线计算节点和实时的流式计算节点共享使用，不必依赖消息中间件，降低了系统的复杂度，相比消息队列减少了一次落地的过程，减少了存储成本、出错的概率以及处理的延迟。

Description

一种分布式数据的处理方法和系统

技术领域

本申请涉及云计算的技术领域，特别是涉及一种分布式数据的处理方法和一种分布式数据的处理系统。

背景技术

随着互联网的快速发展，数据量爆发性增长，云计算已被广泛应用，其中，分布式的海量数据处理是云计算的应用之一。

在分布式的海量数据处理大概分为两个方向：离线处理与流式计算。

离线计算在已知的数据集上执行查询计算，如离线计算模型“MapReduce”。

而对于流计算而言，数据是未知的、实时流入的，当数据流入时，按照已定义的计算模型来处理数据。

不同的计算模型，决定了离线计算和流式计算对存储数据进行持久化的方式(又称数据落地)有不同的要求。

因为离线计算是在已知的数据集上进行的查询计算，先有数据，后有计算，因此对数据落地的要求相对较低，只要数据能够按照一定形式正确写入分布式文件系统即可。

而在流式计算中，数据源源不断地流入提前定义好的计算模型中，因此需要考虑因为各种异常因素导致的数据丢失、重复、乱序等问题，这对数据落地提出了更高的要求。

离线计算和流式计算两种计算模型有着不同的特点，因此有不同的应用场景，两者的界限往往不这么明确。

很多场景当中，同一份数据，往往需要流式计算进行立即处理，也需要沉淀下来为离线计算所用。

这种情况下，需要一种统一的数据落地方式。

目前，业界的通常做法是利用消息队列作为数据落地的中间层，以屏蔽后端计算模型的差异。

这种方法虽然为离线计算和流式计算提供了一个统一的数据落地方式，但是忽略计算模型差异的做法也带来一些明显的问题。

对于离线计算来说，计算所需的数据往往是事先按照某种形式组织在分布式文件系统中的，因此，如果采用消息队列作为数据落地方式，离线计算系统还需要一个额外的数据中间件从消息队列中拉取数据，并按照离线计算的需求存储到分布式文件系统当中，这既增加了系统的复杂性，对数据来说也多了一次落地的过程，增大了存储成本、出错的概率以及处理的延迟。

发明内容

鉴于上述问题，提出了本申请实施例以便提供一种克服上述问题或者至少部分地解决上述问题的一种分布式数据的处理方法和相应的一种分布式数据的处理系统。

为了解决上述问题，本申请实施例公开了一种分布式数据的处理方法，包括：

碎片节点接收客户端针对某一个表上传的数据；

碎片节点将所述数据存储至所述表对应的存储目录中；

当存储成功时，碎片节点将所述数据发送至相连的每个流式计算节点进行流式计算。

可选的，所述碎片节点将所述数据存储至所述表对应的存储目录中的步骤包括：

查找所述表对应的范式；

采用所述范式对所述数据进行校验；

当通过校验时，将所述数据存储至所述表对应的存储目录中。

可选的，所述表划分成一个或多个分区，每个分区对应存储目录中的存储子目录；

所述碎片节点将所述数据存储至所述表对应的存储目录中的步骤包括：

将符合所述分区的数据，按照文件大小和/或时间封装至一个或多个文件中；

将所述一个或多个文件存储至所述分区对应的存储子目录中。

可选的，所述方法还包括：

碎片节点在成功存储数据时生成第一存储操作消息；

碎片节点在打开或关闭分区时生成第二存储操作消息；

其中，所述第一存储操作消息包括如下的一个或多个参数：

数据所属的文件、数据在所属的文件的偏移量、按照存储顺序生成的存储序列号；

所述第二存储操作消息包括如下的一个或多个参数：

数据所属的文件、数据在所属的文件的偏移量、按照存储顺序生成的存储序列号。

可选的，所述方法还包括：

流式计算节点采用所述第一存储操作消息更新第一存储元信息；

碎片节点采用所述第二存储操作消息更新第二存储元信息。

可选的，所述流式计算节点采用所述第一存储操作消息更新第一存储元信息的步骤包括：

判断在所述第一存储元信息中是否存在第一目标存储操作消息；所述第一目标存储操作消息与所述第一存储操作消息表征数据所属的文件相同；

若是，则将所述第一存储操作消息替换所述第一目标存储操作消息；

若否，则将所述第一存储操作消息添加到所述第一存储元信息中；

所述碎片节点采用所述第二存储操作消息更新第二存储元信息的步骤包括：

判断在所述第二存储元信息中是否存在第二目标存储操作消息；所述第二目标存储操作消息与所述第二存储操作消息表征数据所属的文件相同；

若是，则将所述第二存储操作消息替换所述第二目标存储操作消息；

若否，则将所述第二存储操作消息添加到所述第二存储元信息中。

可选的，所述方法还包括：

流式计算节点对比所述第一存储操作消息与在先更新的第一存储元信息，判断数据是否丢失或重复；

当数据丢失时，则从存储目录中读取丢失的数据，采用丢失的数据的第一存储操作消息更新第一存储元信息；

当数据重复时，则丢弃重复的数据。

可选的，所述流式计算节点对比所述第一存储操作消息与在先更新的第一存储元信息，判断数据是否丢失或重复的步骤包括：

当所述第一存储操作消息的存储序列号大于目标存储序列号时，判定数据丢失；

当所述第一存储操作消息的存储序列号小于目标存储序列号时，判定数据重复；

其中，所述目标存储序列号为所述第一存储元信息中，位于最新的存储序列号的下一位存储序列号。

可选的，所述第一存储元信息中标识有当前打开的分区；

所述从存储目录中读取丢失的数据的步骤包括：

计算在所述第一存储操作消息的存储序列号，与，第一存储元信息中最新的存储序列号之间的第一候选存储序列号；

从当前打开的分区对应的存储子目录中读取所述第一候选存储序列号对应的数据。

可选的，所述方法还包括：

流式计算节点对第一存储元信息进行持久化处理；

当故障转移时，流式计算节点采用持久化处理的第一存储元信息进行恢复处理；

碎片节点对第二存储元信息进行持久化处理；

当故障转移时，碎片节点采用持久化处理的第二存储元信息进行恢复处理。

可选的，所述第一存储元信息中标识有当前打开的分区；

所述流式计算节点采用持久化处理的第一存储元信息进行恢复处理的步骤包括：

加载持久化处理的第一存储元信息；

从当前打开的分区对应的存储子目录中查找最新的存储序列号；

计算存储子目录中最新的存储序列号，与，第一存储元信息中最新的存储序列号之间的第二候选存储序列号；

采用所述第二候选存储序列号所属数据的第一存储操作消息更新第一存储元信息；

所述第二存储元信息中标识有当前打开的分区；

所述碎片节点采用持久化处理的第二存储元信息进行恢复处理的步骤包括：

加载持久化处理的第二存储元信息；

计算存储子目录中最新的存储序列号，与，第二存储元信息中最新的存储序列号之间的第三候选存储序列号；

采用所述第三候选存储序列号所属数据的第二存储操作消息更新第二存储元信息。

为了解决上述问题，本申请实施例还公开了一种分布式数据的处理系统，所述系统包括一个或多个碎片节点和一个或多个流式计算节点，其中，所述碎片节点包括：

数据接收模块，用于接收客户端针对某一个表上传的数据；

数据存储模块，用于将所述数据存储至所述表对应的存储目录中；

数据转发模块，用于在存储成功时，将所述数据发送至相连的每个流式计算节点进行流式计算。

可选的，所述碎片节点还包括：

第一存储操作消息生成模块，用于在成功存储数据时生成第一存储操作消息；

第二存储操作消息生成模块，用于在打开或关闭分区时生成第二存储操作消息；

其中，所述第一存储操作消息包括如下的一个或多个参数：

所述第二存储操作消息包括如下的一个或多个参数：

可选的，所述流式计算节点包括：

第一更新模块，用于采用所述第一存储操作消息更新第一存储元信息；

所述碎片节点还包括：

第二更新模块，用于采用所述第二存储操作消息更新第二存储元信息。

可选的，所述流式计算节点还包括：

数据检验模块，用于对比所述第一存储操作消息与在先更新的第一存储元信息，判断数据是否丢失或重复；当数据丢失时，则调用读取模块，当数据重复时，则调用丢弃模块；

读取模块，用于从存储目录中读取丢失的数据，采用丢失的数据的第一存储操作消息更新第一存储元信息；

丢弃模块，用于丢弃重复的数据。

可选的，所述流式计算节点包括：

第一持久化模块，用于对第一存储元信息进行持久化处理；

第一恢复模块，用于在故障转移时，采用持久化处理的第一存储元信息进行恢复处理；

所述碎片节点还包括：

第二持久化模块，用于第二存储元信息进行持久化处理；

第二恢复模块，用于在故障转移时，采用持久化处理的第二存储元信息进行恢复处理。

可选的，所述第一存储元信息中标识有当前打开的分区；

所述第一恢复模块包括如下子模块：

第一加载子模块，用于加载持久化处理的第一存储元信息；

第一存储序列号查找子模块，用于从当前打开的分区对应的存储子目录中查找最新的存储序列号；

第二候选存储序列计算子模块，用于计算存储子目录中最新的存储序列号，与，第一存储元信息中最新的存储序列号之间的第二候选存储序列号；

第一存储元信息更新子模块，用于采用所述第二候选存储序列号所属数据的第一存储操作消息更新第一存储元信息；

所述第二存储元信息中标识有当前打开的分区；

所述第二恢复模块包括如下子模块：

第二加载子模块，用于加载持久化处理的第二存储元信息；

第二存储序列号查找子模块，用于从当前打开的分区对应的存储子目录中查找最新的存储序列号；

第三候选存储序列计算子模块，用于计算存储子目录中最新的存储序列号，与，第二存储元信息中最新的存储序列号之间的第三候选存储序列号；

第二存储元信息更新子模块，用于采用所述第三候选存储序列号所属数据的第二存储操作消息更新第二存储元信息。

本申请实施例包括以下优点：

本申请实施例的碎片节点对客户端针对某一个表上传的数据存储至该表对应的存储目录中，当存储成功时，将数据发送至相连的每个流式计算节点进行流式计算，使得数据一次落地就可以同时被离线计算节点和实时的流式计算节点共享使用，不必依赖消息中间件，降低了系统的复杂度，相比消息队列减少了一次落地的过程，减少了存储成本、出错的概率以及处理的延迟。

本申请实施例通过存储操作消息的更新操作，使得碎片节点与流计算节点之间的数据传输可以保证不丢不重，各个流计算节点可以实现数据共享，状态隔离，使得一个流计算节点的网络异常或者崩溃不会影响碎片节点的数据写入或者其他流计算节点的数据读取，并且，碎片节点与流计算节点可以根据持久化存储操作消息恢复自身的状态，不需要源头重发数据，实现快速恢复。

附图说明

图1是一种Apache Kafka系统的结构框图；

图2是一种Apache Kafka系统的数据落地示意图；

图3是本申请的一种分布式数据的处理方法实施例1的步骤流程图；

图4是本申请的一种分布式系统的结构框图；

图5是本申请的一种分布式系统的数据落地示意图；

图6是本申请的一种数据组织结构示意图；

图7是本申请的一种流式计算的示例图；

图8是本申请的一种分布式数据的处理方法实施例2的步骤流程图；

图9是本申请的一种分布式数据的处理系统实施例的结构框图。

具体实施方式

为使本申请的上述目的、特征和优点能够更加明显易懂，下面结合附图和具体实施方式对本申请作进一步详细的说明。

在流式计算的计算模型中，以Apache Kafka为例，如图1所示，一个典型的Kafka集群中包含若干Producer(可以是web前端(Front End)产生的PageView，或者是服务器(Service)日志，系统CPU、Memory等)，若干broker(Kafka支持水平扩展，一般broker数量越多，集群吞吐率越高)，若干Consumer Group(如Hadoop Cluster(Hadoop集群)、Real-time monitoring(实时监控系统)、Other service(其他服务)、Datawarehouse(数据仓库)等)，以及一个Zookeeper集群。

Kafka通过Zookeeper管理集群配置，选举leader，以及在Consumer Group发生变化时进行rebalance。

Producer使用push(推)模式将消息发布到broker，Consumer使用pull(拉)模式从broker订阅并消费消息。

如图2所示，以Kafka为代表的消息队列(Message Queue)作为数据落地的中间层，由Producer发送数据至Consumer，屏蔽了后端计算模型的差异。

所有的数据需求方作为Consumer接入消息队列系统，并从中拉取数据(如File1、File2、File3等)至分布式文件系统(Distributed Flie System)，进行分布式处理(如MapReduce)。

在流式计算的计算模型中，需要考虑数据流的丢失、重复、乱序问题。

解决这些问题往往需要流式计算的数据源提供数据的额外信息，如为每一条数据提供一个唯一的标识等。

消息队列中，Producer与Consumer的解耦，使得流式计算系统很难获得所需要的额外信息，使得上述问题的解决更加困难。

因此，提出了本申请实施例的构思之一，数据一次落地同时被离线计算节点和实时的流式计算节点共享使用。

参照图3，示出了本申请的一种分布式数据的处理方法实施例1的步骤流程图，具体可以包括如下步骤：

步骤301，碎片节点接收客户端针对某一个表上传的数据；

需要说明的是，本申请实施例可以应用于分布式系统。

如图4和图5所示，分布式系统对外可以提供API(ApplicationProgramming Interface，应用程序编程接口)，如符合Restful规范的API，满足相关Restful规范，用户可以通过譬如Web Console(网页控制台)、专用工具等客户端(如ClientA、Clinet B)，在程序中调用相应SDK(SoftwareDevelopment Kit，软件开发工具包)等多种方式，完成数据(Data)上传。

这些数据可以为网站访问日志、用户行为日志、交易数据等任何结构化数据，本申请实施例对此不加以限制。

例如，某个网站访问日志的格式为：

(ip,user,time,request,status,size,referer,agent)

其示例可以如下：

69.10.179.41,,2014-02-12 03:08:06,GET /feedHTTP/1.1,200,92446,,Motorola；

又例如，某个用户行为日志的格式为：

(user_id,brand_id,type,date)

其示例可以如下：

10944750,21110,0,0607。

分布式系统通过Tunnel Cluster(集群)与客户端进行交互。

Tunnel Cluster由一系列的Tunnel Server(服务器)组成，这些TunnelServer组要负责维持客户端连接，客户端鉴权/授权，流量控制/并发控制等工作，并不直接参与实时/离线计算。

客户端上传的数据经由Tunnel Server转发至计算集群。

计算集群是建立在众多机器上的分布式的计算/存储集群(Compute/Storage Cluster)，它通过分布式操作系统将各个机器资源/内存资源/存储资源进行整合，提供一个抽象的计算/存储平台。

整个计算集群由控制节点管控。

控制节点由三部分组成：元数据服务(Meta Service)、流调度器(StreamScheduler)和任务调度器(Task Scheduler)。

Meta Service负责管理/维护计算集群中的存储资源，并且维护基于底层存储构建的抽象存储信息，比如表及其范式(Schema)等信息。

同一个集群中可能共存多个流，流调度器可以负责协调计算集群中各个流的资源分配、任务调度等操作。

同一个流中可能有多阶段任务，一个阶段任务可能有多个实例(Instance)，任务调度器可以负责在同一个流中，各个Task的资源分配、任务监控等操作。

在计算集群中，每一台机器上都可以，并可能被分配运行流式计算服务或者执行离线运算作业，两者共享集群的存储资源。

具体而言，数据处理涉及三个功能组件：Shard(碎片节点)、AppContainer(首级计算节点)和Processors(普通计算节点)。

Shard用于接收客户端的数据，它先把数据存储(Storage)到分布式文件系统中，保证数据正常落地，这一层落地的数据同时可以用于其他服务，比如，在离线计算节点(Offline Task，如MapReduce)中进行离线计算。

然后，再将数据发送给AppContainer(如图4所示的Machine 1、Machine2)。

一个AppContainer包含一个或多个Task(任务)的运行实例，，Task是流计算中的逻辑处理单元，一个Task可以有多个物理运行实例(Instance)。

由于首级Task处理的数据格式和处理逻辑的特殊性，所以把它和其他Task区别开，首级Task又称为AgentTask(代理任务)，其他Task又称为InnerTask(内部任务)。

InnerTask都在Processors(如图4所示的Machine3)中。

从用户角度来看，AgentTask和InnerTask没有区别，但是从分布式系统实现的角度看，为了不影响数据落地，在Shard中对数据进行落地(落地操作对用户是透明的，但用户可以访问落地后的数据)，所以AppContainer在实现上和后面的Processor有一定区别。

需要说明的是，在一个AppContainer中具有一个或多个Shard，在Processors中，不具有Shard。

具体而言，为了保证数据落地的一致性，负责数据落地的Shard和复负责第一级任务处理的AgentTask放在一起，两者共存在AppContainer当中，第二级及其之后的Task则没有这一约束，所以Processors中没有Shard存在。

在本申请实施例中，若数据落地成功，即对离线计算节点可见。

因此，Shard在落地数据的时候可以按照一定的格式对数据进行组织。

在本申请实施例中，引入了“表”(Table)的概念，每一个表对应分布式文件系统的一个目录，并且同一个表中的所有数据具有相同的范式(Schema)。

表名，范式(Schema)等信息作为原信息可以存储在Meta Service中。

客户端创建数据的上传服务的时候，会以相应的表名启动Shard的服务。

步骤302，碎片节点将所述数据存储至所述表对应的存储目录中；

如图6所示，用户可以根据实际需要，通过Clinet(客户端)创建表(如Table a)，并指定其目录(如/a/pt＝1/，/a/pt＝2/)，Clinet可以通过Shard，向表中写入数据，如Record(记录)。

Shard在接收Clinet的数据时，则可以根据相应的表名，从Meta Service中查找该表对应的范式(Schema)，采用范式(Schema)对数据的每一个字段进行类型的校验，判断数据是否合规，当通过校验时，将数据存储至该表对应的存储目录中。

进一步而言，表划分成一个或多个分区(Partition)，每个分区对应存储目录中的存储子目录(subdir)。

分区是一个逻辑概念，在创建表的时候，用户可以按照实际应用的需要户可以根据需要指定分区列，按照该列的值对数据创建分区。

一个分区当中，包含的是分区列的值符合该分区条件的数据。

例如，数据源源不断进入分布式系统，这些数据往往会记录数据产生的时间，此时，可以按照时间对数据进行分区。

如在分区“20150601”中，即包含的是产生的时间为2015年6月1日的数据。

进一步而言，文件头部保存的表的范式(Schema)，在封装时，可以将符合该分区的数据，按照文件大小和/或时间封装至一个或多个文件中，将一个或多个文件存储至分区对应的存储子目录中。

按照文件大小进行切分，可以减少写数据时的运算量。

按照时间进行切分，可以减少数据在封装时的漂移。例如，13点-14点的文件、14点-15点的文件分开存储，按照5分钟切文件，可以减少13点-14点的数据落入14点-15点的文件中。

在同一个分区中，数据被保存在前缀一致，序列号递增的一系列的文件中。

具体而言，分区下面的文件有统一前缀，并且文件号按照从小到大递增。

当分区刚创建时，分区目录下并没有文件。当有数据写入的时候，在分布式文件系统中创建后缀为“1”的文件。

随后录入的数据即写入该文件中，当该文件超过一定文件大小(如64M)或经过一定时间(如5分钟)，进行文件切换，关闭后缀为“1”的文件，创建后缀为“2”的文件，以此类推。

前缀一致可以使得只需要一个文件号码，既可以根据前缀拼接出文件名，可以减少元信息的大小。

序列号递增可以只需要根据文件的序列号，无需打开文件，即可以判断文件创建的先后顺序。

步骤303，当存储成功时，碎片节点将所述数据发送至相连的每个流式计算节点进行流式计算。

若数据成功落地，即对离线计算节点可见。

如图4和图5所示，每个应用实现的流式计算的逻辑称为Topology，它是由多个计算节点共同完成，每个计算节点执行一个Topology子集。

每一个Shard可以接入一个或多个流式计算节点，当数据成功落地之后，Shard会将数据转发到后端接入的每个流式计算节点进行实时的流式计算。

因此，当其中某个流式计算节点异常或者崩溃，不会影响Shard与其他流式计算节点的通信，避免“快车等慢车”现象。

由于系统对外服务，Task中运行着代码，为了保证分布式系统的安全，Task是在受限的沙箱环境中运行，禁止访问网络，所以，每级Task是通过把数据向上发送给本机的AppContainer或Processor进行中转，再发送给下一级Task。

需要说明的是，在不同的业务领域，流计算节点可以进行不同的实时的流式计算。

在一个示例中，如图7所示，流式计算节点可以用于进行聚合分析(流式计算)。

假设某电商平台采用流式计算节点计算统计商品的实时销售总数。则每产生一笔交易，即生成一条格式如“商品ID：时间：销售量”的日志数据。

日志数据通过RestfulAPI，从Client(如Client1和Client2)实时导入分布式系统当中(为了简化范例，这里省略了Tunnel部分)。

Shard(如Shard1和Shard2)将数据落地持久化之后，转发至流计算节点的AgentTask(如AgentTask1和AgentTask2)上。AgentTask上的处理逻辑比较简单，即从日志中抽取出商品ID以及销售总数COUNT，并且以商品ID为Key对进行Hash，根据取得的Hash值将产生的中间数据转发至对应的InnerTask(如InnerTask1、InnerTask2和InnerTask3)上。

InnerTask接收到AgentTask传递的中间数据，将对应商品ID的销售总数进行累加(TOTAL_COUNT)，得到实时的总销售数量。

参照图8，示出了本申请的一种分布式数据的处理方法实施例2的步骤流程图，具体可以包括如下步骤：

步骤801，碎片节点接收客户端针对某一个表上传的数据；

步骤802，碎片节点将所述数据存储至所述表对应的存储目录中；

步骤803，当存储成功时，碎片节点将所述数据发送至相连的每个流式计算节点进行流式计算；

步骤804，碎片节点在成功存储数据时生成第一存储操作消息；

数据落地成功后，Shard会将数据转发到接入在其上的各个流式计算节点，这里引入了读写分离的RedoLog方案。

具体而言，Shard为每一条成功落地的数据生成一个名为RedoLogMessage的第一存储操作消息。

其中，第一存储操作消息可以包括如下的一个或多个参数：

数据所属的文件(Loc)、数据在所属的文件的偏移量(Offset)、按照存储顺序(如单调递增)生成的存储序列号(SequenceID)。

步骤805，碎片节点在打开或关闭分区时生成第二存储操作消息；

在新打开或关闭一个分区的时候，Shard会在一个名为RedoLogMeta(第二存储元信息)的文件中记录下本次打开的分区信息，并且，同样生成一个名为RedoLogMessage的第二存储操作消息。

其中，第二存储操作消息可以包括如下的一个或多个参数：

需要说明的是，第二存储操作消息和第一存储操作消息的共用一套SequanceID。

数据操作和分区操作的统一编址，使得通过重放一系列连续的RedoLogMessage，即可恢复一段时间内Shard上的操作。

步骤806，流式计算节点采用所述第一存储操作消息更新第一存储元信息；

为了避免各个流式计算节点之间相互干扰，Shard在推送数据的同时，也会将相应的名为RedoLogMessage的第一存储操作消息推送给流式计算节点。

每个流式计算节点的AgentTask上也维护了名为RedoLogMeta的第一存储元信息，RedoLogMeta保存了每一个分区最后一次写入数据的状态。

Shard会将其生成的每一条RedoLogMessage随着数据转发给其上每个流式计算节点的AgentTask，AgentTask根据RedoLogMessage更新各自存储在内存的RedoLogMeta，维护自己与Shard之间数据传输的状态，并且在发生FailOver(故障转移)的时候根据这些信息恢复自己的状态，从而不对其他流式计算节点或者Shard造成影响。

在具体实现中，流式计算节点可以判断在第一存储元信息中是否存在第一目标存储操作消息，其中，第一目标存储操作消息与第一存储操作消息表征数据所属的文件相同；

若是，则将第一存储操作消息替换第一目标存储操作消息；

若否，则将第一存储操作消息添加到第一存储元信息中；

例如，在第一存储操作消息如表1所示：

表1

PardID	Loc	Offset	SequenceID
				2	/a/2/file_2	112	11

第一存储元信息如表2所示：

表2

PardID	Loc	Offset	SequenceID
				1	/a/1/file_1	50	7
2	/a/2/file_2	90	10
				3	/a/3/file_3	0	9

由于第一存储元信息与第一存储操作消息存在相同的文件“/a/2/file_2”，因此，第一存储操作消息表征对文件“/a/2/file_2”最新的操作，替换旧的操作的第一存储操作消息(即第一目标存储操作消息)。

更新后的第一存储元信息如表3所示：

表3

PardID	Loc	Offset	SequenceID
				1	/a/1/file_1	50	7
2	/a/2/file_2	112	11
				3	/a/3/file_3	0	9

又例如，在第一目标存储操作消息如表4所示：

表4

PardID	Loc	Offset	SequenceID
				4	/a/2/file_1	0	11

第一存储元信息如表5所示：

表5

PardID	Loc	Offset	SequenceID
				1	/a/1/file_1	50	7
2	/a/2/file_2	90	10
				3	/a/3/file_1	0	9

由于第一存储元信息与第一存储操作消息不存在相同的文件，因此，第一存储操作消息表征对文件“/a/2/file_1”最新的操作，直接添加到第一存储元信息中。

更新后的第一存储元信息如表6所示：

表6

PardID	Loc	Offset	SequenceID
				1	/a/1/file_1	50	7
2	/a/2/file_2	90	10
				3	/a/3/file_3	0	9
4	/a/2/file_1	0	11

步骤807，碎片节点采用所述第二存储操作消息更新第二存储元信息；

Shard利用每次打开或关闭操作生成的RedoLogMessage(第二存储操作消息)更新内存中、一个名为RedoLogMeta的第二存储元信息的状态，以保存了Shard当前打开的所有分区的状态，即RedoLogMeta保存了每一个分区最后一次写入数据的状态。

与流式计算节点更新的方式相类似地，Shard可以判断在第二存储元信息中是否存在第二目标存储操作消息，其中，第二目标存储操作消息与第二存储操作消息表征数据所属的文件相同；

若是，则将第二存储操作消息替换第二目标存储操作消息；

若否，则将第二存储操作消息添加到第二存储元信息中。

步骤808，流式计算节点对比所述第一存储操作消息与在先更新的第一存储元信息，判断数据是否丢失或重复；当数据丢失时，则执行步骤809，当数据重复时，则执行步骤810；

SequenceID是在整个Shard范围内分配的，也就是说在不同分区之间共享的，连续的数据之间SequenceID也是单调连续的，因此，若流式计算节点接收到的RedoLogMessage与在先更新的RedoLogMeta不连续，则可以表示该数据丢失或重复，需要进行重发(Replay)或丢弃，恢复正常的状态。

进一步而言，当第一存储操作消息的存储序列号大于目标存储序列号时，判定数据丢失；

其中，目标存储序列号为第一存储元信息中，位于最新的存储序列号的下一位存储序列号。

例如，第一存储元信息如表7所示：

表7

PardID	Loc	Offset	SequenceID
				1	/a/1/file_1	50	6
2	/a/2/file_2	90	7
				3	/a/3/file_1	0	5

RedoLogMeta中最新的存储序列号SequenceID_last为7，则目标存储序列号SequenceID_target为8，即表示下一个RedoLogMessage应该为存储序列号为8的数据的RedoLogMessage。

若当前接收到RedoLogMessage的SequenceID为9，大于SequenceID_target，即表示丢失了数据。

若当前接收到RedoLogMessage的SequenceID为6，小于SequenceID_target，即表示数据重复。

步骤809，从存储目录中读取丢失的数据，采用丢失的数据的第一存储操作消息更新第一存储元信息；

在具体实现中，可以计算在第一存储操作消息的存储序列号，与，第一存储元信息中最新的存储序列号之间的第一候选存储序列号；

由于第一存储元信息中标识有当前打开的分区，则可以从当前打开的分区对应的存储子目录中读取候选存储序列号对应的数据。

在更新时，可以判断在丢失的数据的第一存储元信息中是否存在第一目标存储操作消息，其中，第一目标存储操作消息与第一存储操作消息表征数据所属的文件相同；

若是，则将第一存储操作消息替换第一目标存储操作消息；

若否，则将第一存储操作消息添加到第一存储元信息中。

例如，对于表7的例子，RedoLogMeta中最新的存储序列号SequenceID_last为7，若当前接收到RedoLogMessage的SequenceID为9，则第一候选存储序列号为8。

分布式文件系统如表8所示：

表8

Part1	Part2	Part3
			Record SequenceID:1	Record SequenceID:2	Record SequenceID:3
Record SequenceID:4	Record SequenceID:7	Record SequenceID:5
			Record SequenceID:6	Record SequenceID:8	Record SequenceID:9

若RedoLogMeta中记录当前打开的分区为Part2，则可以从Part2中读取SequenceID为8的数据，并采用其RedoLogMessage更新RedoLogMeta。

假设SequenceID为8的数据的RedoLogMessage如表9所示：

表9

PardID	Loc	Offset	SequenceID
				2	/a/2/file_2	112	8

则更新后的RedoLogMeta如表10所示：

表10

PardID	Loc	Offset	SequenceID
				1	/a/1/file_1	50	6
2	/a/2/file_2	112	8
				3	/a/3/file_1	0	5

步骤810，丢弃重复的数据。

在发生Failover情况下，由于要重新发送(Replay)数据，可能存在重复的数据，在网络原因丢包时也可能重传的数据。

此时，直接丢弃该数据。

步骤811，流式计算节点对所述第一存储元信息进行持久化处理；

第一存储元信息存在于内存当中，一旦机器宕机，或者，进程崩溃重启，内存中的第一存储元信息就会丢失。

因此，如图4所示，为了在FailOver的时候能够恢复第一存储元信息，可以将第一存储元信息(MetaFile)通过序列化存储到磁盘(即分布式文件系统，如MetaDir目录)上，成为CheckPoint。

在具体实现中，可以定时进行持久化处理，也可以在满足某个条件时进行，本申请实施例对此不加以限制。

步骤812，当故障转移时，流式计算节点采用持久化处理的第一存储元信息进行恢复处理；

在实际应用中，可以加载持久化处理的第一存储元信息(即CheckPoint)至内存，从一个CheckPoint中通过反序列化够恢复到最后一次做CheckPoint时的RedoLogMeta的状态。

因为系统可能会在两次CheckPoint之间崩溃，或者机器可能在两次CheckPoint之间宕机，因此如果没有额外措施，最后一次CheckPoint之后的信息将会丢失。

这里分两种情况，一种是最后一次CheckPoint后写入的数据，另一种是最后一次CheckPoint后打开/关闭分区。

对于数据来说，因为在落地成功后会生成RedoLogMessage，所以数据可以通过读RedoLogMessage来恢复。

而对已打开/关闭来说，也必须采用同样的方法在磁盘上持久化，才能够找回最后一次CheckPoint之后的打开/关闭分区操作，所以维护了一个名为RedoLogMeta的文件，记录打开/关闭分区的操作。

即第一存储元信息中标识有当前打开的分区，使得可以从当前打开的分区对应的存储子目录中查找最新的存储序列号；

采用所述第二候选存储序列号所属数据的第一存储操作消息更新第一存储元信息。

在实际应用中，保存RedoLogMessage的文件并一般不止一个，而是有多个文件保存相关信息，因此，文件按照顺序进行命名，可以确定一个大概范围的先后顺序。

例如，文件1保存了SequenceId为1-10的数据的RedoLogMessage,文件2保存了SequenceId为11-20的数据的RedoLogMessage，不需要打开两个文件，而凭借文件名的序列号即可知道文件1中RedoLogMessage排序在文件2之前，若需要查找SequenceId为8的数据的RedoLogMessage，则可以打开文件1。

例如，持久化的RedoLogMessage如表11所示：

表11

分布式文件系统如表12所示：

表12

Part1	Part2	Part3
			Racord SequenceID:1	Racord SequenceID:2	Racord SequenceID:3
Racord SequenceID:4	Racord SequenceID:7	Racord SequenceID:5
			Racord SequenceID:6	Racord SequenceID:8	Racord SequenceID:9

若RedoLogMeta中记录当前打开的分区为Part2，则第二候选存储序列号SequenceID为8，从Part2中读取SequenceID为8的数据，并采用其RedoLogMessage更新RedoLogMeta。

则更新后的RedoLogMeta如表13所示：

表13

步骤813，碎片节点对所述第二存储元信息进行持久化处理；

第二存储元信息存在于内存当中，一旦机器宕机，或者，进程崩溃重启，内存中的第二存储元信息就会丢失。

因此，为了在FailOver的时候能够恢复第一存储元信息，可以将第二存储元信息通过序列化存储到磁盘(即分布式文件系统)上，成为CheckPoint。

步骤814，当故障转移时，碎片节点采用持久化处理的第二存储元信息进行恢复处理。

在实际应用中，加载持久化处理的第二存储元信息，(即CheckPoint)至内存，从一个CheckPoint中通过反序列化够恢复到最后一次做CheckPoint时的RedoLogMeta的状态。

即第二存储元信息中标识有当前打开的分区，则可以从当前打开的分区对应的存储子目录中查找最新的存储序列号；

需要说明的是，对于方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本申请实施例并不受所描述的动作顺序的限制，因为依据本申请实施例，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作并不一定是本申请实施例所必须的。

参照图9，示出了本申请的一种分布式数据的处理系统实施例的结构框图，该系统包括一个或多个碎片节点910和一个或多个流式计算节点920，该碎片节点910具体可以包括如下模块：

数据接收模块911，用于接收客户端针对某一个表上传的数据；

数据存储模块912，用于将所述数据存储至所述表对应的存储目录中；

数据转发模块913，用于在存储成功时，将所述数据发送至相连的每个流式计算节点920进行流式计算。

在本申请的一个实施例中，所述数据存储模块912可以包括如下子模块：

范式查找子模块，用于查找所述表对应的范式；

范式校验子模块，用于采用所述范式对所述数据进行校验；

存储子模块，用于在通过校验时，将所述数据存储至所述表对应的存储目录中。

在本申请的另一个实施例中，所述表划分成一个或多个分区，每个分区对应存储目录中的存储子目录；

所述数据存储模块902可以包括如下子模块：

文件封装子模块，用于将符合所述分区的数据，按照文件大小和/或时间封装至一个或多个文件中；

文件存储子模块，用于将所述一个或多个文件存储至所述分区对应的存储子目录中。

在本申请的一个实施例中，碎片节点910还可以包括如下模块：

其中，所述第一存储操作消息包括如下的一个或多个参数：

所述第二存储操作消息包括如下的一个或多个参数：

在本申请的一个实施例中，流式计算节点920可以包括如下模块：

碎片节点910还可以包括如下模块：

在本申请的一个实施例中，所述第一更新模块可以包括如下子模块：

第一目标存储操作消息判断子模块，用于判断在所述第一存储元信息中是否存在第一目标存储操作消息；若是，则调用第一替换子模块，若否，则调用第一添加子模块；所述第一目标存储操作消息与所述第一存储操作消息表征数据所属的文件相同；

第一替换子模块，用于将所述第一存储操作消息替换所述第一目标存储操作消息；

第一添加子模块，用于将所述第一存储操作消息添加到所述第一存储元信息中；

所述第二更新模块可以包括如下子模块：

第二目标存储操作消息判断子模块，用于判断在所述第二存储元信息中是否存在第二目标存储操作消息；若是，则调用第二替换子模块，若否，则调用第二添加子模块；所述第二目标存储操作消息与所述第二存储操作消息表征数据所属的文件相同；

第二替换子模块，用于将所述第二存储操作消息替换所述第二目标存储操作消息；

第二添加子模块，用于将所述第二存储操作消息添加到所述第二存储元信息中。

在本申请的一个实施例中，流式计算节点920还可以包括如下模块：

丢弃模块，用于丢弃重复的数据。

在本申请的一个实施例中，所述数据检验模块可以包括如下子模块：

丢失判定子模块，用于在所述第一存储操作消息的存储序列号大于目标存储序列号时，判定数据丢失；

重复判定子模块，用于在所述第一存储操作消息的存储序列号小于目标存储序列号时，判定数据重复；

在本申请的一个实施例中，所述第一存储元信息中标识有当前打开的分区；

所述读取模块可以包括如下子模块：

第一候选存储序列号计算子模块，用于计算在所述第一存储操作消息的存储序列号，与，第一存储元信息中最新的存储序列号之间的第一候选存储序列号；

分区数据读取子模块，用于从当前打开的分区对应的存储子目录中读取所述第一候选存储序列号对应的数据。

第一持久化模块，用于对第一存储元信息进行持久化处理；

碎片节点910还可以包括如下模块：

第二持久化模块，用于第二存储元信息进行持久化处理；

所述第一恢复模块可以包括如下子模块：

第一加载子模块，用于加载持久化处理的第一存储元信息；

所述第二存储元信息中标识有当前打开的分区；

所述第二恢复模块可以包括如下子模块：

第二加载子模块，用于加载持久化处理的第二存储元信息；

对于系统实施例而言，由于其与方法实施例基本相似，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

本说明书中的各个实施例均采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似的部分互相参见即可。

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

在一个典型的配置中，所述计算机设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括非持续性的电脑可读媒体(transitory media)，如调制的数据信号和载波。

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

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

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

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

最后，还需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者终端设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者终端设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者终端设备中还存在另外的相同要素。

以上对本申请所提供的一种分布式数据的处理方法和一种分布式数据的处理系统，进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本申请的限制。

Claims

1.一种分布式数据的处理方法，其特征在于，包括：

碎片节点接收客户端针对某一个表上传的数据；

碎片节点将所述数据存储至所述表对应的存储目录中；

2.根据权利要求1所述的方法，其特征在于，所述碎片节点将所述数据存储至所述表对应的存储目录中的步骤包括：

查找所述表对应的范式；

采用所述范式对所述数据进行校验；

3.根据权利要求1或2所述的方法，其特征在于，所述表划分成一个或多个分区，每个分区对应存储目录中的存储子目录；

4.根据权利要求1或2或3所述的方法，其特征在于，还包括：

碎片节点在成功存储数据时生成第一存储操作消息；

碎片节点在打开或关闭分区时生成第二存储操作消息；

其中，所述第一存储操作消息包括如下的一个或多个参数：

所述第二存储操作消息包括如下的一个或多个参数：

5.根据权利要求4所述的方法，其特征在于，还包括：

碎片节点采用所述第二存储操作消息更新第二存储元信息。

6.根据权利要求5所述的方法，其特征在于，

所述流式计算节点采用所述第一存储操作消息更新第一存储元信息的步骤包括：

7.根据权利要求4或5或6所述的方法，其特征在于，还包括：

当数据重复时，则丢弃重复的数据。

8.根据权利要求7所述的方法，其特征在于，

所述流式计算节点对比所述第一存储操作消息与在先更新的第一存储元信息，判断数据是否丢失或重复的步骤包括：

9.根据权利要求7所述的方法，其特征在于，所述第一存储元信息中标识有当前打开的分区；

所述从存储目录中读取丢失的数据的步骤包括：

10.根据权利要求1或2或3或4或5或6或8或9所述的方法，其特征在于，还包括：

流式计算节点对第一存储元信息进行持久化处理；

碎片节点对第二存储元信息进行持久化处理；

11.根据权利要求10所述的方法，其特征在于，

所述第一存储元信息中标识有当前打开的分区；

加载持久化处理的第一存储元信息；

所述第二存储元信息中标识有当前打开的分区；

加载持久化处理的第二存储元信息；

12.一种分布式数据的处理系统，其特征在于，所述系统包括一个或多个碎片节点和一个或多个流式计算节点，其中，所述碎片节点包括：

数据接收模块，用于接收客户端针对某一个表上传的数据；

13.根据权利要求12所述的系统，其特征在于，所述碎片节点还包括：

其中，所述第一存储操作消息包括如下的一个或多个参数：

所述第二存储操作消息包括如下的一个或多个参数：

14.根据权利要求13所述的系统，其特征在于，

所述流式计算节点包括：

所述碎片节点还包括：

15.根据权利要求13或14所述的系统，其特征在于，所述流式计算节点还包括：

丢弃模块，用于丢弃重复的数据。

16.根据权利要求12或13或14或15所述的系统，其特征在于，

所述流式计算节点包括：

第一持久化模块，用于对第一存储元信息进行持久化处理；

所述碎片节点还包括：

第二持久化模块，用于第二存储元信息进行持久化处理；