HDFS数据In-place Upgrade到Ozone的原型方案

前言

---

熟悉了解并使用过Hadoop HDFS作为中心数据存储的同学，一定在过去或多或少地遇到过HDFS的扩展性问题，准确来说应该是HDFS NN的扩展性问题。尽管说HDFS在后面引入了诸如HDFS federation之类的方案，但这只是指标不治本。在上层进行了横向扩展。于是乎，后来Hadoop社区设计实现了Ozone系统，从根本上解决HDFS的扩展性问题，官方宣称是可支持数十亿级别的元数据的存储。Ozone目前正在快速的开发迭代过程中，很多功能也在逐渐完善。本文要讨论的一个中的关键话题：假设Ozone发布了一个相对稳定的版本，我们如何将数据从HDFS模式upgrade到Ozone里呢？今天笔者结合社区对此的方案设计，来做个简单的阐述。同时也让大家从另外的层面了解了解HDFS，Ozone这两套存储系统在一些细小方面的异同。

HDFS Upgrade到Ozone的目标

---

我们首先要明确一个大的目标，因为后面具体谈论的Upgrade的细节都是为达成此目标服务的。

第一点，我们要知道这是2套设计完全不同的存储系统。Ozone作为后开发设计出的系统，在设计之初是为了定位并解决HDFS暴露出的扩展性问题。但是鉴于二者系统元数据结果的不同，在升级过程中会存在元数据mapping的过程。因为我们只需要做上层元数据mapping的改造，实质上我们无需进行实际的数据拷贝工作。所以这里其实是一种被称为In-Place的原地升级的操作。

因此我们暂且列出一下几点要求：

• Upgrade过程中尽可能最小化HDFS downtime时间，使得HDFS依然能够对外提供服务。
• 能够支持局部HDFS path的Upgrade操作，因为可能我们只会Upgrade那些元数据特别多（比如小文件特别多)的目录.
• 支持HDFS path到Ozone path的映射规则，因为Ozone采用的是/Volume/Bucket/Key的key，名称形式，所以这里其实会有多种映射规则。比如粗粒度的一点会是