数据中台总结

原理

基础

几个时代

数据仓库
大数据出现
大数据平台
数据中台

数仓建模

恩门提出的建模方法自顶向下
- 这里的顶是指数据的来源，在传统数据仓库中，就是各个业务数据库
- 基于业务中各个实体以及实体之间的关系，构建数据仓库
金博尔建模，是一种自底向上的模型设计方法
- 从数据分析的需求出发，拆分维度和事实
- 那么用户、商品就是维度，库存、用户账户余额是事实
恩门建模因为是从数据源开始构建，构建成本比较高，适用于应用场景比较固定的业务，比如金融领域，冗余数据少是它的优势
金博尔建模由于是从分析场景出发，适用于变化速度比较快的业务，比如互联网业务

数据湖的概念

数据湖（Data Lake）是一个以原始格式存储数据的存储库或系统

大数据平台

大数据平台是面向数据研发场景的，覆盖数据研发的完整链路的数据工作台

大数据平台分类

数据集成
数据开发
数据测试
任务运维
磁层是 Hadoop为代表的基础设施

大数据平台的问题
1、指标口径不一致

业务口径不一致、计算逻辑不一致、数据来源不一致
要实现一致，就务必确保对同一个指标，只有一个业务口径，只加工一次，数据来源必须相同

2、数据重复建设，需求响应时间长

烟囱式的开发模式，导致了大量重复逻辑代码的研发
要解决数据需求响应慢，就必须解决数据复用的问题，要确保相同数据只加工一次，实现数据的共享

3、取数效率低

必须要构建一个全局的企业数据资产目录，实现数据地图的功能，快速找到数据

4、数据质量差

要解决数据质量差，就要及时发现然后快速恢复数据问题

5、数据成本线性增长

本质上跟重复建设有关

数据中台

大数据平台问题：重复开发的需求，导致数据割裂
数据中台的核心，是避免数据的重复计算，通过数据服务化，提高数据的共享能力，赋能数据应用
数据中台是企业构建的标准的、安全的、统一的、共享的数据组织，通过数据服务化的方式支撑前端数据应用
数据中台通过服务化的方式，提高了数据应用接入和管理的效率
对于非技术人员，数据中台提供了可视化的取数平台
实现了全链路的数据质量稽核监控，对一个指标的产出上游链路中涉及的每个表，都实现了数据一致性、完整性、正确性和及时性的监控

所有数据只加工一次

对于数仓数据，我们要求相同粒度的度量或者指标只加工一次，构建全局一致的公共维表
一个是数仓设计中心，在模型设计阶段，强制相同聚合粒度的模型，度量不能重复
另外一个是数据地图，方便数据开发能够快速地理解一张表的准确含义

方法论、组织和技术

如何去做才能实现数据只加工一次呢

对表的命名进行规范化统一

表的名称中最好能够携带表的主题域、业务过程、分层以及分区信息
对于仓储域下的一张入库明细表，如下：

数据中台适合采用分层的设计方式

ODS 原始数据层
DWD 明细数据层
DWS 轻度汇总数据层
ADS/DM 应用数据层 / 数据集市层

数据服务化，统一对外的接口

屏蔽异构数据源
数据网关：要实现包括权限、监控、流控、日志在内的一系列管控能力
逻辑模型：从用户的视角出发，屏蔽底层的模型设计的实现，面向用户提供逻辑模型
性能和稳定性：由于数据服务侵入到用户的访问链路，所以对服务的可用性和性能都有很高的要求，数据服务必须是无状态的，可以做到横向扩展

数据中台技术支撑

最底层是 Hadoop，Spark、Flink等等
浅绿色部分是大数据平台范畴的工具，从数据集成、数据开发、数据测试、任务运维
灰色的部分，是数据中台的核心组成部分：数据治理模块
以元数据中心为基础，在统一了企业所有数据源的元数据基础上，提供了包括数据地图、数仓设计、数据质量、成本优化以及指标管理在内的 5 个产品
深绿色的部分是数据服务，它是数据中台的门户，对外提供了统一的数据服务
最上面是面向不同场景的数据产品和应用

