如何通过事件驱动的 Amazon Red
MuleSoft 如何通过事件驱动的 Amazon Redshift 湖仓架构实现云卓越
作者 : Sean Zou, Terry Quan, Audrey Yuan, Avijit Goswami, Rueben Jimenez
日期 : 2025年1月28日
发布于 : 、、、、、、
关键要点
- MuleSoft受益于事件驱动架构，利用AWS服务实现了云基础设施的优化与可扩展性。
- 通过建立湖仓架构，MuleSoft能够提供接近实时的数据分析并能够迅速满足业务需求。
- 采用多种技术（如文件分区、Amazon Redshift 和物化视图）来改进存储和查询性能。
在我们之前的思想领导博客文章中，我们定义了一个COE框架，展示了MuleSoft实施该框架的原因及所获得的好处。在这篇文章中，我们将深度探讨MuleSoft如何利用、、、和实现这一目标。
解决方案概述
MuleSoft的解决方案是建立在AWS服务之上的湖仓架构，支持一个门户以实现近乎实时的分析。我们采用事件驱动的策略来触发AWSGlue工作，刷新物化视图。这种分层方法包括数据收集、准备和增强，使识别影响数据准确度的领域变得简单明了。
删除)
对于MuleSoft的湖仓端到端解决方案，以下阶段至关重要：
- 准备阶段
- 增强阶段
- 行动阶段
下面我们将详细讨论这些阶段。
准备阶段
在准备阶段，我们利用COE框架与利益相关者进行沟通，以确定业务目标并识别要摄取的数据源。这些数据源包括云资产清单、和。摄取的数据在湖仓中进行处理，以实现Well-Architected柱的有效实施，包括利用率、安全性和合规性状态检查和措施。
如何将 CUR 数据和 Trusted Advisor 数据配置到 S3？
配置过程涉及多个组件，以存储 CUR 和 Trusted Advisor 数据。对于 CUR 设置，客户需要配置一个 S3 桶，用于接收 CUR报告，客户可通过选择现有桶或创建新桶进行配置。该 S3 桶需要应用策略，客户还必须指定 S3 路径前缀，以便为 CUR 文件传递创建子文件夹。
Trusted Advisor 数据使用 Kinesis Firehose 将客户摘要数据传递到支持数据湖 S3 桶中。数据摄取过程使用 Firehose缓冲参数（1MB 缓冲区大小和60秒缓冲时间）管理数据流向 S3 桶的过程。
Trusted Advisor 数据存储为 JSON 和 GZIP 格式，遵循特定的文件夹结构，每小时进行分区，格式为“YYYY-MM-DD-HH”。
MuleSoft使用AWS托管服务和数据摄取工具从多个数据源提取数据，并支持自定义集成。用于收集云基础设施信息，它可以连接多个基础设施数据源，并将数据放入AmazonS3 桶中。提供了一个集成层，能够与许多数据源（如本地、SaaS和行业现成软件）进行集成。则用于云资源管理和自动修复的能力及自定义操作。
增强阶段
增强阶段包括将原始数据通过管道与我们的业务目标对齐，摄取到湖仓中，并将数据整合为单一视图。
管道采用事件驱动架构，包括 EventBridge、Amazon Simple Queue Service (AmazonSQS)和，提供近乎实时的数据分析。当新数据到达源桶时，EventBridge规则捕获新对象的创建，触发 AWS Glue 工作流，包括AWS Glue爬虫和ETL任务。此外，我们还配置了来发送消息到SQS队列，确保管道只能处理新数据。
AWS Glue ETL 任务对数据进行清洗和标准化，使其可以使用 Amazon Redshift进行分析。为处理复杂结构的数据，另外的处理步骤将嵌套数据格式展平为关系模型。展平步骤还会将AWS资产的标签从嵌套JSON对象中提取出来，转换为单独的列，从而增强了标签强制控制和所有权归属。这些基础设施数据的所有权归属提供了可追溯性，使团队对其云资产的成本、利用率、安全性、合规性和修复负责。其中一个重要标签是资产所有权，该数据可通过 SQL 脚本归属到相应的所有者。
一旦工作流完成，来自不同源且结构多样的原始数据将集中存储在数据仓库中，从此不相关的数据便可进行整合，转化为可执行的智能，以符合Well- Architected的要求并实现业务逻辑。
增强阶段的解决方案
在增强阶段，我们面临许多存储、效率和可扩展性挑战，考虑到数据的庞大体量。我们使用了三种技术（文件分区、Redshift Spectrum和物化视图）来解决这些问题，并在不妨碍性能的前提下进行扩展。
文件分区
MuleSoft的基础设施数据以文件夹结构存储：年份、月份、日期、时间、账户和区域在一个 S3 桶中，因此AWS Glue爬虫能够自动识别并将分区添加到AWS Glue数据目录。分区显著提高了查询性能，因为它优化了查询的并行处理。每个查询扫描的数据量基于分区键进行限制，从而减少了总体数据传输、处理时间和计算成本。虽然分区是一种优化技术，有助于提高查询效率，但在使用这项技术时需考虑两个关键点：
- 数据目录每个表的最大分区限制为1000万个
- 随着分区的快速增长，查询性能会受到影响
因此，在数据目录表中平衡分区数量和查询效率至关重要。我们决定实施3个月的数据保留策略，并配置生命周期规则，过期任何超过此期限的数据。
我们的事件驱动架构 — AWS Eventbridge 事件在对象放入或从 S3 桶中移除时激活，事件消息通过 S3 事件通知发布到 SQS 队列，触发 AWS Glue 爬虫，根据消息处理分区清理，添加新分区或移除旧分区。
Amazon Redshift 和并发扩展
MuleSoft 使用 Amazon Redshift 查询 S3 中的数据，因为它提供大规模计算并减少数据冗余。MuleSoft 还采用了 AmazonRedshift 的并发扩展，以在保持快速查询性能的同时运行并发查询。Amazon Redshift会在几秒钟内自动添加查询处理能力，以处理高数量的并发查询，而不会产生延迟。
物化视图
我们使用的另一项技术是 Amazon Redshift的物化视图。物化视图存储预设的查询结果，以便未来的类似查询使用，从而跳过许多计算步骤。因此，相关数据能够高效访问，优化查询性能。此外，物化视图可以自动和增量刷新。因此，我们可以实现我们云基础设施中的单一视图，提供最新的预测、趋势和可操作的见解，改善查询性能。
Amazon Redshift 物化视图在 MuleSoft 的 Cloud Central门户中被广泛用于报告，但如果用户需要深入了解更细致的视图，他们可以引用外部表。
目前，MuleSoft 通过事件驱动架构手动刷新物化视图，但正在评估切换到自动刷新。
行动阶段
利用 Amazon Redshift 中的物化视图，我们在 Tableau 中开发了一个自助服务的 Cloud Central门户，为每个团队、工程师和经理提供一个展示门户，提供指导和建议，帮助他们按照组织的要求、标准和预算进行操作。经理们能够获得监控和决策的信息，工程师能够识别和标记缺少强制标记信息的资产，并修复不合规的资源。门户的一个关键特征是个性化，这意味着门户能够根据管理员或工程师的登录信息填充可视化和分析。
Cloud Central 还帮助工程团队提高在六个 Well-Architected支柱中的云成熟度：运营卓越、安全性、可靠性、性能效率、成本优化和可持续性。团队通过展示“可能的艺术”，对 100 和 200 个 Well- Architected 支柱查询进行概念验证。以下截图展示了MuleSoft 实现的门户 CloudCentral，其他公司会根据自身的用例和需求设计更具个性化的门户。
Leave a Reply