快手大数据平台：以数据治理激活数据价值，赋能业务发展

导读：

大数据是企业发展的重要生产力，在快手我们希望以领先的大数据技术，激活数据价值，赋能业务。要建设有价值的大数据，则要做好数据整治。数据整治是一套体系方式论，包含组织、制度、流程、工具。快手仍然将数据整治作为重要的数据基建，尤其是在质量方向更是作为大数据的基础生命线。快手提出了数据质量的整体解决方案，又探求了以数据管理驱动数据服务（即指标管理+指标服务OneService）的奇特解决方案，实现一处定义，多处使用，解决了业界在数据消费锥面临的数据不一致困局。

本文是快手数据平台在InfoQ2022/08月的广州ArchSummit专题分享内容整理，分享内容为快手大数据平台在数据质量方向上的实践经验，主要会围绕下边四点展开：

01快手大数据平台介绍

快手作为业界背部的短视频+直播的平台，大数据是作为快手业务发展的驱动力。快手大数据平台使命是：以领先的大数据技术，激活数据价值，赋能业务，构建快手核心竞争力。在组织上，快手大数据平台采用“平台+BP组织”的组织阵形，数据平台以平台型部门纵向支持全公司所有的数据业务。相比于业界而言，平台型组织可以将数据进行充分联接，防止各数据孤岛。但也会面临平台与业务之间的部门墙问题，所以引入了数据BP模式。最终，快手通过这些组织阵形解决了数据孤岛、部门墙问题，让数据在快手连成一条线、一个面，赋能业务。

有了组织阵形的基石，在数平内部的推动思路是“统一化建设”，自顶向上，从顶楼设计数据新蓝图，之后到各团队充分对齐并推动：

在数据库房上，采用1横+N纵的思路，1横表示公共数据，在公共数据之上长出N纵业务数据，使各业务数据纵向互相能联接上去；

在数据系统上，快手构建了全链路的数据产品矩阵，包括数据生产（天工）、数据剖析BI（KwaiBI）、APP剖析、AB平台等产品能力；

在规范流程上，由数据内容团队主导制订了统一的数据规范，工具承接规范，让规范落到具体工作流程中，而不是逗留在纸上；

在数据规模上，通过短视频、直播，快手每晚会形成海量的数据：每天数据新增量达到PB级别、总数据量达到EB级别、日作业量在十万级别。结合快手多场景的用户服务产品以及海量的数据，给快手大数据建设带来不小的挑战，不言而喻，在质量方向上也是挑战巨大。

通过对组织的不断更新迭代以及技术上探求思索，快手在数据方向已然初步完成了数据大基建，朝着下一代数据智能迈向。接出来我们重点来介绍：快手在数据质量方向上的实践和探求。

02快手数据质量整体解决方案

1.数据整治与数据质量背景介绍

首先介绍下数据整治、数据质量的概念。国际数据管理商会DAMA、DGI、工信部、以及信通院等组织都对数据整治给出了相关定义。总结而言，数据整治的最终目标是提高数据的价值，是企业实现数字战略的基础，是由组织、制度、流程、工具组成的数据管理体系，这进一步说明大数据的建设并非是只依赖技术，须要一套体系框架。

对于数据质量领域，可能对于一些非大数据朋友不太理解：数据质量为何如此重要。这儿我们模拟举些常见案例：

通过以上介绍，你们能直观感遭到，数据质量是数据的生命线，也是企业的生命线，它可以影响企业形象、收入、决策等。

这么怎样做好质量呢？在DAMA的数据资产管理蓝皮书中，对于质量给出了6个核心描述维度：

1）完备性：储存数据量与潜在数据量的比率。

2）惟一性：在满足对象辨识的基础上不应多次记录实体实例（事物）。

3）及时性：数据从要求的时间点起代表现实的程度。

4）有效性：如数据符合其定义的句型（格式、类型、范围），则数据有效。

5）确切性：数据正确表示实体的“真实”程度。

6）一致性：比较事物多种叙述与定义的差别。

这种理论框架可以给我们数据质量工程化做好指引。简化而言，我对数据质量的理解，就是数据须要准时+确切的产出。

2.快手在数据质量面临哪些问题

要做好数据质量，我们则要晓得数据全链路的质量问题在那里。一般大数据的全链路包含：数据源->数据集成->数据库房->在线数据库->数据服务->数据应用，其中数据服务与数据应用环节，可能会存在两条链路。详尽看各环节在质量上面临问题如下：

