海睿思分享 | 浅谈数仓指标体系管理

Posted 2023-04-04 海睿思

什么是指标？

指标，是用于衡量事物发展程度的单位或方法，也常被称作度量，通常情况下也是报表统计的字段，例如：人口数、营业收入、用户数、利润率、成功率、失败率、覆盖率等。

//

1

数仓指标的构成

❖ 数据域

数据域是统一数仓层的顶层划分，是一个较高层次的数据归类标准，是对企业业务过程进行抽象、提炼、组合的集合，面向业务分析，一个数据域对应一个宏观分析领域，比如采购域、供应链域、HR域等。

数据域是抽象、提炼出来的，并且不轻易变动，既能涵盖当前所有业务需求，又能在新业务进入时无影响地将其分配到已有的数据域中，只有当所有分类都不合适时才会扩展新的数据域。

数据域是有效归纳、组织业务过程的方式，同时方便定位指标/度量。

❖ 业务过程

业务过程是一种企业的业务活动事件，且是企业经营过程中不可拆分的行为事件，比如下订单、银行转账、账号注册都是业务过程。

业务过程产生度量，并且会被转换为最终的事实表中的事实。业务过程一般与事实表一一对应，也有一对多或者多对一的特殊情况，比如累计快照事实表就会把多个业务过程产生的事实在一张表中表达。

❖ 统计周期

统计周期即统计数据的时间范围，例如历史至今、最近7天、最近30天、最近1年等（类似于SQL中where后的时间条件）。

公共定义仅支持定义统计周期，定义时与数据域、业务过程、事实/维度表是否定义无关，在此仅作计算逻辑定义。

❖ 业务限定

业务限定是指除统计维度以外对指标进行限定抽象的业务场景修饰词，限定统计的业务范围，筛选出符合业务规则的记录（类似于SQL中where后的条件，不包括时间区间）。

业务限定也有归属的数据域，某个业务限定来源于一张事实表或维度表，继承来源表的数据域，比如限定词“江苏省”、“部门-销售事业部”等。

❖ 维度

维度是度量的环境，用来反映业务的一类属性，这类属性的集合构成一个维度。维度属于一个数据域，如组织维度（其中包括产品线、部门、科室、车间等）、时间维度（其中包括年、季、月、周、日等）。

2

数仓指标的分类

数仓指标分类主要为：原子指标、派生指标、复合指标、应用指标。

❖ 原子指标

原子指标是针对某一业务事件行为的度量，是一种不可拆分的指标，具有明确业务含义，比如支付金额。原子指标有确定的字段名称、数据类型、算法说明、所属数据域和业务过程。原子指标名称一般采用“动作+度量”方式命名，比如支付金额、注册用户数。

❖ 派生指标

派生指标可以理解为对原子指标业务统计范围的圈定，比如最近1年销售事业部销售金额（“最近1年”是统计周期，“销售事业部”是业务限定，“销售金额”是原子指标），1个派生指标=1个原子指标+统计周期+业务限定。

派生指标的构成

❖ 复合指标

复合指标是基于已经设计好的派生指标，设定复合计算逻辑而构成的指标。例如，一个已保存的派生指标A为最近1年销售事业部销售金额，另一个已保存的派生指标B为历史至今销售事业部在职员工人数，A/B即可以统计最近一年销售事业部人均销售金额。

复合指标的构成

❖ 应用指标

应用指标通常指从客户处调研得到，满足业务需要，最终要形成报表的指标，一般来源于派生指标或者复合指标。

3

数仓指标当前的痛点

❖ 命名不规范：存在含义不清晰、表述不正确、指标名称雷同，实际计算逻辑不一致，或者指标名称不一样，但是计算逻辑一致的情况。

❖ 口径不清晰：从用户处调研过来的指标口径描述不清晰，无法理解和实现。

❖ 指标稽核难：调研口径和实际逻辑没有明确、清晰的校验对比，稽核难度大，容易出现后面返工的情况。

❖ 呈现不直观：客户无法通过系统直观的看到指标业务流向，指标管理方式千差万别，有excel管理、ETL管理等。

❖ 结果跨平台：系统中治理完成的数据和指标无法快速数据分析，需要依赖于其他平台。

❖ 数据难追溯：业务血缘和数据血缘在系统中没有打通，导致应用指标进行数据溯源时较为困难。