什么样的组织架构是适合数据中台建设

数据产品部门：负责数据中台、数据产品的体系规划、产品设计、规范制定、应用效果跟进，指标口径的定义和维护（有的部门是由分析师管理）
数据平台部门：负责研发支撑数据中台构建的产品，例如指标系统、元数据中心、数据地图等
数据开发团队：负责维护数据中台的公共数据层，满足数据产品制定的数据需求
应用开发团队：负责开发数据应用产品，比如报表系统、电商中的供应链系统、高层看板、经营分析

数据中台的下一站

实时数据中台，实现批流一体。
云上数据中台，全面拥抱K8S，实现在线、离线混合部署，进一步提高资源利用率。
智能元数据管理+增强分析，降低数据分析的门槛，进一步释放数据智能
自动化代码构建，通过拖拉拽，自动化生成ETL代码的构建，进一步释放数据研发的效能，甚至让我们的非技术人员都可以完成简单的数据加工。
数据产品的时代，面向各种行业的数据产品全面涌现，并且和中台系统联动，比如基于指标的可分析维度，自动进行指标的业务诊断等等

实现

元数据中心

元数据划为三类：

数据字典
数据血缘
数据特征

下图

dwd_trd_order_df 是一张订单交易明细数据
任务 flow_dws_trd_sku_1d 读取这张表，按照 sku 粒度，计算每日 sku 的交易金额和订单数量
输出轻度汇总表 dws_trd_sku_1d

数据字典描述的是数据的结构信息，我们以 dws_trd_sku_1d 为例

数据血缘

一个表是直接通过哪些表加工而来
dws_trd_sku_1d 是通过 dwd_trd_order_df 的数据计算而来
dwd_trd_order_df 是 dws_trd_sku_1d 的上游表

数据特征主要是指数据的属性信息，以 dws_trd_sku_1d 为例

元数据中心的产品

开源的有 Netflix 的 Metacat、Apache Atlas
商业化的产品有 Cloudera Navigator
Metacat 采用：集成型设计，每个数据源只要实现一个连接实现类即可
Atlas，实时数据血缘采集：通过实时抓取正在执行的 SQL，解析执行计划，获取输入表和输出表

Metacat架构

Atlas 架构

网易元数据中心设计

多业务线、多租户支持
多数据源的支持
数据血缘，支持字段级血缘
与大数据平台集成
数据标签

指标可以作为一种类型的标签打在表上，主题域、分层信息都可以作为不同类型的标签关联到表

网易的元数据中心

数据血缘由采集端、消息中间件、消费端以及血缘清理模块组成
图数据库选择 Neo4J，没有高可用方案，并且不支持水平扩展，不过单机也够了
血缘还有一个清理的模块，主要负责定时清理过期的血缘，默认 7 天
数据字典部分，类似Metacat，直连数据源
对于 Kafka、HBase、Redis 等 KV，在内置的元数据中内置一个元数据管理模块，定期他们的schema信息
数据特征主要是标签的管理以及数据的访问热度信息
元数据中心统一对外提供了 API 访问接口
Ranger 可以基于元数据中心提供的 API 接口，获取标签对应的表，然后根据标签更新表对应的权限，实现基于标签的权限控制
数据地图：元数据中心的界面

总结

数据指标

指标混乱现状，常见指标问题

相同指标名称，口径定义不同
相同口径，指标名称不一样
不同限定词，描述相同事实过程的两个指标，相同事实部分口径不一致

比如：黑卡会员购买用户数，计算周期内去重的，下单成功的
非会员的购买用户数，计算周期内去重的，非关单（购买成功取消订单）的用户
两者对非关单的包括不同，导致口径不同

指标口径描述不清晰
指标口径描述错误
指标命名难于理解
指标数据来源和计算逻辑不清晰

建设过程

面向主题域管理
拆分原子指标和派生指标
还需要指标命名规范
关联的应用和可分析维度
分等级管理
- 一级指标：数据中台直接产出，核心指标（提供给公司高层看的）、原子指标以及跨部门的派生指标。
- 二级指标：基于中台提供的原子指标，业务部门创建的派生指标
- 一级指标，要确保指标按时、保证质量产出，指标创建由中台负责
- 二级指标，允许业务方自己创建，中台不承诺指标的产出时间和质量

