Modernizing financial analytics with Amazon SageMaker Unified Studio

通过 Amazon SageMaker Unified Studio 现代化金融分析 | AWS 架构博客

Avanse Financial Services 是印度领先的教育贷款提供商之一。他们的数据工程团队使用 Amazon Simple Storage Service（Amazon S3）、Amazon Athena 和 AWS Glue 在 AWS 上构建了一个数据湖，用于数据的摄入和处理。然而，他们的分析和报告层运行在一个与 AWS 未集成的外部分析应用程序上。在分析师能够运行任何报告之前，数据必须从 Amazon S3 复制到该外部应用程序中，其许可证消耗了他们预算的很大一部分，尽管使用率很低，而且与 AWS 服务的每次集成都需要自定义构建的管道。

在评估了他们的选项后，Avanse 迁移到了使用 Amazon SageMaker Unified Studio 的云原生湖仓架构，该架构在 AWS 上的单一受控环境中统一了他们的数据工程、分析和人工智能（AI）工作流程。在本文中，我们将介绍他们的迁移历程，以便您能够将他们的方法应用到自己的环境中。

为什么 Avanse 选择现代化

他们 AWS 数据湖与外部分析应用程序之间的分离造成了五个问题：

• 每日数据同步瓶颈。在分析师能够查询数据之前，每个报告都需要从 Amazon S3 向外部分析应用程序进行 4 小时的批量复制。业务决策基于至少一天前的数据。

• 固定的许可成本与使用情况脱节。外部分析应用程序无论分析师运行多少查询，都收取年度费用。Avanse 需要基于使用情况的定价，与他们实际消耗的资源匹配，而不是为未使用的容量支付固定费用。

• 可审计性有限。外部分析应用程序运行在一个共享服务器上，不同的业务部门（风险、催收、投资组合管理）共享相同的资源。它缺乏细粒度的审计跟踪，使得难以追踪谁在何时访问了哪些数据，或按团队分配成本。

• 没有集中化的数据发现。虽然 AWS Glue Data Catalog 管理了数据湖的模式元数据，但外部分析应用程序无法访问它。在该应用程序中工作的分析师依赖文件夹结构和手动文档来查找正确的数据集，这减缓了入职过程，并增加了使用过时数据的风险。

• 与 AWS 服务断开连接。外部分析应用程序无法直接查询 Amazon S3 中的数据，也无法原生使用 AWS Glue 目录。每个数据流都需要连接器和自定义构建的管道，增加了维护开销。

此外，一些数据集存储在 Amazon S3 之外的网络文件系统（NFS）存储上，形成了另一个需要整合的数据孤岛。

Avanse 选择 Amazon SageMaker Unified Studio，因为它解决了所有五个挑战：直接查询 Amazon S3 中的数据以避免同步，通过 Amazon Athena 和 Amazon EMR Serverless 实现基于使用情况的计算，基于项目的隔离和按项目计费，通过 AWS IAM Identity Center 进行血缘跟踪，以及与现有 AWS 服务的原生集成。

解决方案概述

核心架构的变更是从双应用程序模型迁移到单一集成堆栈：

旧架构

Avanse 的数据摄入和处理运行在 AWS（Amazon S3、AWS Glue、Athena）上，但分析和报告则运行在外部的分析应用程序中。每天必须将数据批量复制到这个外部应用程序中，分析师才能对其进行查询。每个系统都有自己的访问控制，它们之间没有共享的目录或血缘追踪。

新架构

现在，分析可以直接在 Amazon S3 中的数据上运行，通过 Amazon SageMaker Unified Studio。没有数据复制的步骤。分析师使用 Athena 进行 SQL 查询，使用 EMR Serverless 进行大规模处理，查询的是摄入管道生成的相同数据。通过 IAM Identity Center 和 SageMaker Catalog 对治理、访问控制和血缘进行集中管理。

下图说明了目标架构。它遵循湖仓一体模式，在 Amazon S3 上以开放格式存储数据，同时保持 ACID 事务支持，以满足金融监管机构对一致性的期望。

该架构有三个层次：

• 数据层 – Amazon S3 以开放格式（Parquet、Delta Lake）存储数据，并使用 S3 Intelligent-Tiering 进行自动成本优化。AWS Glue Data Catalog 维护模式元数据，使数据在各种工具中可被发现。

