导读 本文将分享快手大数据分析在 NoETL 驱动下的功能实践。

主要包括以下五大部分：

　1. 快手大数据分析体系介绍

　　2. NoETL 对大数据分析的启示

　　3. 大数据分析 NoETL 功能实践

　　4. 未来规划

　　5. Q&A

分享嘉宾｜张型龙 快手 工具链团队负责人

编辑整理｜马同学

内容校对｜李瑶

　01

　　快手大数据分析体系介绍

　　1. 快手数据平台部

快手数据平台部的使命是提升数据决策效率，利用数据促进业绩增长。我们需要通过数据处理、数据挖掘、并借助一些产品工具为业务提供分析、实验和增长方面的解决方案。如何在快手海量数据的场景下提高分析、实验和决策效率，是我们一直面临的技术挑战。

从数平的职责中也可以看出，分析决策对业务至关重要，这也引出了快手大数据分析的使命：打造业界领先的一站式数据分析工具链，提供多样化分析场景解决方案，提升整体分析效率。目前，快手大数据分析对外提供的能力可分为两类：多元化产品和多形态服务。在多元化产品方面，我们既提供通用化的分析产品，即快手的 BI 系统——KwaiBI；也会针对特定业务需求提供更专业化、定制化的分析产品，即专题产品。此外，我们还提供多形态服务，针对常见的数据查询和分析场景，将这些能力通过接口形式提供给各业务使用。例如，在数据查询中常见的 KV 点查场景，以及通过 SQL 从数据表中查询数据的场景。以上分析能力不仅应用于数据平台部的各类平台，还可提供给业务方用于构建其特有的分析平台。目前，从服务角度来看，我们的 QPS（每秒查询量）已达到千万量级。从产品使用角度来看，我们的 WAU（每周活跃用户数）均在万级。综合来看，无论是在产品能力还是服务能力方面，快手大数据分析均处于业界相对领先的位置。然而，这一成就并非一蹴而就，是经过多年的功能迭代逐步实现的。

　　2. 大数据分析的痛点

在大数据分析系统建设过程中，我们遇到的主要问题可以总结为分析效率较低。举个例子，假设业务需要一个展示每个省份用户在线时长的看板，首先业务会提出需求，然后数据研发工程师进行口径核对来确定在线时长的定义，其次进行数据开发和校准，最后配置相应的看板以完成需求交付。在数据开发环节，可以进一步细分为基于原始数据开发在线时长的事实表和用户所在省份的维表，基于这些事实表和维表构建模型，并根据实际需求编写 SQL 语句，最终应用于可视化场景。基于上述距离，可以发现分析场景下的上开发模式较为固定，并且存在着一些问题：

开发周期长：通常以周为单位，一个需求从提出到实现可能需要一周或两周时间；

开发效率低：开发过程涉及大量的 ETL 处理，开发效率较低。

开发成本高：随着业务增长，需求变得复杂多样，面对大量数据处理工作，会消耗大量人力成本。同时，随着任务量或数据表数量的增加，所消耗的资源成本也会逐渐增加。

需求交付不灵活：当业务需要在不同省份的在线时长看板上新增点赞次数指标时，无法敏捷支持，需要重新走一遍整个流程。

　　02

　　NoETL 对大数据分析的启示

如何解决上述痛点问题？第二部分，我们将探讨 NoETL 对大数据分析的启示。

　　1. 什么是 NoETL

NoETL 概念早在 2010 年前后就被提出。近年来，国内对 NoETL 的讨论日益增多，国外的 dremio 和国内的 Aloudata 都属于在 NoETL 理念下构建的商业化平台。特别是 dremio，其官方文档中提到真正的 No ETL，而 Aloudata 虽基于 NoETL 理念构建了产品体系，但其推崇的 NoETL 并非完全摒弃 ETL，而是希望 ETL 过程更加透明化、智能化和自动化。

