基于Hadoop的分布式非结构化数据采集系统*

梁柏山1杨启蓓2龙忠建3

摘要：本文所描述的对于非结构化数据，特别是对于海量日常办公文档（如Excel）中的非结构化数据，进行分布式、并行采集的解决方案，能够帮助用户不断发掘并重复利用其积累的各类数据，提高用户数据重复利用的价值，对于云计算以及大数据在企业日常业务场景中的实际应用，具有良好的应用和推广前景。

关键词：Hadoop；HDFS；MapReduce；数据抽取；非结构化数据；

1.引言

近年来，企业对自身累积的越来越多的数据进行管理的需要日益强烈。这些累积数据，除了来自传统的在线交易处理系统和管理信息系统外，还来源于不断快速增长的半结构化和无结构化数据，诸如企业内部的日常办公数据Excel文档、email归档、callcenter对话记录、客户反馈记录、企业内部应用数据等。

如何更加有效、低成本的处理这些大量的数据，且能够自然地融入企业日常工作，并不断挖掘出企业现有海量数据信息的新价值，从而帮助企业发现并开拓新的细分市场，在复杂多变的市场环境中更为准确地把握潜在的市场脉动，是一个亟待解决的问题。

而今涌现的大数据技术的核心价值在于，将以往只有大企业付出高额成本才能获取的高端产品和服务，逐渐转变为众多中小微型企业，乃至普罗大众也可以使用的通用型服务技术。

大数据究其核心思想在于，从庞大的数据集中不断挖掘出新的价值。随着大数据技术的不断成熟与实际应用，当今信息技术的变革重点已经从“技术价值”的挖掘转移到对“信息价值”的挖掘与价值再利用上来[1]。

本文在实际项目研究中总结并提出了一种基于开源ApacheHadoop，特别是利用MapReduce开源框架进行非结构化数据的分布式并行采集处理方案，以满足实际中用户对于海量分散数据信息的归档和数据价值挖掘再利用的需要。

MapReduce[2]是Google提出的一种分布式海量数据处理模型。而其开源实现ApacheHadoop项目中的MapReduce则是一个高性能的批处理分布式计算框架，可以用于对海量数据进行并行分析和处理。与传统数据仓库和分析技术相比，MapReduce更适合处理各种类型的数据，包括结构化、半结构化和非结构化数据。

图MapReduce模型工作原理

MapReduce并非使得某种特定类型的运算处理更快，而是帮助系统应用开发人员可以做到以前无法做到的事情，诸如不必考虑或担忧运算处理的并行化，以及硬件故障情况下的诸多问题。

2.分布式非结构化数据采集方案——以Excel文档为例

本方案中对Excel数据采集所使用的基本方法，是利用Hadoop系统所提供的MapReduce服务来完成各类Excel数据的抽取与统计处理。

Hadoop的MapReduce框架中，map和reduce函数模型遵循如下常规格式：

map：（K1，V1）→list（K2，V2）

reduce：（K2，list（V2））→list（K3，V3）

一般而言，map函数输入的键/值类型（K1和V1）不同于输出类型（K2和V2），reduce函数的输入类型必须与map函数的输出类型相同，但其输出类型不必如此。

用户（系统开发人员或第三方系统开发人员，以下简称“用户”）通过系统提供的数据采集公共接口所提交的，实际上是基于MapReduce框架的的工作任务包（Job）。

一般情况下，在编写Hadoop中的MapReduce任务包时，用户需要分别通过InputFormat和OutputFormat指定输入和输出格式，并定义Mapper和Reducer指定map阶段和reduce阶段的处理方式。

系统所提供的ExcelMapReduce任务包支持，则有针对性地扩展了Hadoop中MapReduce的InputFormat接口。即利用ApachePOI开源项目所提供的Excel文档解析组件，对MapReduce的InputFormat接口进行扩展，在用户进行业务数据处理的Mapper方法之前，将所有待处理Excel文档数据内容进行预处理，转换为MapReduce框架中的通用Text结构（实际上就是可序列化的UTF8编码字符串），且按照系统标准自定义其内容格式。如此，即在默认情况下，系统为用户屏蔽Excel内部处理细节，方便用户快速完成其业务数据处理。

