一种大数据量数据处理方法及系统的制作方法

专利名称：一种大数据量数据处理方法及系统的制作方法
技术领域：
本发明涉及数据处理技术，特别是涉及一种大数据量数据处理方法及系统。
背景技术：
在很多应用场景中，经常会有如下的数据处理过程发送方将某些数据以 一定的格式保存在一个文件中，然后将文件发送给接收方，接收方接收到文件 之后对文件中的内容进行解析，并进行相应的逻辑处理。
在上述数据处理过程中，如果文件不是很大，而且接收方对处理时间又没 有很高的要求，则此时可以用单台服务器或单线程进行处理。这种情况下，系 统仍会运行正常，但接收方处理这些文件数据的时间可能较长。但是，如果文 件很大或者文件数量很多，而接收方对处理时间又有很高的要求，例如接收方
要求对于发送方传输过来的文件数据必须在1分钟内(或者更短时间内)处理 完毕。此时，单台服务器或单线程的处理系统就不能满足需求。
很多情况下，发送方到接收方的文件数据是定时传送的，比如5分钟一次， 而接收方能够容忍的数据最大延时是有限制的，此时如果接收方对传送的数据 在间隔期内处理不完，就会形成恶性循环，上个周期内的数据还未处理完毕， 新的数据又传送过来，这样接收方的数据延时就会越来越多，最后出现系统崩溃。
在很多大型应用中，都会出现这种大数据量的数据处理需求，例如在教育 行业学校需要逐级向教育局上报学生数据，大型网站日志的处理，两个系统间 的数据同步，等等。因此，需要提供一种能够在规定时间内处理大数据量数据 的方法，緩解数据的延时处理。