NoETL 旨在解决传统 ETL 存在的问题。如前所述，传统 ETL 开发周期长，快速迭代困难，开发成本高。NoETL 的目标是减少 ETL 工作量，以提升大数据生产和分析效率。个人对于 NoETL 主要有以下两个观点：

NoETL 并非完全摒弃 ETL，而是更倾向于 Smart ETL 或 Auto ETL。在当前发展阶段，完全无需数据开发和操作不太可能实现，但 Smart ETL 或 Auto ETL 意味着在整个数据处理链路上引入更多自助化和自动化能力，从而降低人工 ETL 的工作量，进而提高整体效率。

传统数据分析领域的业务开发流程相对固定，可以将分析领域的数据和服务标准化、规范化。以此为基础，在分析链路中不断提升自助化和自动化率，也就是降低 ETL 工作，实现 NoETL，可以解决大数据分析的痛点问题。

　　2. NoETL 对大数据分析的启示

由此，我们可以总结 NoETL 对大数据分析的启示。

首先，我们需要实现整个分析链路中数据和服务的标准化与规范化。其次，在构建的分析链路中，应不断提升功能或服务的自助化和自动化水平。最终减少 ET 工作来解决我们面临的痛点问题，从而提高分析效率。03

大数据分析 NoETL 功能实践

第三部分，将详细阐述在 NoETL 驱动下快手大数据分析的功能实践。

　1. NoETL 基础

首先，如前所述，分析链路中的数据和服务的规范化与标准化是实施 NoETL 的基础。（1）管理标准化、规范化

和业界方案一样，我们引入了指标中台，旨在实现分析数据与服务的标准化和规范化。指标中台的核心流程包括对指标维度、数据表和数据集进行管理，围绕这一核心流程，建立了质量监控和系统管理能力，以确保流程中数据和服务质量。需要强调的是，指标中台不仅仅是一个管理平台，更重要的是要将分析链路构建过程中的标准、流程和规范沉淀到平台上。我们不仅针对指标维度，还针对数据开发和整个数据服务制定了一套完整的规范，并将这些规范真正落实到平台上。在建设指标中台时，我们倡导的理念是“一处定义，多处复用”。这意味着定义一个指标后，不仅当前业务场景可以使用，还可以复用在其他场景中。这一理念背后实际上也体现了 NoETL 的思想，即避免重复工作，降低 ETL 的工作量，提高整体分析应用效率。（2）分析数据标准化

接下来将详细说明如何实现分析数据的标准化和规范化。此处目标是从物理表中的数据向上转化，最终形成指标维度，再映射到应用层的数据集。假设当前存在一个需求，即展示不同省份下在线时长的分布情况，在线时长数据及其省份维度分布在底层的不同物理表中。首先需要定义一些指标和维度，并将这些表与指标和维度绑定。在此需要补充的是，我们并非直接将物理表绑定到指标、维度上面，而是引入了逻辑表的概念。逻辑表具有两个作用：首先，它可以屏蔽底层物理表之间的差异；其次，它实现了指标与物理表之间的解耦。比如当需要替换底层的物理表时，我们可以直接替换物理表，而逻辑表以上层面无需任何变动。有了这些指标和维度后，接下来我们会基于维度建模理论自动构建一些模型，比如星型模型或雪花模型，以在线时长为例，它可以与省份等维度一起构建模型。结合业务需求，可以将多个模型构建成一个面向应用层的数据集。数据集中包含所有模型的指标维度，使用户在使用过程中便可以便捷地选择指标维度。通过这个例子可以看到，借助指标中台，我们实现了物理表通过抽象为逻辑表绑定到指标维度上面，通过自动化建模并基于实际需求将模型放入数据集中来供应用层使用，这样就完成了整个分析链路中数据标准化的过程。（3）分析链路标准化