1）数据源质量：埋点质量不高，误报、漏报等诱因，或则因为业务DB存在脏数据或则字段变更等诱因，数据集成环节会有数据重复，数据遗失等质量问题；

2）数据集成质量：数据同步过程中没有严格的保障exactonce，造成数据被重复同步，以及在数据同步过程中数据发生了遗失；

3）数据库房质量：存在估算口径不一致，数据更新不同步，数据刷新不同步，任务延后破线等数据质量问题；

4）数据分发质量：存在库房和在线数据库刷新不同步问题；

5）数据服务/应用质量：指标口径不一致，指标命名不一致等问题也无法控制。

在快手的实践中发觉：在数据消费端（数据服务/应用）中形成的问题会比较难控制，由于数据消费端的用户体量会比较大，而且会直接影响业务、用户。所以在快手：我们既有整体的质量解决方案，为质量领域划定了顶楼新蓝图，又有重点要突破的质量问题：数据消费端的质量问题。

3.快手在数据质量整体解决方案

质量问题是一个领域问题，所以须要有体系化的解决方案，在快手我们开始就规划了数据质量顶楼方案。快手在数据质量上提出了“工具+规范+组织”三位一体化解决方案，通过“数据质量故障数”北极星指标不断牵引数据平台提高，以下对整体方案进行详尽介绍：

在组织层面：在数据平台有质量团队，负责整体规范的制订，以及促进质量工具化落地。

在实践中发觉，在百花齐放的数据产品端，各个产品间的数据不一致问题曝露尤其显著，所以我们要重点突破解决“数据消费端的数据一致性问题”，因此我们在数据平台级别，发起了指标平台的专项项目。这块业界各家解决方案不尽相同，快手通过指标平台挺好的解决了这部份问题，所以我们重点介绍这指标平台对数据质量的解决方案。

03快手指标平台的建设

1.指标概念介绍

一般我们都在讲业务数据化，其中数据化就是指标化，进一步说明，我觉得指标可以通过三方面来解释：

1）数据的抒发：指标是对于数据的抒发，我们每日观测的GMV、DAU等都是指标；

2）统一语言：让公司内部各部门之间以“统一的数据语言”交换数据，让你们在概念认知层面对齐；

3）逻辑具象：在大数据引擎之上建立的逻辑层，可以将上层技术与下层用户进行前馈合。

也有人提出“指标是数字化时代的管理语言”快手在线自助业务平台，这句话非常突出了指标对于大数据领域的重要性。在现代数据栈中，指出了数据自主化，这么怎么让用户高效、准确的自主使用数据，我觉得指标平台的发展是现代数据栈发展的重要驱动力，另外我们还注意到了一些其他新技术趋势，包括HeadlessBI、统一语义层、智能建模以及低代码，还有一些商业化产品GoogleLooker、Transform、AirbnbMinerva等重点指出了“singlesourceoftruth”。由此可见：指标是大数据更高效、更高质的数据生产与剖析效率的源动力。

2.快手大数据服务面临的质量问题

快手数据服务面临问题主要是存在水塔式数据服务建设，水塔建设带来的问题：各业务数据之间命名不一致快手在线自助业务平台，口径不统一，出口不一致问题问题尤为显著。

3.指标平台对数据服务质量整体解决方案

要解决3个不一致问题，须要从数据服务源头解决，可以将数据服务控制在一个服务，同时严格保障该服务的数据质量，使该平台提供的数据保持高质量，即实现“一处定义，多处使用”的HeadlessBI平台理念，总结出来快手的方案包含：统一指标管理、统一指标监控、统一指标服务，这儿更想给你们分享的是，我们实现了三层保障，层层递近。

第一层保障：指标定义保障，其核心目标是让指标定义惟一，通过在定义时防止重复定义

“统一指标管理”即指标定义惟一，包含指标统一化管理、指标命名惟一性。在快手我们定了《数据指标体系标准化管理规范》，在规范中明晰以下核心要素：

第二层保障：指标质量保障，其核心目标是让指标准时+确切的产出

“统一指标监控”保障的是指标视角的质量，通过指标的元信息，系统推导入背后关联的表：

第三层保障：指标服务保障，其核心目标是让指标调用惟一，即在使用时防止

