华为官方关于数字化转型的书,去年读了《华为数据之道》,今年读了本《华为数字化转型》,华为2016年开始启动的数字化转型所做的工作和目前公司做的相似度蛮高,都是非数字原生企业,华为走得更早更快更专业,就想着做个小小的总结,以借此总结下过去几年的部分工作。第一篇就从数据之道开始,这一篇会比较贴近书本,偶尔穿插些实际工作里的一些例子。
目录
目录
3.1 信息架构(Information Architecture)的四个组件
一、华为数据工作建设的整体框架
自底向上,分别有五大部分:
1.1、数据源
通过业务对象、规则和过程数字化,不断提升数据质量,建立清洁、可靠的数据源。清洁、可靠的数据源是卓越运营的前提,华为数据治理经历了两个阶段,数据清洁与贯通、数据分析与洞察,实际场景里其实是两个阶段并行的,只是每个阶段工作重心不同。
1.2、数据入湖
基于“统筹推动、以用促进”的建设策略,严格按照六项标准,通过物理与虚拟入湖两种方式汇聚内外部数据。
1.3、数据主题联结
通过五种数据联结方式,规划和需求双驱动,建立数据主题联结,并通过服务支撑数据消费。这五种方式也是常见的对外提供服务的方式,标签、固定报表、算法模型、数据集。
1.4、数据消费
通过数据分析平台满足数据消费需求。
1.5、数据治理
建立统一的数据治理能力,包括数据体系、数据分类、数据质量、安全与隐私等。
以上主要是介绍数据工作框架,第二部分介绍企业数据分类管理的框架。
-----------------------------------------------------我是分割线------------------------------------------------------------
二、差异化的企业数据分类管理框架
按照数据主权所属公司内部/外部分为外部数据和内部数据,外部数据主要是指公司通过公共领域获取的数据,如国家、币种、汇率等。
按照存储特性分为结构化数据和非结构化数据(文档、图片、视频等)。
2.1 基础数据(也叫参考数据)
2.1.1 定义
用于分类或目录整编的数据,通常有一个有限的允许、可选值范围。也就是常见的基础码值。如性别、币种、业务单类型等。
2.1.2 基础数据治理
基础数据治理无论对优化业务流程还是数据分析都有较高的价值。一方面是增强与外部系统、提高业务敏捷度;另一方面,减少mapping的开发,支持业务端到端分析,增加业务确定性。码值管理最好通过系统来管控,目前的工作里也遇到这类问题,因为老系统之前较为混乱,新建系统建了一套全新的,但当时相关标准管理系统不完善,且在新老mapping上并不完善,导致数据部门很难开展工作。
2.2 主数据
2.2.1 定义
具有高业务价值的、可以在企业内跨流程跨系统被重复使用的数据,具有唯一、准确、权威的数据源。通常是业务事件的参与方,参与方在业务中是一个很重要的概念。常见的主数据有机构主数据、员工主数据、产品主数据、财务主数据等。
与基础数据的异同:两者具有一定的相似性,都是在业务业务事件发生前预先定义的;但主数据不受限于预先定义的数据范围,而且主数据记录的增加一般不会影响流程和IT系统的变化。如客户主数据,系统中增加一条客户记录,并不影响现有的流程和系统;但如果客户类型从之前的01个人、02法人变成01个人、02法人和03国王,在没有良好管控的情况下,下游的系统就不知道03是什么意思了。
2.2.2 主数据治理
华为的主数据范围包含客户、产品、供应商、组织和人员。每个主数据都有相应的架构、流程及管控组织来负责管理。目前的工作里也各自新建域来管理相应的主数据,但缺少良好的流程和管控,产品功能存在但实际转起来时没有那么顺畅,需要不断打磨。最后的目的是保证数出一孔,提高数据质量、支持交易流打通等。
2.3 事务数据
2.3.1 定义
用于记录企业经营过程中产生的业务事件,其实质是主数据之间活动产生的数据。如一条xx订单数据。
2.3.2 事务数据治理
事务数据会调用主数据和基础数据,当然也有自身的数据。如一张订单上,一般有客户、产品、机构主数据,币种、订单类型等基础数据,也有订单金额、订单号等事务数据。因此,事务数据治理的重点是管理好事务数据对主数据和基础数据的调用,以及事务数据之间的关联关系,确保上下游传递顺畅,数仓中间层建模时就是事实表表来源。
2.4 观测数据
2.4.1 定义
观测者通过观测工具获取观测对象行为/过程的记录数据。如系统日志、物联网数据、GPS数据等。
2.4.2 观测数据治理
观测对象主要是人、事、物和环境,观测对象要定义成业务对象进行管理。观测方式分为软感知(使用软件或各种技术进行数据收集,比如某log日志)和硬感知(收集对象为物理世界中物理实体,如IOT数据)。
2.5 规则数据
结构化描述业务规则变量(一般为决策表、关联关系表、评分卡等形式)的数据,是实现业务规则的核心数据。无法实例化,只能以逻辑实体存在。如某下单流程中的定价规则,风控规则等。业务规则/规则变量->规则数据,一个业务规则可以包含0-N个规则数据。
2.6 报告数据
对数据进行处理加工后,用作业务决策依据的数据。主要是指维度、指标。
2.6.1 细分数据类型
(1)事实表
从业务活动或事件中提炼出来的性能度量,每个事实表由颗粒度属性+维度属性+事务描述属性+度量属性组成,又可分为基于明细构建的事实表和基于明细做过汇聚的事实表。(如事务型事实表和,某日周期快照)。
(2)维度
用于观察和分析业务数据的视角,支持对数据的汇聚、钻取和切片分析。数据来源主要为基础数据和主数据。(比如基础数据,处理方式以退化维度为主)
(3)统计型函数
(4)趋势型函数
(5)报告规则数据
(6)序列关系数据
2.7 非结构化数据
以上2.1-2.6介绍了结构化数据,下面介绍非结构化数据,非结构数据的元数据分为基础特征类(客观,如标题、格式、Owner等)和内容增量类(如标签、关系等)。
2.8 元数据
定义数据的数据,是有关一个企业所使用的物理数据、技术和业务流程、数据规则和约束以及数据的物理与逻辑结构的信息。属于描述性标签,描述了数据、相关概念以及他们之间的关系,如业务术语、指标定义、表/字段描述等。
2.8.1 元数据管理架构与策略
(1)产生元数据
这里解释下数据标准,比如行业术语(如订单-order)、数据类型规范(金额类用decimal(18,6))等。
(2)采集元数据
从数据源写入源数据中心即可。
(3)注册元数据
元数据注册有4种模式,一对一模式(逻辑实体和物理表一对一)、主从模式(一对多,逻辑实体对应多张物理表)、主扩模式(一对多主物理表为核心表,少数属性存在其他物理表中)和父子模式(多个逻辑实体业务属性完全相同,按照不同场景区分逻辑实体,但落在同一物理表中)。
(4)运维元数据
略。
以上主要是介绍企业数据分类管理的框架,第三部分会从信息架构角度出发,介绍业务过程数字化的思路和原则。
-----------------------------------------------------我是分割线------------------------------------------------------------
三、面向“业务交易”的信息架构建设
首先需要强调一个理念,信息架构的价值并不应局限于“支撑IT建设落地(模块功能)”,而是更好地管理企业数据资产,更好地提升整个业务交易链条的效率,甚至基于信息架构重新审视业务边界的划分和整合。
3.1 信息架构(Information Architecture)的四个组件
信息架构的目的是定义好整个运作过程中涉及的各种人、事、物资源,并实施有效的治理,从而确保业务单元间高效、准确地传递,上下游快速执行和运作。
3.1.1 数据资产目录
这里的主题域与数仓的主题概念不同,更多是业务领域划分。这里的业务对象是信息架构的核心层,用于定义业务领域重要的人、事、物,架构建设和治理主要围绕业务对象展开。
3.1.2 数据标准
每个数据标准应该覆盖三个方面,分别是业务视角(统一业务侧语言,明确定义、用途、业务规则、同义词,并对名称进行统一定义,避免重复)、技术视角(对IT实施形成必要的指引和约束,包括数据类型、长度)和管理视角(明确各业务部门在观测标准中应该承担的责任)。
3.1.3 数据模型
从数据视角对现实世界特征的模拟和抽象,根据业务需求抽取信息的主要特征,反映业务信息对象之间的关联关系。
3.1.4 数据分布
核心是数据源,指业务上首次正式发布某项数据的应用系统,并通过数据管理专业组织认证,作为企业范围内唯一数据源头被周边系统调用,如常见的ECIF系统,作为客户主数据唯一数据源被周边系统调用。
3.2 基于业务对象进行设计和落地
3.2.1 按照业务对象进行架构设计
核心是判定哪些是业务对象,不同角色(架构、业务、数据owner)对业务对象的判定可能存在理解的差异。建议以以下4条原则来判定:
(1)通常一个业务对象会有对应的管理流程和管理组织,以及支持运作的IT系统,如客户,就有对应的客户管理部门。
(2)业务对应有一个唯一的身份标识信息,如对于员工,有员工工号做唯一识别。
(3)业务对象可以独立存在,业务对象中间可以有关联、依赖关系,但不能包含或从属,如客户这个业务对象中客户类型、客户姓名,无法独立存在,既无法独立存在又无法实例化。
(4)业务对象可以实例化。
3.2.2 按照业务对象进行架构落地
数据模型分层:概念模型-逻辑模型-物理模型。要确保在落地时不变形,要控制好2个关键点,概念到逻辑模型的一致性主要通过逻辑模型实体的设计管理来实现;逻辑模型与物理模型的一致性通过一体化建模管理实现。
(1)逻辑数据实体设计
主要通过逻辑数据模型指导IT系统层面的数据设计,在设计逻辑数据实体时主要参考如下几个原则:
a)业务对象:逻辑数据实体=1:N,逻辑数据实体不能脱离业务对象独立存在。
b)描述业务对象不同业务特征的密切相关的一组属性集合,可以设计为一个逻辑数据实体。
c)遵守第三范式。
d)提供数据服务或跨业务领域使用的基础数据,要单独设计成逻辑数据实体。
e)两个业务对象的关系也可以设计成关系型逻辑数据实体。
(2)一体化建模管理
从模型设计、发布到日常运营,对模型做全生命周期的融合管理。
最后,在传统信息架构的基础上,提出了面向数字化转型的扩展,对象数字化、过程数字化和规则数字化。
以上主要是介绍企业信息架构部分,第四部分会从数仓出发,介绍数据底座的建设。
-----------------------------------------------------我是分割线------------------------------------------------------------
四、面向“联接共享”的数据底座建设
4.1 数据底座建设框架
数据底座由数据湖和数据主题联接两层组成,将公司内外部的数据汇聚到一起,并对数据进行重新饿组织和联接,为业务可视化、分析、决策等提供数据服务。
底座资产建设遵守四项原则:数据安全原则、需求/规划双轮驱动原则、数据供应多场景原则和信息架构遵从原则(遵从公司的信息架构)。
4.2 数据湖
这里区分下物理入湖和虚拟入湖:
(1)物理入湖是指将原始数据复制到数据湖中,主要有批量集成、数据复制同步(实时,CDC)、消息集成(实时,API提取数据,MQ工具)和流集成(实时,Pipline工具)。
(2)虚拟入湖是指原始数据不在数据湖中进行物理存储,而是通过建立虚拟表的集成方式实现入湖,实时性强,一般面向小数据量应用,数据量过大可能影响源系统。主要是面向需要低数据低时延、高灵活性和临时模式(不断消费下的模式)的消费场景。如Denodo中的逻辑数据架构,支持数据虚拟化。
4.2.1 结构数据入湖流程
4.2.2 非机构化数据入湖流程
以上概念上前面以介绍了,就不重复了。
4.3 数据主题联接
在数据湖的基础上,通过建立数据联接层,基于不同的分析场景,通过5种方式将跨域的数据联接起来,支撑不同的数据消费需求,下面重点对这5种方式作讲解。
4.3.1 多维模型
多维模型是依据明确的业务关系,建立基于维度、事实表以及相互间连接关系的模型,实现多角度、多层次的数据查询和分析。设计出稳定、易扩展、高可用的数据模型来支撑消费的4个步骤:
(1)确定业务场景
分析业务需求,识别需求中所涉及的业务流及其对应的逻辑数据实体和关联关系。
(2)声明粒度
不同粒度对应不同的事实表
(3)维度设计
维度由层次结构(关系)、层次、成员、属性组成,维度可以分为基础树(提供统一定义、完整的层次结构和成员)和组合树(根据业务使用场景定制)。
维度设计需要满足单一性(一个维度有且仅有一个视角,同一维度不能穿插其他分析视角,比如产品维不含渠道)、单向性(上大下小,维度只能支撑自上而下的分解和自下而上的收敛,不能同时具备向上和向下两个方向,比如机构维度,一级-二级-三级-国家,这是不行的)和正交性(成员两两不相交,同一成员不能同时有多个上级成员)。
(4)事实表设计
事实表由粒度属性(事实表主键)、维度属性、事实属性和其他描述属性组成。
一些原则:
同一事实表不能存在多种不同粒度的事实;尽可能包含所有与业务过程相关的事实,不包含与业务过程无关的事实;对于不可加的事实需要分解为可加的(比如比率分解为分子和分母);事实的数值单位要保持一致;另外还有一些创建人、创建时间、最后修改人、最后修改时间等审计字段。
4.3.2 图模型设计
图模型由节点和边组成,节点表示实体或概念,边则由属性或关系构成。
实体:具有可区别性且独立存在某种事物,比如一个叫小王的年轻人。
概念:对特征的组合而形成的知识单元,主要是指集合、类别、对象类型、事物种类,如哲学家。
属性:实体或概念的特征或特性,比如小王的生日。
图模型构建包含的几个关键步骤:
(1)业务场景定义
业务场景决定信息涵盖范围,以及信息颗粒度的表示,信息颗粒度的原则是“能满足业务应用的最粗颗粒度”。
(2)信息收集
信息选取需要考虑与应用场景直接相关的信息;与应用场景间接相关的但可辅助理解问题的信息。
(3)图建模
相同的数据可以有若干模式的定义,良好的模式可以减少数据冗余,提高实体识别准确率。
(4)实体、概念、属性、关系的标注
企业图模型涉及的实体和概念分为3类,公共类(如人名、机构名等)、企业类(业务术语、企业部门等)和行业类(如金融行业等)。
(5)实体和概念的识别
可以在业务输入的基础上,用NER扩展出新实体的概念,经业务确认后列入实体、概念库。
(6)属性识别和关系识别
一般建议用混合存储方式存储数据,用图数据库存储关系、关系型数据库或键值对存储属性。偏重逻辑推理的应用场景用RDF方式存储,偏重图计算的选择属性图的存储方式。
(7)图挖掘计算
a)图遍历:直接查询遍历图
b)经典算法:比如最短路径
c)路径的探寻:给定两个或多个实体,去发现它们的关系
d)权威节点的分析:常用于社交网路
e)族群分析
f)相似节点的发现
4.3.3 智能标签
标签是根据业务场景的需求,通过对目标对象运用抽象、归纳、推理等算法得到的高度精炼的特征标识,用于差异化管理与决策。标签由标签和标签值组成,打在目标对象上。
标签管理分为标签体系建设与打标签。
(1)标签体系建设
选定目标对象-设计标签层级-详细的标签和标签值设计(包含标签定义、适用范围、标签的生成逻辑等)。
(2)打标签
建立标签值和实例数据的关系。
4.3.4 指标数据
指标=指标名称+指标数值。指标名称及其含义体现了指标在质的规定性和量的规定性;指标数值反映了指标在具体时间、地点和条件下的数量表现。
原子指标+指标叠加公式=指标复合。
实操中根据指标拆解文档来把指标拆为原子指标、维度、业务限定、时间修饰词,再去在step4中落地对应的物理表,支持用户自主实现指标计算,拉通指标设计和落地。
4.3.5 算法模型
算法模型的设计步骤主要分为4步,具体的:
(1)需求评估
(a)业务驱动的分析需求识别
(b)数据驱动的分析需求识别
(c)价值与可行性评估
(2)数据准备
(3)方案设计
(a)明确要分析的业务目标与相关假设。
(b)定义数据集中的分析目标、样本与筛选条件。
(c)设计所需变量、指标、可能的分析方法与产出。
(d)规划分析的应用场景。
(4)建模与验证
(a)决定是否需要分析建模
结合技术复杂度、业务效益和资源来评估是否需要分析建模。不需要的话转BI分析。
(b)建模与验证
(c)试算分析
(d)编写数据分析线下验证报告
(e)决定是否需要IT开发
(f)模型线上验证
(g)转运营
以上主要是介绍数据底座部分,接下来会重点介绍面向业务数据消费的数据服务建设。下面以思维导图的方式来介绍。
五、数据服务
六、数据质量综合管理