首页  思维导图  详情

《数据中台：让数据用起来》读书笔记

2020-05-13 09:42:18   7  举报





AI智能生成

为你推荐

查看更多



数据中台

关于数据中台目前最好的一本书，数澜出品的《数据中台：让数据用起来》，第3遍读，完整的做了一次读书笔记，对全书的核心内容做了详细的摘要

数据

数澜

数据中台

读书笔记

数据分析

作者其他创作

大纲/内容

数据中台:让数据用起来

前言

信息化建设出现发展瓶颈的原因

数据孤岛问题

独立采购和自建信息系统

新模式下产生的外部数据

IT架构变的复杂

多云环境出现

底层数据互联互通

业务数据化

数据资产化

资产服务化

服务业务化

第1章——数据中台：信息化的下一站

数字化平台特征

充分协同并融入业务流程

统一数据模型并可平滑交换数据

云原生和能力开放

智能化

三个核心认知

需要提升到企业下一代基础设施的高度，进行规模化投入

需要全新的数据价值观和方法论，并在其指引下形成平台级能力

围绕业务，数据，分析会衍生出全新人才素养要求，需要尽快启动人员储备

业务自流程化

当业务能够实现对象数字化、规则数字化、结果数据化时，业务自身的流程也就可以按照规则自由、自行组建和优化了

数据中台发展三个阶段

数据中台探索

传统数据应用是从外往内，企业自身没有沉淀

需要借助具体场景化数据应用来推动，积累行业头部客户的业务和服务经验

数据中台整合数据应用提升效率

数据的多样性，多态性，多云连接能力（汇聚/交换能力）

交换的能力用来解决企业有那些事故件，数据在哪里

数据资产化的能力数据中台建设的关键

能直接作用于业务领域，业务能于都，能理解的数据才叫数据资产

数据服务化的能力

用数据技术来使用数据的方法

数据中台重构数据空间和业务空间

业务和业务流程本身都可以通过适当的颗粒度进行数字化解耦和标准化

以数据编排的方式响应业务需求

颠覆传统的软件工程方式

业务实现自流程化

数据实现自我管理能力

企业业务空间

产生和形成全量数据的根本依据和前提

企业数据空间

自主产生和消费的数据

外部数据

单向外部获取数据

单向对外提供数据

内外部交互数据

四种信息化建设模式

软件功能驱动

以采购和实施成熟产品为主，目标是业务部门直接能用

数据治理驱动

业务上遇到难题，立个专项解决，目标是针对同一数据不同问题或不同数据同一问题进行分类治理

业务能力驱动

建设难度极高，通常会形成顶层规划设计和一系列实施项目，目标是基于企业架构自上而下开展规划建设

业务服务化驱动

专注于新技术的引入，通常是面向业务拉动资源调度

第2章——什么是数据中台

数据中台需要具备的四个核心能力

汇聚整合

数据采集

交换

监控管理

数据集成

数据安全

部署灵活

提纯加工

完善的安全访问机制

完善的数据治理保障体系

规范的，紧密结合业务的可扩展标签体系

面向业务主题的资产平台

智能的数据映射功能，简化数据资产生成

服务可视化

提供自然语言处理等人工智能服务

数据分析功能

数据可视化

便捷快速的开发环境

实时流数据分析

预测分析，机器学习等高级服务

价值变现

数据应用管理能力

数据洞察直接驱动业务行动

跨业务场景能力

跨部门普适性业务价值能力

基于场景的数据应用

业务行动效果评估

数据中台VS业务中台

业务中台是抽象数据能力的共性形成通用数据服务能力

业务中台是抽象业务流程的共性形成通用业务服务能力

业务中台不直接面向终端用户，但可以极大提升构建面向终端用户的前台速度和效率

同一个服务，在应用层面展现的内容可能不一致，但是底层的数据体系是一致的

业务中台沉淀的业务数据进入到数据中台进行体系化的加工，再以服务化的方式支撑业务中台上的应用

业务中台只是数据中台的数据来源之一

数据中台的数据服务可能绕过业务中台，直接作用于业务系统

数据中台VS数据仓库

数据仓库的主要场景是支持管理决策和业务分析

数据中台是将数据服务化后提供各给业务系统，不局限于决策分析类场景

数据中台包含数据仓库的完整内容

数据中台可以将已建好的数据仓库当成数据源，避免重复建设

可以基于数据中台提供的能力，构建全新的离线或实时数据仓库

数据中台与企业现有信息架构不存在竞争关系

数据中台的业务价值

以客户为中心，用洞察驱动企业稳健行动

以数据为基础，支持大规模商业模式创新

盘活全量数据，构筑坚实壁垒以持续领先

数据中台的技术价值

应对多数据处理的需求

批量离线计算

报表

实时流式计算

指标统计和实时推荐

即席计算

决策类业务和ad-hoc需求

圈人

在线计算

高并发业务

用户画像

丰富标签数据，降低管理成本

数据分类

主数据

参考数据(引用数据)

指标数据

数据的价值能体现业务系统效果而不仅是准确度

支持跨主题域访问数据

数据可以快速复用而不仅是复制

第3章——数据中台建设与架构

数据中台建设方法论

1种战略

把用数据中台驱动业务发展定位为企业级战略

2项保障条件

通过宣导统一组织间的数据认知

数据采集意识

数据标准化意识

数据使用意识

数据安全意识

通过流程加速组织变革

3条目标准则

数据可见，可用，可运营

4套建设内容

技术体系

骨架

数据体系

血肉

服务体系

灵魂

数据中台与大数据平台最主要区别是数据能更方便的以服务化的方式支撑业务，而这是通过数据中台服务体系实现的

数据中台无法产品化的提供该企业所需的所有数据服务能力

运营体系

5个关键步骤

理现状

组织现状

业务现状

数据现状

技术现状

立架构

组织架构

