一、背景
随着数字化时代的来临,B站每天都在处理并注入PB级的数据到大数据平台。经过离线或实时的ETL建模后,这些数据被广泛应用于下游的分析、推荐及预测等场景。面对如此大规模的数据和日益增长的分析需求,如何高效且低成本地满足这些需求,一直是我们工作的重点方向。
我们之前的数据处理流程是:先通过采集端收集客户端埋点、服务端埋点、日志、业务数据库等数据到HDFS、Kafka等存储系统,然后利用Hive、Spark、Flink等工具进行数据的ETL处理及数仓建模。数据存储使用ORC列式存储格式,用户可以通过Presto、Spark等引擎进行数据探索和构建BI报表。当前的数据处理流程在效率和成本上还有很大的提升空间。
为了解决这些问题,本文主要介绍我们在湖仓一体方向上的一些探索和实践。
二、为什么需要湖仓一体
湖仓一体是近两年大数据一个非常热门的方向。数据湖提供了数据的无限扩展和灵活的数据探索,而数据仓库则提供了高效的数据查询和管理。湖仓一体旨在结合二者的优势,既保证数据的灵活性,又保证数据的查询效率。
我们之前的大数据架构是一个典型的数据湖架构,使用HDFS作为统一的存储系统,Hive metastore提供统一的Schema元数据管理。我们也发现了数据湖架构在数据管理和查询效率上的问题。与此数据仓库虽然提供了高效的查询,但对数据的灵活性和扩展性有所限制。
我们选择了从数据湖架构向湖仓一体演进的方向,希望在保证数据灵活性的提升数据的查询效率。
三、B站的湖仓一体架构
我们的湖仓一体架构基于Iceberg表存储格式,并结合了开放的查询引擎和S3对象存储的湖仓一体架构。我们的目标是减少从Hive表出仓到外部系统(如ClickHouse、HBase、ES等)的复杂性,降低成本,并提升查询效率。
我们的架构中有一个核心组件——Magnus智能管理服务。Magnus负责管理优化所有的Iceberg表中的数据,当Iceberg表发生更新时,它会发送一个event信息到Magnus服务中,并维护一个队列用于保存这些commit event信息。Magnus内部的Scheduler调度器会持续消费event队列,并根据对应Iceberg表的元数据信息及相关的策略决定是否及如何拉起Spark任务优化Iceberg表的数据。
我们还对Iceberg内核进行了增强,引入了Z-Order排序和索引等功能,以进一步提升数据的查询效率。Z-Order是一种在数据上进行排序的方式,可以保证多个字段的Data Skipping效果。而索引则可以帮助我们更快速地定位到需要的数据,进一步提高查询效率。
我们的湖仓一体方案已经在B站的数据分析场景中逐渐落地,并支撑了PB级的数据量,每天响应几万个查询。其中P90的查询可以在1秒内响应,满足了多个运营分析数据服务的交互式分析需求。
四、总结和展望
未来,我们计划在星型模型的数据分布、预计算、智能化等方面进行进一步的研究和探索,以适应更多样化的查询模式,提高查询效率,为用户提供更好的使用体验。我们期待与更多的小伙伴一起交流沟通,共同推动大数据技术的发展。
>>>>
参考资料
- 通过数据加速大规模数据分析:该文献详细介绍了如何通过优化数据来提高大规模数据分析的效率。
- 通过索引加速湖仓一体分析:该文献详细介绍了如何利用索引技术来提高湖仓一体架构的分析效率。
(
dbaplus社群即将迎来一场关于金融行业数据库运维演进的直播分享。这场名为【适配金融行业的数据库运维演进之路】的直播活动,将为我们揭示金融核心系统分布式改造中遇到的数据库运维问题的解决方案。
该活动将于6月25日下午2点准时开启,我们联合平安银行共同筹划此次分享,主要针对的议题包括:数据库故障自愈技术、MySQL跨同城高可用架构设计等前沿的数据库运维技术。
感兴趣的参与者可以点击下方的评论区链接进行报名。一旦报名成功,您还可以将直播链接复制到微信,通过小程序直接观看直播,方便快捷。
关于我们
我们dbaplus社群致力于为数据库从业者提供一个交流学习的平台。我们汇集了众多业内专家和资深从业者,通过定期举办各类技术分享和直播活动,为大家带来最前沿的数据库技术和行业动态。我们希望通过这样的方式,助力金融行业在数据库运维方面的不断进步和创新。