数据中台(好用请点赞) 思维导图模板_ProcessOn思维导图、流程图

起源

"中台"某种意义上是正宗的中国概念，早在2015年，马老师访问过北欧的Supercell游戏公司之后，便提出了这个概念。随之而来的，是阿里带动的“大中台、小前台”运动。这个概念听起来还是非常不错的，因为整合技术力量，既能够有效降低研发成本，也能够带来业务上更多的试错机会。

前提条件

业务：多元协同的业务体系

才有必要建设数据中台

组织：步调一致的数据团队

才能建设数据中台

系统：全局统一的业务系统

才能建设数据中台

平台：完善高效的研发平台

才能建设数据中台

优点

中台提供通用的业务解决方案和通用的技术解决方案，对业务前台业务做强有力支撑。

避免重复建设

业务沉淀

业务协同

快速响应

快速试错

快速创新

价值

消除指标不一致

在做数据中台之前，指标业务口径不一致，数据来源不一致，计算逻辑不一致，经常是造成同个指标结果不一样的原因。通过指标系统，我们对所有数据产品的指标进行了全面梳理，按照主题域、业务过程进行划分，对指标按照原子指标和派生指标进行拆分，消除冗余指标、无效的指标，明确所有指标的业务口径、计算逻辑和数据来源。通过指标系统，我们可以快速的查询，数据产品上直接引用指标系统的业务口径，在数据产品上，我们完全消除了指标的二义性。

提升数仓设计水平

在做数据中台之前，我们有大量的表没有明确的主题域和业务过程划分，大量汇总层数据直接引用原始数据，ODS 层有大量的任务直接引用，大量 Query 直接查询原始数据。在数据中台建设后，整个数仓水平上了一个台阶，不仅所有数仓维护的非中间表均有明确的主题域和分层，并且完全消除了汇总数据直接引用 ODS 层原始数据的情况，数仓表的复用性显著提高，汇总层 Query 的覆盖率明显提升。

提升取数效率

在做数据中台前，大量的数据发现都是通过人工协作交流的方式进行的，数据理解的准确性、效率都非常低。基于数据地图，我们实现 100% 自助取数，取数效率提升 300%，分析师满意度得到大幅提升。

提升数据质量

在做数据中台前，数据经常无法按时产出。我们规定每天 6 点前数仓的数据要产出完成，但是往往达不到这样一个要求，出现一个异常，经常被业务方投诉，而排查和定位一个故障，也需要大量的时间，有了数据质量中心后，通过大量的稽核监控规则，我们做到了先于使用数据的人发现数据的问题，并且基于全链路的监控，我们可以知道某个任务异常，影响了哪些指标，并且基于任务的历史运行数据，对故障恢复时间进行预测。

降低数据成本

衡量这个其实是最简单的，直接就看数仓消耗的资源，原先是多少，数据中台建设之后又是多少，当然这里面存在业务增长的情况，我们核算的方法是把单个任务的成本占优化任务时，数仓消耗的当日成本占比，作为衡量指标，我们最终通过下架无用的、低价值的表和任务，为业务节省了 20% 的成本。

缺点

建设成本比较高，无论是人员、系统，还是平台都需要投入巨大成本，如果公司业务不够多元丰富是没有必要建设数据中台的。

建议

首先要有目标和度量，不管是做质量，还是成本，还是效率，没有目标，没有度量，就很难讲的清楚效果。其次，要通过系统化的方式对规范和方法论进行沉淀。数据中台不是一次性的事情，做质量，稽核监控规则要不断的完善，治理成本，任务和表的优化要持续进行。所以必须要有系统和产品做支撑。

直观感受

开发平台

DataWorks、Simba、网易猛犸

数据仓库

模型分层

基础数据

业务的数据化还原，积蓄数据价值的势能，关键词"还原"

ODS、DIM、DWD

指标系统

数据的业务化应用，应用业务场景的沉淀，关键词"沉淀"

DWB、DWS

数据产品

数据的价值变现，实现数据驱动业务，关键词"变现"

DM、APP、RPT

数据分域

交易、产品、用户、流量、营销、服务、供应链、物流、风控、金融、社交、公共

数据体系化建设思路

三级火箭

基础数据

指标系统

数据产品

电线面体

点：维度、指标

线：业务过程

面：数据域

体：数据体系

金字塔评估模型

准确性

数据口径符合业务需求，计算结果准确无误

及时性

数据产出的时间满足各类业务的时效性要求

稳定性

数据体系运维规范有保障，任务运行稳定可靠

规范性