业务架构

技术架构

应用架构

数据架构

建资产

资产萃取

数据标准

数据质量

用数据

场景服务

做运营

监控审计

价值评估

质量评估

资产排名

第4章——数据中台建设的评估与选择

企业数据应用成熟度评估

统计分析

中小企业在思考如何通过将生产计划和业务流程从线上迁移到线上，以实现对整个业务流程的计划，管控和集成

将原来线下生产线中的看板转移到系统中

利用信息系统对生产流程中从订单到采购，生产，存货，物流，销售在内的各环节中的每一个细小的环节信息进行记录

从需求拉动的角度对各个环节中的数据进行分析，对流程进行持续优化

利用业务系统将业务开展情况通过数据保留了下来，但是在使用时出现了

每天大量业务数据会出现系统或者数据的问题，需要专人维护

数据库分散存放了各种数据，部分是脏数据，无法根据自身需求找到原始数据

这个阶段的分析只是停留在对过去业务结果的统计，形成了面向业务主题的客观事实描述和分析结果

没有以数据为导向积累数据，主要是通过单一维度的少量数据的统计分析进行业务的总结

数据应用场景只针对业务系统中的关键数据和指标进行简单的，单一维度的统计分析和管理，辅助业务总结

业务报表基于系统报表模块或系统数据导出后通过excel制作

决策支持

企业开始构建企业级数据仓库，有BI团队来支撑需求分析与决策

将大力复杂的原始数据抽象为指标，并以体系化，可视化的方式直接呈现在决策者面前

数据应用场景开始基于数据仓库进行各业务主题的数据收集、管理和分析，建立包括领导驾驶舱，企业运行指数，企业第四张报表（数字资产表）等场景应用

数据驱动

对多源异构全域数据进行汇聚，跨界考虑数据价值的应用

开始根据需求进行数据清洗加工和标准化处理

从该阶段开始，数据开始从管理层逐步转向具体业务

数据场景最为典型的是个性化推荐，风控，精准营销

运营优化

汇聚企业各类数据资产，消除物理孤岛，通过Mapping能力将数据进行融合，消除逻辑孤岛

实现目标五大条件

能够追溯数据资产的行程过程，包括涵盖了哪些数据来源，经过了怎样的加工环节，涉及哪些业务环节和部门等

能及时获取到数据资产当前的状态，尤其是数据治理和安全情况，如更新频率，合规性，空值率等

能够知道数据资产被哪些业务调用了，以通过建立数据闭环了解和追溯数据资产所带来的业务价值

能够对整个数据中台从数据采集到数据应用的整个链路建立监控体系，便于及时发现和排除故障，保证数据资产的稳定性

建立丰富的数据内外部共享和服务渠道，实现数据价值的释放和交换

什么样的企业适合建设数据中台

有一定信息化基础，沉淀了数据，实现了业务数据化过程

业务复杂，有丰富的数据维度和多个业务场景，特别是多业态型集团企业

有数字化转型，精细化经营的需求

第5章——数据汇聚联通：打破企业数据孤岛

数据采集和汇聚

数据采集和汇聚是最容易触碰法律红线的环节

用户行为

线上行为

客户端埋点

全埋点

无埋点

适合终端设计标准化且有统一系统接口

不用频繁升级，数据存储传输成本高

可视化埋点

将终端设备上一部分操作，通过服务端配置的方式有选择性的记录并保存

适合需要考虑存储和带宽成本

不用频繁升级，成本比全埋点低，能够灵活配置；遗留采集对象时会影响业务进度

代码埋点

适合终端设计非标准化，事件行为需要通过代码来控制

灵活性强，成本高，维护难度大，升级周期长

服务端埋点

HTTP服务器上的access_log

如果用户数据通过服务端可以获取，为降低客户端复杂度，避免信息安全问题

无访问服务端请求时，无法采集

线下行为

wifi信号采集

信令数据采集

图像视频采集

传感器探测

互联网数据采集

内部数据汇聚

数据组织形式

结构化

半结构化

非结构化

时效

离线

全量

增量

实时

增量日志

通知消息

ETL和ELT

转换放在最后因为

数据体量过大和清洗逻辑复杂性导致数据传输效率大大降低

数据价值会随着对数据认知的发展而不断挖掘，ETL模式容易导致有价值的数据被清洗掉

数据交换产品

数据交换是后续数据作业的起点

数据交换中心的首要目的是屏蔽底层工具的复杂性，以可视化配置的方式提供给企业用户

其次要考虑异构存储和交换需求

考虑不同时效要求下的数据互通

数据源管理

可以是已有系统存储业务数据的地方

为应用场景提供结果数据存储的地方

数据源

关系型数据库

oracle

mysql

sqlserver

greenplum

nosql

redis

hbase

Cassandra

mongodb

neo4j

网络及mq

kafka

http

文件系统

hdfs

ftp

oss

csv

txt

excel

大数据相关

hive

impala

kudu

maxcompute

adb

libra

elk

离线数据交换

针对时效要求低，吞吐量大的场景，解决大规模数据的批量迁移问题

实现原理是将不同数据源的交换抽象为从源头数据源读取数据的读取插件，以及向目标端写入数据的写入插件

读取插件

数据采集模块，负责数据源的数据采集，将数据发送给数据交换核心模块

写入插件

数据写入模块，不断从数据交换核心模块取数据，并将数据写入到目的端

数据交换核心模块

用于连接读取插件和写入插件，作为二者的数据传输通道

离线数据同步技术亮点

前置稽核

数据转换

跨集群数据同步

全量同步

表名称、结构相同，目标表允许不存在

增量同步

新增

覆盖

更新

实时数据交换

数据订阅服务

数据的订阅和收取

任务实例的启停控制

数据消费服务

任务状态控制

数据解析

数据过滤

数据写入

数据存储

数据规模

数据生产方式

数据应用方式