发明内容
本发明所要解决的技术问题是提供一种大数据量数据处理方法及系统，以 解决大数据量数据无法在规定时间内处理造成处理延时，最后造成系统崩溃的 问题。为解决上述技术问题，根据本发明提供的具体实施例，本发明公开了以下
技术方案
一种大数据量数据处理方法，包括
根据原始文件命名规则分配服务器，将原始文件拆分为小文件；
针对拆分后的每个小文件，根据小文件命名规则再次分配服务器，对拆分 后的小文件进行处理。
其中，根据原始文件命名规则或小文件命名规则分配服务器的步骤包括 解析文件名，获取原始文件序列号；计算原始文件序列号％待分配服务器 总数+l;其中，％表示取模运算；根据所述计算结果值分配服务器。
其中，根据原始文件命名规则或小文件命名规则分配服务器的步骤包括 配置每台服务器处理的数据类型；解析文件名，获取文件中存储的数据类型； 根据所述配置，分配与所述文件中存储的数据类型相对应的服务器。
其中，根据小文件命名规则分配服务器的步骤包括解析文件名，获取拆 分后的小文件序列号；计算小文件序列号％待分配服务器总数+l;其中， %表示取模运算；根据所述计算结果值分配服务器。
优选的，将原始文件拆分为小文件之后，还包括将拆分后的小文件保存 到磁盘。
优选的，所述方法还包括对拆分和处理失败的操作进行重试；其中，对 拆分出错的操作重试一次，对处理失败的操作重试多次。
优选的，所述方法还包括将所有待拆分和待处理的文件存放在不同的目 录下。
其中，所述待拆分文件目录下的数据流程包括将原始文件存放到"待拆 分的原始文件存放目录，，；根据原始文件命名规则分配服务器之后，将待拆分 文件存放到"拆分文件时的临时目录"；对待拆分文件进行拆分，将拆分成功的 原始文件备份到"完全拆分成功的原始文件存放目录"，并将拆分后的小文件保 存到"分割之后的小文件存放目录"；将重试失败的原始文件备份到"拆分文件 时出错的原始文件存放目录"。
其中，所述待处理文件目录下的数据流程包括根据小文件命名规则再次 分配服务器之后，将"分割之后的小文件存放目录"下的待处理小文件存放到"处理小文件时的临时目录"；对待处理小文件进行处理，将处理成功的小文件 备份到"完全处理成功的小文件存放目录"，将进行重试的小文件备份到"有部 分记录未成功处理的小文件存放目录"，并将重试失败的小文件备份到"经过重 试之后还无法处理的小文件存放目录"。
一种大数据量数据处理系统，包括多台服务器，每台服务器包括
预处理单元，用于根据原始文件命名规则，判断待拆分的原始文件是否属 于自己处理，如果是，则触发拆分单元；并根据拆分后的小文件命名规则，再 次判断待处理的小文件是否属于自己处理，如果是，则触发处理单元。
拆分单元，用于将原始文件拆分为小文件；
处理单元，用于对拆分后的小文件进行处理。
其中，所述预处理单元通过文件名中的原始文件序列号判断待拆分的原始 文件是否属于自己处理，并通过文件名中的原始文件序列号或拆分后的小文件 序列号判断待处理的小文件是否属于自己处理。
其中，所述预处理单元通过文件中存储的数据类型，判断待拆分的原始文 件或待处理的小文件是否属于自己处理时，每台服务器还包括配置单元，用于 配置自己处理的lt据类型。
优选的，每台服务器还包括存储单元，用于将拆分后的小文件保存到磁盘。
优选的，所述存储单元采用目录结构，将所有待拆分和待处理的文件存放 在不同的目录下。
优选的，每台服务器还包括重试单元，用于对拆分和处理失败的操作进 行重试；其中，对拆分出错的操作重试一次，对处理失败的梯:作重试多次。
根据本发明提供的具体实施例，本发明公开了以下技术效果 首先，本发明提供了 一种针对大文件进行并发或分布式处理的方法和系 统，通过并发策略的控制，可以部署多台服务器同时对大数据量文件进行拆分 和处理，极大地提升了系统的处理能力，保证系统在规定时间内对文件处理完 毕。而且，这种通过文件命名规则分配服务器来拆分和处理文件的并发策略， 保证只有一台服务器可以对原始文件进行拆分，对于拆分之后的每个小文件，也只能有一台服务器对其进行处理，从而避免资源竟争。
其次，本发明提供了两种并发策略， 一种是根据文件名中的原始文件序列 号分配服务器，这种策略在文件数较多的情况下可以保持各台服务器的均衡
性；另一种是配置每台服务器能够处理的数据类型，将待处理文件按照数据类 型分配合适的服务器，这种策略在新增服务器的情况下只需修改配置表即可， 具有良好的扩展性。根据实际应用需求，本发明可以将两种并发策略结合使用， 因此，本发明所述系统能够最大限度地平衡各台服务器的繁忙程度；而且，具 有非常好的扩展性，当文件越来越大或者是越来越多的时候，通过新增服务器 就可以满足需求，即可以线性扩展，而不需要购买更高级的服务器，也不需要 重新部署以前已经运行的服务器。
再次，为了降低扫描文件带来的磁盘10 (Input/Output,输入/输出)压力， 可以将各个待拆分和待处理的文件放在不同的目录中，然后对目录中所有文件
进行緩存，对緩存中的文件处理完毕之后再去读取新的文件。


