Hologres实时数仓在B站游戏的建设与实践

一、背景

实时数据仓库是近年来数据技术领域内的一大发展潮流。构建一个能够实现高吞吐量写入与更新、端到端全链路实时处理以及低延迟、高并发的实时数据仓库，一直是众多企业面临的重大挑战。随着B站游戏业务的快速发展，对数据的实时应用需求也日益增加。单点式实时指标计算模式已难以支撑日益复杂的实时业务需求，因此，构建一个稳定、高效的实时数据仓库变得迫在眉睫。

建设实时数仓的主要原因包括：

1. 游戏业务对数据实时性的需求愈发迫切，需要实时数据来辅助决策制定；

2. 实时数据建设缺乏统一规范，导致数据可用性不足，难以形成完整的数仓体系，造成资源的极大浪费；

3. 离线数仓与实时链路相互独立，难以统一对外服务

如今，Hologre实时数仓体系已建设完成，它全面支持了运营、广告、算法等多元化业务场景的实时化需求，成为B站游戏数据应用的重要基石。本文将主要介绍我们在架构选型、方案设计、技术细节等方面的探索。

二、架构选型

离线数仓搭建的方法论比较明确，各类数据模型构建方式也比较成熟，数据流转可通过定时层间调度实现；但对于实时数仓的搭建，目前还没有一个明确的方法体系，各大厂商也采取了不同的方案架构，尤其是近年来各类优秀的OLAP (Online Analytical Processing) 数据库如StarRocks、Hologres快速发展，给实时数仓方案提供了更为丰富的选型，从众多方案中设计出符合B站游戏业务的实时架构，也就成为了我们首先考虑的方面。

1. Lambda还是Kappa？

Lambda架构是一种最经典的数据处理架构，通过Hive构建离线数仓，再利用Kafka、Hbase、Redis、Clickhouse等组件构建实时数仓，既可以满足跑批的需求，也可以进行流式计算。但是也有一个弊端，就是流和批分为两套技术栈，运维也要维护两套系统架构，维护成本非常高。

Kappa架构的出现，给行业带来了不一样的思路，即完全通过实时进行数据处理，实现全流程实时化构建，也是对流批一体式架构的一种探索。但只有实时链路，难以解决数据质量问题，时常需要离线链路对实时链路进行修正和丰富，而且依赖消息中间件支撑海量数据的回刷是成本极高且不稳定的架构。

考虑到B站游戏已经有了完善的离线数仓架构，选用Lambda架构是一种可靠且实际的做法，但是如何解决传统Lambda架构所带来的离线实时割裂化和高运维成本仍是个亟待解决的问题。

2. StarRocks还是Hologres？

为解决上述问题，我们考虑选取一种OLAP引擎来优化传统的Lambda架构，StarRocks与Hologres这两个近年来飞速发展的组件就成为了我们关注的重点。

首先是StarRocks，它采用了全面向量化引擎，并配备全新设计的 CBO优化器，使其查询速度（尤其是多表关联查询）远超同类产品。用其进行应用层的构建可使效率得到极大的提升，业内也有利用其强大的物化视图及视图能力分层构建实时数仓的案例，但对于大数据量的实时构建，通过物化视图进行驱动会对性能产生巨大的消耗，并不是当前的最优架构。

于是，我们将目光转向了Hologres，一款阿里自主研发的OLAP引擎，在经过深度调研后，其以下几个功能点吸引了我们的注意：

a.全链路事件驱动

Hologres内部表支持更新事件的Binlog透出能力，可替代kafka等消息中间件实现数仓各层级之间的数据传递，从而能够实现数仓层次间全链路实时开发。

b.行列共存

Hologres同时支持行存格式和列存格式，能支持多样化的应用场景。

c.局部更新能力

局部更新能力使Flink多表join场景