原子指标

指标名称适合用“动作 + 度量”的命名方式（比如注册用户数、购买用户数），标识的命名用英文简写或者汉语拼音缩写比较好

派生指标

指标名称应该严格遵循“时间周期 + 统计粒度 + 修饰词 + 原子指标”的命名方式，标识命名要用“修饰词 _ 原子指标 _ 时间周期”的方式

基于指标系统构建全局的指标字典

一个是面对一个新的指标需求，如何基于指标系统完成指标开发流程
另外一个是面对已经存在的，混乱的指标现状，如何进行全局梳理

先来看第一个场景

指标需求评审，需要需求方、数据开发、应用开发都参加。评审首先要确认这是不是一个新的指标，并明确它是原子指标还是派生指标。评审的目的就是要大家达成一致
评审的结果一种是不需要开发，是一个已经存在的指标;第二种就是需要开发
这个流程适用于一级指标，对于二级指标，可以不需要评审，当然开发也是由业务方开发和发布上线

第二个场景

成立以数据产品或者分析师为核心的 1～3 人的工作小组，专门负责指标的全局梳理
制定指标梳理计划，明确指标梳理目标，覆盖多少个业务线，与业务方共同制定时间计划
对于每一个业务线，需要对还在使用的数据报表、数据产品进行盘点，这里顺便可以把没用的报表和数据产品应该下线
对于每一个报表和数据产品中涉及的指标，按照以下格式进行收集
对于收集的指标，明确业务口径，对于口径相同的，应该去除重复，关联的应用应该合并，此时以我的经验，可以过滤掉相当一部分
根据指标业务口径，明确指标所属的主题域、业务过程
区分指标类型，对于派生指标，要明确指标的统计粒度、修饰词、时间周期以及关联的原子指标
按照指标系统对指标的规范化定义，把整理好的指标录入指标系统

总结

数据模型复用

表1

有 2547 张未识别分层的表，占总表 6049 的 40%，它们基本没办法复用
ODS：DWD：DWS：ADS 的读取任务分别是 1072：545：187：433，直接读取 ODS 层任务占这四层任务总和的 47.9%
说明有大量任务都是基于原始数据加工，中间模型复用性很差

表2

在已识别的分层的查询中，ODS：DWD：DWS：ADS 的命中的查询分别是 892：1008：152：305
有 37.8% 的查询直接命中 ODS 层原始数据，说明 DWD、DWS、ADS 层数据建设缺失严重

数据模型可复用，完善且规范

如何衡量完善度
DWD 层完善度

跨层引用率：ODS 层直接被 DWS/ADS/DM 层引用的表
占所有 ODS 层表（仅统计活跃表）比例
不允许出现跨层引用，ODS 层数据只能被 DWD 引用

DWS/ADS/DM 层完善度

汇总数据查询比例：DWS/ADS/DM 层的查询占所有查询的比例
汇总查询比例不可能做到 100%，但值越高，说明上层的数据建设越完善
一个比较差的模型设计，自下而上是一条线
而一个理想的模型设计，它应该是交织的发散型结构
模型引用系数：一个模型被读取，直接产出下游模型的平均数量
一般低于 2 比较差，3 以上相对比较好（经验值）

共享的数据中台建设

接管 ODS 层，控制源头
划分主题域，构建总线矩阵
构建一致性维度

维度统一的最大的难题在于维度属性的整合
如果维度是商品，那么商品类别、商品品牌、商品尺寸等商品的属性，我们称为维度属性
公共维度属性与特有维度属性拆成两个维表
产出时间相差较大的维度属性拆分单独的维表
出于维表稳定性产出的考虑，你可以将更新频繁的和变化缓慢的进行拆分
维度表命名规范：DIM_ 主题域 _ 描述 _ 分表规则
维度设计是维度建模的灵魂，也是数据中台模型设计的基础，维度设计的核心是构建一致性维度

事实表整合

