众所周知,Hadoop的存储组件有已经存活了十二年之久的HDFS,问世三年而用户寥寥的KUDU,以及来势凶猛的新晋网红Ozone。
KUDU虽然有和HDFS一样的水平扩展能力以及近似HBase的高效随机读写能力,但受限于其功能局限性以及和其他软件之间的兼容能力不强,因此目前主要作为存放"实时更新的,用来做快速分析的结构化数据"的载体,这部分数据量不会太大,比起HDFS中的数据应该会小的多。
Ozone到目前刚刚推出了alpha 0.4.1版本,离正式release还有一段路要走,所以短期内也只有小范围的试用需求。
说到底,目前的存储规划还是要以HDFS为主。而对于HDFS,这里有几个问题考量:
● HDFS容量
● 数据压缩
● 硬件选择
HDFS的容量HDFS设计初衷是以多副本机制解决硬件的不可靠性,从而在节约硬件成本的情况下尽量提升数据的可用性与读写效率。HDFS通常默认配置为3副本,结合HDFS的机架感知特性,3个副本通常按照如下分布:
● 将第一副本写到离数据输入client最近的同一rack数据节点上,如输入client与集群数据节点分布在不同的机架上,则随机写入一个不太繁忙的数据节点。
● 将第二副本写入与第一副本不在同一rack的数据节点上。
● 将第三副本写入与第二副本同一rack的不同数据节点上。
在几年前大数据产业发展伊始,企业中的数据量都还是”数据库量级”的时候,数据库软件和专用存储都非常昂贵,这样做的确是最佳实践,既降低了软硬件的成本,还提高了数据的可用性。然而技术发展日新月异,在企业的大数据发展终于进入”大数据量级”的时候,即便是普通廉价的工业磁盘也因为集群过大,数量太多产生了经济方面的压力。
多副本机制是否有必要,是不是造成了存储资源的浪费?
Hadoop 3.X实现了EC码(纠删码)机制,来减少数据存储副本,提升数据的可用性。最简单的EC码是XOR编码(异或操作码),它的原理如下:
RS码策略存储开销
可以看出,使用了EC码(无论是XOR码还是RS码)以后,存储的开销都从之前的300%下降到了150%左右,但是不是说EC纠删码代替原来的多副本机制就是更好的解决方案?或者说考虑使用磁盘阵列(RAID)的方式来提高数据可用性操作性更强?毕竟RAID方式也是使用了EC纠删码的原理(RAID5实现了XOR的机制允许坏掉一个副本,RAID6则实现了RS的机制允许坏掉2个副本)。
事情没有这么简单,多副本机制与EC纠删码码机制相比,有以下特点:
多副本与EC码
可以看出,EC纠删码虽然大大提升了磁盘利用率,但是其在数据恢复方面的表现是不太理想的,因为EC纠删码的加密解密过程大大依赖于CPU的能力,而数据恢复过程中,又需要网络传输大量的数据。
在同一个集群中,同一份数据要么配置EC纠删码机制,要么配置多副本机制,两者是互斥的。基于这么一个前提,有benchmark测试表明,在未发生数据故障时,配置了EC纠删码和多副本机制的HDFS读写效率基本一致,但在发生了数据恢复时,多副本机制的HDFS读写效率要比EC码机制的读写效率快3-4倍。在数据量超大,CPU配置不高以及网络带宽有限的集群环境里,这也是相对致命的问题。
要不要使用磁盘阵列(RAID)的方式?
其实配置磁盘阵列与配置HDFS纠删码实现原理是一样的,但是磁盘阵列只在单个节点生效,HDFS纠删码则针对整个集群生效。换句话说,即便配置了磁盘阵列,但是单个节点的服务器如果由于磁盘以外的其他原因故障了,那数据就丢失了,这个风险很大,因此使用HDFS纠删码要比单纯使用磁盘阵列安全的多。
怎么选择使用多副本机制还是EC纠删码?
通常建议热数据较多,业务密集型的集群还是按照3副本机制进行配置容量,而冷数据较多,以存放备份归档数据为主的集群可考虑以EC纠删码的方式来进行配置容量,但是磁盘总容量不应小于实际数据的大小的2倍。另外需要注意的是,使用EC纠删码只能在Hadoop 3.X以上的版本进行。
数据压缩HDFS上的数据可以启用压缩,通常这也是做存储规划时值得考虑的因素。对于一个在Hadoop发生的计算过程,以典型的MapReduce框架考虑,压缩可以在三个阶段处理:map任务阶段,reduce任务阶段,以及最终写HDFS的阶段。由于map任务阶段和reduce任务阶段主要是写本地磁盘为主,因此主要考虑最后写HDFS的阶段的压缩(spark等内存计算引擎也只需要考虑最后写HDFS的压缩)。
HDFS支持的压缩方式有Deflate,gzip,bzip2,LZO,LZOP,LZ4,Snappy几种。他们的区别如下:
各种压缩方式对比
以100M的常规文件(XML文件,来自http://mattmahoney.net/dc/textdata.html的enwik8.zip,非纯文本)作为原始文件,各种压缩方式的压缩时间,解压时间以及压缩率比较如下:
各种压缩方式性能表现
由上表可以看出,压缩比最好的是bzip方式,但是其效率实在是不高,在大数据量的时候,压缩和解压的时间耗费过长,不是首选压缩方式。
综合考虑各种因素,LZ4与Snappy是比较推荐的压缩方式,性能和效率都还不错。LZ4由于推出较晚,因为这样,Snappy目前成为使用最普遍的压缩方式。
由于集群中并不是所有数据都会被压缩,通常来说,我们考虑集群的冷热数据比为6:4,即60%的数据为冷数据,这部分数据被压缩,而剩下40%为热数据,这部分数据不压缩。假设使用Snappy的压缩机制,参考上表假设压缩比为数据,那么整体数据在压缩完成后约为原始数据量的75%。
这样的话有一个参考,如果原来启用3副本机制,那么存储只需规划数据量的2.25倍即可。如果原来使用EC纠删码机制,那么存储只需规划数据量的1.5倍即可(同时使用EC纠删码和压缩的情况下对CPU要求会非常高,并不推荐)。
硬件选择讨论完了HDFS的容量考虑与数据压缩的问题;
如何选择合适的硬件以支持HDFS服务呢?
HDFS底层可以是本地磁盘,可以是传统的存储设备,哪一个好一些?
首先,关于硬件选择没有好不好的问题,只有合不合适的范畴。在数据量不大的初期,使用本地磁盘绝对是个性价比更好的方案,另外在数据读写效率上,本地磁盘也比存储设备要优秀的多。
而在数据量上升到一定程度,3副本带来的磁盘经济成本和管理成本迅速上升时,低端的存储设备优势开始表现出来:可以做数据分层,归档,监控数据情况,管理便捷等,毕竟在不考虑性价比的情况下,存储设备的功能是很强大的。
但数据量再继续上升(PB往上),存储设备的扩展性开始受到了局限,而磁盘仍然可以继续线性增加。所以在一个”大数据”量级的场景下,本地磁盘可能是一个”没得选”的选择。
如果用本地磁盘作为HDFS的存储硬件,磁盘又该怎么选择?
是用SSD盘,还是用SAS盘,还是用SATA盘?
从性价比的角度来讲,一般不考虑把SSD盘用作HDFS的底层磁盘,毕竟当容量超过TB级别后,SSD的价格非常昂贵,当然财大气粗的公司请无视该建议。而对于同等容量的SAS盘与SATA盘,目前市场上的价格差异上已经不大了,考虑速写效率以及性能稳定性等因素,建议首选SAS盘。
大盘好还是小盘好?回答这个问题前,先了解几个背景因素:
一、SAS盘分为大盘和小盘,其中大盘3.5寸,小盘2.5寸,市场上两种尺寸的磁盘容量包括:
● 2.5寸:300G, 600G, 900G, 1.2T, 1.8T, 2.4T, 1T, 2T
● 3.5寸:1T,2T,4T,6T,8T,10T
二、2.5寸的盘通常有三种转速,分别是7.2K rpm, 10K rpm, 15K rpm,具体为:
● 7.2K rpm:1T,2T
● 10K rpm:1.2T,1.8T,2.4T
● 15K rpm:300G, 600G, 900G
而3.5寸的盘统一只能达到7.2K rpm。
在了解以上两个要素后,我们讨论一下磁盘的性能问题,首先需要说明的是,磁盘的读写性能和其容量大小无关。
影响磁盘性能的有两个指标。一个是磁盘的IOPS,全称是磁盘每秒处理的I/O请求数量。另一个磁盘数据传输率。一般数据传输率更多的依赖于磁盘的接口,对于同种接口数据传输率几乎相同,因此IOPS是评价磁盘性能最重要的指标。理论上,磁盘的IOPS计算公式如下:
1s/(Tseek+Trotation)
其中,Tseek是寻道时间,一般SAS盘的Tseek为4-8ms。具体来说,15K rpm的Tseek约为4ms,10K rpm的Tseek约为6ms,7.2K rpm的Tseek约为8ms。
Trotation为盘片旋转延时,通常为磁盘旋转半圈的时间表示,15K rpm磁盘的延时为60*1000/15000/2=2ms,同理,10K rpm的延时为3ms,7.2Krpm的延时为4ms。
则根据以上理论,可以得出:
15K rpm磁盘:IOPS=1000/(4+2)=166
10K rpm磁盘:IOPS=1000/(6+3)=111
7.2K rpm磁盘:IOPS=1000/(8+4)=83
由以上数据可以得出,使用15KPM的磁盘性能会是7.2KPM磁盘性能的2倍。使用10K rpm的磁盘性能会是7.2KPM磁盘性能的1.33倍。
15K rpm的磁盘由于其容量太小,一般不在实际的使用考虑之中,而10K rpm和7.2K rpm是实践中用的最多的磁盘。10K rpm最大磁盘容量为2.4T,7.2K rpm最大磁盘容量为10T,几乎为前者的4倍。
由此,在实际选择中,如果HDFS的数据量不大且为计算密集型集群,对实时响应要求较高时,建议使用10K rpm的小盘;如果HDFS有海量数据存储的需求,那么还是10T的大盘好一些,即便这意味着让渡一些性能出来,虽然集群数据处理的慢一些,但是它能处理更多的数据。
![a4268f7fabcdbec66de9df677fe92525.png](https://i-blog.csdnimg.cn/blog_migrate/8468ee9af1230830f83c8a483f8d49b4.jpeg)