在线与离线

在线存储设备一般为磁盘，磁盘阵列，云存储

离线存储为了做灾备，不会被经常调用，远离系统应用。典型产品是硬盘，磁带和光盘

OLTP与OLAP

OLTP用于存储和管理日常操作的数据，需要进行大量的更新操作，对响应时间的要求比较高

OLAP用于分析这些数据，主要用来执行大量的查询操作，对实时性要求低

存储技术

第6章——数据开发：数据价值提炼工厂

数据开发的产品能力

离线开发

企业有60%-80%的场景需要用到离线批处理的能力

作业调度

DAG有向无环图

依赖调度

时间调度

基线控制

根据最先到达，最短执行时间原则，动态调整资源分配及作业的优先级

采用算法对作业完成时间进行智能预测

异构存储

新建各种类型作业，在执行时自动根据作业的类型寻找相应插件来运行作业

代码校验

语法校验

规则校验

多环境级联

单一环境

经典环境

复杂环境

推荐依赖

如何保证选定了上游作业后，不会因为形成环路而导致调度失败，需要自动推荐上游作业

智能推荐依赖原理

获取推荐依赖的核心原理在于上下游作业输入和输出的表级血缘依赖图

通过血缘分析当前作业的输入和输出，找到合适的上游作业

对合适的作业进行环路检测，剔除存在闭环的作业

返回合适的节点列表

数据权限

数据权限管理面临的问题

部分引擎有独立的权限管理系统，导致权限申请要到每一种引擎上单独申请，让使用变得复杂

数据权限是大数据集群或数据库运维人员管理的，开发人员无法直接接触或者操作，造成运维人员负担过重

缺乏一套能同时支持多种计算引擎的权限申请，审批，管理系统

实时开发

实时开发套件是对流计算能力的产品封装

实时计算三大特点

实时且无界的数据流

持续且高效的计算

流式且实时的数据集成

元数据管理

sql驱动

组件化开发

将任务具体化为流计算的加工拓扑图，由平台负责任务的调度，解析及运行

对流计算中各组件的吞吐，流速等指标做统计分析，帮助用户更加直观的分析计算瓶颈，准确的定位问题并进行优化

算法开发

算法开发套件提供可视化建模和NoteBook建模两种建模方式

可视化建模

拖拽式实验流

丰富算法组件

实验周期调度

告警通知

多角色协同

NoteBook建模

算法开发可为离线开发和实时开发提供算法模型

数据集管理要考虑的功能点

数据接入

数据标注

数据探查

核心算法组件

数据获取及存储

数据预处理

特征工程

构建对结果具有显著影响或便于模型处理的特征

机器学习

深度学习

文本分析

网络分析

工具类

多算法框架

多算法框架支持

tensorflow

pytorch

lightgbm

算法框架多版本支持

基于conda的环境隔离

基于docker的隔离

加工场景

离线和实时数仓建设

算法模型训练

数据化运营分析

数据探索

数据计算能力四种类型

批计算

主要用于批量数据的高延时处理场景，比如离线数仓加工，大规模的数据清洗和挖掘。大多数利用MapReduce，hive，spark等计算框架进行

特点是数据吞吐量大，延时高，适合人机交互少的场景

传统的数据处理方式通常是将数据导入专门的数据分析工具中

源数据非常大时，往往数据的移动就要花费较长时间

数据处理工具是单击的，或系统架构无法快速扩容，面对海量数据，数据处理时间是个很大的问题

spark相较MapReduce的优势

数据处理技术

数据格式和内存布局

执行策略

流计算

常见应用场景

流式ETL

流式报表

监控预警

在线系统

计算框架有flink，spark streaming和storm

在线查询

主要用于数据结果的在线查询、条件过滤和筛选

画像服务

征信查询

搜索的应用场景

文档搜索，商品搜索

圈人场景

响应延时要求高，缓存型存储计算，如redis

响应延时要求正常，选择hbase，mysql

需要进行条件过滤，检索的，选择es

即席分析

主要用于分析型场景和经验统计

交互式数据分析

群体对比分析场景

A/B测试

针对不同维度的分析，有提前固定计算的维度、根据需求任意维度的交叉分析（ad-hoc）

大部分是聚合操作

实现方式

ROLAP

以关系数据库为核心

MOLAP

以多维数据组织为核心

第7章——数据体系建设

中台数据体系应具备的特征

覆盖全域数据

覆盖所有业务过程数据

结构层次清晰

纵向的数据分层，横向主题域，业务过程划分

数据准确一致

定义一致性指标，统一命名，统一业务含义，统一计算口径

性能提升

降低成本

方便易用

把一些复杂的处理尽可能前置，通过公共计算下沉，明细与汇总共存等为业务提供灵活性

数据分层

操作明细层ODS

对各业务系统数据进行采集，汇聚，尽可能保留原始业务流程数据，与业务系统基本保持一致，仅做简单整合，非结构化数据结构化处理或者增加标识数据日期描述信息，不做深度清洗加工

统一数仓层DW

与传统数据仓库功能基本一致，细分为明细数据层DWD和汇总数据层DWS

对来源于业务系统的数据进行重新组织，定义一致的指标，维度，各业务板块，业务域

标签数据层TDM

对跨业务板块，跨数据域的特定对象数据进行整合，通过ID-Mapping把各个业务板块，各个业务过程中的同一对象的数据打通，形成对象的全域标签体系

应用数据层ADS

按照业务需要从DW和TDM取数据，向特定应用组装应用数据

数据读取规范

ODS直接从业务系统或日志系统获取数据

ODS的数据只能被DW使用

DW数据只被TDM和ADS使用

ODS和DW只保存历史数据以及被TDM和ADS引用，不直接支撑业务，所有业务使用的数据均来源于TDM和ADS

实际建设过程中，由于时间问题或者DW层没有，TDM或ADS会直接从ODS取数据，这会导致数据口径不一致的情况

