OnZoom基于Apache Hudi的流批一体架构实践

本文涉及的产品
RDS MySQL Serverless 基础系列,0.5-2RCU 50GB
RDS MySQL Serverless 高可用系列,价值2615元额度,1个月
简介: OnZoom基于Apache Hudi的流批一体架构实践

1. 背景

OnZoom是Zoom新产品,是基于Zoom Meeting的一个独一无二的在线活动平台和市场。作为Zoom统一通信平台的延伸,OnZoom是一个综合性解决方案,为付费的Zoom用户提供创建、主持和盈利的活动,如健身课、音乐会、站立表演或即兴表演,以及Zoom会议平台上的音乐课程。

在OnZoom data platform中,source数据主要分为MySQL DB数据和Log数据。其中Kafka数据通过Spark Streaming job实时消费,MySQL数据通过Spark Batch job定时同步, 将source数据Sink到AWS S3。之后定时调度Spark Batch Job进行数仓开发。最终按照实际业务需求或使用场景将数据Sink到合适的存储。

初版架构问题

MySQL通过sql方式获取数据并同步到S3是离线处理,并且某些场景下(比如物理删除)只能每次全量同步Spark Streaming job sink到S3需要处理小文件问题默认S3存储方式不支持CDC(Change Data Capture),所以只支持离线数仓因为安全要求,有时需求删除或更新某个客户数据时,只能全量(或指定分区)计算并overwrite。性能较差

2. 架构优化升级

基于以上问题,我们在进行大量技术调研选型及POC之后,我们主要做了如下2部分大的架构优化升级。

2.1 Canal

MySQL Binlog即二进制日志,它记录了MySQL所有表结构和表数据变更。

Cannal基于MySQL Binlog日志解析,提供增量数据订阅和消费,将数据Sink到Kafka实现CDC。

后续使用Spark Streaming job实时消费Binlog就能解决上述问题1的时效性以及物理删除等问题。

2.2 Apache Hudi

我们需要有一种能够兼容S3存储之后,既支持大量数据的批处理又支持增加数据的流处理的数据湖解决方案。最终我们选择Hudi作为我们数据湖架构方案,主要原因如下:

Hudi通过维护索引支持高效的记录级别的增删改Hudi维护了一条包含在不同的即时时间(instant time)对数据集做的所有instant操作的timeline,可以获取给定时间内的CDC数据(增量查询)。也提供了基于最新文件的Raw Parquet 读优化查询。从而实现流批一体架构而不是典型的Lambda架构。Hudi智能自动管理文件大小,而不用用户干预就能解决小文件问题支持S3存储,支持Spark、Hive、Presto查询引擎,入门成本较低只需引入对应Hudi package

3. Hudi 实践经验分享

1.Hudi upsert 时默认PAYLOAD_CLASS_OPT_KEY为OverwriteWithLatestAvroPayload,该方式upsert时会将所有字段都更新为当前传入的DataFrame。但很多场景下可能只想更新其中某几个字段,其他字段跟已有数据保持一致,此时需要将PAYLOAD_CLASS_OPT_KEY传为OverwriteNonDefaultsWithLatestAvroPayload,将不需要更新的字段设为null。但该upsert方式也有一定限制,比如不能将某个值更新为null。2.我们现在有实时同步数据,离线rerun数据的场景,但当前使用的是Hudi 0.7.0版本,该版本还不支持多个job并发写Hudi表。临时方案是每次需要rerun数据的时候暂停实时任务,因为0.8.0版本已经支持并发写,后续考虑升级。3.一开始我们任务变更Hudi表数据时每次都默认同步hive元数据。但对于实时任务每次连接Hive Metastore更新元数据很浪费资源,因为大部分操作只涉及到数据变更而不涉及表结构或者分区变动。所以我们后来将实时任务关闭同步hive元数据,在需要更新元数据时另外再执行hudi-hive-sync-bundle-*.jar来同步。

4.Hudi增量查询语义是返回给定时间内所有的变更数据,所以会在timeline在里查找历史所有commits文件。但历史commits文件会根据retainCommits参数被清理,所以如果给定时间跨度较大时可能会获取不到完整的变更数据。如果只关心数据的最终状态,可以根据_hoodie_commit_time来过滤获取增量数据。5.Hudi默认spark分区并行度withParallelism为1500,需要根据实际的输入数据大小调整合适的shuffle并行度。(对应参数为 hoodie.[insert|upsert|bulkinsert].shuffle.parallelism)6.Hudi基于parquet列式存储,支持向后兼容的schema evolution,但只支持新的DataFrame增加字段的schema变更,预计在在 0.10 版本实现 full schema evolution。如果有删除或重命名字段的需求,只能overwrite。另外增加字段也可能导致hive sync metadata失败,需要先在hive执行drop table。

