基于云环境下的海量大数据存储系统的设计

裴衣非，王艳艳，李海荣

（内蒙古科技大学工程训练中心，内蒙古包头，014010）

1 云环境下海量大数据存储系统平台搭建

MapReduce是一种能有效对数据进行处理的编程模式，主要采取的是文件系统以及数据管理两种体系，前者以GFS格式呈现，后者以BigTable格式呈现。基于MapReduce开源信息处理的Hadoop平台受到了越来越多研究人员的关注，因此需要相关部门整合管控机制和管理措施，优化管理流程，对商业计算模式中的分布式计算予以系统化整合，确保核心技术能发挥其实际优势。

Hadoop平台是开源组织结合MapReduce工作原理进行设置后形成的分布式处理框架体系，也是云计算环境中应用较为广泛的软件项目。在系统结构中，要借助相应程序完善硬件处理，实现容错和扩展机制，从根本上提高可靠性和扩展性，从而为系统运行结构升级创设良好的空间[1]。

Hadoop平台，主要分为HDFS、Hbase和MapReduce。

HDFS 主要应用在硬件设备上，是整个平台结构的最底层系统，能存储有效性为TB级别的海量数据，并且能为程序提供更加高吞吐量的数据访问项目，在数据访问过程中，其本身就存在一定的顺序，更加适合对于数据较为密集型的项目予以分析和判定，从而得出有效的信息内容和体系[2]。

Hbase 本身是开源实现，其基本构造是在底层之上，能为系统提供分布式数据库服务，在实际运行过程中，也能按照存储模式完成数据处理，并且优化实时读写项目，为规划数据集随机访问提供保障，实现管理标准和管理目标。

MapReduce 是整个平台系统的核心部分，能有效对海量数据进行分布式处理，并且在集群运行体系建立后，完善应用程序，其整体编程结构和操作较为简单，因此，开发者在处理相关信息的过程中，只需要对数据进行函数编写即可，对任务调度和容错管理提供保障，从而真正优化分布式应用程序的完整性，为后续管理工作奠定了基础。

2 云环境下海量大数据存储系统设计流程

2.1 设计文件系统

在存储系统设计的过程中，要对节点给予重视，较为常见的节点是数据节点和非数据节点。目前在大数据存储系统中，数据节点主要是DataNode形式，而非数据节点则更加倾向于管理节点和监控节点，能为Matster节点所用。

Client节点，这种节点在实际应用过程中主要是获取海量信息以及分布式系统的基础性程序，能保证客户访问工作的完整性和实效性，并且借助网络应用业务服务器，也能对相关网络结构予以应用，维护海量数据存储系统的访问接口，一定程度上升级主机和服务器管理效率。

DataNode节点，其是整体系统结构中的关键点，不仅仅能负责常规化运行任务，保证数据存储过程、查询过程以及事务处理过程的完整性，也能结合系统的基本需求完善计算过程，确保相应的节点参数之间能形成有效的关系，从而一定程度上升级系统之间的联系程度。需要注意的是，在对节点进行分析的过程中，相关人员能结合地域的邻居节点和非邻居节点对系统内部分布式数据应用展开深度分析。若是只存在一层关系管理的节点结构，则整个操作较为繁琐，会对后续处理工作造成影响。因此，在研发相关数据体系的过程中，节点将系统分为三层管理层级，能保证相同的域节点之间通信单价和质量较好，并且为每个组内关系节点的连接提供保障，一定程度上系统化分割同组的邻居节点和不同组的远程节点[3]。

Matster节点，此节点基本是上述负责系统的整体运行状态，涉及到节点状态、局部数据节点查询状态以及文件块地址信息处理状态等，在此基础上，确保相关系统负载能力能满足Matster节点的具体需求，为系统PC端完善处理效果提供保障，也能一定程度上升级系统内管理节点的工作效率。

2.2 设计文件块存储体系