统计粒度必须保持一致，不同统计粒度的数据不能出现在同一个事实表中
对于 ODS 层直接被引用产出 DWS/ADS/DM 层的任务，通过血缘，找到任务清单，逐个进行拆解

模型开发

所有任务都必须严格配置任务依赖
任务中创建的临时表，在任务结束前应该删除
任务名称最好跟表名一致，方便查找和关联
生命周期的管理，对于 ODS 和 DWD，一般尽可能保留所有历史数据，对于DWS/ADS/DM 需要设置生命周期，7～30 天不等
DWD 层表宜采用压缩的方式存储，可用 lzo 压缩

应用迁移

划分主题域

构建总线矩阵，明确每个主题域下的业务过程有哪些分析维度

维度表分表策略

总结

数据质量

一次典型的数据处理链路异常问题

数据运营发现 ADS 层的一张表有问题
由于处理链路很长，开发排查了 3 小时才找到根源
原因是数据格式解析异常
修复问题，因为链路很长，重跑需要 5 小时

数据质量问题的根源

业务源系统变更
- 首先是源系统数据库表结构变更
- 第二个是源系统环境变更，增加服务器，但是没配置同步任务
- 最后一个是源系统日志数据格式异常
数据开发任务变更
- 占总体问题的 60%
- 任务发布上线，代码中引用的测试库没有修改为线上库，结果污染了线上数据
- 任务发布上线，代码中使用了固定分区，没有切换为“${azkaban.flow.1.days.ago}”，导致数据异常
- 数据格式处理错误，代码忽略了异常，导致数据错误
- 没有配置依赖，前一个任务没有运行完，后一个任务就开始运行，输入数据不完整，导致下游数据产出错误
物理资源不足
- 多租户场景下，临时任务抢资源
- 开发写了很差劲的 SQL，多层嵌套，占用资源
基础设施不稳定

提高数据质量

早发现，早恢复

添加稽核校验任务

在每个任务处理完后，添加稽核校验
根据任务是否重要，开启电话、邮件、短信报警，
完整性规则，检查表数据量是否有波动
准确性规则，格式是否正确，如 IP地址等
一致性规则，两个指标是否能推导出第三个指标

建立全链路监控

基于数据血缘关系，建立全链路数据质量监控
通过智能预警，确保任务按时产出
通过应用的重要性区分数据等级，加快恢复速度
规范化管理制度

衡量数据质量

4 点半前数据中台核心任务产出完成率
基于稽核规则，计算表级别的质量分数
需要立即介入的报警次数
SAL：每个数据产品上所有指标有没有在 9 点产出，超时的按时间计算不可用SLA，99.8% 是相对较好的SLA

数据质量中心

首页提供了：稽核规则的数量、表的覆盖量以及这些规则的执行通过情况
绿色节点代表数据正常
蓝色节点代表数据正在产出中
红色节点代表数据异常
灰色节点代表产出任务还未被调度到

总结

成本治理

成本的陷阱

数据上线容易下线难
低价值的数据应用消耗了大量的资源
烟囱式的开发模式
数据倾斜
数据未设置生命周期
调度周期不合理
任务参数配置
数据未压缩

精细化成本管理的步骤

全局资产盘点

计算全链路数据资产视图中，末端数据的成本和价值
如果一个表被多个下游应用复用，那这个表的存储资源成本以及产出任务消耗的成本，需要分摊给多个应用

计算价值

末端是应用层表，看使用的人(根据人员等级加权重)，使用频率
特定场景的应用数据，看人群覆盖率，直接业务价值产出
轻度汇总，集市层，看使用范围和使用频率

发现问题

持续产生成本，但是已经没有使用的末端数据（“没有使用”一般指 30 天内没有访问）；缺陷 1
数据应用价值很低，成本却很高，这些数据应用上游链路上的所有相关数据；缺陷 2
高峰期高消耗的数据；缺陷 4 - 8

治理优化

对于第一类问题，应该对表进行下线
对第二类问题，需要按照应用粒度评估应用是否还有存在的必要
第三类问题，主要是针对高消耗的数据，又具体分为产出数据的任务高消耗和数据存储高消耗

