本文将从数据分析的发展历程和面临的问题，引出为什么需要通过指标去解决这些问题，并分享滴普科技指标中台的核心能力以及技术实践。

全文目录：

1. 现代数据分析的趋势及现状

2. 通过指标实现敏捷高效数据分析

3. 指标中台核心能力及技术实践

4. 结语

5. Q&A

01

现代数据分析的趋势及现状

首先和大家分享下数据分析的趋势及现状。

1. 数据分析及商业智能发展史

d2704b480db5e2138a1591eb525ab359_640_wx_fmt=png&tp=webp&wxfrom=5&wx_lazy=1&wx_co=1.webp

这里的商业智能指的是更广泛意义上的商业智能，不仅是大家所理解的可视化，也包含数据洞察和辅助决策。

商业智能（BI）这一概念始于1958年。在上世纪70年代到90年代间，BI经历了1.0和2.0阶段的发展。在2000年前后，形成了完整的理论及工具体系，出现了统一和寡头式的发展。到2010年以后，随着QlikView和Tableau的兴起，数据分析出现了巨大的变革，首先是由IT端逐渐转向由业务端等终端去完成；另外，由周报、月报、季报等报表分析逐渐转向归因分析等精细化运营分析。在这个过程中，数据分析人员需要具备统计、业务、数据等跨领域的知识储备，这样才能够迅速地根据数据分析结果解决业务问题，并推动数据为业务赋能。

2.数据分析主要趋势

f88fa49723be75caba2bfa2aece535ba_640_wx_fmt=png&tp=webp&wxfrom=5&wx_lazy=1&wx_co=1.webp

数据分析的未来，从数据需求层面和整体趋势层面分别有以下主要趋势：

（1）数据需求层面

①精确性

现有的数据分析不管是使用Tableau还是PowerBI等分析工具，都是通过数仓中的数据去创建分析模型，通过分析模型去处理数据分析，最终数据计算和指标定义是在这些分析工具中完成的。

由于企业中存在不同的业务体系及数据团队，当同时存在多个数据分析工具时，数据的可信度就会存在差异。比如销售量、销售额和利润率等指标在财务报表和销售分析中就可能出现不一致的情况，此时数据分析的结果是存疑的，精确性需要提高。

②敏捷性

随着业务的灵活发展，一些原有的经营指标，其生命周期由3-5年变得越来越短。特别是随着新的业务渠道和模式的出现，会引起一些原有的指标统计口径发生变更，分析维度会随着变更，原来的常规报表分析可能只需要5到10个维度，现在的报表可能需要10到100个维度去快速使用。

③实时性

目前的报表分析实效要求已经是天级，用T+1的数据生成报表，之前会有周报、月报的级别。目前业务人员开始提出T+0.X或者T+0的数据报表，以实现更好更及时的接触业务情况，促进业务发展。

敏捷性和实时性的结合将使得数据体系的复杂性越来越高，使得数据表越来越多。不同的业务场景会用到不同的数据中间件，一些金融性企业在Hadoop平台上甚至会用到10个以上的中间件。这种情况下，下游人员和应用将很难使用这些工具和数据。

（2）整体趋势层面

①全民数据分析

在ChatGPT等人工智能工具出现之后，全民数据分析将从概念被推进到落地，按Gartner预测在未来的2-5年所有人都将需要具备数据分析能力。

数据分析的整体逻辑将可能是通过对话的方式完成指标和数据的查询。数据分析人员将不仅仅是原有的数据分析师和IT人员，也将是一线业务人员，比如销售人员和客服人员，都将能够直接去完成数据分析。

②主动数据驱动

目前的数据驱动方式是进行数据展示，使用大屏、报表、数据面板等方式。一些数据分析能力较强的企业已经开始逐渐改变，由人找数变成数找人。

人找数：当业务人员有数据需求时，去数据平台上提申请，去描述需要什么样的指标，什么样的维度以及什么样的报表。
数找人：当一个业务事件发生时，主动向业务人员去推送相应的数据。比如每隔一个小时推送给销售人员在该时段内其关心的数据。

③AI增强分析

随着人工智能工具的变革性发展，主流的数据分析方式将发生改变，从现有的托拉拽的方式，转变为问答的方式。数据分析工具甚至能够直接给出相应的业务建议。滴普科技目前也在进行一些相关产品的实验。

3. 数据分析的现状

（1）数据分析的问题

6cac9bf7b8bb5a9ecb672c7f963dccc1_640_wx_fmt=jpeg&tp=webp&wxfrom=5&wx_lazy=1&wx_co=1.webp

从现状来看，数据分析主要有三个问题：

①找数难

目前数据量级越来越大，有可能达到PT级甚至是更大的数据量。数据结构越来越复杂，涉及到几千上万的表，分布在不同类型的数据仓库，比如Hive、Clickhouse、Doris等。

如何去快速拿到数据？如何验证存疑的数据？在具体的分析过程中，即使做了很好的数据治理，快速的找到准确的数据仍是非常困难的。对于一个成熟的企业来讲，可能需要2个小时去找到正确的数据。