ODS层——全域数据统一存储

保留企业全量业务原始数据，并作为DW层建设的数据源（业务系统数据，业务运行的日志数据，机器运转的日志数据，网络爬虫）

不对数据做过多的清洗加工，尽可能保留数据的原始状态

建设目标就是把企业的全域原始数据都汇聚到数据中台，从而能在数据中台查询到所有的企业数据，为后面的DW、TDM和ADS层建设做准备

与传统数仓不同，采用ELT进行数据获取，将所有原始数据都抽取到数据中台的ODS，在数据中台内部再利用大数据底层平台的计算能力进行转换操作

抽取过程尽量简单

保留原始数据，以便问题追溯

充分利用大数据的计算能力

结构化数据

从业务系统DB抽取到ODS

半结构化数据

保留贴源数据的同时也做结构化处理

非结构化数据

保留原始文件，只保留对原始数据文件的描述

表结构参考业务系统数据表结构设计即可

数据表设计规范

命名采用前缀+业务系统表名的方式。ODS_系统简称_业务系统表名

字段名与业务系统字段名保持一致，在ODS层不做字段名归一，字段类型也尽可能保持一致

对于数据量较大的业务表，如采用增量同步的方式，则要同时建立增量表和全量表。增量表利用后缀表示。ODS_系统简称_业务系统表名_delta

汇聚到增量表的数据通过数据加工任务合并生产全量表数据

对于日志，文件等半结构化数据，不仅要存储原始数据，还要对数据做结构化处理，并存储结构化后的数据

原始数据按行存储在文本类型的大字段中，通过解析任务把数据解析到结构化数据表中

一般采用数据同步工具实现数据同步落地

确定业务系统源表与ODS层目标表

配置数据字段映射关系，目标表可能会增加采集日期，分区，原系统标识等必要信息，业务相关内容不做转换

如果是增量同步或者有条件的同步部分数据，则配置数据同步条件

清理目标表对应数据

启动同步任务，往ODS层目标表导入数据

验证任务是否可以正确运行，并采集到准确数据

发布采集任务，加入生产调度，并配置相关限速，容错，质量监控，告警机制

DW层——标准化的数据底座

站在业务视角，不考虑业务系统流程，从业务完整性的角度重新组织数据

目标是建设一套覆盖全域，全历史的企业数据体系，利用这套体系可以还原企业任意时刻的业务运转状态

准确定义术语非常关键，有时候描述不清楚复杂流程和场景的根本原因是没有厘清其中的一些概念

相关概念

业务板块

根据业务的属性划分出的相对独立的业务板块，各业务板块中的业务重叠度低，数据独立建设。如地产板块，金融板块，医疗板块

模型设计

构建一致的维度和事实，同时设计出一套表命名规范

数据域

DW层的顶层划分，对企业业务过程进行抽象，提炼和组合的集合

面向业务分析，一个数据域对应一个宏观分析领域，如采购域，供应链域，HR域

不轻易变动，既能涵盖当前所有业务需求，又能在新业务进入时无影响的将其分配到已有的数据域中

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

业务过程

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

业务过程产生度量，兵器会被转换为最终的事实表中的祘

业务过程一般与事实表一一对应

累计快照事实表会把多个业务过程产生的事实在一张表中表达

修饰词

除统计维度以外的对指标进行限定抽象的业务场景词语，修饰词属于修饰类型。如在日志域的访问终端类型下，有修饰词PC，无线端

修饰类型的出现是为了方便管理，使用修饰词

原子指标

对某一业务事件行为的度量，是一种不可拆分的指标，具有明确业务含义，比如支付金额

原子指标有明确的字段名称，数据类型，算法说明，所属数据域和业务过程

原子指标名称一般采用动作+度量方式命名，比如支付金额，注册用户数

派生指标

对原子指标业务统计范围的圈定

派生指标=1个原子指标+多个修饰词+时间修饰词

计算方式

汇总，平均，最大，最小

维度表

提供某一业务过程事件所涉及的用于过滤及分类事实的描述性属性

用于描述与5W1H有关的事件

维度表是统一设计的，在整个数据仓库中共享，所有数据域，业务过程都需要用到维度，都可以在公共维度表中获取相关维度属性

事实表

涉及来自业务过程事件的度量，基本都是以数量值表示

事实表不跨数据域，一个事实表可以对应同数据域下一个或者多个业务过程

明细事实表保存的是原子数据，数据的粒度通常是每个事务一条记录，数据一旦被插入，就不再进行更改，更新方式为增量更新

汇总事实表包括以具有规律性的，可预见的时间间隔来记录事实的周期快照事实表和以不确定的周期来记录事实的累计快照事实表

粒度

用于确定某一事实表中的行表示什么，确定维度和事实之前必须声明粒度

原子粒度是最低级别的粒度，是对业务过程最详细的刻画

原子粒度事实必须保留

一致性指标定义

指标归属到具体数据域，定义指标的含义，命名，类型，计算方法，确保指标的全局一致性

数据域划分

数据域是指面向业务或数据进行本质分析，归纳总结出来的数据集合

数据域需要抽象提炼，并且长期维护和更新，但不轻易变动

划分过程

数据调研

业务调研

跟业务专家访谈或者进行资料文档收集

内容

确定项目要涵盖的业务领域和业务线

各个业务线可以细分成哪几个业务模块

各业务模块具体的业务流程

梳理

业务流程

业务边界

专业术语

调研全部数据目录信息

梳理数据流与业务过程关联关系

业务分类

业务过程提取

根据调研结果抽取全部业务过程

业务过程拆分

将组合型的业务过程拆分成一个个不可分割的行为事件。如下单，支付，收货，退款

业务过程分类

按照业务分类规则，将相似特征的业务过程分为一类，且每一个业务过程只能唯一归属于一类