7.Hudi Insert 对 recordKey 相同的数据,根据不同的参数有不同的处理情况,决定性的参数包括以下三个:    hoodie.combine.before.insert    hoodie.parquet.small.file.limit    hoodie.merge.allow.duplicate.on.inserts    其中:hoodie.combine.before.insert 决定是否对同一批次的数据按 recordKey 进行合并,默认为 false;hoodie.parquet.small.file.limit 和hoodie.merge.allow.duplicate.on.inserts 控制小文件合并阈值和如何进行小文件合并。如果 hoodie.parquet.small.file.limit > 0 并且 hoodie.merge.allow.duplicate.on.inserts 为 false,那么在小文件合并的时候,会对相同 recordKey 的数据进行合并。此时有概率发生去重的情况 (如果相同 recordKey 的数据写入同一文件中);如果 hoodie.parquet.small.file.limit > 0 并且 hoodie.merge.allow.duplicate.on.inserts 为 true,那么在小文件合并的时候,不会处理相同 recordKey 的数据

4. 总结

我司基于Hudi实现流批一体数据湖架构上线生产环境已有半年多时间,在引入Hudi之后我们在以下各个方面都带来了一定收益:

成本: 引入Hudi数据湖方案之后,实现了S3数据增量查询和增量更新删除,之前更新删除方案只能全表overwrite。Hudi实现智能小文件合并,之前需要单独任务去处理。在数据处理和存储方面都节约了相应成本,预估节省1/4费用。时效性: 所有ODS表已从T+1改造为Near Real Time。后续会建设更多实时表。效率: 在插入及更新数据时,默认情况下,Hudi使用Bloom Index,该索引更适合单调递增record key,相比于原始Spark Join,其速度最高可提高10倍。查询数据时,借助Hudi提供的Clustering(将文件按照某些列进行聚簇,以重新布局,达到优化查询性能的效果),Compaction(将基础文件和增量日志文件进行合并,生成新版本列存文件)等服务,可将**查询性能提升50%+**。