用户可以在其Mapper或Reducer方法中定义所需数据处理流程，或者是直接使用Hadoop所提供的默认IdentityMapper和IdentityReducer，将Excel文档中的所有数据内容导出为文本文件。该文本文件的内容格式使用的是Hadoop默认的TextOutputFormat——将键和值转换成字符串并用Tab分隔一条记录一行进行输出。

2.1用户任务包

用户输入任务包必须按照系统平台规范格式打包成zip压缩包，并以“.job”后缀结尾（如manipulate-statistics.job）提交至系统平台进行处理。该任务包主要包括如下内容：

●job.plist文件

该文件主要用于说明用户所需处理的任务内容，如任务名称、描述、主程序执行入口、数据输入/输出目录（相对路径）、数据输出回调接口等内容。

该文件实际上是一个UTF-8格式（无BOM标记）存储的纯文本文件，其内容格式类似于windows系统中的ini配置文件，所有字段标识皆为小写字母。

例如：

job.name=manipulate-statistics

job.description=处理上一年度至今计划执行数据统计

job.main=entrance.class

job.input=xls，xlsx

job.output=data-out/

job.callbacks=

上述文件内容即定义了一个：

●名为“manipulate-statistics”的任务【必填项】；

●其描述信息为“处理上一年度至今计划执行数据统计”【选填项】；

●主程序入口为entrance.class，也可以使用jar包作为该项内容属性，但此时jar包中必须有Main方法入口的相关说明信息（参照相关Java规范）【必填项】；

●数据使用任务包中的data目录下的所有Excel文档——此处既包括标准xls文档，也包括Excel的xml扩展文档，相关文档后缀以逗号分隔【必填项】；

●数据输出目录使用data-out，如果不指定，则由系统平台为其创建默认输出目录，且无论是否指定输出目录名，其在系统平台中的实际物理位置都由系统平台决定，一般来说是按照用户在平台中的用户账号或其使用的代理用户账号的私有目录作为根路径，如hdfs：//someone/jobs/{eejo-qeoi-rrqs-ddpq-1ipqj}/data-out/【选填项】；

●最后，则是任务结束后所使用的通知或数据反馈服务接口地址，一般情况下需要配合平台Web公共服务系统来使用该标识，且只有系统平台开发人员可以使用【选填项】。

除系统平台默认的标识属性以外，用户还可以自定义其他标识属性，但也必须按照“名称=值”方式进行定义，且名称标识不能以“job”标识开头，一般情况下，系统平台建议使用“usr”作为起始标识符。系统平台会自动将其加载，以供用户运行时使用。

●libs目录

该目录中包含任务执行所需的所有第三方库文件（jar），以及这些库文件所使用的相关配置文件等。

●classes目录

该命令中包含所有任务处理程序编译后得到的javaclass文件，以及这些class文件所必需的相关配置文件等。

●model目录

对于比较复杂的Excel文档，用户还可以自定义数据schema，用于模式化处理相关数据内容。这些数据自定义schema对应的文件都在这里放置。

系统平台对于用户自定义的schema文件内容格式并无强制性要求，只是建议使用xml作为数据schema标准存储方式。如果用户自己负责处理其自定义数据schema内容，系统平台也将这些schema解析的任务交由用户处理，否则，系统平台会自动将这些定义内容加载，并提供给用户程序使用。

●data目录

系统平台同时也支持用户在提交其任务包的同时，包含此项任务所需处理的Excel文档。所有与任务相关的Excel文档都放置于此data目录中。

系统平台会在任务执行前，自动将该目录下的所有数据提供给平台内部各计算节点，以做到真正的数据并行化处理。

2.2系统任务处理

系统在处理用户提交的任务包时，会首先解析job包中的job.plist文件，并对内容进行检查，若不符合要求（如普通用户而非系统开发人员提交了job.callbacks任务内容）则不执行任何任务。

在检查用户提交的任务包并确认审核通过后，系统会根据用户job.plist文件列表中的标识属性，将对相关数据进行检查：主要是确认用户指定的Excel输入文件是否存在，无论是在系统中，还是在用户提交的任务包中。若用户指定Excel输入文件在任务包中，则首先将其提交至系统内部进行存储，并在确认存储完成后，方进入下一步任务执行。