治理效果评估

下线了多少任务和数据
这些任务每日消耗了多少资源
数据占用了多少存储空间

假设：

任务 A 运行时长 3 个小时，在运行过程中，共消耗 5384503 cpu*s
37007892 GB *s, 假设我们 1 个 CU （1 cpu， 4g memeory）一年是 1300 元成本
折合每天为 3.5 元（计算公式为 1300/365）

总结

数据服务

数据中台两个重要方法论

OneData
OneService

日常数据建设中存在的问题

不知道数据被哪些应用访问
数据接入方式多样，接入效率低
数据和接口没办法共享
底层数据变更，影响数据应用

数据服务应该具备的八大功能

接口规范化定义，可以看成是取快递约定的收货码，基于统一的收货码取走快递
数据网关，可以看成是我们对每个货架前的队伍进行限流，确保每个队伍都能取走快递
链路关系的维护，可以看作是驿站会记录谁取走了什么快递
数据交付，可以看作驿站同时提供取快递和送货上门服务
提供多样中间存储，可以看成有不同类型的货架
逻辑模型，可以看成是一个工作人员，可以取多个货架的快递
API 接口，可以看作是驿站的不同货架的不同队伍导览
API 测试，可以看作是驿站工作人员上岗前的测试

详细分析

数据网关层面，可以做安全验证，ak、sk验证，并发控制，熔断、限流等
实时推送最新数据，业务层可以捕获 kafka 的消息
利用中间存储，加速数据查询
逻辑模型，实现数据的复用，一个 view 底层关联多个不同物理数据源
构建 API 集市，实现接口复用

数据服务系统架构设计

云原生
逻辑模型
数据自动导出

总结

数据安全

安全的几个要点

数据备份/恢复
精细化权限管理
生产、测试集群隔离
删除数据垃圾箱设计
操作审计

数据备份与恢复

基于 HDFS 快照 + DistCp + EC 实现的
DistCp 通过对比快照数据，支持增量同步
冷备集群采用 5 副本，纠删码存储原理，可以降低一半的存储空间，适合冷备

快照原理

基于 S1 创建了一个快照，后面新增的文件，使用 diff 表示差异
通过 diff 就可以得到新增的数据，适合变化不大的场景

备份过程

备份内容

任务的备份，要保存任务代码、任务的依赖关系、任务的调度配置以及任务的告警、稽核监控等信息
表的备份主要是备份表的创建语句
数据的备份策略应该和数据资产等级打通，对于核心数据资产，数据中台应该强制进行备份

垃圾文件夹

只对于命令行有效果
对于 SQL 或者 API操作的，需要修改客户端
将 rm 改为 mv 操作
垃圾箱保留 24 小时，然后会默认同步到冷备集群

权限管理

OpenLDAP + Kerberos + Ranger 实现的一体化用户、认证、权限管理体系

OpenLDAP

是一个轻量化的目录服务，数据以树型结构进行存储
能够提供高性能的查询服务，非常适合用户管理的场景
Hadoop 可以使用 LdapGroupsMappings 同步 LDAP 创建的用户和用户组
在 LDAP 中添加用户和组时，会自动同步到 Hadoop 集群内的所有机器上

认证机制

采用 Kerberos

权限控制

Rnager 提供字段级别细粒度控制

操作审计机制

Ranger 支持审计的功能
用户的访问记录会由部署在各个服务（HDFS，HBase 等等）上的插件推送到 Audit Server 上

开发和生产集群物理隔离

传统企业，安全较高的，采用两套集群
普通企业，兼顾安全和开发效率，共享meta-store，而集群环境隔离

总结

实践

构建企业应用

初级阶段。一般企业的数据应用都是从数据报表开始的
发展阶段。一键执行，这个时候就要借助数据产品来实现
高级阶段。那么就要实现自助取数，让每个人都能基于数据去做分析和决策，实现普惠大数据

赋能 BI 工具

第一，统一报表指标业务口径
第二，掌握任务影响了哪些数据报表
第三，治理低价值的数据报表
第四，全维度钻取，比如天气导致打车业务增加，通过全维度找到天气

