李呈祥：bilibili在湖仓一体查询加速上的实践与探索

---

导读： 本文主要介绍哔哩哔哩在数据湖与数据仓库一体架构下，探索查询加速以及索引增强的一些实践。主要内容包括：

• 什么是湖仓一体架构
• 哔哩哔哩目前的湖仓一体架构
• 湖仓一体架构下，数据的排序组织优化
• 湖仓一体架构下，索引增强与优化的实践探索

--

01 什么是湖仓一体

当我们讲湖仓一体时，涉及到数据湖和数据仓库两个概念。

什么是数据湖？通常来说，它有以下几个特点：

• 有一个统一的存储系统，所有的数据都放到这个统一的存储系统里，没有数据孤岛。
• 支持任意数据类型，比较自由，包括结构化、半结构化和非结构化的数据。这些不同类型的数据都可以统一放到存储系统里。
• 对于多个计算引擎是开放的，包括实时、离线的分析等，计算引擎很丰富。
• 有比较灵活的数据处理接口。有基于SQL这种级别的数据处理，也可以像基于Spark，提供更底层的，基于Dataset甚至RDD这种层面的，更甚者对于机器学习一些场景去对数据进行解析。也可以直接用文件系统，通过API直接读取文件。
• 因其灵活性，数据质量相对较低，比较难管理。

因此，基于数据湖的灵活与易用，它非常适合用于基于未知数据的探索与创新。

什么是数据仓库？它有以下几个特性：

• 强格式（schema），事前对数据进行建模
• 有封闭的数据格式与存储，不对其他引擎开放
• 查询效率高：存储与计算的紧密结合优化，丰富的索引/预计算等支持
• 数据入仓，无论是实时的还是离线的，或者说数据的存储组织由数仓内部而非写入任务决定
• 数据质量高，容易运维管理，建设成本高

因此，高效和可靠的特性使得数据仓库非常适用于基于已知数据的分析与决策。

哔哩哔哩和大部分互联网公司一样，之前的大数据平台都是基于开源的Hadoop生态系统。存储用的是HDFS，计算引擎则有Hive，Spark以及Presto等。在我看来，这是一个比较典型的数据湖的架构。但是，我们也有很多交互分析的需求，为了解决这些需求，我们会引入特定的分布式数仓，引擎使用的是ClickHouse。

这样就会引入新的问题。

比如，针对某个数据产品或者数据服务，为了对其提供比较好的查询效率和性能，需要先把数据从HDFS入仓到ClickHouse，使得整个的流程变长。其次，会带来数据冗余的问题，因为数据在HDFS上有一份，在ClickHouse上也有一份。第三，在入仓过程中，可能会对数据做一些操作，使得数据发生变化，导致很难与HFDS里的其他数据进行关联，导致数据孤岛出现。这两年，像Iceberg，Hudi以及Delta Lake这种数据湖的存储格式也逐渐被很多公司引入去解决上述问题。对我们来说，我们主要使用的是Iceberg这种引擎去解决数据湖和数据仓库之间存在gap的问题。

在我们看来，湖仓一体的目标有三个：

第一，希望它还是像数据湖一样灵活。主要是我们还是用统一的HDFS存储，和之前的SQL on Hadoop生态系统无缝兼容，包括基于Spark或者Flink ETL数据接入，SQL/ML/DataSet等各层次API访问以及Presto/Spark/Hive等多种计算引擎的支持。

第二，希望它像数据仓库一样高效。针对于写成Iceberg格式的表，我们希望它能够做到或者接近于专用的分布式数仓的高效查询效率，包括数据分布组织、索引、预计算、计算存储一体化/缓存等整体的增强和优化。像Iceberg本身提供了粗粒度这种事务的能力，使得我们能够拥有支持更多的变化读写，实时进实时出仓的额外能力。

第三，希望它能像风一样自由，这个是对用户而言，希望可以做到智能化，用户的使用门槛更低，易用性更高。之前，用户想要使其ETL结果的数据分析查询效率更高的话，需要关注很多方面，比如写出的数据是不是小文件会非常多，ETL里的SQL逻辑怎么写使得写出去的数据怎样排序，是否需要做预计算等，并且这些方面和用户的业务逻辑没有关系。

用户想追求比