<div> MinIO 作为一个高性能的对象存储系统，正在突破传统的存储角色，积极拥抱多模态数据处理的新范式，致力于为生成式AI提供统一的数据基础。它通过创新的技术手段，试图解决AI在处理结构化和非结构化混合数据时面临的固有挑战。
Minio特性
MinIO 的核心思路是让对象存储成为多模态数据的“统一底座”，将结构化和非结构化数据都视为一等公民。这意味着，无论是需要向量化的非结构化数据（如图片、文本），还是传统的结构化表格数据，都能在MinIO的存储体系中找到原生的支持。
结构化数据作为对象存储的上层：MinIO 认为，诸如 Apache Iceberg 这样的表格数据，本质上是由许多细小的 Parquet 对象集合而成。这种视角使得在对象存储之上高效地管理和处理海量结构化数据成为可能。
超越向量化：AI生成代码以理解结构化数据：对于结构化数据，MinIO 认为传统的向量化方法并不适用。它的解决方案颇具创新性：利用AI本身来生成代码，以此理解表格数据的模式和结构，从而在AI的非结构化思维和数据的结构化世界之间建立桥梁。
PromptObject API：像对话一样查询非结构化数据：MinIO 推出的 promptObject API 是对传统 S3 API 的重要扩展。这个API允许你直接向存储在MinIO中的非结构化数据（例如一张餐厅小票的图片）提问，例如“有多少人来吃饭？”或者“最贵的菜是什么？”。这背后有多模态大模型的支持，极大地降低了对非结构化数据进行复杂查询和挖掘的门槛，也让数据操作从传统的“PUT 和 GET”，进化为“PUT 和 PROMPT”。
支持KV缓存卸载：为了满足AI推理引擎对高速数据访问的需求，MinIO 还支持 KV缓存卸载 (KV Cache Offloading)。这使得大规模的键值缓存能够从计算节点卸载到MinIO存储层，帮助保持GPU计算资源的持续高效运转。
Minio优势
简化数据架构：通过一个统一的存储平台同时承载对象、表格乃至向量数据，可以显著减少企业在数据湖、数据仓库和向量数据库之间进行数据搬运和管理的复杂度与成本。
提升AI工作流效率：PromptObject API 为开发者和数据科学家提供了一个直观的数据交互界面。即使不具备专业的向量数据库或RAG模型知识，也能快速从非结构化数据中提取有价值的信息，加速AI应用的开发和迭代。
面向未来的数据准备：MinIO 推出的 ExaPOD 参考架构，旨在解决百亿亿次级 (Exascale) AI 数据基础设施的瓶颈。通过与 Intel、Solidigm 和 Supermicro 等伙伴合作，ExaPOD 致力于提供低延迟、高吞吐的数据访问，确保庞大的多模态数据集能够持续、稳定地供给GPU进行计算，避免因数据等待导致算力闲置。
EMR部署Minio
在EMR（弹性MapReduce）集群的部署与配置流程中，集成Minio对象存储服务是一项关键操作。以下为详细的部署指南：
1. 节点池配置与磁盘规划
在EMR集群部署页面中，用户首先需要进入“节点池”配置模块。在此，您可以创建或选择一个特定的节点池，并将Minio服务精准地关联至池内目标计算节点。关键步骤在于对存储资源的规划：您需要明确指定为Minio服务挂载的磁盘数量，系统默认为每个选中的节点挂载一定数量的磁盘。
2. 灵活的参数自定义
为满足不同业务场景的存储需求，上述默认配置并非固定不变。您可以进入高级“参数配置”页面，对Minio的部署参数进行细粒度调整。其中，最重要的自定义项即为 data_path 存储路径，默认为 /data/minio，此路径规划确保了Minio服务能够直接利用节点本地的存储资源，实现高性能的数据读写。您也可以根据节点的实际磁盘分区情况、性能要求或数据管理策略，将其修改为任何合适的目录（例如 /opt/minio/data 或 /mnt/disk1/minio），从而实现了存储位置的完全灵活配置。
3. 服务验证与访问
完成部署并启动集群后，Minio服务将作为EMR集群中的一个核心数据服务运行。您只需前往EM管理控制台的“服务管理”页面，在服务列表中找到Minio并点击其提供的“Web UI”访问链接。系统将自动打开Minio的图形化控制台登录界面。在此，您可以使用部署时预设的管理员凭据进行登录，随后即可开始执行存储桶（Bucket）的创建、权限策略管理、文件上传下载以及用户与访问密钥（Access Key）的配置等全部运维管理工作，实现对分布式对象存储空间的全面掌控。
集群扩容
MinIO 最常用、也最核心的扩容就是对等扩容，顾名思义，就是通过向现有 MinIO 集群中添加一个或多个全新的、在架构上完全对等的服务器池，来扩展集群的整体容量和性能。一个服务器池 是由多个 MinIO 节点（服务器）组成的、独立的纠删码组。池内的节点协同工作，为存储在该池中的数据提供数据保护和冗余。在扩容时，我们以整个池为单位进行添加，而不是添加单个节点或磁盘
对等扩容工原理
对等扩容的核心原理可以概括为：“各自为政，统一调度”。
1）数据分布策略
这是对等扩容最关键的一点：新写入的对象，会根据所有现有池的剩余可用空间比例，智能地分布到不同的服务器池中。
举个例子：
假设你初始有一个服务器池 Pool-1，总容量为 4TB，已用 2TB，剩余 2TB。
你扩容新增了一个对等的 Pool-2，总容量也是 4TB，已用 0TB，剩余 4TB。
此时，整个集群的总剩余空间是 2TB + 4TB = 6TB。
当有新对象需要写入时：
写入 Pool-1 的概率是 2 / 6 ≈ 33%
写入 Pool-2 的概率是 4 / 6 ≈ 67%
这种方式确保了所有池的存储空间能够被均衡地使用，避免出现一个池子已满而另一个池子还空着的情况。
2）元数据统一视图
尽管数据物理分布在不同池中，但 MinIO 通过统一的元数据层，为客户端提供了一个单一的全局命名空间。客户端无需关心数据具体存储在哪个池，它只需要像访问单个集群一样进行操作。
3）独立的故障域
每个服务器池都是一个独立的故障域。一个池子内的节点或磁盘发生故障，不会影响其他池子的正常运行和数据完整性。这实际上在扩容的同时，也增强了整个系统的可用性和韧性
对等扩容的优势
| 优势/特点 |
详细说明 |
| 架构简单清晰 |
以池为单位扩展，规则固定，运维模型简单，易于理解和规划。 |
| 真正的线性扩展 |
每个新池都能提供额外的存储容量和独立的 I/O 性能，集群的整体吞吐量随之线性增长。 |
| 无数据迁移 |
扩容时，现有池中的数据不会自动迁移到新池 。这避免了大规模数据搬迁带来的网络带宽消耗、性能抖动和潜在风险。 |
| 容量与性能同步增长 |
增加存储容量的同时，也因为有了更多的节点和磁盘，整个集群的聚合读写带宽和 IOPS 都得到了提升。 |
| 保持强一致性 |
扩容过程不影响 MinIO 提供的严格的写后读一致性。 |
EMR对等扩容应用
导航至服务列表：在主导航栏中，点击 “服务管理”，进入集群所有服务的状态总览页面。
定位 Minio 服务：在服务列表中，找到 “Minio” 或 “对象存储” 服务。您可以通过服务状态指示灯确认其当前运行正常。
启动扩容操作：点击 Minio 服务行右侧的 “更多” 按钮，从弹出的操作列表中，选择 “添加实例” 。
在弹出的“添加实例”配置窗口中，系统可能会让您选择将实例添加到现有 Pool 或新建 Pool。
对于 Minio 扩容，必须选择 “新增Pool”。这是因为 Minio 的分布式架构要求以集合（即 Pool）为单位来增加存储资源，而不是简单地在原有节点上增加进程。
查看扩容的进度，节点显示100%表示扩容完成
完成扩容后，您可以在 Minio 控制台上直观地看到总可用存储空间的增长，并能够利用新增的容量来创建更多的存储桶（Bucket）或存储更大的对象（Object）
在minio也可以看到当前的server有四个节点
集群缩容
MinIO 的架构，尤其是其依赖的纠删码机制，依赖于固定数量的节点和磁盘。直接删除节点会破坏纠删码组，导致数据丢失甚至整个集群不可用。那么，如果确实需要缩减容量或下线服务器，正确的做法是什么？下面介绍几种可行的方案。
方案一：迁移集群
目标是缩减容量或更换硬件（无数据丢失）
这是最常见的需求，正确的方法是部署一个新集群，然后迁移数据。
操作流程如下：
搭建新集群：
按照你的需求（例如，更少的节点、更大的磁盘）搭建一个全新的、独立的 MinIO 集群。
数据迁移：
使用 MinIO 客户端 mc 的 mirror 命令，将数据从旧集群完整地同步到新集群。
命令示例：
# 设置旧集群别名
mc alias set oldcluster http://old-node-ip:9000 ACCESS_KEY SECRET_KEY
# 设置新集群别名
mc alias set newcluster http://new-node-ip:9000 ACCESS_KEY SECRET_KEY
# 执行镜像同步（迁移）
mc mirror --watch oldcluster newcluster
切换流量：
数据迁移完成后，将应用程序的配置从指向旧集群改为指向新集群。
下线旧集群：
确认新集群稳定运行一段时间后，再下线并清理旧集群的服务器。
优点：
安全可靠：整个过程不会影响旧集群的可用性，数据零丢失。
灵活：你可以任意改变新集群的架构（节点数、磁盘数、纠删码配置）。
缺点：
需要额外资源：需要临时准备一套新的服务器资源。
时间与带宽：迁移大量数据需要时间和网络带宽。
方案二：节点故障恢复
目标是让特定节点停止服务（节点故障处理）
如果某台服务器硬件故障需要下线，但你不希望缩减总容量，MinIO 的自动修复机制会发挥作用，但这不属于“缩容”。
场景：假设你有一个 8 节点的集群，其中 1 个节点磁盘损坏。
MinIO 的行为：
当读写操作发现该节点不可用时，MinIO 会将其标记为离线。
它会在其他在线节点上，利用剩余的纠删码块自动重建丢失的数据，并写入一个可用的新位置（如果配置了备用盘）。
在这个过程中，集群仍然可读写，但处于降级运行状态，性能可能会受影响。
正确操作：
更换故障服务器上的硬件（例如，换一块新磁盘）。
将修复好的节点重新加入集群。
MinIO 会自动将重建的数据同步回该节点，使集群恢复完整健康状态。
方案三：删除池
假如当前集群是以多池模式运行的，需要下线一个池，可以使用
使目标池“停止服务”，目标不是立刻停止进程，而是防止新数据写入，为迁移做准备。
设置桶策略为只读：您需要为集群中的每一个桶（Bucket）设置策略，拒绝新的 PUT/DELETE 操作，但允许 GET（读）操作。这可以确保迁移过程中，应用程序仍然可以读取数据，但不会写入新数据到待下架池。
使用 mc 设置只读策略示例：
# 为每个桶设置只读策略<br># 请将 bucket-name 替换为实际的桶名
mc anonymous set-json /dev/stdin myminio/bucket-name <<EOF
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {"AWS": "*"},
"Action": ["s3:GetObject"],
"Resource": ["arn:aws:s3:::bucket-name/*"]
}
]
}mc mirror 会列出源桶的所有对象，然后重新 PUT 到目标桶。由于目标桶是同一个（统一的命名空间），MinIO 的负载均衡器会根据各池的剩余空间比例，将这些新写入的对象分布到其他有空间的池中。
# 此命令会将数据从源集群“镜像”到目标集群<br># 因为在同一集群内，它实际上会触发数据向有空间的其他池写入
mc mirror --watch myminio/bucket-name myminio/bucket-name在确认目标池中的数据已经被全部迁移走后（可以通过监控该池的磁盘空间变化来判断），就可以安全地将其移出集群了。
停止所有 MinIO 服务：必须同时停止集群中的所有 MinIO 服务进程，不能滚动重启。
更新配置：在所有节点的启动命令或配置文件中，移除待下架池的所有节点信息
修改前
minio server http://pool1-{1...4}/disk{1...4} http://pool2-{1...4}/disk{1...4}
修改后
minio server http://pool1-{1...4}/disk{1...4}
重新启动集群：使用新的配置，同时启动所有剩余节点。集群启动后，就可以看到池删除成功了
