​

说道数据的完整性,之前是有火车相撞的情况,比如,如果控制高铁信号灯的,一个数据,存储该数据的磁盘如果坏了,那不严重了吗,该显示

红灯,显示成绿灯了.

​

还有比如,如果你存款余额是1000,000,如果中间的小数点搞错了,那么变成1000000,那么银行不就完蛋了对吧.

二 HDFS 对于,数据的正确性,完整性,是有校验机制的.

​

关于这个校验机制,最简单的一种是 奇偶校验 ,可以看到奇偶校验是什么意思呢?

可以看到比如我们传输数据:

0100 0001 对应的他会给数据添加一个校验位是0 这个0是怎么来的,他是查一下1的个数,可以看到左边1的个数是2,2是偶数所以 校验位就给填写了一个0 .然后把这个 0100 0001 0这个数据传输了过去.然后接收端,接收到这个数据以后,如果网络传输中,这个数据错了一位,比如0100 0011 0

过来数据变成了这样的,那么,接收端也会做一个检查,他也会去查1的个数,一查是3,这个时候,他就知道3是奇数,按说,最后以为校验位,应该填写的是1啊,怎么会是0呢?

这个时候他就知道,传过来的数据,在传输过程中,给弄错了,这个数据需要重新传输.

但是有人就可能会说了,他这个奇偶校验有漏洞,比如0100 0001 0 传过来的结果是

0101 0011 0 这样呢,这样就检测不出来了,虽然也是错了,但是1的个数还是偶数个是4个了,

所以校验位还应该是0.这个时候接收端就认为数据是对的,其实这个时候传过来的数据已经错了

但是接收端这个时候,按照奇偶校验的方式就校验不出来了.

​

但是 hadoop hdfs 工程师,也想到了这一点,他们使用 CRC 校验,就可以保证数据,传输过来的是

对的了,这个crc校验算法,这里不说,可以查一下了解一下.

可以看到,crc校验,也是有个校验位,就是判断比如

0100 1001 110的校验位是110,然后接收端,收到数据以后,0100 1001 110 他就去根据crc算法去获得0100 1001 这个数据的校验位,如果和传过来的校验位110一样,那么他就认为这个数据是没问题的.

​

然后我们再去集群上去看一下这个效果.

访问hadoop102:9870/dfshealth.html#tab-overview

选择utilities 下面有个browser the file system

​

这里数据比较多,我们换一种方式看

​

我们在hadoop102中,放一个vim a.txt这个文件中,写入个abcd

​

esc 然后:wq!保存

​

然后我们把这个文件上传到hdfs文件系统中的根目录

hadoop fs -put a.txt /

​

可以看到上面的方法,testGet,这个是我们之前写的,下载文件到本地的,方法java代码

fs.copyToLocalFile(false,…..)

第一个参数是下载后,是否要把hdfs上的源文件删除,然后第二个是下载hdfs上的哪个文件,

第三个是要下载的本地的什么路径内,然后第三个是,是否开启文件正确性校验,这里我们设置成false.

​

执行之前我们先去看看,d盘根目录,在我们下载之前没有这个a.txt文件

​

然后我们执行下载

​

执行以后我们看到有个a.txt文件

打开一看

​

没问题对吧,

然后那个crc文件怎么看呢

我们需要用 editplus 工具,把刚才那个crc文件拖进来,然后

用16 进制 打开.

​

这个错误不用管,点击确定就可以了

​

可以看到上面,63 72 00 00 00 02 00 这个是传过来的,abcd内容,然后

58 8A A4 AC 是crc的校验码

​

我们去找个crc循环冗余校验的网站去看看去

​

我们输入abc,选择Ascii,然后点击计算,得到的crc的结果是

ED 82 CD 11 这个CRC校验位,跟我们那个crc文件中的

58 8A A4 AC 的crc的校验码不一样怎么回事?传的时候出错了?我们得到的数据是abcd没错啊

对吧.

这个时候我们再去看

​

可以看到这个a.txt文件中多了一个回车换行对吧.

​

我们把这个带有回车的abcd,放到需要校验的数据里面,然后点击计算

​

可以看到校验的结果,校验位算出来是

58 8A A4 AC对吧,跟我们那个crc文件中的,crc校验位一样了,也就是什么?

我们如果传输错误了数据,比如把abcd回车,传输成了abcd了,这个时候,就会导致

crc校验 位出现问题,和原来的不一样了对吧,这也就证明了crc校验是,可以保证数据的

正确性的.

只要数据跟原来的数据不一样,只要差一点,就会被crc校验,检测出来,校验位就变了.

​

​