谈地震大数据处理的性能优化和成本

地震行业经过多年的建设发展，特别是“九五”数字化改造项目 和“十五”数字地震观测网络项目以来，已形成一个覆盖全国范围的多学科、多测项的智能化前兆网络观测系统，在观测技术方面已经有了一个质的飞跃。数字化后的地震前兆观测数据产出，无论从采样率和采样精度上都有大幅提高，使观测数据量激增。早期，前兆观测系统在数据加工处理环节，大都靠人机交互方式完成，因此效率不高，且很难保证处理结果的客观性。为了提高数据分析效率，进而提高地震预测的准确度，在地震监测领域开展地震行业引入大数据分析的手段，已经迫在眉睫。

　　近些年，Hadoop开源大数据项目的日益成熟，给地震预测和分析行业带来了可行的解决方案。Hadoop的并行处理框架Map-Reduce，对结构化和半结构化数据的处理均能够实现多台节点并行化，可以很大程度上提升数据分析处理的速度，为地震预测争分夺秒。本文重点针对数据的存储与分析两个方面，结合设备合理有效利用的需求，对Hadoop的存储和分析模型进行针对性优化，以达到成本的优化和性能的提升。

　　一、Hadoop地震大数据处理模型

　　Hadoop大数据处理模型简介。Google使用GFS、Bigtable、MapReduce、Chubby等一系列颠覆传统的设计很好地解决了搜索引擎的问题，并以此为基础建立了大数据处理平台。这个平台上支撑了包括Google Map、Google Earth、Google Finance等数十个应用。当Google把这些技术以学术论文的形式公开后，业界以此为蓝本实现了一套类似的系统，即Hadoop。目前Hadoop 由Apache软件基金会管理，它的核心是HDFS和MapReduce。围绕着这两个基础组件，开源社区相继形成了HBase、Hive 和ZooKeeper等成员。真正形成了一个大数据处理的生态系统，并且仍然在衍化和扩充中。

　　二、地震大数据处理成本和性能优化

　　(一)磁盘阵列RAID替代HDFS三副本

　　Hadoop的默认存储采用自带的HDFS分布式文件系统，默认情况下，HDFS采用3副本存储，对于地震数据来说，HDFS默认的多副本存储有几个劣势：首先，地震监测的源数据，大都通过各种传感器或人机交互方式来进行采集和录入到磁盘阵列等通用存储设备，通常很难直接使用HDFS专有接口进行存储，因此分析时，需要经过一次数据导入，将数据导入到HDFS当中，造成了极大的不便;其次，三副本的存储空间利用率为33.3%，对于海量数据的地址预测分析来说，成本相当昂贵;再次，HDFS属于开源项目，文件系统的可靠性、可维护性等方面均存在较多问题，不适合存储生产环境中的关键数据。

　　为了解决以上问题，本文提出采用磁盘阵列RAID存储来替代HDFS三副本存储，一方面省却了数据导入导出的过程，另一方面，传统RAID5和RAID6的使用，大大提高了存储空间利用率，节省了采购成本。

　　由于磁盘阵列可以通过NFS网络文件协议进行访问，因此通过在Hadoop中加入HDFS协议转换插件，将HDFS协议转换为NFS访问协议，从而将Hadoop的存储访问转换为对于磁盘阵列存储的访问。

　　(二)Hadoop数据布局机制

　　Hadoop中的数据默认是采用副本方式存储在HDFS上，Hadoop的各个组件，如Map-Reduce、HBase等，依赖副本机制进行容错，例如，当第一副本所在节点故障时，Hadoop的组件会自动访问第二副本上面的数据。但是，采用磁盘阵列替代HDFS后，文件就不再有副本的概念，虽然磁盘阵列的RAID机制能够保证数据自身的可靠性，但是无法保证Hadoop内部副本自动切换机制的容错机制能够正常工作。

　　由于磁盘阵列存储采用NFS网络文件共享协议导出，因此所有的计算节点看到的数据是完全一致的，因此可以认为任意一个节点均是一个文件副本的存储节点。按照Hadoop文件存储的原则，对文件按照定长的对象(如64 MB)进行切分，以保证Map-Reduce任务能够分发到不同的计算节点;对于每个对象，指定3个计算节点作为其存储副本所在节点。这样，Hadoop的内部各个组件，拿到文件的数据布局后，按照默认的算法进行任务分发即可，不需要做任何改变。

　　在为每一个对象的副本选择计算节点时，采用伪随机算法，保证每个计算节点被选中的概率基本一致，从而保证Hadoop系统在任务调度时，能够充分利用系统内的每一个计算节点，不会造成部分节点饿死的情形。

　　(三)Map-Reduce流程优化

　　Hadoop的Map-Reduce执行过程中，每个Map阶段结束前，需要将该阶段之前写入到磁盘上的多个结果文件进行归并，合并成一个结果文件;而Reduce阶段开始前，需要从各个Map任务端拉取Map的结果文件，并将所有的Map结果进行归并，形成最终的结果文件，进入到Reduce计算阶段。以上从Map后阶段到Reduce开始前的整个处理过程，称之为Shuffle处理过程。具体流程如图1。

　　图1　Hadoop的Map-Reduce过程

　　对于大的Map-Reduce作业，以上流程中的Shuffle过程中有大量的IO操作，尤其是数据拉取阶段，Reduce作业节点需要从Map作业节点通过网络传输拉取数据，该过程消耗的时间在整个作业中占10%以上的比重。而对于本文提出的使用磁盘阵列和NFS共享存储的架构，由于所有的数据均在共享存储上，因此该网络传输的过程完全可以省略。

　　三、结果和分析

　　本文通过在地震大数据存储和分析平台中，使用磁盘阵列和NFS网络文件共享协议组合的方式，替代Hadoop的HDFS三副本，使平台在成本、数据可靠性、系统可维护这几个方面均得到了较大改善。采用盘阵结合NFS网络文件共享协议后，本文对Map-Reduce的Shuffle过程进行了局部优化，以降低在Map任务节点和Reduce任务节点之间通过http协议进行数据传递，从而提高整个处理过程的效率。在对于100M条地震前兆数据分析的对比中，优化后的模型处理时间比优化前的模型处理时间减少约10%，进一步提高了地震预测任务的效率。