《华为数据之道》总结
华为官方关于数字化转型的书，去年读了《华为数据之道》，今年读了本《华为数字化转型》，华为2016年开始启动的数字化转型所做的工作和目前公司做的相似度蛮高，都是非数字原生企业，华为走得更早更快更专业，就想着做个小小的总结，以借此总结下过去几年的部分工作。第一篇就从数据之道开始，这一篇会比较贴近书本，偶尔穿插些实际工作里的一些例子。
目录
一、华为数据工作建设的整体框架
1.1、数据源
1.2、数据入湖
1.3、数据主题联结
1.4、数据消费
1.5、数据治理
二、差异化的企业数据分类管理框架
2.1 基础数据（也叫参考数据）
2.1.1 定义
2.1.2 基础数据治理
2.2 主数据
2.2.1 定义
2.2.2 主数据治理
2.3 事务数据
2.3.1 定义
2.3.2 事务数据治理
2.4 观测数据
2.4.1 定义
2.4.2 观测数据治理
2.5 规则数据
2.6 报告数据
2.6.1 细分数据类型
2.7 非结构化数据
2.8 元数据
2.8.1 元数据管理架构与策略
三、面向“业务交易”的信息架构建设
3.1 信息架构（Information Architecture）的四个组件
3.1.1 数据资产目录
3.1.2 数据标准
3.1.3 数据模型
3.1.4 数据分布
3.2 基于业务对象进行设计和落地
3.2.1 按照业务对象进行架构设计
3.2.2 按照业务对象进行架构落地
四、面向“联接共享”的数据底座建设
4.1 数据底座建设框架
4.2 数据湖
4.2.1 结构数据入湖流程
4.2.2 非机构化数据入湖流程
4.3 数据主题联接
4.3.1 多维模型
4.3.2 图模型设计
4.3.3 智能标签
4.3.4 指标数据
4.3.5 算法模型
五、数据服务
一、华为数据工作建设的整体框架
自底向上，分别有五大部分：
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）转运营
以上主要是介绍数据底座部分，接下来会重点介绍面向业务数据消费的数据服务建设。下面以思维导图的方式来介绍。
五、数据服务
