亚马逊AWS官方博客

深入探讨 RedBus 的数据平台以及他们如何利用 Amazon QuickSight 加速业务洞察

本文与 redBus 的 Girish Kumar Chidananda 共同撰写。

redBus 是印度最早采用 AWS 的公司之一,其大部分服务和应用程序都托管在 AWS Cloud 上。AWS 为 redBus 提供了快速扩展基础设施的灵活性,同时将成本保持在极低水平。AWS 提供了全套服务来满足他们的大部分需求,包括提供 redBus 可以信赖的客户支持。

在这篇文章中,我们分享了 redBus 的数据平台架构,以及如何连接各种组件以形成其数据骨干通路。我们还讨论了 redBus 在为其实时商业智能(BI)使用场景构建控制面板时面临的挑战,以及他们如何使用 Amazon QuickSight 这一高速、易用的云端业务分析服务,让 redBus 的所有员工能够随时使用任意设备,轻松构建可视化内容和执行临时分析,从其数据中获得业务洞察。

关于 redBus

redBus 是全球最大的线上巴士票务平台,成立于印度,为全球超过 3600 万名客户提供令人满意的服务。在其公交票务垂直领域之外,redBus 还提供名为 redRails 的铁路票务服务和名为 rYde 的大巴和轿车租赁服务。该公司隶属于 GO-MMT 集团,这是印度领先的在线旅游公司,旗下拥有广泛的品牌组合,包括 MakeMyTrip 和 Goibibo 等知名的在线旅游品牌。

redBus 的数据骨干通路 1.0

redBus 在各个级别上都高度依赖于制定数据驱动的决策,包括旅客的行程跟踪、预测交通高峰期间的需求、识别和解决大巴运营商注册流程中的瓶颈等等。随着 redBus 的业务不断发展,其运营所涉的城市和国家/地区数量在增加,每个城市使用其服务的大巴运营商和旅客数量也在增长,随之而来的是传入数据量的增加。他们需要在一个位置访问和分析数据,这就需要构建自己的数据平台,如下图所示。

redBus 数据平台 1.0

在以下部分中,我们将更详细地介绍每个组件。

数据摄取来源

在数据平台 1.0 中,数据从多种来源摄取:

  • 实时 – 实时数据流的来源多种多样,包括 redBus 的移动应用程序、后端微服务,以及乘客、大巴运营商或应用程序执行的任何操作,例如预订大巴车票、搜索大巴清单、上传 KYC 文档等
  • 批处理模式 – 定时任务从多个持久数据存储中提取数据,例如存储来自其所有应用程序的 OLTP 数据的 Amazon Relational Database Service(Amazon RDS),存储来自各家运营商的大巴清单的 Apache Cassandra 集群,以及存储用户身份图的 Arango DB 等

数据编目

实时数据将会摄取到他们自行管理的 Apache Nifi 集群,这是一个开源数据平台,他们使用该平台的路由功能对数据进行清理、分析和编目,然后再将数据发送到目标。

存储和分析

redBus 使用以下服务来满足其存储和分析需求:

  • Amazon Simple Storage Service(Amazon S3)是一种对象存储服务,其几乎无限的可扩展性和更高的持久性为数据湖奠定了基础。实时数据来自 Apache Druid,数据存储的数据按计划以固定间隔传入。
  • Apache Druid 是一种 OLAP 风格的数据存储(数据通过 Kafka Druid 数据加载器流入),它在数据加载过程中根据各种维度计算事实和指标。
  • Amazon Redshift 是一种云数据仓库服务,可帮助您分析 EB 级数据和运行复杂的分析查询。redBus 使用 Amazon Redshift 存储来自 Amazon S3 的处理后数据和来自 Apache Druid 的聚合数据。

查询和可视化

为了使 redBus 尽可能实现数据驱动的决策,他们确保了 SRE 工程师、数据工程师和业务分析师都可以通过可视化层访问数据。该层配有控制面板,使用 Apache SuperSet(开源数据可视化应用程序)和 Amazon Athena(交互式查询服务,使用标准 SQL 分析 Amazon S3 中的数据)向其提供服务,以满足临时查询需求。

挑战

最初,redBus 处理数据的速度是每天摄取 1000 万个事件。随着时间的推移,公司业务开始增长,数据量(从 GB 到 TB 再到 PB)、每天的数据摄取量(从 1000 万增长到 3.2 亿个事件)及其商业智能控制面板需求也随之增长。不久之后,他们自行管理的 Superset 的 BI 功能开始面临着挑战,运营复杂性与日俱增。

BI 能力有限