数据标准化是数据自底向上的抽象过程。从服务角度来看，分析服务的实现实际上是一个面向用户自上而下的具象过程。我们需要将数据集映射回指标维度，并最终转换成实际的物理表执行语言。快手分析链路中最上层是 OAX（OAX 是快手的一种快速统一分析语言），能够简洁地表达用户的分析需求。我们将分析需求转换为面向数据集的语法树，然后通过分析构建和逻辑计划分析，识别出具体的数据集，并使用指标维度映射到的数据表，最终构建出物理执行计划并执行实际查询语句。例如用户有一个分析需求，希望分析过去7 天内一线城市电商 GMV 情况。我们将该分析需求抽象成关键要素：指标是 GMV，维度是日期和行业，它所在的数据集以及时间范围。这些关键要素可以转换成统一的分析语言 OAX。这种语言与具体的底层物理表无关，是面向数据集的分析语言。从图中可以看出，它类似于单表查询语言，即选择哪些指标维度 from 哪个数据集，再加上相应的筛选条件。最终，通过上述链路，进行数据解析、分析、构建等，转换成物理表查询语言。实际物理表查询可能会从多张表中查询出相应的指标并返回给上层业务。数据从底向上抽象，服务从上向下具象，通过这两条链路的建设，我们确定了整个分析链路上的数据和服务的标准和规范化。在此基础上，我们可以不断优化整个链路中的功能点，提升自助化率和自动化率，减少ETL，提高分析效率。

2. 指标中台落地情况

目前，我们的指标中台在数据和服务的标准化建设上已取得一些成果，无论是质量、效率还是复用度都有明显提升；在指标管理、分析服务、和运营等方面，都取得了不错的成效，为分析链路 NoETL 建设奠定了基础。

　　3. 分析链路典型需求场景

在整个分析链路上，典型的需求场景可以分为两类：一类是面向消费侧，另一类是面向生产侧，下面举 3 个典型的场景示例。场景一：灵活新增指标、维度。这是面向消费侧的一个典型场景。比如用户有一个在线时长的指标，希望对此指标进行分段，将在线时长 1 至 10 分钟的用户归为 A 类用户，10 至 20 分钟的归为 B 类用户，并希望统计不同分类下用户的数量。传统模式下，针对此类需求，我们首先需要进行 ETL 处理，为每个用户打上标签，标明其属于哪一分类，然后在最终分析时统计各类用户的数量。以下场景二和场景三是面向生产的两种典型场景。场景二：构建宽表。业务希望其业务域下的所有指标和维度能够关联起来，以便在上层进行多维分析。在传统模式下，我们可能需要通过 ETL 将所有指标维度构建成一张宽表，以便基于宽表进行自由组合和多维分析。这需要大量的 ETL 操作，在宽表中增加其他指标和维度也会较为繁琐。场景三：基于常见查询组合提速。在日常分析中，可能经常将某个指标与某个维度组合起来一起使用，但是这两个指标和维度可能位于不同的表中，为了提高分析性能，我们通常会将这些指标和维度加工到一张表中，然后通过这张表查询该指标和维度。这三种场景是分析链路中的典型场景，而传统的处理模式都需要进行大量的ETL 操作，且灵活性非常低，任何小的变动都需要重新走一遍处理流程，效率非常低。我们希望借助 NoETL 的思路，为这些场景提效。（1）自定义字段

为了解决场景一的问题，即如何灵活地新增指标和维度，我们提供了自定义字段的能力。以一个例子来说明，传统模式下，若要增加一个新的指标或维度，至少需要开发一个新的表或在现有表中添加新的字段，再绑定指标后在分析场景中使用。自定义字段功能解决的问题是，我们不再需要通过 ETL 处理来生成新的表或字段，而是可以根据上层的指标和维度组合生成逻辑指标，并基于这些新指标提供服务。这种自定义字段方式不仅减少了 ETL 工作量，而且提高了灵活性，允许在上层基于现有指标和维度配置出更多新的指标。例如，我们可以创建两个指标的简单累加，还可以进行维度拼接、字符串拼接，以及 case when 条件判断处理等。

