网易数据中台
2020-07-20 10:54:29 5 举报AI智能生成
网易数据中台（即客时间课程笔记）
作者其他创作
大纲/内容
网易数据中台（即客时间课程笔记）
八： 流程协作
数据研发流程
需求阶段
工具
指标系统
涉及角色
数据产品、数据开发、应用开发、分析师
产出
指标业务口径、数据来源、计算逻辑
核心
指标的规范化定义
研发阶段
设计阶段
模型设计中心
数据架构师、数据开发
模型
基于主题域、分层的维度建模
开发阶段
数据集成
离线数据开发/实时数据开发
数据测试
数据质量中心
数据开发
任务
先设计后开发
交付阶段
数据服务
应用开发、数据开发
API 接口
数据提取到中间存储、发布API接口
运维阶段
任务运维中心
任务文档运行
早发现、早恢复
数据分析流程
认识数据
承载产品
数据地图
目标
帮分析师快速准确理解有哪些指标、数据可以用
探查式分析
自助分析
通过SQL方式探索分析，找到问题
可视化展现
网易有数
基于数据，实现可视化展示分析过程
数据产品化
数据产品
将分析思路固化到数据产品，并进行持续监控，自动生产决策建议，付诸行动
资产管理流程
成本管理
成本治理中心
下线无用、低价值得数据、报表，甚至数据产品
资产管理员制定规则，系统自动通知对应数据开发，实现一键下线
资产等级
前提
与权限申请流程、数据和任务发布上线流程打通
数据管理中心
规则
数据应用向上溯源
涉及企业核心机密、KPI
九： 数据应用
数据应用的三个阶段
初级阶段
BI 数据报表
发展阶段
高级阶段
自助提数
数据中台对BI赋能
指标口径一致性
数据报表的数据质量
报表治理
每张表的加工成本
增强分析
全维度钻取
打造零售行业精益数据运营体系
拉新
基于数据评估广告渠道转化效果
基于数据计算人群画像，推正确的商品给正确的人
指标：新消用户数，新消APRU，新销单客成本
基于数据计算用户喜欢的种类
促活
门店，定向推送折扣信息
供应链
基于数据，精准预测销量，自动生产采购计划
滞销商品监控
基于数据分析原因，及时干预
构建数据产品
量化目标
持续监控
诊断分析
决策建议
执行
问题
靠技术人员喂饭，取数效率低，每周100次临时取数
数据开发50%的时间用于临时取数
EasyFetch
拖拉拽图形操作，替代SQL
对业务人员友好的指标、维度
SQL 跟进查询自动优化
自助取数效果
数据开发50%的临时取数下降到10%，更加专注于数据中台公共模型构建
取数效率提升10倍
十： 数据中台由来
启蒙时代：数据仓库的出现
BI 商业智能
企业分析决策
报表+取数
概念
数据仓库是在企业管理和决策中面向主题的、集成的、与时间相关的，不可修改的数据集合
Bill Inmon 比尔.恩门
自顶而下
从数据源出发
实体以及实体之间的关系
Ralph Kimbal 金博尔
自底而上
从需求出发
从分析场景出发
实时+维度
技术革命：从 Hadoop 到数据湖
互联网时代的商业智能
数据规模
海量数据
数据类型
结构化
半结构化
非结构化
Hadoop
完全分布式，易扩展
弱化数据格式
数据格式与数据存储隔离
数据湖
一个以原始格式存储数据的存仓库或系统
Hadoop 商业化
数据工厂时代：大数据平台兴起
工作流
数据发布
任务运维
基础设施
计算
Hive/Spark
离线
Flink
实时
Impala
交互式查询
存储
HDFS
全量数据
不可更新
Kudu
实时更新能力
实时数仓
HBase
可更新的KV
资源调度
Yarm
K8S
数据价值时代：数据中台崛起
原因
数据割裂
重复开发、计算
数据结果不一致
数据中台内容
借鉴传统数据仓库面向主题的数据组织模式
依赖大数据平台的数据开发全流程、数据治理和数据服务
构建于数据湖之上的基础设施
维度建模
统一数据公共层
趋势
云上数据中台
十一： 建设数据中台背景
一： 数据中台解决的问题
1. 指标口径不一致
业务口径不一致
计算逻辑不一致
数据来源不一致
2. 需求响应慢
3. 取数效率低
找不到数据
企业数据资产目录
取不到数据
提供可视化的查询平台
4. 数据质量差
5. 数据成本增长过快
数据成本
资源成本
人力成本
二： 问题背后的原因
缺失全局统一的指标管理
必须要有一个团队统一负责指标口径的管控
数据管控能力缺失
最好是数据产品团队
烟囱式的开发导致数据重复建设
烟囱式开发模式
找不到数据，SQL又不适合非技术人员
使用门槛高，对非技术人员不友好
数据加工链路长，出现问题很难及时发现
缺少全链路数据质量监控
数据重复建设，无用的数据加工也消耗了大量资源
成本粗放式管理
技术系统跟不上
组织架构分散
三： 数据中台如何解决
确保全局指标业务口径、数据来源、计算逻辑一致
流程规范缺失
相同聚合粒度的度量、指标只加工一次，避免重复建设
数仓规范
数据字典
构建企业数据资产目录，提供非技术人员取数工具
全链路稽查监控，早发现、早处理、早恢复
计算每个应用、报表、直白的ROI，避免低价值的数据加工
四： 什么样的企业适合建设数据中台
拥有3个以上的数据应用场景
存在业务数据孤岛
面临效率、质量何成本问题
需要借助数据提高企业经营效率
业务相对稳定且有一定规模的公司
十二： 数据中台建设方法论、组织和架构
方法论
OneData
方法
分主题域管理
命名规范统一
主题域、业务过程、分层以及分区信息
指标口径统一
数据模型复用
数据完善
包含
数据发现（数据地图、元数据）
指标管理
模型设计
数据质量
成本优化
OneService
屏蔽异构数据源
MySQL 数据量小
HBase 数据量大，超过500W
Greenplum 多维分析
Redis 实时要求
ES 全文检索
数据网关
权限
监控
流控
熔断
逻辑模型
屏蔽底层物理模型设计
性能何稳定性
无状态设计
支撑技术
数据应用
自助取数
非技术人员
分析师
数据开发工程师
标签工厂
数据治理
元数据中心
数仓设计
大数据平台
大数据基础设施
组织架构
数据中台的组织架构是数据中台建设的第一步
独立于业务线的中台组织部门
中台团队必须深入业务，懂业务
中台团队的组织架构
负责数据中台、数据产品的体系规划
产品设计、规范制定
应用效果跟进
指标口径的定义和维护
负责维护数据中台的公共数据层
满足数据产品制定的数据需求
数据平台
负责研发支撑数据中台构建的产品
元数据
负责开发数据应用产品
报表系统
风控
高层看板
经营分析
中台团队的组织绩效必须与业务绑定
十三： 数据中台项目管理
项目立项
业务痛点
业务指标口径布依族
需求响应速度慢
取数效率低
数据经常违反常识
数据成本呈指数级增长
业务目标
商品部门
优化滞销商品
供应链部门
确保商品供应
仓配部门
优化物流成本，确保送达及时率
KPI
中台建设
效率
模型复用
质量
全链路监控
稽核监控
成本
低价值资产
业务支撑
项目推进
团队组织架构搭建，职责划分
数据中台团队，负责公共数据研发
角色
职责
集市DM (公共)
应用ADS（公共）
汇总数据DWS
明细数据DWD
原始数据ODS
业务部门基于中台数据，构建业务线集市层和应用层
数据分析师
集市DM（业务）
应用ADS(业务)
数据整合
指标梳理
中台数据产品经理牵头
业务数据产品经理协同
业务数据分析师协同
模型重构、整合、迁移
模型开发
研发工具产品
正交化产品设计，每个产品聚集一个应用场景
全链路打通，形成产品闭环
组件式产品架构，允许业务根据场景搭配产品使用
轻型易用、降低用户门槛，尤其注重非技术人员的交互体验
数据产品构建
商品运营系统
供应链辅助决策系统
项目成果总结
研发效率，需求交付时间从一周到两周
100% 数据产品指标口径统一
被投诉的数据质量问题下降60%
优化成本38%
滞销商品下降60%
70%订单由数据产品生成
十四： 数据产品全景图
数据研发
数据传输中心
核心功能
数据源离线和实时数据传输
使用对象
离线开发中心
基于Hive、Spark的离线数据开发平台
实时开发中心
基于Flink的一站式实时数据开发平台
数据测试中心
提供数据对比、静态代码检查的数据测试工具
提供运维大屏、全链路影响分析、任务管理（重跑、补数据）、智能报警、任务治理
流程写作中心
多角色流程协作，包括审批、通知
应用开发
资产管理员
运营
企业元数据门户，查询有哪些数据
统一管理指标的业务口径定义，消除指标业务口径不一致，形成企业的指标字典
稽核校验，全链路数据质量监控
成本优化中心
消除无用的、低价值的数据，建立数据的ROI评估体系
数仓设计中心
模型设计开发平台
基于维度建模理论
通过构建主题域、分层的方式组织数据
基于指标、维度、度量构建数据模型
数据备份与恢复
数据生命周期管理
文件管理
数据资产等级
数据安全中心
提供数据脱敏、数据加密功能
提供统一的API管理平台
基于数据中台数据一键发布API接口
提供类型丰富的中间存储
数据分析应用
自助取数工具、基于指标、维度查询数据
产品
可视化数据分析报告制作平台
网易大屏
可视化大屏
数据填报
移动端报表
复杂报表
多表头复杂式报表设计
数据门户
基于有数报表实现一站式建站，满足个性化数据门户建设
智能预警
基于报表数据的智能预警
标签应用
一站式标签管理系统
标签加工
ID-Mapping
人群圈选
一： 元数据
元数据内容
描述数据结构信息
内容
表名
注释信息
表的产出任务
每个表多少字段
这些字段分别代表什么含义
字段的类型
数据血缘
指一个表从哪些表加工而来
影响分析和故障溯源
数据特征
数据的属性信息
存储空间大小
20T
访问热度
每天100次
主题域
交易域
分层
dws
表关联指标
每日SKU粒度交易金额
业界元数据产品
Metacate
支持多种数据源
Hub 型设计
Atlas
实时数据血缘采集
网易元数据设计
关键特征
多租户支持
多数据源支持
字段血缘
血缘生命周期管理
数据标签
字段标签
多标签类型
与大数据平台集成
与Ranger结合，实现基于Tag的权限控制
与数据传输、数据治理系统集成
技术实现
运行时血缘
元数据管理模块
标签
API接口
元数据界面
多维度检索
表
列
指标
按照主题域、分层导览
表详情
基础信息
字段信息
分区信息
产出信息
二：指标管理
组成
业务口径
数据来源
计算逻辑
常见指标管理
相同指标名称，口径不一致
相同口径，指标名称不一致
不同限定词，描述相同实时过程的两个指标，相同事实部分口径不一致
指标口径描述不清楚
指标命名难于理解
指标数据来源和计算逻辑不清楚
指标规范定义
面向主题域管理
指标归属于业务线
业务线是定级目录
拆分原子指标和派生指标
指标命名规范
原子：易懂、统一
指标命名
原子指标
指标名称：动作+度量
指标标识：英文简写或汉语拼音
派生指标
指标名称：统计周期+统计粒度+修饰词（业务限定）+原子指标
指标标识：修饰词_原子指标_时间周期的方式
关联应用和可分析维度
5. 分等级管理
核心指标
数据中台直接产出的指标和原子指标为核心指标
业务方根据数据中台产出派生指标为非核心指标
管控
核心指标事实强管制原则
基于元数据，指标以标签形式，下沉到元数据对应表和字段
自动同步元数据的主题域和业务过程划分
基于指标规范化定义创建指标
照指标名称、标识、业务口径的检索
基于指标系统构建指标字典
指标开发需求
参与方
数据产品经理
指标开发流程（新表）
指标需求
产品经理、分析师
需求评审
产品经理、分析师、数据开发、应用开发
模型设计与开发
数据验证与发布上线
数据开发、产品经理、分析师
应用接入
指标开发流程（已存在表）
逻辑模型设计
数据验证与发布模型
指标梳理流程
指标治理小组
指标梳理时间计划
盘点还在使用的数据报表和数据应用
收集使用中的报表和应用的指标
指标展示名称
指标标识
分析维度
评审指标的业务口径、对相同的进行去重合并
根据业务口径明确主题域、业务过程
拆分指标类型、录入指标系统
三： 模型设计
让数据成为一种资产
评估数仓模型设计的好坏
完善度
DWD
跨层引用率：ODS 层直接被 DWS/ADS/DM 层引用的表，占所有 ODS 层表（仅统计活跃表）比例
跨层引用率越低越好
我们要求不允许出现跨层引用，ODS 层数据只能被 DWD 引用
DWS/ADS/DM
汇总数据查询比例
复用度
模型引用系数：一个模型被读取，直接产出下游模型的平均数量
模型被复用的数量
比如一张 DWD 层表被 5 张 DWS 层表引用，这张 DWD 层表的引用系数就是 5
一般低于 2 比较差，3 以上相对比较好
规范度
没有主题域、业务过程归属表的数据
不规范命名表的数量
字段命名不一致的表数量
好的数仓设计标准
数据比较丰富完善、数据复用性强、规范性强
从烟囱的小数仓到共享的数据中台
接管ODS层，控制源头
根本上防止出现重复的数据体系
数据中台团队必须明确职责，全面接管 ODS 层数据
确保数据从业务系统产生后进入数据仓库时，只能在数据中台保持一份
划分主题域，构建总线矩阵
主题域是业务过程的抽象集合
主题域划分要尽量涵盖所有业务需求，保持相对稳定性
构建一致性维度
DIM_ 主题域 _ 描述 _ 分表规则
维度统一的最大的难题在于维度属性的整合
事实表整合
ETL开发
应用迁移
数仓建模工具EasyDesign
模型设计度量
模型审核
维度、度量管理
基础字典
四： 数据质量
确保数据按时产出
准
快
数据质量问题根源
业务源系统变更
源系统数据库表结构变更
源系统环境变更
源系统日志数据格式异常
数据开发任务变更
线上代码发布上线后，引用测试库数据
代码中使用固定分区
代码逻辑处理有缺陷
任务配置异常
物理资源不足
大促期间容量规划不到位
提交差的任务影响其他任务
基础设施不稳定
底层计算、存储引擎的BUG
如何提高数据质量
添加稽核校验任务
完整性规则
一致性规则
准确性规则
建立全链路监控
通过智能预警，确保任务按时产出
通过应用重要性，区分数据等级，加快恢复速度
圈定核心任务
规范化管理制度
如何衡量数据质量
6点前数据中台任务产出完成率
基于稽核规则，计算表级别的质量分数
立即接入报警此数
数据产品SLA
质量大屏
质量分析
稽核规则
监控执行历史
五： 成本控制
省
常见成本陷进
数据上线容易，下线难
低价值得数据应用消耗了大量的资源
烟囱式的开发模式
数据倾斜
数据未设置生命周期
调度周期设置不合理
任务参数配置
数据未压缩
精细化成本管理
全局资产盘点
建立全链路数据资产视图
基于数据血缘
核算数据成本
计算资源成本
存储资源成本
核算末端数据的价值
应用层表
对接数据应用
报表展示应用
使用范围
产品粘性
面向特定场景的数据应用
目标人群覆盖率
直接业务价值产出
轻度汇总层表或是集市层
探索分析
使用频次
发现问题
持续产生成本，但是已经没有使用的末端数据
数据下线策略
产出任务停止调度
数据备份到了冷备集群
线上数据清理
成本很高，业务价值很低的末端数据
高消耗数据
治理优化
无用末端数据下线
按照应用粒度评估数据是否下线
高消耗数据优化
计算优化
数据倾斜问题诊断和解决
消峰填谷
配置参数优化
存储优化
治理效果评估
数据成本计算
数据产出任务的计算资源成本
数据存储成本
EasyCost
系统化实现
一键灰度下线
六： 数据服务
意义和价值
数据服务实现了数据模型与数据应用的全链路打通，解决了任务异常影响分析和数据下线不知道影响哪些应用的难题
数据服务解决的问题
数据接入效率低
为了保障数据的查询速度需要引入中间存储
数据量小：MySQL
数据量大： HBase
维度分析，数据量大： GreenPlum
不同的中间存储提供的API接口不同
提供统一的API接口，为开发者屏蔽不同的中间存储
数据和接口没有办法复用
中间存储中的数据无法复用
API接口跟进应用高度定制化，也无法复用
数据服务暴露的不是数据，而是接口
数据服务具备限流功能，使得不同应用共享数据成为可能
不知道数据被哪些应用访问，数据流转问题
数据和应用得链路关系是短的
数据出现问题，不知道影响了哪个应用，无法优先恢复
下线数据，不知道下游还有没有应用访问
数据服务维护了数据应用和数据中台表的链路关系，建立全链路血缘
数据部门的字段变更导致应用变更
汇总层模型根据需求不断优化是最频繁的事情
对应用开发来说，底层表变更简直是噩梦
数据服务解耦了数据应用和数据，修改数据服务的映射关系即可实现字段变更
数据服务八大产品功能设计
接口规范化定义
快递的收货码
货架前的队伍，并给队伍进行限流
认证
授权
限流
链路关系的维护
驿站记录谁取走了快递
数据交付
驿站提供快递和快递送货上面
推和拉数据交付方式
利用中间存储
提供不同类型的货架
加速数据查询
中间存储
MySQL/Oracle
数据量小
500万内
数据量大
500万以上
基于RowKey 查询
存在冷热明显特征
分布式数据库，如MyCAT
都是热数据
GreenPlum
多维分析场景
Redis
对实时要求高
一个工作人员可以取多个货架的快递
实现数据复用
逻辑模型类比数据库视图概念
动态计算而来
没有实际保持数据
API接口集市
驿站不同货架不同队伍导览
实现接口复用
API测试
工作人员上岗前的培训测试
数据服务系统架构设计
云原生
每个接口发布成为一个Service
动态服务发现
副本动态弹性创建
解决数据复用的难题
数据自动导出
七： 数据安全
备份与恢复
HDFS 快照机制
EC 存储策略冷备集群，低成本实现数据备份
基于 DistCp 实现数据的增量同步
根据数据资产等级制定备份策略
垃圾回收箱设计
原生HDFS垃圾回收机制仅针对通过CLI rm 命令，不适用于delete api
回收站一般保留24小时内的数据，超过24小时，使用备份数据恢复
精细化权限管理
OpenLDAP
统一用户管理服务
Kerberos
基于共享密钥实现的安全认证
Ranger
基于策略的细粒度权限管理
根据数据资产等级，制定权限审批流程
操作审计机制
在权限校验过程中，获取用户对表的访问记录
基于Ranger实现操作审计
开发和生产环节物理隔离
解决了什么问题
禁止数据开发使用生产数据测试
基础组件升级，使用开发测试环节承担灰度测试的功能
解决开发环境任务影响线上任务和数据，不改代码一键发布
模式一：安全隔离
优势
严格禁止开发环境使用生产环节数据测试，数据脱敏同步
劣势
效率低
适用
对数据安全要求高于效率低的企业（尤其是金融行业）
模式二：共享MetaStore
可以使用生产环节数据进行测试，效率高
存在数据安全泄露风险
效率优先，兼顾一定的数据安全
0 条评论
回复 删除
下一页
