Page 39 - 《软件学报》2021年第10期

乔嘉林 等:基于着色 Petri 网的 HDFS 数据一致性建模与分析 3011

综合分析有错条件下的操作层一致性,有以下结论.
(1) 系统会出现操作层的不一致,导致不一致的原因包括:多个副本之间传播的快慢程度不同;副本传播
过程中出错,造成一部分副本没有写成功;
(2) 有错误发生时,即使经过足够时间的传播,系统最终也不会达到操作层的一致状态.
4.5 代价分析

本文通过阅读源码的方式对 Hadoop 进行人工建模,大约需要 2~3 周的时间.除人工建模方式以外,还可以通
过系统日志分析实现自动建模,如对 Cassandra 的日志进行建模的工作 [27] .然而,对日志进行自动建模虽然效率
高,但由于日志较多,建模结果可能包含一些不关心的状态,没有人工建模精准.人工建模和日志自动建模两种
方法是时间与精准性的权衡,需要建模人员根据实际情况选择合适的建模策略.建模之后,即可使用 CPN Tools
计算状态空间.对于本文提出的模型进行计算耗时约 5 分钟,相比整体工作量来说,这一耗时是可以接受的.
4.6 本节小结
本节介绍了基于 CPN Tools 的状态空间分析工具集,并以该工具集为手段,以 HDFS 读写流程模型为样本,
从数据层一致性和操作层一致性两个角度,详细分析了不一致的情况及其产生原因.本节实验包含了 HDFS 所
有的不一致条件.
综合两种不一致性的分析可以发现:数据层不一致是操作层不一致产生的根本原因,只有数据层出现了不
一致,才有可能被读操作观测到.操作层出现不一致的另一个原因是并发隔离机制不严格,因为 HDFS 允许在读
文件的最后一块时从 FileINode 直接获取文件块存储位置,此时并不能保证每一个数据节点上都已经完成了写
文件块操作,因此访问不同数据节点就可能导致不同的读操作结果(见表 5).
Table 5 HDFS data consistency analysis summary table
表 5 HDFS 数据一致性分析结果汇总表
场景 数据层一致性 操作层一致性
1. 存在不一致,原因是多副本间数据传播速度不同; 同左,且只发生在
无错情况
2. 经过足够的时间,系统恢复一致 文件最后一块
1. 存在不一致,原因是副本传播速度和副本写失败; 同左,且只发生在
有错情况
2. 如果出现写失败,则不会恢复到一致状态 文件最后一块
操作层不一致只发生在文件的最后一块,是因为最后一块的位置信息由名字节点分配,其他文件块位置信
息由写成功的数据节点上报,因此能够保证数据的一致性.
HDFS 的文档对一致性的描述为:当一个客户端创建的文件关闭后,其他客户端可以立即看到完整的这一
文件.本文的结论关注的则是在一个客户端创建文件的过程中,其他客户端读取该文件时的一致性,属于文档中
未涉及的部分.
我们注意到:HDFS 提供了 FileStatus 的 getLen()接口来获取文件大小,该接口仅会返回已写完的文件块的
总长度.然而,其提供的 FSDataInputStream 接口会将未写完的文件块也读取出来,因此,实际读取的大小可能大
于 getLen()的返回值.由此可以对基于 HDFS 的上层应用开发提出建议:由于不一致出现在不同客户端读取同
一个正在写入的文件这一情况下,因此,在应用层进行读操作时,通过对文件块的长度进行检测,来达到一致性
和可用性的平衡.在读取文件之前调用 getLen()得到文件长度,若实际读取到的文件长度大于 getLen()的返回
值,则说明读取到了未写完的文件块,此时可以根据应用需求选择是否将大于 getLen()返回值的部分数据舍弃
掉:如果舍弃掉,则可以保证所有客户端读到的都一样;如果保留,则牺牲一致性而保证了高性能.由于该策略是
在应用层进行的,不同的应用可以选择不同的控制策略,因此不会破坏 HDFS 的高可用性.由于该策略仅增加了
一次 getLen()调用和一次长度判断,因此也不会影响应用层的读取性能.
5 总 结

本文基于着色 Petri 网开展 HDFS 数据一致性的相关研究,完成的主要工作有: