文章目录
前言
在大型的分布式存储系统内，当系统运行超过一段时间，个别存储节点出现数据块的损坏是再常见不过的事情了。这时候从系统层面，它最好能够自动发现并从其它节点同步副本数据。我们称这个过程为Data Scrubbing（数据清理）过程。对于一套成熟的分布式系统而言，Data Scrubbing模块的作用不能被忽视。当数据错误只有等被用户应用程序读取发现错误时，那样的代价将远远高于系统提前发现并纠正这个错误的行为。本节笔者来聊聊分布式存储系统中Data Scrubbing的一般机理过程以及其注意事项。
Data Scrubbing Vs Data Cleaning
首先笔者要来解释极易被我们混淆的两个概念：Data Scrubbing和Data Cleaning。要用中文字来区分的话，前者可以解释为“数据清理”，后者为“数据清洗”。
上面的中文名词其实还是无法体现二者直接区别，根据维基百科对这2个概念的区分如下：
- Data Scrubbing：一种对于内存数据或实际存储数据的周期性错误侦查以及矫正行为。检验错误的标准是通过计算数据的checksum来比较。
- Data Cleaning：同样是一种数据错误矫正行为，当检测的依据标准来自于外部提供的标准数据记录，db等等信息。以此做根据，来修正（包括删除，修改，替换）原始数据。
上述的区分点用一句话概括就是二者对于“坏”数据的检测标准不同，以及对应造成的不同的数据矫正行为。
OK，搞清楚这2个概念后，我们重新回到本文的主题：Data Scrubbing。
Data Scrubbing的缘起
万千事物，有果必有因，皆有其起源。Data Scrubbing的出现是为了解决存储系统节点出现非预期性的数据错误行为。而这个行为可能产生于以下原因：
- 机器硬件（磁盘驱动）的老化
- 文件系统写数据操作的丢失或异常写入（不排除恶意数据篡改写入的可能）
- Bit rot，位衰减（单个字节位的翻转）
当我们的存储节点规模达到上千甚至上万规模级别时，这种情况将会是非常常见的。
Data Scurbbing的数据清理策略
下面我们来看看Data Scrubbing具体的清理逻辑，首先它是一个周期性的清理过程。这个周期可随用户对系统进行设置而定。
这里目标清理的的数据类型一般有如下3类：
- 实际文件数据
- 内存元数据
- 实际文件数据的元数据
所以这里可以衍生出很多种情况以及对应的correct action行为。这里列举部分数据不一致的情况：
- 文件元数据存在，内存中不存在。
- 内存元数据存在，文件元数据实际不存在。
- 文件元数据信息与内存元数据不一致
- 文件元数据信息与实际文件数据计算的checksum不匹配
- …
类似其它一些情况，一旦数据被检测出损坏时，一般我们的第一行为是通知主服务此数据块为损坏块，而不是让当前节点直接删了它。后续行为应该由系统主节点来控制，是从其它节点做replication或者其它别的修复行为。
Data Scrubbing的执行性能考虑要点
Data Scrubbing操作本身也是一种IO操作，它也是会占用系统IO资源的。所以并不是说我们把Data Scrubbing操作的周期执行变得越短越好，这里其实是一个latency和performance的trade off。
一般来说，我们可以把Data Scrubbing的操作行为控制在系统总IO资源的10%以内。如果做的更细致的话，可以带上流控行为（类似于HDFS Balancer的带宽限制）保证瞬时IO数据传输量也不至于过大。
执行周期的设定也可以通过计算实际存储文件数以及磁盘实际转数确定执行时间。比如我有140w个文件需要查找，磁盘是7200rpm，约合120转/秒。我们假设每一转能命中2次查询，那么就是240 seeks/秒，再带上我们对IO资源做限制，最多使用5%的话，那么要查询完这140w个文件，就要有140w/(240* 0.05)=1.35天的时间。
Data Scrubbing行为在HDFS内有一个完整的实现，大家可以阅读里面的BlockScanner和DirectoryScanner的逻辑实现。
引用
[1].https://en.wikipedia.org/wiki/Data_scrubbing
[2].https://en.wikipedia.org/wiki/Data_cleansing
[3].https://issues.apache.org/jira/browse/HDDS-1162. Data Scrubbing for Ozone Containers