数据中台项目

项目编号：

   2023年数据中台项目

建

设

方

案

项目编号：2023-XX-XX

编制单位：XX市XX中心

编制日期：二〇二三年四月

目录

第2章元数据中心

1.系统、全面地查询元数据信息

⒉.变更评估及精准变更周知

3.协助数据问题定位及解决

2.1元数据中心概述

2.2元数据中心的核心功能

第3章数据指标中心

3.1数据指标中心概述

3.2数据指标中心的设计思路

第4章数仓模型中心

4.1数仓模型中心概述

4.2数仓模型中心的设计思路

第5章数据资产中心

5.1 数据资产中心概述

5.2数据资产中心的治理流程

第6章数据服务中心

6.1数据服务中心概述

6.2数据服务中心的设计思路

数据分析篇

第7章数据分析理论

7.1业务和数据

7.2 数据分析师的全貌，

7.3 数据分析团队的组织架构及其对应的工作模式

7.4数据分析师的工作方式

第8章数据分析实操

8.1 预测性分析

8.2描述性分析

8.3诊断性分析

8.4 数据分析报告

数据应用篇

第9章BI系统

9.1让人头疼的看板需求

9.2 BI系统介绍

9.3 BI系统的关键技术

9.4 BI系统实践

 

第2章元数据中心

老汤姆:“在上次月会复盘时，大家反馈了一些问题，如表信息等无处可查，在表字段信息发生变更时难以评估对下游的影响等，而且常常上游执行变更了，下游却未收到变更通知。”

小风:“嗯，确实是，目前对于数据平台相关信息的查询主要是通过人问人或者Wiki(内部文档平台)等进行查询的。同时，在每次发生变更时，我们都在尽全力进行周知，但因为缺少血缘链路，一方面我们在进行周知时，可能有遗漏（原本应该被周知到的下游未被周知到，导致部分变更工作的衔接脱节);另一方面我们可能对下游造成不必要的打扰（原本本次变更不会对该下游产生影响，但因怕遗漏，所以我们无差别地对其进行了周知)。“

老汤姆:“那针对这些老大难问题，你是否有系统化的解决方案呢?“

小风:“是的，目前我们正在规划元数据中心，有了元数据中心，我们就可以较好地解决这些问题。”

1.系统、全面地查询元数据信息

通过元数据中心，我们可以系统、全面地查询到各个表、指标的元数据信息和血缘信息。例如，通过元数据中心，数据部门能比较轻易地获取表的描述信息、表如何使用的信息，以及表字段及下游引用血缘等信息。

⒉.变更评估及精准变更周知

当表字段或者指标变更时，通过元数据中心的血缘链路，数据部门可以比较方便地评估该次变更对下游的影响，以及大致的变更工作量，确保变更工作能有序、有计划地开展。

3.协助数据问题定位及解决

在日常业务过程中，数据部门常常需要修复一些问题（数据的一致性、时效性等)。但数据从被采集到最终被应用涉及采集、存储、加工、查询、可视化等链路，如果不能较准确地定位问题，那么从0开始全链路盘查的工作量之大可想而知。此时，借助血缘链路，数据部l门可以快速定位问题所在，从而缩短解决问题所需的时间。

2.1元数据中心概述

元数据中心是数据中台最基础的系统（图2-1)，其他系统都需要搭建在它之上。无论是数据资产中心的资产管理与资产治理，数仓型中心的调度配置、依赖配置，还是指标设计中心的指标生产逻辑，都需要通过元数据中心整合与控制。

 

图2-1

因此，元数据中心需要实现三大模块的内容。