在加载相关系统默认配置和用户自定义配置后，系统会尝试启动用户定义的主程序来对Excel数据进行处理，其过程大致如下：

将用户指定Excel文件进行分配（split），且由于用户提交的Excel文档大多为小文件，为了提高整体并行计算的效率并充分利用系统资源，系统首先会对这些文件进行归并打包（如果是已经存储于系统中，则这一步已经预先完成），这些文件包的大小一般会与系统所配置的默认数据块大小相符，以便于在系统多个计算节点中并行抽取并采集数据。

分配（split）算法是系统针对Excel文档数据处理所做的针对性功能扩展之一。默认情况下，可以按照文件包的数量、文件包中的文件数量，依据“数据就近原则”，对系统中各计算节点分配各个Map任务和Reduce任务。

Map任务和Reduce任务的具体执行，则由用户提交的程序控制。系统负责按照标准格式，将Excel文档数据按照通用格式解析封装给用户程序，用户程序从中抽取其所需数据，并进行相关计算处理，结果由Reduce程序负责汇集并存储与系统中。

如果是系统开发人员提交的任务包，则系统还会自动将计算结果复制至系统Web公共服务子系统中，以提供外部其他第三方系统使用。其处理主要是通过job.plist文件中的job.callbacks标识指定的系统内服务接口地址，将数据导出至系统开发人员所需位置。

如果是第三方系统开发人员提交的任务包，则必须通过系统Web公共服务子系统所提供的任务处理Web服务及其UI交互，来完成结果数据的后续处理。

3.实验和分析

实验系统环境按照ApacheHadoop官方推荐配置可以选择使用Redhat企业版或者CentOS5/664位系统环境，也可以使用SUSE1164位系统环境。

本次实验中系统环境以小型局域网为核心搭建多台CentOS6.2（64位）版本系统物理机ApacheHadoop集群。集群内部以多主机内部域名指向为主，且未使用DNS来统一管理多主机集群。

本次实验的目的主要在于，通过特定场景中分散数据的采集与分析，来验证系统有关数据抽取各类设计的可行性和可操作性。为此选取日常办公文档中用的最多的Excel文档，作为非结构化数据分布式采集的主要实验场景。

Excel数据的采集与统计可以使用多种方法。比如可以在用户或其所使用的第三方系统中增加前置机，在应用场景中即时收集并采集所需数据，并将Excel数据采集结果或连带Excel文档传递给系统。但是这种方式要求能够事先圈定要采集的数据内容范围，且当数据采集需求发生变化时，还需要重新采集相关Excel数据。此种方式不仅无法保障数据采集的整体质量，且会造成整体数据采集架构设计的紧耦合效应，并对第三方系统产生连带影响（side-effect）。

第二种方式，也即是本次实验系统所采用的方式。它通过将多个第三方系统中的Excel文档在系统中进行归档处理，一方面充分利用了系统本身的数据归档特性，另一方面也能够实现数据重复利用的价值。也就是说，与其对所有Excel文档集合进行不完善的预处理，不如将其汇总归档存储于分布式系统内部，在后期根据需要完成各类数据采集与综合统计的功能，并可以充分利用中长期累积“大数据”的优势，发掘出以往未能觉察的新问题、新价值。

本次实验系统进行Excel数据采集的工作流程大致如下：

①系统提供Excel文档归档接口，由用户或第三方系统手工或自动将Excel文档及其相关元数据提交至系统；

②系统根据Excel文档的相关元数据，对Excel文档进行归档合并，并利用Hadoop系统完成分布式存储，相关存储信息会及时存储于系统中的元数据库中，以供后期随时查询与调阅；

③系统提供数据采集的公共接口服务，为不同场景中的Excel数据采集需求提供技术支持，系统开发人员或第三方系统开发人员可以按照其需要，完成相关数据采集任务的提交与计划执行工作；

④系统会将最终结果按照其所需的数据格式或接口服务，返回至用户或第三方系统以供其查询或进行应用集成。

3.1数据准备

模拟实际业务场景中的业务类Excel文档作为实验数据。这些Excel文档来源主要包括，ApachePOI项目的测试用例文档、用户各类统计报表，以及其他各种存档类文件。

