Zoom 基于Apache Hudi 的流式日志处理实践

简介: Zoom 基于Apache Hudi 的流式日志处理实践

在当今的数字时代,日志记录是应用程序开发和管理的一个重要方面,但在遵守数据保护法规的同时有效管理日志可能是一项重大挑战。Zoom 与 AWS 数据实验室团队合作,开发了一种创新架构来克服这些挑战并简化日志记录和记录删除流程。在本文中我们探讨了架构及其为 Zoom 及其用户提供的优势。

应用程序日志挑战:数据管理和合规性

应用程序日志是任何应用程序的重要组成部分;它们提供有关系统的使用和性能的有价值的信息。这些日志用于各种目的,例如调试、审计、性能监控、商业智能、系统维护和安全。然而,尽管这些应用程序日志对于维护和改进应用程序是必要的,但它们也遇到了一个挑战。这些应用程序日志可能包含个人身份数据,例如用户名、电子邮件地址、IP 地址和浏览历史记录,这会引起数据隐私问题。

通用数据保护条例 (GDPR) 和加州消费者隐私法案 (CCPA) 等法律要求组织在特定时间段内保留应用程序日志。数据存储所需的确切时间长度因具体法规和存储的数据类型而异。这些数据保留期的原因是为了确保公司保留个人数据的时间不会超过必要的时间,这可能会增加数据泄露和其他安全事件的风险。这也有助于确保公司不会将个人数据用于收集数据的目的以外的目的,否则可能会违反隐私法。这些法律还赋予个人要求删除其个人数据的权利,也称为“被遗忘权”。个人有权要求删除其个人数据,不得无故拖延。

因此,一方面组织需要收集应用程序日志数据以确保其服务的正常运行,并将数据保留特定时间段。但另一方面,他们可能会收到个人要求从日志中删除其个人数据的请求。这为组织创造了一种平衡行为,因为它们必须遵守数据保留和数据删除要求。

对于在多个国家和州运营的大型组织而言,这个问题变得越来越具有挑战性,因为每个国家和州可能都有自己关于数据保留和删除的规则和条例。例如,加拿大的个人信息保护和电子文件法 (PIPEDA) 和澳大利亚的澳大利亚隐私法与 GDPR 类似的法律,但它们可能有不同的保留期限或不同的例外情况。因此,无论大小,组织都必须驾驭数据保留和删除要求的复杂环境,同时还要确保它们遵守所有适用的法律和法规。

Zoom 的初始架构

在 COVID-19 大流行期间,随着越来越多的人被要求在家工作和上课,Zoom 的使用猛增。该公司必须快速扩展其服务以适应激增,并与 AWS 合作在全球大多数地区部署容量。随着大量应用程序端点的突然增加,他们不得不快速发展他们的日志分析架构,并与 AWS 数据实验室团队合作,为他们的合规性用例快速构建原型并部署架构。

Zoom对数据摄取吞吐量和性能需求非常严格。必须从每分钟产生超过 3000 万条消息的数千个应用程序端点提取数据,每天产生超过 100 TB 的日志数据。现有的摄取管道包括首先通过 Apache Kafka 将数据写入 Apache Hadoop HDFS 存储,然后运行日常作业以将数据移动到持久存储。这花了几个小时,同时也减慢了摄取速度并可能造成数据丢失。扩展架构也是一个问题,因为无论何时添加或删除节点,都必须移动 HDFS 数据。此外,数十亿条记录的事务语义对于帮助满足与合规性相关的数据删除请求是必要的,并且日常批处理作业的现有架构在操作上效率低下。

正是在这个时候,通过与 AWS 客户团队的对话,AWS 数据实验室团队参与进来,协助为 Zoom 的超大规模构建解决方案。

解决方案概述

AWS 数据实验室在客户和 AWS 技术资源之间提供加速的联合工程参与,以创建有形的可交付成果,从而加速数据、分析、人工智能 (AI)、机器学习 (ML)、无服务器和容器现代化计划。数据实验室提供三种服务:构建实验室、设计实验室和常驻架构师。在构建和设计实验室期间,AWS 数据实验室解决方案架构师和 AWS 专家通过提供规范的架构指导、共享最佳实践、构建工作原型和消除技术障碍来帮助满足其生产需求,特别支持 Zoom。