图1是本发明实施例所述一种大数据量数据处理方法流程图2是本发明实施例中目录结构下的文件拆分流程图3是本发明实施例中目录结构下的文件处理流程图4是本发明实施例所述一种大数据量数据处理系统的逻辑结构图5是图4所示系统中每台服务器的内部逻辑结构图。
具体实施例方式
为使本发明的上述目的、特征和优点能够更加明显易懂，下面结合附图和具体实施方式
对本发明作进一步详细的说明。
本发明提供了 一种针对大文件进行并发或分布式处理的方法和系统，通过 文件命名规则分配服务器的并发策略，可以部署多台服务器同时对大数据量文 件进行拆分和处理，极大地提升了系统的处理能力，保证系统在规定时间内对 大数据量文件处理完毕。
举例说明发送方每隔2分钟按照一定的格式生成多种类别(比如商品、 订单；单个类别的数据文件也可以有多个)的文件FileA (文件的容量很大，
8比如有200M)，并发送给接收方；接收方接收到文件FileA,对其进行后期逻 辑处理，其中逻辑处理可能比较复杂，需要做很多相关的事情，比如保存到数 据库等等。此时如果单台服务器的处理能力为10M/Min，则2分钟能处理20M 的数据，还剩下180M的数据没有处理完毕。本发明的目标就是要让接收方的 系统能够在2分钟内将所有的文件FileA处理完毕。
参照图1,是本发明实施例所述一种大数据量数据处理方法流程图。参照 上例，本实施例采用分布式多台服务器并发处理的方法，对发送方传送来的大 数据量文件进行业务逻辑处理。其中，所述多台服务器可以并发执行相同的程 序。
本实施例实现的一个前提是发送方传送过来的文件FileA需要有统一的文 件命名规范，不符合命名规范的文件将不会被处理。即发送方传送过来的文件 已经是按照规范命名的文件，接收方可以直接对文件名进行解析。
下面将以发送方一次传送过来的文件处理为例进行说明，具体处理过程如
下
5101, 对发送方传送过来的原始文件FileA进4于文件名解析；
5102, 根据解析结果分配一台服务器，对原始文件FileA进行拆分； S103，该服务器将原始文件FileA拆分为多个小文件FileY; 对文件进行拆分时，拆分成N个容量较小的文件FileY, N的大小视具体
情况而定，主要取决于有多少台服务器在进行处理。
S104,自动为拆分后的每个小文件FileY按照小文件命名规范进行命名； S105，对每个小文件FileY进行文件名解析；
5106, 根据解析结果为每个小文件FileY分配一台服务器进行处理；
5107, 每台服务器进行后期逻辑处理。
由上可知，原始文件和拆分后的小文件都有相应的命名规则，具体如下 原始文件命名规范
例力口文件名为DateTime_Sequence_DateType.TXT; 其中各参数意义如下
DateTime代表数据导出的时间，精确到秒，格式为20070209133010， 即年月日时分秒；
9Sequence代表数据分页(为了不让单个文件太大，可以采取分页措施)的 序列，也可称为原始文件序列号，假设定为3位，从001开始累加；
DateType代表文件中存储的数据类别，比如user代表用户数据，order代 表订单数据，sample代表商品数据。
从上面可以看出，单个数据类型DateType对应的数据文件可能会有多个。
拆分后的小文件命名规范
例Jt口文寸牛名为SubDateTime—DateTime—Sequence—SubSequence—retryX DateType.TXT;
各参数的意义如下
DateTime、 Sequence, DateType的意义与原始文件中的相同； SubDateTime代表子文件导出的时间，默认与DateTime相同，但是遇到
重试的时候两者就会不一样，具体见后面retry部分的说明；
SubSequence代表针对原始文件分割之后的小文件序列号，假设为4位，
从OOOl开始累加；
retry后面的X代表这个文件被实际处理进行重试的次数，当第 一次分割 的时候为O,失败一次之后变成l，以后进行累加，累加的时候需要注意前 面对应的SubDateTime也需要做相应的修改，规则为系统当前时间+重试间隔；
小文件的文件名中还保留DateTime,主要的目的是为了便于后续处理出 现问题的时候查错。
上述步骤S102和S106都需要根据文件名解析结果来合理分配服务器，即 在拆分原始文件和对拆分后的小文件进行处理时都需要调度服务器。如果从整 个服务器系统的执行来看，这是一个并发执行的过程，即分配一台服务器拆分 原始文件的同时，还可以分配另一台服务器处理上一次拆分的小文件。
本实施例提供了两种并发策略，在拆分原始文件和处理拆分后小文件的时 候都可以使用。并发策略的原则是保证只有一台服务器可以对原始文件进行 拆分，对于拆分之后的每个小文件，也只能有一台服务器对其进行处理，从而 避免资源竟争。
一种策略是根据文件名中的序号Sequence或者SubSequence进行取才莫， 计算公式如下Sequence/SubSequence %待分配服务器总数+l;
其中，"％，，表示取模运算；加1是为了保证计算结果不为0。
比如总的server凄史为3;
对文件名20070429160001_00x_order.txt; 00x即为Sequence;
计算x。/。3+l，若为1,则由serverl处理，若为2,则由server2处理，若 为3，则为server3处理。
默认情况下，小文件处理和原始文件拆分时判断的规则可以是一样的，即 可以都针对文件名中的Sequence进行判断。但优选的，为了保证各台server 间的均衡性，对小文件进行处理的时候还可以根据SubSequence来进行判断。
当然，根据文件名中的序号Sequence或者SubSequence，也可以通过其他 计算公式均衡的分配服务器，上述耳^莫的计算方法仅作为实施例进行说明。
这种策略可以比较平均地分配各台server,但是serverl和server2会较多 地处理一些文件，因为并不是所有的文件数都是3的倍数；另外，某些数据量 比较小的文件本来就只有一个文件，所以按照这个规则，肯定会被serverl处 理。所以，该策略适合于文件数较多的情况，文件数越多，各台server间的均 衡性就越好。但是，如果需要增加新的server,则需要将所有的server重新部 署。
另一种策略是对各台server设置其可以处理的、只有自己能处理的 DateType (数据类别)。
系统提供一份配置表，配置项为各台server能够处理的以及只有自己能处 理的DateType。比如配置serverl能处理order数据(订单数据)，配置server2 能处理user数据(用户数据)，配置server3能处理sample数据(商品数据)。 在进行该项设置的时候需要保证各台server间的配置不会冲突，如果有冲突， 则会提示配置出错。
这种策略适合于文件数较少的情况，而且该策略还有另外一个好处就是 当新增DateType对应的文件数据时，新增server不会影响已经部署好的server, 只需要修改配置表即可。
上述两种并发策略都可以很好地调度多台服务器同时进行文件拆分或处 理，在实际应用中，可以针对具体应用需求选择其中一种。优选的，还可以将两种并发策略结合起来，因为这两种策略并不是互相排
斥的。例如，可以指定多台server都可以处理DateType为order的文件数据， 但是user只能由server3处理，sample只能由server2处理；这样各server间的 处理就能够最大化平均了，最大限度地平衡各台server的繁忙程度。
在图1所示的拆分和处理过程中，如果采用第一种策略，就需要解析原始 文件名获耳又Sequence,并解析小文件名获取Sequence或SubSequence;如果采 用第二种策略，需要从文件名中获取DateType;如果采用两种策略的结合， 则需要同时获取Sequence或SubSequence及DateType。无论采用哪种并发策 略，都是根据文件名来判断该文件应该由哪台server进行拆分或处理，各server 只能处理属于自己的那些文件。
优选的，服务器对原始文件进行拆分之后，还需要将拆分后的小文件保存 到不兹盘，当对小文件进行处理时从磁盘读取。某台服务器拆分出来的小文件还 没有完全写入到磁盘的时候不允许被处理，因为若此时被处理，则另外的处理 服务器从小文件中读取出来的内容可能不完整。
优选的，如果在拆分或者处理过程中出现错误，则需要将出错部分进行重 试。并且，如果有很多文件等待拆分或处理，则可以按照时间先后顺利进行处 理。
综上所述，这种分布式多台服务器并发处理的方法，在针对一些大文件进 行处理的时候，可以大大提升系统的处理能力，最大限度地平衡各台服务器的 繁忙程度；而且，具有非常好的扩展性，当文件越来越大或者是越来越多的时 候，通过新增服务器就可以满足需求，即可以线性扩展，而不需要购买更高级 的服务器，也不需要重新部署以前已经运行的服务器。
本实施例还优选的，为了降低扫描文件带来的磁盘IO压力，可以将各个 待拆分和待处理的文件放在不同的目录中，然后对目录中所有文件进行緩存， 对緩存中的文件处理完毕之后再去读取新的文件，其处理的先后顺序取决于文 件名的自然排序(即按文件名中DateTime升序排列，时间早的先被处理)。
处理的目录结构可以如下
/root //顶级目录
/source—file //待拆分的原始文件存放目录
12/tmp—divide
/hostnameA /hostnameB
/source—smallfile /tmp—execute /hostnameA /hostnameB
/bak_sucs—file /20070212
/hour /20070213
/hour
/bak一sucs一sma11 /20070212
/hour /20070213
/hour
/bak一erroi:
/20070212
/hour /20070213
/hour
〃拆分文件时的临时目录 〃当前拆分服务器的hostname
〃
〃这些目录名称根据server多少动态分配 〃保存分割之后的小文件
〃具体对某个小文件进行业务逻辑处理的临时目录 〃当前处理服务器的hostname
〃
〃这些目录名称根据server多少动态分配
〃备份完全拆分成功的原始文件
〃当前曰期
〃当前日期下的小时，比如IO、 20
〃 〃
〃根据当前日期动态新增
〃备份完全处理成功的小文件
〃当前日期
〃当前日期下的小时，比如IO、 20
〃 〃
〃根据当前日期动态新增
〃备份有部分记录未成功处理的小文件
〃当前曰期
〃当前日期下的小时，比如10、 20
〃 〃
〃根据当前日期动态新增/error—divide 〃备份拆分文件时出错的原始文件
/20070212 〃当前日期
/hour 〃当前日期下的小时，比如10、 20
/20070213 〃
/hour 〃
...... 〃根据当前日期动态新增
/error—execute //备份经过重试之后还无法处理的小文件，超过5次处理失败的。
/20070212 〃当前日期
/hour 〃当前日期下的小时，比如10、 20
/20070213 〃
/hour 〃
...... //根据当前日期动态新增
其中，所述目录结构可以自行调整，在此仅作为实施例进行说明，比如/hour 这级目录是否需要，要根据系统中拆分出来的小文件数据量而定，因为OS(操 作系统)对文件系统中的文件数、目录树、单目录下最大文件数都有限制，而 且单目录下文件数如果太多，会严重影响系统的性能。
上述目录结构的生成过程实质上与图1所示的拆分和处理流程同步，可以 通过目录间文件的数据流反映图1所示流程，主要包括文件拆分和文件处理两 个数据流程，具体如下。
参照图2，是目录结构下的文件拆分流程图，参照上述目录结构说明 S201,从发送方传送过来的原始文件存^L到目录/source—file下； S202，根据文件名对目录/source—file下的待拆分文件分配服务器，此时， 为了避免各个线程对同一个文件进行拆分，将待拆分文件再存放到目录 /tmp一divide/hostname下，即存放到分配的服务器目录下，此过程称为重命名；
5203, 服务器对所述待拆分文件进行拆分，如果拆分成功，则将拆分出来 的小文件保存到目录/source—smallfile下，并将拆分成功的原始文件备份到目 录/bak—sues—file下；
5204, 如果拆分不成功，则进行重试，如果重试一次成功，则返回S203
14将拆分出来的小文件保存到目录/source一smallfile下，并将拆分成功的原始文 件备份到目录/bak—sucs一file下；如果重试一次仍不成功，则将重试失败的原始 文件备^f分到目录/error—divide下。
参照图3，是目录结构下的文件处理流程图，参照上述目录结构说明
5301, 拆分出来的小文件都存》文在目录/source—smallfile下；
5302, 根据文件名对目录/source—smallfile下的待处理文件分配服务器， 此时，同样为了避免各个线程对同一个小文件进行处理，将待处理文件再存放 到目录/tmp一execute/hostname下，即存放到分配的服务器目录下，此过程称为 重命名；
5303, 服务器对所述待处理文件进行逻辑处理，如果处理成功，则将处理 成功的小文件备4分到目录/bak—sues—small下；
5304, 如果处理出错，则进行重试；可以设置重试的次数，假设为5次。 将进行重试的小文件备份到目录/bak—error下，重试时，返回S301,即将
S303处理失败的小文件重新放回目录/source—smallfile下，由原来分配的服务 器对其进行再次处理；如果重试5次都没有成功，则将重试失败的小文件备份 到目录/error—execute下。
本实施例中，对原始文件的重试次数和对小文件的重试次数不同。若对原 始大文件拆分的时候出错，则直接重试一次，若还失败，则直接将文件移动至 错误目录，同时写错误日志和报警；若对小文件进行业务逻辑处理过程中出错， 则需要采取更加灵活的重试机制，因为通常原始文件拆分出错的概率很小，而 后期业务逻辑处理的失败会更多，所以对小文件进行多次重试。
对小文件进行多次重试时，需要配置一4分重试间隔列表，重试的次数和每 次向后推迟的时间都可以自己定义，比如定义为重试5次，重试5次之后若还 是失败，则不再进行处理，将其移动到错误目录中，同时写错误日志和报警。 所以，当某台服务器取到某个具体文件进行处理时，需要判断一下该文件的 SubDateTime是否比当前时间早，若早，则进行实际处理，否则不处理该文件。
如前所述，某台服务器拆分出来的小文件还没有完全写入到磁盘的时候不 允许被处理。因此，对于预防一个被拆分生成的小文件内容还没有完全被写入 磁盘的时候被处理，需要结合目录结构来完成。小文件先被写入到一个临时目录/source一smallfile中，当写入成功之后，再进行重命名操作，将其移动到另 外一个目录/tmp—execute/hostname。因为重命名操作是原子的，而且只是^f务改 一个文件指针链接，所以这样就可以保证数据的完整性。
本发明还提供了一种大数据量数据处理系统的实施例，参照图4，是本发 明实施例所述一种大数据量数据处理系统的逻辑结构图。
如图所述，所述系统采用分布式架构由多台服务器组成，每台服务器都可 以执行拆分和处理程序。针对发送方传送数据由接收方在规定时间内进行处理 的例子，所述系统部署在接收方，以下简称为接收方系统。接收方系统的多台 服务器可以并发执行相同的程序。
对于发送方传送过来的大文件FileA,接收方系统中多台服务器并发处理 文件FileA的流程如下
大文件FileA先被存放到目录/source—file下，每台服务器都会定时到该目 录下扫描发送方传送过来的大文件，并依据前述的并发策略(在此不再详述)， 根据文件名判断该文件是否由自己进行拆分。当某台serverA取到属于自己处 理的文件FileA之后，对文件进行拆分，拆分成N个容量较小的文件FileY， N的大小视具体情况而定，主要取决于有多少台server在进行处理。然后，再 依据并发策略，多台serverX根据文件名判断拆分后的各个小文件FileY是否 属于自己处理，当某台serverB取到属于自己处理的小文件FileY之后，对其 进行后期逻辑处理。
上述处理流程中，为了避免资源竟争，需要保证只有一台server可以对原 始文件FileA进行拆分；对于拆分之后的每个小文件FileY，也只能有一台server 对其进行处理。而且，各台server的繁忙程度要尽量均匀，不能出现某些server 非常繁忙而另外的server却很空闲的情况。本发明提供的两种并发策略可以保 证这些。同时，所述系统非常灵活，具有良好的可扩展性，能够支持各台server 独立配置处理某些类别的文件，这样在新增server时不需要重新部署以前已经 运行的server。
优选的，为了保证小文件读取的完整性，对原始文件进行拆分之后，还需 要将拆分后的小文件保存到磁盘。而且，拆分或者处理过程中若出现错误，则 需要将出错部分进行重试。若有4艮多文件等待拆分或处理，则按照时间先后顺利进行处理。
下面详细说明每台服务器的内部逻辑结构。参照图5，是每台服务器的内
部逻辑结构图。每台服务器都包括预处理单元U501、拆分单元U502、处理 单元U503。
所述预处理单元U501用于定时扫描磁盘目录，根据文件名判断该文件是 否属于自己处理。具体包括根据原始文件命名规则，判断待拆分的原始文件 是否属于自己处理，如果是，则触发拆分单元U502;并根据拆分后的小文件 命名规则，再次判断待处理的小文件是否属于自己处理，如果是，则触发处理 单元U503。所述拆分单元U502用于将原始文件拆分为小文件；所述处理单 元U503用于对拆分后的小文件进行逻辑处理。
根据前述的两种并发策略，如果采用第一种策略，则所述预处理单元U501 通过文件名中的原始文件序列号判断待拆分的原始文件是否属于自己处理，并 通过文件名中的原始文件序列号或拆分后的小文件序列号判断待处理的小文 件是否属于自己处理。
如果采用第二种策略，则所述预处理单元U501通过文件中存储的数据类 型，判断待拆分的原始文件或待处理的小文件是否属于自己处理时，此时每台 服务器还包括配置单元U504，用于配置自己处理的^t据类型。预处理单元 U501进行判断时，根据所述配置判断文件中存储的数据类型是否是自己可以 处理的类型。
优选的，为了保证小文件读取的完整性，服务器还包括存储单元U505， 用于将拆分后的小文件保存到磁盘。而且，为了降低扫描文件带来的磁盘10 压力，所述存储单元U505采用目录结构，将所有待拆分和待处理的文件存^: 在不同的目录下。
优选的，每台服务器还包括重试单元U506，用于对拆分和处理失败的操 作进行重试；其中，根据应用需要，对拆分出错的操作重试一次，对处理失败 的操作重试多次。
综上所述，所述系统支持多台服务器并发执行，以提升系统的处理能力， 而且具有非常好的扩展性。
图4、图5所示系统中未详述的部分可以参见图1、图2、图3所示方法的相关部分，为了篇幅考虑，在此不再详述。
以上对本发明所提供的 一种大数据量数据处理方法及系统，进行了详细介
例的说明只是用于帮助理解本发明的方法及其核心思想；同时，对于本领域的 一般技术人员，依据本发明的思想，在具体实施方式
及应用范围上均会有改变 之处。综上所述，本说明书内容不应理解为对本发明的限制。
权利要求
1、一种大数据量数据处理方法，其特征在于，包括根据原始文件命名规则分配服务器，将原始文件拆分为小文件；针对拆分后的每个小文件，根据小文件命名规则再次分配服务器，对拆分后的小文件进行处理。
2、 根据权利要求1所述的方法，其特征在于，根据原始文件命名规则或 小文件命名规则分配服务器的步骤包括解析文件名，获取原始文件序列号；计算原始文件序列号％待分配服务器总数+l;其中，％表示取模运算； 才艮据所述计算结果值分配服务器。
3、 根据权利要求1所述的方法，其特征在于，根据原始文件命名规则或 小文件命名规则分配服务器的步骤包括配置每台服务器处理的数据类型； 解析文件名，获取文件中存储的数据类型；根据所述配置，分配与所述文件中存储的数据类型相对应的服务器。
4、 根据权利要求1所述的方法，其特征在于，根据小文件命名规则分配 服务器的步骤包括解析文件名，获^U斥分后的小文件序列号；计算小文件序列号％待分配服务器总数+l;其中，％表示取模运算； 根据所述计算结果值分配服务器。
5、 根据权利要求1所述的方法，其特征在于，将原始文件拆分为小文件 之后，还包括将拆分后的d 、文件保存到磁盘。
6、 根据权利要求1所述的方法，其特征在于，还包括 对拆分和处理失败的操作进行重试；其中，对拆分出错的操作重试一次，对处理失败的揚:作重试多次。
7、 根据权利要求1所述的方法，其特征在于，还包括将所有待拆分和 待处理的文件存放在不同的目录下。
8、 根据权利要求7所述的方法，其特征在于，所述待拆分文件目录下的数据流程包括将原始文件存放到"待拆分的原始文件存放目录"；.根据原始文件命名规则分配服务器之后，将待拆分文件存放到"拆分文件 时的临时目录"；对待拆分文件进行拆分，将拆分成功的原始文件备份到"完全拆分成功的 原始文件存放目录"，并将拆分后的小文件保存到"分割之后的小文件存放目 录"；将重试失败的原始文件备份到"拆分文件时出错的原始文件存放目录"。
9、 根据权利要求8所述的方法，其特征在于，所述待处理文件目录下的 数据流程包括根据小文件命名规则再次分配服务器之后，将"分割之后的小文件存放目 录"下的待处理小文件存放到"处理小文件时的临时目录"；对待处理小文件进行处理，将处理成功的小文件备份到"完全处理成功的 小文件存;^文目录"，将进行重试的小文件备^f分到"有部分记录未成功处理的小文 件存放目录"，并将重试失败的小文件备份到"经过重试之后还无法处理的小文 件存放目录"。
10、 一种大数据量数据处理系统，其特征在于，包括多台服务器，每台服 务器包括预处理单元，用于根据原始文件命名规则，判断待拆分的原始文件是否属 于自己处理，如果是，则触发拆分单元；并根据拆分后的小文件命名规则，再 次判断待处理的小文件是否属于自己处理，如果是，则触发处理单元。拆分单元，用于将原始文件拆分为小文件；处理单元，用于对拆分后的小文件进行处理。
11、 根据权利要求IO所述的系统，其特征在于所述预处理单元通过文件名中的原始文件序列号判断待拆分的原始文件 是否属于自己处理，并通过文件名中的原始文件序列号或拆分后的小文件序列号判断待处理的小文件是否属于自己处理。
12、 根据权利要求IO所述的系统，其特征在于所述预处理单元通过文件中存储的数据类型，判断待拆分的原始文件或待 处理的小文件是否属于自己处理时，每台服务器还包括配置单元，用于配置自己处理的数据类型。
13、 根据权利要求IO所述的系统，其特征在于，每台服务器还包括 存储单元，用于将拆分后的小文件保存到-兹盘。
14、 根据权利要求13所述的系统，其特征在于所述存储单元采用目录结构，将所有待拆分和待处理的文件存放在不同的 目录下。
15、 根据权利要求IO所述的系统，其特征在于，每台服务器还包括 重试单元，用于对拆分和处理失败的操作进行重试；其中，对拆分出错的操作重试一次，对处理失败的操作重试多次。
全文摘要
本发明公开了一种大数据量数据处理方法及系统，以解决大数据量数据无法在规定时间内处理造成处理延时，最后造成系统崩溃的问题。所述方法包括根据原始文件命名规则分配服务器，将原始文件拆分为小文件；针对拆分后的每个小文件，根据小文件命名规则再次分配服务器，对拆分后的小文件进行处理。本发明可以部署多台服务器同时对大数据量文件进行拆分和处理，极大地提升了系统的处理能力，保证系统在规定时间内对文件处理完毕。而且，所述系统具有非常好的扩展性，当文件越来越大或者是越来越多的时候，通过新增服务器就可以满足需求，即可以线性扩展，而不需要购买更高级的服务器，也不需要重新部署以前已经运行的服务器。
文档编号G06F17/30GK101582064SQ20081009759
公开日2009年11月18日 申请日期2008年5月15日 优先权日2008年5月15日
发明者唐益鹏, 洪文其 申请人:阿里巴巴集团控股有限公司