数据域定义

业务分类确认

确认业务分类结果，避免分类范围中出现业务特征明显与其他业务过程无关的情况

根据业务分类的规律总结出划分业务范围的标准定义

数据域命名

为每一个数据域起一个专属名称，并附上英文全称和简称

总线矩阵构建

关系梳理

明确每个数据域下有哪些业务过程（矩阵的行），并梳理出业务过程与哪些维度相关（（矩阵的列）

矩阵构建

定义一张二维矩阵，将数据域下的业务过程与维度信息记录下来

指标设计

指标是在企业业务运转过程中产生的度量事实

一致性指标设计是为了在企业内外部使指标的命名，计算方法，业务理解达到一致避免不同部门同一个指标的数据对不上或者对同一个指标的数据理解不一致

时间周期

维度表设计

维度表设计的好坏直接决定了维度建模的好坏

维度表包含了事实表所记录的业务过程度量的上下文和环境

每个维度表都包含单一的主键列

维度设计的核心是确定维度属性

查询where条件

分组group

报表标签

维度表通常比较宽

维度表应该尽量包括一些有意义的文字性描述，以方便下游用户使用

维度表设计过程

选择维度

必须保证维度的唯一性

一般用于查询约束条件，分组，排序的关键属性

可以从报表需求中分析获取，也可以从与业务人员的交谈中发现

确定主维表

一般直接从业务系统同步而来，是分析事实时所需环境描述的最基础，最频繁的维度属性集合

比如用户维表从业务系统的用户基本信息表中产出

梳理关联维表

根据对业务的梳理，确定哪些表和主维表存在关联关系，并选择其中的某些表用于生成维度属性

比如商品与类目、SPU、卖家、店铺等维度存在关联关系

定义维度属性

从主维表或关联表中选择维度属性或生成新的维度属性

尽量生成更丰富，更通用的维度属性，并维护和描述维度属性的层次及关联关系

如商品维表，商品属于类目，类目属于行业

事实表设计

DW层绝大部分表都是事实表

两部分组成

主键和外键组成的键值部分

确定事实表的粒度

用来描述业务过程的事实度量

描述业务过程

事实表的外键总是对应着某个维度表的主键

一切数据应用和分析都是围绕着事实表展开的

三种类型

事务事实表

描述业务过程事务层面的事实，每条记录代表一个事务事件，保留事务事件活动的原始内容

相对其他事实表保存的数据粒度更细，可以通过事务事实表对事务行为进行详细分析

周期快照事实表

每行代表某个时间周期的一条记录

一般是建立在事务事实表之上的聚焦，维度比事务事实表少，粒度比事务事实表粗

一般事实会比事务事实表多

累计快照事实表

覆盖一个事务从开始到结束之间所有的关键事件，覆盖事务的整个生命周期，通常具有多个日期字段来记录关键事件时间点

一般采用全量刷新的方式更新

一般用于追踪某个业务的全生命周期及状态转换

通过累计快照事实表可把相关事件串起来放在一条记录中

设计过程

确定业务过程

确定实施所要表达的是哪一个或者几个业务过程

最基本的是每一个业务过程对应一张事实表

定义粒度

实际设计过程中，粒度与主键等价，粒度更偏向业务，而主键是站在技术角度说的

确定维度

维度依附于粒度，是粒度的环境描述

常见的维度有时间，区域，客户，产品，员工等

确定事实

业务过程产生的事实度量的计算结果

事实表的所有事实度量都与事实表所表达的业务过程有关

冗余维度属性

为降低资源消耗，建议适当冗余维度属性数据到事实表，直接利用事实表可以完成绝大多数业务的使用需求

模型落地实施步骤

按照命名规范创建表，包括维表和事实表

开发生成维表和事实表的数据的逻辑代码

进行代码逻辑测试，验证数据加工逻辑的正确性

代码发布，加入生产调度，并配置相应的质量监控和报警机制

持续任务运维监控

TDM层——数据价值魅力所在

同一个对象的各种信息分散在不同的数据域并且有不同的数据粒度，以客户数据举例

基本信息在客户域按照客户粒度组织

交易信息在交易域按照订单粒度组织

社交信息在社交域按照关系粒度组织

通过建设标签层来满足

大数据的典型应用基本都是通过标签体系来支撑的

标签归属到一个对象

属性标签

对象本身的性质

统计标签

对象在业务过程事件中产生原子指标，组装出统计标签

算法标签

对象在多个业务过程中的规律特征通过一定计算方法计算出算法标签

对象标签表（标签融合表）

标签

对象标签类目

对象标识

对象

客观世界中研究目标的抽象

比如自然人，产品，账户等

用以标识一个对象，一般是各种ID

比如手机号，身份证，登录账号

利用原始数据，通过一定的加工逻辑产生，能够为业务所直接使用的可阅读，易理解，有业务价值的数据

标签类目

标签的分类组织方式，是标签信息的一种结构化描述，目的是管理，查找标签

一般采用多级类目

是根据人类对实体长期认知得出的

比如性别，年龄，体重

特定场景下，维度和度量的结合

比如日均登录次数、最近30天交易额

不可以直接获得的，需要通过复杂逻辑分析推理得出

比如信用指数、购买能力、品牌偏好

标签融合表

以对象为核心把属性标签，统计标签，算法标签组装起来得到的表，是标签数据层落地的产出物

设计要考虑标签的类目结构进行合理组织

确定对象

进行标签建设，首先要清楚对哪类对象建设标签，也就是确定对象

人

自然人，法人，法人群体等

物

物品，物体，物品集合等

关系

人和物，人和人，物和物发生的某种行为

行为关系

归属关系

思维关系

对象ID打通

如果需要对一个对象进行全面的数据收集、完整刻画、辨别真伪，就需要对多方数据进行融合打通