4

面向业务的现代化指标体系

OceanMind海睿思 基于面向业务的现代化指标体系的理解，结合自身在大数据行业的技术沉淀，设计开发的S-DW智能数仓，通过建立企业数字化经营管理指标体系，实现经营健康情况实时、数字、可视化展示，纵向到底、追根溯源、高效辅助业务决策。

❖ 业务指标调研脑图线上呈现，统一管理，权限管理，可以做到调研结果的可视化、规范化、准确化。

【脑图体系】

❖ 业务总线矩阵，一键导入，线上管理和维护，快速构建数仓模型，提升指标建设实施效率。

【总线矩阵】

❖ 指标构建流程化，提供快速运算方式，为指标构建提高了效率，提升了准确性。

【指标构建】

❖ 提供了指标稽核能力，为业务逻辑和计算逻辑实现的一致性提供了稽核校验，方便人员审核。

【指标稽核】

❖ 提供了指标溯源、数据血缘能力，从业务指标层层追溯到源头业务数据，所见即所踪。

【指标血缘】

❖ 提供指标预览和预警功能，让企业运营风险及时掌握。指标全链路分析追根溯源，纵向到底，精准定位问题。

【异常预警】

 

【数据预览】

❖ 提供指标分析能力，支持多指标、多维度自定义构建，实时查看指标分析结果，可以将指标结果明细导出报表。

【指标分析】

5

总结

海睿思S-DW智能数仓，通过提供面向业务现代化指标体系，帮助企业进行指标规范化管理，规范指标的开发，维护好指标的计算口径和取数逻辑，为指标体系化构建赋能，为业务人员减负！

基于DolphinScheduler的使用浅谈数仓分层及模型设计

前言：本文旨在简单介绍DS的概述和架构上的设计，对其安装等不做展开介绍。之前了解了一下，很多小伙伴也在使用该产品。我呢，也是到现在公司后才开始接触并使用，对其 “开发” 的还不够深，这里根据官方文档和项目中的实践和大家简单分享。欢迎大家批评指正，敬礼！

一、简介

DS是分布式易扩展的可视化工作流任务调度平台。

Apache DolphinScheduler是一个分布式去中心化，易扩展的可视化DAG工作流任务调度平台。致力于解决数据处理流程中错综复杂的依赖关系，使调度系统在数据处理流程中开箱即用。

二、架构图

三、架构设计

1、名词解释

1.1、DAG：

​ 相信大家对这个次并不陌生，在spark和flink中都有这个定义。在DS中，工作流中的Task任务以有向无环图的形式组装起来，从入度为零的节点进行拓扑遍历，直到无后继节点为止。举例如下图：

1.2、任务类型：

​ 目前支持有SHELL、SQL、SUB_PROCESS(子流程)、PROCEDURE、MR、SPARK、PYTHON、DEPENDENT(依赖)，同时计划支持动态插件扩展，注意：其中子 SUB_PROCESS 也是一个单独的流程定义，是可以单独启动执行的。举例如下图：
注：左侧边栏看大的都是可调度执行的组件，畅用无限~

1.3、调度方式：

​ 系统支持基于 cron 表达式的定时调度和手动调度。

​ 命令类型支持：启动工作流、从当前节点开始执行、恢复被容错的工作流、恢复暂停流程、从失败节点开始执行、补数、定时、重跑、暂停、停止、恢复等待线程。其中 恢复被容错的工作流 和 恢复等待线程 两种命令类型是由调度内部控制使用，外部无法调用。举例如下图：

1.4、依赖：

​ 系统不单单支持 DAG 简单的前驱和后继节点之间的依赖，同时还提供任务依赖节点，支持流程间的自定义任务依赖。说到依赖想重点和兄弟们讨论下这个问题，但是文字表达起来比较费劲，希望各位兄弟可以留言，咱们针对具体问题一起聊聊。

1.5、补数：

​ 补历史数据，支持区间并行和串行两种补数方式

1.6、邮件告警：

​ 支持 SQL任务 查询结果邮件发送，流程实例运行结果邮件告警及容错告警通知

下图：是单独执行任务时进行的相关配置，我个人感觉补数功能是比较牛X的，用好系统时间的变量，造作起来吧（我也是这两天遇到了这样的需求，才 “开发出了这个功能”）。欢迎兄弟们一起讨论。