②价值低

一些企业在建整个数据仓库或者数据湖的过程中，大量数据已经被存放到ODS数据贴源层。真正被使用到的数据却不到10%，特别是一些半结构化和非结构化数据，在国内这种情况更加突出。

③准确性低

因为使用的数据量相对较低，准确性低的情况在国内还不明显。但是在国外已经是主要问题。前文已提到，同一个指标在不同报表中就可能出现数据不一致的情况，需要花费大量的时间去验证数据，导致数据分析的工作内容变成了数据验证。

（2）人员的矛盾

16e967609346c23b09388b40379a0d57_640_wx_fmt=png&tp=webp&wxfrom=5&wx_lazy=1&wx_co=1.webp

基于上述问题，数据分析师和业务人员在沟通中会出现一些矛盾：

①受理周期长VS需求变化频繁

业务人员：你不能需求提出后1-2周才处理；

数据分析师：你不能今天确定指标内容，下个月就发生变化；

②数据实效性低VS资源紧张

业务人员：我需要T+0或者T+0.X，不是T+3也不是T+1；

数据分析师：我资源有限无法承担过量工作内容；

③数据使用难VS直接用

业务人员：我需要可以直接使用的数据，而不是直接使用的SQL脚本。

02

通过指标实现敏捷高效数据分析

1. 目前大数据平台如何完成数据分析

（1）目前数据分析方式

46aa349572d9100d4e22cb2008761406_640_wx_fmt=png&tp=webp&wxfrom=5&wx_lazy=1&wx_co=1.webp

接下来大概介绍下，在数据分析过程中如何完成各项处理。一个新的指标定义的模式有两种：

①直接定义

跳过数据仓库使用原始表或者使用清洗后的DWD层数据表（明细事实表）直接在BI完成指标的定义。

②通过汇总表定义

在数据仓库上根据指标需要的一些维度提前完成轻度汇总，然后根据汇总表在BI进行分析和定义。

这种模式数据精确性高，更可靠；缺点是汇总表与维度的耦合性高，维度发生变化后，汇总表需要进行重构，从而影响到下游使用该表的应用。分析师更愿意新增一张汇总表，这时旧的汇总表将持续占用工作空间。

（2）目前数据使用矛盾

a73e9c136b3f761d98f17e0f1a006938_640_wx_fmt=png&tp=webp&wxfrom=5&wx_lazy=1&wx_co=1.webp

此时数据的膨胀和业务的灵活性也形成了一个矛盾：数据量更多，数据结构更复杂，数据湖和数据仓库更庞杂；而业务变化更敏捷。这也是前述数据使用和数据开发的矛盾产生的原因。

①数据使用

数据消费门槛高。同样的一个指标只要一个数据结果，而不是分散在多处的，需要自行join处理。

②数据开发

有些数据指标仅仅存在于分析过程中的SQL里，未及时沉积。当其中一个数据指标发生变化时，可能需要修改无数张实际对外的ADS层数据表。于是，各平台中、各BI中、各下游应用中会出现大量的歧义数据。

2. 建立统一语义层

（1）数据开发视角

8fd23a31e83977896d9d225eb25158bf_640_wx_fmt=png&tp=webp&wxfrom=5&wx_lazy=1&wx_co=1.webp

如何解决这些矛盾，目前的共识是建立统一语义层。

统一语义层通过虚拟视图（虚拟仓库）解决了逻辑层和物理层Mapping，并统一面对下游用户完成统一指标定义。此时上游自动完成数据匹配，下游用户无需关心数据来源。

（2）数据使用视角

fa05b097f0fc680521adce3ca96018a6_640_wx_fmt=png&tp=webp&wxfrom=5&wx_lazy=1&wx_co=1.webp

建立统一语义层后，数据已经完成整体隔离。业务将不再通过数据库访问数据，可以直接从指标中获取相应的数据。

如上图案例所示，数据分析师完成指标目录创建后，业务人员可以直接使用他们熟悉的术语进行指标探索，比如入货额、退货量、客户增长率等。业务人员明确指标以及相关维度、时间范围、数据粒度后，自动完成指标分析。

统一语义层接入方案中，数据输出时基本于传统BI一致，区别是已无需再关心指标来源和定义方式。

3. 最终目标：敏捷高效

b56ffa13cbe6f573c212d8db289da59a_640_wx_fmt=png&tp=webp&wxfrom=5&wx_lazy=1&wx_co=1.webp

最终的目标是在指标目录中选择指标后，能够快速完成指标探索。用户无需关心数据来源，不管是来自多少数据表还是来自多少数据源；可以更多的去关心业务，真正的对业务赋能。

统一语义层也被称为指标中心或者指标平台，其核心意义就是让业务人员忽略源头关注结果，实现低门槛高效率。

03

指标中台核心能力及技术实践

对于统一语义层统一接入方案，滴普科技也总结了一些经验，形成了一些产品。