Zoom 和 AWS 团队(以后统称为“团队”)确定了数据摄取和删除的两个主要工作流程。

数据摄取工作流

下图说明了数据摄取工作流。

该团队需要在开发/测试环境中快速填充数百万条 Kafka 消息才能实现这一目标。为了加快流程,我们(团队)选择使用 Amazon Managed Streaming for Apache Kafka (Amazon MSK),这使得实时摄取和处理流数据变得简单,而且我们在不到一天的时间内就启动并运行了。

为了生成类似于生产数据的测试数据,AWS 数据实验室团队创建了一个自定义 Python 脚本,该脚本在多个 Kafka 分区中平均填充超过 12 亿条消息。为了匹配开发帐户中的生产设置,我们必须增加云配额限制。

我们使用 Amazon MSK 和 Amazon EMR 中的 Spark Structured Streaming 功能以高吞吐量和低延迟摄取和处理传入的 Kafka 消息。具体来说,我们将源数据以每 5 分钟 1.5 亿条 Kafka 消息的最大传入速率插入 EMR 集群,每条 Kafka 消息包含 7-25 条日志数据记录。

为了存储数据,我们选择使用 Apache Hudi 作为表格格式。我们选择 Hudi 是因为它是一个开源数据管理框架,可在 Amazon Simple Storage Service (Amazon S3) 等不可变存储层之上提供记录级插入、更新和删除功能。此外,Hudi 针对处理大型数据集进行了优化,并与 Zoom 已经使用的 Spark Structured Streaming 配合得很好。

在缓冲了 1.5 亿条消息后,我们使用 Amazon EMR 上的 Spark Structured Streaming 处理这些消息,并每 5 分钟将数据以 Apache Hudi 兼容的格式写入 Amazon S3。我们首先展平消息数组,从嵌套的消息数组中创建一条记录。然后我们为每条消息添加了一个唯一的主键,称为 Hudi 记录主键。该键允许 Hudi 对数据执行记录级别的插入、更新和删除操作。我们还从传入消息中提取字段值,包括 Hudi 分区键。

该架构允许最终用户使用带有 AWS Glue 数据目录的 Amazon Athena 或使用 Apache Hive 和 Presto 查询存储在 Amazon S3 中的数据。

数据删除工作流程

下图说明了数据删除工作流程。

我们的架构允许高效的数据删除。为了帮助遵守针对 GDPR 删除的客户发起的数据保留政策,计划的作业每天运行以识别要以批处理模式删除的数据。

然后我们启动了一个瞬态 EMR 集群来运行 GDPR upsert 作业来删除记录。数据以 Hudi 格式存储在 Amazon S3 中,Hudi 的内置索引使我们能够使用布隆过滤器和文件范围高效地删除记录。因为只有那些包含记录键的文件需要读取和重写,所以从 10 亿条记录中删除 1,000 条记录只需要大约 1-2 分钟,而这在以前需要数小时才能完成,因为整个分区都被读取了。

总体而言,我们的解决方案实现了高效的数据删除,根据 GDPR 要求,这提供了对 Zoom 至关重要的额外数据安全层。

构建优化规模、性能和成本的架构

在本节中,我们将分享 Zoom 为优化规模、性能和成本而采取的以下策略:

• 优化摄取

• 优化吞吐量和 Amazon EMR 利用率

• 使用 EMRFS 解耦摄取和 GDPR 删除

• 使用 Apache Hudi 进行高效删除

• 使用 Apache Hudi 优化低延迟读取

• 监控

优化摄取

为了保持 Kafka 中的存储精简和优化,并获得实时数据视图,我们创建了一个 Spark 作业,以每批 1.5 亿条消息的形式读取传入的 Kafka 消息,并以与 Hudi 兼容的格式写入 Amazon S3 5分钟。即使在迭代的初始阶段,当我们还没有开始扩展和调整时,我们也能够使用 Apache Spark 的 Amazon EMR 运行时在 2.5 分钟内成功加载所有 Kafka 消息。