“统一指标服务”即指标服务出口统一（指标服务OneService），经过上面两层保障，我们将数据定义以及估算口径都保障确切，最终目标是让下层所有应用端产品取出的数据确切。通过指标管理驱动指标服务，下层应用都通过指标服务调阅数据，从而实现统一OneService。

4.快手指标平台关键技术

指标平台是介于数据仓/数据湖与数据应用之间中间件，建立在各类估算引擎（Hive、Spark）、OLAP引擎之上（Clickhouse、Druid），对下层调用方提供面向指标/维度的服务化能力，须要将指标/维度翻译为引擎查询语言。

在其中涉及到一些关键技术：首先是须要面向具象一套指标/维度语言；其次是须要建立表与表之间的关系，用于翻译查询语言，我们叫数据建模；之后是找表，通过系统取代人工查找表，我们叫模型搜索；最后是代码生成，我们须要翻译为不同引擎的查询土语。下边我们依次介绍各项关键技术的设计。

（1）统一语言具象

在指标体系下，我们具象统一服务语言主要解决两层问题：

面向引擎的统一查询语言：须要支持联邦查询，业界有的建设思路是具象一套SQL句型，然而该方案会成本较高，由于不同引擎的Native句型兼容成一套句型，会是一个巨大的工程量。所以我们在此基础上进行了迭代思索，采用简化SQL句型+编排句型，简化SQL句型支持简单的跨引擎Join、Union算子，而编排句型基于BPL思想，通过类似于业界最新提出SubstraitDSL描述化学执行计划；下边给出简单的事例：

// 简化语法SELECT   table_a.api_name,   table_b.job_descriptionFROM CLICKHOUSE_CATALOG.public_hdd.one_service_job_df as table_aJOIN HIVE_CATALOG.ks_data_factory.one_service_meta as table_bON table_a.id = table_b.job_idWHERE table_a.id = ${job_id}
// 编排语法input {  groupId: 111 // 开发组信息  userName: "xiaozhang"; // 用户信息}
operators {  // 查询 Redis  operator op1 {      type: REDIS,      lang: OneSQL,      query: "scan 0 match dp12:* count 20"  }
  // 查询Hive  operator op2 {      type: HIVE,      lang: OneSQL,      query: "select uid, name, age from people"  }
  // 联邦查询节点  operator op3 {      type: FEDERATION / EXCHANGE,      lang: OneSQL, // 可以不用显式写      query: "select *               from clickhouse.db.table a               join mysql.db.table b on a.xx = b.xx              join operator.op1 c on a.xx = c.xx"  }}
output {    return: op3}

面向指标的统一查询语言：指标查询语言会比表查询更简单，由于指标估算逻辑早已被封装在指标平台进行管理，所以愈发简练，查询方不须要写估算逻辑。为此我们采用查询5要素进行描述：数据范围、时间范围、指标、维度、过滤条件，同时我们支持一些二次估算能力。该语言与面向引擎的统一查询语言的差别，在于会愈发简练。

SELECT  GRANULARITY(__time, 'all', 1),  ks :metric :gaia / query_cnt), // 指标：查询次数  ks :metric :gaia / query_cost), // 指标：查询耗时  tb(`ks :metric :gaia / query_cnt`, 'DAYS', -7) // 二次计算：同环比FROM  data_set_name // 数据集名称WHERE  CONTEXT_WHERE __time >= '2022-10-17 00:00:00' // 上下文筛选器  AND __time <= '2022-10-21 23:59:59'  AND ks :dimension :gaia / from_app_module NOT IN ('BI平台') LIMIT  5000000 OFFSET 0

（2）手动化建模

首先我们讲一下哪些建模，业界都在提数据建模，一般提的数据建模业界有两类数据建模：一类是面向数据生产的建模，基于指标/维度进行维度建模，常见的国外云厂商都有相关的产品方案；二类建模是面向消费的BI数据建模，一般还会是基于关系建模，像业界的PowerBI、Tableau等都有建模能力。我们此处介绍的是面向消费的数据建模，其核心目标是建立表与表之间的关系，有了该关系，系统可手动化生产查询代码。

快手采用的是手动化建模模式，基于指标/维度的预置管理元数据，手动化发觉表与表之间的关系。在技术上，须要考虑：

（1）模型多路径：假如模型存在多条可达路径，则此时我们须要路径剪裁；

（2）累加性推论估算：一个指标在一个表上可能是全可累加、半可累计以及全可累加，须要基于表与表之间的关系进行推论，推导入指标与维度的累加性关系。针对累加性，如下表格案例，用户数在性别维度上可累加，在城市上不可累加，以下为单表的情况，若果sex可关联维表，则须要推导入维表的累加性。

