从 HDFS 迁移到 MinIO 企业对象存储

云原生、Kubernetes 导向的、基于微服务的架构正在推动对网络存储的需求，例如 MinIO。 对象存储在云原生环境中具有许多优势——它允许计算硬件的弹性扩展，与存储硬件无关。 它使应用程序无状态，因为状态存储在网络上，并且通过简化操作复杂性，允许应用程序实现比以往任何时候都更高的扩展性。

从网络对象存储系统读写数据的最突出标准是 S3。 MinIO 是一个完全兼容 S3 的、高性能的、混合的、多云就绪的对象存储解决方案。

与将数据引入计算的传统方法相比，从计算工作负载通过网络存储数据的模式体现了现代的解耦架构。 这种方法的优势是多方面的：成本节省、可扩展性和性能。 我们的一位客户，一家领先的金融集团在性能方面比 HDFS 提高了 60% 以上，这得益于 MinIO。 这种节省绝非偶然。

在可扩展性方面，Hadoop 在处理小文件时效率低下，并且需要数据本地性，这限制了它的可扩展性，而 MinIO 在处理各种大小的对象（从千字节到太字节）方面表现出色。

至于性能，大多数精通 Hadoop 的管理员都知道，高性能对象存储后端已成为现代实施的默认存储架构。 这篇文章详细介绍了如何将对象存储的优势引入 Hadoop——通过更改存储协议、数据迁移和性能调优。

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

hdfs:// 到 s3a://

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

有几种方法可以进行迁移到 MinIOAIstore。 您可以将旧数据保留在 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 和 MinIO 之间的数据访问模式截然不同。对象存储系统在设计上不支持编辑。这在其能够实现多 PB 规模方面起着关键作用。

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

注意：MinIO 不存在一致性缺陷，因为它严格一致。

考虑到这些因素，很容易将应用程序调整为成为对象存储原生。已经付出了巨大努力来帮助加快这个过程，那就是在 Hadoop 中引入了 S3 提交器。顾名思义，S3 提交器承诺对 S3 的数据进行一致、可靠和高性能的提交。提交器改变了从 S3 读取/写入数据的模式。首先，它们避免服务器端复制，而服务器端复制通常由 Hadoop 应用程序广泛使用，以允许多个 Hadoop 工作节点原子地写入数据。某些提交器甚至使用本地驱动器作为缓存，并且只将最终输出写入 MinIO 以提高性能。共有三个提交器，每个提交器都有不同的权衡取舍，以解决各种用例。它们分别是

• 目录提交器
• 分区提交器
• Magic 提交器

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

目录提交器

此提交器更改访问模式以首先在本地（缓存驱动器）写入数据，并且一旦收集到要写入数据的最终版本，就会执行写入。这种写入方式更适合于分布式计算和由快速网络连接的 MinIO，并且通过防止服务器端复制，极大地提高了性能。

为了选择此提交器，请将以下参数 fs.s3a.committer.name 设置为 directory。

分区提交器

此提交器与目录提交器类似，不同之处在于它处理冲突的方式。目录提交器通过考虑整个目录结构来处理不同的 Hadoop 工作节点写入同一文件的冲突。在分区提交器的情况下，冲突是在逐分区的基础上处理的。如果目录结构嵌套很深或总体上很大，此提交器与目录提交器相比提供了更高的性能。仅建议将其用于 Apache Spark 工作负载。

Magic 提交器

此提交器的内部工作原理鲜为人知，因此被称为 Magic 提交器。它会自动选择最佳策略以实现尽可能高的性能。它仅适用于严格一致的 S3 存储。

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

选择提交器的一个好经验法则是从最简单、最可预测的目录提交器开始，如果应用程序的需要无法满足，则尝试其他两个提交器（如适用）。一旦选择了合适的提交器，就可以对应用程序进行性能和正确性测试。

结论

有关性能调优的更多说明，请参阅我们的基准测试指南 这里。有关 S3 提交器的更多信息，请参阅 这里。

如果您有任何问题，请联系我们，地址为 hello@min.io，或者访问 min.io 以 下载 并立即开始使用！