在当今的数字时代，日志记录是应用程序开发和管理的一个重要方面，但在遵守数据保护法规的同时有效管理日志可能是一项重大挑战。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) 作业和资源效率。但是也可以使用此处介绍的架构模式为其他用例快速构建经济高效且可扩展的解决方案。