小型 DevOps 团队如何为德铁的 SaaS 产品解锁分析功能

作者：Ben Freiberg 和 Oliver Jgle，发布时间：2024 年 1 月 12 日，发表于 Amazon Aurora，Amazon QuickSight，Analytics，AWS 数据库迁移服务，客户解决方案，[中级 (200)](https//awsamazoncom/blogs/database/category/learninglevels/intermediate200/查看所有中级200的文章。

关键要点

德铁的 Curbside Management 团队推出了一款以浏览器为基础的 SaaS 产品，帮助城市管理微型出行的停车治理。该团队面对着缺乏数据分析能力的挑战，因此寻求 AWS 的原型参与进行快速解决方案的开发。他们最终利用 AWS 的工具构建了一个自动化的数据管道，使交通数据的获取和分析成为可能。

在当今的城市交通环境中，人们越来越倾向使用电动滑板车或自行车，而非选择步行或乘坐公共交通。随着这一趋势的发展，交通管理中的一个问题逐渐凸显：用户往往不在意他们的交通工具停放在哪里，这就给他人带来了不便。此时，路边管理的概念应运而生，帮助城市或地方政府管理停车位、驾驶行为，对违规行为进行处罚，并实时观察车辆的分布情况。根据收集到的数据，相关的基础设施如停车位、道路和自行车道也可相应进行规划。

我们来自 德铁路边管理 的团队提供了一款基于浏览器的 SaaS 产品，旨在降低相关机构对于微型出行管理的门槛。然而，直到最近，我们的产品只能满足一些基本的监管需求，对于分析性问题的支持则十分有限，比如某个区域过去一周的可用情况或某个观察区出发的行程时长等。这些问题的答案需要依赖大量数据，并以灵活易懂的方式呈现。在此文中，我们将详细描述团队所面临的挑战以及我们为解决这些需求而构建的方案。

AWS 最近发布了 ZeroETL 集成的 Aurora PostgreSQL 功能，使得将事务性数据无缝集成到数据仓库以进行分析成为可能，但在我们开始此项目时，这项能力尚未推出。

背景

我们的开发团队属于一个 DevOps 团队，不仅负责业务功能开发，还需运营整个服务。由于团队规模较小，我们力求保持操作上的低复杂度。

在探索车辆分析的过程中，我们意识到需要一种方案来汇总和展示我们已收集的数据，而无须搭建完整的数据基础设施，包括数据仓库、ETL提取、转换与加载工具和分析前端。由于我们团队中缺乏这一领域的专家，因此 AWS 的原型参与方案正符合我们的需求，使我们得以迅速行动。

本篇文章不仅探讨了我们的具体解决方案，同时还讨论了什么是 AWS 原型参与以及为何在早期阶段进行此流程具有重要价值。

挑战

在参与实际合作之前，我们讨论了架构选项，并在架构决策记录 (ADR) 中记录了我们的决定。我们的目标如下：

目标描述解耦将事务性数据的持久性从分析查询工作负载中解耦。高效基础设施提供一个能够高效建模、查询和可视化与车辆相关数据的基础设施。多数据源分析实现使用来自多个数据源的数据的分析和报告。

作为一支小团队，以下是我们的主要驱动力：

维护 基础设施的低维护成本可观察性、补丁管理、扩展等复杂性 整体系统的低复杂度耦合性、技术多样性、可追溯性等上市时间 每个关键绩效指标KPI的低实施成本

针对传统的 ETL 流程，一些解决方案的关键要素显而易见，但它们需要以近实时的方式执行。使用拥有原生集成的 AWS 服务来进行数据提取、分析持久性、数据转换和可视化是最佳的选择。

方案

我们在此方案中使用的关键服务与功能如下：

AWS 数据库迁移服务 (AWS DMS)：这是一个托管迁移与复制服务，可以快速、安全、最低停机零数据丢失地将数据库和分析工作负载迁移到 AWS。Amazon 关系数据库服务Amazon RDS：这是一个托管的数据库服务，可以轻松在云中设置、运营和扩展关系数据库。Amazon Aurora：这是一种专为云而构建的关系数据库管理系统，完全兼容 MySQL 和 PostgreSQL，提供商业级数据库的性能和可用性，而成本仅为十分之一。Amazon QuickSight：这是一个快速、易用的云计算商业分析服务，可轻松构建可视化、进行临时分析、从数据中快速获取业务洞察，支持任意设备的访问。

接下来的示意图展示了完整解决方案的高层架构及各组件的最适合 AWS 服务。

整套架构中的组件需满足以下职责：

将多个数据库中与报告相关的表实时复制到专用数据库。该次级数据库将分析读取访问负载与事务性性能解耦，并提供存储分析作品的存储库。开发者将分析查询的源设计为具有潜在空间操作的数据库视图。这些视图可在版本控制下定义，并可以针对容器化的 PostgreSQL 进行单元测试。使用一个轻薄层将数据库视图暴露为 REST API，支持添加隐含的访问限制。自定义的 Vuejs 组件根据 REST 封装的数据库视图来构建查询、过滤条件和聚合。如可能，分析小部件可在 Amazon QuickSight 中设计和嵌入。这些小部件包括过滤和聚合数据的选项，并可将选择上下文传递给其他小部件。QuickSight 自身支持行级安全性以对数据进行过滤，集成到前端时可使用不同的机制。使用 QuickSight 创建视觉效果，生成的成果可以通过 AWS 命令行界面 AWS CLI或 API 导出并保存在存储库中。定期调度的作业提取相关数据。Amazon 简单存储服务 (Amazon S3) 被用作长期存储以降低成本，为后续分析提供支持，如使用 Amazon Athena 或 Amazon Redshift Spectrum。

解决方案概述

在与整个团队合作之前，我们与 AWS 的一位架构师评估了所有职责的不同选项，并根据其适用性对其进行了排序。

同时，我们剔除了如 REST API 或 AWS Glue 作业等非关键任务，从而专注于关键结果。最终结果如以下图示所示。

在构建周期间，我们实施了一个自动化管道，以近实时的方式从不同的事务源数据库源数据库 1 和源数据库 2获取和集成地理空间及车辆数据到分析数据库。

我们首先使用 DMS 执行了现有数据的全量加载，然后在源数据库上实施了变更数据捕获 (CDC)，实时将变更复制到分析数据库。目标是 Amazon Aurora Serverless，作为次级持久性存储和分析数据库。这种方案将分析读取访问负载与事务性系统解耦，提供比简单的 PostgreSQL 只读副本更大的灵活性。此次级持久性用于存储和服务仅分析文档。

白鲸加速器安装教程

选择 Aurora 是因为团队已经熟悉 PostgreSQL，并想继续使用 PostGIS 扩展。之所以选择 Aurora Serverless v2，是因为分析查询的复杂性和频率差异很大。Aurora Serverless 可根据需求自动调整容量，费用透明，仅按数据库集群实际消耗的资源收费。

在此次级持久性中，获取的数据被转换和建模以支持使用 PostgreSQL 程序、数据库视图和支持地理空间操作的规则来进行地理空间分析。所有这些作品的源代码都有版本控制，并针对容器化的 PostgreSQL 进行单元测试。变换后的数据随后与参考表进行连接，应用额外的聚合以创建物化表，使得地理空间数据的可视化和分析更加快速。

最终生成的报告表在 QuickSight 中用于创建分析和仪表板，并嵌入在我们的网页应用中。以下截图展示了一个通过几天时间的车辆租赁与归还数据的仪表板示例。还有其他图表对租赁和归还的厂家和车辆类型例如自行车或电动滑板车进行分类。

结论

经过一周紧张的建设过程，能得到经验丰富的 AWS 专家的支持，我们感到非常愉快。在短短 4 天内，我们从多个源数据库构建了一个自动化的近实时数据获取管道，该管道一直延伸到嵌入我们网页应用中的仪表板。这些仪表板帮助我们的设计师更好地理解数据，并支持业务决策的制定。

能在仅 4 天内看到解决方案被构建在我们的应用中非常令人惊叹。此外，有一个关键的洞察是，在完全实施系统之前，我们无法获得的。系统能够回答我们一开始定义的查询，但在不改变原始数据持久化方式的情况下，无法扩展到更通用的查询。

与 AWS 一起，我们设计了一种基于事件源的升级系统，目前我们正在进行测试。得到 AWS 的支持并快速进行实验对我们至关重要。当我们规划应用的主要部分时，我们非常希望再次进行 AWS 原型参与！

关于作者

Ben Freiberg 是亚马逊网络服务 (AWS) 的高级解决方案架构师。他为大型企业客户提供服务，帮助他们在 AWS 上设计、架构和创新高可扩展性和高抗灾性的解决方案。

Oliver Jgle 是 DB Systel 的软件开发者和架构师，热衷于业务解决方案。目前，他着重于解密复杂的无限数据流，并将其转化为可操作的洞察。