利用FSx for NetApp ONTAP的“SVMDR”实现SSD存储容量优化

引言

在当今数据驱动的企业环境中，存储成本优化与灵活性已成为IT决策者面临的核心挑战。随着工作负载需求的周期性变化，特别是在电子设计自动化(EDA)、数据迁移项目和媒体制作等领域，存储容量的动态调整能力变得尤为关键。虽然Amazon FSx for NetApp ONTAP已在全球区域的第二代系统中推出了无中断缩减SSD容量的重要功能，参见如下的在线说明：

https://docs.aws.amazon.com/fsx/latest/ONTAPGuide/storage-capacity-and-IOPS.html#decreasing-ssd-capacity

但中国区域的客户仍在使用第一代系统，尚无法直接受益于这一创新。

面对这一挑战，我们发现SVM灾难恢复(SVMDR)技术提供了一条有效的替代路径。本文将深入探讨如何在FSx for NetApp ONTAP上使用SVMDR功能来降低SSD存储成本的战略性工具。通过这种方法，我们可以帮助中国区域客户解决存储弹性问题，在新一代系统正式登陆中国区域之前，有效控制存储支出，同时确保数据安全和业务连续性。

接下来，让我们一起探索如何配置和实施这一解决方案，使您的组织能够在优化成本的同时保持卓越的存储性能和可靠性。

关于SVMDR

• SVMDR 是基于 SnapMirror 的异步复制机制，用于将完整的 SVM（包括其配置、卷、LUN、共享、导出策略等）从主站点复制到 DR 站点。
• 复制内容包括：
• 所有数据卷（FlexVol 或 FlexGroup）
• SVM 配置（如 CIFS/SMB 共享、NFS 导出、网络接口等）
• 支持一致性组（Consistency Groups）和 FlexGroup 卷的 SVMDR 复制。

注意：目前FSx for NetApp ONTAP** **不直接支持SVMDR** **，但可以利用SVMDR** **的MirrorAllSnapshotsDiscardNetwork** **选项在文件系统级别建立SnapMirror** **关系，复制所有数据卷、快照以及配置信息(** **丢弃网络配置信息),** **特别适合用于SSD** **磁盘缩容的场景。

https://docs.aws.amazon.com/fsx/latest/ONTAPGuide/scheduled-replication.html

和数据卷迁移的比较

–

数据卷复制：针对特定卷的数据层面复制，类似于”文件复制”

–

SVMDR：整个SVM环境的完整镜像，类似于”系统克隆”

复制范围详细对比

|

|复制内容类别

|具体项目

|数据卷复制

|SVMDR

|说明

|1

|

数据层 |卷数据内容

|

✅ 选定卷 |

✅ 所有卷 |SVMDR复制SVM内所有卷

|2

|

|卷快照

|

⚠️ 部分 |

✅ 全部 |SVMDR保持完整快照历史

|3

|

|数据去重信息

|

❌ 丢失 |

✅ 保持 |SVMDR保持存储效率

|4

|

配置层 |卷配置参数

|

✅ 基本配置 |

✅ 完整配置 |大小、类型、策略等

|5

|

|导出策略

|

❌ 需重建 |

✅ 自动复制 |NFS/SMB访问控制

|6

|

|配额设置

|

❌ 需重建 |

✅ 自动复制 |用户/组配额限制

|7

|

|QoS策略

|

❌ 需重建 |

✅ 自动复制 |性能限制和保证

|8

|

|加密设置

|

⚠️ 部分 |

✅ 完整 |卷级和SVM级加密

|9

|

协议层 |NFS服务配置

|

❌ 不复制 |

✅ 完整复制 |版本、选项、性能调优

|10

|

|SMB/CIFS配置

|

❌ 不复制 |

✅ 完整复制 |共享、权限、域加入

|11

|

|iSCSI/FC配置

|

❌ 不复制 |

✅ 完整复制 |LUN映射、启动器组

环境说明

• 准备Gen 1 FSx for NetApp ONTAP 文件系统，包括源文件系统 与目标文件系统
• 在目标 FSx for NetApp ONTAP 文件系统上有一个空白的可用 vserver（用于 SVMDR 对等的 vserver 不能具有相同的名称）

源文件系统和目标文件系统

–

FsxId0c9b5b9602b41fe9f – 源文件系统

如下所示，目前的源文件SSD系统容量为2.54TB

FsxId0c9b5b9602b41fe9f::> storage aggregate show -fields size,availsize,storage-type,space-full-threshold-percent,percent-snapshot-space

aggregate storage-type percent-snapshot-space space-full-threshold-percent availsize size

——— ———— ———————- —————————- ——— ——

aggr1 ssd 5% 96% 2.52TB 2.54TB

对应的volume设置如下

FsxId0c9b5b9602b41fe9f::> volume show

Vserver Volume Aggregate State Type Size Available Used%

——— ———— ———— ———- —- ———- ———- —–

fsx fsx_root aggr1 online RW 1GB 972.2MB 0%

fsx vol0 aggr1 online RW 1TB 953.2GB 2%

fsx vol1 aggr1 online RW 200GB 190.0GB 0%

3 entries were displayed.

–

FsxId00a6c10ba5aee140e – 目标文件系统

如下所示，目前的目标文件SSD系统容量为860.5GB

FsxId00a6c10ba5aee140e::> storage aggregate show -fields size,availsize,storage-type,space-full-threshold-percent,percent-snapshot-space

aggregate storage-type percent-snapshot-space space-full-threshold-percent availsize size

——— ———— ———————- —————————- ——— ——

aggr1 ssd 5% 96% 860.5GB 860.5GB

对应的volume设置如下

FsxId00a6c10ba5aee140e::> volume show

Vserver Volume Aggregate State Type Size Available Used%

——— ———— ———— ———- —- ———- ———- —–

mysvm1 mysvm1_root aggr1 online RW 1GB 972.2MB 0%

1 entries were displayed.

创建从源 SVM到目标SVM的SnapMirror关系

创建源集群和目标集群之间的集群对等关系

获取目标集群的集群间接口：

FSx:: net int show -services intercluster-core

FsxId00a6c10ba5aee140e::> net int show -services intercluster-core

(network interface show)

Logical Status Network Current Current Is

Vserver Interface Admin/Oper Address/Mask Node Port Home

FsxId00a6c10ba5aee140e

inter_1 up/up 192.168.29.20/19 FsxId00a6c10ba5aee140e-01

e0e true

inter_2 up/up 192.168.129.180/25 FsxId00a6c10ba5aee140e-02

e0e true

2 entries were displayed.

获取源集群的集群间接口：

Src:: net int show -services intercluster-core

FsxId0c9b5b9602b41fe9f::> net int show -services intercluster-core

(network interface show)

Logical Status Network Current Current Is

Vserver Interface Admin/Oper Address/Mask Node Port Home

FsxId0c9b5b9602b41fe9f

inter_1 up/up 192.168.14.56/19 FsxId0c9b5b9602b41fe9f-01

e0e true

inter_2 up/up 192.168.104.102/19 FsxId0c9b5b9602b41fe9f-02

e0e true

从目标发起集群对等关系（在提示时输入密码）：

FsxId00a6c10ba5aee140e::> cluster peer create -peer-addrs 192.168.14.56,192.168.104.102

Notice: Use a generated passphrase or choose a passphrase of 8 or more characters. To ensure the authenticity of the peering relationship, use a phrase or sequence of characters that

would be hard to guess.

Enter the passphrase:

Confirm the passphrase:

Notice: Now use the same passphrase in the “cluster peer create” command in the other cluster.

从源发起集群对等关系：

Src:: cluster peer create -peer-addrs <>,<>

FsxId0c9b5b9602b41fe9f::> cluster peer create -peer-addrs 192.168.29.20,192.168.129.180

Notice: Use a generated passphrase or choose a passphrase of 8 or more characters. To ensure the authenticity of the peering relationship, use a phrase or sequence of characters that

would be hard to guess.

Enter the passphrase:

Confirm the passphrase:

检查源和目标，确保对等成功，如从源端检查Snapmirror关系

FsxId0c9b5b9602b41fe9f::> cluster peer show

Peer Cluster Name Cluster Serial Number Availability Authentication

FsxId00a6c10ba5aee140e 1-80-000011 Available ok

在源和目标vserver之间创建vserver对等关系：

获取目标集群的vserver名称，并从”Vserver”下方获取值：

sxId00a6c10ba5aee140e::> vserver show

Admin Operational Root

Vserver Type Subtype State State Volume Aggregate

mysvm1 data default running running mysvm1_ aggr1 root

获取源集群的vserver名称，并从”Vserver”下方获取值：

FsxId0c9b5b9602b41fe9f::> vserver show

Admin Operational Root

Vserver Type Subtype State State Volume Aggregate

fsx data default running running fsx_root aggr1

从目标发起vserver对等关系：

FsxId00a6c10ba5aee140e::> vserver peer create -vserver mysvm1 -peer-vserver fsx \

-applications snapmirror -peer-cluster FsxId0c9b5b9602b41fe9f

Info: [Job 64] ‘vserver peer create’ job queued

注意：如果源和目标vserver** **使用相同的名称（如FSxN** **部署中的默认”fsx”vserver** **），ONTAP** **将会报错。为每个vserver** **使用不同的名称。

从源接受vserver对等关系：

FsxId0c9b5b9602b41fe9f::> vserver peer accept -vserver fsx -peer-vserver mysvm1

Info: [Job 2380] ‘vserver peer accept’ job queued

从源和目标检查vserver对等关系：

FsxId0c9b5b9602b41fe9f::> vserver peer show

Peer Peer Peering Remote

Vserver Vserver State Peer Cluster Applications Vserver

fsx mysvm1 peered FsxId00a6c10ba5aee140e

snapmirror mysvm1

数据卷复制-可选

如果只需要迁移源系统的部分数据卷到目标系统（不包含根卷），可以采用基于数据卷复制的方法。

对于源集群上的数据卷，此处以源系统上vol0为例：

在目标集群上创建与源集群相同名称、至少相同大小的卷，类型为DP：

FsxId00a6c10ba5aee140e::> vol create -volume vol0 -aggregate aggr1 -size 15G -type DP

[Job 69] Job succeeded: Successful

在目标集群上为源卷创建SnapMirror关系，使用SVM-DR的默认策略（

MirrorAllSnapshotsDiscardNetwork）：

FsxId00a6c10ba5aee140e::> snapmirror create -source-path fsx:vol0 -destination-path \

mysvm1:vol0 -vserver mysvm1 -identity-preserve true \

-policy MirrorAllSnapshotsDiscardNetwork -schedule pg-15-minutely

Operation succeeded: SnapMirror create for the relationship with destination “mysvm1:vol0”.

从目标FSxN（确保卷级和SVM级的SnapMirror策略相同）：

FsxId00a6c10ba5aee140e::> snapmirror show -instance

Source Path: fsx:vol0

Destination Path: mysvm1:vol0

Relationship Type: XDP

Relationship Group Type: none

SnapMirror Schedule: pg-15-minutely

SnapMirror Policy Type: async-mirror

SnapMirror Policy: MirrorAllSnapshotsDiscardNetwork

Tries Limit: –

Throttle (KB/sec): unlimited

Mirror State: Broken-off

Relationship Status: Idle

在目标FSxN上初始化SnapMirror关系：

FsxId00a6c10ba5aee140e::> snapmirror initialize -destination-path mysvm1:vol0

Operation is queued: SnapMirror initialize of destination “mysvm1:vol0”.

在目标FSxN上检查SnapMirror关系：

FsxId00a6c10ba5aee140e::*> snapmirror show

Progress

Source Destination Mirror Relationship Total Last

Path Type Path State Status Progress Healthy Updated

fsx:vol0 XDP mysvm1:vol0 Snapmirrored

Finalizing 0B true 06/29 07:01:16

如上，表示基于数据卷的复制设置成功，当Relationship status显示为Idle时，表示数据复制已经完成。

SVMDR配置

SVMDR实现SVM级SVM SnapMirror，其主要的步骤如下：

停止目标端FSxN vserver：

FsxId00a6c10ba5aee140e::> vserver stop -vserver mysvm1

[Job 144] Job succeeded: DONE

列出源文件系统源根卷名称：

FsxId0c9b5b9602b41fe9f::> vserver show -vserver fsx -fields rootvolume

vserver rootvolume

——- ———-

fsx fsx_root

列出目标系统根卷名称：

FsxId00a6c10ba5aee140e::> vserver show -vserver mysvm1 -fields rootvolume

vserver rootvolume

——- ———-

mysvm1 mysvm1_root

重命名目标文件系统vserver的根卷以匹配源文件系统vserver的根卷，将目标vserver根卷重命名为与源vserver根卷相同的名称：

FsxId00a6c10ba5aee140e::*> vol rename mysvm1_root -newname fsx_root

[Job 72] Job succeeded: Successful

在目标上创建源vserver和目标vserver之间的SnapMirror关系（注意所使用的策略，必须为

MirrorAllSnapshotsDiscardNetwork）：

FsxId00a6c10ba5aee140e::*>snapmirror create -source-path fsx: -destination-path \

mysvm1: -vserver mysvm1 \

-policy MirrorAllSnapshotsDiscardNetwork -schedule pg-15-minutely \

-identity-preserve true

从目标重新同步SnapMirror关系：

FsxId00a6c10ba5aee140e::*>snapmirror resync -destination-path mysvm1: -vserver

注意：如果ONTAP报告存在没有Snaplock的卷，请检查卷恢复队列，并在必要时清除

从目标FSxN,设置正确后，状态应显示为SnapMirrored和Idle。您不会看到卷之间的所有单独SnapMirror关系，因为它已转换为SVM-DR关系。

默认操作状态将为”stopped”（因为这是SVMDR），除非您有故障转移事件并需要启动它，此时您的卷将变为R/W，并且您将在CM中看到它们。

如下，可以看到卷”vol0″以及”vol1″都处于DP状态。这是因为它们不是”活动的”，并且仅在您打开SVM”svm_dr”的故障转移事件中才会变为RW。

FsxId00a6c10ba5aee140e::> snapmirror show

Progress

Source Destination Mirror Relationship Total Last

Path Type Path State Status Progress Healthy Updated

fsx: XDP mysvm1: Snapmirrored

Idle – true –

FsxId00a6c10ba5aee140e::> vol show

Vserver Volume Aggregate State Type Size Available Used%

mysvm1 fsx_root aggr1 online RW 1GB 967.8MB 0%

mysvm1 vol0 aggr1 online DP 1TB 953.2GB 2%

mysvm1 vol1 aggr1 online DP 200GB 190.0GB 0%

3 entries were displayed.

FsxId00a6c10ba5aee140e::> vserver show

Admin Operational Root

Vserver Type Subtype State State Volume Aggregate

mysvm1 data dp-destination stopped fsx_root aggr1

stopped

此时重新检查目标文件系统的SSD容量，总容量为 861.7GB，可用容量为859.7GB，成功实现了SSD缩容。

FsxId00a6c10ba5aee140e::> storage aggregate show -fields size,availsize,storage-type,space-full-threshold-percent,percent-snapshot-space

aggregate storage-type percent-snapshot-space space-full-threshold-percent availsize size

——— ———— ———————- —————————- ——— ——-

aggr1 ssd 5% 96% 859.7GB 861.7GB

取消SnapMirror关系

• * *取消Snapmirror* *关系*

在FSxN目标系统执行 snapmirror break

FsxId00a6c10ba5aee140e::*> snapmirror break -destination-path mysvm1:

Notice: Volume quota and efficiency operations will be queued after “SnapMirror break” operation is complete. To

check the status, run “job show -description “Vserverdr Break Callback job for Vserver : mysvm1″”.

在FSxN目标系统删除snapmirror

FsxId00a6c10ba5aee140e::*> snapmirror list-destinations

Progress

Source Destination Transfer Last Relationship

Path Type Path Status Progress Updated Id

———– —– ———— ——- ——— ———— —————

fsx: XDP mysvm1: – – – 51562ad7-5bc9-11f0-b03a-d[已去除电话]ae2

FsxId00a6c10ba5aee140e::*> snapmirror delete -destination-path mysvm1:

在FSxN源系统删除snapmirror

FsxId0c9b5b9602b41fe9f::*> snapmirror release -destination-path mysvm1:

Warning: Snapshot copies on source “fsx” generated by SnapMirror for the purpose of mirroring to destination “mysvm3” will be

deleted. Once these Snapshot copies are deleted, it will not be possible to re-establish a mirroring relationship between

these two endpoints unless there are other common Snapshot copies between the endpoints.

Do you want to continue? {y|n}: y

Info: [Job 243] ‘SnapMirror Release’ job queued

在FSxN目标系统取消vserver peer

FsxId00a6c10ba5aee140e::*> vserver peer show

Peer Peer Peering Remote

Vserver Vserver State Peer Cluster Applications Vserver

———– ———– ———— —————– ————– ———

mysvm1 fsx peered FsxId0c9b5b9602b41fe9f

snapmirror fsx

FsxId00a6c10ba5aee140e::*> vserver peer delete -vserver mysvm1 -peer-vserver fsx

Info: [Job 135] ‘vserver peer delete’ job queued

此时，从FSxN源文件系统中已经无法查到对应vserver peer关系

FsxId0c9b5b9602b41fe9f::*> vserver peer show

There are no Vserver peer relationships.

在FSxN目标系统取消cluster peer

FsxId00a6c10ba5aee140e::*> cluster peer delete -cluster FsxId0c9b5b9602b41fe9f

FsxId00a6c10ba5aee140e::*> cluster peer show

This table is currently empty.

• *在FSxN源文件系统中取消Cluster peer关系

FsxId0c9b5b9602b41fe9f::*> cluster peer show

Peer Cluster Name Cluster Serial Number Availability Authentication

————————- ——————— ————– ————–

FsxId00a6c10ba5aee140e 1-80-000011 Available ok

FsxId0c9b5b9602b41fe9f::*> cluster peer delete -cluster FsxId00a6c10ba5aee140e

FsxId0c9b5b9602b41fe9f::*> cluster peer show

This table is currently empty.

小结

本文介绍的基于FSx for NetApp ONTAP的SVM灾难恢复(SVMDR)解决方案，为需要优化SSD存储容量的客户提供了一种创新的替代方案。这一方法特别适用于以下场景：

–

第一代FSx ONTAP 系统用户 – 尚未能够使用原生SSD缩容功能的客户，尤其是中国区域的企业。

–

周期性工作负载 – 具有明显高低峰的工作负载，如EDA设计项目、季节性数据处理或阶段性媒体制作。

–

成本敏感型项目 – 需要严格控制存储成本，避免为闲置容量付费的企业。

–

灾备与成本优化双重需求 – 既需要灾难恢复保障，又希望优化存储成本结构的组织。

通过SVMDR实现的SSD容量优化不仅是一个技术解决方案，更是一种战略性业务决策。它使企业能够实现以下价值：

–

显著的成本节约 – 通过将数据迁移到更小的文件系统，企业可以立即减少存储支出，根据实际观察，客户通常能够降低30%-50%的SSD相关成本。

–

业务连续性保障 – 整个过程保持服务可用性，最小化对业务运营的影响。

–

灵活的容量管理 – 根据业务周期动态调整存储资源，实现真正的按需付费模式。

–

无缝过渡路径 – 为未来迁移到支持直接SSD缩容的第二代系统提供了经验积累。

随着AWS持续优化FSx for NetApp ONTAP服务，我们期待第二代系统在更多区域的可用性，但在此之前，SVMDR方案为客户提供了一条有效的途径，实现了技术与业务的完美结合，帮助企业在云时代更加敏捷和高效地管理存储资源。

本篇作者

---

亚马逊AWS官方博客

云端机器人研发：在 AWS 实现 ROS 2 设备与 Isaac Sim 的 Lerobot 仿真及数据流

背景

在现代机器人开发领域，传统的开发模式往往依赖于真实硬件设备进行数据采集和算法验证，这种方式不仅成本高昂，而且存在设备损坏风险、环境限制等诸多挑战。随着云计算技术的快速发展，基于云端的机器人仿真平台为开发者提供了全新的解决方案。

本文将详细介绍如何利用AWS云计算平台的强大计算能力，结合NVIDIA Isaac Sim仿真环境，实现Lerobot SO-101机械臂的远程遥操作和数据收集。这种云端仿真方案不仅能够显著降低硬件成本，还能提供可扩展的计算资源，支持大规模并行仿真实验，为机器人算法的快速迭代和验证提供理想的开发环境。

架构设计

流程图

架构概述

该架构通过AWS EC2构建云端Isaac Sim仿真环境，实现本地机器人设备与云端仿真的无缝集成，支持远程开发和数据收集。

核心组件

本地环境

• Lerobot SO-101设备作为物理机器人平台
• ROS2数据采集节点负责传感器数据收集
• 开发者工作站提供开发界面
• Amazon DCV客户端实现远程可视化访问

AWS云端环境