我们还支持更复杂 LOD（level of detail）自定义字段，即在不同粒度下的数据统计分析。例如有一张表存储了每个城市不同性别下的发布作品数，如果我们要计算不同城市男女发布作品的占比，传统模式下需要构建一个 SQL 语句，通过两个视图关联后相除得到结果。在实际分析场景中，若要将占比数据作为一个指标，通常需要在原有表中增加一列：发布作品数占比，然后绑定到占比指标上供业务使用。现在，我们可以通过自定义字段减少 ETL 操作，只需在上层对 LOD 指标进行定义即可。这个表达式在实际执行过程中所转换的 SQL 语句与手动编写的 SQL 相同，保证了结果的正确性。通过这个例子可以看出，我们通过自定义字段减少了很多 ETL 操作，对分析效率和灵活性都有很大的提升。

目前，平台不仅支持用户通过代码模式配置自定义字段，也支持配置方式自定义字段，用户可以通过勾选拖拽来提高自定义字段配置效率。该功能解决了场景一的问题，即如何灵活增加指标和维度，而无需通过大量 ETL 处理来添加这些指标。

（2）自动化建模

针对场景二，业务希望将业务域内所有指标和相关维度关联起来，以支持上层的多维分析。当前我们可以通过自动化建模，可以将业务范围内的指标和维度通过维度建模理论自动化关联，在数据集范围内构建一个虚拟宽表，不再需要手动编写 ETL 语句来构建宽表。对于上层业务使用而言，指标和维度可以一起支持业务分析，而无需在底层构建宽表。通过这种模式，减少了 ETL 工作量，并且在虚拟宽表（数据集）中只需简单配置即可灵活增加其他指标和维度。自动化建模过程包括若干步骤，例如获取元数据，自动化建模服务（发现关联字段，最 佳路径计算，累加性计算），最终构建出模型。以一个实际例子来说明，我们有一些实体，包括事实表和维表，系统会根据实体自动发现关联，例如事实表可以关联到两张包含省份的维表，但我们会剔除从城市到省份的链路，找到路径，最终构建出模型。通过自动化手段减少用户构建模型的工作，降低人工成本。目前，自动化建模在整个分析链路中的占比超过 60%，在数据量大、指标维度范围广的情况下，自动化建模能显著提高建模效率。另外，通过数据集这种虚拟宽表的形式增加指标和维度，操作耗时都在分钟级别。

有了自动化建模，从分析角度来看，在整个查询链路中，我们需要从自动构建的模型中选择最合适的以提高分析性能。这一过程可以分为两个部分：模型筛选和模型排序。模型筛选是指从所有模型中找到最满足条件的模型。首先会基于当前分析需求涉及的指标和维度，找到满足条件的模型；然后根据数据范围、时间范围再次筛选满足条件的模型。基于筛选出的模型需要进行排序，找出查询性能最 优的模型，比如不同模型涉及的物理表可能来自不同的引擎，我们会优先选择计算速度最快的引擎，例如相比于 Hive 会优先选择 ClickHouse 中的数据，而 Druid 可能优于 ClickHouse 中的数据，或者在多维建模场景下，Cube 可能优于传统的 ClickHouse 场景等。基于这一套模型搜索能力，结合自动化建模，我们不仅提高了建模效率，降低了 ETL 工作量，还提升了查询性能。

（3）自动化加速

针对第三个场景，即在正常分析过程中，业务会发现某些指标和维度经常一起分析或使用。在传统方式中，我们会将这些指标或维度整合到一张表中，以提高分析速度。为了加速这一过程，我们可以通过手动或自动识别出哪些指标和维度经常组合查询，然后自动创建一张新表，并将这张新表重新注册并绑定回原来的指标维度，最终供分析使用。虽然构建新表的 ETL 过程并未减少，但我们通过更加自动化的手段，更高效地找到这些组合关系并生成新表。另一方面，自动生成的新表也会重新注册并绑定指标维度，用户无需进行其他操作。