优化吞吐量和 Amazon EMR 利用率

我们启动了一个成本优化的 EMR 集群,并从统一实例组切换到使用 EMR 实例队列。我们选择实例队列是因为我们需要灵活地将 Spot 实例用于任务节点,并希望分散可用区中特定实例类型的容量耗尽的风险。

我们开始尝试测试运行,首先将 Kafka 分区数从 400 更改为 1,000,然后更改任务节点数和实例类型。根据运行结果,AWS 团队提出了使用具有三个核心节点(r5.16xlarge(每个 64 个 vCPU))的 Amazon EMR 和使用 Spot 队列实例(r5.16xlarge (r5.16xlarge (r5.16xlarge ( 64 个 vCPU)、r5.12xlarge(48 个 vCPU)、r5.8xlarge(32 个 vCPU))。这些建议帮助 Zoom 将其 Amazon EMR 成本降低了 80% 以上,同时实现了在 5 分钟内摄取 1.5 亿条 Kafka 消息的预期性能目标。

使用 EMRFS 解耦摄取和 GDPR 删除

存储和计算分离的一个众所周知的好处是可以独立扩展。但一个不太明显的优势是可以将连续工作负载与零星工作负载分离开来。以前数据存储在 HDFS 中,资源密集型 GDPR 删除作业和数据移动作业将与流摄取竞争资源,导致上游 Kafka 集群积压超过 5 小时,接近填满 Kafka 存储(只有 6 小时的数据保留) ) 并可能导致数据丢失。将数据从 HDFS 卸载到 Amazon S3 使我们能够自由地按需启动独立的瞬态 EMR 集群以执行数据删除,有助于确保从 Kafka 到 Amazon EMR 的持续数据摄取不会因资源不足而不足。这使系统能够每 5 分钟摄取一次数据,并在 2-3 分钟内完成每次 Spark Streaming 读取。使用 EMRFS 的另一个副作用是成本优化的集群,因为我们不再依赖 Amazon Elastic Block Store (Amazon EBS) 卷来存储超过 300 TB 的存储空间,这些存储空间用于 HDFS 数据的三个副本(包括两个副本)。我们现在只需为 Amazon S3 中的一个数据副本付费,它提供 11 个 9 的持久性并且是相对便宜的存储。

使用 Apache Hudi 进行高效删除

并发运行时摄取写入和 GDPR 删除之间的冲突怎么办?这就是 Apache Hudi 的强大之处。

Apache Hudi 为具有事务语义的数据湖提供了一种表格式,可以在并发运行时分离摄取工作负载和更新。该系统能够在不到一分钟的时间内连续删除 1,000 条记录。Apache Hudi 0.7.0 在并发写入方面存在一些限制,但 Amazon EMR 团队通过将支持乐观并发控制的 Apache Hudi 0.8.0 反向移植到当前(当时的 AWS Data Lab 协作)Amazon EMR 6.4 版本。这节省了测试时间,并允许通过最少的测试快速过渡到新版本。这使我们能够直接使用 Athena 快速查询数据,而无需启动集群来运行临时查询,以及使用 Presto、Trino 和 Hive 查询数据。存储层和计算层的解耦提供了灵活性,不仅可以跨不同 EMR 集群查询数据,还可以使用完全独立的瞬态集群删除数据。

使用 Apache Hudi 优化低延迟读取

为优化 Apache Hudi 的低延迟读取,我们需要解决由于数据持续流入数据湖而导致在 Amazon S3 中创建过多小文件的问题。

我们利用 Apache Hudi 的功能来调整文件大小以实现最佳查询。具体来说,我们将 Hudi 中的并行度从默认值 1,500 降低到一个较低的数值。并行度是指用于向Hudi写入数据的线程数;通过减少它,我们能够创建更大的文件,这些文件更适合查询。

因为我们需要针对大容量流式摄取进行优化,所以我们选择为我们的工作负载实施读取表类型合并(而不是写入时复制)。这种表类型使我们能够快速将传入数据提取到行格式 (Avro) 的增量文件中,并将增量文件异步压缩到列式 Parquet 文件中以进行快速读取。为此,我们在后台运行了 Hudi 压缩作业。压缩是合并基于行的增量文件以生成新版本的列文件的过程。因为压缩作业会使用额外的计算资源,所以我们将插入的并行度调整为较低的值 1,000,以解决额外的资源使用问题。此调整使我们能够在不牺牲性能吞吐量的情况下创建更大的文件。

总体而言,我们使用 Apache Hudi 优化低延迟读取的方法使我们能够更好地管理文件大小并提高数据湖的整体性能。

监控

该团队使用 Prometheus(一种开源监控工具)监控 MSK 集群。此外,我们还展示了如何使用 Amazon CloudWatch 指标监控 Spark 流作业。有关更多信息,请参阅在 Amazon EMR 上监控 Spark 流应用程序。

结果

Zoom 与 AWS 数据实验室之间的协作展示了使用 Amazon EMR 和 Apache Hudi 的架构在数据摄取、处理、存储和删除方面的显着改进。该架构的一个主要好处是降低了基础设施成本,这是通过使用云原生技术和有效管理数据存储来实现的。另一个好处是数据管理能力的提高。

我们发现与之前基于 HDFS 的架构相比,EMR 集群的成本可以降低约 82%,同时使存储成本降低约 90%。所有这一切同时使数据在从源头摄取后 5 分钟内在数据湖中可用。同时从包含多个 PB 数据的数据湖中删除数据可以更高效地执行。通过我们的优化方法,我们能够在1-2 分钟内删除大约 1,000 条记录,而之前需要 3 小时或更长时间

结论

总之,日志分析过程涉及从各种来源(例如服务器、应用程序和设备)收集、处理、存储、分析和删除日志数据,对于帮助组织努力满足其服务弹性、安全性和性能监控、故障排除和合规性需求 ,例如 GDPR至关重要。

这篇文章分享了 Zoom 和 AWS 数据实验室团队在解决关键数据管道挑战方面共同取得的成就,并且 Zoom 进一步扩展了解决方案以优化提取、转换和加载 (ETL) 作业和资源效率。但是也可以使用此处介绍的架构模式为其他用例快速构建经济高效且可扩展的解决方案。

相关实践学习
日志服务之使用Nginx模式采集日志
本文介绍如何通过日志服务控制台创建Nginx模式的Logtail配置快速采集Nginx日志并进行多维度分析。
目录
相关文章
|
6天前
|
存储 SQL BI
毫秒级查询性能优化实践!基于阿里云数据库 SelectDB 版内核:Apache Doris 在极越汽车数字化运营和营销方向的解决方案
毫秒级查询性能优化实践!基于阿里云数据库 SelectDB 版内核:Apache Doris 在极越汽车数字化运营和营销方向的解决方案
毫秒级查询性能优化实践!基于阿里云数据库 SelectDB 版内核:Apache Doris 在极越汽车数字化运营和营销方向的解决方案
|
16天前
|
存储 运维 监控
Kubernetes 集群监控与日志管理实践
【5月更文挑战第28天】在微服务架构日益普及的当下,容器编排工具如 Kubernetes 已成为运维工作的核心。有效的集群监控和日志管理是确保系统稳定性和服务可靠性的关键。本文将深入探讨 Kubernetes 集群的监控策略,以及如何利用现有的工具进行日志收集、存储和分析,以实现对集群健康状况的实时掌握和问题快速定位。
|
16天前
|
存储 监控 Kubernetes
Kubernetes 集群监控与日志管理实践
【5月更文挑战第27天】 在微服务架构日益普及的当下,容器化技术与编排工具如Kubernetes已成为现代云原生应用的基石。然而,随着集群规模的不断扩大和复杂性的增加,如何有效监控和管理这些动态变化的服务成为了维护系统稳定性的关键。本文将深入探讨Kubernetes环境下的监控策略和日志管理的最佳实践,旨在为运维人员提供一套系统的解决思路,确保应用性能的最优化和问题的快速定位。
|
17小时前
|
存储 分布式计算 物联网
Apache IoTDB进行IoT相关开发实践
物联网技术带来数据库管理挑战,特别是实时数据整合与安全性。IoTDB是一个专为时间序列数据设计的数据库,提供数据收集、存储和分析服务,适用于海量物联网数据。其架构包括数据文件、系统文件和预写日志文件的管理,并支持多目录存储策略。此外,IoTDB还开发了InfluxDB协议适配器,使得用户能无缝迁移原有InfluxDB业务。此适配器基于IoTDB的Java服务接口,转换InfluxDB的元数据格式,实现与IoTDB的数据交互。目前,适配器支持InfluxDB 1.x版本及部分查询语法。
17 5
|
4天前
|
消息中间件 Kafka 数据处理
Apache Flink:流式数据处理的强大引擎
【6月更文挑战第8天】Apache Flink是开源的流处理框架,专注于高效、低延迟的无界和有界数据流处理。它提供统一编程模型,支持实时与批量数据。核心概念包括DataStreams、DataSets、时间语义和窗口操作。使用Flink涉及环境设置、数据源配置(如Kafka)、数据转换(如map、filter)、窗口聚合及数据输出。通过丰富API和灵活时间语义,Flink适于构建复杂流处理应用,在实时数据处理领域具有广阔前景。
|
6天前
|
存储 大数据 分布式数据库
使用Apache HBase进行大数据存储:技术解析与实践
【6月更文挑战第7天】Apache HBase,一个基于HDFS的列式存储NoSQL数据库,提供高可靠、高性能的大数据存储。其特点是列式存储、可扩展至PB级数据、低延迟读写及多版本控制。适用场景包括大规模数据存储、实时分析、日志存储和推荐系统。实践包括集群环境搭建、数据模型设计、导入、查询及性能优化。HBase在大数据存储领域扮演关键角色,未来有望在更多领域发挥作用。
|
8天前
|
监控 数据处理 调度
使用Apache Airflow进行工作流编排:技术详解与实践
【6月更文挑战第5天】Apache Airflow是开源的工作流编排平台,用Python定义复杂数据处理管道,提供直观DAGs、强大调度、丰富插件、易扩展性和实时监控。本文深入介绍Airflow基本概念、特性,阐述安装配置、工作流定义、调度监控的步骤,并通过实践案例展示如何构建数据获取、处理到存储的工作流。Airflow简化了复杂数据任务管理,适应不断发展的数据技术需求。
|
8天前
|
监控 NoSQL 数据建模
使用Apache Cassandra进行分布式数据库管理的技术实践
【6月更文挑战第5天】本文探讨了使用Apache Cassandra进行分布式数据库管理的技术实践。Cassandra是一款高性能、可扩展的NoSQL数据库,适合大规模、高并发场景。文章介绍了其高可扩展性、高性能、高可用性和灵活数据模型等核心特性,并详细阐述了环境准备、安装配置、数据建模与查询以及性能优化与监控的步骤。通过本文,读者可掌握Cassandra的运用,适应不断增长的数据需求。
|
10天前
|
分布式计算 Spark 大数据
深入探究Apache Spark在大数据处理中的实践应用
【6月更文挑战第2天】Apache Spark是流行的开源大数据处理框架,以其内存计算速度和低延迟脱颖而出。本文涵盖Spark概述、核心组件(包括Spark Core、SQL、Streaming和MLlib)及其在数据预处理、批处理分析、交互式查询、实时处理和机器学习中的应用。通过理解Spark内部机制和实践应用,可提升大数据处理效率,发挥其在各行业的潜力。
|
13天前
|
Prometheus 监控 Kubernetes
Kubernetes 集群的监控与日志管理实践深入理解PHP的命名空间与自动加载机制
【5月更文挑战第30天】 在容器化和微服务架构日益普及的背景下,Kubernetes 已成为众多企业的首选容器编排工具。然而,随之而来的挑战是集群的监控与日志管理。本文将深入探讨 Kubernetes 集群监控的最佳实践,包括节点资源使用情况、Pods 健康状态以及网络流量分析等关键指标的监控方法。同时,我们也将讨论日志聚合、存储和查询策略,以确保快速定位问题并优化系统性能。文中将介绍常用的开源工具如 Prometheus 和 Fluentd,并分享如何结合这些工具构建高效、可靠的监控和日志管理系统。

推荐镜像

更多