字节、阿里关于实时数据湖的应用与解决方案总结
在海量数据下,依靠传统数据库和传统实现方法基本完成不了,企业需要一种分布式的、高吞吐量的、延时低的、高可靠的实时计算框架。
下面将为大家分享字节跳动、阿里2家企业在实时数据湖的方面的实践应用。
01 实时数据湖在字节跳动的实践
近两年数据湖是一个比较火的技术,从传统的数仓到数据湖,在过去 5 年里架构演变得非常迅速。Hudi、Iceberg、Dalta Lake在业界被称为数据湖三剑客。
目前,字节对数据湖的解读,主要聚焦在数据湖的六大能力上:高效的并发更新能力、智能的查询加速、批流一体的存储、统一的元数据和权限、极致的查询性能,以及AI + BI。
字节内部的数据湖最初是基于开源的数据湖框架Hudi构建的,在尝试规模化落地的过程中,主要遇到了四个挑战:数据难管理、并发更新弱、更新性能差,以及日志难入湖。
如何应对这些挑战?字节做了问题背后的详细的原因分析,以及针对不同问题,采取了不同的应对策略。
1. 构建一层统一的元数据层
为了解决数据难管理的问题,字节在数据湖和数仓之上,构建了一层统一的元数据层,这层元数据层屏蔽了下层各个系统的元数据的异构性,由统一的元数据层去对接 BI 工具,对接计算引擎,以及数据开发、治理和权限管控的一系列数据工具。
2.使用乐观锁重新实现并发的更新能力
多任务的并发写入是字节内部实践当中一个非常通用的诉求。因此字节在Hudi Metastore Server的Timeline之上,使用乐观锁去重新实现了这个并发的更新能力。同时,字节的并发控制模块还能支持更灵活的行列级别并发写策略,为实时数据关联的场景的落地提供了一个可能。
与此同时,在进行高QPS入湖的情况下,字节遇到了单个Flink任务的扩展性问题和批流并发冲突的问题。如何解决?
- 通过在Flink的 embedding term server上支持对当前进行中的事务元信息进行缓存,大幅提升单个任务能够并发写入的文件量级。
- 提供更灵活的冲突检查和数据合并策略——行级并发、列级并发和冲突合并。
3.采用可扩展数据结构hash
在早期的落地过程当中,字节尽可能地复用Hudi的一些原生能力,比如Boom Filter index。但Bloom Filter存在假阳性,规模达到一定量级之后,大部分数据都是更新操作,没有办法再被索引加速。
Bloom Filter索引的问题,根因是读取历史数据进行定位,导致定位的时间越来越长。对此,字节采用可扩展数据结构hash,无需读历史数据,也可以快速定位到数据所在位置。
利用这个数据结构结构,可以很自然地做桶的分裂和合并,让整个bucket的索引从手动驾驶进化到自动驾驶。在数据写入的时候,也可以快速地根据现有的总数,推断出最深的有效哈希值的长度,通过不断地对 2 的桶深度次方进行取余的方式,匹配到最接近的分桶写入。
4.提供无索引的机制
日志难入湖的本质原因在于Hudi的索引系统,这个索引系统要求数据按照组件聚集,会带来性能上的问题以及资源上的浪费。
无索引,即绕过Hudi的索引机制,做到数据的实时入湖。同时因为没有主键,Upsert 的能力也失效了。字节在这方面提供了用更通用的 update 能力,通过shuffle hash join和 broadcast join 去完成数据实时更新。
02 阿里基于Flink Hudi的增量ETL架构
过去半年,阿里巴巴计算平台事业部 SQL 引擎组一直在开发Apache Flink sql 模块,核心工作是 Flink 与 Hudi 的集成。
为什么选择Hudi而不是Iceberg或Dalta Lake?
这与Hudi的两个能力有关系,一个是事务管理能力,另一个是upsert 能力。Hudi 提供的事务模型是快照级别,初步实现了海量数据 upsert 以及事务的管理能力。
1.Hudi如何做到近实时的数据库入湖?
最近兴起的流批一体的架构,像debezium、canal 通过订阅 MySQL binlog 事件的方式将增量数据近实时地导入数仓之中,这就要求下游数据库本身有 upsert 语义,而 Hudi 提供了这样的能力,并且是目前做得比较成熟的,因此 Hudi 可以使用这两种途径至少在 ODS 层进行近实时的数据库数据入湖:
先使用debezium 采集 binlog,在使用 flink cdc connector 直接对接,flink cdc connector 具有 snapshot 再加增量消费的能力,可以直接向下游拥有 upsert 的数据湖(如hudi)进行同步,不需要再去接一层 kafka 就可以做到分钟级别的入仓入湖。
2.阿里如何构建分钟级别近实时的增量数仓模型?
用传统的方式构建经典的数仓模型,需要通过调度系统按照某种时间策略构建一个定期的 pipeline 任务,依据 pipeline 之间的依赖关系规定触发机制,整体维护十分复杂。
Hudi 因为具有 upsert 的能力,因此可以利用 debezium 等工具,通过 flink CDC 加 kafka 将数据库数据近实时地同步到 ODS 层。如果Hudi 可以继续将上游数据的变更数据流传到下游,借助 flink CDC 的能力下游可以继续消费这种增量数据,然后在原有状态的基础上继续做增量计算。因此,阿里通过对 hudi table format 进行改动,构建了分钟级别近实时的增量数仓模型。
相关文章
- LibreOffice 7.5 发布:漂亮的新应用图标和酷炫功能
- elementary OS 7 发布
- Windows 应用兼容层 Wine 8.1 发布:默认启用“Windows 10”前缀
- 微软正测试新功能:当 Windows 11 有新的小组件可用时会提醒通知
- 解析分布式存储选型和应用九个典型问题
- ClickHouse在自助行为分析场景的实践应用
- Chrome DevTools 远程调试安卓网页的原理
- Uni-app + Vue3 页面如何跳转及传参?
- 微软证实系统还原点会损坏 Windows 11 22H2 版本应用程序
- 巧用 Transition 实现短视频 APP 点赞动画
- 初学者试试,HarmonyOS应用开发者基础认证
- 媒体实测微软 Windows 开发工具包 2023:存在不兼容 HDR 显示器、某些应用无法运行等问题
- 快速了解Navigator API SetAppBadge
- 微软 Windows 11 Dev 预览版 Build 25276 发布,应用兼容问题对话框 UI 改进
- 基于Next.js、Prisma、Postgres和Fastfy构建全栈APP
- 开始菜单搜索框变圆角,微软 Windows 11 Beta 预览版 22621.1095 和 22623.1095 发布
- 2022-2023 十大应用开发趋势
- 观远数据发布业内首部《移动BI白皮书》,深入业务数字化场景重新定义移动BI
- Windows 10 学院:不借助第三方工具如何卸载 Windows 10 预装应用
- 正处高质量发展期,我国大数据产业突破1.3万亿元