01腾讯视频数据业务介绍

首先来介绍一下腾讯视频相关业务背景和技术背景。

1. 视频业务流程

腾讯视频是中国比较领先的在线视频平台，拥有丰富的优质流行内容和专业的媒体运营能力，包括影视、综艺，生态视频、娱乐社区等相关的内容平台。

用户在腾讯视频的行为，被我们抽象为一些关键指标。用户通过启动视频 APP，浏览页面里的海报，点击或者搜索视频，观看视频内容，观看结束后对视频做一些评论。会产生活跃用户数，海报的曝光数、点击数、搜索的次数、播放次数、互动指标等各种各样的关键指标。这些指标是腾讯视频业务运营的基础，可以帮助业务进行决策，所以管理和治理好这些指标至关重要。

2. 视频技术背景

接下来介绍一下技术背景。腾讯视频拥有很多终端，包括 APP 端、PC 端、OTT端等，来源非常丰富。由于使用的人数比较多，且使用人数的时长也比较长，所以视频使用数据量的峰值也比较大，在高峰期的峰值数据量可达到五千多万每秒。

同时，因为腾讯是个庞大的组织，涉及到很多部门，各个部门又有各种各样不同的组件，导致我们在进行数据处理时，链路也会比较复杂。另一方面，我们面对的业务也比较广，包括给老板、运营、产品看的报表类数据，对外对接的 API 数据，以及通过接口调用给视频的终端能够外显给用户的数据。因此要求数据要精准，并且延迟要低，这对数据处理工作提出了很高的要求。

02腾讯视频指标中台的整体架构

1. 指标中台的业务背景

接下来将详细介绍指标中台，首先来看一下业务背景。

我们为什么要做指标中台？主要是要解决指标的治理问题，包括指标在使用或者生产过程中的一致性、时效性、易用性、成本的问题。指标一致性问题，主要来源于我们没有统一的平台来管理这些指标，指标的流程也不够规范，同一个指标的加工逻辑又不能保证是一致的。实时和离线会有不同的链路，也会导致指标的一致性问题和时效性问题。

前面提到，腾讯视频的用户量是比较大的，所以数据的体量也比较大，加工的流程较为复杂。在整个运行过程中依赖了很多组件，又需要依赖值班运维在遇到异常时的异常处理。我们一直关注降本增效，所以也希望能够降低指标相关的成本，避免指标的重复加工带来的计算和存储的成本增加，并控制好指标的存储生命周期，下线一些无用的指标，进一步降低指标成本。

由于指标是要开放给业务使用的，因此存在指标的易用性问题，需要相应的平台开放给用户去找指标、使用指标、查看指标口径。同时要有一些文档和培训工作，方便业务和相关下游使用者更好地使用数据。

2. 指标中台业界调研

我们做了业界调研，调研一些指标中台的特征，比如一次定义多次使用，在一个地方定义好之后，在下游接口、报表配置、SQL 查询能够保证一致性。另外，还需要一个平台进行统一的管理，管理这些指标、指标的下游，指标的血缘，指标的服务等，统一对下游提供 API 数据服务等。同时，还希望能够通过低代码的方式，用较少的代码、较快的速度去交付指标应用。

基于这些特性，我们调研了国内外指标中台的产品。比如说 Airbnb、Kyligence 以及国内快手、头条等相关的一些指标中台的产品。

3. 指标中台整体架构

基于前文提到的业务背景和业界调研内容，我们设计了腾讯视频指标中台的整体架构，主要是基于公司平台的基础能力，通过指标中台对指标的一致性、时效性、易用性、成本进行治理。依赖公司数据平台提供的数据接入、任务调度、存储、统计分析、实时计算能力，建设相关的数据资产平台，包括数据的开发工具，引擎，数据的查找、发现、使用等工具。

指标治理包括指标管理和指标消费两大部分。指标管理部分，会对指标进行分类，包括指标的等级、指标的类型、指标的相关关系等。然后对维度进行标准化，把维度划分成不同的实体，实体相关的维度以及维度相关的属性等做标准化处理。同时因为数仓的指标特别多，我们会对校验过的指标做认证，把认证过的指标作为标准指标开放给用户，最后还会把指标流程在整个指标管理中规范起来，做到整个流程的线上化。

指标消费方面，我们提供统一的指标服务，打通了指标上下游的数据血缘，提供数据地图，让用户可以方便地查找和使用指标维度和表，同时对指标提供 SLA 的保障。

在资产运营部分，通过对成本、规范使用等建立量化机制，形成一套数据资产分，以实现对整个数据资产的持续运营。

