B 站基于 StarRocks 构建大数据元仓

作者：bilibili 大数据高级开发工程师 杨洋

B站大数据元仓是一款用来观测大数据引擎运行情况、推动大作业治理的系统诊断产品。经过调研和性能测试，大数据元仓最终以 StarRocks 为技术底座，从实际的应用效果来看，大部分查询都能在几百毫秒内返回结果。 B站大数据元仓是一款用来观测大数据引擎运行情况、推动大作业治理的系统诊断产品。经过调研和性能测试，大数据元仓最终以 StarRocks 为技术底座，从实际的应用效果来看，大部分查询都能在几百毫秒内返回结果。

随着B站业务的高速发展，数据量已达到 EB+ 级，为了适应数据服务需求，B站大数据平台引入了 Presto、Spark、ClickHouse 等多种大数据引擎。

在大数据引擎运行过程中，由于缺乏一些运行时的切面数据，我们难以实时观测引擎的运行情况，另外，由于缺乏作业维度的统计信息，我们也难以推动用户对大作业进行治理。为了满足这些需求，B站构建了大数据元仓系统。

大数据元仓涉及的大数据组件包括 Yarn、Presto、Spark 等，以 Presto 元仓为例，系统主要从集群、队列、query 等三个维度进行分析。 其中集群维度可以细分为包括 CPU、内存、扫描数据量等在内的节点资源汇总信息和包括各种 query 状态统计的集群 query 汇总信息；队列维度主要包括队列的资源、水位信息；query 维度则是对集群 query 汇总信息的一个补充，可以获取更详细的信息，比如可以具体了解导致查询失败的异常情况。

技术选型

需求特点

目前，我们的内部监控架构基于 Prometheus 搭建，Prometheus 存储数据量有限，通常仅为一两个月的数据，不适合存储长时间的历史数据。此外，Prometheus 是基于度量的系统，更多地用于展示趋势性数据，例如集群的 CPU 和内存情况等，但对于像元仓这样需要下钻到具体明细数据的需求，Prometheus 则难以满足。

基于以上问题，我们打算设计一个新的架构来构建大数据元仓。我们的大数据元仓应该满足以下特点：

实时观测：能够实时观测到集群的指标数据，并在多维分析场景中实现秒级或亚秒级的查询返回。

复杂逻辑计算：支持复杂的逻辑计算，不需要将数据落库后打成大宽表的形式。有较高的灵活性，以便后期满足不同的需求，并在现有逻辑的基础上进行处理和分析。

存储及回放：能够存储半年甚至更久的数据，并支持数据的回放。

数据湖 or 数仓

基于以上需求，我们对当前比较热门的数据湖、数仓组件进行了调研。其中，数据湖组件主要包括 Iceberg、Hudi 和 Delta Lake，数仓组件则重点调研了 ClickHouse 和 StarRocks。

最终，由于以下原因，我们选择了数仓技术作为大数据元仓的技术底座： 传统的数据湖技术在实时性方面普遍存在不足，Hudi、Iceberg 虽然可以达到分钟级的实时性，但要实现秒级的实时性可能仍然存在一些困难；

数据湖的远程 I/O 成本可能会较高，而数仓技术更多地采用本地 I/O，可以更有效地减少远程 I/O 的开销。

在数仓技术中，有一些成熟的加速手段，例如通过物化视图和索引等方式来提高查询性能。相对于数据湖技术，数仓技术在这方面更加成熟。

组件选型

在数据湖与数仓之间作出选择后，关于采用 StarRocks 还是 ClickHouse，我们从6个维度进行了比较。

标准 SQL：StarRocks 支持标准 SQL，并兼容 MySQL 协议，这对于应用程序迁移来说是一个优点。而 ClickHouse 在标准 SQL 方面并不完全支持；

性能：StarRocks 的读写性能都较好，而 ClickHouse 在单机性能方面可能更强大；

StarRocks 可以很便利地通过多机多核的方式提高并发能力，而 ClickHouse 的并发能力相对较弱，默认的 QPS 大约为100；

JOIN 能力：StarRocks 的支持较好，可以建立星型或者雪花模型应对维度数据的变更，而 ClickHouse 的 JOIN 能力相对较弱，通常需要将数据处理成宽表进行查询；

运维：StarRocks 不依赖第三方组件，如果出现资源不足的情况，可以很容易地对 FE 和 BE 进行横向扩展。而 ClickHouse 依赖于第三方组件，如 Zookeeper 来构建集群，运维成本更高；

StarRocks 社区在国内活跃度相对较高，在我们对 StarRocks 进行调研和测试时，如果遇到问题，社区往往能够快速给出建议和回复； 根据以上分析，我们更倾向于选择 StarRocks 作为大数据元仓技术的底座。

性能测试