一般会给每个对象设置一个超级ID作为唯一识别该对象的标识码，业务系统中不同的对象标识ID都通过一定的算法规则与这个超级ID打通

大数据领域的ID-Mapping技术就是利用机器学习算法解决对象数据的打通问题

基于输入的ID关系对

做稳定性和收敛性计算

输出关系稳定的ID关系对

生成超级ID作为唯一标识码

打通关系的误差用置信度来描述

置信度越高误差越小

不同业务根据自身需要选择不同的置信度

ID打通是标签体系建设的前提

标签类目设计

首先需要确定根目录

针对根目录展开，可以构建多级类目结构

树状结构

数据类目体系建议按照数据采集，存储，管理等系统原有的业务体系进行划分

标签类目体系则建议按照数据理解，使用，价值等数据应用的角度进行划分

通常说的标签体系，一般是指一类对象的标签类目+标签

对象标签体系设计的核心是标签类目设计，标签类目设计完成，整个标签体系的框架就有了

标签设计

设计合适的标签并将其挂载到标签类目

数据必须转化成能帮助业务提升的标签才具有价值

大数据业内一直尝试探索的最核心环节就是数据的商业变现

标签即业务需求的数据呈现，商业价值核心承载在标签上

标签设计考验的是理解，抽象，提炼，提升业务场景的数据能力

两大前提条件

标签必须是业务上需要的，能体现业务价值，帮助业务人员作出业务判断或者能创造性的唤醒新业务场景的数据项

在业务上往往会称其为属性，特征，指标，参数

必须要探查清楚根据业务需求提炼，整理出的标签是否具有数据可行性，是否有原始数据可以用于加工成标签

需要了解数据源有哪些，数据字典信息

根目录：一个用来指向某个对象的词都不应该是标签，往往是根目录，在物理层面可以和某张大宽表中的主键对应

标签类目：对对象的拆分及对象的角度，层面或过程，一般是类目，往往由名词构成，在物理层面可以和某张具体表对应

标签：对对象具体属性，特征，信息，内容的字段级刻画，是标签。往往由前后两个名词构成，在物理层面可以和某张具体表中的字段对应

标签值：对对象属性，特征，新，内容的具体取值，是标签值。往往由形容词，名词，数字组成，在物理层面可以和某张具体表中的字段值字典对应

元标签的设计内容

偏向业务方向

主要登记与业务所需相关的指标

标签名

标签加工类型

标签逻辑

值字典

取值类型

示例

更新周期

安全等级

偏向技术方向

主要登记技术开发实施过程相关的指标

表名

字段名

负责人

完成时间

标签设计注意事项

某具体对象某标签的标签值，只允许有一条记录，即对应在数据表里，是一个字段取值

对于人-物-关系各对象标签间的转化

标签融合表设计

两种组织方式

纵表类似KV表

每行表示一个对象的标签

横标二维表

每行表示一个对象

推荐使用横表的方式设计标签融合表

由于标签众多，一般不会用一张标签融合表来存储所有标签，而是通过多张融合表来存储标签

标签融合表实现

按照设计和命名规范创建标签表

开发生成标签数据的逻辑代码

进行代码逻辑测试，验证数据加工逻辑是否正确

持续进行任务运维监控

ADS层——灵活支持业务需求

一般采用维度建模，但并没有非常规范的建设标准

应用数据层类似于数据集市，但是比数据集市更轻量化，用于解决特定的业务问题

整体而言是构建在DW与TDM层之上的简单数据组装层

应用数据表设计

面向特定业务需求而准备的个性数据组装层

强业务驱动，推荐的工作方式是业务部门的业务专家把需求告知数据部门的数据工程师，在建模过程中深入沟通

结构

应用场景是多维的即席分析，采用大宽表形式组织

如果是特定指标的查询，可以采用k-v表形式组织

一次要查询多种信息，也可能会用复杂数据结构组织

应用数据表实现

调研业务应用对数据内容，使用方式，性能的要求

盘点现有DW，TDM层数据是否满足业务数据需求

组装应用层数据

多维自由聚合分析

指标组装成大宽表

特定指标查询

组装成k-v结构数据

应用数据场景化支撑

结果数据集要根据不同使用场景，同步到不同的存储介质

第8章——数据资产管理

数据资产的3个特征

企业拥有或控制

能带来未来经济利益

数据资源

数据资产管理现状和挑战

缺乏统一的数据视图

数据基础薄弱

数据应用不足

数据价值难估

缺乏安全的数据环境

数据管理浮于表面

数据资产管理4个目标

可见

数据资产地图

数据资产目录

可懂

通过元数据管理，完善对数据资产的描述

将数据资产标签化，标签是面向业务视角的数据组织方式

可用

通过统一数据标准，提升数据质量和数据安全性等措施，增强数据的可信度

可运营

数据资产管理在数据中台架构中的位置

处于中间位置，介于数据开发和数据应用之间

对上支持以价值挖掘和业务赋能为导向的数据应用开发，对下依托大数据平台实现数据全生命周期的管理

数据治理

车同轨书同文

如果数据没有得到良好的治理，就没有办法相信手中的数据是可靠的

六个目标

提升数据质量

构建统一的，可执行的数据标准

良好响应需求，保护数据隐私

培训员工

实现可重复的数据管理流程

数据可持续运营

六个原则

标准化

透明

数据的认责和问责

认责是数据治理的先决条件

问责和考核是制度保障

平衡

数据可商用是平衡原则的重要参考

变更

持续改进

十大领域

数据架构管理

数据开发

数据操作管理

数据安全管理

参考数据和主数据管理

数据仓库和商务智能管理

文档和内容管理

数据质量管理

七个环境因素

目标和原则

活动

主要交付物

角色和职责

技术

时间和方法

组织和文化

三个发展趋势

从质量管理到质量与服务并重

人工智能大幅提升数据治理效率

以元数据为核心的分布式数据治理

