导图社区 华为数据之道
- 304
- 2
- 0
- 举报
华为数据之道
华为数据之道学习整理，包含数据治理和数字化转型、企业政策与框架协同等内容，可以对其对数据的理解有一个整体认知和参考。
编辑于2023-11-05 09:03:37- 数字化转型
- 数据治理
- 企业政策
- 华为数据之道
- 相似推荐
- 大纲
华为数据之道
本书框架
数据治理和数字化转型
挑战
目标
愿景
蓝图
框架
企业政策与架构协同
企业级数据综合治理体系
数据与变革、运营、IT之间的协同关系
数据责任管理主体在业务
不同数据的管理方式和要点
重点任务
信息架构
数据底座
数据服务
关键能力
全量感知
综合质量提升
可控共享
未来思考
AI治理
数据主权
数据生态
企业级数据治理体系
每个数据负责制
必须由对应业务部门承担管理责任
必须有唯一的数据Owner
数据管理总纲
原则
信息架构管理原则
数据产生管理原则
数据应用管理原则
数据问责与奖惩管理原则
政策
信息架构管理政策
管理信息架构的角色与职责
信息架构建设要求
信息架构遵从管控
数据源管理政策 【数据同源是治理的核心观点】
数据源管理原则
数据源认证标准
数据质量管理政策 【质量持续提升是治理的核心目标】
数据质量管理职责及要求
数据质量管理的业务规则和管理要求
融入变革、运营和IT
建立数据管理流程
定位
L1：MBT&IT
L2：管理数据
L3：管理信息架构
L3：管理数据质量
L3：管理数据分析
关键角色
信息架构工程师
数据治理工程师
数据平台工程师
数据分析师
数据科学家
共同完成数据解决方案在管理变革、管理质量及运营的交付和验证
变革体系与运营体系共同进行数据治理决策
数据治理融入IT实施
通过内控体系赋能数据治理
公司级管理组织
任命数据Owner和数据管家
公司数Owner
制定数据管理体系的愿景和路标
传播数据管理理念，营造数据文化氛围
建设和优化数据管理体系，包括组织与任命、授权与问责等
批准公司数据管理的政策与法规
裁决跨领域的数据及管理争议，解决跨领域的重大数据及管理问题
领域数据Owner
负责数据管理体系建设
负责信息架构建设
负责数据质量管理
负责数据底座和数据服务建设
负责数据争议裁决
数据管家
数据Owner的助手，具体工作的执行者
双轮组织
公司数据管理部
公司数Owner
领域数据Owner
质量与流程IT管理部
质量运营部/XX管理部
XX数据管理部
XX数据管理部
XX数据管理部
跨领域数据联合战团队
数据质量执行组
信息架构建设组
数据服务推进组
数据分析工作组
数据底座工作组
元数据工作组
数据管理组织定位
体系建设者
能力中心
业务的数据伙伴
文化倡导者
数据工作框架
数据源
数据湖
数据主题联接
数据消费
数据治理
数据分类管理框架
分类框架【数据特性】
描述手段
元数据【Meta-data】
数据权属
外部数据【External Data】
内部数据【Internal Data】
存储特性
结构化数据【Structured Data】
基础数据【Reference Data】
主数据【Master Data】
事务数据【Transactional Data】
观测数据【Observational Data】
规则数据【Conditional Data】
报告数据【Report Data】
非结构化数据【Unstructured Data】
结构化数据管理【统一语言】
外部数据【External Data】
分类定义
定义：通过公共领域获取的数据
特征：客观存在，其产生、修改不受公司的影响
举例：国家、货币、汇率
数据治理
合规优先
责任明确
有效流动
可审计、可溯源
受控审批
内部数据【Internal Data】
分类定义
定义：企业内经营产生的数据
特征：在企业的业务流程中产生或在业务管理规定中定义，受企业经营营销
举例：合同、项目、组织
结构化数据【Structured Data】
分类定义
定义：可以存储在关系数据库里，用二维表结构来表达实现的数据
特征：可以用关系数据库存储；先有数据结构，在产生啥数据
举例：国家、币种、组织、产品、客户
非结构化数据【Unstructured Data】
分类定义
定义：形式相对不固定，不方便使用数据库二维逻辑来表现的数据
特征：形式多样，无法用关系数据库存储；数据量通常较大
举例：网页、图片、视频、音频、XML
数据治理
对其基本特征和内容进行提取，并通过元数据开展落地
基础数据【Reference Data】
分类定义
定义：用结构化的语言描述属性，用于分类或目录整编的数据，也称作参考数据
特征：通常由一个有限的允许/可选值范围；静态数据，非常稳定，可以用作业务/IT的开关、职责/权限的划分或统计报告的维度
举例：合同类型、职位、国家、币种
数据治理
重点在于变更管理和统一标准管控
主数据【Master Data】
分类定义
定义：具有高业务价值的、可以在企业内跨流程跨系统被重复使用的数据，具有唯一、准确、权威的数据源
特征：通常是业务事件的参与方，可以在企业内跨流程、跨系统重复调用；取值不受限于预先定义的数据范围；在业务事件发生之前就客观存在，比较稳定；主数据的补充描述可归入主数据范畴
举例：实体型组织、客户、人员基础配置
数据治理
重点是确保同源多用和重点进行数据内容的校验
事务数据【Transactional Data】
分类定义
定义：用于记录企业经营过程中产生的业务事件，其实质是主数据之间活动产生的数据
特征：有较强的时效性，通常是一次性的；事务数据无法脱离主数据独立存在
举例：BOQ、支付指令、主生产计划
数据治理
重点做好对主数据和基础数据的调用及事务数据之间的关联关系
观测数据【Observational Data】
分类定义
定义：观测者通过观测工具获取观测对象行为/过程的记录
特征：通常数据量较大；数据是过程性的，主要作用监控分析；可以由机器自动采集
举例：系统日志、物联网数据、运输过程中产生的GPS数据
数据治理
要定义成业务对象进行管理是治理的先决条件
规则数据【Conditional Data】
分类定义
定义：结构化描述业务规则变量（一般为决策表、关联关系表、评分卡等形式）的数据，是实现业务规则的核心数据
特征：规则数据不可实例化，只以逻辑实体形式存在；规则数据的结构在纵向和横向两个维度上相对稳定，变化形式多为内容刷新；规则数据的变更对业务活动的影响是大范围的
举例：员工报销遵从性评分规则、出差补助规则
数据治理
目标是实现规则的可配置、可视化、可追溯
根据轻量化、分级的特点进行不同的方式管理
业务规则要有流程中的业务活动相关联，是业务活动的指导和依据
包括规则变量和变量之间的关系
必须有唯一的数据Owner负责
其元数据要记录与业务规则的关系
报告数据【Report Data】
分类定义
定义：指对数据进行处理加工后，用作业决策依据的数据
特征：通常需要对数据进行加工处理；通常需要将不同来源的数据进行清晰、转换、整合，以便更好底进行分析；维度、指标值都可归入报告数据
举例：收入、成本
数据治理
在应用相关数据的基础上，重点进行细分数据类型进行说明
元数据【Meta-data】
分类定义
定义：定义数据的数据，是有关一个企业所有使用的物理数据、技术和业务流程、数据规则和约束以及数据的物理与逻辑结构的信息
特征：是描述性标签，描述了数据（如数据库、数据元素、数据模型）、相关概念（如业务流程、应用系统、软件代码、技术架构）以及它们之间的联系（关系）
举例：数据标准、业务术语、指标定义
数据治理
目标与使命：入湖有依据，出湖可索引
面向“业务交易”的信息架构建设
企业运营过程
管理好人和物等“资源”
管理好各类资源直接的联系，即各类业务交易“事件”
对各类事件执行效果进行“整体描述和评估“，最终实现组织目标和价值
信息架构（Information Architecture）
目的
定义好整个运作过程中涉及的各种人、事、物资源，并实施有效的治理，从而确保各类数据在企业各业务单元间高效、准确地传递，上下游流程快速地执行和运作。
四大组件
数据资产目录
要点
通过分层架构表达
对数据的分类和定义
厘清数据资产
建立数据模型的输入
分层
L1主题分组
基于数据自身特征边界
基于业务管理边界
L2主题域
相互不重叠的数据分类
通常一个主题域有相同的数据Owner
L3业务对象
信息架构核心层
定义业务领域的重要人、事、物
架构建设和治理主要围绕业务对象开展
企业架构EA范畴内，信息架构（IA）通过业务对象实现与业务架构（BA）、应用架构（AA）、技术架构（TA）架构集成
L4数据逻辑实体
描述一个业务对象在某方面特征的一组属性集合
L5属性
信息架构的最小颗粒
客观描述业务对象在某方面的性质和特征
数据标准
要点
业务定义的规范
统一语言，消除歧义
为数据资产梳理提供标准的业务含义和规则
要求
业务视角要求
技术视角要求
管理视角要求
企业级数据模型
要点
通过E-R建模实现对数据关系的描述
指导IT开发，是应用系统实现的基础
关联关系
比较真实底模拟业务（场景）
对重要业务模式和规则的固化
数据分布
要点
数据在业务流程和IT系统上流动的全景视图
识别数据的“来龙去脉”
定位数据问题的导航
核心
数据源
认证数据源
原则
建立企业层面共同的行为准则
具体原则
原则一：数据按对象管理，明确数据Owner
原则二：从企业视角定义信息架构
原则三：遵从公司的数据分类管理框架
原则四：业务对象结构化、数字化
原则五：数据服务化，同源共享
核心要素
基于业务对象进行设计和落地
按业务对象进行架构设计
原则一：业务对象是指企业运作和管理中不可缺少的重要人、事、物
原则二：业务对象有唯一身份标识信息
原则三：业务对象相对独立并有属性描述
原则四：业务对象可实例化
按业务对象进行架构落地
数据模型
概念模型
逻辑模型
物理模型
控制关键点
逻辑数据实体设计
控制概念模型与逻辑模型的一致性
规则
1.业务对象与逻辑实体的关系是一对一或一对多，不允许多对一的情况
2.描述业务对象不同业务特征的密切相关的一组属性集合，可以设计为一个逻辑数据实体
3.逻辑实体设计要遵循第三范式
4.提供数据服务或跨业务领域使用的基础数据，要单独设计逻辑实体
5.两个业务对象间的关系也可以设计关系类型的逻辑数据实体，在数据资产目录中，可按业务发生的时间先后顺序，归属于后出现的业务对象
一体化建模管理
逻辑模型与物理模型的一致性
控制点
1.产品逻辑模型和物理模型的一体化设计，元数据管理和数据模型管理融合
2.构建数据标准池，实体属性只能从数据标准池选择
3.产品元数据和数据库自动比对和验证
4.产品元数据发布认证和信息资产打通
5.基于交易侧产品元数据的自助入湖
面向业务数字化扩展
传统信息架构的挑战
1.大量业务和作业所产生的数据并有完整地被管理
2.大量业务过程么有形成可视、可管理的数据
3.大量业务规则缺乏管理、无法灵活使用
扩展方法
对象数字化
目标是建立对象本体在数字世界的映射
不是基于流动要求的少量数据的管理，而是管理某个对象的全量数据
过程数字化
不干预业务活动，并能自动记录
业务线上化，并记录执行或操作轨迹
规则数字化
把复杂场景下的复杂规则用数字化手段进行管理
规则
定义类规则
行为类规则
面向“联接共享”的数据底座建设
建设框架
1.统一管理结构化、非结构化数据
2.打通数据供应通道
3.确保公司数据完整、一致、共享
4.保障数据安全可控
建设策略
1.数据安全原则
2.需求、规划双轮驱动原则
3.数据供应多场景原则
4.信息架构遵从原则
数据湖
实现企业数据的“逻辑汇集”
特点
1.逻辑统一
2.类型多样
3.原始记录
入湖
六标准
1.明确数据Owner
2.发布数据标准
3.认证数据源
4.定义数据密级
5.数据质量评估
6.元数据注册
方式
技术手段
批量集成
数据复制同步
消息集成
流集成
数据虚拟化
分析表
方式
拉和推两种方式
数据类型
结构化
1.需求分析及管理
2.符合度评估
检查数据源准备度
评估入湖标准
3.实施入湖
4.注册元数据
非结构化
管理范围
文件本身
文件属性
参考标准
都柏林核心元数据 Dublin Core™ Metadata Initiative (DCMI)
1.基本特征元数据
2.文件解析内容
3.文件关系
4.原始文件
数据主题联接
将数据转换为“信息”
5类联接应用场景
多维模型
面向业务的多视角、多维度分析
步骤
1.确定业务场景
2.声明粒度
3.维度设计
单一性
单向性
正交性
4.事实表设计
事实属性是对对应粒度事实进行定量的属性，一般事实表包括一个或多个事实字段
同一事实表中不能存在多种不同粒度的事实
尽可能包含所有与业务过程相关的事实，不包含无关事实
对于不可相加的事实，需要分解为可加的事实
事实的数值单位要保持一致
图模型
面向数据间关联影响分析，帮助业务快速定位关联影响
步骤
1.业务场景定义
2.信息收集
3.图建模
4.实体、概念、属性、关系的标注
5.实体和概念的识别
5.属性识别与关系识别
标签
对特定业务范围的圈定
分类
事实标签
源于实体属性
客观和静态
规则标签
对数据加工处理产生
相对客观和静态
模型标签
属性结合算法生成
主观和动态
步骤
1.标签体系建设
2.打标签
数据存储结构
实现方法
事实标签
标签值和属性允许值
系统自动
规则标签
设计打标签逻辑
系统自动
模型标签
设计打标签算法模型
系统自动
指标
对业务结果、效率和质量的度量
分类
原子指标
复合指标
步骤
1.指标拆解需求澄清
2.指标拆解设计
基于指标叠加公式拆解指标
基于指标拆解结果，识别指标数据
3.指标与数据资产匹配
算法
面向智能分析的场景，提供支撑业务判断和决策的高级分析方法
步骤
1.需求评估
业务驱动的分析需求识别
数据驱动的分析需求识别
价值与可行性评估
2.数据准备
3.方案设计
4.建模与验证
决定是否需要分析建模
建模与验证
试算分析
编写数据分析线下验证报告
决定是否需要IT开发
模型线上验证
转运营
面向“自助消费”的数据服务建设
自助、高效、复用
数据搬家挑战
成本
一致性
数据共享模式发展趋势
参考美国智慧社区信息共享战略
定义
数据分发、发布的框架
服务产品
满足需求
符合标准
兼顾共享和安全
建设策略
1.明确数据服务化方法
2.制定数据服务管理规范和流程
3.构建数据服务中心
统一标准
1.满足可重用、减少数据“搬家”
2.明确服务使用用户，针对性设计并定义SLA
3.应用和应用间都必须使用服务接口交互
4.在统一的平台注册和发布
5.不同场景选择合适的服务化架构粒度
生命周期管理
第1阶段：服务识别与定义
1.分析数据服务需求
2.识别可重用性
3.判读准入条件
4.制定迭代计划
第2阶段：服务设计与实现
设计
服务契约
基本信息
提供方
服务类型
能力要求
时效性
处理逻辑
安全策略
SLA
数据契约
描述
输入和输出参数
业务数据资产编码
物理落地资产编码
服务划分颗粒度
原则
业务特性
消费特性
管理特性
能力特性
参考规范
同一种提供形式下，一个数据只能设计在一个数据服务中
按主题（业务对象）将相同维度的数据设计为一个数据服务
将同一个逻辑实体的数据设计为一个数据服务
将单一功能的算法、应用模型设计为一个服务
交付
需求接收和管理
构建自助式开发平台
代码自动审查
数据自动验证
功能自动测试
服务部署
服务分类建设
数据集成服务
定义
提供完整数据集访问
消费方自决定处理逻辑
规范
数据湖
业务对象
数据资产
关联主数据
主题联接
主题
数据资产
数据API服务
定义
面向某个IT系统提供数据事件驱动的“响应”
特征
提供方基于随机的数据事件主动底传送数据
提供方会基于事件定义数据处理逻辑，有消费方提前订阅并随机触发
服务的生命周期跟着事件走，事件结束，服务终止
对比集成服务优势
供应/消费数据服务
高聚合
松耦合
数据供应三个一
1天
1周
1个月
第3阶段：服务运营
知识自主化
数据地图
自主分析能力
结果管理到过程管理
打造“数字孪生”的数据感知能框架
能力架构
硬感知
软感知
打造“清洁数据”的质量综合管理能力
PDCA质量综合管理框架
ISO 8000 Data Quality and Enterprise Master Data
SY/T 7005-2014 数据质量控制与评估原则
业务异常数据监控
度量与改进
打造“安全合规”的数据可控共享能力
元数据
授权与权限