(1）数据整合。

(2）数据管理。

(3）数据地图。

2.2元数据中心的核心功能

2.2.1 数据整合

因为元数据中心是数据中台的基础设施，其他系统都需要以它为基础搭建，所以它需要能够支持不同的结构化数据源，如MySQL、Hive、Oracle等，还需要能够支持半结构化的数据源，如Kafka、Redis、HBase等，并且要考虑不同数据源的不同集群。

通过配置定时采集器的方式，对数据进行采集，如图2-2所示。

 

采集器有以下两种采集计划。

(1）场景采集:根据实际的业务场景，在业务需要时才进行采集。

(2）周期采集:按照时间周期，如月采集，在每月的特定时间进行采集，还有周采集、天采集、时采集等。周期采集设置如图2-3所示。

 

数据管理就是管理数据中台所有的元数据，元数据即描述数据的数据。这个概念其实不难理解，我们举一个电影的例子来说明:要判断—部电影是否热门，我们可以用一些指标来描述它，如购票人数、退票人数、上座率、排片率等。这些都是描述电影本身的数据。但除了这些数据，还有另外一些数据，如统计周期、产出时间、计算逻辑等，这些数据不是描述电影的，而是描述购票人数这个指标的，所以它们是关于电影的数据的数据，即电影的元数据。在数据中台中，元数据的类型有很多，如以下几类。

(1）数据表的名称、关系、字段、约束、存储位置等。

(2）数据表与字段之间的流程依赖关系。

(3）事实逻辑表、维度表、属性、层次的描述信息等。

(4)指标的生成逻辑、数据流向，物理表与逻辑表之间的映射关系等。

(5）调度系统的相关调度配置、调度周期等。

(6)哪些表何时被人访问、何时被稽查、何时被人调用、调用情况等。

针对不同类型的元数据，我们可以把它们组织起来分为3组:数据属性、数据字典、数据血缘。下面用一个实际的例子来详细说明这3组元数据的来源、内容与实现方式。

如图2-4所示，这是一个订单数据的开发流程，订单交易明细表( dwd_goods_order_df)通过一个任务( task_dws_goods_sku_1d ) ，按照SKU(库存量单位)的粒度，计算每日SKU的交易金额和订单数量，最终输出到SKU每日汇总表(dws_goods_sku_1d)中。 

 

图2-4

1.数据属性

数据属性主要是关于数据本身的描述，就好比我们描述用户，我们会用年龄、性别、身高等属性来描述用户，这些属性可以勾勒出用户的基础印象。我们也可以用一些基础的数据来描述数据属性。这些数据有几种类型:基础信息、标签信息、业务信息、技术信息、权限信息。

以图2-4 中的SKU每日汇总表(dws_goods_sku_1d）为例。

基础信息如图2-5所示。

图2-5

标签信息如图2-6所示。

                         

 

图2-6

标签的维护是靠基于元数据中心的各个数据中台支撑产品下沉到元数据中心上的。例如，指标系统创建了一个指标，在模型设计中，我们会为某个表的某个字段关联一个指标，之后指标和表就产生了关联关系，关联关系就会下沉到元数据中心，以标签的形式存在。

技术信息如图2-7所示。

 

图2-7

权限信息与业务信息整合在一起，如下。

项目:dataplatform_dev。

数仓层级: dwd。

主题域:交易域。

权限状态:无权限。

⒉数据字典

数据字典与数据属性有些相似，但是它主要描述数据的结构信息。其主要的数据来源是数仓模型中心的数据表的相关配置、调度系统等，如图2-8所示。

 

图2-8

对数据属性与数据字典的内容进行组织后，其展示效果如图2-9所示。

 

图2-9

3.数据血缘

数据血缘主要描述表与表之间的关系。其主要的数据来源是数仓模型中心的调度依赖配置、数据指标中心的指标生产逻辑、数据服务中心的逻辑表配置信息等。

数据血缘是元数据建设中最重要的一个模块，又对于后续的数据问题排查与数据资产计估都具有非常大的作用。数据血缘的作用主要体现在如下几个方面。

1）问题定位排查

在实际的业务场景中，我们如果发现某个数据应用或程序出现故障，就可以通过数据血缘进行排查，以快速定位相关故障节点。

2）指标波动分析

当某个指标出现误差或者出现不正常的波动时，我们可以通过数据血缘进行溯源分析，判断是哪条数据开发链路出现了问题。

3)数据预警与产出保障

对数据加工链条的所有节点进行监控，对下游任务产出时间进行预测，一旦发现下游任务无法按时产出，就及时报警。并且当某些节点出现问题时，我们需要确保高资产等级的整条数据链路能够有较高的优先级，优先调度并占用数据资源，确保高资产等级的数据能够被准时、准确地产出。

4.数据评估

在明确数据产品的价值之后，我们可以通过数据血缘反溯数据加工链路，判断数据化的重要性，并且从调用频率、数据热度等不同的维度进行评估，从而判断数据的价值，进行资产定级。

5.数据优化

通过血缘关系的调度依赖分析，我们可以获得数据的整体情况，如集中度、冗余度、计算成本、存储成本等，从各个方面对数据进行衡量，以便能持续对数据进行优化。

关于血缘关系的实现方式，业内已经有一些成熟的框架，如Druid，内部已经实现了大部分的解析功能，但是它的缺点是只能解析SQL,无法兼容Spark SQL、Hive sQL等其他模块的语法，所以会导致解析不完全。更好的解决方法是，通过Spark/Hive/Flink本身提供的Listener/Hook机制，解析调度依赖中的FROM、CREATE、INSERT等语句，获取输入节点与输出节点，生成血缘关系，就可以解析除SQL之外的其他语法。

在明确了实现方式后，就要考虑计划执行时机了。执行时机主要有3个。

(1)在运行前通过解析静态的SQL，获取依赖的输入节点与输出节点。

(2）在运行中实时截取动态的SQL，获取依赖的输入节点与输出节点。

(3）在运行后通过解析任务日志，获取依赖的输入节点与输出节点。

在这3个时机中，时机（1）因为没有执行代码，所以无法保证可以正常运行，时机 (3)则比较后置，没有时效性，所以最合适的是时机(2)，在运行中解析SQL，能够实时获取输入与输出表，并且当依赖关系改变时也能实时变更。但是时机(2)也有一个缺点，那就.是当数据表开发完成但还没有被执行时，就无法获取血缘关系，这时就需要通过解析静态SQL的方式，建立跟其他表的依赖关系。最终存储效果如图2-10所示。

 

图2-10

(注:这里是为了直观展示而采用了关系型数据的形式，实际应该用图形数据库存储。)

因此，对于数据血缘的实现，可以简要概述为:首先，通过Spark Listener/HiveHook/Flink Hook，解析调度依赖中的FROM、CREATE、INSERT等语句获取输入节点与输出节点，生成血缘关系并推送给消息中间件(Kafka) ;其次，消费端负责将血缘关系沉淀到图形数据库(Neo4j)中;最后，通过图计算引擎在前端以图形的方式将其展示出来。最终展示效果如图2-11所示。

 

另外，还需要补充一点，在生产过程中会生成很多临时表，这些表是不能被写入血缘关系的。因此，我们需要对这些表执行一个规则，如以t_开头，在后续执行解析任务时，一旦遇到这些表，系统就会自动优化这些表，避免弄脏血缘关系。

2.2.3数据地图

数据地图是基于所有元数据搭建起来的数据资产列表，如图2-12所示。我们可以将数据地图看作将所有元数据进行可视化呈现的系统。它不仅能够解决有什么数据的问题，还能够进行检索，解决数据在哪里的问题。

 

图2-12

数据地图提供了多维度的检索功能，使用者可以按照表名、列名、注释、主题域、分层、指标进行检索，结果按照匹配相关度进行排序。考虑到数据中台中有一些表是数仓维护的表，有一些表数仓已经不再维护，因此在结果排序时，我们增加了数仓维护的表优先展示的规则。数据地图还提供了按照主题域、业务过程导览功能，可以帮助使用者快速了解当前有哪些表可以使用。

当使用者定位到某个表被打开时，会进入详情页，详情页中会展示表的基础信息:字段信息、变更记录、产出信息、分区信息及数据血缘，如图2-13所示。数据血缘可以帮助使用者了解这个表的来源和去向、这个表可能影响的下游应用和报表、这个表的数据来源。

 

图2-13

元数据中心是数据中台最基础的系统，是所有数据中台系统的基石，后续的数仓开发、指标开发、数据治理、成本治理等都需要元数据中心的支持。

第3章数据指标中心

在一次月度报告会议上，老汤姆发现运营部门负责人的数据报告与自己的有一些出入。例如，有一项指标是新用户的付费率，二者的数据有几个百分点的差异。

在会议结束后，老汤姆找来阿北，问道:“今天我的数据报告与运营部门负责人的有差别，你检查一下是不是你算错了。”

阿北赶紧核对了一下自己的数据，在连续核对了几遍之后，他发现数据逻辑与数据源都没有问题，他判断可能是统计口径的问题，于是拿着数据报告去找了运营部门的同事。运营部门的同事说:“我们对新用户的定义是首次下单并完成支付的用户。”“果然是这个问题，”阿北一拍脑袋，继续说，“数据中台对新用户的定义是当天新注册的用户。”

阿北随即把这个问题反馈给了老汤姆。老汤姆在沉思片刻后，叫来了小风，说:“现在出现了数据中台的统计口径与运营部门不一致的问题，这个问题挺严重的，我们必须重视。”

小风:“要解决这个问题，就必须构建全局一致的统计口径，输出一份覆盖全平台所有业务的指标字典。”

3.1数据指标中心概述

数据指标中心是规范化开发指标并对其进行管理和维护的系统，它将指标的组成部分解耦拆分开来，并在逻辑表中进行规范的定义，在此基础上，按照一定的规则对指标的组成部分进行自由拼装，实现自定义指标的功能。

3.2数据指标中心的设计思路

3.2.1 定义指标并将其归集到对应的主题域

指标的本质是量化的目标，常见的例子如下。

(1）我们要把用户的盘子做大，对应的指标就是已注册用户数。

(2）我们要统计今天的销售额，对应的指标就是总支付金额。

(3）我们要衡量一次活动的效果，对应的指标就是下单率。

从上面的例子中我们可以看到，比较常用的几类指标是存量型指标(已注册用户数)、事务型指标（总支付金额)、转化型指标（下单率)。另外，还有比例型指标、统计型指标、排名型指标等，这些指标不常用，所以此处不做介绍。

这些指标分散在产品的不同功能模块中，所以为了更好地规范与管理这些指标，我们需要将这些指标按照主题域的方式归集起来。我们在数仓模型中心对主题域进行创建与定义，在这里我们只需要将对应的指标划归到对应的主题域中即可，如表3-1所示。

 

表3-1

3.2.2拆分原子指标与派生指标

先来看原子指标与派生指标的概念。

(1)原子指标:事实逻辑表中某个字段的统计值(sum、count、max、min、avg) ,如下单用户数、下单金额等。

(2）派生指标:基于原子指标，进行维度组合后产生的指标，如近1天商城下单用户数、本周商城黄金会员下单金额等。

原子指标无业务意义，它只是预定义的代码片段。我们在业务中用到的指标基本都是派生指标。新建原子指标如图3-1所示。

3.2.3 定义原子指标与派生指标的生产逻辑

前文提到过“将指标的组成部分解耦拆分开来，并在逻辑表中进行规范的定义”，这个解耦和定义的过程就是把一个派生指标拆解成统计周期、聚合粒度、限定维度、原子指标，再重新拼装，生成新的派生指标的过程，如图3-2所示。

我们可以这样理解上面的例子。

(1）统计周期是这个原子指标进行统计运算的时间范围，在这里是本周。

(2）聚合粒度是指标的主体，即按照哪个维度来进行聚合，在这里是黄金会员。

(3）限定维度限制原子指标的计算范围，这里限定在商城，即只计算与商城相关的数据。

(4）原子指标是预定义的某个字段计算规则，在这里是求和（下单金额)。

创建派生指标如图3-3所示。

 

3.2.4通过指标管理平台对指标进行规范生产

1.规范指标命名

命名规范对后期大量的指标管理来说非常重要，因为当指标很多时，我们要寻找一个指标就经常需要用到检索功能，而检索的前提是我们对指标有一些前置的认知。这就需要我们规范指标命名。

指标命名规范有3个重点。

(1）简洁明了、易懂:最好让人只要看到指标名，不需要看注释就可以知道它的含义、归属等。

(2）格式统一:每个指标的格式都是相同的。

(3）生成统一:原子指标与继承自它的派生指标的规范是一致的。

以与商城相关的指标为例。

(1）所有业务下单与支付指标，默认以“主单”为统计口径，不用带与“主单”相关的字眼，如商城下单次数;当统计口径为“子单”时，则需要在命名中标出，如商城子单下单次数。

(2）所有与人相关的指标都默认以“注册用户”为统计实体，不需要带与“用户”相关的字眼，如访问次数;当统计主体为“游客"时，则需要在命名中标出，如游客访问次数。

(3）无指定业务范围的指标默认为平台指标，不需要带与“平台”相关的字眼，如近30天支付人数;如果限定了业务范围，就需要加上业务名称，如商城-近30天支付人数。

(4）无指定时间周期的指标默认为“近1天”（但需要保存小时粒度，便于后续下钻)，不需要带与“时间”相关的字眼，如注册人数;如果限定了时间范围，就需要加上时间周期，如近7天注册人数。

完整的指标命名规范为商城（业务板块)+用户(实体)+近7天(统计周期）+新增（(业务动作)＋子单（类型)＋单日（间隔周期)＋平均(统计运算规则）＋支付金额（原子指标)，如商城-用户近7天新增子单单日平均支付金额（没有的部位可留空，如商城-汇总支付金额)。

2.规范统计口径

当指标主体为实体（名词)，如游客、用户、商品等时，则只需定义单位为“人/个”即可，如游客人数、用户人数、商品个数。

当指标为业务动作（动词），如点击、支付、下单等时，则除将单位定义为“次数”外，还需考虑与这个动作关联的实体的单位，如当实体为“商品”时，则需要多定义一个单位“笔数”;当实体为“用户”时，则需要多定义一个单位“人数”等。因此，一个下单动作的指标会有多个不同的统计口径，如下单次数、下单笔数、下单人数等。

我们在定义指标名称时，需要清楚地定义指标名称，避免出现“下单数”这样模糊的指标。

3.规范指标等级

随着企业的发展，产品在不断地进行迭代，功能的增删与业务的变化势必影响指标的发展，一些旧的指标被不断更新或废弃，而新的指标也不断增加。这时，对指标的管理就成了一个问题，哪些指标由谁开发?后续由谁来维护?......

一个比较好的解决方案就是对指标进行等级划分。我们可以将指标划分为两个等级。

1. 一级指标，即原子指标与小部分全平台的核心指标，在从各个业务部门收集需求后，统一由数据中台来产出，有一套完整、规范的开发流程:需求—评审—排期—开发—测试—验收—上线。所有维护管理工作都由数据中台负责。

(2）二级指标，即派生指标，由各个业务部门自行通过指标中心生成，没有严格的开发流程，各个业务部门根据需要自行创建，但需要遵守指标命名规范。所有维护管理工作都由部门内部负责。

指标等级划分如图3-4所示。

 

第4章数仓模型中心

数仓开发人员在进行曰常维护时发现，有一个任务消耗的资源非常多，影响了其他数仓的任务，他在检查后发现该任务是计算每月的会员销售额。这个任务是阿北创建的，但是由于阿北不具备专业技术知识，没有考虑到性能的问题，而且数据是直接从原始数据开始加工的，因此SQL用了多层嵌套，导致资源被消耗了很多。于是，他把这个问题反馈给了小风，小风找来老汤姆和阿北，一起讨论如何解决这个问题。

小风说:“数据分析部门经常从原始数据开始清洗、加工指标，这样做不规范，是不是把原始数据的访问权限收回来比较好?“

阿北反驳道:“但是现在并没有复用的数据，我们都需要自己去处理。如果提出开发公共表需求，就需要很长的排期，还不如我们自己去清洗数据。”

这时老汤姆止住了他们的对话，说:“你们说的问题确实都存在，主要根源在于没有对数据模型进行开发流程的规范化，只要把数据模型的开发流程固化成产品的功能步骤，就可以解决这些问题了。”

4.1数仓模型中心概述

数仓模型为如何组织数据提供了思路。数仓模型中心是数据加工的底层基础，也是指标加工的基础，还是数据成本的主要承担者，如图4-1所示。因此，在进行模型开发时，我们必须按照规范的流程来进行开发，只有在规范开发的基础上，才能对数仓的数据模型进行有效的控制与治理。

 

4.2数仓模型中心的设计思路

4.2.1控制数据源

ODS层(操作数据存储层)汇集了来自不同数据储存系统的数据，从ODS层开始往下游进行数据的分发，所以ODS层是数仓的源头，也是数据中台中所有数据加工的起点。我们必须控制ODS层的数据变化，因为只有控制了源头，才能从根本上建设一个规范化的数据中台。

ODS层的表的数据结构必须和数据源的表结构一致，确保映射过来的数据行和数据列一致，没有损耗，以保证与业务库的数据同步,以免数据中台的产出数据与业务数据出现偏差，产生较大范围的影响。

4.2.2划分主题域

面向业务分析，将业务过程或者维度进行抽象的集合，就形成主题域。为了保证整个数据体系可以正常地运转，主题域需要先对数据进行归纳，然后进行抽象提取，并长期维护和更新。在划分主题域时，要既能涵盖当前所有的业务需求，又能让新业务在进入时可以被已有的主题域或扩展的新主题域包含。主题域如图4-2所示。

 

主题域是业务过程的抽象集合。用户在使用产品的过程中，会进行一系列的业务活动，如注册、下单、退款等，这一系列的业务活动就是业务过程，也就是在经营的过程中，单个不可再往下细分的行为事件。主题域可以按照企业的部门划分，也可以按照业务过程或者业务板块中的功能模块划分，如纯线上电商的主题域划分如表4- 1所示。

 

用于描述业务过程的详细信息，在创建事实逻辑表之后，需要明确规定度量值与关联的维度。事实逻辑表是每个业务动作(可以简单理解为埋点)的存储表，如支付有支付事实逻辑表、下单有下单事实逻辑表等，如图4-3所示。