1. 指标平台架构

74e384f5b242316908bd64a7cd88c2ff_640_wx_fmt=png&tp=webp&wxfrom=5&wx_lazy=1&wx_co=1.webp

指标平台整体结构分为两层：一层是指标中心，一个是数据门户。分别面向两类人群：数据开发人员和数据使用人员。

（1）指标中心

面向数据开发人员。数据分析师通过统一语义模型建立模型定义指标，发布到数据门户。

根据实际需求，可以进行定义指标加速，配置相关监控。

（2）数据门户

面向数据使用人员。业务人员能够快速的查询指标，快速的业务探索，创建相应的标签、大屏和报表，分享到钉钉、飞书等下游应用或者连接到FineBI或者FindReport等下游工具。

下游不同的应用和工具通过统一的数据门户访问数据，同样的指标获取同样的数据，保障了数据准确性。

2. 基于指标的数据分析协作流程

d185238a81647aec7c2bf9651aaf3654_640_wx_fmt=png&tp=webp&wxfrom=5&wx_lazy=1&wx_co=1.webp

基于指标的数据分析协作流程可以梳理为两步：

（1）数据开发人员工作

根据取数需求，完成模型和指标的新增或者修改，发布到数据门户。

（2）数据使用人员工作

在数据平台，完成数据指标到发现与探索，以及大屏和报表的创作，并连接到外部应用。

基于指标的数据分析协作流程实现了数据资源的隔离。不管是ClickHouse、Hive还是PostgreSQL、Kafka中存储的数据资源，都能够被有效隔离。用户只需要关注指标。

3. 实现数据资源隔离

fff677e4f281cb554d43050211808f0f_640_wx_fmt=png&tp=webp&wxfrom=5&wx_lazy=1&wx_co=1.webp

具体如何实现数据资源隔离，下面继续进行分享：

（1）智能查询路由

首先是核心逻辑，需要实现智能查询路由。智能查询路由能够根据指标智能路由到不同等数据层级。目前提供了3个层级的数据查询：

①即席查询

当指标数据没有进行任何的加速和缓存的时候，会生成原有数仓的查询SQL。

②主题加速

如果配置了相应的主题加速，会在主题加速层完成亚秒级配置，目前是4-6次。

③查询缓存

针对的场景多是数据应用的首页或者常规的排名查询，能够通过查询缓存层实现毫秒级，目前能达到10-30ms。智能查询路由给指标平台带来最大的改变是，下游用户无需再选择查询层级和数据表，只需要制定指标和查询条件。智能查询路由进行自动路由，实现了数据消费时速度和敏捷性的平衡。

（2）统一查询入口

不同下游应用包括BI商业智能、SDK应用、API应用等，通过不同的interface连接到统一查询入口。然后再通过统一的查询语言进行指标查询。

4. 实现统一查询语言

bd9ac72fd697ff1071ae69f82fe07a64_640_wx_fmt=png&tp=webp&wxfrom=5&wx_lazy=1&wx_co=1.webp

首先，下游Client的不同查询语言都被转换为MetricsQL（指标查询语言）标准的查询语言。然后，QueryEngine（查询构建引擎）根据已经完成的模型和指标进行数据源的SQL构建。如果配置了指标加速，QueryEngine就会完成加速层的SQL构建。另外，统一的查询入口也支持进行数据权限管理。

f4cdeabee6c70bb5cf56a3154a6fb3c6_640_wx_fmt=png&tp=webp&wxfrom=5&wx_lazy=1&wx_co=1.webp

QueryEngine通过指标的定义自动生成不同平台相应的查询SQL脚本，并支持智能路由查询相应的数据层。

5. 实时指标方案

17647f320fec5cc92dfa4cf5f809f1bd_640_wx_fmt=png&tp=webp&wxfrom=5&wx_lazy=1&wx_co=1.webp

目标是实现T+0实时指标方案。业务数据通过CDC等方式进入实时数仓，通过指标语义模型完成语义查询，最终形成实时指标洞察和实时指标服务，给到下游应用。

04

结语

整个分析过程中，统一查询入口保障了精确性，智能查询路由保障了敏捷性，实时指标方案保障了实时性。

最终目标是满足全民数据分析的需求，让任何人都能以想要的方式去快速访问数据。在这个过程中，他无需具有大数据的基础知识储备就能完成数据的整体分析。即使上游数据是很复杂一个Hadoop体系，他也能完成这样的分析。

05

Q&A

Q：在构建统一语义层的时,会存在两层逻辑:一层是命中加速层，一层是非命中加速层。对应的物理存储引擎上可能会有一定的差异，这种差异是如何处理的？

A：上游数据源基本上都会存在差异。首先是查询语言已经被转换为MetricsQL标准的查询语言，QueryEngine去完成语法树的重新构建；然后去适配不同的数据源，去完成每个数据源语法树的适配。在这个过程中，实现插件式的适配能力，目前已经适配了5种数据源，仍在持续更新中。

以上就是本次分享的内容，谢谢大家。