• EC2实例运行NVIDIA Isaac Sim仿真引擎
• Amazon DCV Server提供高性能远程桌面服务
• rosbridge-suite实现ROS2与本地设备的通信
• S3存储服务保存仿真数据和模型

数据流程

实时数据同步

• 本地SO-101设备通过ROS2节点采集传感器数据
• 数据经WebSocket协议传输至云端rosbridge服务
• rosbridge将数据桥接到Isaac Sim仿真环境
• 仿真引擎处理后返回反馈数据到本地设备

远程开发访问

• 开发者通过DCV客户端连接云端工作站
• 获得Isaac Sim的完整图形界面访问权限
• 实时调试和配置仿真参数

数据持久化

• 仿真过程中的训练数据、模型参数自动收集
• 通过数据收集模块统一管理
• 存储至S3实现数据收集

实施方案

阶段一：AWS云端基础设施部署

1.1 NVIDIA Isaac Sim™开发工作站部署

访问AWS Marketplace：https://aws.amazon.com/marketplace/pp/prodview-bl35herdyozhw

部署路径：AWS控制台 → EC2 → 启动实例 → 浏览其他AMI → AWS Marketplace AMI → 搜索”NVIDIA Isaac Sim”

选择”NVIDIA Isaac Sim™ Development Workstation (Linux)”，配置网络安全组后启动实例。

推荐配置规格：

• 实例类型：

g6e.8xlarge（GPU加速计算优化）

• 存储容量：

500GB EBS gp3

• 安全组规则：开放端口22（SSH）、8443（DCV远程桌面）、9090（WebSocket通信）

阶段二：ROS2数据采集环境配置与Rosbridge服务部署

2.1 本地开发环境初始化

2.2 AWS实例Rosbridge服务配置

2.3 本地机器人设备接入配置

在本地开发环境中连接Lerobot SO-101机械臂：

2.4 ROS2通信桥接服务建立

部署本地USB数据到云端ROS2 Topic的桥接服务：

执行桥接服务，实现本地USB数据向远程EC2 ROS2 Topic的实时传输：

在AWS EC2实例上验证数据传输：

阶段三：Amazon DCV可视化通道配置

3.1 Amazon DCV远程桌面连接

• 在本地工作站安装Amazon DCV客户端：

https://www.amazondcv.com/

• 配置DCV连接参数：
• 服务器地址：

:8443

• 用户名：

ubuntu

• 密码：阶段二中设置的ubuntu用户密码
• 服务器地址：

3.2 Isaac Sim仿真环境配置

通过DCV远程桌面访问EC2实例，执行以下配置：

Isaac Sim环境配置流程： URDF模型导入：File → Import → 选择

~/Documents/SO-ARM100/Simulation/SO101/so101_new_calib.urdf

ROS2 Bridge扩展激活：Window → Extensions → 搜索”ROS 2 Bridge” → 启用”isaacsim.ros2.bridge” 关节状态订阅配置：Tools → Robotics → ROS2 OmniGraphs → Joint States

配置参数：

Topic中继服务启动：开启新终端执行

ros2 run topic_tools relay /joint_states /joint_command实现状态到命令的数据转换

仿真执行：点击Isaac Sim界面左侧Play按钮，通过本地遥控器实现对远程仿真环境的实时控制

阶段四：企业级数据管道与AI驱动开发生态

基于前述ROS2-Isaac Sim云端仿真基础设施，本阶段构建端到端的机器人AI开发工作流：

核心AWS服务集成 Amazon S3数据湖架构：利用S3的11个9可用性构建分层存储，集成S3 Intelligent-Tiering实现成本优化的海量机器人数据集管理 Amazon FSx for Lustre高性能存储：提供亚毫秒级延迟的并行文件系统，专为Vision-Language-Action (VLA)模型训练优化I/O性能 Amazon SageMaker ML运营平台：

• SageMaker Processing Jobs实现大规模多模态数据预处理
• 分布式训练支持，利用Spot实例降低成本高达90%
• Model Registry提供企业级模型版本管理和A/B测试能力

AWS Batch大规模并行仿真：基于Spot Fleet实现成本优化的GPU集群，支持Isaac Sim的大规模并行数据生成 Amazon Kinesis实时数据流：实现传感器数据的实时摄取和流处理，支持低延迟的机器人遥测分析

总结

技术架构价值

本文提出的双入口AWS云端机器人仿真架构，通过

rosbridge WebSocket数据通道和 Amazon DCV可视化通道的协同工作，实现了企业级的机器人开发环境：

架构优势分析

1. 云原生弹性能力

• 基于AWS EC2的按需扩缩容，适应不同规模的仿真需求
• GPU实例的动态调配，优化计算资源利用率
• 全球多区域部署，降低网络延迟

2. 机器人全链路开发

• Amazon S3实现可扩展的无限数据存储
• 与AWS机器学习服务的无缝集成，加速算法迭代
• 云机器人数据生成，训练，仿真验证等全流程实现快速融合。

结论

AWS云端机器人仿真平台代表了机器人开发技术的重要发展方向。通过本文介绍的双入口架构设计，开发者能够：

降低门槛：消除硬件投资壁垒，让更多开发者参与机器人技术创新 提升效率：并行仿真和云端协作显著加速开发周期 保障质量：企业级基础设施确保开发环境的稳定性和可靠性 促进创新：与AWS AI/ML服务的深度集成，推动智能机器人技术突破

随着云计算技术的持续演进和5G、边缘计算等新技术的融合，基于AWS的机器人仿真平台将成为推动机器人产业数字化转型的核心基础设施，为构建更加智能、高效的机器人生态系统提供强有力的技术支撑。

---

亚马逊AWS官方博客

Accelerating ROS 2 Simulation and Data Collection on AWS with NVIDIA Isaac Sim – Use Case: Lerobot SO-101

The Chinese version of this blog post is published at the same time.

Background

In modern robotics development, traditional workflows heavily rely on physical hardware for data collection and algorithm validation. While effective, this approach incurs high capital and operational costs, introduces risks of hardware wear or damage, and is constrained by environmental and logistical factors. With the rapid development of cloud computing, cloud-native robotic simulation platforms have emerged as a transformative alternative, which enable safe, repeatable, and scalable experimentation without the limitations of physical test environments.

This article details how to leverage AWS’s powerful computing capabilities, combined with the NVIDIA Isaac Sim simulation environment, to achieve remote teleoperation and data collection of the Lerobot SO-101 robotic arm. This cloud-based simulation solution significantly reduces hardware costs, offers scalable compute resources, and supports large-scale parallel simulation experiments — providing an ideal environment for fast iteration and verification of robotics algorithms.

Architecture Design

Workflow Diagram

Architecture Overview

The architecture builds a cloud-based Isaac Sim environment on AWS EC2, integrating local robotic devices with cloud simulation for seamless remote development and data collection.

Core Components

Local Environment

• Lerobot SO-101 as the physical robot platform
• ROS2 data collection node for sensor data acquisition
• Developer workstation for coding and debugging interface
• Amazon DCV client for visualized remote access

AWS Cloud Environment

• EC2 instances running NVIDIA Isaac Sim
• Amazon DCV Server for high-performance remote desktop access
• rosbridge-suite for ROS2 communication with local devices
• Amazon S3 for simulation data, models, and artifacts storage

Data Flow

Real-time Data Synchronization

• The local SO-101 device collects sensor data via ROS2 node
• Data is transmitted via WebSocket to the cloud rosbridge service
• rosbridge bridges the incoming data streams to the Isaac Sim
• Simulation results are processed and fed back to the local device in real time

Remote Development Access

• Developers connect to the EC2 workstation via the DCV client
• Full graphical access to Isaac Sim is provided
• Simulation can be debugged and configured interactively in real time

Data Persistence

• Training data and model parameters generated during simulation are automatically captured
• A dedicated data collection module ensures centralized management and consistency
• All artifacts are stored in Amazon S3, enabling backup, version control, and downstream ML workflows

Implementation Steps

Phase 1: Deploy Issac Sim on AWS

1.1 Launch NVIDIA Isaac Sim™ Development Workstation

Marketplace link: NVIDIA Isaac Sim™ Development Workstation

Navigate to: AWS Console → EC2 → Launch Instance → AWS Marketplace AMIs → search “NVIDIA Isaac Sim”.

Choose

NVIDIxA Isaac Sim™ Development Workstation (Linux), then configure security groups and launch the instance.

Recommended configuration:

• Instance type:

g6e.8xlarge(GPU-accelerated)

• Storage:

500GB EBS gp3

• Open ports:

22(SSH),

8443(DCV Remote Desktop),

9090(WebSocket communication)

Phase 2: Configure ROS2 Data Collection and rosbridge Service

2.1 Setup Local Development Environment

2.2 Deploy Rosbridge service on AWS

2.3 Setup local robot device connection

On your local developer workstation, connect the

Lerobot SO-101 robotic arm and execute the following commands:

2.4 Establish the ROS2 Communication Bridge

Run the following commands on your local machine to automatically forward USB data from the Lerobot device to ROS2 topics on the remote EC2 instance:

Then, log in to your AWS EC2 instance to verify the ROS2 topics.

Phase 3: Setup Amazon DCV Visualization Channel

3.1 Connect to Amazon DCV Remote Desktop

• On your local computer, install the

Amazon DCV clientfrom https://www.amazondcv.com/.

• Use the client to connect to the EC2 instance. Configure the connection with the following parameters:

Server:

:8443

Username:

ubuntu

Password: the Ubuntu password you configured in Step 2

–

3.2 Initialize the Isaac Sim Environment

Access the remote EC2 instance via the DCV client and run:

Follow the steps below inside the Isaac Sim interface:

URDF Model Import: File → Import → Select

~/Documents/SO-ARM100/Simulation/SO101/so101_new_calib.urdf

ROS2 Bridge Extension Activation: Window → Extensions → Search “ROS 2 Bridge” → Enable “isaacsim.ros2.bridge”

Joint State Subscription Configuration: Tools → Robotics → ROS2 OmniGraphs → Joint States

Configuration parameters:

• Articulation Root:

/World/so101_new_calib/root_joint

• Enable

Subscriberoption

• Confirm and apply the configuration

Topic Relay Service Startup: Open a new terminal and run

ros2 run topic_tools relay /joint_states /joint_commandto convert state messages into command data.

Simulation Execution: Click the Playbutton on the left panel of the Isaac Sim interface to start the simulation. This enables real-time control of the robot within the remote simulation environment using the local teleoperation device.

Phase 4: Toward an Enterprise-Grade Data Pipeline in an AI-Driven Development Ecosystem

Building on the ROS2–Isaac Sim cloud simulation infrastructure described above, this phase can establish an end-to-end AI-driven robotics development workflow.

Key AWS Service Integrations Amazon S3 – Data Lake Architecture: Leverage S3’s 11 9s of durability to build tiered storage, with S3 Intelligent-Tieringoptimizing costs for managing large-scale robotics datasets. Amazon FSx for Lustre – High-Performance Storage: Provides sub-millisecond latency with a parallel file system, delivering optimized I/O performance for Vision-Language-Action (VLA)model training. Amazon SageMaker – ML Operations Platform:

• Use

SageMaker Processing Jobsfor large-scale multimodal data preprocessing

• Scale distributed training with Spot Instances, reducing training costs by up to 90%
• Leverage

Model Registryfor enterprise-grade version management and A/B testing

• Use

AWS Batch – Large-Scale Parallel Simulation: Use Spot Fleets to provision cost-optimized GPU clusters that support large-scale parallel data generation in Isaac Sim. Amazon Kinesis – Real-Time Data Streams: Enable low-latency ingestion and processing of sensor data, supporting real-time robotic telemetry and analytics.

Summary

Architectural Value

The dual-entry AWS cloud robotics simulation architecture introduced in this article — combining the

rosbridge WebSocket data channel and the Amazon DCV visualization channel — delivers an enterprise-ready development environment for robotics.

Key Advantages

1. Cloud-Native Elasticity

• On-demand scaling with AWS EC2 to support varying simulation workloads
• Dynamic GPU provisioning for optimal resource utilization
• Multi-region deployment to reduce latency globally

2. End-to-End Robotics Development

• Amazon S3 provides virtually unlimited and scalable data storage
• Seamless integration with AWS AI/ML services accelerates algorithm iteration
• Full lifecycle support for data generation, training, and simulation validation in the cloud

Conclusion

The AWS cloud robotics simulation platform represents a major step forward in how robotics development is conducted. Through the dual-entry architecture outlined in this article, developers can:

Lower Barriers to Entry: Remove the need for costly hardware investment and broaden access to robotics innovation Accelerate Development: Enable faster cycles with parallel simulation and cloud-based collaboration Ensure Quality: Leverage enterprise-grade infrastructure to maintain stability and reliability Foster Innovation: Drive breakthroughs in intelligent robotics through deep integration with AWS AI/ML services

As cloud computing continues to advance—together with 5G, edge computing, and other emerging technologies—AWS-based robotic simulation platforms are poised to become a

core enabler of digital transformation in the robotics industry, providing the foundation for building smarter and more efficient ecosystems.

---

亚马逊AWS官方博客

从误判到精准：游戏社区 AI 审核的工程化实践

引言

游戏社区作为典型的 UGC（用户生成内容）场景，用户遍布全球，涉及中、英、日、韩、俄、西班牙语、阿拉伯语、法语等多种语言。讨论氛围活跃，但其中不可避免会夹杂 辱骂、仇恨、色情、暴力、涉政 等违规言论。

平台需要在不伤害社区氛围的前提下，做到

及时、准确的内容审核。但传统规则引擎容易出现“误杀”或“漏判”，直接依赖大语言模型审核又存在 准确率不高、分类不稳定 的问题。

我们遇到的客户需求还有一些额外挑战：

• 审核对象是

长文本（动辄上千字符）；

• 无法通过向量检索或 RAG 切片，因为长文本拆分后上下文丢失，相关度很差；
• 模型需要一次性给出

判定结果（Pass/Reject ），并在 Reject 时指定 10 种违规分类之一。

在这样的背景下，我们为一家游戏公司落地了一套

提示词工程 + ReAct 框架 + 工程化架构 的 AI 审核方案。最终整体准确率提升到了 81%。需要说明的是，对比基准是客户的人工审核数据，而人工标注过程存在“多人多日、缺乏复核”的情况，口径并不完全统一。因此，我们只能说模型的 81% 一致性 大体上达到了人工审核的水平，具体效果还需结合更严格的标注体系进一步验证。

整体方案架构

工程化落地能力

在文本审核项目中，提示词优化只是其中一步。真正支撑业务落地的，是一整套

可观测、可回滚、可扩展 的工程架构： 蓝绿部署：通过 Amazon Bedrock 的多版本部署机制，提示词优化和模型更新可以安全上线，支持灰度/回滚。 日志与判例库：所有审核请求和结果写入 DynamoDB / OpenSearch，用于后续的回溯分析与提示词再训练。 配置与流控：AWS AppConfig + 控制 Lambda，保证在高并发/大流量场景下系统稳定。 端到端可监控：从请求入口到最终存储都有日志链路，方便快速排查问题。

提示词冷启动阶段：提示词从 0 到 1

在没有任何“黄金提示词”的前提下，拿到可用的提示词方法有很多种，甚至可以直接让AI生成一个。

但我们这里采用冷启动的办法，先让模型把客户给的几千条样本过一遍。每跑一条，就拿它的结果和人工标注比对，把提示词里有问题的地方修掉。这样循环一轮，等于帮我们凑出了一个“能跑”的初始版本，后面再慢慢打磨。

我们的做法是：

• 让大模型逐条读取客户提供的数千条人工审核样本（每条都包含文本、判定结果以及违规分类）。
• 在阅读过程中，模型会尝试基于已有样本生成提示词。
• 每读取一条样本，就对提示词做一次微调，逐步修正不合理的部分。
• 完成一轮全量样本后，就得到一个

初始提示词，作为进一步优化的基线。

例如，最初我们生成的提示词大致如下：

在冷启动阶段，这个提示词的准确率并不算高，容易出现

灰色语境误判（例如把二次元梗误判成色情内容），或者 多语言覆盖不足（对阿拉伯语、西班牙语等的判定不稳定）。但它为后续优化奠定了基础。

ReAct 框架引入：让模型“先思考，再行动”

冷启动阶段得到的提示词虽然能跑通流程，但在一些关键问题上仍然存在不足：

灰色语境：例如二次元梗、讽刺语气，容易被误判为违规。 多语言一致性：某些语言（如阿拉伯语、西班牙语）分类不稳定。 输出随机性：相同输入多次测试，结果可能不同。

为了解决这些问题，我们在提示词中引入了

ReAct （Reason + Act ）框架。 ReAct 的核心思想是让大模型先进行显式的“推理”步骤，再做最终的“行动”输出。这样可以减少随机性，并提高可解释性。

ReAct 框架在审核场景中的拆解

Reasoning （思考）：

• Step 1: 确定文本语言
• Step 2: 提取潜在违规关键词或短语
• Step 3: 将关键词与违规类别进行匹配
• Step 4: 根据上下文和类别，决定 Pass / Reject

Action （行动）：

• 输出最终 JSON 结果（判定 + 类别）。

示例提示词片段

下面是我们在 ReAct 框架下的一部分提示词（简化版）：

这样设计后，准确率虽不高，容易把二次元梗当成色情，或对小语种判定不稳。但它给我们提供了一个起点。

ReAct 框架下的实现示例（Python 伪代码）

在工程落地中，我们通过 Agent 框架调用大模型，来执行上述 ReAct 推理：

在 ReAct 机制下，我们观察到模型的表现明显更加稳定：

• 对多语言输入的分类一致性增强；
• 对灰色语境（如“玩梗”）的误判显著减少；
• 审核理由透明，可以复盘和解释。

多轮循环优化：从 3 轮到 10+ 轮，我们如何选定 5 轮

在引入 ReAct 之后，我们对“

每轮：全量跑样本 → ** **纠错 → ** **修提示词**”的闭环进行了系统化实验，对比不同轮数的收益与成本： **3** **轮：欠拟合

• 典型问题：仍然存在多语言一致性不足、灰色语境误判偏多。
• 现象：指标提升明显低于 5 轮，呈“上升未饱和”状态。

5** **轮：效果-** **成本最优点

• 进入

收益递减区间的起点，准确率与稳定性基本收敛。

• 与 10 轮相比，

增益不明显，但计算/时间成本显著更低。

• 进入

10** **轮：与 5** **轮接近

• 指标接近 5 轮，

差异在统计误差范围内。

• 成本约为 5 轮的 2 倍（推理费用、时间占用、并发管理）。
• 指标接近 5 轮，

10** **轮以上：可能出现负面影响

• 过拟合于“特定审核员口径/特定样本簇”，提示词

变窄。

• 对跨天、跨审核员、跨语种的泛化能力

略有下降。

• 过拟合于“特定审核员口径/特定样本簇”，提示词

结论：在成本—收益的综合考量下，我们选择 5 轮 作为生产建议，并给出 实践区间 5–8 轮（8 轮用于更严格的场景/关键上线前的稳健性校验）。

版本对比

|版本

|轮次

|核心改动

|效果观察

|主要问题

|1

|v1

|1

|冷启动提示词，直接分类

|基线 72%

|灰色语境误判、多语言不稳

|2

|v2

|3

|加语言识别、关键词提取

|~77–79%

|仍有欠拟合迹象

|3

|v3

|5

|ReAct 推理链条收敛、分类边界精炼

|81%

|标注噪声成为主限因素

|4

|v4

|8

|规则精修、输出一致性增强

|~81%±

|提升接近噪声天花板

|5

|v5

|10+

|更细粒度规则

|

收益不增反降 |过拟合风险上升，提示词会过于具象化

Temperature 调参经验

在我们反复调提示词的过程中，发现

temperature ** **参数** 对结果影响较大。 **在调试和实验阶段

我们会把 temperature 开得比较高，大概在

8–1.0。这样模型会更“活跃”，能从不同角度去理解文本。比如：

• 二次元梗、讽刺话语、跨语种甚至夹杂 emoji 的内容，高 temperature 下模型能给出更多解释；
• 这对我们来说很有帮助，可以暴露提示词里没考虑到的边角情况，方便我们快速改进。

在真正上线的时候

我们把 temperature 拉到

0–0.1。

• 这样模型输出会尽量固定，不会同一条内容前后给出不一样的结果；
• 对审核业务来说，

稳定和可解释比“有创造力”要重要得多。

所以我们的做法是：

调试阶段高 temperature ，生产环境低 temperature，既能探索问题，也能保证上线稳定。

实验结果（口径与噪声说明）

整体准确率**： **81%** **正向召回准确率（合规判定）**： **76%** **负向召回准确率（违规判定）**： **90%** **评估口径与数据噪声：

• 基准为客户提供的

人工审核数据；多人、分多日完成， 未建立双盲复核，口径存在 天然不一致。

• 因此 81% 的一致性，

已经接近甚至可能超过多人人工的稳定水平。