在组织保障上，建立数据委员会，对指标口径的定义、变更，以及规范的制定等进行 review。同时在底层，我们依赖指标生产，包括引入流批一体打通实时和离线的处理流程，引入数据湖的机制，实现在湖上建仓，提供多维数据分析的能力，开放给业务进行更灵活的处理分析。有这样的基础之后，我们对下游可以支持各种各样的数据应用，包括报表、产品、敏捷分析、实验平台、开发应用等等。以上就是指标中台的整体架构。

4. 指标一致性-指标服务

接下来介绍该架构中对前文提到的指标问题的解决方案。

在指标一致性方面，提供统一的指标服务，统一管理指标。并且打通了这些指标对应的数据源配置，包括 MySQL、CK、StarRocks 等相关的查询存储引擎，把指标的口径和指标的基础元数据信息以及业务元数据信息统一地管理起来，提供统一的指标查询服务。同时还有一套查询语言，可以屏蔽底层存储计算引擎的差异，提供统一的服务支持下游的应用。如上图右侧所示，可以在看板中选择相应的数据集以及指标维度进行查询，也可以通过一套类 SQL 的 MQL 语言，查询指标和维度信息。

5. 指标一致性-指标认证

在指标一致性层面，我们对数据仓库中的指标做了官方认证，保障多个平台中的指标口径是一致的，提升了指标的可信度。指标认证部分，主要针对指标名称、指标分类、指标责任人、指标口径，以及指标的数据源信息做认证。经过认证的指标也能透传到相应下游的数据产品中。这依赖于指标的整个生产以及下游链路的打通。有了指标认证的标识，下游就可以放心地使用指标了。

6. 指标时效性-SLA 保障

在指标时效性方面，我们基于任务的运行信息和血缘信息，监控整个数据的执行链路，保障数据按时就绪，及时处理数据异常。我们做了一套 SLA 监控工具。

首先接入数据信息，包括任务的运行信息、定义信息，以及任务的上下游血缘信息，统一在管理层管理起来。对于下游应用，我们配置相应的期望就绪时间以及报警的责任人、值班人等。如果整个数据链路中发现异常，在应用层对运营整个数据链路进行运营监控，链路过程中的卡点会及时报警。这些对应的 SLA 有分级的机制，比如 A 级、B 级会要求在不同的时间点响应，A 级夜间必须有值班等。通过值班的运维机制，出现问题通过报警通知、电话通知等，通知相关的值班人员及时处理，同时还能按周按月形成质量报表来监控整体数据质量的变化和运营情况。

7. 指标易用性-数据地图

在指标易用性上，我们通过统一管理的指标元数据信息，提供了一套查找和使用数据的数据地图。基于数据地图可以根据一些关键词、标签、主题，高效地查找和使用指标。用户可以通过分类查找和关键词检索，来查看这些指标的基本信息、血缘信息和指标加工信息等。

8. 指标易用性-自助分析

同时，为了让指标能更容易被使用，我们还提供了一套自助分析工具。指标中台统一管理了指标的数据源信息和指标的分析维度，用户可以通过自助分析工具直接选取这些指标和维度来进行查询，由指标服务路由到相应的数据源，构建查询语句即可查询所需数据。自助分析工具覆盖全业务场景，基于 StarRocks 引擎，提供高效的查询服务。用户可以不需要写 SQL，通过拖拽即可直接取到数据，提升了数据的易用性。

9. 指标成本-数据资产分

在指标成本方面，我们建立了对数据资产的量化机制，基于指标治理引擎，建立数据资产的评估体系，包括成本分、规范分、安全分、质量分、易用分等，对无用的任务及时下线。并对数据仓库的库、表命名、注释等进行规范化，对敏感字段和不一致等数据安全隐患进行治理。同时监控指标的认证情况、任务的延迟情况等，形成了一套统一的资产量化机制。这样基于治理引擎制定治理目标、定义治理规则，将不达标的任务推送给相关责任人进行处理，提升整个数据的资产分，让整个数据资产实现良性的运营。

03腾讯视频湖仓一体建设实践

接下来介绍指标中台湖仓一体的建设实践。

1. 湖仓一体建设背景

首先介绍湖仓一体的背景。基于之前 Lamda 的模式，离线和实时有两套架构，因此存在开发效率和质量的问题，也是因为离线和实时不同的链路，导致了数据的不一致和数据波动、延迟等。同时两套链路也会带来人效问题，离线和实时两套代码、两套脚本，需要研发人员分别去开发。