列

列名

city

城市

sex‍

性别‍

uv

用户数

（3）模型搜索

类比于搜索引擎，搜索引擎通过给定Query检索出最佳结果，在大数据领域的搜索引擎，我们的目标是基于“指标/维度”的Query，搜索出才能估算出该指标/维度的最高效率模型。

在搜索过程中须要充分应用表的元数据，对于模型的估算Cost进行预估，最终选择最佳模型。我们采用RBO+CBO结合来选择最佳模型：

（4）代码生成

代码生成模块是将数据模型翻译为数学引擎可执行代码，通过代码生成来达到系统手动化，无需人工写代码。

为了屏蔽不同引擎的差别性，首先将数据模型转化为具象句型树，再应用优化规则进行调整，最终得到最佳的查询代码。在生成最佳代码环节，须要结合引擎Native特点+表元信息（表的行数、维度的基数、值分布等），针对不同的场景调整执行计划，在平台中沉淀了30项的优化规则。以下给出几个规则案例：

引擎

策略描述

说明

druid

虚拟列改为lookup

对于casewhen查询转为lookup查询

druid

filteredaggr应用

对于指标带过滤条件，使用filteredaggr查询，不使用虚拟列

clickhouse

countDistinctIf

精确去重常见，部份常见使用countDistinctIf函数，不使用count（distinct）

clickhouse

join次序调整

维表过大，使用维表join事实表

5.快手指标平台总结

快手指标平台经过2年的建设，在快手进行全面推广，领到了较好的利润。

服务模式升级：指标平台在数据消费端是促进了消费端的模式升级，由UGC模式升级为PGC模式：在UGC模式下用户在剖析时刻，须要各自定义指标口径；而在PGC模式下，由平台定义好指标口径，用户可直接基于指标/维度数据剖析。

全公司全面使用：快手指标平台在公司范围内进行全面的落地推广，所有核心业务全部接入指标平台，渗透率达到60%+。相比于业界指标平台的方案，快手指标平台具备奇特性、创新性：

04指标平台的未来

明天，整个大数据行业都在提DataFabric、现代数据栈，本质上是现有的集中式的、人工的数据库房建设模式，已难以满足“人人都须要剖析数据”的诉求。所以面向未来，大数据一定是去中心化的剖析模式—自助化模式演变，而大数据生产也会朝着从重ETL到SmartETL的演进。这两种演变方向，其背后的核心驱动力是须要来自数据管理，DataFabric定位“数据管理的未来”，这儿的数据管理是对于数据语义的管理，有了数据语义化，我们可以做到：向下驱动消费，向上驱动生产，建立指标驱动的数据全链路。

同时，我们希望促进这套体系的标准化，产出大数据语义化蓝皮书。基于此蓝皮书，建立大数据语义化建设生态。包括：面向语义的逻辑语言，业界在该方向已然有好多现有的案例，比如GoogleLookML/Malloy、PowerBI的DAX、TableauLod等，

在快手我们基于OneDSL理念，重新拆解了语言体系，包括面向语义化的开放剖析查询语言KwaiOAX（OpenAnalysisExpression）、面向化学联邦查询语言KwaiFQL（FederationQueryLanguage），未来希望将两套语言逐渐开放；

近一步会逐渐加快整套体系智能化，包括从手动建模演变为手动建模，智能查询优化，智能数据加速等。

作者简介：

刘一凡，2020年加入快手，有大数据和搜索领域工作经历，当前主要聚焦在大数据领域，对相关的开源技术以及行业趋势持续保持高度关注，过去在数据整治、数据质量、数据服务、数据应用、数据管理、BI剖析产品等大数据中台化方向有较丰富的经验。

快手数据中台团队介绍：

快手核心大数据中台团队，为全公司建立业界领先的智能大数据生产和剖析平台，赋能全业务线提高公司数据创新效率。目前涉及方向包括数据开发工具链（离线和实时数据开发平台、数据同步、大规模工作流调度、全链路质检平台）、数据服务工具链（智能指标模型平台、百万级并发数据服务化平台）、数据剖析工具链（一站式数据剖析平台、专题式数据剖析产品）、数据管理工具链（全链路元数据平台、资源管理平台、数据地图、数据安全平台）。也欢迎优秀朋友加入我们！