日均PB级数据分析，B站基于Iceberg的湖仓一体架构实践

一、背景

在B站，每天都有PB级的数据注入到大数据平台，经过离线或实时的ETL建模后，提供给下游的分析、推荐及预测等场景使用。面对如此大规模的数据，如何高效低成本地满足下游数据的分析需求，一直是我们重点的工作方向。

我们之前的数据处理流程基本上是这样的：采集端将客户端埋点、服务端埋点、日志、业务数据库等数据收集到HDFS、Kafka等存储系统中，然后通过Hive、Spark、Flink等离线和实时引擎对数据进行ETL处理及数仓建模，数据存储使用ORC列式存储格式，用户可以通过Presto、Spark等引擎对数仓建模后的数据进行数据探索以及构建BI报表。对于大部分的数据服务和部分BI报表，Presto、Spark访问ORC格式数据可能无法满足用户对于查询响应时间的要求，这时需要将数据写入ClickHouse等这种专门的OLAP引擎或者进一步处理数据后写入HBase、Redis等KV存储系统中等方式解决。

​

当前的数据处理流程虽然在一定程度上可以满足目前的业务需求，但是整个流程的效率和成本都还有很大的提升空间，主要体现在：

• 为了提升查询效率，从Hive表出仓到ClickHouse、HBase、Redis、ElasticSearch、Mysql等外部系统中，需要额外的数据开发工作，额外的存储冗余，但同时拥有了更少的数据灵活性，复杂的组件支持增加了数据服务开发的成本，更长的数据处理流程也降低了稳定性和可靠性。
• 对于未出仓的数据，用户无论是进行数据探索还是使用BI报表，都还受SQL on Hadoop本身性能所限，和用户期望的交互式响应有很大差距。

本文主要介绍为了应对以上挑战，我们在湖仓一体方向上的一些探索和实践。

二、为什么需要湖仓一体

在讨论这个问题前，我们可能首先要明确两个概念：什么是数据湖？什么是数据仓库？这两个概念在业界都有大量的讨论，每个人的说法也不尽相同，我们尝试总结如下，对于数据湖：

• 使用统一的分布式存储系统，可假设为无限容量。
• 有统一的元数据管理系统。
• 使用开放的数据存储格式。
• 使用开放的数据处理引擎对数据进行加工和分析。

我们之前的大数据架构基本上是一个典型的数据湖架构，使用HDFS作为统一的存储系统，Hive metastore提供统一的Schema元数据管理，数据以CSV、JSON、ORC等开放存储格式存储在HDFS上，用户可以使用SQL、DataSet、FileSystem等各个层次的API使用Hive、Spark、Presto、Python等框架或语言访问数据。

数据湖架构的好处是有非常大的灵活性，结构化、半结构化、非结构化数据都可以放在数据湖中，用户可以使用任意合适的引擎对所有的数据进行灵活的数据探索，几乎没有任何限制，但是它也存在很大的缺陷，最主要的就是数据管理和查询效率的问题。

对于数据仓库：

• 自定义的数据存储格式。
• 自己管理数据的组织方式。
• 强Schema数据，对外提供标准的SQL接口。