自动化加速的具体实现如上图所示，核心模块包括智能化加速分析服务、自动化加速服务和元数据服务。根据上层不同的加速需求制定生产任务，并进行管理和运维，实现自动化加速能力。自动化加速解决了场景三的问题，即自动识别指标维度来构建小表来提高查询性能。除此之外，也适用于其他一些场景，比如支持整表加速，可以将 Hive 表数据一键转化为热引擎 ClickHouse 数据；基于大表加工成小表，剔除正常查询过程中不使用的数据，从而提高查询性能。目前，自动化加速在快手使用中也获得了很好的效果，加速任务量级达到千级，涉及加速的指标占整体指标量级的约 10%。实验表明，加速前后的查询性能提升可达 10 倍及以上。以上就是快手大数据分析在 NoETL 理论驱动下所做的一些工作，首先是通过引入指标中台，对分析链路上的数据服务进行了规范化和标准化，为 NoETL 在各个环节的应用打下了基础；另外，针对分析链路中的常见痛点场景，通过自定义字段、自动化建模和自动化加速，减少了 ETL 操作，实现了整体分析效率的提升。04

　　未来规划

未来，我们希望能够借鉴 NoETL 的理念，持续提升整个分析链路的效率。

首先，我们希望在未来能够实现更智能化的加速，基于历史查询情况进行智能化分析，找到全局最优的加速方案。在消耗一定资源成本的情况下，尽量覆盖更广泛的查询范围，以提高整体 ROI。其次，我们会不断拓展高级分析能力，支持更多高阶分析函数，满足更复杂的分析场景需求。在上层分析链路应用中，提高分析信息的密度。最后，我们希望实现分析与生产结合，将沉淀下来的标准化的指标和维度信息与生产领域打通，提升生产效率，实现大数据资产的整合。以上就是本次分享的内容，谢谢大家。

05 Q&A

Q1：在文章中提到了星型模型和雪花模型等专业术语，这些术语相对专业，可能需要具备数据仓库基础知识的人员才能理解。请问这些概念是否需要用户感知？普通用户能否使用您介绍的系统？

A1：确实，星型模型和雪花模型是数据仓库建模理论中常用的术语，数据工程师对此肯定非常熟悉。但在我们构建指标中台的过程中，这些概念对用户来说是相对透明的，用户无需感知我们后端自动化建设是星型模型还是雪花模型。因为我们通过自动化建模将指标和维度关联在一起，用户无需明确感知具体的模型理论。我们系统会自动将它们关联起来，并且我们通过工程化的方法构建最优模型，并评估模型的合理性。因此，对于普通用户来说，他们无需感知具体的理论细节，而星型和雪花模型的概念至少在数据建模或数据开发层面，是需要有明确概念的，也是指导我们指标中台建模的基础。

Q2：第二个问题是关于自动化加速功能，这是一个非常好的功能。但自动化加速会带来成本消耗，那么在成本和收益的平衡上，主要是基于什么样的思路来进行平衡？

A2：目前我们的自动化加速支持两种方式，一种是手动加速，这基于业务实际场景，如果业务认为这是一个高优先级场景，可能不会对成本考虑得那么细致，这时性能的考虑会大于成本，他们可以通过手动配置相应的指标和维度，生成加速表以满足业务需求。另一种是我们更自动化地分析，寻找最 优方案。在这种情况下，我们会衡量成本，包括查询覆盖范围和预估提升的性能量级，这个时候会找到一个相对均衡的点。在自动化加速前，我们也会尽量为用户提供选择，功能上会展示加速哪些内容、消耗的成本如何、预期提升的查询性能范围和效果如何，然后有一个用户确认的过程，综合考虑成本和性能，达到加速效果的最大化。