• 在多语言与灰色语境（玩梗、反讽）上，

ReAct 提示词显著降低了随机误判，并提升了跨语言一致性。

代表性案例（模拟真实数据）

|文本（节选）

|人工标注

|基线模型

|ReAct 提示词

|1

|“You are stupid, I hate you.”

|仇恨言论

|Pass ❌

|Reject ✅（Hate Speech）

|2

|“This waifu is so hot omg 🔥”

|合规（二次元语境）

|Reject ❌

|Pass ✅

|3

|“The devs are scammers, I hope they burn.”

|仇恨言论

|Reject ✅

|Reject ✅（Hate Speech）

|4

|“Hello”

|Pass✅

工程实现要点

核心代码

1) 日志与可追溯性

目的：记录每个文件、每条样本的判定与指标，支撑问题回溯。 实践要点：

• 文件 + 控制台双通道日志；
• 关键信息结构化输出（accuracy、pass/reject、category 指标）；
• 每轮/每版本生成独立 log 文件，便于对比。

2) 数据装载与多文件批处理

Excel 列位处理：文本、标签列提取。 要点： 统一 label 口径：

Pass → 1 / Reject → 0；

类别精度：对

Reject的类别进行

单独统计，便于发现“弱类”。

–

3) 大模型调用与推理参数（使用botocore调用Bedrock）

默认参数：

temperature=0.0、

max_tokens=1000，确保

可重复与稳定输出，

max_tokens过大对效果影响有限;

超时/ 重试：

botocore.config.Config中设置

connect_timeout/read_timeout/retries；

4) 提示词模板与占位

• 通过

prompt_template.format(text=…)注入样本正文。

建议：模板内统一约束 唯一 JSON 输出，便于解析；输出前置 ReAct 步骤（语言识别、关键词提取、类别匹配、最终判定）。

5) 并发验证与节流

多文件并行：

ThreadPoolExecutor按文件粒度并发；

速率控制：

time.sleep(0.5)做基础节流，避免限流，注意您Amazon Web Service账号内Quota；

6) 评估与报表

• 输出四个 Sheet：

Results / Overall Metrics / File Metrics / Category Metrics+

Prompt。

好处：

Category Metrics能快速定位

薄弱类别；

Prompt留存使

版本可复现；

• 结合日志快速回放异常样本。

–

评估口径：统一使用“与人工标注的一致性”为主指标（Overall/Pass/Reject accuracy + Category accuracy），并在文中 显式声明标注噪声与“多审核员/多日/未复核”的现实约束。

经验总结（针对轮数选择与成本）

建议轮数： 5–8 轮；5 轮用于大多数生产场景，8 轮用于上线前稳健性校验。 避免过拟合：10 轮以上容易对某些审核员口径或小样本簇过拟合，泛化变差。 成本优化：

• 串并结合：文件级并行 + 样本级节流；
• 固定

temperature，保证一致性，减少“返工轮”；

• 对类别

分层抽样做小集评估，优先修“弱类”，再全量回归。

• 在最终工程化实施时，可以将提示词放到system prompt中，同时开启cache，以降低成本。

JSON** **仅输出与解析健壮性

• 强调输出格式的规范化，降低对输出结果的不统一增加生产系统的不确定性。
• 部分提示词
• 输出

落地经验

在整个项目落地的过程中，我们积累了几条关键经验：

提示词必须贴合业务标注体系:通用的“内容安全”提示词远远不够。只有结合客户的 10 类违规分类，并不断对照人工审核样本修正，才能让模型输出结果和业务口径保持一致。 ReAct 框架带来了可解释性:模型先进行“思考”，再给出“行动”，让每一步逻辑更加透明。我们可以展示模型的推理逻辑（语言识别、关键词提取、类别匹配），增强了审核结论的可信度。 数据质量是上限，提示词优化是下限:我们使用的人工审核数据存在多人、分多日完成、缺乏复核等问题，导致标注结果本身带有噪声。在这种情况下，模型的准确率“天花板”就会受到影响。换句话说，提示词优化能逼近人工水平，但要进一步突破，还需要客户改善数据标注流程。 成本与效果的权衡:我们在实验中验证了 3、5、10 轮迭代的差异，最终选择 5 轮作为最优点。同样地，temperature 参数在调优阶段设置高值，在上线阶段锁定低值，也是平衡创造性与稳定性的工程实践。

未来优化方向

自动化提示词优化

• 引入 AutoPrompt、RLHF 等方法，让提示词进化不再完全依赖人工试错。
• 在更多语言、更多语境下持续收敛。

更细粒度的分类与标签

• 客户的 10 类违规类别是第一层级。
• 后续可以扩展子类别（如“仇恨言论 → 针对性别 / 种族 / 职业”），满足更精细化的内容治理需求。

成本优化

• 会结合Bedrock的cache特性，增加对system prompt、user prompt的cache，在保证审核效果的情况下，尽可能优化成本。
• 成本详情请参阅Amazon Bedrock成本页面（https://aws.amazon.com/cn/bedrock/pricing/）与Claude模型成本页面（https://docs.claude.com/zh-CN/docs/about-claude/pricing）

结语

从最初的“误判频发”，到最终实现

81% 的整体准确率，我们通过 提示词工程 + ReAct 框架 + 工程化架构，帮助客户构建了一套 稳定、可观测、可扩展 的游戏社区审核系统。

这个过程的价值在于：

• 它不仅是一次模型调优尝试，而是一套

可工程化复制的方法论；

• 在

UGC 社区、社交平台、直播审核等场景，都可以直接复用这套 提示词优化 + 架构闭环的方案；

• 通过

日志、判例库、蓝绿部署等工程实践，我们让审核系统具备了 一致性、可追溯性和快速迭代能力。

最终，这个项目让我们看到了

大语言模型 + ** **工程化落地** 在内容审核领域的潜力： **提示词调优**让模型快速逼近甚至超越人工审核的一致性； **工程化架构**确保系统在 **高并发、大规模多语言**审核场景下依旧稳定运行； **端到端闭环**使审核系统不仅能解决当下问题，还能通过数据回流不断自我进化。 ***前述特定亚马逊云科技生成式人工智能相关的服务目前在亚马逊云科技海外区域可用。亚马逊云科技中国区域相关云服务由西云数据和光环新网运营，具体信息以中国区域官网为准。

---

亚马逊AWS官方博客

如何在Amazon Athena中在线解密在Amazon Glue DataBrew中加密的数据

背景分析

在企业数字化转型的浪潮中，依托于数据驱动的决策和洞察变得尤为重要。云端数据湖已成为企业汇聚、加工和分析海量数据的重要平台。而于此同时，全球各国对个人隐私数据保护也越来越重视，要求企业在收集、使用和传输个人信息PII(Personally Identifiable Information)时遵守更加严苛的合规要求。因而，企业需要对敏感数据采取合适的保护措施，来防止个人身份信息 PII 数据泄露。

Amazon Glue DataBrew 是亚马逊云科技数据服务Amazon Glue中一款可视化数据处理工具。数据分析师不用编码，采用图形化的界面就可以对数据集进行操作。Amazon Glue DataBrew内置了多种功能，能够识别敏感数据并进行大规模预处理，其中一项关键功能就是对PII数据(如姓名、社保号、地址等)进行加密，防止数据泄露。虽然Amazon Glue DataBrew对加密的数据集提供了对应解密的方法，但是该方法仍然需要调用Amazon Glue DataBrew的Recipe解密方法进行数据解密处理，这不仅繁琐而且会形成多个副本，难以满足即时解密查询的要求。

本文介绍了如何在Amazon Athena中，通过用户定义函数UDF(User Defined Function)在查询过程中解密这些在Amazon Glue DataBrew中加密的数据。该UDF以Amazon Lambda函数的方式实现，通过精细的权限控制，可以确保只有获得授权的用户才能执行解密操作，查看明文数据，其他未授权用户只能看到加密后的字段。这种方法既保护了敏感数据的安全，又为授权用户提供了灵活的数据访问途径，实现了安全性与可用性的平衡。

方案场景说明