数据资产管理和数据治理的关系

数据资产管理就是传统的数据治理的升级版

数据资产管理职能

数据标准管理

标准体系框架

基础标准

业务术语标准

被批准，管理的业务概念定义的描述

参考数据和主数据标准

数据字典，是数据可能的取值范围

跨部门，跨系统共享的核心业务实体数据

数据元标准

描述数据的最基本单元

指标数据标准

一般由指标名称，指标解释，时间限定，其他条件限定，指标数值组成

通常数据标准相对好制定，落地就困难多了

制定的数据标准本身有问题

标准化推进过程中出了问题

对建设数据标准的目的不明确

过分依赖咨询公司

对数据标准化的难度估计不足

最容易出现的问题

缺乏落地的制度和流程规划

组织管理水平不足

解决之道

制定可落地的执行方案

事先确定好落地的范围

事先做好差异分析

事先做好影响性分析

元数据管理中的影响性分析可以帮助用户确定影响的范围

具体执行落地方案

事后评估

正确认识数据标准建设目的

正确认识咨询公司在数据资产管理工作前期的作用

充分认识到数据标准化的难度

实际落地中，建立起科学可行的数据标准落地形式

源系统改造

数据中心落地

绝大多数组织的选择

数据接口标准化

技术标准

平台和工具标准

管理标准

安全和隐私标准

行业应用标准

如果确实有多个不同口径需要同时存在，必须用不同的限定词把它们区别开

对于每一种指标，都必须明确阐述其唯一的业务含义，明确其计算公式，数据来源，限定范围，并确保这种指标标准是可供业务部门和技术部门参考，有专人维护的

由于组织内业务的复杂性，将收集到的所有参考标准都纳入数据标准管理中进行管理是没有必要的

数据模型管理

现状

生产库存在大量没有注释的字段和表

模型变更前没有任何合理性判断

模型修改过程中缺乏监督

模型是黑盒子或者没有模型

为了解决架构设计和数据开发的不一致，而对数据开发中的表名，字段名等规范性进行约束，一般与数据标准相结合

通过模型管理维护各级模型的映射关系，通过关联数据标准来保证最终数据开发的规范性

通过数据模型管理可以清楚的表达企业内部各种业务主体之间的数据相关性

关键活动

定义和分析企业数据需求

定义标准化的业务用语，单词，域，编码等

设计标准化数据模型，遵循数据设计规范

制定数据模型管理拌饭和实施流程要求

建设数据模型管理工具，统一管控企业数据模型

概念

元数据是描述数的数据

元数据是数据的户口簿

元数据是数据治理的核心和基础

元数据相当于所有数据的一张地图

有哪些类型的数据

有哪些信息系统，哪些数据库，哪些表，哪些字段

数据全量是多少，每日增量是多少

数据分布在哪里

数据之间有什么流向关系

现在流行的数据资产管理，知识图谱等，是建立在元数据之上的

有没有描述元数据的数据

有，元模型

元数据贯穿大数据平台数据流动的全过程

数据源元数据

数据加工处理过程元数据

指标层元数据

标签层元数据

服务层元数据

应用层元数据

类型

技术元数据

库表结构

字段约束

数据模型

ETL程序

SQL程序

业务元数据

业务指标

业务代码

业务术语

管理元数据

数据所有者

数据质量定责

数据安全等级

采集

指获取到分布在不同系统中的元数据，对元数据机械能组织，然后将元数据写入到数据库中的过程

采集方式

数据库直连

接口

日志文件

结构化数据的数据字典

非结构化数据的

元数据信息

代码

数据加工过程

管理

元数据的增删改查

必须经过元数据管理员的审核流程

元数据变更管理

元数据对比分析

元数据统计分析

应用

元数据浏览和检索

通过合理的权限分配，元数据浏览和检索可以大大提升信息在组织内的共享

数据血缘和影响性分析

主要解决数据之间有什么关系的问题

血缘分析是以历史事实的方式记录数据的来源，处理过程

在数据分析中发现问题数据时，可以依赖血缘关系，追根溯源，快速定位到问题数据的来源和加工流程

影响性分析分析数据的下游流向

减少系统升级改造带来的影响

有利于快速锁定元数据变更带来的影响，将可能发生的问题提前暴露

数据冷热度分析

主要对数据表的被使用情况进行统计，用图表展现表的重要性指数

对冷热度不同的数据做分层存储，更好的利用HDFS资源

主数据管理

用来描述企业核心业务实体的数据

企业核心业务对象，交易业务的执行主体

是在整个价值链上被重复，共享应用于多个业务流程的，跨越各个业务部门和系统的，高价值的基础数据

是各业务应用和各系统之间进行数据交互的基础

是业务运行和决策分析的基础

是企业信息系统的神经中枢

常见主数据

供应商

客户

企业组织结构

员工

产品

渠道

科目

交易方式

管理内容

主数据相关标准及规范设计

主数据建模

主数据梳理及集成

主数据质量管理

建立灵活的主数据共享服务

建立主数据维护流程

主要数据质量现状如何，谁来改进，如何提供，怎样考核的问题

数据质量问题产生的根源

流程

评估标准

准确性

完整性

一致性

有效性

唯一性

及时性

稳定性

连续性

合理性

梳理和分析数据治理问题，摸清数据质量的现状

针对不同的质量问题选择合适的解决办法，制定详细的解决方案

问题的认责，追踪方案执行的效果，监督检查，持续优化

数据质量问题解决方案的知识库

数据价值管理

数据共享管理

开展数据共享和交换

数据内部共享

企业内跨组织，部门的数据交换

外部流通

企业之间的数据交换

对外开放

数据输出监控

服务链路分析

影响度分析

异常监控警告

数据API服务管控

API接口鉴权认证

流量控制

访问次数控制

生命周期管理

不可恢复数据

永久保存