2、系统架构

2.1、系统架构图

2.2、架构组成、简介

• MasterServer

  MasterServer采用分布式无中心设计理念，MasterServer主要负责 DAG 任务切分、任务提交监控，并同时监听其它MasterServer和WorkerServer的健康状态。 MasterServer服务启动时向Zookeeper注册临时节点，通过监听Zookeeper临时节点变化来进行容错处理。 MasterServer基于netty提供监听服务。

• WorkerServer

  WorkerServer也采用分布式无中心设计理念，WorkerServer主要负责任务的执行和提供日志服务。 WorkerServer服务启动时向Zookeeper注册临时节点，并维持心跳。 WorkerServer基于netty提供监听服务。

• ZooKeeper

  ZooKeeper服务，系统中的MasterServer和WorkerServer节点都通过ZooKeeper来进行集群管理和容错。另外系统还基于ZooKeeper进行事件监听和分布式锁。

• Task Queue

  提供任务队列的操作，目前队列也是基于Zookeeper来实现。由于队列中存的信息较少，不必担心队列里数据过多的情况。

• Alert

  提供告警相关接口，接口主要包括告警两种类型的告警数据的存储、查询和通知功能。其中通知功能又有邮件通知

• API

  API接口层，主要负责处理前端UI层的请求。该服务统一提供RESTful api向外部提供请求服务。 接口包括工作流的创建、定义、查询、修改、发布、下线、手工启动、停止、暂停、恢复、从该节点开始执行等等

• UI

  系统的前端页面，提供系统的各种可视化操作界面

2.3、架构设计思想

一、去中心化vs中心化

中心化思想：

​ 中心化的设计理念比较简单，分布式集群中的节点按照角色分工，大体上分为两种角色：

• Master的角色主要负责任务分发并监督Slave的健康状态，可以动态的将任务均衡到Slave上，以致Slave节点不至于“忙死”或”闲死”的状态。
• Worker的角色主要负责任务的执行工作并维护和Master的心跳，以便Master可以分配任务给Slave。

​ 中心化思想设计存在的问题：

• 一旦Master出现了问题，则群龙无首，整个集群就会崩溃。为了解决这个问题，大多数Master/Slave架构模式都采用了主备Master的设计方案，可以是热备或者冷备，也可以是自动切换或手动切换，而且越来越多的新系统都开始具备自动选举切换Master的能力,以提升系统的可用性。
• 另外一个问题是如果Scheduler在Master上，虽然可以支持一个DAG中不同的任务运行在不同的机器上，但是会产生Master的过负载。如果Scheduler在Slave上，则一个DAG中所有的任务都只能在某一台机器上进行作业提交，则并行任务比较多的时候，Slave的压力可能会比较大。

去中心化思想：

• 在去中心化设计里，通常没有Master/Slave的概念，所有的角色都是一样的，地位是平等的，全球互联网就是一个典型的去中心化的分布式系统，联网的任意节点设备down机，都只会影响很小范围的功能。
• 去中心化设计的核心设计在于整个分布式系统中不存在一个区别于其他节点的”管理者”，因此不存在单点故障问题。但由于不存在” 管理者”节点所以每个节点都需要跟其他节点通信才得到必须要的机器信息，而分布式系统通信的不可靠性，则大大增加了上述功能的实现难度。
• 实际上，真正去中心化的分布式系统并不多见。反而动态中心化分布式系统正在不断涌出。在这种架构下，集群中的管理者是被动态选择出来的，而不是预置的，并且集群在发生故障的时候，集群的节点会自发的举行"会议"来选举新的"管理者"去主持工作。最典型的案例就是ZooKeeper及Go语言实现的Etcd。
• DolphinScheduler的去中心化是Master/Worker注册到Zookeeper中，实现Master集群和Worker集群无中心，并使用Zookeeper分布式锁来选举其中的一台Master或Worker为“管理者”来执行任务。

四、实践

注：这部分的话，我截图给大家展示一下吧，然后配一些文字说明，有感兴趣的小伙伴可以讨论哈。

先来介绍下我们这边大致的设计思路：

​ 按照数仓分层的思想，我们构建出了四个主要的项目。当然还会有一些其他的项目，包括临时需求、多场景取数等等吧。下面来重点看下这四个项目中内容：

1、dw_ods层