redBus 遇到了以下 BI 限制:

  • 无法从多个数据来源创建可视化 – Superset 不允许从其数据探索层内的多个表创建可视化内容。redBus 数据工程师必须在数据来源级别本身,预先将表联接起来。为了面向 redBus 的业务利益相关者创建 360 度全方位视图,数据工程师需要维护多个表来支持可视化层,这带来了诸多不便之处。
  • 控制面板中没有用于可视对象的全局筛选器 – Superset 不支持控制面板中可视对象的全局或主筛选器。例如,假设控制面板中的可视对象有按地区划分的销售赢单数、按地区划分的年初至今营收、按地区划分的销售管道等,然后在控制面板中添加了“地区”筛选器,其值为 EMEA、APAC 和 US。“地区”筛选器仅应用到其中一个可视对象,而不是整个控制面板。但是,控制面板用户希望在整个控制面板上进行筛选。
  • 对业务用户并不友好的工具 – 在定制设置方面,Superset 高度以开发人员为中心。例如,如果 redBus 业务分析师需要自定义定时刷新,以根据预设值自动重新查询控制面板上的每个切片,则分析师必须更新控制面板的 JSON 元数据字段。因此,要在可视对象或控制面板上进行任何自定义,都必须了解 JSON 及其语法。

运营成本增加

虽然 Superset 是开源的,没有许可成本,但同时也意味着需要花费更多的精力,来维护将该服务作为企业级 BI 工具运行时所需的全部组件。redBus 部署并维护了一个 Web 服务器(Nginx),其前端为一个应用程序负载均衡器,用于进行负载平衡;一个元数据数据库服务器(MySQL),供 Superset 在其中存储用户、切片和控制面板定义等内部信息;一个异步任务队列(Celery),用于支持长时间运行的查询;一个消息代理(RabbitMQ);以及一个分布式缓存服务器(Redis),用于在 Amazon Elastic Compute Cloud(Amazon EC2)实例上缓存结果、绘制数据图表等。下图展示了这种架构。

redBus 的 Apache Superset 部署

redBus 的 DevOps 团队必须完成繁重的工作,包括预置基础设施、进行备份、根据需要手动扩展组件、单独升级组件等等。它还要求有 Python Web 开发人员辅助进行配置更改,这样所有组件才能无缝协同工作。所有这些手动操作都增加了 redBus 的总拥有成本。

转向 QuickSight 的旅程

一开始,redBus 主要围绕多个控制面板需求探索 BI 解决方案:

  • 面向业务利益相关者和分析师的 BI 控制面板,通过 Amazon S3 和 Amazon Redshift 获取数据。
  • 实时应用程序性能监控(APM,Application Performance Monitoring)控制面板,可帮助其 SRE 工程师和开发人员确定微服务部署中问题的根本原因,这样他们就可以尽快修复问题,避免影响客户体验。该控制面板通过 Druid 获取数据。

QuickSight 符合 redBus 的大部分 BI 控制面板需求,他们的数据平台团队针对几个复杂控制面板,快速启动了概念验证(POC,Proof Of Concept)。在历时一个月的 POC 结束时,团队分享了他们的发现成果。

首先,QuickSight 具有下列丰富的 BI 功能:

  • 这是一款具有拖放功能的自助式 BI 解决方案,可以帮助 redBus 分析师轻松使用,无需完成任何编码工作。
  • 在单个控制面板中对来自多个数据来源的数据进行可视化,可以帮助 redBus 业务利益相关者在单一控制面板中获取销售的 360 度全方位视图、进行预测和获取洞察。
  • 对于 redBus 的 BI 需求,在控制面板中跨可视对象和跨表单执行级联筛选是急需的功能。
  • QuickSight 提供类似 Excel 的可视对象,即带有计算功能的表格、带有单元格分组的数据透视表,以及富有吸引力的样式。
  • QuickSight 中的超快并行内存计算引擎(SPICE,Super-fast, Parallel, In-memory Calculation Engine)可以帮助 redBus 扩展到成千上万的用户,而这些用户可以同时跨各种 AWS 数据来源快速执行交互式分析。
  • 利用无需额外成本、现成可用的机器学习洞察和预测,redBus 的数据科学团队在处理销售预测和类似模型外,还可以将精力集中在机器学习模型上。
  • 利用内置的行级别安全性(RLS),redBus 可以为查看者授予筛选访问权限。例如,redBus 有许多业务分析师,分别管理不同的国家/地区。使用 RLS,每位业务分析师可以在单个控制面板中,只查看与其指定国家/地区相关的数据。
  • redBus 使用 OneLogin 作为其身份提供商,它支持安全断言标记语言 2.0(SAML 2.0)。在 QuickSight 的身份联合验证和单点登录支持的帮助下,redBus 可以为其 QuickSight 用户提供简单的登录流程。
  • QuickSight 提供内置警报和电子邮件通知功能。

其次,QuickSight 是 AWS 提供的完全托管式云原生无服务器 BI 服务,具有以下特点:

  • redBus 工程师无需浪费精力在 EC2 实例上完成繁重的 BI 解决方案预置、扩展和维护工作。
  • QuickSight 提供与 Amazon Redshift、Amazon S3 和 Athena 等 AWS 服务以及其他流行框架(如 Presto、Snowflake、Teradata 等)的原生集成。QuickSight 可以连接到 redBus 既有的大多数数据来源,但 Apache Druid 除外,因为截至 2022 年 12 月尚未提供与 Druid 的原生集成。有关支持的数据来源的完整列表,请参阅支持的数据源