相关实践学习
基于CentOS快速搭建LAMP环境
本教程介绍如何搭建LAMP环境,其中LAMP分别代表Linux、Apache、MySQL和PHP。
全面了解阿里云能为你做什么
阿里云在全球各地部署高效节能的绿色数据中心,利用清洁计算为万物互联的新世界提供源源不断的能源动力,目前开服的区域包括中国(华北、华东、华南、香港)、新加坡、美国(美东、美西)、欧洲、中东、澳大利亚、日本。目前阿里云的产品涵盖弹性计算、数据库、存储与CDN、分析与搜索、云通信、网络、管理与监控、应用服务、互联网中间件、移动服务、视频服务等。通过本课程,来了解阿里云能够为你的业务带来哪些帮助     相关的阿里云产品:云服务器ECS 云服务器 ECS(Elastic Compute Service)是一种弹性可伸缩的计算服务,助您降低 IT 成本,提升运维效率,使您更专注于核心业务创新。产品详情: https://www.aliyun.com/product/ecs
目录
相关文章
|
1天前
|
Cloud Native 持续交付 云计算
构建未来:云原生架构在现代企业中的应用与实践
【5月更文挑战第25天】 随着数字化转型的浪潮席卷全球,企业正面临着前所未有的挑战与机遇。云原生技术以其独特的弹性、可扩展性和敏捷性,成为推动企业技术创新的重要力量。本文将深入探讨云原生架构的核心概念,分析其在现代企业中的应用实例,并提出实施策略和最佳实践,以助力企业在激烈的市场竞争中占据先机。
|
1天前
|
安全 API 持续交付
构建高效微服务架构:从理论到实践
【5月更文挑战第25天】在现代软件开发领域,微服务架构已经成为实现灵活、可扩展和容错系统的关键设计模式。本文不仅深入探讨了微服务的核心概念与设计原则,还展示了如何将这些理念应用于实际的开发流程中。通过具体案例分析,我们将详细阐述在构建微服务时如何进行服务的划分、管理的优化以及安全性的加固,旨在为开发者提供一套实用的微服务开发指南。
|
1天前
|
消息中间件 监控 安全
构建高效微服务架构:从理论到实践
【5月更文挑战第25天】 在现代软件开发领域,"微服务"一词已然成为实现业务敏捷性、可扩展性与技术多样性的代名词。本文将深入探讨如何构建一个高效的微服务架构,涵盖从基本理念的梳理、关键技术选型,到具体实施过程中的最佳实践。我们将通过实际案例分析,展示如何在保证系统稳定性的前提下,提升服务的独立性和弹性。文章不仅为开发者提供了一套可行的后端开发框架参考,同时也为架构师呈现了一幅微服务实施的蓝图。
|
1天前
|
监控 持续交付 数据库
构建高效可靠的微服务架构:策略与实践
【5月更文挑战第25天】 在当今快速迭代的软件发展环境中,微服务架构因其灵活性和可扩展性而广受青睐。本文将深入探讨构建一个高效且可靠的微服务系统的策略与实践,从服务划分、通信机制到数据一致性问题,再到容器化部署和服务监控。通过实例分析和最佳实践的分享,旨在为开发者提供一个清晰可行的技术蓝图,帮助他们在设计微服务时做出明智决策。
|
1天前
|
监控 负载均衡 安全
微服务架构下的API网关设计与实践
【5月更文挑战第25天】 在现代软件工程领域,微服务架构以其灵活性、可扩展性以及容错能力受到广泛关注。作为微服务架构中的关键组件,API网关承担着请求路由、负载均衡、安全认证等重要职责。本文将深入探讨在微服务架构下如何高效地设计并实现一个API网关,包括对API网关的功能需求分析、核心组件的选择与配置、以及性能优化等方面进行详细阐述。通过对具体案例的分析,旨在为开发者和企业提供一个清晰、高效的API网关构建指南。
|
1天前
|
监控 API 持续交付
构建高效微服务架构:策略与实践
【5月更文挑战第25天】 在当今的软件开发领域,微服务架构已经成为一种流行的设计模式,它通过将大型应用程序拆分为一系列小型、独立的服务来提高系统的可扩展性和灵活性。本文旨在探讨构建高效微服务架构的关键策略,并提供实践中的建议。我们将从微服务的定义出发,讨论其核心原则和优势,进而深入到如何设计、部署和维护这些服务。我们还将关注性能优化、容错机制和服务间通信等挑战,并给出相应的解决策略。
|
1天前
|
监控 API 持续交付
构建高效微服务架构:后端开发的现代实践
【5月更文挑战第25天】随着业务需求的多样化和复杂性增加,传统的单体应用架构逐渐显得笨重且难以维护。微服务架构以其灵活性、可扩展性和技术多样性成为解决这一问题的关键。本文将深入探讨构建高效微服务架构的最佳实践,包括服务拆分策略、容器化部署、API网关设计以及分布式事务处理等关键技术点,旨在为后端开发人员提供一套系统的方法论和实践案例,助力企业快速响应市场变化,提升系统稳定性与开发效率。
|
1天前
|
监控 Kubernetes 安全
构建高效微服务架构:后端开发的新趋势
【5月更文挑战第25天】 在现代软件开发中,微服务架构已经成为一种流行的设计模式,它通过将大型应用程序拆分为独立、可部署的服务来提高系统的可伸缩性和灵活性。本文深入探讨了如何构建一个高效的微服务架构,包括关键的设计原则、技术选型以及实践中的最佳实践。我们将重点讨论如何确保服务的高可用性、容错性和一致性,同时考虑到性能和成本效益的平衡。
|
1天前
|
监控 安全 API
构建高效可扩展的微服务架构
【5月更文挑战第25天】 随着数字化转型的加速,企业需要构建更加灵活、可扩展的系统以应对不断变化的市场需求。微服务架构作为一种创新的软件开发模式,以其独立性、灵活性和可伸缩性成为解决复杂系统问题的有效途径。本文将深入探讨如何构建一个高效且可扩展的微服务架构,涵盖关键设计原则、技术选型以及实践案例,旨在为开发者和企业提供实用的参考和指导。
|
1天前
|
负载均衡 安全 开发者
探索微服务架构中的服务网格
【5月更文挑战第25天】 在现代软件工程实践中,微服务架构已成为构建和部署分布式系统的主流方式。随着其流行度的提升,管理这些微服务之间的交互变得日益复杂。服务网格(Service Mesh)作为一种基础设施层,旨在处理服务间的通信,并提供服务发现、负载均衡、故障管理等功能。本文将探讨服务网格在微服务体系结构中的作用,以及如何利用它来优化分布式系统的可靠性和性能。

热门文章

最新文章

推荐镜像

更多