为了进一步了解 StarRocks 在性能方面的表现，我们对 StarRocks 内外表与内部 Presto 集群的性能进行了比较，使用了 TPCH 数据集，并随机选择了一些 SQL 进行性能测试。

图中橙色线表示 StarRocks 外表的查询，灰色线表示 Presto 的查询。可以看出，相对于 Presto，StarRocks 具有更强大的查询性能，外表查询时间相缩短了大约70%至80%。如果采用内表查询，查询时间则会进一步缩短。

除了查询性能，我们还关注计算引擎的资源消耗，因此还比较了 StarRocks 和 Presto 的查询资源消耗。

这里特别说明一下，考虑到我们的元仓场景更倾向于使用内表进行查询，因此采用内表进行了资源、内存和 CPU 方面的比较。总体而言，相对于 Presto，StarRocks 的资源消耗更小。

架构方案

在元仓架构方面，我们最终确定 StarRocks 作为元仓的技术底座，提供存储和查询能力。此外，还构建了一个采集模块，主要功能是收集各个集群的指标，并将其推送到 Kafka。为了实现这一功能，我们在内部实现了一个代理（agent），该代理封装了从采集器（collector）将数据推送到 Kafka 的逻辑。

StarRocks 有两种方式从 Kafka 导入数据：Routine Load 和 Flink。其中，Routine Load 是 StarRocks 自带的一种导入作业方式，可以消费 Kafka 数据并将其写入 StarRocks。

采用 Routine Load 方式比较简单，用户只需要创建一个 Routine Load 作业，并指定列和 Kafka 主题以及一些分区信息即可进行数据消费和写入 StarRocks。在线上环境中，对于新业务来说，Routine Load 是比较容易推广的，因为我们可以与用户规范数据格式，使其以规范的格式写入 Kafka。

对于存量数据，用户可能已经在 Kafka 端采集了一些度量指标，此时让用户按照之前定义的规范重新将数据写入 Kafka 可能并不合适。对于一些特殊的业务逻辑，Routine Load 可能无法满足需求，这时就需要用到 Flink 来处理。

相比 Routine Load，Flink 通过编码的方式更加灵活，特别适用于处理复杂的多表关联查询。然而，由于 Flink 即使是对于简单的表也需要进行编码，这对于一些不常开发代码的用户来说可能会增加上手成本。因此，在内部我们会将 Routine Load 与 Flink 结合使用。

应用效果

根据最终的应用情况，StarRocks 整体的性能表现非常好，在99分位延迟方面表现出色，大部分查询都能在几百毫秒内返回结果。

从元仓的角度来看，大数据元仓（以 Presto 元仓为例）带来的一个效果是对 CPU 使用情况的监控和分析。通过监控 Presto worker 的 CPU 指标，如可用处理器数量和 CPU 负载等，可以根据用户选择的时间范围（如3000分钟）和粒度（分钟、小时或天），对 CPU 使用情况进行分组和聚合，以获取整体 CPU 使用情况的统计数据。这样可以帮助用户了解 CPU 的利用率情况。

上图展示了B站内部 Presto 集群作业的概况。有时用户会反馈 Presto 作业运行较慢或失败较多。在遇到这些问题时，我们可以通过这张图进行量化分析，以确定是否存在排队查询或失败等情况。

图中，排队查询量、正在执行的作业成功量以及失败的作业数量等数据主要来源于 Presto Coordinator 的查询信息。通过这些信息，我们可以更加清楚地了解 Presto 作业的排队情况、执行成功率以及失败数量，以便更好地监控和管理 Presto 集群的性能和稳定性。

未来规划

目前我们已经在内部完成了 StarRocks 的初步落地，将其应用于公司的元仓场景，并构建了一个大数据元仓系统，为用户提供实时的资源观测能力。此外，还通过诊断系统推动用户治理异常作业。

未来，会在如下一些方向开展工作：

由于 StarRocks 在大数据元仓场景中表现非常出色，我们希望将其接入更多的业务场景，例如 BI 和 DQC 等。

解决权限、UDF 等问题，比如接入 Hive UDF，使 StarRocks 与其它引擎对齐。

目前的架构主要是以仓为中心，未来我们计划将半年或者更长时间的数据回流到数据湖中，从而实现湖仓一体化的架构。

开启 StarRocks 的一些加速功能，例如物化视图索引，以提升现有元仓查询的速度。

我们希望能够接入更多的组件，例如将 HDFS、Kyuubi 的大数据元信息纳入元仓体系中。

诊断系统方面，目前主要以 Spark 诊断为主。未来，我们希望能够支持更多类型的作业诊断，如 Presto 和 Flink 作业的智能诊断。此外，我们还希望将诊断系统与公司内部其他平台打通，为用户提供更专业的诊断建议。