首页  思维导图  详情

数据中台:让数据用起来，阅读笔记总结

2022-10-26 16:06:11   0  举报





AI智能生成

为你推荐

查看更多



数据中台:让数据用起来，阅读笔记总结

作者其他创作

大纲/内容

独立采购和自建信息系统

新模式下产生的外部数据

数据孤岛问题

多云环境出现

底层数据互联互通

IT架构变的复杂

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

服务业务化

资产服务化

数据资产化

业务数据化

前言

充分协同并融入业务流程

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

云原生和能力开放

智能化

数字化平台特征

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

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

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

三个核心认知

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

业务自流程化

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

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

数据中台探索

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

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

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

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

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

数据服务化的能力

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

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

颠覆传统的软件工程方式

业务实现自流程化

数据实现自我管理能力

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

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

企业业务空间

自主产生和消费的数据

单向外部获取数据

单向对外提供数据

外部数据

内外部交互数据

企业数据空间

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

数据中台发展三个阶段

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

软件功能驱动

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

数据治理驱动

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

业务能力驱动

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

业务服务化驱动

四种信息化建设模式

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

数据采集

交换

监控管理

数据集成

数据安全

部署灵活

汇聚整合

完善的安全访问机制

完善的数据治理保障体系

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

面向业务主题的资产平台

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

提纯加工

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

数据分析功能

数据可视化

便捷快速的开发环境

实时流数据分析

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

服务可视化

数据应用管理能力

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

跨业务场景能力

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

基于场景的数据应用

业务行动效果评估

价值变现

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

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

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

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

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

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

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

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

数据中台VS业务中台

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

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

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

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

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

数据中台VS数据仓库

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

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

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

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

数据中台的业务价值

报表

批量离线计算

指标统计和实时推荐

实时流式计算

圈人

决策类业务和ad-hoc需求

即席计算

用户画像

高并发业务

在线计算

应对多数据处理的需求

主数据

参考数据(引用数据)

指标数据

数据分类

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

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

支持跨主题域访问数据

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

数据中台的技术价值

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

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

1种战略

数据采集意识

数据标准化意识

数据使用意识

数据安全意识

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

通过流程加速组织变革

2项保障条件

数据可见，可用，可运营

3条目标准则

骨架

技术体系

血肉

数据体系

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

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

灵魂

服务体系

运营体系

4套建设内容

组织现状

业务现状

数据现状

技术现状

理现状

组织架构

业务架构

技术架构

应用架构

数据架构

立架构

资产萃取

数据标准

数据质量

建资产

场景服务

用数据

监控审计

价值评估

质量评估

资产排名

做运营

5个关键步骤

数据中台建设方法论

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

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

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

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

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

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

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

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

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

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

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

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

统计分析

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

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

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

决策支持

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

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

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

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

数据驱动

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

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

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

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

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

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

实现目标五大条件

运营优化

企业数据应用成熟度评估

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

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

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

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

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

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

无埋点

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

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

全埋点

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

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

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

可视化埋点

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

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

代码埋点

客户端埋点

HTTP服务器上的access_log

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

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

服务端埋点

线上行为

wifi信号采集

信令数据采集

图像视频采集

传感器探测

线下行为

用户行为

互联网数据采集

结构化

半结构化

非结构化

数据组织形式

全量

增量

离线

增量日志

通知消息

实时

时效

内部数据汇聚

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

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

转换放在最后因为

ETL和ELT

数据采集和汇聚

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

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

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

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

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

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

oracle

mysql

sqlserver

greenplum

关系型数据库

redis

hbase

Cassandra

mongodb

neo4j

nosql

kafka

http

网络及mq

hdfs

ftp

oss

csv

txt

excel

文件系统

hive

impala

kudu

maxcompute

adb

libra

elk

大数据相关

数据源

数据源管理

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

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

读取插件

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

写入插件

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

数据交换核心模块

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

前置稽核

数据转换

跨集群数据同步

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

全量同步

新增

覆盖

更新

增量同步

离线数据同步技术亮点

离线数据交换

数据的订阅和收取

任务实例的启停控制

数据订阅服务

任务状态控制

数据解析

数据过滤

数据写入

数据消费服务

实时数据交换

数据交换产品

数据规模

数据生产方式

数据应用方式

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

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

在线与离线

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

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

OLTP与OLAP

存储技术

数据存储

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

企业有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

实现方式

即席分析

数据计算能力四种类型

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

覆盖所有业务过程数据

覆盖全域数据

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

结构层次清晰

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

数据准确一致

性能提升

降低成本

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

方便易用

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

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

操作明细层ODS

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

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

统一数仓层DW

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

标签数据层TDM

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

应用数据层ADS

数据分层

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

ODS的数据只能被DW使用

DW数据只被TDM和ADS使用

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

数据读取规范

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

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

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

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

抽取过程尽量简单

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

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

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

从业务系统DB抽取到ODS

结构化数据

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

半结构化数据

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

非结构化数据

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

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

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

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

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

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

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

数据表设计规范

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

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

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

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

清理目标表对应数据

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

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

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

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

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

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

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

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

业务板块

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

模型设计

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

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

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

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

数据域

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

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

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

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

业务过程

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

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

修饰词

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

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

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

原子指标

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

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

派生指标

汇总，平均，最大，最小

计算方式

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

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

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

维度表

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

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

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

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

事实表

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

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

原子粒度事实必须保留

粒度

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

一致性指标定义