因为腾讯视频数据量较大，离线数据处理会比较慢，整个 T+1 的离线底层数据的就绪时间可能在两点以后，因此下游的时效性就会比较低。另外，如果上游出现数据故障，整个数据的回溯也比较麻烦。两套链路，数据的资源成本、运维成本都会翻倍。基于这个背景，我们计划将整个开发方式变成配置化、标准化的，提供一些自动修复类的运维机制，同时把流和批的两条链路整合成流批一体。并且进行采样监控，对数据质量监控构建一些准实时的链路，综合流和批的特点。

2. 湖仓一体建设方案

基于上述背景，我们建设了湖仓一体 1.0 的方案。主要是引入了数据湖的技术，在湖上建仓。整个架构从 Lamda 架构升级到了流批一体的架构，数据会通过流批一体进行处理，再到下游去应用，同时还保留了批的流程，适用于在流式处理出现故障时，通过批处理进行修复。

为什么我们要在湖上建仓？因为我们要解决原有数仓里面的 upsert 等问题，所以引入了数据湖技术。如果只是单引用数据湖，查询效率的问题还不能得到完全解决。为了提升查询效率，我们通过在湖上建设数据仓库，并对数仓进行加速，来提供实时分析和 OLAP 查询。

我们为什么选择 Iceberg 作为湖的技术呢？因为 Iceberg 在数据入库流程中会提供事务能力，不影响当前数据的处理，同时也支持 upsert 这样的功能，此外 Iceberg 能够支持更多的计算引擎，包括 Spark、Flink、Presto、Hive，正好也和我们的技术栈比较吻合。并且还支持灵活的文件组织，使得批任务和流任务能够做相同的存储模型。所以我们选择了在湖上建仓，并使用 Iceberg 作为湖的技术方案。

3. 配置化、标准化：全面 SQL 化

有了这套方案之后，我们开始推进全面配置化、标准化的流程建设。之前也提到了，离线和实时有两套 API，人效会比较低，缺乏体系化的研发框架。基于这一背景，我们希望对离线和实时研发环境实现流批一体，通过配置化、SQL 化和模板化来进行生产，我们引入了一套 SQL in Jar 编程架构，希望把核心的逻辑通过SQL 来进行表达，同时引入了 Flink batch 引擎，这样离线和实时都会通过一套SQL 来保证逻辑是一致的。同时 Flink batch 主要用于数据的修复和回补等。这些能保证离线和实时整个逻辑是一致的。同时可以使用一套代码进行开发，从而提升人效，并最终实现效率和一致性的保障。

4. 湖仓 1.0 方案的问题

湖仓 1.0 实现了一段时间后，也发现了一些问题。因为当年只是在 DWD 数据明细层做了湖仓的融合，而下游解决得并不够彻底。在我们的 DWS 数据汇总层以及下游，还是准实时和离线分别有单独的链路。这样，在生产指标时，虽然底层数据源是一致的，但是指标加工时，也可能会因为逻辑的不一致导致数据的不一致。

这会带来时效性问题，以及准实时的计算和查询效率问题。因为通过 Iceberg 导入 ClickHouse 时，还会再经过一层 Hive 去进行落地，然后再用 load 的方式导入到 ClickHouse。整个准实时的流程就会长一些，造成时效性降低。同时开发效率，在整个 DWS 层同时存在流和批都需要计算逻辑时，会由于生产方式的差异带来生产开发效率以及人力成本的问题。

5. 湖仓一体主流趋势

我们调研了湖仓一体的组织趋势。第一个方式是数据湖加速查询，数据直接入数据湖，然后通过 OLAP 引擎直接查询数据湖，这种方式由于底层数据偏明细，查询数据量比较大时，查询效率会比较低，对应的计算成本也比较高。

第二种方式是湖上分层建仓，数据直接入湖，将热数据导入到数仓中，湖仓进行关联查询。类似于之前的明细数据导到数据湖，再把这些数据通过数仓的方式在湖上建仓，通过数仓进行分层建设，进行查询。

第三种方式是实时数仓的融合数据湖。数据直接入仓，冷数据导入到数据湖，湖仓进行关联查询。我们升级时也借鉴了二和三的方式。

第四种方式，就是基于现有 OLAP 引擎原生的湖仓能力，将 OLAP 架构转变成湖仓一体的架构，等于通过存算分离架构统一把湖仓搭建在一套原生的环境中，提供数据查询。这种方式我们还在探索中。

6. 湖仓一体 2.0 优化

基于以上内容，我们升级到了湖仓 2.0 的架构。主要解决一致性、时效性、开发效率和数据成本的问题。