为了演示整个数据加密和解密流程，我们需要提前准备一份包含敏感信息的样例数据。我们从 DLPTEST (https://dlptes[已去除短链接]m) 下载名为 sample_data.csv 的示例数据集。这个文件包含模拟的个人身份信息（PII）例如姓名、地址、电话号码、电子邮件地址和社会安全号码（SSN）等。该方案执行流程如下图所示，无论在亚马逊云科技的中国区域还是全球区域都可实现：

该方案的具体执行流程如下：

创建源数据集：我们将下载的包含敏感信息的样例数据上传到一个未加密的 Amazon S3 存储桶中。然后，在 Amazon Glue DataBrew 中创建一个新的数据集，建立与这个 S3 存储桶中数据的连接。方便后续的数据处理和加密操作。 识别敏感信息：利用Amazon Glue DataBrew 的内置功能来识别数据中的敏感信息列。在 DataBrew 的Profile Job中启用个人身份信息（PII）统计功能，该作业会自动扫描数据集，识别出可能包含 PII 的列，如姓名、地址、社会安全号码等。 加密敏感数据：针对识别的 PII 列，我们在 DataBrew 中创建一个 处置方案Recipe。这个 Recipe 包含了对特定敏感列应用加密转换函数的步骤。通过执行一个 DataBrew 作业，调用 Recipe中的加密过程加密源数据集的指定列。作业完成后，加密后的数据输出到指定的目标 S3 存储桶中，实现了加密后敏感数据的安全存储。 设置数据目录：为了便于后续查询和使用加密后的数据，我们需要建立相应的元数据目录。通过在Amazon Athena中运行DDL语句，在 Amazon Glue Data Catalog中，基于加密后的数据构建数据库和表，来创建元数据条目，这样，加密后的数据可以在Amazon Athena中通过标准 SQL 接口进行查询。 实现安全查询：开发并部署一个用户自定义函数（UDF）作为 Amazon Lambda 函数，用于解密数据。部署成功后，在 Amazon Athena 中引用这个 UDF，使其能够在查询执行时调用解密 Amazon Lambda 函数。这样，用户就可以通过 Amazon Athena 执行 SQL 查询，实时调用解密函数查看明文数据，实现了敏感数据的安全查询和访问。另外，通过严格的授权，可以防止非授权用户通过其他途径获取明文。

方案实现

准备源数据

测试数据来自于DLPTEST提供的样例数据，访问 https://dlptes[已去除短链接]m/sample-data.csv 下载csv格式文件。通过控制台在中国宁夏区域 cn-northwest-1 中创建存储桶 databrew-pii-data-zhanla，并在存储桶内创建三个文件夹(Prefix)，其中：

–

sensitive_data_input用来存放源数据。 encrypted_data_output用来存放加密后的输出文件。 profile_job_out用来存放Profile作业的统计输出。

–

文件夹建好后，上传文件文件“

sample-data.csv” 到该S3存储桶中的 “ sensitive_data_input” 文件夹中。也可以运行如下的cli命令达到同样目的：

识别敏感信息

上载数据后，我们需要创建DataBrew数据集，运行DataBrew Profile作业，来分析数据集中的PII敏感数据列。

创建源数据集

按照以下步骤创建 Amazon Glue DataBrew 数据集DataSet：

• 在 DataBrew 控制台左侧的导航栏，选择数据集 “

DATASETS”。

• 选择连接新数据集 “

Connect new dataset”，在向导页中：

–

• 数据集名称

Dataset name，输入

data-pii-sample。

• 在连接到新数据集

Connect to new dataset下，选择 “ Amazon S3” 作为数据源。

• 对于 S3文件的路径

Enter your source from S3，输入 “ sample-data.csv” 文件的 S3 路径

s3://databrew-pii-data-zhanla/sensitive_data_input/sample-data.csv。

• 文件类型

Selected file type选择 “ CSV”。 列标题 Column header values选择 “ Treat first row as header”。

• 数据集名称
• 滚动到页面底部，点击

【Create dataset】创建数据集。

运行源数据集的Profile Job

数据集的Profile Job可以让数据分析师了解数据集的数据形态，比如值的分布、区间、极值、平均值、有效值等，还可以帮助发现是否有PII数据。接下来我们创建并运行一个数据形态分析作业 Profile Job对数据进行分析。

• 在DataBrew左侧导航栏中，选择数据集“

DATASETS”。

• 选择我们创建的数据集 “

pii-sample”。

• 点击运行数据分析作业

【Run data profile】**，在弹出的对话框中，点击创建配置文件作业 **【Create profile job】。

• 在Create Job的向导页中,

–

• 在

PII statistics中选择 “ Enable PII statistics”，这样Profile Job 就会识别数据集中的PII列。注意：该选项默认是Disable的，需要手动激活。对于 PII categories, 选择 “ All categories”。

• 在

–

• 其他的设置保持缺省值不改变。在Permissions选项中， Role name中选择 “

Create New IAM Role”， 在 new IAM role suffix中输入PII-DataBrew-Role。这样会自动创建以PII-DataBrew-Role为后缀的Glue运行角色。

• 其他的设置保持缺省值不改变。在Permissions选项中， Role name中选择 “
• 点击

【Create and run job】来运行作业，等待数据分析作业Profile Job运行完毕后，可以在数据集中的 Data profile overview选项卡中来查看数据状况。PII的识别信息显示在选项卡的右面，包括已识别的 PII 列，以及这些列映射到的 PII的统计类别。

以上，通过运行数据集的Profile作业，对源数据Dataset进行初步的分析，识别出了存放PII的信息列，在接下的处理中，我们会对识别的PII列的数据进行加密。

加密敏感数据

在Amazon Glue DataBrew中有多种对敏感数据的处理方式， 包括屏蔽、哈希或者加密等。当下游的应用程序需要获取原始的数据时，需要采用加密的方式进行处理。Amazon Glue DataBrew提供了两种加密方式： 确定性加密（Deterministic Encryption） 和非确定性概率加密（Probabilistic Encryption）。

• 其中

确定性加密（Deterministic Encryption）调用DataBrew中RECIPE的 “ DETERMINISTIC_ENCRYPT” 方法加密。其原理是通过访问以Base64编码格式存储在Amazon Secrets Manager中的256位密钥 AES-GCM-SIV进行加密，加密算法使用内置的Amazon LC github 库。 采用这种方式加密后的数据只能通过Amazon Glue DataBrew中的“ DETERMINISTIC_DECRYPT”方法进行解密。该方法适合加密一些不需要参与运算，却需要以确定值参与统计，并且最后还可以还原的字段。 非确定性概率加密（Probabilistic Encryption）调用RECIPE中的 “ ENCRYPT” 方法，借助Amazon KMS服务对源列中的值进行加密。由于加密过程是调用标准的加密SDK进行加密的，因而解密过程不但可以在DataBrew内部调用“ DECRYPT” 进行解密，还可以使用加解密SDK在DataBrew外部解密。该方法适合加密一些不需要参与运算，也不需要参与统计，但是在特定时刻，有特定权限的人还是可以将其还原的数据处理。

在本方案中，我们对源数据集中的PII列SSN进行非确定性加密后，在Athena中调用UDF进行解密。

创建KMS Key

在加密前，我们需要创建一个Amazon KMS Key。在Amazon KMS服务的控制台中，点击

【Create a Key】，进入创建Amazon KMS Key的向导页面：

• 在第一步

Configure Key中选择Key类型为对称 “ Symmetric”， Key的用途选择 “ Encrypt and decrypt”。

• 在第2步

Add Labels中， 填入Key的别名：databrew-pii-key。

• 在第3步选择可以管理该Key的用户或者角色。
• 在第4步中需要赋权给相应的databrew中Job运行的Role，选择我们前面在创建分析Profile作业时，已经自动创建的角色：AWSGlueDataBrewServiceRole-PII-DataBrew-Role。
• 完成剩余步骤，直到该Amazon KMS Key创建成功。这里可以查看Amazon KMS Key的Key Profile，需要对后面的Amazon Lambda进行授权。

创建处置方案Recipe，对敏感字段进行加密

在识别出数据集中的 PII 列，并创建了Amazon KMS Key之后，我们在 DataBrew 项目中使用敏感类的转换函数来执行加密过程。

按照如下步骤创建 DataBrew 项目：

• 在 DataBrew 控制台左侧导航栏，选择项目

Projects。

• 点击创建项目

【Create Project】后，在 Create Project引导页面中：

–

• 在项目名称

Project Name，输入：prj-pii-encryption，系统会自动填充Recipe Name为：prj-pii-encryption-recipe。

• 对于选择数据集

Select a Data Set，选择我的数据集 “ My DataSets”，然后，选择前面创建的数据集 “ data-pii-sample”。

• 在

Permissions中选择同样的前述生成的IAM角色：AWSGlueDataBrewServiceRole-PII-DataBrew-Role。

• 在项目名称

–

• 点击创建项目

【Create Project】，数据集在经过几分钟加载后，在完整的编辑器上面有一排图标。通过这些图标，可以对给定的行列进行各种编辑，包括进行加密的操作。我们这里以列SNN为例进行加密。

• 选中

SSN列，在菜单 【MORE】→【SENSITIVE】中，选择 Encryption->Probabilistic Encryption。

• 在

Data Encryption的具体配置向导中，确保：

–

Source columns选择 “ SSN”。 Encryption options选择不确定性概率加密 “ Probabilistic encryption”。 Encryption key选择我们预先生成的Key “ databrew-pii-key” 的arn: “arn:aws-cn:kms:cn-northwest-1:[已去除电话]:key/315dc82c-249b-499e-942b-24be302c43f2” 。 Apply encryption to选择完整字符串值 “ Full string value”。 Apply transform to选择 “ All rows”。

–

–

• 点击 Apply按钮，可以看到数据已经被加密。
• 点击

【Publish】按钮发布该处置方案Recipe。

创建并运行 DataBrew 作业对数据集加密

基于我们准备好的Recipe，创建一个作业来将RECIPE中设定的数据变换逻辑应用到创建的

pii-example 数据集。

• 在 DataBrew 控制台上，选择作业

Job。

• 选择创建作业

Create job。在Create Job的向导页上：

–

• 对于作业名称

Job Name，输入名称: pii-encyption-job。 Job type选择 “ Create a recipe job”。

• 在Job Input中，

Run On选择 “ Dataset”，通过查询选择输入 Choose dataset: pii-sample 数据集, Select a recipe选择prj-pii-encryption-recipe 作为处置方案。

• 在文件类型的作业输出

Job output settings设置下，可以选择最终存储格式为 “ Parquet”，对于压缩 Compression，选择 “None”。

• 对于 File output storage，通过点击

【Settings】选择 “Replace output files for each job run”。

• 对于 S3 位置，选择 S3 输出为 s3://databrew-pii-data-zhanla/encrypted_data_output/。
• 在

Permissions中，对于角色名称 Role Name，依然选择我们之前已经创建的 IAM 角色: AWSGlueDataBrewServiceRole-PII-DataBrew-Role。

• 对于作业名称

–

• 点击按钮

【Create and run job】创建并运行作业 , 该作业会自动运行并对源数据集中的数据列SSN进行加密后输出到指定的S3文件夹中。

创建数据目录

通过在Athena的查询编辑器中运行如下SQL， 在Amazon Glue Data Catalog中创建相应数据库 “

pii_sample_db” 以及表 “ databrew_pii_sensitive_data” 和 “ databrew_pii_encrypted_data” 。这两个表分别对应加密前的数据和加密后的数据。

create database pii_sample_db

–Create table databrew_pii_sensitive_data from S3 file with csv format

CREATE EXTERNAL TABLE databrew_pii_sensitive_data(

SSN string,

gender string,

birthdate string,

maidenname string,

lastname string,

firstname string,

address string,

city string,

state string,

zip string,

phone string,

email string,

cc_type string,

CCN string,

cc_cvc string,

cc_expiredate string

)

ROW FORMAT DELIMITED

FIELDS TERMINATED BY ‘,’

LOCATION

‘s3://databrew-pii-data-zhanla/sensitive_data_input/’

TBLPROPERTIES (“skip.header.line.count”=”1”);

–Create table databrew_pii_encrypted_data from S3 file with Parquet format

CREATE EXTERNAL TABLE databrew_pii_encrypted_data (

SSN string,

gender string,

birthdate string,

maidenname string,

lastname string,

firstname string,

address string,

city string,

state string,

zip int,

phone string,

email string,

cc_type string,

CCN string,

cc_cvc int,

cc_expiredate string

)

STORED AS PARQUET

LOCATION ‘s3://databrew-pii-data-zhanla/encrypted_data_output/’

执行如下查询可以查看到数据表

databrew_pii_encrypted_data 中列 SSN为加密字段

SELECT SSN from databrew_pii_encrypted_data

该加密字段由于采用标准信封加密，所以比明文本身增添了较多的字节。

实现安全查询

这里我们会通过Amazon Lambda创建UDF，并在在Amazon Athena中调用UDF，解密表

databrew_pii_encrypted_data 中被加密的字段 SSN。

创建解密Lambda函数

基于如下java代码创建Amazon Lambda函数

“athena-udf-gluepii”。主入口函数decrypt接受两个入参， “ciphertext” 为加密后的密文字符串, “ keyArn” 为Amazon KMS Key对应的arn。源代码可以访问代码库。

由于所创建的Amazon Lambda需要访问前面创建的Amazon KMS Key进行解密，因此需要为Amazon Lambda的运行角色Role提供访问Key的权限，用来解密:

在Amazon Athena中通过UDF调用Lambda函数

在Amazon Athena的查询窗口中，执行带有UDF的查询语句进行解密操作：

USING EXTERNAL FUNCTION decrypt(t1 varchar, t2 varchar)

RETURNS varchar

LAMBDA ‘athena-udf-gluepii’

SELECT

decrypt(ssn, ‘arn:aws-cn:kms:::key/’) ssnplaintext,*

FROM databrew_pii_encrypted_data

运行结果如下图所示，密文经过UDF调用Amazon Lambda 被解密出来。

比较原PII数据和解密后的数据

我们通过运行如下SQL语句来查询SSN未加密的数据以及SSN经过解密后的数据，进行对比。

对比结果完全一样，可见我们成功的实现了在Amazon Glue DataBrew中加密后存储，而在Amazon Athena中运行在线查询解密的功能。

数据安全考虑

在本方案中，通过在Amazon Athena调用UDF访问KMS对加密的数据进行解密，但是，要达到数据的安全，必须对Amazon Athena， Amazon Lambda，Amazon KMS Key等的权限进行严格的授权，因此建议建立专门的Amazon KMS Key， Amazon Lambda以及Amazon Athena工作组。

Amazon Athena 工作组授权：建立专门的Amazon Athena工作组，将该Amazon Athena 工作组授权给合适的Amazon IAM用户或者用户组。 Amazon Athena 工作组执行角色：为Amazon Athena 工作组明确指定执行角色， 该角色可以调用创建的Amazon Lambda，并访问相应的Amazon Glue Data Catalog和S3文件。 Amazon Lambda的授权：Amazon Lambda可以考虑通过创建Resource-based policy statements，仅授权Athena服务调用该Lambda，防止用户直接调用Lambda。 Amazon KMS Key的授权：Amazon KMS Key Policy只授权给Amazon Glue DataBrew运行Job的角色，以及Amazon Lambda的执行角色。

分析总结

数据合规是越来越值得重视的话题，为了合规，数据持有者必须高度重视访问控制。Amazon Glue DataBrew作为一个无服务器的可视化数据处理服务， 非常适合数据科学家、业务专家等对业务熟悉但对底层技术研究不深的用户快速搭建一套弹性的数据处理流水线，把更多的精力放在业务上。Amazon Glue DataBrew 引入了 PII 数据处理转换，使用户能够对敏感应用数据进行屏蔽、加密、解密和其他操作，进一步增强了安全性。对于Amazon Glue DataBrew中的两种加密方法的比较如下表所示，无论是哪种加密方式，相对于原始的明文，明显需要更大的存储空间。

|

比较点 |

确定性加密

Deterministic Encryption

|

不确定性概率加密

Probabilistic Encryption

|

加密Key |以Base64方式存储于Amazon Secrets Manager 中的256位密钥。

|存储于Amazon KMS中的对称密钥。

|

加密方式 |访问Amazon Secrets Manager获得密钥，调用 Amazon Web Service libcrypto加密库进行加密。

|通过Amazon KMS Key对密钥进行加密，完成最终数据的标准信封加密。

|

解密方式 |只能在Amazon Glue DataBrew中进行相应的解密。

|可以在Amazon Glue DataBrew中进行解密，也可以在外部的其他服务中调用SDK进行解密。 例如Amazon Athena中通过UDF调用Amazon Lambda进行解密。

|

安全性 |通过指定密钥和给定算法进行加减密，安全性较低。

|Key不离开Amazon KMS服务，采用信封加密，安全性显著更高。

|

密钥轮转 |如果要对Amazon Secrets Manager中的密钥进行轮转，需要注意如下的几个问题：

1. 密钥的轮转需要保证轮转后的Base64编码满足256位密钥要求。

2. 加密后的密文不包含Secret值的版本信息， 版本关联信息仅存储在DataBrew RECIPE转换脚本中。

3. 当原加密密钥在轮转后不再是AWSCURRENT版本时，必须在解密操作中显式指定正确的密钥版本进行解密。

4. 轮转后的旧密钥如未添加自定义标签(Label)将被系统自动回收， 为确保数据可持续解密，必须为需要保留的旧版本密钥添加自定义标签。

|

密文中会存放Key的版本信息，因而

1. Amazon KMS本身Key的轮转，不会影响解密。

|

密文确定性 |使用固定参数的加密算法， 相同明文的加密结果相同。

|使用随机初始化向量(IV)， 相同明文对应的密文每次不同。

|

密文长度 |密文较长。

|密文非常长，原因是用了标准的信封加密。

|

加密后分析 |虽然对明文进行了加密，但是仍然可以进行数据量的聚合统计计算等。

|虽然加密在一定条件下可以解密，但是加密后的文本无法直接进行聚合统计。

|

适用场景 |适用于一般的对个人数据等敏感数据的加密，既可以保护个人数据，又不影响整体分析。例如欧盟GDPR (General Data Protection Regulation)。

|适用于针对国家安全的敏感信息(包括个人信息)处理，例如E.O.14117，防止接收方通过数据统计分析进一步获得信息。

本文中，我们通过对Amazon Glue DataBrew中对敏感数据的相关加密功能做了介绍，并通过在Athena 中调用UDF对Amazon Glue DataBrew中加密的字段进行在线解密，保证了数据安全的同时，提升了数据使用的便捷性。通过Amazon Athena 和Amazon Lambda的最小授权，可以控制用户对UDF/ Amazon Lambda的调用，进而控制用户解密的权限。该方法不但可以部署在亚马逊云科技的中国区，还可以部署在全球区域。

除了本文中所示例的加密和解密方法，对于数据湖中的加密数据，还可以结合其他的安全进行权限管控，例如：

• 如果在本组织内使用数据，可以将数据存储到KMS加密的S3中提高安全性，同时在通过Amazon Glue DataBrew进行数据准备时，在创建加密字段的同时，还可以保留明文字段，并结合Amazon Lake Formation更加精细的权限控制，来控制数据的访问。
• 在数据需要显式传输的情况下，对于密文数据来说，可以在加密数据发送给数据接收方后，通过控制KMS的跨账号访问权限，来控制对方是否可以获得明文解密数据。

参考文档

Introducing PII data identification and handling using AWS Glue DataBrew

https://aws.amazon.com/blogs/big-data/introducing-pii-data-identification-and-handling-using-aws-glue-databrew/

Build a data pipeline to automatically discover and mask PII data with AWS Glue DataBrew

https://aws.amazon.com/blogs/big-data/build-a-data-pipeline-to-automatically-discover-and-mask-pii-data-with-aws-glue-databrew/

Identifying and remediating PII data in AWS Glue

https://www.[已去除社交账号]/pulse/identifying-remediating-pii-data-aws-glue-tom-reid

PII Recipe Steps

https://docs.aws.amazon.com/databrew/latest/dg/recipe-actions.ENCRYPT.html

What is the AWS Encryption SDK?

https://docs.aws.amazon.com/encryption-sdk/latest/developer-guide/introduction.html

使用 Amazon Glue DataBrew 对数据进行预处理

https://aws.amazon.com/cn/blogs/china/preprocess-the-data-with-amazon-glue-databrew/

Use IAM policies to control workgroup access

https://docs.aws.amazon.com/athena/latest/ug/workgroups-iam-policy.html

Allow access to Athena UDFs: Example policies

https://docs.aws.amazon.com/athena/latest/ug/udf-iam-access.html

Viewing resource-based IAM policies in Lambda

https://docs.aws.amazon.com/lambda/latest/dg/access-control-resource-based.html

---

浏览本文需要约10分钟，建议按照章节分段阅读。

在AI加速企业应用的时代，面对快速增长的数据，企业通常会构建高效、可扩展、低成本的分布式存储系统。既要保障数据的安全性与完整性，还要实现便捷的管理和灵活的访问，快速将海量数据高效输送到GPU等计算资源，支持AI训练与推理任务。

以下是在开源社区中，几个开源分布式文件系统常见的比较，包括GitHub星标情况及主要特点：

|产品名称

|GitHub Star 规模（2025年8月）

|主要特点简述

|JuiceFS

|约12k

|云原生设计，依赖对象存储，支持高性能、弹性扩展，适合云环境和大规模AI训练。官方文档及对比文章丰富

|Alluxio

|约7k

|主要用作分布式存储缓存层，支持多数据源聚合。非持久存储，适合作为加速层

|Ceph

|约15.3k

|企业级成熟系统，支持快照和细颗粒权限，适合私有云和IDC环境。配置和运维相对复杂

|GlusterFS

|约5k

|传统分布式文件系统，无中心元数据，简单部署，性能和扩展性相对有限

|SeaweedFS

|约25.3k

|高性能分布式存储，元数据操作较弱，但轻量且自包含。适合大对象存储

当前，大多数企业选择在多云环境的 Kubernetes 上运行AI应用通过 CSI Driver 实现与持久化存储的无缝集成，使用标准 POSIX 协议访问文件数据，能够支持大多数应用、框架和工具，例如 AI 训练平台、大数据分析以及常见数据处理程序等。在综合对比社区主流分布式存储项目以及客户在技术社区中的实践，JuiceFS 是当前符合上述需求的优选方案。本文将探讨在亚马逊云科技上构建 JuiceFS 的具体实践。

1. 构建方向

在选定 JuiceFS 作为存储层解决方案后，整体存储架构演变为下图的三种形态：

本文将从实际使用方式的三个环节进行详细说明，并首次对 JuiceFS CSI Driver on EKS部分进行系统性描述。

|使用方式

|使用场景

|业务特点

|技术优势

|HostPath

|直接处理百万级的训练数据并保持读取稳定，适配 AI/ML 训练、科学计算等高 I/O 场景

|模型训练需处理超大规模数据集，且源数据大多分布在各类对象存储。当所有训练计算资源集中配置时，通常选择直接在物理机或容器上（HostPath）通过 FUSE 将 JuiceFS 卷挂载到本地目录

|可以透明整合不同云存储来源的训练数据形成统一本地访问空间，无需人工拷贝或脚本同步，实现大规模并发高效、稳定的数据读取

|CSI Driver

|完成自动化部署、卷自动扩缩容、数据隔离等企业级生产需求，提升站点运维和弹性能力

|k8s 上运行的大数据、微服务集群需要持久化共享存储，且多个 Pod/租户并行读写同一数据集

|CSI Driver 管理的挂载点能够实现精细化资源调度与并发控制，避免资源冲突。例如，通过 pod 级访问控制和调度优化，有效解决早期的死锁、并发读写冲突等问题

|S3 Gateway

|企业内部构建自有文件共享服务，实现复杂的权限和时效性管理

|

无需单独开发权限体系，直接用 S3 标准工具（awscli、minio client 等）和 SDK 进行安全数据共享。

也可用于 Web 管理界面的跨平台文件操作和多云同步

|S3 Gateway 提供角色与精细权限（基于 IAM/ACL）管理机制，可通过 Security Token 实现共享链接的时效管控，有效防止数据被滥用或恶意抓取

2. 环境准备

2.1 准备对象存储

Amazon S3 是公有云对象存储服务的事实标准，其他主流云平台提供的对象存储服务通常也兼容 S3 API，这使得为 S3 开发的程序可以自由地在其他平台的对象存储服务之间切换。JuiceFS 完全支持 Amazon S3 以及所有类似 S3 的对象存储服务，所有支持的存储类型请参见 JuiceFS 的官方文档。

2.2 准备数据库

JuiceFS 主要支持三种类型的元数据引擎。

第一种是 Redis，它是 JuiceFS 自首次发布以来就支持的元数据引擎。JuiceFS 也支持兼容 Redis 协议的数据库，例如 KeyDB 和 Amazon MemoryDB。但是Redis 的可靠性和可扩展性有限，在数据安全性要求高或规模较大的场景下性能不佳。

第二种是类 SQL 引擎，例如 MySQL、MariaDB 和 PostgreSQL，通常具有良好的可靠性和可扩展性，JuiceFS 还支持嵌入式数据库 SQLite。

第三种是 TKV（事务性键值数据库），它拥有更简单的原生接口，在 JuiceFS 中可定制性更强，并且通常比 SQL 数据库性能更高。目前JuiceFS 支持 TiKV、etcd 和 BadgerDB（也是嵌入式数据库），FoundationDB 的支持也在开发中。

以上是基于数据库协议的分类，每个类别中又包含各种数据库，每个数据库都有各自的特点，下表是官方文档根据这些特点对常用数据库的比较。

|

|Redis

|MySQL/PostgreSQL

|TiKV

|etcd

|SQLite/BadgerDB

|性能

|高

|低

|中

|低

|中

|扩展性

|低

|中

|高

|低

|低

|可靠性

|低

|高

|高

|高

|中

|可用性

|中

|高

|高

|高

|低

|流行度

|高

|高

|中

|高

|中

云平台通常都提供种类丰富的云数据库提供，比如 Amazon RDS 提供各类关系型数据库的版本，Amazon ElastiCache 提供兼容 Redis 的内存型数据库产品，经过简单的初始化设置就可以创建出多副本、高可用的数据库集群。

目前Redis 单机架构和Redis Cluster 都无法提供强一致性的保证，这个话题本文不再赘述，读者可以参考JuiceFS的官方说明。

生产环境下，建议使用Amazon MemoryDB for Redis服务，这是一个兼容 Redis 协议的全托管存储服务，它具有微秒级的读取性能以及毫秒级的写入性能，并提供强一致性保证，这是通过将写操作持久化到一个分布式事务日志系统来实现的，以确保成功写入的数据不会丢失。Amazon ElastiCache for Valkey也是兼容 Redis 协议的全托管服务，主要作为内存缓存使用，提供极低的读写延迟，支持自动扩展和多可用区高可用，但它不提供强一致性保证，写入持久化机制和容错设计与 MemoryDB 不同，适合对一致性要求较低的缓存场景。

本文以在客户环境中经常使用的Redis为例，使用Amazon ElastiCache for Valkey和Amazon s3进行介绍。

Valkey是一个开源的高性能键值数据存储系统，由Linux基金会管理（由40多家大型全球企业来支持）。Valkey是Redis OSS闭源后的直接替代品，同样由Redis OSS的社区开发者开发和维护，自2024年3月项目启动以来，Valkey已经在业界被广泛使用。

Valkey配置过程请参考官方文档，其中分片个数，访问控制方式及需要注意的参数，请参考下边的表格：

|参数

|推荐值

|说明

|Number of shards

|1~3

|小规模测试选择1即可，或最多3分片模拟多分片场景

|Replicas per shard

|0 或 1

|

0副本模拟单节点部署，1副本模拟简易高可用测试

副本数设置为 0 时，无法启用多可用区。需选择一个或多个副本来启用多可用区。

|访问控制方式

|认证强度

|适用场景

|推荐程度

|No Access Control

|无认证

|测试/内部隔离环境

|不推荐

|Auth Default User Access

|

基础认证

Auth Default User Access

|小规模、权限简单的应用

|可用，非最佳

|User Group Access List (RBAC)

|多用户多权限

|多租户、复杂权限、高安全需求场景

|推荐，最佳实践

|参数名

|调整方式

|注意事项

|appendonly

|不能启用（保持 no）

|ElastiCache 不支持开启 AOF，使用多 AZ 多副本替代

|maxmemory-policy

|设置为 noeviction

|可通过参数组选项修改，保证元数据不会被驱逐

2.3 准备IAM策略

创建 IAM 策略juicefs-policy，包含访问 S3 以及对 Redis 访问所需权限

{

“Version”: “2012-10-17”,

“Statement”: [

{

“Sid”: “AllowS3Access”,

“Effect”: “Allow”,

“Action”: [

“s3:ListBucket”,

“s3:PutObject”,

“s3:GetObject”,

“s3:DeleteObject”,

“s3:ListMultipartUploadParts”,

“s3:AbortMultipartUpload”

],

“Resource”: [

“arn:aws:s3:::juicefs-demo-eks”,

“arn:aws:s3:::juicefs-demo-eks/*”

]

},

{

“Sid”: “AllowValkeyAccess”,

“Effect”: “Allow”,

“Action”: [

“elasticache:Describe*”,

“elasticache:ListTagsForResource”

],

“Resource”: “*”

}

]

}

2.4 部署环境

|节点名称

|操作系统

|配置

|内网IP

|可用区

|Kubectl Console

|Amazon Linux 2023

|t3.medium 2C/4G/50G

|10.28.6.94

|ap-northeast-2a

|EKS

|1.30

|node01

|Amazon Linux 2

|g5.xlarge 4C/16G/250G

|10.28.6.83

|ap-northeast-2a

|node02

|Amazon Linux 2

|g5.xlarge 4C/16G/250G

|10.28.6.176

|ap-northeast-2b

|对象存储

|Amazon S3

|juicefs-demo-eks

|元数据引擎

|Valkey caches 8.1.0

|cache.r5.large 2C/13G

|JuiceFS version

|1.3.0+2025-07-03.30190ca

|juicefs-csi-driver version

|v0.26.4

2.5 性能评估

以上的部署环境，是构建在一个通用场景下，适合中等规模、多样化计算需求、对存储性能和系统可靠性有较高要求的云原生应用。在准备交付生产之前，需要评估下使用场景，对部署的资源进行调整，包括：

• 对接的应用是什么？比如 Apache Spark、PyTorch 或者是自己写的程序等
• 应用运行的资源配置，包括 CPU、内存、网络，以及节点规模
• 预计的数据规模，包括文件数量和容量
• 文件的大小和访问模式（大文件或者小文件，顺序读写或者随机读写）
• 对性能的要求，比如每秒要写入或者读取的数据量、访问的 QPS 或者操作的延迟等

3. 构建过程

3.1 安装客户端

在所有需要挂载文件系统的计算机上安装 JuiceFS 客户端，一键安装脚本适用于 Linux 系统，会根据EC2架构自动下载安装最新版 JuiceFS 客户端。

开源版JuiceFS on Amazon EKS 上的实践

sudo curl -sSL https://d.juicefs.com/install | sh –

确认安装的版本

[ec2-user@ip-172-31-27-182 bin]$ juicefs -V

juicefs version 1.3.0+2025-07-03.30190ca

3.2 创建文件系统

[ssm-user@ip-172-31-66-201 ~]$ juicefs format –storage s3 –bucket https://s3.ap-northeast-2.amazonaws.com/juicefs-demo-eks rediss://default:[已去除邮箱]:6379/1 juicefs-apn2

3.3 挂载文件系统

在一台EKS node上挂载文件系统

[ssm-user@ip-172-31-66-201 ~]$ sudo /usr/local/bin/juicefs mount -d rediss://default:[已去除邮箱]:6379/1 /mnt/juicefs

2025/08/04 09:43:25.707487 juicefs[604981] : Meta address: rediss://default:****@clustercfg.juicefs-valkey.kjmaj8.apn2.cache.amazonaws.com:6379/1 [[已去除邮箱]:578]

2025/08/04 09:43:25.724902 juicefs[604981] : redis clustercfg.juicefs-valkey.kjmaj8.apn2.cache.amazonaws.com:6379 is in cluster mode [[已去除邮箱]:214]

2025/08/04 09:43:25.737225 juicefs[604981] : AOF is not enabled, you may lose data if Redis is not shutdown properly. [[已去除邮箱]:84]

2025/08/04 09:43:25.737951 juicefs[604981] : Ping redis latency: 619.556µs [[已去除邮箱]:3692]

2025/08/04 09:43:25.739458 juicefs[604981] : Data use s3://juicefs-demo-eks/juicefs-apn2/ [[已去除邮箱]:588]

2025/08/04 09:43:26.241453 juicefs[604981] : OK, juicefs-apn2 is ready at /mnt/juicefs [checkMountpoint@mount_unix.go:235]

自动挂载

将 juicefs 客户端重命名为 mount.juicefs 并复制到 /sbin/ 目录

[root@ip-172-31-65-22 ~]# cp /usr/local/bin/juicefs /sbin/mount.juicefs

编辑/etc/fstab配置文件，添加下边的新记录

rediss://default:[已去除邮箱]:6379/1 /mnt/juicefs juicefs _netdev,cache-size=20480 0 0

3.4 验证文件系统

3.5 查看源数据

Valkey 完全兼容 Redis 7.2+ 的命令，使用标准的 redis-cli 工具来连接和查询数据。在EC2实例上安装valkey-cli的具体步骤如下，适用于Amazon Linux或类似的Linux发行版：连接到EC2实例，确保已具备sudo权限。

安装必需的依赖工具

sudo yum install -y gcc jemalloc-devel openssl-devel tcl tcl-devel make

下载valkey-cli的源码包（以最新版本为例，这里用的是8.1.3版本）：

wget https://github.com/valkey-io/valkey/archive/refs/tags/8.1.3.tar.gz

解压源码包：

tar xvzf 8.1.3.tar.gz

cd valkey-8.1.3/

编译valkey-cli：

如果是第一次编译，建议先执行清理：

make distclean

然后带TLS支持编译valkey-cli：

make valkey-cli BUILD_TLS=yes

编译成功后，执行安装

sudo make install

安装完成后，可以用以下命令验证valkey-cli是否可用：

valkey-cli –version

连接到Valkey查看键值

[ssm-user@ip-172-31-27-182 ec2-user]$ valkey-cli –tls -h clustercfg.juicefs-valkey.kjmaj8.apn2.cache.amazonaws.com -p 6379 -a juicefspasswordabc

Warning: Using a password with ‘-a’ or ‘-u’ option on the command line interface may not be safe.

clustercfg.juicefs-valkey.kjmaj8.apn2.cache.amazonaws.com:6379> KEYS *

4. 三种使用方式的实践

4.1 HostPath

在Amazon EKS集群中使用JuiceFS，常见的方式是通过FUSE接口进行文件系统挂载。FUSE客户端需要运行在宿主机节点上，通常以DaemonSet形式部署，负责将后端对象存储挂载为节点上的本地目录。当Pod访问该文件系统时，通常采用HostPath卷方式，将宿主机上的FUSE挂载目录直接映射至容器内。

4.1.1 添加IAM策略

找到现有NodeInstanceRole，关联“准备IAM策略”中的juicefs-policy

4.1.2 Pod 配置示例（直接访问挂载目录）

假设节点上 JuiceFS 已挂载路径为 /mnt/juicefs/，直接使用 ls 查看该目录

apiVersion: v1

kind: Pod

metadata:

name: juicefs-hostpath

spec:

containers:

• name: juicefs-app

image: busybox

command: [“/bin/sh”, “-c”, “ls /mnt/juicefs && sleep 3600”] # 列出挂载目录内容后休眠，方便调试查看

volumeMounts:

• name: juicefs-volume

mountPath: /mnt/juicefs

volumes:

• name: juicefs-volume

hostPath:

path: /mnt/juicefs/ # JuiceFS 在节点上的挂载目录

type: Directory

kubectl get nodes # 确认节点状态

kubectl apply -f juicefs-hostpath.yaml # 创建pod

kubectl get pod juicefs-hostpath-example # 检查 Pod 状态

[ec2-user@ip-172-31-27-182 ~]$ kubectl get pod

NAME READY STATUS RESTARTS AGE

backend-655f66b77-94jds 1/1 Running 0 238d

frontend-64db969c4c-wfstf 1/1 Running 0 238d

juicefs-hostpathe 1/1 Running 0 20s

php-apache-77b9d477b8-9t7qn 1/1 Running 0 236d

kubectl exec -it juicefs-hostpath-example — sh # 进入容器验证

ls -l /mnt/juicefs

[ec2-user@ip-172-31-27-182 ~]$ kubectl exec -it juicefs-hostpath — sh

/ # ls -l /mnt/juicefs

total 0

-rw-rw-r– [已去除电话] 0 Aug 4 14:58 test.txt

4.1.3 并发的考虑

对于多客户端同时挂载读写同一个文件系统的情况，JuiceFS 提供关闭再打开（close-to-open）一致性保证，即当两个及以上客户端同时读写相同的文件时，客户端 A 的修改在客户端 B 不一定能立即看到。但是，一旦这个文件在客户端 A 写入完成并关闭，之后在任何一个客户端重新打开该文件都可以保证能访问到最新写入的数据，不论是否在同一个节点。

4.2 CSI Driver

除了上述传统的hostPath方式，在Kubernetes下标准化的做法是使用JuiceFS的CSI驱动，在Amazon EKS中实现对JuiceFS存储的动态管理和挂载。 JuiceFS CSI Driver将底层复杂的 FUSE 管理抽象成 Kubernetes 原生资源（PVC、PV、StorageClass），它部署在集群中，包括控制器Pod和节点守护进程（DaemonSet），对外提供Kubernetes标准的PersistentVolume（PV）和PersistentVolumeClaim（PVC）接口。

JuiceFS CSI Driver 有两种主要的存储卷配置方式，本文讨论的是动态配置：

|方式

|说明

|适用场景

|优缺点

|动态配置（Dynamic Provisioning）

|用户只需创建 StorageClass 和 PersistentVolumeClaim (PVC)，Kubernetes 会根据 StorageClass 自动创建和绑定 PersistentVolume (PV)，CSI Driver 会在 JuiceFS 文件系统中为每个 PVC 自动创建子目录进行隔离

|多应用共享同一个 JuiceFS 文件系统时，且希望数据隔离，简化管理员管理时；大多数生产场景使用。

|自动化程度高，支持数据隔离和多租户，减少了管理员手动维护PV的工作量。

|静态配置（Static Provisioning）

|系统管理员预先创建好 PV 并绑定指定 JuiceFS 根目录或子目录，用户通过 PVC 绑定已有 PV

|已有大量 JuiceFS 数据；或简单快速验证 CSI 驱动时使用。

|简单直接，适合单租户或测试环境，但缺乏自动资源编排和隔离能力。

4.2.1 添加IAM策略

建议使用 IAM Roles for Service Accounts (IRSA) 方式，安全且符合云原生最佳实践，JuiceFS CSI Controller Pod 在相应的命名空间使用的服务账户就自动拥有了访问 AWS 资源的权限。

4.2.2 安装配置过程

• 配置过程如下所示：

|步骤

|目的

|创建ServiceAccount

|JuiceFS Driver Pod 能够安全地调用这些 API

|安装 JuiceFS CSI Driver

|用动态方式（Dynamic Provisioning）部署 JuiceFS CSI Driver

|创建Kubernetes Secret

|存储访问JuiceFS的配置信息

|创建 StorageClass

|提供一个简单申领持久化存储（PVC）的标准方式

|创建 PVC 并绑定 StorageClass

|为应用程序动态的申领和获取持久化存储资源

|创建测试Pod

|测试是否可以正常访问juicefs

• EKS 集群已开启 OIDC 提供商（OIDC provider），可使用命令查看
• 创建ServiceAccount

附加“环境准备”章节的安全策略juicefs-policy（替换YOUR_POLICY_ARN）

eksctl create iamserviceaccount \

–name juicefs-csi-controller-sa \

–namespace kube-system \

–cluster three-tier-cluster \

–attach-policy-arn arn:aws:iam::[已去除电话]:policy/juicefs-policy \

–override-existing-serviceaccounts \

–approve

检查已附加的策略

aws iam list-attached-role-policies –role-name JuiceFS-CSI-Driver-Role

• 安装 Helm（如果未安装）

curl https://raw.githubuserconten[已去除短链接]m/helm/helm/main/scripts/get-helm-3 | bash

• 添加 JuiceFS Helm 仓库

helm repo add juicefs https://charts.juicefs.com

helm repo update

• 创建 JuiceFS CSI Driver 配置文件 values.yaml，用动态方式（Dynamic Provisioning）部署 JuiceFS CSI Driver，这段 values.yaml 的基础配置示例如下，可以根据使用场景做调整和补充：

kubeletDir: “/var/lib/kubelet”

mountMode: “process” # 这里为 process 模式

image:

repository: “juicedata/juicefs-csi-driver”

tag: “v0.26.4”

webhook:

certManager:

enabled: false

provisioner:

enabled: true # 开启动态 Provisioner, 支持自动创建 PV 和挂载 JuiceFS 子目录

controller:

resources:

limits:

cpu: 1000m

memory: 512Mi

requests:

cpu: 200m

memory: 256Mi

node:

resources:

limits:

cpu: 500m

memory: 256Mi

requests:

cpu: 100m

memory: 128Mi

• 生成这个 values.yaml 文件后，用 Helm 安装，安装 JuiceFS CSI Driver

helm upgrade –install juicefs-csi-driver juicefs/juicefs-csi-driver -n kube-system -f values.yaml

• 创建Kubernetes Secret，因为已经配置了IRSA ，此处access-key 和secret-key留空

apiVersion: v1

kind: Secret

metadata:

name: juicefs-secret

namespace: kube-system

type: Opaque

stringData:

name: juicefs-apn2 #之前创建的juicefs

metaurl: “rediss://default:[已去除邮箱]:6379/1”

storage: s3

bucket: “https://s3.ap-northeast-2.amazonaws.com/juicefs-demo-eks”

access-key: “”

secret-key: “”

• 创建StorageClass并引用Kubernetes Secret

apiVersion: storage.k8s.io/v1

kind: StorageClass

metadata:

name: juicefs-csi

provisioner: csi.juicefs.com

parameters:

引用 Secret

csi.storage.k8s.io/provisioner-secret-name: juicefs-secret

csi.storage.k8s.io/provisioner-secret-namespace: kube-system

csi.storage.k8s.io/node-publish-secret-name: juicefs-secret

csi.storage.k8s.io/node-publish-secret-namespace: kube-system

reclaimPolicy: Delete

volumeBindingMode: Immediate

• 创建 PVC 并绑定 StorageClass

apiVersion: v1

kind: PersistentVolumeClaim

metadata:

name: juicefs-pvc

spec:

accessModes:

• ReadWriteMany

resources:

requests:

storage: 10Gi

storageClassName: juicefs-csi

• 创建测试Pod

apiVersion: v1

kind: Pod

metadata:

name: juicefs-test

spec:

containers:

• name: app

image: alpine:latest # 轻量级测试镜像

command: [“sh”, “-c”, “echo ‘JuiceFS Test’ > /data/juicefs.txt && sleep 3600”]

volumeMounts:

• name: juicefs-pvc

mountPath: /data # 挂载路径

volumes:

• name: juicefs-pvc

persistentVolumeClaim:

claimName: juicefs-pvc # 必须与当前的PVC名称一致

4.2.3 验证过程

查看 CSI Driver Pod 运行状态：

kubectl get pods -n kube-system -l app=juicefs-csi-driver

创建 Pod 并进入容器，测试读写挂载目录：

kubectl exec -it juicefs-app — sh

touch /data/testfile

ls -l /data/testfile

4.2.4 CSI Driver和HostPath的特性比较

|特性

|CSI Driver

|手动 FUSE (DaemonSet)

|集成度

|原生 Kubernetes 方式，自动化

|需手动或脚本管理

|生命周期

|自动挂载/卸载、清理

|手动管理，易泄露

|配置方式

|动态配置 StorageClass

|静态配置 (手动PV)

|隔离性

|强，使用独立 Mount Pod

|弱，通常共享挂载点

|安全性

|高，IAM Role for Service Account on Pod

|低，通常需特权模式

|多版本/配置

|支持，不同StorageClass不同配置

|困难，节点共享配置

|可观测性

|高，标准 Pod 日志监控

|低，需登录节点排查

4.2.5 模型训练的场景

请参考代码示例，在EKS环境下，使用Juice CSI Driver，通过PyTorch构建端到端的自动驾驶神经网络。该网络由CNN特征提取器和全连接控制预测器组成，能够直接从图像输入预测车辆的转向、油门和刹车控制信号。训练完成后，会保存模型权重文件、训练历史记录和损失曲线图。

4.3 S3 Gateway

JuiceFS S3 Gateway 基于 MinIO Gateway 开发，实现了S3 API，允许用户通过任何兼容 S3 的客户端访问和管理 JuiceFS 文件系统中的数据。它能够将 JuiceFS 文件系统以 S3 协议的形式对外提供服务，使用户能够构建独立的文件服务，用于安全地共享内部文件。

面对复杂的权限与时效性管理需求，该方案不仅满足基本共享要求，还通过 Security Token 机制实现了对共享链接时效性的精细控制。这一机制有效防止了数据被恶意抓取的风险，进一步增强了文件共享的安全性。

4.3.1 创建和执行Dockerfile

1.创建Dockerfile，当前官方版本镜像不能正常使用，需要新建Docker镜像

FROM ubuntu:22.04

设置JuiceFS版本

ARG JUICEFS_VERSION=1.3.0

安装依赖

RUN apt-get update && apt-get install -y \

ca-certificates \

curl \

fuse3 \

&& rm -rf /var/lib/apt/lists/*

下载并安装JuiceFS

RUN set -eux; \

ARCH=$(uname -m); \

case “${ARCH}” in \

x86_64) ARCH=amd64 ;; \

aarch64) ARCH=arm64 ;; \

*) echo “unsupported architecture: ${ARCH}”; exit 1 ;; \

esac; \

curl -fSL “https://github.com/juicedata/juicefs/releases/download/v${JUICEFS_VERSION}/juicefs-${JUICEFS_VERSION}-linux-${ARCH}.tar.gz” -o juicefs.tar.gz; \

tar -xzf juicefs.tar.gz; \

install juicefs /usr/local/bin/juicefs; \

rm juicefs.tar.gz juicefs; \

juicefs version

创建用户和目录

RUN groupadd -r juicefs && useradd -r -g juicefs juicefs

RUN mkdir -p /var/juicefs && chown juicefs:juicefs /var/juicefs

WORKDIR /var/juicefs

USER juicefs

EXPOSE 9000

设置入口点，支持自定义参数

ENTRYPOINT [“juicefs”]

CMD [“gateway”, “–help”]

2.构建Docker镜像

!/bin/bash

JuiceFS Gateway镜像构建脚本

set -e

配置变量

IMAGE_NAME=”juicefs-gateway”

TAG=”latest”

JUICEFS_VERSION=”1.3.0″

echo “开始构建JuiceFS Gateway镜像…”

echo “JuiceFS版本: v$JUICEFS_VERSION”

构建镜像

docker build \

–build-arg JUICEFS_VERSION=$JUICEFS_VERSION \

-t $IMAGE_NAME:$TAG .

echo “镜像构建完成: $IMAGE_NAME:$TAG”

测试镜像基本功能

echo “测试镜像功能…”

docker run –rm $IMAGE_NAME:$TAG version

docker run –rm $IMAGE_NAME:$TAG gateway –help | head -5

echo “构建和测试完成！”

3.上传镜像到AWS ECR

set -e

配置变量

IMAGE_NAME=”juicefs-gateway”

TAG=”latest”

AWS_ACCOUNT_ID=”[已去除电话]” # 替换AWS账户ID

AWS_REGION=”ap-northeast-2″ # 根据EKS区域调整

ECR_REPO_NAME=”juicefs-gateway”

echo “登录到AWS ECR…”

获取ECR登录密码并登录

aws ecr get-login-password –region $AWS_REGION | docker login –username AWS –password-stdin $AWS_ACCOUNT_ID.dkr.ecr.$AWS_REGION.amazonaws.com

echo “检查ECR仓库…”

检查仓库是否存在，如果不存在则创建

if ! aws ecr describe-repositories –repository-names $ECR_REPO_NAME –region $AWS_REGION > /dev/null 2>&1; then

echo “创建ECR仓库: $ECR_REPO_NAME”

aws ecr create-repository \

–repository-name $ECR_REPO_NAME \

–region $AWS_REGION \

–image-scanning-configuration scanOnPush=true \

–image-tag-mutability MUTABLE

fi

echo “标记镜像…”

标记镜像用于ECR

docker tag $IMAGE_NAME:$TAG $AWS_ACCOUNT_ID.dkr.ecr.$AWS_REGION.amazonaws.com/$ECR_REPO_NAME:$TAG

echo “推送镜像到ECR…”

推送镜像到ECR

docker push $AWS_ACCOUNT_ID.dkr.ecr.$AWS_REGION.amazonaws.com/$ECR_REPO_NAME:$TAG

echo “镜像推送完成!”

echo “ECR镜像地址: $AWS_ACCOUNT_ID.dkr.ecr.$AWS_REGION.amazonaws.com/$ECR_REPO_NAME:$TAG”

显示仓库信息

echo “ECR仓库信息:”

aws ecr describe-repositories –repository-names $ECR_REPO_NAME –region $AWS_REGION –query ‘repositories[0].repositoryUri’ –output text

4.3.2 在AWS EKS上部署 JuiceFS Gateway 并通过 Ingress 方式暴露给内部团队

• 部署过程如下表所示：

|步骤

|目的

|安装 AWS Load Balancer Controller

|EKS支持ALB Ingress

|创建 Deployment

|定义并部署应用程序 Pod（JuiceFS 相关组件或应用）

|创建 Service

|暴露Pod 端口给ALB

|创建 IngressClass

|关联AWS ALB Controller

|创建 Ingress

|配置路由规则给Service

|获取ALB地址并访问

|内部客户访问服务

• 具体步骤如下：

确保 EKS 集群已经部署了 Ingress Controller，这里推荐使用AWS ALB Ingress Controller，具体步骤参考ALB Ingress Controller 官方文档。

定义并部署应用程序 Pod，指定镜像的ECR地址，ElastiCache for Valkey 的配置端点，s3 gateway的根用户名和访问密钥。

apiVersion: apps/v1

kind: Deployment

metadata:

name: juicefs-s3-gateway

namespace: kube-system

spec:

replicas: 1

selector:

matchLabels:

app: juicefs-s3-gateway

template:

metadata:

labels:

app: juicefs-s3-gateway

spec:

containers:

• name: juicefs-s3-gateway

image: [已去除电话].dkr.ecr.ap-northeast-2.amazonaws.com/juicefs-gateway:latest # 指定ECR的地址

env:

• name: MINIO_ROOT_USER

value: “admin”

• name: MINIO_ROOT_PASSWORD

value: “password”

command: [“juicefs”]

args:

• “gateway”
• “rediss://default:[已去除邮箱]:6379/1” # 指定valkey访问链接的用户名和口令
• “0.0.0.0:9000”

ports:

• containerPort: 9000
• 创建 Service（ClusterIP 或 NodePort）

为了让 Ingress 能访问 Pod，需要先创建一个对应的 Service，暴露 JuiceFS Gateway 的 9000 端口。示例 Service YAML如下：

apiVersion: v1

kind: Service

metadata:

name: juicefs-s3-gateway

namespace: kube-system

spec:

selector:

app: juicefs-s3-gateway

ports:

• port: 9000

targetPort: 9000

protocol: TCP

type: NodePort # ALB 需要用 NodePort 或 LoadBalancer 类型

• 创建 IngressClass 资源，绑定 ALB

apiVersion: networking.k8s.io/v1

kind: IngressClass

metadata:

name: alb

annotations:

ingressclass.kubernetes.io/is-default-class: “true” # 设置默认 ingressclass（非必需）

spec:

controller: eks.amazonaws.com/alb

parameters:

apiGroup: eks.amazonaws.com

kind: IngressClassParams

• 创建 Ingress 资源，将流量路由到 Service

apiVersion: networking.k8s.io/v1

kind: Ingress

metadata:

name: juicefs-s3-gateway-ingress

namespace: kube-system

annotations:

kubernetes.io/ingress.class: alb

spec:

rules:

• http:

paths:

• path: /*

pathType: ImplementationSpecific

backend:

service:

name: juicefs-s3-gateway

port:

number: 9000

等待几分钟后，通过以下命令查看 ALB 地址（DNS 名称）

kubectl get ingress -n kube-system juicefs-s3-gateway-ingress -o jsonpath='{.status.loadBalancer.ingress[0].hostname}’

内部客户可以直接使用这个 ALB 地址访问 JuiceFS Gateway

请参考Juicefs官方文档身份和访问控制

5. 总结

本文主要讲述了在AWS EKS环境下构建JuiceFS的三种不同的使用方式：HostPath，CSI Driver和S3 Gateway，并首次对 JuiceFS CSI Driver on EKS部分进行了系统性描述。在生产环境下可以结合自身的需求选择适合的JuiceFS架构，满足海量数据下的高效AI训练与推理需求。

AWS FSx for Lustre是亚马逊云科技提供的一项全托管的高性能并行文件存储服务。它的核心设计目标是为运行在 AWS 上的计算密集型工作负载提供极致的吞吐量，和满足低延迟高性能的需求。AWS FSx for Lustre 与 Intelligent Tiering 的结合，更是显著降低长期存储成本。在实际架构选型中，选择开源版 JuiceFS还是选择 AWS FSx for Lustre或AWS FSx for Lustre + Intelligent Tiering，可以参考下表：

|对比维度

|开源版 JuiceFS

|AWS FSx for Lustre

|FSx for Lustre + Intelligent Tiering

|部署纬度

|支持跨云、混合云部署

|仅限 AWS 区域内使用

|仅限 AWS 区域内使用

|部署方式

|需要依赖外部元数据引擎（Redis/MySQL等）

|不依赖外部元数据引擎，与EKS集群独立存在

|不依赖外部元数据引擎，自动化分层管理

|成本效益

|利用低成本对象存储，缓存加速，性价比高

|全托管服务，费用略高

|智能分层大幅降低存储成本，热数据高性能访问

|存储协议支持

|支持POSIX、S3 Gateway、HDFS 等

|支持 POSIX，与 S3 可双向同步

|支持 POSIX，自动S3分层，透明访问

|管理/运维复杂度

|需要维护文件系统与元数据库，复杂度高

|托管式服务，管理成本低

|零运维，自动化数据生命周期管理

|数据分层策略

|手动配置缓存策略，需要运维介入

|手动管理S3导入/导出

|基于访问模式自动分层，无需人工干预

|性能表现

|通过缓存实现高性能读写，适合数据密集场景

|极低延迟和高吞吐，专为 HPC 和密集型 AI 训练优化

|热数据毫秒级访问，冷数据秒级恢复，性能与成本平衡

|弹性扩展

|需要预先规划缓存容量

|支持动态扩展，但需要手动管理

|自动根据访问模式调整存储层级，无限扩展

|自动驾驶场景优势

|适合多云环境下的数据湖场景

|高性能训练数据访问，模型推理加速

|训练数据自动分层，历史数据低成本存储，实时数据高性能访问

|数据生命周期管理

|需要自行开发脚本管理

|手动设置S3同步策略

|智能识别数据访问模式，自动优化存储成本

|适用业务场景

|AI 训练、数据湖、容灾备份、低成本扩展

|高性能计算、AI训练、原生云上应用

|大规模自动驾驶数据处理、智能训练数据管理、成本敏感的AI工作负载

6. 参考资料

[1] 多云架构、 POSIX 全兼容、低运维的统一存储

[2] 性能评估指南

[3] JuiceFS 元数据引擎选型指南

[4] JuiceFS CSI Driver 架构设计详解

[5] JuiceFS CSI 驱动遵循 CSI 规范

[6] JuiceFS 与 Amazon MemoryDB 夯实企业数据基石

*前述特定亚马逊云科技生成式人工智能相关的服务目前在亚马逊云科技海外区域可用。亚马逊云科技中国区域相关云服务由西云数据和光环新网运营，具体信息以中国区域官网为准。

本篇作者

---

亚马逊AWS官方博客

AWS WAF 指南（十一）：全新WAF控制台及WAF与CloudFront联动体验

保护面向公众的 Web 应用存在诸多挑战，随着威胁格局不断演变，要求企业必须能够应对复杂威胁，包括但不限于零日（Zero-day）漏洞、自动化事件以及不断变化的合规要求。在控制台中浏览并为使用场景选择最合适的防护措施要求具备安全专业知识，还需要深入理解想保护的应用程序，这往往会很复杂。好消息是AWS WAF 推出了全新的控制台体验，旨在简化安全配置。此增强界面提供一体化安全解决方案，能在您的应用环境中实现全面防护，采用简化的一页式工作流程，可将部署时间从数小时缩短至几分钟！AWS WAF 现在提供针对特定工作负载的预配置规则包、自动安全建议，以及统一仪表板以清晰查看安全状态。新控制台还提供灵活的保护级别和集成合作伙伴解决方案，不仅仅是所短部署时间， 还可以助力企业高效扩展的安全运维及可视化。

在本文中，将介绍 AWS WAF 增强控制台体验的功能，可以选择工作负载类型，自动应用专家级推荐规则组合，从而为工作负载之间提供全面防护。对于利用WAF保护CloudFront的使用场景，介绍WAF与CloudFront 联动的全新体验。

新控制台切换方法

用户进入WAF配置页面后，可以随时点击左侧菜单栏最下方的“切换WAF新控制台”（Switch to the new WAF console）切换到新控制台界面，新控制台也可随时切换回旧版控制台。新控制台与旧版控制台在功能上具有一致性，即所有 AWS WAF 功能仍然可用，只是界面不同。用户可安心迁移使用。

将 Web 应用安全部署实施步骤减少 80%

新控制台在创建保护包（WebACL）的配置步骤集中在一页上，打造了直观的工作流程，减少多页面切换的需要，降低设置复杂性。这种方法将以往复杂耗时的流程跳转为直观高效的工作流程，同时保持强大安全标准，大幅减少实施时间和潜在配置错误。用户可以在几分钟内完成原本需数小时才能完成的配置，实施时间减少了约 80%。

新控制台提供预配置的安全默认设置和文档，帮助不同技术水平的用户有效保障应用安全。启动设置过程时，您选择应用类别和关注功能（例如保护 API 或 Web 应用），AWS WAF 会自动相应定制保护参数。

通过保护包选项简化 AWS WAF 规则部署

AWS WAF 通过三种配置选项简化安全部署，均基于 AWS 安全专业知识并可立即实施。保护包提供针对不同应用类型优化的全面配置：

推荐（Recommended ）：为所选应用类别和流量来源启用推荐防护 精华（Essentials ）：为所选应用类别和流量来源启用必要防护 自选（You build it ）：从可用选项中选择并自定义防护

实现仅需一步：根据安全需求选择合适的保护包。这种方式在降低配置复杂度的同时，保证了安全标准。如果用户不知道如何选择，建议选择

Essentials ，包含了必要的防护规则，并且成本也相对较低。用户可以根据需要对规则的ACTION进行后续调整。

用户有更细致的配置需求，可以打开定制保护包（可选）Customize protection pack (web ACL) – optional，选项，进行配置。或者使用默认选项。 这既能满足需要简化管理的用户，也能满足需要细化配置的用户。

实时监控、自动建议与防护活动可视化

新控制台配备对于流量情况更加直观的仪表板，在一个页面列出所有的保护包，让用户对所有保护包的情况一览无余。

通过将威胁检测指标、规则性能分析和可操作洞察合并到单一视图中，简化安全监控。安全团队可更快速响应威胁，无需在多个屏幕间切换。

AWS 威胁情报通过分析流量模式来增强监控能力，主动识别潜在漏洞。该服务分析包括 IP 信誉（IP reputation）、DDoS 攻击、机器人活动、匿名 IP（Anonymous IP） 来源和易受攻击的应用流量等关键流量维度。当 AWS WAF 检测到漏洞时，会推荐特定的 AWS 托管规则来增强用户的安全防护能力。

新的序列规则视图仪表板提供一览式安全洞察。它显示所选时间范围内的请求数，并汇总各防护规则及其对应的终止动作。一个突出功能是桑基图（Sankey Diagram）可视化，映射防护活动到 AWS WAF 操作（ACTION），帮助安全团队跟踪流量路径、识别规则交互模式并优化配置。

点选具体的操作（ACTION），可以选择过滤到这条规则组（Filter to this rule），查看针对该规则组的视图，显示具体规则的视图。

面向结果的仪表板，提供可操作洞察

新仪表板基于各类业务影响角度显示安全指标。左侧面板包含四大类别：流量、规则、机器人和 DDoS防护特性。右侧面板显示每个类别下的指标。在流量特性（Traffic characteristics）中，您可按国家、攻击类型和设备类型查看指标。规则特性（Rule characteristics）突出前十的托管规则标签，和被托管规则组终结的请求数量。“机器人特性”包括检测比例、机器人类别、令牌信息、协同行为信号及会话令牌等仪表板。DDoS防护（Anti-DDoS）包括DDoS的规则标签以及Challenge触发情况。 新控制台体验使您能够快速识别威胁、优化 WAF 规则，并根据具体需求保持高效安全控制。

控制台中的查询日志

新的 AWS WAF 控制台内置日志浏览器，点击右下角的尖角图表，即可打开折叠的日志浏览器。您可在控制台底部访问两种分析选项：用于详细分析的日志浏览器（Log explorer）或用于即时查看的请求抽样（Sampled requests）。日志浏览器依赖 Amazon CloudWatch 日志，提供基于规则操作和时间范围的预配置筛选器，便于快速识别模式和趋势。如未启用 CloudWatch 日志，也可通过请求抽样分析安全事件。

可用性与定价

从今天起，这些仪表板默认在 AWS WAF 控制台中可用，无需额外WAF费用，无需额外设置即可使用。如果采用 Amazon CloudWatch 日志，获得日志浏览器（Log explorer）和排名洞察（Top Insight）图表，产生的费用由CloudWatch服务收取。

与CloudFront 联动新体验

如果用户同时使用 CloudFront服务，利用AWS WAF挂载在CloudFront服务上提供保护，WAF与CloudFront联动新体验提高整体部署效率与运维效率。 在创建新的 CloudFront 分配（Distribution）时，用户可以在“Web Application Firewall（WAF）”部分点击 “启用安全保护”（Enable security protections），CloudFront 将自动为您创建一个保护包（Web ACL），并附加到此分配上，简化了操作流程。如果用户已经在 AWS WAF 中创建了保护包，也可以在 CloudFront 控制台的 Security 选项卡中，选择 “使用现有 WAF 配置”（Use existing WAF configuration），将现有规则关联到目标分配上。

启用 WAF 后，CloudFront 控制台的 安全仪表盘（Security dashboard ）将呈现实时安全指标，包括允许与拦截请求数，还有 Bot 控制功能等。无需跳转到其他控制台，即可查看整体安全状况，并对可疑流量进行快速响应。

点击管理保护（Manage protections）下的管理规则（Manage Rules），即可在无需跳转WAF控制台的情况下，直接在CloudFront面板上对WAF规则进行添加或者修改。

结论

通过融合智能监控、引导配置和轻松访问专业化解决方案，全新的WAF增强控制台帮助组织在无需经历以往高级安全管理复杂性的情况下，保持强大安全标准。在部署和运维管理阶段极大的提升了用户的使用效率和便捷性，提升了可视化运维的能力。

*前述特定亚马逊云科技生成式人工智能相关的服务目前在亚马逊云科技海外区域可用。亚马逊云科技中国区域相关云服务由西云数据和光环新网运营，具体信息以中国区域官网为准。

---

亚马逊AWS官方博客

构建AI驱动的智能定价解决方案：新能源充电运营的数字化转型实践

随着全球电动汽车市场的快速发展，充电基础设施运营商面临着日益复杂的定价挑战。传统的静态定价模式已无法适应多变的市场环境、竞争格局和用户需求。本文将深入探讨如何构建Agentic AI驱动的智能报价系统，帮助充电运营商（CPO）实现动态定价优化，提升运营效率和盈利能力。

行业挑战与机遇

新能源充电运营商正经历着快速的全球化扩张，但传统的运营模式面临着诸多挑战：

• 静态定价局限性：传统充电站普遍采用固定价格模式，根据当地一天内的用电高峰和低谷电价进行定价，但是针对不同环境的充电场站，都采取统一定价，而不是根据历史使用情况动态调整启动费、滞留费等，导致运营商错失大量收益优化机会。
• 海量数据处理挑战：现代充电运营产生的数据量呈指数级增长，包括每次充电的详细记录、用户行为模式、设备运行状态、环境条件变化等。这些数据不仅量大，而且结构复杂，数据处理能力的不足会成为业务发展的瓶颈，限制了运营商进行深度业务分析和优化的能力。
• 业务洞察提取困难：拥有大量数据并不等同于拥有业务洞察，如何从原始数据中提取有价值的商业智能是许多充电运营商面临的核心挑战。传统的报表系统只能提供基础的统计信息，如充电次数、总收入等，但无法深入分析用户行为模式、预测市场趋势、识别潜在商业机会。

Agentic AI** **驱动的智能定价解决方案

为解决充电运营商的挑战，基于Amazon Strands Agents SDK，我们构建了一套革命性的Agentic AI驱动智能报价系统，实现了从传统单一决策系统向多Agent协作生态的根本性转变。

智能定价决策Agent，作为系统的核心决策单元，专门负责综合分析多维度数据并生成最优定价策略。基于Amazon Strands Agents SDK构建，具备强大的推理能力和学习能力。Agent能够处理复杂的业务规则，考虑多个约束条件，在保证合规性的前提下实现收益最大化。该Agent还具备解释能力，能够为每个定价决策提供清晰的逻辑说明和风险评估，帮助管理层理解AI决策的合理性。通过持续学习机制，Agent能够根据历史决策效果不断优化自身的决策模型，提高定价准确性。

该方案将 Generative BI作为MCP Tool， 实现自然语言进行智能数据查询和检索。Generative BI是一种结合了生成式AI技术的新型数据分析工具，它允许用户通过自然语言对话的方式直接与数据进行交互，无需掌握复杂的SQL查询语句或数据分析技能。用户只需用日常语言描述自己的数据需求，系统就能自动理解意图、生成相应的查询逻辑，并返回可视化的分析结果，大大降低了数据分析的门槛，让业务人员能够快速获得数据洞察。

通过这种方式，系统可以快速从海量运营数据中提取相关的历史定价数据、用户行为数据和市场竞争数据。例如，当需要为特定充电站制定新的定价策略时，系统能够通过自然语言交互，精确定位并分析该区域的历史表现数据、用户反馈和竞争对手信息，将复杂的数据分析转化为直观的业务洞察。然后通过Amazon Strands Agents SDK，实现复杂的定价场景，可以调度多个专业化的子 Agent 协同工作，从而综合考虑多个因素（如峰谷电价、设备利用率、竞争态势等），通过多步推理得出最优定价方案。

智能定价解决方案的架构图

• 前端接入与负载均衡：用户请求通过应用负载均衡器(ALB)进入系统，ALB提供高可用性保障和智能流量分发功能。整个系统部署在AWS VPC环境中，确保网络安全和资源隔离。
• 容器化应用服务层：ECS容器服务承载基于FastAPI框架的Web应用，该应用同时支持RESTful API和SSE长连接通信。SSE长连接的设计解决了生成式商业智能系统执行复杂分析任务时可能出现的HTTP超时问题。应用集成Strands Agents SDK，支持运行时动态创建和配置Bedrock Agent。
• AI推理：Amazon Bedrock提供核心的大语言模型推理能力，通过Strands Agents SDK进行调用管理。
• 数据集成：Generative BI作为MCP客户端，为系统提供数据分析和洞察能力。MCP协议的采用实现了标准化的模型上下文交互，便于集成多种数据源和分析工具。
• 数据存储与安全管理：Amazon DynamoDB负责存储对话历史、会话状态等关键业务数据。AWS Secrets Manager统一管理系统敏感配置和API密钥，确保安全合规。Amazon ECR存储容器镜像，支持应用的版本管理和快速部署。

该架构架构支持”Agents as Tools”模式，实现多Agent协调处理复杂业务流程。以价格策略制定为例，系统能够分步骤执行站点识别、数据获取、洞察生成等任务。整体设计兼顾了系统扩展性和长时间AI计算任务的处理需求。

制定定价策略** **Demo** **展示

为了更好地展示系统的实际应用效果，我们以制定某充电站的定价策略为例，演示完整的智能定价策略制定流程。当用户通过自然语言输入”帮我制定站点某充电站的定价策略”时，该解决方案立即启动多步骤分析流程。该方案首先进行任务拆解，如获取场站基本信息数据、获取经纬度范围等，然后通过Generative BI工具针对每一个字任务进行数据查询。

基于收集到的多维度数据，系统生成了一份详尽的智能定价分析报告。该报告展示站点的地理位置特征、历史使用模式、设备状态、电力成本变化等多个维度的信息。通过大模型识别用户行为规律，预测不同时段的需求波动，并结合外部市场因素进行风险评估。这一过程体现了Agentic AI的核心优势——能够处理人类难以同时考虑的多重复杂因素。

基于收集到的多维度数据的分析结果，通过对比分析、趋势预测，最终为运营商提供了具有前瞻性的定价策略建议，同时给出了调价理由和配套措施，确保策略的可操作性和有效性。

通过这个Demo，我们可以看到整个系统如何将复杂的数据分析转化为直观的商业洞察，为运营决策者提供了强有力的智能支持工具。

优化效果监控** **Demo** **展示

为了验证智能定价策略的实际效果，我们选择了已实施动态定价策略的充电站作为监控对象。当运营人员输入指令出发后，将启动效果监控分析流程。系统首先通过Generative BI工具自动提取该站点实施新定价策略前后的关键运营指标，包括收入变化、充电频次、用户满意度、设备利用率等多维度数据。智能监控Agent对比分析策略实施前与实施后的数据表现，自动识别关键变化趋势和异常波动点。

基于数据对比结果，系统生成了一份全面的效果评估报告。报告详细展示了定价策略调整带来的直接影响和间接效应，通过可视化图表清晰呈现收入增长曲线、用户行为变化模式、竞争地位变化等关键信息。系统还自动识别出策略执行过程中的成功因素和潜在风险点，为后续优化提供数据支撑。

该方案监控过程实现了从数据收集到洞察生成再到行动建议的闭环管理，为充电运营商提供了完整的智能化运营支持。

总结

通过构建基于Amazon Strands Agents SDK的智能定价解决方案，帮助新能源充电运营商实现了从传统静态定价向智能动态定价的根本性转变，有效破解了行业面临的三大核心挑战。Agentic AI的多维决策能力通过多Agent协作综合考虑峰谷电价、设备利用率、竞争态势等复杂因素，显著提升了充电站收益和运营效率。同时，Generative BI彻底改变了海量数据处理模式，通过自然语言交互，让业务人员无需技术背景即可快速获取深度洞察。Agent AI强大的推理学习能力结合Generative BI的可视化分析，实现了从原始数据到商业洞察的智能化转换，为管理层提供了可解释的决策支持和前瞻性的市场预测。

本解决方案展现了多Agent协作、MCP标准化集成和实时流式处理等技术创新的巨大价值，不仅为新能源充电运营商提供了可复制的智能化转型范式，更为整个新能源生态的数字化升级奠定了坚实基础。运营团队从繁重的价格维护工作转向高价值的战略决策，管理决策实现了智能化跃升，在激烈的市场竞争中赢得了显著优势。随着技术的持续演进，这种AI驱动的智能化运营模式必将在更广泛的能源管理领域发挥重要作用，为行业的可持续发展和数字化转型提供强有力的技术支撑。

*前述特定亚马逊云科技生成式人工智能相关的服务目前在亚马逊云科技海外区域可用。亚马逊云科技中国区域相关云服务由西云数据和光环新网运营，具体信息以中国区域官网为准。

---

亚马逊AWS官方博客

基于Amazon Bedrock的TwelveLabs Marengo Embed 2.7多模态搜索系统

*本文展示如何通过AI辅助开发，在零手工编码的情况下构建生产就绪的多模态搜索应用，完整体验Amazon Bedrock上TwelveLabs Marengo Embed 2.7模型的跨模态AI能力。*

项目亮点

完整多模态体验系统

构建了一个

端到端的多模态搜索演示系统，让用户能够直观体验Marengo Embed 2.7的强大跨模态能力，包括文本到图像、文本到视频、文本到音频以及文件间的相似性搜索。

AI辅助开发实践

本项目

完全通过AI辅助开发完成，开发者未编写任何一行代码。从架构设计、代码实现、部署配置到问题调试，全程由Amazon Q Developer AI助手完成，展示了AI驱动开发的巨大潜力。

引言

在AWS Summit New York上，我们宣布TwelveLabs视频理解模型正式登陆Amazon Bedrock，其中包括突破性的

Marengo Embed 2.7模型。该模型代表了多模态AI的重大进步，在单一的1024维向量空间内提供跨图像、视频、音频和文本的统一嵌入生成。

这一技术突破对于解决现实世界的业务挑战具有重要意义。以游戏行业为例，公司在发行游戏产品时需要制作大量广告视频素材进行AB测试。部分游戏公司的广告视频素材量已超过

10万+级别，每月以上万条的速度增加。面对如此庞大的素材库，传统的文件名和标签检索方式已经无法满足需求。设计师需要频繁从庞大的视频素材库中检索、提取素材信息和片段，获取创意灵感或拼接新的广告视频。这种需要通过文本描述、参考图片或音频片段快速找到相关视频素材的跨模态搜索需求，正是多模态AI技术的理想应用场景。

与需要为每种模态使用单独模型的传统方法不同，Marengo Embed 2.7实现了真正的跨模态理解，允许开发者构建文本查询可以找到相关图像、图像可以匹配相似视频、音频内容可以与视觉元素语义链接的应用程序。这种能力不仅适用于游戏行业，同样可以复用到效果类广告、教育培训、电商平台、媒体内容等多个需要大量多媒体内容管理和检索的行业。

更令人兴奋的是，本文展示的完整多模态搜索系统完全通过AI辅助开发实现，无需手工编写任何代码，为AI驱动的软件开发开辟了新的可能性。

Marengo Embed 2.7的独特之处

统一向量空间架构

传统多模态系统面临对齐不同向量空间的挑战：

传统方法：

图像模型 → 图像向量空间A

文本模型 → 文本向量空间B

视频模型 → 视频向量空间C

音频模型 → 音频向量空间D

跨模态搜索 = 复杂的映射和转换 ❌

Marengo Embed 2.7：

所有模态 → 统一1024维向量空间

跨模态搜索 = 直接余弦相似度计算 ✅

高级视频理解

该模型为视频内容提供三种不同的嵌入类型：

visual-image：针对视觉相似性匹配优化 visual-text：专为语义文本到视频搜索设计 audio：捕获包括音乐、语音和环境声音在内的音频特征

企业级特性

异步处理：为大文件的生产工作负载而构建 AWS集成：与Amazon Bedrock基础设施原生集成 可扩展架构：自动扩展和负载均衡 安全性：内置访问控制和加密

解决方案架构

方案概述

针对游戏行业在发布新游戏产品时需要制作大量广告视频的挑战，我们构建了一个基于Marengo Embed 2.7的多模态搜索解决方案。由于这些视频的生命周期通常很短（仅持续几天到几周），游戏公司必须持续创建新视频进行A/B测试以确保广告性能的一致性。

当前游戏公司通常采用三种方法制作广告视频内容： 使用游戏内资产：利用游戏内的资产创建与游戏玩法相关的视频 利用大语言模型：使用AI生成广告视频片段，然后组合成完整视频 素材拆解重组：将现有广告视频拆解成小片段，然后重新组合成新的广告创意

其中，

第三种方法在A/B测试中特别有用，能够提供大量的广告变体，尤其适用于不包含游戏内元素的广告。在这个制作过程中，游戏公司会构建一个庞大的视频素材库，素材来源于各种渠道。 从这个素材库中搜索合适的广告片段每天都会消耗大量的人力资源。一些公司也在探索跨模态检索技术来简化这一过程。

在构建素材管理的解决方案时，可以

以Marengo Embed 2.7多模态嵌入模型为核心，将所有媒体类型（图像、视频、音频、文本）映射到统一的1024维向量空间，实现高效的跨模态素材检索。同时结合大语言模型的理解能力，进一步提升素材管理的智能化水平，有效解决第三种方法中的核心痛点。本文通过构建一个演示系统，展示这些技术方法的实际应用效果。

业务价值

该解决方案通过自动化资产检索和利用现有资源，

加速内容创作并提高广告性能。这不仅 降低了人力成本，还 优化了资源利用率，使设计师能够通过文本描述、参考图像或音频片段等多模态检索方法快速定位相关视频。

技术实现

为了完整体验Marengo Embed 2.7的能力，我们通过AI辅助开发构建了一个基于Serverless无服务器架构的综合多模态搜索系统。整个开发过程中，从架构设计到代码实现，从部署配置到问题调试，开发者未编写任何一行代码，全程由Amazon Q Developer AI助手完成：

*系统架构*

系统执行流程

系统通过两个主要工作流程运行：

文件上传与处理和 搜索与检索。

文件上传与处理工作流程

用户交互：用户通过Amazon CloudFront访问网络界面，通过拖放或文件选择上传媒体文件（图像、视频、音频）。 API处理：文件转换为base64格式，通过Amazon API Gateway发送到主AWS Lambda函数，进行文件类型和大小限制（最大10MB）验证。 Amazon S3存储：AWS Lambda解码base64数据并将原始文件上传到Amazon S3进行持久化存储。 Amazon S3事件触发：Amazon S3在上传新文件时自动触发专用的嵌入AWS Lambda函数，启动嵌入生成过程。 Amazon Bedrock调用：嵌入AWS Lambda异步调用Amazon Bedrock的Marengo Embed 2.7模型，为所有媒体类型生成统一的1024维嵌入向量。 向量存储：嵌入AWS Lambda将生成的嵌入向量与元数据一起存储在Amazon OpenSearch Service中，创建可搜索的向量数据库。

搜索与检索工作流程

搜索请求：用户通过网络界面使用上传文件或文本查询启动搜索，可选择不同的搜索模式（视觉、语义、音频）。 API处理：搜索请求通过Amazon API Gateway发送到搜索API AWS Lambda函数进行初始处理。 任务创建：搜索API AWS Lambda在Amazon DynamoDB中创建搜索任务记录，并向Amazon SQS队列发送消息进行异步处理。 队列处理：搜索API AWS Lambda向Amazon SQS队列发送消息进行异步处理。 工作器激活：搜索工作AWS Lambda被Amazon SQS消息触发，提取搜索参数并准备嵌入生成。 查询嵌入：工作AWS Lambda调用Amazon Bedrock的Marengo模型为搜索查询（文本或上传文件）生成嵌入向量。 向量搜索：工作AWS Lambda在Amazon OpenSearch Service中使用余弦相似度执行相似性搜索，对跨模态查询使用不同策略，然后在Amazon DynamoDB中更新结果供前端轮询。

工作流程集成

两个工作流程共享通用基础设施组件但服务于不同目的：

上传工作流程（1-6）：专注于摄取和处理媒体文件以构建可搜索的向量数据库 搜索工作流程（1-7）：处理用户查询并从预构建的向量数据库中检索相关结果 共享组件：两个工作流程都利用相同的Amazon Bedrock模型、Amazon OpenSearch Service索引和核心AWS服务以保持一致性

关键技术特性

统一向量空间：所有媒体类型（图像、视频、音频、文本）都嵌入到相同的1024维空间中，实现真正的跨模态搜索 异步处理：Marengo Embed 2.7需要异步调用，通过Amazon SQS队列和工作AWS Lambda函数处理 多模态搜索：支持文本到图像、文本到视频、文本到音频和文件到文件的相似性搜索 可扩展架构：无服务器设计根据需求自动扩展，无需基础设施管理 实时状态：类似WebSocket的轮询提供处理状态和搜索结果的实时更新

演示演练

为了说明系统的能力，让我们通过用户界面和关键功能进行演练：

系统概览

*系统主界面*

应用程序提供了直观的界面，包含三个主要模块：

文件上传：支持图像、视频和音频文件 异步搜索：基于文件和基于文本的搜索模式 实时处理：状态跟踪和结果显示

文件上传和处理

*文件上传界面*

系统支持多种媒体格式，具有拖放功能：

图像格式：PNG、JPEG、JPG、WEBP 视频格式：MP4、MOV 音频格式：WAV、MP3、M4A 文件大小限制：每个文件10MB

搜索能力

*文件搜索界面*

用户可以上传媒体文件来查找不同模态的相似内容。例如，在游戏广告素材库中，设计师可以上传一个包含特定游戏角色的参考视频，系统会自动找到其他包含相似角色或场景的广告素材。对于视频文件，系统提供多种搜索模式：

视觉相似性：基于视觉内容匹配，适用于查找相似的场景或人物外观 语义相似性：基于内容理解，适用于查找相似的动作或情节 音频相似性：基于音频特征匹配，适用于查找相似的背景音乐或声音效果 *文本搜索界面*

基于文本的搜索实现了真正的跨模态检索，允许用户使用自然语言描述找到相关的图像、视频和音频内容。在游戏广告制作中，这意味着设计师可以输入“人物战斗”或“城堡场景”等描述，快速找到匹配的广告素材。

搜索结果和跨模态匹配

*搜索结果显示*

结果显示包括：

相似度分数：量化匹配置信度 媒体预览：视频和音频的直接播放 元数据：文件类型、上传时间和其他详细信息 排序：按相关性排序的结果 *跨模态搜索对比*

系统演示了不同的搜索模式：

视觉搜索：专注于颜色、形状和视觉元素 语义搜索：强调内容理解和概念匹配 音频搜索：针对声音特征和音频特性

异步处理

*处理状态界面*

由于Marengo的异步处理模型，系统提供实时状态更新：

处理状态：显示嵌入生成进度 完成通知：自动重定向到结果 错误处理：清晰的错误消息和建议

素材管理

*素材管理界面*

系统提供了完整的素材管理功能，帮助用户有效管理和监控上传的多媒体内容。对于游戏公司而言，这意味着可以集中管理数万甚至十万级别的广告视频素材：

素材展示：以卡片形式展示所有已上传的游戏广告视频、角色图像和音效文件 处理状态监控：实时显示每个素材的embedding生成状态，确保新上传的广告素材可以及时被搜索到 智能筛选：支持按素材类型（角色展示、游戏场景、技能特效）和处理状态进行筛选 状态指示器：通过颜色编码清晰标识不同的处理状态，帮助美术团队快速识别可用素材 批量管理：便于美术和策划团队批量查看和管理大量广告素材文件

多模态搜索实战演示

系统支持多种搜索模式，以下展示了实际运行中的各种跨模态搜索场景。这些功能在游戏广告制作中尤为实用，能够显著提高设计师的创意效率和素材复用率：

图像搜索

*图像输入搜索*

使用图像作为查询输入，系统能够：

视觉相似性匹配：找到具有相似视觉特征的图像和视频。在游戏广告制作中，设计师可以上传一张人物图像，快速找到包含相似人物的所有广告视频 跨模态检索：基于视觉内容发现相关媒体，如通过场景截图找到相关的背景音乐或声音效果 实时处理：上传图像后立即开始embedding生成和搜索，支持快速的创意迭代

视频搜索

*视频输入搜索*

视频文件搜索展示了Marengo Embed 2.7的强大多模态能力：

多重embedding生成：同时提取视觉、文本和音频特征 智能匹配：根据内容类型选择最佳embedding进行搜索 异步处理：处理大型视频文件的完整工作流程

音频搜索

*音频输入搜索*

音频文件的跨模态搜索能力：

音频格式支持：WAV、MP3、M4A主流格式 音频特征提取：捕获音乐、语音和环境声音特征 相似性匹配：找到具有相似音频特征的内容

文本到图像和视频搜索

*文本搜索图像视频*

文本查询的跨模态检索展示了真正的语义理解：

自然语言处理：理解复杂的文本描述。在游戏广告制作中，设计师可以输入“激烈战斗场面”或“多人组队合作”等描述 跨模态匹配：文本描述匹配相关的游戏截图和广告视频内容，帮助设计师快速找到符合创意方向的素材 语义相似性：基于内容理解而非关键词匹配，能够理解游戏中的情节和情感表达

文本到音频搜索

*文本搜索音频*

文本到音频的跨模态搜索展示了Marengo Embed 2.7的强大语义理解能力：

语义音频匹配：使用自然语言描述找到相关音频内容，如“欢快的音乐”、“海浪声”等 音频播放器集成：搜索结果中的直接播放控件，支持即时试听 相似度评分：量化文本到音频内容匹配的准确性，帮助用户理解结果相关性 音频内容匹配：基于音频特征进行语义匹配，支持各种音频文件格式

实现细节

1. 嵌入生成

核心功能利用Marengo Embed 2.7对所有媒体类型的统一API：

def generate_embedding(media_type, s3_uri, bucket_name):

“””使用Marengo Embed 2.7生成嵌入”””

根据媒体类型配置输入

if media_type == “image”:

model_input = {

“inputType”: “image”,

“mediaSource”: {

“s3Location”: {

“uri”: s3_uri,

“bucketOwner”: account_id

}

}

}

elif media_type == “video”:

model_input = {

“inputType”: “video”,

“mediaSource”: {

“s3Location”: {

“uri”: s3_uri,

“bucketOwner”: account_id

}

}

省略embeddingTypes以获取所有可用类型

}

elif media_type == “audio”:

model_input = {

“inputType”: “audio”,

“mediaSource”: {

“s3Location”: {

“uri”: s3_uri,

“bucketOwner”: account_id

}

}

}

elif media_type == “text”:

model_input = {

“inputType”: “text”,

“inputText”: text_content

}

异步调用（Marengo必需）

response = bedrock_client.start_async_invoke(

modelId=’twelvelabs.marengo-embed-2-7-v1:0′,

modelInput=model_input,

outputDataConfig=output_config

)

return response

2. 向量存储策略

系统使用统一模式在Amazon OpenSearch Service中存储嵌入：

{

“visual_embedding”: [0.1, 0.2, …], // 图像和视频视觉特征

“text_embedding”: [0.3, 0.4, …], // 视频文本/语义特征

“audio_embedding”: [0.5, 0.6, …], // 视频和音频特征

“s3_uri”: “s3://bucket/file.mp4”,

“file_type”: “mp4”,

“timestamp”: “2024-01-25T10:00:00Z”

}

3. 智能搜索实现

搜索逻辑根据查询类型和目标媒体进行调整：

def cross_modal_search(query_embedding, query_type):

“””实现跨模态搜索逻辑”””

if query_type == ‘text’:

文本查询：通过visual_embedding搜索图像，

通过text_embedding搜索视频，通过audio_embedding搜索音频

search_body = {

“query”: {

“bool”: {

“should”: [

{

“bool”: {

“must”: [

{“knn”: {“visual_embedding”: {“vector”: query_embedding, “k”: 5}}},

{“terms”: {“file_type”: [“png”, “jpg”, “jpeg”, “webp”]}}

]

}

},

{

“bool”: {

“must”: [

{“knn”: {“text_embedding”: {“vector”: query_embedding, “k”: 5}}},

{“terms”: {“file_type”: [“mp4”, “mov”]}}

]

}

},

{

“bool”: {

“must”: [

{“knn”: {“audio_embedding”: {“vector”: query_embedding, “k”: 5}}},

{“terms”: {“file_type”: [“wav”, “mp3”, “m4a”]}}

]

}

}

]

}

}

}

else:

文件查询：使用visual_embedding进行相似性搜索

search_body = {

“query”: {

“knn”: {

“visual_embedding”: {

“vector”: query_embedding,

“k”: 10

}

}

}

}

return opensearch_client.search(index=’embeddings’, body=search_body)

关键特性和能力

支持的媒体格式

图像：PNG、JPEG、JPG、WEBP 视频：MP4、MOV 音频：WAV、MP3、M4A 文本：自然语言查询

跨模态搜索场景

文本到图像：查找匹配文本描述的图像 文本到视频：基于语义查询定位视频内容 文本到音频：通过描述性文本发现音频内容 图像到视频：查找具有相似视觉内容的视频 文件到文件：在所有格式中定位相似媒体

性能指标

基于演示系统的测试，以下是关键性能特征：

处理时间

文本嵌入：2-5秒 图像嵌入：10-30秒 视频嵌入：1-5分钟（取决于长度） 音频嵌入：30秒-2分钟

搜索性能

查询响应时间：向量相似性搜索<500ms 并发用户：通过Lambda自动扩展 存储效率：1024维向量（每个嵌入4KB）

性能和可扩展性

资源配置

AWS Lambda内存：嵌入处理1024MB AWS Lambda超时：大文件处理15分钟 Amazon OpenSearch Service：1024维向量空间 文件大小限制：每个文件10MB（Amazon API Gateway约束）

最佳实践和经验教训

1. 异步处理至关重要

Marengo Embed 2.7仅支持异步调用。相应地设计您的架构：

✅ 正确：异步调用

response = bedrock_client.start_async_invoke(

modelId=’twelvelabs.marengo-embed-2-7-v1:0′,

modelInput=model_input,

outputDataConfig=output_config

)

❌ 错误：同步调用将失败

response = bedrock_client.invoke_model(…)

2. 针对不同媒体类型优化

图像：单一视觉嵌入 视频：多个嵌入（visual-image、visual-text、audio） 音频：单一音频嵌入 文本：单一文本嵌入

3. 实现适当的错误处理

def poll_async_result(invocation_arn, max_attempts=60):

“””轮询异步调用结果，具有适当的错误处理”””

for attempt in range(max_attempts):

try:

response = bedrock_client.get_async_invoke(invocationArn=invocation_arn)

if response[“status”] == “Completed”:

return process_output(response)

elif response[“status”] in (“Failed”, “Cancelled”):

raise Exception(f”调用失败: {response.get(‘failureMessage’)}”)

time.sleep(5) # 下次轮询前等待

except Exception as e:

if attempt == max_attempts – 1:

raise e

time.sleep(5)

raise TimeoutError(“异步调用超时”)

部署指南

先决条件

• 配置了适当权限的AWS CLI
• 安装AWS CDK v2
• Python 3.11+和Node.js 18+

快速部署

克隆仓库

git clone

cd aws-multimodal-embedding

配置服务前缀

export SERVICE_PREFIX=”your-project-name”

部署基础设施

cd infrastructure

cdk deploy –require-approval never

上传前端资源

aws s3 sync ../frontend/ s3://${SERVICE_PREFIX}-frontend/

所需AWS权限

部署需要以下权限：

• Amazon Bedrock模型访问
• AWS Lambda函数创建和执行
• Amazon OpenSearch Serverless集合管理
• Amazon S3存储桶操作
• Amazon API Gateway配置
• Amazon CloudFront分发设置

用例和应用

游戏和广告行业

游戏广告素材管理：面对10万+级别的广告视频库，通过文本描述、参考图片或音频片段快速找到相关素材 效果类广告复用：与游戏广告类似，需要大量AB测试和快速迭代，可直接复用多模态搜索方案 创意灵感获取：设计师通过跨模态搜索快速找到相似风格的历史素材作为参考

教育和企业培训

课程视频资源管理：教师通过关键词快速找到相关教学素材 多媒体教学资源检索：跨模态检索和推荐相关学习内容 企业培训库管理：员工通过描述快速找到相关的培训内容

电商平台

产品视频库管理：通过商品描述快速找到相关的产品展示视频 视觉产品搜索：用户上传图片搜索相似商品的视频介绍 跨模态产品匹配：将产品视频与客户查询匹配

媒体内容管理

新闻素材库管理：通过文本描述快速找到相关的视频片段 影视后期制作：素材查找和复用，提高制作效率 内容档案管理：在庞大的多媒体档案中进行智能搜索

安全建议

数据隐私

• 所有媒体文件在您的AWS账户内处理
• 嵌入存储在您的OpenSearch集群中
• 不与外部服务共享数据

访问控制

AWS Lambda执行角色的IAM策略

{

“Version”: “2012-10-17”,

“Statement”: [

{

“Effect”: “Allow”,

“Action”: [

“bedrock:InvokeModel”,

“bedrock:StartAsyncInvoke”,

“bedrock:GetAsyncInvoke”

],

“Resource”: “arn:aws:bedrock:*:*:model/twelvelabs.marengo-embed-2-7-v1:0”

},

{

“Effect”: “Allow”,

“Action”: [

“s3:GetObject”,

“s3:PutObject”

],

“Resource”: “arn:aws:s3:::your-bucket/*”

}

]

}

未来增强

可增加功能

实时处理：实时内容的流式嵌入 高级过滤：基于元数据的搜索细化 多语言支持：扩展语言能力 自定义模型：针对特定领域用例的微调 成本优化：嵌入缓存策略和批处理优化，减少API调用成本

def get_cached_embedding(file_hash, media_type):

“””实现缓存以减少API调用”””

cache_key = f”{file_hash}:{media_type}”

检查Amazon DynamoDB缓存

cached_result = dynamodb_table.get_item(Key={‘cache_key’: cache_key})

if ‘Item’ in cached_result:

return cached_result[‘Item’][’embedding’]

如果未缓存则生成新嵌入

embedding = generate_embedding(media_type, s3_uri, bucket_name)

存储在缓存中

dynamodb_table.put_item(

Item={

‘cache_key’: cache_key,

’embedding’: embedding,

‘ttl’: int(time.time()) + ttl_seconds # 设置适当的TTL

}

)

return embedding

对于大规模部署，考虑实现批处理以优化成本和吞吐量。

集成机会

Amazon Rekognition：增强图像分析 Amazon Transcribe：音频到文本转换 Amazon Translate：多语言搜索能力 Amazon Personalize：个性化内容推荐

结论

Amazon Bedrock上的TwelveLabs Marengo Embed 2.7代表了多模态AI能力的重大进步。通过为所有媒体类型提供统一的向量空间，它简化了复杂跨模态搜索应用的开发，同时保持企业级性能和安全性。

回到文章开头提到的业务场景，游戏公司面临的10万+级别广告视频素材管理挑战，正是多模态AI技术的理想应用场景。通过本文展示的解决方案，设计师现在可以：

通过自然语言描述快速定位相关广告素材，如”激烈战斗场面”或”多人组队合作” 上传参考图片或音频片段找到风格相似的视频素材，大幅提升创意效率 实现跨模态素材复用，将现有广告视频拆解重组的第三种制作方法变得更加高效 显著降低人力成本，从每天消耗大量人力资源的手工搜索转向智能化检索

本文演示的无服务器架构展示了如何构建可自动扩展的生产就绪多模态应用，同时保持成本优化。同时，整个系统完全通过AI辅助开发实现，展示了AI驱动开发在解决实际业务问题中的巨大潜力。

关键要点

统一方法：单一模型处理所有媒体类型 生产就绪：基于AWS无服务器基础设施构建 成本效益：按使用付费定价和优化策略 可扩展：基于需求自动扩展 安全：企业级安全和隐私控制

对于游戏、广告、教育、电商等需要大量多媒体内容管理的行业，Marengo Embed 2.7提供了一个具有强大跨模态理解能力的可访问入口点。随着多模态AI的持续发展，这样的解决方案将成为释放多样化媒体资产价值的关键技术。

其他资源

*本文中显示的示例代码和架构模式可在GitHub仓库中获得。* *前述特定亚马逊云科技生成式人工智能相关的服务目前在亚马逊云科技海外区域可用。亚马逊云科技中国区域相关云服务由西云数据和光环新网运营，具体信息以中国区域官网为准。

---

背景

在电商和游戏等数据密集型行业中，业务人员经常需要快速获取数据洞察及时应对运营策略的变化，例如转化率，下单率，付费玩家的等级分布变化等等问题。这些问题往往需要涉及复杂的SQL查询。传统方式主要依赖技术人员手动的查询语句，或者使用固定报表，整体灵活性较差。非技术人员希望可以通过自然语言完成数库查询的工作，提高数据获取的效率和灵活性。本文将介绍如何通过Bedrock AgentCore Runtime, Strands Agents SDK以及Amazon Redshift MCP Server，通过简单的代码，快速完成数据分析智能体方案的构建。

Amazon Bedrock AgentCore

Amazon Bedrock AgentCore 可帮助您安全、大规模地部署和运行功能强大的人工智能体，主要解决AI智能体的云端部署和运行挑战。Amazon Bedrock AgentCore 服务可以组合使用，也可以单独使用。本文将部署Bedrock AgentCore Runtime，托管数据分析智能体。Bedrock AgentCore Runtime 提供了一个安全、无服务器且专门构建的托管环境，用于部署和运行AI智能体或工具。

Strands Agents SDK

Strands Agents SDK是亚马逊云科技发布的开源AI智能体SDK，可以简化智能体开发，充分利用最新大语言模型的原生推理、规划和工具调用能力，而不需要复杂的编排逻辑。Strands Agents SDK支持多种模型提供商，包括Amazon Bedrock、Anthropic、Ollama、Meta等，并且支持OpenAI兼容接口，在中国区也可以使用国内的模型服务商提供的模型API，Strands Agent SDK还同时提供了20多个预构建工具。本文将通过Strands Agents SDK与Amazon Redshift MCP Server的集成，实现主要的智能体功能。Strands Agents SDK通过MCP Client自动发现和加载Redshift MCP Server提供的所有数据库操作工具，可以自动发现和管理Redshift集群的元数据信息，包括表结构、字段类型、索引关系等，为AI代理提供完整的数据库上下文。MCP Server还处理连接池管理、权限控制和查询优化，生成安全高效的SQL查询。

Amazon Redshift MCP Server

关于MCP的定义这里不再赘述。本文主要使用Amazon Redshift MCP Server来与Redshift资源进行交互。该MCP Server提供了一套全面的工具集，包括发现、探索和查询Amazon Redshift集群及无服务器工作组的功能，使AI助手能够安全高效地操作Redshift资源。该MCP Server使用Redshift Data API完成数仓的访问和操作，无需用户名密码。因此，在后续的AgentCore Runtime部署过程中，请确保AgentCore Runtime附加的角色有足够的权限访问Redshift中的数据，同时请注意分配对应的表权限。

本文将基于模拟的游戏用户数据完成方案演示。

方案架构

架构图

实现逻辑

核心文件如下：

• strands_agent.py # 主要Agent实现
• deploy.py # 部署脚本
• test_client.py # 测试客户端，客户端主要调用agentcore client
• requirements.txt # 依赖管理

requirements.txt

strands-agents

strands-agents-tools

bedrock-agentcore

bedrock-agentcore-starter-toolkit

aws-opentelemetry-distro>=0.10.0

mcp

strands_agent.py

本文基于已有的strands agent代码，通过@app.entrypoint装饰器，将普通的Python函数转换为AgentCore Runtime可以识别和调用的入口点。AgentCore Runtime将用户的代码打包成Docker容器，容器启动后通过@app.entrypoint装饰器识别请求入口点主函数。

请在Redshift MCP Server中配置您的Redshift集群所在的区域为默认区域。在Strands Agent中指定调用的模型，这里使用的是Amazon Bedrock 中的Claude 3.7模型。您可以根据具体的业务需求调整系统提示词。请注意在initialize_table_permissions函数中替换您在Redshift集群中需要访问的表，该函数用于初始化Redshift Data API对于表的访问权限。请参考Amazon Redshift MCP Server文档中涉及的权限要求。

基于Amazon Redshift MCP Server + Strands Agents SDK + Amazon Bedrock AgentCore Runtime实现Agentic Analytics

“””

Strands Agent with Redshift MCP Tools for AgentCore Runtime

“””

from strands import Agent

from strands.tools.mcp import MCPClient

from mcp import stdio_client, StdioServerParameters

from bedrock_agentcore.runtime import BedrockAgentCoreApp

app = BedrockAgentCoreApp()

async def initialize_table_permissions(mcp_client, cluster_id, database_name, tables):

“””Initialize table permissions for Redshift Data API access”””

try:

clusters_result = await mcp_client.call_tool_async(“list_clusters”, {})

if hasattr(clusters_result, ‘content’) and clusters_resul[已去除短链接]ntent:

cluster_info = str(clusters_resul[已去除短链接]ntent)

if cluster_id not in cluster_info:

import re

matches = re.findall(r’identifier[“\’]?\s*:\s*[“\’]?([^”\’}\s,]+)’, cluster_info)

if matches:

cluster_id = matches[0]

for table in tables:

grant_sql = f”GRANT SELECT ON TABLE {table} TO PUBLIC;”

try:

result = await mcp_client.call_tool_async(

“execute_query”,

{

“cluster_identifier”: cluster_id,

“database_name”: database_name,

“sql”: grant_sql

}

)

except Exception as table_error:

continue

except Exception as e:

pass

@app.entrypoint

async def strands_agent_bedrock(payload, context):

“””

Invoke the agent with a payload

“””

========== 配置参数 ==========

AWS配置

AWS_REGION = “us-west-2”

DATABASE_NAME = “testdb”

CLUSTER_ID = “test-workgroup”

数据表配置

TABLES = [

‘public.activity_events’,

‘public.charge_events’,

‘public.fight_events’,

‘public.login_logout_events’

]

模型配置

MODEL_ID = “us.anthropic.claude-3-7-sonnet-[已去除电话]-v1:0”

MCP服务器配置

MCP_COMMAND = “uvx”

MCP_ARGS = [“awslabs.redshift-mcp-server@latest”]

========== 配置参数结束 ==========

try:

redshift_mcp_client = MCPClient(

lambda: stdio_client(StdioServerParameters(

command=MCP_COMMAND,

args=MCP_ARGS,

env={

“AWS_DEFAULT_REGION”: AWS_REGION,

“AWS_REGION”: AWS_REGION

}

))

)

with redshift_mcp_client:

redshift_tools = redshift_mcp_client.list_tools_sync()

try:

await initialize_table_permissions(redshift_mcp_client, CLUSTER_ID, DATABASE_NAME, TABLES)

except Exception as perm_error:

print(f”表权限初始化失败: {perm_error}”)

agent = Agent(

model=MODEL_ID,

system_prompt=””””””你是一位专业的AWS Redshift数据分析师助手，具备以下核心能力：

角色定位

• 精通Redshift数据仓库架构、性能优化和数据分析
• 能够使用可用工具高效查询和分析Redshift数据
• 提供准确、实用的数据洞察和业务建议

分析方法论

1. 数据探索：首先了解数据结构、质量和分布特征

2. 业务理解：结合业务场景解读数据含义

3. 统计分析：运用描述性统计、趋势分析、异常检测等方法

4. 洞察提炼：从数据中提取可操作的业务洞察

5. 建议输出：提供基于数据的决策建议和后续行动方案

SQL执行安全规范

• 仅执行SELECT查询，严禁INSERT、UPDATE、DELETE、CREATE、DROP等写操作
• 每个查询必须包含LIMIT子句，避免返回过大结果集
• 查询前必须验证表名和字段名的存在性
• **重要**：如果查询失败，必须先执行ROLLBACK或COMMIT来结束当前事务，然后重新开始新的查询
• 避免在字符串字段上使用日期函数，需要先进行类型转换
• 如果查询失败，重新生成兼容的SQL而不是尝试修复事务状态

输出要求

• **语言**：全程使用中文回复
• **格式**：以Markdown格式组织内容，包含清晰的标题层级
• **内容结构**：
• 数据概览与质量评估
• 详细分析过程和思维逻辑
• 关键发现和数据洞察
• 业务建议和行动建议

分析深度

• 不仅提供查询结果，更要解释数据背后的业务含义
• 识别数据趋势、模式和异常
• 提供预测性分析和建议
• 考虑数据的时间序列特征和季节性等相关的环境影响

请始终保持专业、准确、有洞察力的分析风格。”””,

tools=redshift_tools,

)

user_input = payload.get(“prompt”, “No prompt found”)

response = agent(user_input)

return response

except Exception as e:

error_msg = f”Agent执行错误: {str(e)}”

return f”抱歉，处理请求时出现错误: {str(e)}”

if __name__ == “__main__”:

app.run()

接下来需要将开发好的strands_agent.py部署到Bedrock AgentCore Runtime中运行。在deploy.py中定义AgentCore部署的区域信息，指定部署的entrypoint和requirements文件。Bedrock AgentCore Runtime部署的过程中会解析strands_agent.py中的entrypoint，并生成.bedrock_agentcore.yaml、Dockerfile、.dockerignore等文件。同时在云上自动创建ECR 用于存储Agent的Docker镜像，用于构建Docker镜像并推送到ECR的CodeBuild项目。最终会在指定区域完成AgentCore Runtime的部署。请注意完成Bedrock AgentCore Runtime部署后，确保关联的IAM角色权限允许访问Redshift集群，可以添加文档中提及的权限用于集群访问以及Data API执行。

deploy.py

!/usr/bin/env python3

“””

Deploy Strands Agent with Redshift MCP Tools to AgentCore Runtime

“””

from bedrock_agentcore_starter_toolkit import Runtime

import boto3

import time

def deploy():

“””Deploy Strands Agent to AgentCore Runtime”””

region = ‘us-west-2’

agentcore_runtime = Runtime()

response = agentcore_runtime.configure(

entrypoint=”strands_agent.py”,

auto_create_execution_role=True,

auto_create_ecr=True,

requirements_file=”requirements.txt”,

region=region,

agent_name=”<替换为您所需的agentcore名称>“

)

print(f”AgentCore Runtime configured successfully!”)

print(f”Region: {region}”)

launch_result = agentcore_runtime.launch()

print(“等待部署完成…”)

status_response = agentcore_runtime.status()

status = status_response.endpoint[‘status’]

end_status = [‘READY’, ‘CREATE_FAILED’, ‘DELETE_FAILED’, ‘UPDATE_FAILED’]

while status not in end_status:

print(f”状态: {status} – 等待中…”)

time.sleep(10)

status_response = agentcore_runtime.status()

status = status_response.endpoint[‘status’]

print(f”最终状态: {status}”)

if status == ‘READY’:

print(“部署成功!”)

return {

‘region’: region,

‘agent_arn’: launch_result.agent_arn,

‘launch_result’: launch_result

}

else:

print(“部署失败”)

return None

if __name__ == “__main__”:

result = deploy()

if result:

print(“\n” + “=”*50)

print(“部署信息:”)

print(“=”*50)

print(f”Region: {result[‘region’]}”)

print(f”Agent ARN: {result[‘agent_arn’]}”)

print(“\n保存这些信息用于测试!”)

test_client.py

• 在agent_runtime_arn参数中指定您上一步部署完成的AgentCore Runtime的arn。
• 请在prompt中替换为您的指令，根据原始表结构，本文使用的提示词为：“帮我总结testdb中charge_events的事件情况，并且根据历史趋势，分析总结未来两周用户可能的事件趋势，在输出中包含详细的分析过程”
• 本文测试客户端代码通过正则解析输出内容并转写到文件中方便阅读，请根据实际需求获取输出内容。

!/usr/bin/env python3

import boto3

import json

import uuid

import datetime

import re

def extract_agent_content(response_data):

content = []

if isinstance(response_data, bytes):

text = response_data.decode(‘utf-8′, errors=’ignore’)

else:

text = str(response_data)

text = text.strip()

if text.startswith(‘”‘) and text.endswith(‘”‘):

cleaned = text[1:-1].replace(‘\\n’, ‘\n’).replace(‘\\t’, ‘\t’).replace(‘\\”‘, ‘”‘).replace(‘\\\\’, ‘\\’)

if len(cleaned.strip()) > 50:

content.append(cleaned)

return content

try:

json_pattern = r’\{[^{}]*”body”[^{}]*”output”[^{}]*”messages”.*?\}’

json_matches = re.findall(json_pattern, text, re.DOTALL)

for json_str in json_matches:

try:

data = json.loads(json_str)

if “body” in data and “output” in data[“body”]:

messages = data[“body”][“output”].get(“messages”, [])

for message in messages:

if “content” in message and “message” in message[“content”]:

msg_content = message[“content”][“message”]

if len(msg_content.strip()) > 20:

content.append(msg_content)

except:

continue

except:

pass

if not content:

message_pattern = r'”message”:\s*”((?:[^”\\]|\\.|\\n|\\t)*)”‘

matches = re.findall(message_pattern, text, re.DOTALL)

for match in matches:

cleaned = match.replace(‘\\n’, ‘\n’).replace(‘\\t’, ‘\t’).replace(‘\\”‘, ‘”‘).replace(‘\\\\’, ‘\\’)

if len(cleaned.strip()) > 50:

content.append(cleaned)

return content

def test_strands_agent():

agent_runtime_arn = “<您上一步中部署完成的agentcore runtime arn>“

session_id = str(uuid.uuid4())

client = boto3.client(

‘bedrock-agentcore’,

region_name=’us-west-2′,

config=boto3.session.Config(read_timeout=300, connect_timeout=60)

)

PROMPT = “帮我总结testdb表中充值的事件情况，并且根据历史一个月内的趋势，分析总结未来以周用户可能的事件趋势，在输出中包含详细的分析过程”

try:

print(f”测试查询: {PROMPT}”)

response = client.invoke_agent_runtime(

agentRuntimeArn=agent_runtime_arn,

qualifier=”DEFAULT”,

runtimeUserId=”123″,

runtimeSessionId=session_id,

payload=json.dumps({“prompt”: PROMPT})

)

all_data = “”

if “text/event-stream” in response.get(“contentType”, “”):

print(“处理流式响应…”)

for line in response[“response”].iter_lines(chunk_size=1024):

if line:

line_str = line.decode(“utf-8”, errors=’ignore’)

all_data += line_str + “\n”

else:

print(“处理普通响应…”)

for event in response.get(“response”, []):

event_str = event.decode(‘utf-8′, errors=’ignore’)

all_data += event_str + “\n”

print(f”收到数据长度: {len(all_data)} 字符”)

contents = extract_agent_content(all_data)

if contents:

print(“\nAgent输出:”)

for i, content in enumerate(contents, 1):

print(f”\n— 片段 {i} —“)

print(content)

else:

print(“未提取到有效内容”)

timestamp = datetime.datetime.now().strftime(“%Y%m%d_%H%M%S”)

output_file = f”agent_output_{timestamp}.txt”

with open(output_file, ‘w’, encoding=’utf-8′) as f:

f.write(f”Agent测试结果\n”)

f.write(f”时间: {datetime.datetime.now()}\n”)

f.write(f”查询: {PROMPT}\n”)

f.write(f”会话ID: {session_id}\n”)

f.write(“=”*50 + “\n\n”)

for i, content in enumerate(contents, 1):

f.write(f”片段 {i}:\n{content}\n\n”)

print(f”\n测试完成，共提取 {len(contents)} 个内容片段”)

print(f”结果已保存到: {output_file}”)

except Exception as e:

print(f”测试失败: {e}”)

if __name__ == “__main__”:

test_strands_agent()

参考输出内容：

Agent测试结果

时间: 2025-09-24 15:31:08.648040

查询: 帮我总结testdb表中充值的事件情况，并且根据历史一个月内的趋势，分析总结未来以周用户可能的事件趋势，在输出中包含详细的分析过程

会话ID: xxxxxxxx

==================================================

片段 1:

充值事件分析报告

1. 数据概览

本次分析基于testdb数据库中的charge_events表，包括充值事件的详细信息。

2. 周度充值趋势分析

2.1 充值事件统计

• **总周数**：4周
• **充值周列表**：

1. 2025-04-28：250个用户，250个充值事件，总金额638万

2. 2025-05-05：812个用户，842个充值事件，总金额2076万

3. 2025-05-12：1053个用户，1102个充值事件，总金额2787万

4. 2025-05-19：1035个用户，1066个充值事件，总金额2643万

2.2 趋势解读

• **用户增长**：从250人快速增长到1000+人，增长约4倍
• **充值事件增长**：从250增长到1100，增长约4.4倍
• **总充值金额**：从638万增长到2787万，增长约4.3倍

3. 充值时间分布

3.1 Top 5充值高峰时段分析

| 排名 | 小时 | 事件数 | 总金额 | 百分比 |

|——|——|——–|——–|——–|

| 1 | 15时 | 162 | 413万 | 4.97% |

| 2 | 9时 | 156

| 394万 | 4.79% |

| 3 | 1时 | 156 | 405万 | 4.79% |

| 4 | 2时 | 146 | 358万 | 4.48% |

| 5 | 11时 | 144 | 344万 | 4.42% |

3.2 时间分布特征

• 充值高峰主要集中在15时、9时、1时
• 每个高峰时段事件数在144-162之间
• 高峰时段金额在340万-410万之间

4. 未来预测与建议

4.1 用户增长预测

• 根据过去4周趋势，预计未来每周用户增长将保持在20-30%
• 下一个月可能达到[已去除电话]活跃充值用户

4.2 充值事件预测

• 预计下一个月每周充值事件将在[已去除电话]个
• 周充值总金额可能达到[已去除电话]万

4.3 业务建议

1. 高峰时段运营

• 15时、9时、1时作为重点运营时段
• 在这些时间段提供特殊优惠或活动

2. 用户增长策略

• 分析新用户转化路径
• 优化新用户充值引导机制

3. 产品优化

• 研究用户充值行为特征
• 根据高峰时段调整产品功能和运

营策略

5. 数据质量与局限性

• 仅基于4周数据，长期趋势还需进一步验证
• 建议持续监控和更新预测模型

结论

充值事件呈现快速增长态势，用户基数和充值金额都有显著提升。建议密切跟踪用户行为，及时调整运营策略。

Redshift MCP Server分析方式

上述测试方式中显式声明了具体需要查询数据库的名称，这是因为数据库名称为testdb，定义不明确，建议在生产环境中使用与业务紧密相关的数据库/表名称，或通过注释声明，或在系统提示词中添加定义以减少工具调用次数并且提高准确率。同时，我们在提示词中没有声明具体需要查询的表，因为表名称定义清晰，在下面的日志内容分析中可以更加清楚的看到Redshift MCP Server的工具调用过程中，AI可以明确的找到所需要的charge_events表。

根据Redshift MCP Server的工作流可以知道主要的工作为：

AgentCore Runtime日志内容分析

您可以根据以下日志内容分析详细了解到Redshift MCP Server中的工具被调用执行的具体逻辑。

1. list_cluster

2. list_databases

3. list_schemas

4. list_tables & list_columns

根据前面的查询结果确定charge_events表并分析充值事件，同时调用了list_columns工具查看charge_events表结构，表结构输出不在这里详细展示。

5. execute_query

大语言模型根据上述输出内容完成text2sql生成对应的sql语句，并调用execute_query工具执行，在执行过程中会根据返回的结果调整sql语句直到输出符合预期。

最终根据查询的结果和提示词生成详细的事件分析报告

总结

本项目成功构建了基于 Amazon Bedrock AgentCore Runtime 的智能数据分析系统，通过集成游戏业务的多维度事件数据，实现了从自然语言查询到业务洞察输出的完整闭环。总体技术核心优势如下：

• Amazon AgentCore Runtime：提供企业级无服务器托管环境，内置 CloudWatch 集成和分布式追踪，支持Sessions > Traces > Spans 三层监控体系，便于生产环境的性能优化和问题排查，同时通过 CodeBuild 实现云端构建和一键部署，支持快速迭代，让开发者专注业务逻辑而非基础设施运维。
• Strands Agents SDK + Redshift MCP Server：从单纯的”查询生成”升级为”洞察发现”，具备智能化数据探索、上下文感知分析、业务导向输出和错误自愈能力。并且Strands Agents SDK仅需几行代码即可通过集成任意 MCP Server，同时支持框架原生工具的快速开发，为开发者提供了从快速原型到生产部署的完整工具生态集成能力。

通过 AgentCore Runtime 的企业级托管能力与 Strands Agents SDK+ Redshift MCP Server的智能化工具生态深度融合，本项目展现了从传统数据查询向 AI 驱动的业务洞察分析转变的技术路径，为企业级智能数据分析应用提供了完整的云原生解决方案。

*前述特定亚马逊云科技生成式人工智能相关的服务目前在亚马逊云科技海外区域可用。亚马逊云科技中国区域相关云服务由西云数据和光环新网运营，具体信息以中国区域官网为准。

本篇作者

---