• 计算层 – Amazon SageMaker Unified Studio 提供基于项目的、按业务功能组织的工作空间。Collections 使用内置的 SQL 查询编辑器（由 Athena 提供支持），Risk Reporting 使用 JupyterLab 进行交互式分析，MIS 通过 Amazon EMR Serverless 运行大规模的 Spark 作业。AWS Glue ETL 处理数据转换，AWS Lambda 提供事件驱动的触发器用于报告生成。对于机器学习（ML）工作负载，Amazon SageMaker AI 支持模型训练和部署，Amazon Bedrock 提供生成式 AI 能力，例如增强风险叙事。

• 治理层 – IAM Identity Center 提供跨工作空间的 SSO 和审计日志。SageMaker Catalog 作为业务术语表，提供数据血缘追踪和访问控制。Amazon DataZone 通过一个通用的元数据层连接各个组件。

迁移之旅

Avanse 采用了一个五阶段的方法。时间线可以根据您的环境进行调整，但从验证到生产部署的系统性推进是关键。

第一阶段：技术验证（72 小时研讨会）

Avanse 从一个聚焦的 72 小时研讨会开始，使用隔离的 SageMaker 环境，开发人员可以在其中进行实验而不会影响生产环境。他们的团队测试了 SQL 分析与现有的 Athena 表，并验证了 Python 和 PySpark 是否能够复制现有的分析工作流程。

团队确认直接在 Amazon S3 中查询数据完全解决了他们的同步瓶颈。每天 4 小时的数据复制不再需要，这验证了迁移方法的可行性。

第二阶段：数据迁移和存储优化

Avanse 将数据集从 NFS 存储和旧的分析格式迁移到 Amazon S3，将数据集中到一个位置。他们实施了 S3 Intelligent-Tiering，根据使用模式自动在访问层级之间移动数据，从而在不影响检索性能的情况下优化成本。

他们用 SageMaker 统一工作室中的原生 Athena 工作组替换了传统的分析连接器，完全避免了数据同步。源数据仍然存储在 Amazon S3 中，可以通过 Athena SQL 和 SageMaker 笔记本进行查询，从而建立了单一的数据来源。

第三阶段：计算现代化

Avanse 从共享的分析服务器迁移到了基于项目的隔离环境，使用 SageMaker 统一工作室。每个业务功能（风险报告、催收、管理信息）都获得了自己的项目，其中运行 JupyterLab 的专用计算空间。项目特定的 IAM 执行角色提供了访问控制和按业务单元分配成本的功能。

现在，通过一个基于浏览器的 URL 并结合多因素认证（MFA），用户可以访问内置查询编辑器的 SQL 分析、JupyterLab 笔记本中的机器学习开发，以及通过 Amazon EMR Serverless 进行的大数据处理。这取代了之前需要安装本地分析客户端的需求。

第四阶段：治理实施

Avanse 部署了 SageMaker Catalog 作为其核心业务数据目录。现在，分析师可以通过语义搜索发现已批准的数据集，而不再需要浏览文件夹结构或依赖手动文档。他们将技术上的 Athena 表名映射到业务术语。例如，分析师搜索“催收效率”时，可以找到相关的表格，包括描述、模式和血缘信息。

血缘追踪将风险报告中的每个指标回溯到源表、转换和中间数据集。每个操作（笔记本执行、SQL 查询、数据访问）都与 IAM Identity Center 用户相关联，为合规团队创建了所需的全面审计跟踪。

第五阶段：用例迁移

Avanse 没有尝试一次性迁移，而是逐步迁移关键工作流程：

投资组合 MIS（月度/双周）

以前需要每天花费 4 小时将数据从 Amazon S3 复制到外部分析应用程序，然后才能开始生成报告。Avanse 完全跳过了数据同步步骤，现在通过直接在 Amazon S3 中查询现有的 Athena 表来生成 MIS 报告。由于源数据已经在 AWS 上，因此不需要使用外部应用程序进行此活动。报告生成时间从数小时减少到不到 30 分钟。

催收效率和反弹率计算

将用于计算催收效率和反弹率等指标的复杂传统分析流程迁移至基于事件驱动的处理，使用 AWS Glue ETL、AWS Lambda 和 PySpark 作业进行大规模数据聚合。无服务器执行模型仅按实际消耗的计算时间收费。

EDW 风险报告

