从 HDFS 迁移到对象存储 - hdfs:// 到 s3a://

云原生、面向 Kubernetes、基于微服务的架构正在推动对网络存储（例如对象存储）的需求。对象存储在云原生环境中的好处很多——它允许独立于存储硬件的计算硬件的弹性扩展。它使应用程序无状态，因为状态存储在网络上，并允许应用程序通过降低操作复杂性实现比以往任何时候都更高的规模。

与将数据带到计算中的传统方法相比，通过网络从计算工作负载中存储数据的模式是现代分解架构的缩影。从网络对象存储系统写入和读取数据的最突出标准是 S3。MinIO 是一个完全符合 S3 的、高性能、混合和多云就绪的对象存储解决方案。

正如大多数经验丰富的 Hadoop 管理员所知，高性能对象存储后端已成为现代实施的默认存储架构。这篇文章详细介绍了如何将对象存储的优势带入 Hadoop - 更改存储协议、数据迁移和性能调优。

在接下来的部分中，我们将描述从 HDFS 迁移到MinIO的过程——我们自己的高性能、kube-native、s3 兼容的对象存储系统。

hdfs:// 到 s3a://

Hadoop 生态系统中的任何大数据平台都默认支持 S3 兼容的对象存储后端。这种支持一直追溯到 2006 年，当时新兴技术嵌入了 s3 客户端实现。所有与 Hadoop 相关的平台都使用hadoop-aws 模块和aws -java-sdk-bundle来提供对 s3 API 的支持。

应用程序可以通过指定适当的协议在 HDFS 和 S3 存储后端之间无缝切换。在 S3 的情况下，协议方案是 s3a://，在 HDFS 的情况下，方案是 hdfs://。

Hadoop SDK 中的 S3 客户端实现已经发展了多年，每个都有不同的协议方案名称，例如 s3://、s3n:// 和 s3a://。目前 s3:// 表示亚马逊的 EMR 客户端。Hadoop 生态系统中可用的最著名的 s3 客户端是 s3a://，它适用于所有其他 S3 后端。

注意：s3n:// 已失效，不再受任何主要 Hadoop 供应商的支持。

迁移的第一步是将 Hadoop 用于与后端存储通信的协议从 hdfs:// 更改为 s3a://。在适用于您平台的 core-site.xml 文件中，更改以下参数 Hadoop.defaultFS 以指向 s3 后端。

有几种方法可以迁移到对象存储。您可以将旧数据保留在 HDFS 中以供 Hadoop 访问，而将新数据保存在 MinIO 中以供 Apache Spark 等云原生应用程序访问。您可以将所有内容移动到 MinIO，Hadoop 和云原生应用程序可以访问它。或者您可以选择进行部分迁移。您必须为您的组织选择最好的一个。我将在下面描述如何进行完整迁移，并在以后的博文中深入探讨如何规划您的迁移。

将数据从 HDFS 迁移到 S3

可以使用名为 distcp 的 Hadoop 原生工具（代表分布式副本）在不同的存储后端之间迁移数据。它有两个参数，源和目标。源和目标可以是 Hadoop 支持的任何存储后端。

在此示例中，为了将数据从 HDFS 移动到 s3，必须将源设置为 hdfs://192.168.1.2:9000，将目标设置为 s3a://minio:9000。

根据数据的大小和传输速度，distcp 本身可以扩展，并且可以使用大规模并行基础设施迁移数据。

映射器的数量，即复制数据的并行任务的数量，可以使用 -m 标志进行配置。一个好的经验法则是将它设置为基础架构中所有节点上可用的 CPU 内核数。

例如，如果您有 8 个空闲节点，每个节点有 8 个内核，则 CPU 内核数将为 64。

注意：映射器的数量应对应于基础架构中的空闲核心数，而不是整个集群中的核心总数。这是为了确保其他工作负载有可用于其操作的资源。

性能调整

Hadoop 和对象存储之间的数据访问模式有很大不同。按照设计，对象存储系统不支持编辑。这对其实现多 PB 规模的能力起着关键作用。

其次，在对象存储系统中将数据从一个位置复制到另一个位置非常昂贵，因为该操作会导致服务器端复制。一些对象存储系统不是严格一致的，这可能会使 Hadoop 感到困惑，因为文件可能不会显示，或者如果最终一致，则删除的文件可能会在列表操作期间显示。

注意：MinIO 没有一致性缺点，因为它是严格一致的。

考虑到这些因素，很容易将您的应用程序调整为原生对象存储。已经付出了巨大的努力来帮助加速这一旅程，那就是将 S3 提交者引入 Hadoop。顾名思义，S3 提交者向 S3 承诺一致、可靠和高性能的数据承诺。

提交者更改来自 S3 的数据的读/写访问模式。首先，它们避免了服务器端副本，否则 Hadoop 应用程序会广泛使用服务器端副本，以允许多个 Hadoop worker 以原子方式写入数据。一些提交者甚至使用本地驱动器作为缓存，并且只将最终输出写入对象存储以提高性能。

共有三个提交者，每个提交者都有不同的权衡来解决不同的用例。他们是：

• 目录提交者

• 分区提交者

• 魔术提交者

为了在您的应用程序中启用提交者，请在您的 core-site.xml 文件中设置以下配置：

目录提交者

该提交者将访问模式更改为首先在本地（缓存驱动器）写入数据，一旦收集到要写入的数据的最终版本，就执行写入。这种写法更适用于通过快速网络连接的分布式计算和对象存储，并通过防止服务器端复制大大提高了性能。

为了选择这个提交者，将以下参数 fs.s3a.committer.name 设置为目录。

分区提交者

这个提交者类似于目录提交者，除了它处理冲突的方式。目录提交者通过考虑整个目录结构来处理不同 Hadoop worker 写入同一文件的冲突。在分区提交者的情况下，冲突是在逐个分区的基础上处理的。

如果目录结构嵌套很深或通常非常大，则此提交程序与目录提交程序相比可提供更高的性能。仅建议将其用于 Apache Spark 工作负载。

魔术提交者

这个提交者的内部工作不太为人所知，因此得名 Magic 提交者。它会自动选择最佳策略以实现最高性能。它仅适用于严格一致的 S3 存储。

由于 MinIO 是严格一致的，因此可以安全地使用 Magic committer。建议在您的工作负载下试用此提交程序，以将性能与其他提交程序进行比较。

选择提交者的一个好的经验法则是从最简单和最可预测的目录提交者开始，如果它不能满足您的应用程序需求，请尝试其他两个提交者。

一旦选择了合适的提交者，就可以对您的应用程序进行性能和正确性测试。

结论

有关性能调整的更多说明，请参见此处的基准测试指南。可以在此处找到有关 S3 提交者的更多信息。如果您有任何问题，请通过sales@minio.org.cn