成果

考虑到各种丰富的功能和较低的总拥有成本,redBus 选择 QuickSight 来满足他们的 BI 控制面板需求。借助 QuickSight,redBus 的数据工程师很快便构建了许多控制面板,利用 PB 级数据,向业务利益相关者和分析师提供洞察。redBus 数据骨干通路的演进为公司中更广泛的受众提供了性能更好、价值实现时间更短的商业智能。截至 2022 年 11 月,该服务结合了面向业务用户的 QuickSight 和用于实时 APM 控制面板的 Superset(在撰写本文时,QuickSight 尚未提供 Druid 的原生连接器),如下图所示。

redBus 数据平台 2.0

销售异常检测控制面板

在 redBus 已部署到生产环境的众多控制面板中,销售异常检测是 redBus 构建的非常让人感兴趣的控制面板之一。它使用 redBus 专有的销售预测模型,而模型获取 Amazon Redshift 表中的历史销售数据以及 Druid 表中的实时销售数据,如下图所示。

销售异常检测数据流

计划作业按照固定的间隔,向 redBus 预测模型提供实时和历史销售数据,然后将预测的数据推送到 Amazon Redshift 表中。所生成的 Amazon Redshift 表为 QuickSight 中的销售异常检测控制面板提供服务。

以下是销售异常检测控制面板的可视对象之一。它使用折线图构建,展示了每小时实际销售额、预测销售额以及 redBus 中特定业务群组在某个时间序列的警报阈值。

特定群组的销售额和预测销售额

在此可视对象中,每个条形表示在该时间序列中特定时间点触发的销售异常数量。

redBus 的分析师可以向下钻取来了解销售详细信息和分钟级别的异常情况,如下图所示。这项向下钻取功能在 QuickSight 中是现成可用的。

向下钻取图 – 特定群组的销售额和预测销售额

有关向 QuickSight 控制面板可视对象添加向下钻取功能的详细信息,请参阅在 Amazon QuickSight 中向可视对象添加向下钻取功能

除了可视对象之外,还有以下非常重要的功能,因此它已成为查看者最喜欢的 redBus 控制面板之一:

  • 由于跨可视对象筛选是 QuickSight 现成可用的功能,因此他们在控制面板中添加了基于时间戳的筛选条件。这可以实现在控制面板中一键筛选多个可视对象。
  • 在可视对象上配置的 URL 操作可帮助查看者导航到与其上下文相关的内部应用程序。
  • 针对 KPI 和 Gauge 可视对象配置的电子邮件警报可帮助查看者及时获得通知。

后续步骤

除了根据其 BI 控制面板需求构建新的控制面板外,redBus 还采取了以下后续步骤:

  • 根据他们的多个应用程序需求探索了 QuickSight Embedded Analytics,帮助用户通过上下文中的数据可视对象、交互式控制面板等等,加快直接在应用程序中获得洞察的速度
  • 探索 QuickSight Q,这可以让他们的业务利益相关者用自然语言提问,并通过相关的可视化对象获得准确的答案,从而帮助他们从数据中获得洞察
  • 随着集成功能的提供,使用 QuickSight 构建涵盖所有数据来源的统一控制面板解决方案

小结

在这篇文章中,我们向您展示了 redBus 如何使用各种 AWS 服务和 Apache 框架构建自己的数据平台,该平台所遇到的挑战(尤其是他们的 BI 控制面板需求和扩展时的挑战),以及他们如何使用 QuickSight 并降低总拥有成本。

要了解有关 redBus 工程的更多信息,请查看他们的媒体博客文章。要了解有关 QuickSight 中最新进展的更多信息,或者如果您有任何疑问,请联系 QuickSight 社区,这个非常活跃的社区提供了多种资源。


关于作者


作者:Girish Chidanand
Girish Kumar Chidananda
在 redBus 担任数据工程高级工程经理,在过去的 5 年内,他一直在 redBus 开发各种数据工程应用程序和组件。在开始涉足 IT 行业之前,他曾在多家企业担任机械和控制系统工程师,并拥有巴斯大学流体动力工程硕士学位。


作者:Kayalvizhi Kandasamy
Kayalvizhi Kandasamy
与数字化原生公司合作支持其创新。作为 Amazon Web Services 的高级解决方案架构师(亚太地区),她利用自己的经验帮助人们将想法变为现实,主要侧重于微服务架构和使用 AWS 服务的云原生解决方案。工作之余,她喜欢下棋,是获得国际棋联定级的国际象棋选手。她还辅导女儿们学习国际象棋,并帮助她们为参加各种国际象棋比赛做好准备。