打造零售行业精益数据运营体系

找到业务问题、量化业务目标，比如，我们找到提高奶茶周转的关键，在于及时发现滞销奶茶品类，那么我们用动销率来衡量业务目标
然后要对业务目标持续监控，及时发现问题，比如，我们监控各个品类奶茶的销售情况，及时发现零动销奶茶
紧接着，要对问题进行诊断，比如，我们要发现奶茶滞销是因为口感太差
当然，还要根据原因形成决策，比如下线这款奶茶
最后付诸执行，比如通过一键，在所有门店菜单中去掉了该品类奶茶

释放取数效能

BI 部门一般有两项职责，一个是做报表，一个是取数
一年中做的报表可能就几百张，但是取数，一年可能要取几千次，或者上万次

自助取数

用图形化的方式，替代了写 SQL 的方式
提供了对业务人员比较友好的业务过程、指标、维度的概念，替换了表、字段
每个指标的业务口径都能够直接显示
用户通过选取一些指标和维度，添加一些筛选值，就可以完成取数过程
界面非常简洁，使用门槛非常低

总结

数据研发流程

关注一个协作流程

一个流程中涉及到了哪些环节
这些环节涉及到哪些角色参与
承载这个场景的工具产品是什么
这些环节之间是如何衔接的

标准的数据研发流程包括四个阶段

需求阶段
开发阶段
交付阶段
运维阶段
每个阶段中又涉及多个环节

需求阶段

数据需求通常是以指标的形式出现的
分析师在制作新的报表，数据产品经理在策划新的数据产品时，会提一些新的指标需求
然后就会在指标系统登记指标（包括指标的业务口径、可分析维度、关联的应用、时间周期信息）
后面是等待评审，包括：
指标是新指标还是存在的指标；
如果是新指标，那么是原子指标还是派生指标
确认指标业务口径、计算逻辑和数据来源

研发阶段

利用数据地图发现已经存在的表，然后理解这些表中数据的准确含义
在模型设计过程中，要对模型中每个字段关联前面设计好的指标，以及可分析的维度
开发后找到对应主题域负责人审批
检查数据是否重复建设，复用性、完善度、规范性
模型变更增加字段，通过数据血缘通知所有依赖这个表的下游任务负责人

数据开发

清洗加工后，在数据开发中心开发数据ETL 任务，实时/离线
数据测试中心，验证数据
一个是进行数据探查，确定新加工的数据是否符合预期
另外一类是对原有模型的重构，新增字段或者更新部分字段
数据对比：不仅要验证新加工数据的正确性，还要确保原有未修改数据与修改前是否有改变
SQL静态代码检查，检查：使用了固定的分区，测试环境库，笛卡尔积等，扫码通过才能上线
配置稽核校验规则，主键唯一性监控，表行数波动值，以及一些业务规则监控

发布

申请配置参数是否合理，比如Spark Executor 的CPU和内存分配
任务依赖，报警是否正确，核心任务要有循环报警
检查稽核规则是否完备

交付阶段

数据开发不仅需要加工数据，还需要把数据发布成 API 接口或者其他服务形式
如读Hive 表写入到某个中间存储
数据开发可以基于中间存储发布 API 接口，定义输入和输出参数
最后，应用开发在数据服务上创建应用，然后申请对该接口的授权

运维阶段

在这个阶段的第一责任人是任务负责人（一般是这个任务对应的数据开发）
数据开发接到报警后，要第一时间认领报警
任务运维中心提供了报警认领的功能，数据开发点击认领，代表数据开发开始处理这个报警
如果报警迟迟没有人认领，任务运维中心会每隔 5 分钟会发起一次电话报警，直到报警认领
如果报警一直没有认领，系统会在 3 次报警，15 分钟后进行报警的上报，发送给模型所在域的负责人

修复问题

排查上游的任务稽核是否正确，输入数据是否异常
通过日志排查问题，确认后修复，重跑
发送“下游任务需要进行重跑”的通知
故障恢复完，还要进行复盘，其中重要的事情就是补充稽核规则，确保不再出现犯过的错误