以前，大规模的监管性企业数据仓库资产连接作为传统计划任务运行。现在，这些操作作为 SQL 查询在 SageMaker 统一工作室的查询编辑器中运行，分析师可以按需执行这些查询，或通过 Athena 工作组进行计划。分布式查询引擎处理跨数百万行的复杂多表连接。

评分卡生成

模型构建从外部分析应用程序迁移至 SageMaker AI 工作流。数据科学家使用 JupyterLab 和 Python 库进行开发，并直接将模型部署到 SageMaker 端点，避免了在不同环境之间移动数据。

一个技术挑战是代码迁移。Avanse 的分析代码库包含了多年积累的专有脚本和程序。直接逐行翻译并不现实。相反，他们采取了务实的方法：基本的数据转换迁移到 Athena 中的 SQL，复杂的业务逻辑则用 PySpark 重写以实现可扩展性，统计过程则用 pandas 和 scikit-learn 等 Python 库替代。这种方法的重点是关注代码所实现的功能，然后使用云原生模式进行实现。

另一个技术挑战是性能验证。团队需要确认从 Amazon S3 查询数据的性能是否能与外部分析应用的内存处理相媲美。使用 Athena 查询 Amazon S3 中格式为 Parquet 的数据，在标准报告工作负载下表现出相当的性能，同时完全避免了每天 4 小时的数据同步步骤。对于涉及数百万行的大型监管连接查询，Amazon EMR Serverless 提供了分布式 Spark 处理，能够在几分钟内完成，而不是外部应用所需的数小时。

关键成果

领域

结果

授权费用

完全避免了外部分析应用的费用

存储费用

通过 S3 智能分层（S3 Intelligent-Tiering）减少了存储费用，该功能可根据使用模式自动在不同访问层级之间移动数据

报告生成

从超过 4 小时（包括从 Amazon S3 向外部分析应用同步数据）缩短到不到 30 分钟（通过直接查询 Amazon S3）

合规审计

从需要数周的手动调查缩短到几天，通过自动生成的血缘报告实现

计算费用

基于使用情况的无服务器模型替代了持续运行的外部分析基础设施

协作

为数据科学家、分析师和工程师提供统一的基于浏览器的环境

“通过采用 SageMaker 统一工作室，我们数据团队消除了遗留的授权费用，通过无服务器、基于使用情况的模型减少了存储和计算成本，并加快了定期报告的生成。同时，我们通过缩短审计时间并统一团队在一个高效的数据环境中，实现了合规性和协作性的提升。” —— Komal Thakkar，高级副总裁兼数据工程主管，Avanse 金融服务

最佳实践

根据他们的经验，Avanse 建议：

• 从工作坊开始。在承诺全面迁移之前，先进行为期 72 小时的技术验证，以确认您的具体使用案例。

• 迁移使用案例，而不是代码。关注您的分析实现了什么，然后使用云原生模式进行实现，而不是逐行翻译遗留脚本。

• 早期投资治理。从第一天起就实施数据目录和血缘追踪。

• 采用基于项目的隔离。围绕业务功能进行组织，以实现清晰的成本分配和安全边界。

• 记录业务逻辑。利用迁移机会，将未记录的知识捕获到业务术语表和数据集描述中。

Avanse 从外部分析应用程序迁移到 Amazon SageMaker Unified Studio，将他们的分析堆栈整合到 AWS 上的单一集成环境中。通过直接在 Amazon S3 中查询数据，而不是将其复制到外部应用程序中，他们缓解了最大的运营瓶颈。基于项目的隔离取代了共享服务器模型，使每个业务部门都能独立使用计算资源并清晰地看到成本。通过 SageMaker Catalog 和 IAM Identity Center 的集中治理，他们的合规团队获得了之前缺失的审计追踪。

无服务器、基于使用量的模型意味着 Avanse 不再需要为闲置的容量付费。湖仓架构支持新出现的分析模式，并且与 AWS 服务的原生集成（包括通过 Amazon Bedrock 的生成式 AI）使他们能够随着需求的变化采用新的功能。

下一步

通过安排一个 72 小时的技术验证研讨会，开始你的分析现代化之旅。联系你的 AWS 账户团队，讨论你的迁移方法。

如需更多信息，请参阅：

• 使用 Amazon SageMaker Unified Studio 统一数据、分析和 AI

• AWS 分析参考架构

• 在 AWS 上构建湖仓架构

• 什么是 Amazon DataZone？