​ 看到这个名字，不用说，相信大家也知道是在做什么事了。对喽，就是你们想的那样。我来说下我们这边ODS层的设计吧（可能很乱，见笑了各位大佬）

对了，就是有这么多的ODS库，是不是很酸爽？基于工具的不能全局查找的特性，在不了解表的情况下，再加上运气背的话，可能要翻遍整个ODS的库才能知道你想看的表在哪个库下（哭瞎）~~

这么设计也是历史遗留问题了，很难再改变了。这就是所谓的按照业务系统的划分，在ODS落地时，也做了分库，并且基本是和ODS保持高度一致的。
其实从另外一面看待，这么设计也没什么问题。
也有了解过其他小伙伴们在ODS层的设计，其中有一种是将所有的ODS层表落到一个库下，但是在命名的时候，会按照业务系统进行划分。我个人觉得这两种设计各有利弊吧，不能绝对的说谁好谁坏~
另外还有一点，就是ODS层表的设计，目前我们是采用分区表进行存储的，并定期对历史分区进行删除，以保证存储空间和执行效率。当然也有把ODS层直接进行truncate再进行全量写的~看自己公司的设计理念和习惯了。

来给大家展示下，在DS中的设计：

这两张图非常清晰的展示了我们在ODS层的设计，懂得一眼就明白了，不明白的咱可以留言交流。

2、dw_dwd层

说下DWD的设计，在数仓中将业务流转换为数据流。根据业务过程划分出主题，采用维度建模的方式，将数据进行汇总，采用一些七七八八的手段，尽可能的提高dwd层表的复用性。

​ 在DS中，根据主题表创建不同的工作流：

​ 弊端：等主题慢慢膨胀起来，管理起来比较费劲

​ 好处：各自为战，清晰明了

来看上面图二：

​ 这是我们众多DWD表中的一张，在DS中，设置任务调度时，强依赖了DS中的依赖组件，并将DWD表中涉及到的ODS表增加至依赖中。这样做的好处，是比较精准的把控了每一张DWD表的动向。

3、dw_dws层

DWS层的设计也是比较明确的，基于DWD的层表，在同粒度的情况下，对数据进行汇总，然后形成主题宽表。
我们在设计这层的时候，严格按照数仓设计的规范：DWS层的表只能使用DWD的表进行关联汇总，坚决不允许出现跨层使用的情况。
如果在生产过程中，发现现有模型不能很好的支持业务的输出，会定期对模型进行小范围的重构（增减字段等），以保证模型的复用能力和“活力”。
在DS中，我们也是按照主题宽表进行分工作流设计的，如下图：

如上图二：在DWS中，我们也是按照依赖对工作流进行了设计。DIM层、DWD层都是在执行完毕的情况下，才能继续往下走。
PS：做任务依赖这点DS还是很香的，当然很多同学想用弱依赖来更加完美的配置工作流，但是目前DS貌似不支持，期待新功能早日上线吧。

4、DM层

设计完DWS层算是完成一大半工作了，DM层（或者叫ADS层）基本就是根据实际的报表需求，对数据进行汇总，最终由DM层将数据推到OLAP（目前我们使用的Doris，感兴趣的小伙伴可以一起交流下，哇咔咔~）供业务或者分析师使用。

5、DIM层

对了，差点忘了说，还有比较重要的一层：DIM层，即维度层。
在数仓建设的过程中，严格遵守一致性维度的原则。维度层的表是可以进行跨层使用的，下面展示下我们数仓分层的架构简图：

五、结束语

本文介绍了DS的架构原理和我实际工作中的使用情况，在我们整个数仓项目中，DS起到了至关重要的作用，使得开发效率明显提升，调度任务管理起来也更加清晰。
说一说我在使用过程中的心得吧，我个人个感觉，对调度的设计也是需要画个架构图提前规划的，不然随着需求的增加，项目越来越多，工作流越来越多，管理就变得困难了。提前做好规范，各位开发的小伙伴严格按照规范做事，即使会出圈也不会跑太偏。
本文篇幅有限，有些问题介绍也不是很深入，相信所有使用DS的小伙伴会充分挖掘它的功能，使开发变得更加容易。实际使用的功能还有很多，就不一一介绍了，有兴趣的小伙伴可以一起交流。
好了，此致吧，敬礼了~~睡觉了，晚安！！！