落地高效的数据分析流程

第一步：发现业务问题，如某个季度销售额下降30%
第二步：理解数据
- 要分析的业务过程
- 这些业务过程中涉及到了哪些关键指标
- 这些指标的业务口径是什么
- 有哪些可以分析的维度
第三步：探索式分析
- 如果现有的数据可以满足分析的需求，她可以直接在数据地图表详情页上发起数据权限的申请流程
- 如果现有的数据没办法满足需求，甄可爱就要对数据开发提出数据研发的需求，会稍显麻烦
- 需要开通相关权限
第四步：可视化展现
第五步：分析过程产品化
- 将分析过程固化到数据产品中
- 研发了供应链决策协同系统，能够自动检测商品的库存和销售，智能生成补货建议，然后推送给采购系统

制订资产等级的标记规则

一方面是数据本身涉及企业的核心机密，比如 KPI、产品日活、毛利等
另外一方面因素是根据数据应用的优先级，然后基于全链路的数据血缘制订数据的等级

总结

中台建设

如果你要建中台，要做到这样几点：

问问自己为什么要建中台，与业务达成一致的目标
把数据中台作为一个公司级别的顶级项目来推进，而不是一个数据部门自己的 KPI
数据中台必须要有清晰的、可量化的价值来衡量（从主观上也要得到业务部门的认可）

立项数据中台项目

如果能达成一个一致的、可量化的目标，数据中台的项目就成功了一半。
调研：当前数据使用过程中存在哪些痛点
调研：当前业务部门最关注的业绩目标
传统企业，更关注业绩目标（让企业达成KPI)

几个问题

第一，指标业务口径不一致
第二，需求响应速度慢
第三，取数效率低
第四，数据经常违反常识
第五，数据成本指数级增长

数据中台部门考核 KPI，跟其他团队共背

包含中台建设和业务支撑两部分
前者对应的是业务痛点，后者对应的是业务目标
从业务出发制订的这两部分内容，这是业务愿意和中台团队达成共建 KPI 的基础

推进数据中台项目落地

第一步，调整团队组织架构，明确各个团队的职责
- 成立数据中台团队
- 原先三个小数仓独立的，先跟一个整合，其他两个基于中台的数据做加工
- 否则业务部门会认为在抢人，员工因为团队定位、福利等原因不愿意转部门
第二步，数据整合
- 跟业务梳理各种指标，分解原子指标
- 对模型重构，整合，迁移，建设主题域
- ODS必须由中台完全接管，但是压力会很大
第三步，研发工具产品
- 跟基础团队合作，承担中台支撑技术产品研发
- 包括数据研发、数据治理、数据服务、数据分析应用、标签应用
- 正交化产品设计。每个产品聚焦一个应用场景，构建产品矩阵，简化了系统使用的复杂度
- 全链路打通，形成产品闭环。比如任务运维中心与有数报告打通，可以看到一个任务影响了哪些下游报表
- 组件式产品架构，允许业务根据场景搭配产品使用，形成面向不同场景的解决方案能力，例如数据质量解决方案、成本优化解决方案
- 轻型易用、降低用户门槛，尤其注重非技术人员的交互体验
第四，数据产品构建

总结数据中台项目成果

快：研发交付时间大幅缩短、自助取数频率大幅度提高
准：100%数据产品指标业务口径一致；数据质量 bug 数量下降
省：优化高消耗任务，节省资源 40%

EasyData 数据中台支撑技术工具列表

数据用的好不好，主要看这样几点

数据需求的交付时间到底有没有缩短；
还存不存在指标业务口径不一致的问题；
数据质量是否有显著的提升；数据成本是否增长变慢了
数据使用的成本到底有没有降低，只有真正降低了，才能让更多的人用

数据解决了什么业务问题

帮助零售行业解决了库存周转慢的问题
帮助物流行业提前发现了快递延迟的风险

数据中台和业务的关系，就是鱼和水的关系，谁也离不开谁
业务想要获得更大的增长，就必须依赖数据中台，数据中台想要存活下去，就必须依赖业务的口碑和认可

总结

原理

基础