可恢复数据

原始数据

加工模型

标签管理

分类

数据分类方式

根据数据的来源，更新频率，归属部门等进行标识和分类

数据内容进行重新描述甚至重新组织的方式

根据行为特点组织的还贷能力，某个属性从业务视角的重新定义等

指标

是一种衡量目标的方法，主要是针对某个场景而提炼的一些关键评判维度

画像

某个对象从各个标签的维度的具体内容描述

字段

一种物理存储的形态。字段的取值具体画像的内容

数据资产门户

为用户提供多层次，多视角的数据资产图像化呈现方式

数据总量

每日数据增量

数据资产质量的整体状况

数据资产的分类情况

数据资产的分布情况

数据资产的冷热度排名

各个业务域及系统之间的数据流动关系

组织方式

业务域

数据来源

数据类型

用户角色

数据资产开发者

数据资产管理者

数据资产使用者

数据资产探索

数据资产管理效果评估

根据行业特点评估效果

金融机构

对数据标准和数据质量要求很高，适合自上而下开展干大数据资产管理

更重视数据标准和数据质量的实施效果

政府部门

打通不同政府部门之间的数据墙，业务墙，在海量数中快速找到所需数据

必须进行不同部门间的数据交换与共享

相对更重视数据的安全可控，数据交换的及时性和共享开放性

电信

重视数据资产是否被良好的组织和管理起来，是否实现了开放和共享

根据客户的不同诉求评估效果

数据资产健康度评价模型

建立数据资产健康评估维度

统计分析的数据不准

建设数据问题的血缘追溯功能，实现数据质量问题自动化诊断

数据标准不统一

首先统一企业内部的数据标准

指标标准

代码标准

数据开发标准

再进行其他方面的数据资产管理工作

数据资产管理的7个成功要素

强有力的组织架构

清晰的数据战略

重视数据的企业文化

合理的制度与流程

标准与规范

成熟的软件平台

科学的项目实施

数据资产的管理能力决定了一个企业能否完成数字化转型

第9章——数据服务体系建设

将数据资产封装成数据服务，以接口形式提供给上层应用，才能极大释放、提示数据资产的价值

补全数据应用的最后一公里

数据资产只有形成数据服务被业务所使用，才能体现其价值

通过数据服务便捷的对接业务系统或应用系统，才能将数据资产灵活使用起来

通过服务接口的方式对数据进行封装和开放，快速，灵活的满足上层应用的需求

定义和定位

数据服务是对数据进行计算逻辑的封装，生产API服务，上层数据应用可以对接数据服务API，让数据快速应用到业务场景中

数据服务是数据中台能力的出口，是支持数据应用的重要支撑

数据中台落地支撑业务时，数据分析师或算法工程师可以通过数据服务配置中台数据资产的访问API

数据服务分类

基础数据服务

面向的对象是物理表数据

面向的场景

数据查询

多维分析

通过自定义SQL方式实现数据中台全域物理表数据的指标获取和分析

标签画像服务

面向的对象是标签数据

标签圈人

画像分析

通过界面配置方式实现数据中台全域标签数据跨计算、存储的统一查询分析计算

算法模型服务

面向的对象是算法模型

智能营销

个性化推荐

金融风控

通过界面配置方式将算法模型一键部署为在线API

核心价值

确保数据在业务层的全域流通

降低数据接口的重复建设

保障数据获取的及时性和稳定高效

使能数据能力扩展

常见的数据服务

查询服务

输入特定查询条件，返回该条件下的数据，以API形式供上层应用调用

三个特征

支持配置查询标识，底层数据组织一般会对该标识建立索引，以加快查询速度

支持配置过滤项

支持查询结果配置

构建过程

数据库

文件

API

数据资产库

结果规则配置

能力开放

分析服务

借助分析组件高效的大数据分析能力，对数据进行关联分析，分析结果通过API形式供上层应用调用

四大特征

支持多源数据接入

高性能即席查询

多维数据分析

灵活对接业务系统

接口URL

后端服务类型

接口请求模式

把业务所需的数据通过各种数据库，API或文件等形式与分析组件进行对接

在线建模

本质上就是构建SQL语句的过程

SQL代码编辑器

图形化界面

对于生成的API，需要控制其使用权限

检索服务

圈人服务

从全量用户数据中，基于标签组合筛选符合指定特征条件的人群，并以API形式对接上层应用系统

3个特征

支持人群圈选

通过SQL代码或标签取值组合

支持人群计量

支持多渠道对接

对接下游业务系统

人群圈选

圈人服务本质其实是数据查询分析的过程

圈选出人群包名单

圈选的人群特征

推荐服务

按约定的格式提供历史行为数据和实时访问数据，推荐模型就会生成相应的推荐API，从而为上层应用提供推荐服务

3大特征

支持不同行业的推荐

不同行业背后的推荐逻辑是有区别的

支持不同场景的推荐

同一个行业中，对于推荐的使用也会存在不同的场景

支持推荐效果优化

推荐服务能够自我迭代，自我更新

从导入原始数据开始，经过推荐组件生成推荐数据，再根据用户的浏览数据不断修正推荐模型

选择行业和场景模板

不同行业不同场景背后的推荐模型不同

原始数据接入

用户相关数据

物品相关数据

关系类数据

参数配置

模型结构

样本指向

目标设定

输入输出格式

数据回流

风控服务

常见的数据应用

数据大屏

将数据可视化，提供业务决策支持

可视化框架

WebGL

three.js

Mapbox

基本流程

数据服务

可视化呈现

数据报表

对数据进行分析计算，通过表格，图像等形式展现

分析服务接口往往对接报表分析类的分析型数据应用

发展阶段

传统报表时代（记录能力）

统计报表时代（统计能力）

分析报表时代（分析能力）

统计报表

描述性统计

数据分析

探索性数据分析

假设检验

显著性检验