这些文档大小都在10MB以内，且其中80%的Excel文档大小都在1MB以内，文档数据内容则包含多种形式的数据表格与运算公式。

所有从Excel文档中采集的数据，都以UTF8编码格式存储为文本文件，采集过程中并未对数据做任何运算处理，仅是将数据抽取并输出。且这些采集得到的数据中，已经将原Excel数据内容的部分元数据信息包含其中。比如，数据所属工作簿、单元格标识等信息。

3.2结果与分析

Excel文档数据采集实验的结果数据如下图所示。

图4.2Excel数据采集耗时曲线

从图中可以清晰看出，随文档数量增长变化，数据采集所需时间并无明显加速，而是较为平稳地呈线性增长。

由于实验样本Excel文档大多属随机抽样得到，且80%左右的Excel文档实验样本都属于小文档（文档大小小于1MB），如此一来系统中各计算节点上的数据采集负载也处于平均状态。

从实验统计数据来看，Excel文档数据采集在模拟业务场景中主要表现为计算密集型应用，数据抽取所带来的负载压力主要体现在对计算节点的CPU资源占用之上，且随文档大小而起伏变化。

数据抽取过程中各计算节点的内存资源变化较为平稳。这也与实验样本特征相符。实验系统所模拟的用户实际业务场景中，大多数业务过程中产生的Excel文档都属于小文档。

4结语

本系统实验中所完成的测试内容，都达到了实验目的。但是，从系统实验的统计数据以及相关文献资料中，也指出了一些实验系统环境中未能测试到的问题，并主要表现为如下2个方面：

●Excel数据采集小文件效率问题处理

在之前章节的研究中已经指出，系统所使用的HDFS分布式文件系统最初是为流式访问大文件而设计的，对于大量小文件的存储和处理效率存在很多问题，并主要表现在对于系统计算节点集群中的主节点（NameNode）内存占用，以及MapReduce处理过程中产生过多Mapper处理子流程的问题。

然而实际业务场景中，大量Excel小文件，且特别是小于1MB的小文件占据着很大比例。如此一来，在系统的实际生产环境中，不得不面临海量Excel小文件的处理问题。

在相关文献研究与分析中也已经指出[3]，可以通过多种技术方案来解决这一问题，分别为HadoopArchive、SequenceFile、MapFile和CombineFileInputFormat。

在系统中所使用的解决方案则是一种综合处理方法。在用户通过系统WebUI子系统提交Excel文件时，利用MapFile将所有Excel小文件进行归档存储；而对于开发人员提交的任务包，则采用SequenceFile和CombineFileInputFormat相结合的方式进行处理，因为此时Excel文档的处理目的主要是进行流式数据采集，且要兼顾分片（split）后这些文件的分布式存储位置，以提高处理效率。

●大量非结构化数据导入HBase的效率问题处理

大量非结构化数据导入HBase处理过程中同样也面临实际处理效率问题。实验系统中所采用的HBase接口与MapReduce结合方式，在应对海量数据同时导入的情况时，其性能会有很大损耗，对系统计算节点集群的资源损耗也会急剧上升。

故而在系统中所采用的主要解决方案是，充分HBase的bulk-load功能来应对海量数据导入。与实验系统使用的方法相比，会降低对集群计算节点的CPU资源损耗，并降低网络资源占用[4]。

当然，由于我们自身的能力所限，在项目研究和系统实践中遇到的一些问题还没有能够得到完满解决，如对于多种类型日常文档（Word、Excel、PowerPoint等）非结构化数据采集的模式识别问题，以及更加方便的非结构化数据可视化采集工具等，都需要进一步的研究与讨论。

参考文献：

[1]ViktorMayer-Schönberger，KennethCukier.大数据时代：生活、工作与思维的大变革[M].浙江人民出版社，2013：97

[2]J.Dean，G.Sanjay.MapReduce：SimpliedDataProcessingonLargeClusters[J].CommunicationsoftheACM，2008，50thanniversaryissue：107-113.

[3]洪旭升，林世平.基于MapFile的HDFS小文件存储效率问题[J].计算机系统应用，2012，21（11）：180

[4]Cloudera.BulkLoadsinHBase[EB].