模型的层次划分和任务依赖关系合理规范，表和指标的命名以及代码格式有规范可依

一致性

同一维度属性和指标的口径、命名和计算逻辑统一

易用性

数据体系丰富完整，使用方便快捷，开发维护成本低

BI分析工具

QuickBI、网易有数

可视化平台

AntV、DataV

机器学习平台

PAI、SageMaker

数据体系

全局概况

组织

前台：BI、算法、风控

具体业务场景的数据化应用

中台：数仓

模型架构、数据内容体系化建设

后台：平台

存储、计算、开发工具

规模

350台离线集群

16PB存储，日增45T

40000多张表

12000多任务

日均接口调用1亿+

业务功能架构

数据应用

离线报表

实时计算

流量分析

接口调用

自助取数

指标体系

会员

商家

营销

流量

物流

商品

服务

。。。

基础数据

一致性维度表

事务性事实宽表

累计快照事实宽表

周期快照事实宽表

数据接入

离线数据

准实时数据

实时数据

数据源

交易、商品、会员、商家、营销、服务、供应链、物流、服务、金融、社交、流量、公共

技术架构

数据产品

星云/星空

实时直播厅

比邻星

数据服务

自助取数

实时计算

观星台

数据服务

Hive

Mysql

HBase

ES

数据计算

离线计算(HiveSql、SparkSql)

实时计算(Jstorm、Flink)

数据存储

离线存储(HDFS、Hive)

消息中间件(Kafka)

分布式存储(HBase)

数据采集

离线数据同步(Datax、Sqoop)

Mysql、Oracle、DTS

实时数据同步(Canalx、Flume)

Binlog、Log、API

数据技术

日志采集

数据同步

离线数据开发

实时数据开发

数据服务

数据挖掘

数据模型

模型概述

指标管理

纬度设计

事实表设计

数据管理

元数据

计算管理

存储管理

数据质量

质量保障原则

完整性

记录缺失：通常每天大于100万条，几天10万条

字段缺失：用户id、商家id、支付时间、创建时间

准确性

金额为负值

时间小于1970

当日GMV小于平均值30%

订单中没有用户id或商家id

一致性

例如用户id在所有业务中保持一致性

及时性

小时级

秒级

质量保障方法

消费场景知晓

通过数据资产等级和元数据链路分析解决消费场景知晓的问题，确定资产等级，并上推至各个加工环节，根据不同等级采用不同的生产加工方式

数据资产等级

毁灭性质A1

出错会造成重大资产损失，面临重大收益损失，面临重大危机公关风险

例如：财务报表

全局性质A2

直接或间接影响级业务和效果的评估、重要平台运维、对我数据透露等，总之是集团级别的

例如：商家运营中心

局部性质A3

直接或间接影响公司内一般数据产品或运营数据产出，给事业部或者事业线造成影响，总之是业务部或者事业线级

例如：某业务运营平台

一般性质A4

常规运营数据，如果数据延迟或者出错不会带来影响或者影响很小

例如：临时报表和数据

未知性质Ax

未明确表明数据的使用场景，标记为未知

数据资产等级落地方法

通过数据产品和应用场景等级打标(例如A2)，然后再根据元数据给整个链路打标(A2)

例如：商家运营中心

数据生成加工各个环节卡点校验(一致性)

OLAP(在线系统)

工具

离线人员订阅重大发布过程(数据资产等级)

比如财报、商家中心等业务逻辑变更

离线人员订阅重要的DDL过程(数据资产等级)

人

操作工具的是人，离线数据资产等级的概念要传达给在线开发任务，开发人员在重大发布或者重要数据变更时应该主动通知到离线开发人员，通过培训将离线开发诉求、离线数据加工过程、数据产品的应用方式告诉在线开发人员，让其意识到数据的重要性，意识到数据的重要价值，告诉其出错的后果，做到业务端和离线端数据的一致性

事前培训告知

事中订阅监控

事后故障复盘

OLTP(离线系统)

SQLSCAN

代码扫描，提示风险点

测试

线下测试

Code Review

代码检查

规范

暴利扫描

优化点

回归测试

保障新逻辑正确，同时保障旧逻辑不受影响

线上测试

Dry Run

保证不会因为线上和线下环境不一致导致代码执行错误

变更通知

节点变更或者数据重刷通知，将变更原因、变更逻辑、变更测试报表、变更时间通知到下游，下游无异议后，按照约定时间发布变更，将变更影响降到最低

风险点监控(准确性)

OLAP(在线系统)

BCP(实时业务监测平台)