首先，要对主副本进行节点编号，不同节点在进入到系统后，都能从Matster节点位置完成编号处理，相关人员则要应用节点编号对具体问题展开深度分析，最终确认地址。其次，判定副本个数，结合副本个数对具体问题进行分析和处理，按照对应的显示判定具体参数。最后，对副本所在节点编号进行分析和整理，并且形成列表，能在保存相应编号参数体系的基础上，维护节点地址处理和系统编号访问处理。在Matster节点体系中，要结合客户信息形成客户编号，并且建立快照，能结合系统文件块满足地址信息索引的处理效果，为实现全局管控提供保障，也结合快照表对客户信息进行最终定位，一定程度上升级管控效果和管理流程完整性，满足应用服务其管控效果，并且访问相应节点。

例如，客户编号1，对应文件块a；客户编号2，对应文件块d；客户编号3，对应文件块a；客户编号4，对应文件块e。结合快照表就能将不同客户的信息进行整理，并且集中落实在信息体系内，除了能对快照表予以分析外，也能一定程度上升级处理效果和节点信息表数据水平。因此能得出文件块副本信息表：文件块xx对应的节点信息是“节点xx|主副本/普通副本|可用/不可用”的形式。

2.3 设计文件块算法

在借助相应技术对数据进行分析的基础上，也要设计有效的锁控制服务模块，对文件予以及时更新，尤其是在事务处理的过程中，要保证能建立动态化管理流程。在事务中要更新的信息不在文件块中，就不会在同一个节点内，此时需要对不同信息节点进行协调管控，一定程度上进一步整合流程。在事务更新体系内判定其最终更新的成败，若是成功则能直接提交，若是失败则回滚。相较于传统的算法，文件块更新算法Chubby能更好地解决实际问题[4]。

Chubby算法能对一致性问题予以深度分析，并且在开发过程中完成具体的处理工作，利用系统解决一致性问题的同时，保证程序架构体系以及通信机制的有效性和完整性，也为后续提升整个系统运行效率提供保障。

Chubby算法能对系统中的多数事件予以分析，将其最终的计算结果直接告知用户或服务器，确保文件系统锁定服务项目运行的稳定性，且能将变动的问题直接写入到文件中[5]。

Chubby算法是在锁体系研发项目的基础上，对接口进行处理，尽管开发人员对其运行体系有所了解，但是，系统中研究会应用建议性锁体系，而并没有利用强制性锁体系，整体组件结构和信息交互项目更加有效，能一定程度上避免信息交互过程中访问被禁止的问题。并且，算法中还应用了粗粒度等服务类型，能从根本上提高整体系统运行过程的稳定性和安全性能，为后续操作过程的优化升级奠定了坚实基础。

Chubby算法在实际应用过程中会利用副本协调者作为参数分析基准，从客户提供的数值中选取一个，并且在消息分析后将其传递到其他副本处，针对不同副本的接受或拒绝都能进行信息收集。在协调不同副本反馈后，就能保证信息的一致性，发送相关处理后的信息[6]。

值得一提的是，Chubby本身就存在全冗余策略，能在保证系统协议一致性的基础上，完善控制的同步性，当Client节点和Chubby算法之间要建立联系时，会借助event完成基础性通信，一定程度上降低了通信频率，且本地能保持相关的Chubby文件模块，完善更新效果[7]。

设计事务故障恢复系统：为了保证数据处理和管控的实效性，建构完善的系统事务恢复机制十分有必要。相较于集中式数据库处理，分布式数据库事务故障恢复较为复杂，因此，在存储结构建立后，要实现云存储系统事务恢复项和本地协作管理的体系，从而完成恢复模型。

3 云环境下海量大数据存储系统负载模块

在系统管理的基础上，系统目录存储和管理工作都会分为若干个组群，能借助指定节点完成相应的目录服务项，无论是应用普通节点还是应用主副本节点，都要结合系统内相关内容完成节点操作。依据信息和节点管控体系进行排序，确保已知节点分析系统的查询结构和完整性能为执行效率优化提供保障，尤其要对系统负载平衡算法展开统计，尽量减少目录查询节点的其他任务，保证数据存储系统负载模块能发挥其实际价值[8]。