时效性方面，我们引入了 StarRocks，简化了计算流程。准实时的链路通过Iceberg 直接到 StarRocks，减少了之前落地到 Hive 里面，再到 ClickHouse 的流程，可直接落地到 StarRocks，提供准实时的服务。同时，为了做到数据的一致性，我们把 StarRocks 的数据再导回到 Iceberg。这样整个离线和准实时的数据是一致的，也没有额外的开发成本，整个数据底座进行了统一，时效性也有所提升。Iceberg 的数据在下游，因为准实时要依赖 StarRocks，为使整个对外的数据服务统一，我们把 Iceberg 离线数据也向 StarRocks 同步。这样整个离线和实时的数据都在统一的查询引擎中。

通过线上的方式，优化之前预计算的方式，节省了相关的计算和存储成本，提升了开发效率。以上就是湖仓 2.0 的方案。

7. 引入 StarRocks 优势

我们引入 StarRocks，主要在于 StarRocks 在复杂查询、高并发和实时分析等OLAP 场景下能够提升分析效率。在批处理部分，它通过支持多引擎的查询加速、IO 合并、存算分离等，能够更好地支持我们现有的技术栈，同时也支持生产提速，简化了整个数仓的分层架构。

在实时数据部分，它支持实时数据接入，支持事务，可以提升数据可见性。因此我们引入了 StarRocks 作为整个湖仓 2.0 迭代的基础。同时我们做到了冷热数据的隔离，特别是在 StarRocks 往 Iceberg 同步时，实现了数据降冷的方式。通过包装 StarRocks 的一个 export 任务，实现了一套降冷的能力。把 StarRocks 的数据加工计算好，直接往 Iceberg 同步，实现了整个流批数据的一致，以及整个计算和开发效率的提升。在热数据部分，通过直接接入实时数据流，然后引入到StarRocks，实现数据的热加载。

我们对比了 StarRocks 内表查询，以及使用 Presto、StarRocks 查询 Iceberg 的效率。通过 StarRocks 内表查询的性能比 Presto 查询 Iceberg 和 StarRocks 直接 Iceberg 的效率都有明显提升。所以对外提供服务时，我们优先使用 StarRocks 内表的方式进行查询。

04总结&规划

最后对指标中台以及湖仓一体进行一下总结和展望。

1. 指标中台总结&规划

我们未来会建立以指标为中心，定义、生产、消费、质量保障为一体的指标驱动式数据消费的新模式。在指标生产部分，提供标准化配置化的生产。指标消费部分提供一次定义，多处使用。指标质量部分提供全链路全面的可观测和诊断。指标运营部分降低成本，优化指标生产消费的流程，最终形成以指标驱动的数据消费新模式。

2. 湖仓一体总结&规划

在湖仓一体部分，我们计划基于 StarRocks 的存算分离方案，对冷热数据实现自适应的管理，该存到数仓时上数仓，该加速查询通过 StarRocks 去查询，兼顾成本和效率两方面。同时通过物化视图替代传统 ETL 的建模流程，实现流批一体。在数据质量方面，打通多个平台的元数据信息，提供端到端的数据链路的完整性。在开发工具方面，打通多平台的开发，实现湖仓一体的快速交付。

05Q&A

Q1：您多次提到 MQL 的应用，实际上 MQL 在实践中难点比较多。想知道在真正的实践过程中，这里面有什么关键的思路和经验是可以分享的吗？

A1：提供 MQL，实际上想简化整个 SQL 的规范，正常 SQL 可能需要关联多个表才能查出来。我们通过自定义的一套 MQL 的模式，屏蔽了底层多个数据源，比如 MySQL、CK、Hive 里面，多个数据源进行融合。同时对用户呈现的可能是一张很宽的表，用户可以选指标、选维度去查，不用关心这些表之间是怎么关联的，来源于哪些数据源，从而简化用户的学习成本。

Q2：StarRocks 中存的是宽表还是窄表？

A2：我们对外提供指标服务时，是通过视图的方式把指标表和相应的维表进行关联。这样的好处是它不是一张特别宽的表，但也不是一个完全的窄表。我们会把相应的主题，比如播放相关的数据，存在一个对应的表里面。然后结合相应的维表，组成一个播放主题相关的宽表。

Q3：关于数据湖和数据仓库，刚刚讲为了时效性数据是直接入仓，然后数据怎么回流到数据库中呢？

A3：因为 StarRocks 计算和存储成本会比传统的 HDFS 高一些，所以我们不会把所有的数据都往 StarRocks 里去存，会将一部分历史数据导回到 Iceberg 中。我们通过 StarRocks 提供的 export 方式建立的一个导出任务，在空闲时间点，把StarRocks 的数据分批导入 Iceberg 中。这个 export 的任务，我们在腾讯还包装了一个任务，通过简化的降冷的任务，把数据导入 Iceberg。

本文来自公众号：DataFunTalk