第一步：用户在BCP中针对某个业务表订阅消息

第二步：用户配置业务规则，即准确性校验的逻辑，比如支付时间为空、时间不是当天、金额为0等

第三步：配置告警，消息通知到订阅相关人

OLTP(离线系统)

DQC(数据质量中心)

数据准确性

强规则

主任务添加检查点，不通过置错

检查的过多影响业务产出，仅针对重要数据资产等级数据强覆盖

弱规则

针对枚举值、为空、阈值、波动配置规则监控，只通知不影响业务正常产出

数据及时性

任务优先级

调度系统重点保障重要资产等级数据，从叶子节点发起，所有上游任务都是相同等级

调度队列

优先策略

强告警(强阻塞)

告警范围

监控任务以及所有上游任务

告警类型

错误告警

基线告警

变慢

变长

预警

最近N天产出时间，提前预警

何时告警

一般根据业务配置时间

告警对象

owner

oncall

告警方式

邮件

钉钉

短信

电话

自定义(非阻塞)

目的：主要是给用户自定义监控任务产出情况，一般强规则是数仓运维人员预警使用，自定义更多用于用户

告警类型

出错告警

告警范围

告警对象

告警方式

完成告警

未完成告警

周期性告警

超时告警

质量衡量

起夜率

数据质量事件(oncall事件)

首先：用来最终质量问题处理过程

其次：归纳质量问题的原因

最后：找出方案，避免下次再次出现

数据质量故障保障体系(故障复盘)

背景：从数据采集到数据消费，中间要经过几十个系统，任何一个环节出错都会导致数据异常，因此需要一个机制，把各个团队绑在一起，形成合力。

范围：对公司造成重大资损和公关危机

财报数据错误

商家数据错误

微贷信息错误

高管报表延迟或出错

故障定义：失败重要数据业务和资产，注册到任务中，填写号业务相关情况，如技术负责人、业务负责人、数据应用场景、延迟和错误带来的影响、是否发生资损等，最好挂到基线中，一键形成故障单。

故障等级：可以根据故障时长、故障投诉率、故障造成资损大小，团队也会根据故障分作为运维考核的一项

故障处理：尽快发现问题、尽快处理、并把处理进度通知到各相关方

故障复盘：分析原因、处理过程复盘、跟踪后续结果、故障定位到人，复盘不是为了惩罚人，而是避免问题再次发生

质量配套工具

BCP

DQC

SQLSCAN

Dry Run

测试环境

告警系统

数据应用

应用部门：运营、产品、管理、搜索、推荐、广告、商家、算法、信用、文娱、金融

应用场景

报表

静态报表、Dashboard等报表统计分析

多维分析

OLAP、即时查询等工具型数据产品

专题分析

某一业务场景，沉淀分析思路

智能型数据应用产品

个性化搜索、推荐、广告定向推送、精准营销

对内服务

用户：销售、BD、运营、产品、技术、客服、管理者

痛点：用户对业务发展中数据监控、问题分析、商业洞察、决策支持

价值：高效获取数据、合理分析框架、数据辅助业务决策

一般数据产品建设历程

临时需求取数

临时需求、主要靠数仓人力支出、无产品概念

优点

快

缺点

人力成本高、效率低、不能支持海量需求

自助报表取数

采用商业BI工具支持常用分析需求

优点

自动化、高效、增强可读性

缺点

扩展性差、很难支撑海量个性化需求

自助研发BI工具

自研BI工具支持更为复杂的数据分析需求

优点

支持更多复杂的个性化需求、自动化、高效、可读性好

缺点

研发投入成本高，一般公司投入产出比不高

数据产品平台

数据监控

普通运营：自己DIY数据门户

专题分析

专题运营：自助分析

应用分析

对接前台系统：自动应用分析

数据决策

高管和决策者：数据辅助决策

对外服务

商家中心

访客

访客身份、性别、年龄、关键词偏好、地域、价格敏感度、优惠偏好、卖家等级、买家等级、评价信息、退货情况、换货情况、新老买家

商品

商品PV、访客数、买家数、订单数、交易件数、访问-下单转化、下单-支付转化、库存、价格、图片、类目、评价、优惠措施、来源关键词

流量

PV、PV趋势、来源、来源PV、页面类别、页面类别PV、流量TOP商品、流量TOP访客、广告流量

交易

订单数、买家数、新老买家、客单价、交易金额、退货、退款、评价、满意度、动态评价

转化

新品转化、旧品转化、来源转化、新买家转化、老买家转化、广告转化