数据之道读书笔记-05面向“联接共享”的数据底座建设

在从信息化向数字化转型的过程中，企业积累了海量的数据，并且还在爆发式地增长。数据很多，但真正能产生价值的数据却很少。数据普遍存在分散、不拉通的问题，缺乏统一的定义和架构，找到想要的、能用的数据越来越难。

本章将讲述华为数据底座的总体架构和建设策略，详细说明华为如何通过数据湖和数据主题联接的建设，实现数据的汇聚和联接，打破数据孤岛和垄断，重建数据获取方式和次序。数据底座在华为数字化转型中起着关键作用。

---

5.1 支撑非数字原生企业数字化转型的数据底座建设框架

华为通过建设数据底座，将公司内外部的数据汇聚在一起，对数据进行重新组织和联接，让数据有清晰的定义和统一的结构，并在尊重数据安全与隐私的前提下，让数据更易获取，最终打破数据孤岛和垄断。通过数据底座，主要可以实现如下目标。

1）统一管理结构化、非结构化数据。将数据视为资产，能够追溯数据的产生者、业务源头以及数据的需求方和消费者等。

2）打通数据供应通道，为数据消费提供丰富的数据原材料、半成品以及成品，满足公司自助分析、数字化运营等不同场景的数据消费需求。

3）确保公司数据完整、一致、共享。监控数据全链路下的各个环节的数据情况，从底层数据存储的角度，诊断数据冗余、重复以及“僵尸”问题，降低数据维护和使用成本。

4）保障数据安全可控。基于数据安全管理策略，利用数据权限控制，通过数据服务封装等技术手段，实现对涉密数据和隐私数据的合法、合规地消费

5.1.1 数据底座的总体架构

华为数据底座由数据湖、数据主题联接两层组成，将公司内外部的数据汇聚到一起，并对数据进行重新的组织和联接，为业务可视化、分析、决策等提供数据服务，如图5-1所示。

数据湖是逻辑上各种原始数据的集合，除了“原始”这一特征外，还具有“海量”和“多样”（包含结构化、非结构化数据）的特征。数据湖保留数据的原格式，原则上不对数据进行清洗、加工，但对于数据资产多源异构的场景需要整合处理，并进行数据资产注册。

数据入湖必须要遵循6项标准，共同满足数据联接和用户数据消费需求。

数据主题联接是对数据湖的数据按业务流/事件、对象/主体进行联接和规则计算等处理，形成面向数据消费的主题数据，具有多角度、多层次、多粒度等特征，支撑业务分析、决策与执行。基于不同的数据消费诉求，主要有多维模型、图模型、指标、标签、算法模型5种数据联接方式。

5.1.2 数据底座的建设策略

数据底座建设不能一蹴而就，要从业务出发，因势利导，持续进行。具体来说，华为数据底座采取“统筹推动、以用促建、急用先行”的建设策略，根据公司数字化运营的需要，由公司数据管理部统一规划，各领域分别建设，以满足本领域和跨领域的数据需求。其中，数据Owner是各领域数据底座建设的第一责任人，各领域数据部负责执行。数据底座资产建设遵从下面四项原则。

1）数据安全原则
数据底座数据资产应遵循用户权限、数据密级、隐私级别等管理要求，以确保数据在存储、传输、消费等全过程中的数据安全。技术手段包括但不限于授权管理、权限控制、数据加密、数据脱敏。
2）需求、规划双轮驱动原则
数据底座数据资产基于业务规划和需求触发双驱动的原则进行建设，对核心数据资产优先建设。
3）数据供应多场景原则
数据底座资产供应需根据业务需求提供离线/实时、物理/虚拟等不同的数据供应通道，满足不同的数据消费场景。
4）信息架构遵从原则
数据底座数据资产应遵从公司的信息架构，必须经IA-SAG（信息架构专家组）发布并完成注册

5.2 数据湖：实现企业数据的“逻辑汇聚”

5.2.1 华为数据湖的3个特点

华为数据湖（如图5-2所示）是逻辑上对内外部的结构化、非结构化的原始数据的逻辑汇聚。数据入湖要遵从6项入湖标准，基于6项标准保证入湖的质量，同时面向不同的消费场景提供两种入湖方式，满足数据消费的要求。经过近两年的数据湖建设，目前已经完成1.2万个逻辑数据实体、28万个业务属性的入湖，同时数据入湖在华为公司也形成了标准的流程规范，每个数据资产都要入湖成为数据工作的重要标准。

华为数据湖主要有以下几个特点。
1）逻辑统一
华为数据湖不是一个单一的物理存储，而是根据数据类型、业务区域等由多个不同的物理存储构成，并通过统一的元数据语义层进行定义、拉通和管理。
2）类型多样
数据湖存放所有不同类型的数据，包括企业内部IT系统产生的结构化数据、业务交易和内部管理的非结构化的文本数据、公司内部园区各种传感器检测到的设备运行数据，以及外部的媒体数据等。
3）原始记录
华为数据湖是对原始数据的汇聚，不对数据做任何的转换、清洗、加工等处理，保留数据最原始特征，为数据的加工和消费提供丰富的可能。

5.2.2 数据入湖的6个标准

数据入湖是数据消费的基础，需要严格满足入湖的6项标准，包括明确数据Owner、发布数据标准、定义数据密级、明确数据源、数据质量评估、元数据注册。通过这6项标准保证入湖的数据都有明确的业务责任人，各项数据都可理解，同时都能在相应的信息安全保障下进行消费。
（1）明确数据Owner
数据Owner由数据产生对应的流程Owner担任，是所辖数据端到端管理的责任人，负责对入湖的数据定义数据标准和密级，承接数据消费中的数据质量问题，并制定数据管理工作路标，持续提升数据质量。
（2）发布数据标准
入湖数据要有相应的业务数据标准。业务数据标准描述公司层面需共同遵守的“属性层”数据的含义和业务规则，是公司层面对某个数据的共同理解，这些理解一旦明确并发布，就需要作为标准在企业内被共同遵守。数据标准的信息如表5-1所示。

（3）认证数据源
通过认证数据源，能够确保数据从正确的数据源头入湖。认证数据源应遵循公司数据源管理的要求，一般数据源是指业务上首次正式发布某项数据的应用系统，并经过数据管理专业组织认证。认证过的数据源作为唯一数据源头被数据湖调用。当承载数据源的应用系统出现合并、分拆、下线情况时，应及时对数据源进行失效处理，并启动新数据源认证。
（4）定义数据密级
定义数据密级是数据入湖的必要条件，为了确保数据湖中的数据能充分地共享，同时又不发生信息安全问题，入湖的数据必须要定密。数据定密的责任主体是数据Owner，数据管家有责任审视入湖数据密级的完整性，并推动、协调数据定密工作。数据定级密度在属性层级，根据资产的重要程度，定义不同等级。不同密级的数据有相应的数据消费要求，为了促进公司数据的消费，数据湖中的数据有相应的降密机制，到降密期或满足降密条件的数据应及时降密，并刷新密级信息。
（5）数据质量评估
数据质量是数据消费结果的保证，数据入湖不需要对数据进行清洗，但需要对数据质量进行评估，让数据的消费人员了解数据的质量情况，并了解消费该数据的质量风险。同时数据Owner和数据管家可以根据数据质量评估的情况，推动源头数据质量的提升，满足数据质量的消费要求。
（6）元数据注册
元数据注册是指将入湖数据的业务元数据和技术元数据进行关联，包括逻辑实体与物理表的对应关系，以及业务属性和表字段的对应关系。通过联接业务元数据和技术元数据的关系，能够支撑数据消费人员通过业务语义快速地搜索到数据湖中的数据，降低数据湖中数据消费的门槛，能让更多的业务分析人员理解和消费数据。

5.2.3 数据入湖方式

数据入湖遵循华为信息架构，以逻辑数据实体为粒度入湖，逻辑数据实体在首次入湖时应该考虑信息的完整性。原则上，一个逻辑数据实体的所有属性应该一次性进湖，避免一个逻辑实体多次入湖，增加入湖工作量。

数据入湖的方式主要有物理入湖和虚拟入湖两种，根据数据消费的场景和需求，一个逻辑实体可以有不同的入湖方式。两种入湖方式相互协同，共同满足数据联接和用户数据消费的需求，数据管家有责任根据消费场景的不同，提供相应方式的入湖数据。

物理入湖是指将原始数据复制到数据湖中，包括批量处理、数据复制同步、消息和流集成等方式。虚拟入湖是指原始数据不在数据湖中进行物理存储，而是通过建立对应虚拟表的集成方式实现入湖，实时性强，一般面向小数据量应用，大批量的数据操作可能会影响源系统。

数据入湖有以下5种主要技术手段
批量集成（Bulk/Batch Data Movement）
对于需要进行复杂数据清理和转换且数据量较大的场景，批量集成是首选。通常，调度作业每小时或每天执行，主要包含ETL、ELT和FTP等工具。批量集成不适合低数据延迟和高灵活性的场景。

数据复制同步（Data Replication/Data Synchronization）
适用于需要高可用性和对数据源影响小的场景。使用基于日志的CDC捕获数据变更，实时获取数据。数据复制同步不适合处理各种数据
结构以及需要清理和转换复杂数据的场景。

消息集成（Message-Oriented Movement of Data）
通常通过API捕获或提取数据，适用于处理不同数据结构以及需要高可靠性和复杂转换的场景。尤其对于许多遗留系统、ERP和SaaS来
说，消息集成是唯一的选择。消息集成不适合处理大量数据的场景。

流集成（Stream Data Integration）
主要关注流数据的采集和处理，满足数据实时集成需求，处理每秒数万甚至数十万个事件流，有时甚至数以百万计的事件流。流集成不适合需要复杂数据清理和转换的场景。

数据虚拟化（Data Virtualization）
对于需要低数据延迟、高灵活性和临时模式（不断变化下的模式）的消费场景，数据虚拟化是一个很好的选择。在数据虚拟化的基础上，通过共享数据访问层，分离数据源和数据湖，减少数据源变更带来的影响，同时支持数据实时消费。数据虚拟化不适合需要处理大量数据的场景。

5种数据入湖方式的对比可以参考表5-2。

可以通过数据湖主动从数据源PULL（拉）的方式入湖，也可以通过数据源主动向数据湖PUSH（推）的方式入湖。数据复制同步、数据虚拟化以及传统ETL批量集成都属于数据湖主动拉的方式；流集成、消息集成属于数据源主动推送的方式（如表5-3所示）。在特定的批量集成场景下，数据会以CSV、XML等格式，通过FTP推送给数据湖。

5.2.4 结构化数据入湖

结构化数据是指由二维表结构来逻辑表达和实现的数据，严格遵循数据格式与长度规范，主要通过关系型数据库进行存储和管理。触发结构化数据入湖的场景有两种：第一，企业数据管理组织基于业务需求主动规划和统筹；第二，响应数据消费方的需求。

结构化数据入湖过程包括：数据入湖需求分析及管理、检查数据入湖条件和评估入湖标准、实施数据入湖、注册元数据（如图5-3所示）。

1. 数据入湖需求分析及管理
对于规划驱动入湖场景而言，由对应的数据代表基于数据湖的建设规划，输出入湖规划清单，清单包含主题域分组、主题域、业务对象、逻辑实体、业务属性、源系统物理表和物理字段等信息。

对于需求驱动入湖场景而言，由数据消费方的业务代表提出入湖需求，并提供数据需求的业务元数据和技术元数据的信息，包括业务对象、逻辑实体、业务属性对应界面的截图。

无论是主动规划还是被动响应需求，入湖需求清单必须通过业务代表和数据代表的联合评审。当业务代表和数据代表就评审结论发生争议时，可到专业评审组织申请仲裁。

2. 检查数据入湖条件和评估入湖标准
在数据入湖前要检查数据源准备度和评估数据入湖标准。
（1）检查数据源准备度
数据有源是数据入湖的基本前提，数据源准备度检查不仅需要源系统的IT团队提供源系统的数据字典和数据模型并检查源系统的物理表规范度，而且需要数据代表评估源系统的数据质量。

（2）评估入湖标准
入湖标准包括以下几点。
明确数据Owner：为保证入湖数据的管理责任清晰，在数据入湖前应明确数据Owner。
发布数据标准：入湖数据应有数据标准，数据标准定义了数据属性的业务含义、业务规则等，是正确理解和使用数据的重要依据，也是业务元数据的重要组成部分。
认证数据源：原则上以初始源进湖，数据源认证是保证数据湖数据一致性和唯一性的重要措施。
定义数据密级：定义完整、明确的数据密级是数据湖数据共享、权限控制等的关键依据。信息安全管理专员向业务Owner提出定密需求，并与业务Owner确定定密规则，确定数据密级、定密时间、降密期/降密条件等，然后由信息安全管理专员在信息架构管理平台注册密级信息。
评估入湖数据质量：对入湖数据做质量评估，给入湖数据打质量标签。
如果不满足上述任意一条入湖标准，就应推动源系统数据代表完成整改，满足要求后方可实施数据入湖。
3. 实施数据入湖
数据代表依据消费场景合理选择入湖方式，在不要求历史数据、小批量数据且实时性要求高的场景，建议虚拟入湖；在要求历史数据、大批量数据且实时性要求不高的场景，可以物理入湖。虚拟入湖由数据代表实施，数据代表负责设计和部署虚拟表。物理入湖由对应数据湖的IT代表承接IT实施需求，设计集成方案和数据质量监测方案，实施数据入湖。数据代表组织UAT测试、上线验证。
4. 注册元数据
元数据是公司的重要资产，是数据共享和消费的前提，为数据导航和数据地图建设提供关键输入。对元数据进行有效注册是实现上述目的的前提。
虚拟表部署完成后或IT实施完成后，由数据代表检查并注册元数据，元数据注册应遵循企业元数据注册规范。

5.2.5 非结构化数据入湖

1. 非结构化数据管理的范围
非结构化数据包括无格式的文本、各类格式的文档、图像、音频、视频等多样异构的格式文件。相较于结构化数据，非结构化数据更难以标准化和理解，因而非结构化数据的管理不仅包括文件本身，而且包括对文件的描述属性，也就是非结构化的元数据信息。

这些元数据信息包括文件对象的标题、格式、Owner等基本特征，还包括对数据内容的客观理解信息，如标签、相似性检索、相似性连接等。这些元数据信息便于用户对非结构化数据进行搜索和消费。非结构化数据的元数据实体如图5-4所示。

都柏林核心元数据是一个致力于规范Web资源体系结构的国际性元数据解决方案，它定义了一个所有Web资源都应遵循的通用核心标准。
基本特征类属性由公司进行统一管理，内容增强类属性由承担数据分析工作的项目组自行设计，但其分析结果都应由公司元数据管理平台自动采集后进行统一存储。
2. 非结构化数据入湖的4种方式
非结构化数据入湖包括基本特征元数据入湖、文件解析内容入湖、文件关系入湖和原始文件入湖4种方式，其中基本特征元数据入湖是必选内容，后面三项内容可以根据分析诉求选择性入湖和延后入湖，如图5-5所示。

1）基本特征元数据入湖
主要通过从源端集成的文档本身的基本信息入湖。入湖的过程中，数据内容仍存储在源系统，数据湖中仅存储非结构化数据的基本特征元数据。基本特征元数据入湖需同时满足如下条件。
已经设计了包含基本特征元数据的索引表。
已经设计了信息架构，如业务对象和逻辑实体。
已经定义了索引表中每笔记录对应文件的Owner、标准、密级，认证了数据源并满足质量要求。
参考都柏林核心元数据，非结构化数据的基本特征类属性元数据规范如表5-4所示。


2）文件解析内容入湖
对数据源的文件内容进行文本解析、拆分后入湖。入湖的过程中，原始文件仍存储在源系统，数据湖中仅存储解析后的内容增强元数据。内容解析入湖需同时满足如下条件。
已经确定解析后的内容对应的Owner、密级和使用的范围。
已经获取了解析前对应原始文件的基本特征元数据。
已经确定了内容解析后的存储位置，并保证至少一年内不会迁移。
3）文件关系入湖
根据知识图谱等应用案例在源端提取的文件上下文关系入湖。入湖的过程中，原始文件仍存储在源系统，数据湖中仅存储文件的关系等内容增强元数据。文件关系入湖需同时满足如下条件：
已经确定文件对应的Owner、密级和使用的范围。
已经获取了文件的基本特征元数据。
已经确定了关系实体的存储位置，并保证至少一年内不会迁移。
4）原始文件入湖
根据消费应用案例从源端把原始文件搬入湖。数据湖中存储原始文件并进行全生命周期管理。原始文件入湖需同时满足如下条件。
已经确定原始文件对应的Owner、密级和使用的范围。
已经获取了基本特征元数据。
已经确定了存储位置，并保证至少一年内不会迁移。

5.3 数据主题联接：将数据转换为“信息”

5.3.1 5类数据主题联接的应用场景

在数字化转型的背景下，华为的数据消费已经不再局限于传统的报表分析，还要支持用户的自助分析、实时分析，通过数据的关联，支持业务的关联影响分析以及对目标对象做特征识别，进行特定业务范围圈定、差异化管理与决策等。这些分析需求也不再是对单一数据的分析，往往需要对跨领域的数据进行联接后再进行综合分析。目前，数据湖汇聚了大量的原始数据，用户不再需要到各个源系统调用数据，而是统一从数据湖调用。由于数据湖中的数据零散且数据结构都与源系统一致，严格遵从三范式，即使每个数据都有详细的定义和解释，用户也很难知道数据之间的关联关系。例如，消费者BG做设备收入预测需要的数据有产品、订单、计划等超过150个物理表信息，这些表没有进行联接，没有形成有用信息，是很难支撑用户进行分析的。

华为在数据湖的基础上通过建立数据联接层，基于不同的分析场景，通过5类联接方式将跨域的数据联接起来，将数据由“原材料”加工成“半成品”和“成品”，支撑不同场景的数据消费需求，如图5-6所示。

多维模型是面向业务的多视角、多维度的分析，通过明确的业务关系，建立基于事实表、维度表以及相互间联接关系，实现多维数据查询和分析。例如，对订货数据从时间、区域、产品、客户等维度进行多视角、不同粒度的查询和分析。

图模型面向数据间的关联影响分析，通过建立数据对象以及数据实例之间的关系，帮助业务快速定位关联影响。例如，查看某国家原产地的项目的数据具体关联到哪个客户以及合同、订单、产品的详细信息时，可以通过图模型快速分析关联影响，支撑业务决策。

标签是对特定业务范围的圈定。在业务场景的上下文背景中，运用抽象、归纳、推理等算法计算并生成目标对象特征的表示符号，是用户主观观察、认识和描述对象的一个角度。例如，对用户进行画像，识别不同的用户群，为产品设计和营销提供策略支持。

指标是对业务结果、效率和质量的度量。依据明确的业务规则，通过数据计算得到衡量目标总体特征的统计数值，能客观表征企业某一业务活动中业务状况。例如，促销员门店覆盖率指标就是衡量一线销售门店促销员的覆盖程度。

算法模型是面向智能分析的场景，通过数学建模对现实世界进行抽象、模拟和仿真，提供支撑业务判断和决策的高级分析方法。例如，预测未来18个月的销售量，需要数据科学家根据数据湖中的历史订单、发货等数据通过决策树和基因算法进行数据建模，支持业务决策。

5.3.2 多维模型设计

多维模型是依据明确的业务关系，建立基于维度、事实表以及相互间连接关系的模型，实现多角度、多层次的数据查询和分析。如何设计出稳定、易扩展、高可用的数据模型来支持用户消费对数据主题联接至关重要。
多维模型设计有4个主要步骤，包括确定业务场景、声明粒度、维度设计和事实表设计。

（1）确定业务场景
分析业务需求，识别需求中所涉及的业务流及其对应的逻辑数据实体和关联关系。如业务负责人（PO）履行全流程可视，首先需要识别监控的具体业务环节（如发货、开票等），再根据这些业务环节识别其对应的逻辑数据实体及关联关系，如图5-7所示。

（2）声明粒度
粒度表示数据单元的细节程度或综合程度，细节程度越高，粒度越细；细节程度越低，粒度越粗。声明粒度是维度和事实表设计的重要步骤，声明粒度意味着精确定义事实表的每一行表示什么。针对监控PO履行这个场景，在做设计时首先要确认是监控PO的履行，还是具体到每个PO行的履行，不同的粒度会对应不同的事实表。
（3）维度设计
维度是用于观察和分析业务数据的视角，支持对数据进行汇聚、钻取、切片分析，如图5-8所示。维度由层次结构（关系）、层级、成员、属性组成。维度可以分为基础树和组合树，维度基础树提供统一定义的、完整的层级结构和成员；维度组合树根据业务使用场景进行定制。

维度设计需要满足单一性、单向性和正交性。
1）单一性
有且仅有一个视角，在同一个维度中不能穿插其他经营分析的视角，例如，区域维不含客户视角，产品维不含客户视角等。图5-9中区域维度客户视角不满足单一性要求。

2）单向性
“上大下小”，维度只能支撑自上而下的分解和自下而上的收敛，每个成员只能存在向上的收敛路径，不能具备向上和向下两个方向的收敛逻辑。图5-10中代表处维度低于国家维度，不满足单向性要求。

3）正交性
成员两两不相交，同一成员不能同时拥有多个上级成员，以产品维为例，华为向客户提供的设备或服务都只能被准确地分配到唯一叶子（最底层）节点，并以此路径进行收敛。图5-11中最小粒度成员“无线专业服务”同时归属不同的上层节点，不满足正交性要求。

（4）事实表设计
事实表存储业务过程事件的性能度量结果，由粒度属性、维度属性、事实属性和其他描述属性组成，如图5-12所示。

粒度属性是事实表的主键，通常由原始数据的主键或一组维度属性生成。

维度属性是从维度中继承的属性，可以只继承主键作为事实表的外键，也可以继承维度中全部或其他部分的属性。在上述例子中，事实表中除了有币种ID，还可以带有币种编码和币种名称等属性。
事实属性是可以对该颗粒度的事实进行定量的属性，大多数的事实表包括一个或多个事实字段。
同一事实表中不能存在多种不同粒度的事实，比如PO行明细事实表中不应该包含PO总金额，否则PO总金额累加时会出现错误。
尽可能包含所有与业务过程相关的事实，不包含与业务过程无关的事实，比如在设计“订单下单”这个业务过程的事实表时，不应该存在“支付金额”这个支付业务过程的事实。
对于不可相加的事实，需要分解为可加的事实。比如比率，需要分解为分子和分母。
事实的数值单位要保持一致。

其他属性主要包括创建人、创建时间、最后修改人、最后修改时间等审计字段。

5.3.3 图模型设计

图模型作为当前流行的信息处理加工技术，自提出以来，迅速在学术界和工业界得到了普及，在智能推荐、决策分析等方面有着广泛的应用。

图模型由节点和边组成。节点表示实体或概念，边则由属性或关系构成。实体指的是具有可区别性且独立存在的某种事物，如某一个人、某一个城市、某一种植物、某一种商品等，是图模型中的最基本元素；概念是对特征的组合而形成的知识单元，主要指集合、类别、对象类型、事物的种类，例如人物、地理等；属性主要指描述实体或概念的特征或特性，例如人员的国籍、生日等。我们以“哲学家”为例设计图模型，如图5-13所示。

第一步：业务场景定义。
业务场景决定信息涵盖范围，以及信息颗粒度的表示。以支撑业务连续性为例，因为不可抗力的影响，部分区域的供应商工厂无法正常生产和发货，涉及的信息包括供应商的信息、产能、元器件及内部物料、合同和客户信息，要求能够根据用户输入的当前物料储备和合同状态，获取影响内部物料、产品、合同交付和客户的清单和范围。

这种应用涉及对产品目录和配置的解读，需要对收集的信息进行最小采购器件的抽取。

信息颗粒度在图模型建设中是个不可忽视的问题，根据应用场景决定信息颗粒度以及图模型的精确性与有效性。比如手机，有品牌、型号、批次，直至手机整机。同样的信息范围，颗粒度越细，图模型应用越广泛，关系越丰富，但冗余越多，知识消费越低效。信息颗粒度的原则是“能满足业务应用的最粗颗粒度”。
第二步：信息收集。
信息的选取要考虑两个方面的内容。
1）与应用场景直接相关的信息。例如，判断不可抗力供应中断影响的范围，直接相关的信息有物料信息、产品配置、合同信息等。
2）与应用场景间接相关，但可辅助理解问题的信息。这包括企业信息、专业领域信息、行业信息以及开放域信息。

第三步：图建模。
相同的数据可以有若干种模式的定义，良好的模式可以减少数据冗余，提高实体识别的准确率，在建模的过程中，要结合数据特点与应用场景来完成。同样的数据从不同的视角可以得出不同的图模型。
第四步：实体、概念、属性、关系的标注。
企业图模型中涉及的实体和概念可分为三类：公共类，如人名、机构名、地名、公司名、时间等；企业类，如业务术语、企业部门等；行业类，如金融行业、通信行业等。
第五步：实体和概念的识别。
企业图模型中实体、概念的识别可将业务输入与数据资产中已有的信息作为种子，运用命名实体识别（NER）的方法扩展出新实体概念，经业务确认后，列入实体、概念库。
第六步：属性识别与关系识别。
企业图模型中的属性与关系一般是根据业务知识在模式层设计时定义，属性与关系相对稳定，其扩展场景不是很多。

企业图模型的存储技术要综合考虑应用场景、图模型中节点和联接的数量、逻辑的复杂度、属性的复杂度，以及性能要求。一般建议采用混合存储方式，用图数据库存储关系，关系型数据库或键值对存储属性。偏重逻辑推理的应用场景用RDF的存储方式，偏重图计算的应用场景选择属性图的存储方式。发挥两类数据存储和读写的各自优势。

知识计算主要是根据图谱提供的信息得到更多隐含的知识，如通过模式层以及规则推理技术可以获取数据中存在的隐含信息。知识计算涉及三大关键技术：图挖掘计算、基于本体的推理、基于规则的推理。图挖掘计算是基于图论的相关算法，实现对图谱的探索和挖掘。图挖掘计算主要分为如下6类。

图遍历：知识图谱构建完之后可以理解为是一张很大的图，可以去查询和遍历这个图，要根据图的特点和应用场景进行遍历。
图里面经典的算法，如最短路径。
路径的探寻，即根据给定两个实体或多个实体去发现它们之间的关系。
权威节点的分析，这在社交网络分析中使用较多。
族群分析。
相似节点的发现。
图挖掘计算如图5-15所示。

图挖掘计算在当前的应用场景中，基于业务连续性，通过查询遍历图模型，识别影响节点和影响范围，基于最短路径，辅助决策物流线路，在企业中的应用较为普遍。

图模型在企业中的价值，很大程度上取决于企业基于对象节点可以构建多完善的关系，这个关系的构建是一个逐步完善的过程，基于业务场景不断补充和完善关系，这就是图模型的优势。当形成一个足够完善的企业级图模型后，领域分段的业务场景应用只需要裁剪部分节点和关系，就可以满足业务的需求，达到快速响应业务需求、降低开发成本的目的。

5.3.4 标签设计

标签是根据业务场景的需求，通过对目标对象（含静态、动态特性）运用抽象、归纳、推理等算法得到的高度精练的特征标识，用于差异化管理与决策。标签由标签和标签值组成，打在目标对象上，如图5-16所示。

标签由互联网领域逐步推广到其他领域，打标签的对象也由用户、产品等扩展到渠道、营销活动等。在互联网领域，标签有助于实现精准营销、定向推送、提升用户差异化体验等；在行业领域，标签更多助力于战略分级、智能搜索、优化运营、精准营销、优化服务、智慧经营等。

标签分为事实标签、规则标签和模型标签，如图5-17所示。

事实标签是描述实体的客观事实，关注实体的属性特征，如一个部件是采购件还是非采购件，一名员工是男性还是女性等，标签来源于实体的属性，是客观和静态的；规则标签是对数据加工处理后的标签，是属性与度量结合的统计结果，如货物是否是超重货物，产品是否是热销产品等，标签是通过属性结合一些判断规则生成的，是相对客观和静态的；模型标签则是洞察业务价值导向的不同特征，是对于实体的评估和预测，如消费者的换机消费潜力是旺盛、普通还是低等，标签是通过属性结合算法生成的，是主观和动态的。
标签管理分为标签体系建设和打标签。
1. 标签体系建设
（1）选定目标对象，根据业务需求确定标签所打的业务对象，业务对象范围参考公司发布的信息架构中的业务对象。
（2）根据标签的复杂程度进行标签层级设计。
（3）进行详细的标签和标签值设计，包括标签定义、适用范围、标签的生成逻辑等：
事实标签应与业务对象中的属性和属性值保持一致，不允许新增和修改；
规则标签按照业务部门的规则进行相关设计；
模型标签根据算法模型生成。
2. 打标签
（1）打标签数据存储结构
打标签是建立标签值与实例数据的关系，可以对一个业务对象、一个逻辑数据实体、一个物理表或一条记录打标签。

为了方便从“用户”视角查找、关联、消费标签，可增加用户表，将标签归属到该“用户”下，这里的“用户”是泛指，可以是具体的人，也可以是一个组织、一个部门、一个项目等。
（2）打标签的实现方法
事实标签：根据标签值和属性允许值的关系由系统自动打标签。
规则标签：设计打标签逻辑由系统自动打标签。
模型标签：设计打标签算法模型由系统自动打标签。

5.3.5 指标设计

指标是衡量目标总体特征的统计数值，是能表征企业某一业务活动中业务状况的数值指示器。指标一般由指标名称和指标数值两部分组成，指标名称及其含义体现了指标在质的规定性和量的规定性两个方面的特点；指标数值反映了指标在具体时间、地点、条件下的数量表现。

根据指标计算逻辑是否含有叠加公式，可以把指标分为原子指标和复合指标两种类型。

原子指标是指标数据通过添加口径/修饰词、维度卷积而成，口径/修饰词、维度均来源于指标数据中的属性。
复合指标由一个或多个原子指标叠加计算而成，其中维度、口径/修饰词均继承于原子指标，不能脱离原子指标维度和口径/修饰词的范围去产生新的维度和口径/修饰词。指标和数据的关系如图5-18所示。

指标数据：承载原子指标的数据表，例如门店明细表，其中度量为门店数量，通过【门店编码】卷积；属性包括门店等级、门店状态、门店形象等级、组织等级等。
维度：从属性中选取组织、渠道、门店形象等级。
口径/修饰词：【门店状态】等于【有效】，【有无促销员】等于【1】。
原子指标：由指标数据通过添加口径/修饰词、维度卷积而成，包括促销员覆盖门店数量、有效门店数量。
复合指标：由2个或2个以上指标叠加计算而成，包括【促销员门店覆盖率】=【促销员覆盖门店数量】÷【有效门店数量】。

如何按需求进行指标拆解，是将指标对应到数据资产并进行结构化管理，支持指标服务化与自助需求的关键。指标的拆解过程主要包括指标拆解需求澄清、指标拆解设计、指标数据与数据资产匹配3个阶段，如图5-19所示。

解读指标定义，识别指标：通过与指标定义的业务管理部门沟通（通常为指标解释部门的业务人员），从业务角度了解指标基本信息、所需统计维度、指标度量场景以及各场景下的计算逻辑和口径（包括剔除规则）、指标发布信息等。
基于指标叠加公式拆解指标：根据指标计算逻辑识别原子指标，明确原子指标中需要的口径/修饰词、维度信息，以及原子指标与复合指标间的支撑关系。
基于指标拆解结果，识别指标数据：识别原子指标的度量属性和支撑属性，并根据原子指标中的维度、口径修饰词匹配已发布业务对象的属性，形成指标数据。
数据匹配落地：补充指标、指标数据中的标准属性名称以及对应的落地物理表，支持用户自助实现指标计算，拉通指标设计和落地。
5.3.6 算法模型设计
算法是指训练、学习模型的具体计算方法，也就是如何求解全局最优解，并使得这个过程高效且准确，其本质上是求数学问题的最优化解，即算法是利用样本数据生成模型的方法。算法模型是根据业务需求，运用数学方法对数据进行建模，得到业务最优解，主要用于业务智能分析。
算法模型在数据分析流程中产生，算法模型管理框架包括建模、模型资产管理和模型消费。公司各领域已相继开发出大量基于算法模型的分析应用，通过对算法模型资产注册逐步打造公司级的算法模型地图。
算法模型的设计步骤主要有需求评估、数据准备、方案设计和建模与验证。
（1）需求评估
1）业务驱动的分析需求识别
如果要识别与业务运营优化相关的分析需求，就需要梳理业务需求的背景、现状与目标。
若由战略或变革提出可能的分析需求，则应进行战略目标解耦，识别分析需求，了解业务现状与制定目标。初步识别分析结果的应用场景。
2）数据驱动的分析需求识别
在集成的数据环境中进行数据挖掘，探索可能的分析应用。识别分析需求和确认应用领域。初步识别分析结果的应用场景。
3）价值与可行性评估
确定数据分析主题。
分析需求的业务价值评估，包括业务基线、分析主题的业务影响与可增进的效益。
分析前提与可行性，包括识别目前业务流程与可能的影响因素，探讨业务现状因素，并制定对应的分析解決方案，呈现出对应解决方案可提升的效益，对方案所需资源和数据的可行性进行评估。根据相关的历史数据，进行假设和分析，并明确业务范围。
（2）数据准备
深入探索数据资产目录，识别与分析主题可能相关的数据。
提供数据源、数据标准、数据流等信息。
收集与整合原始数据，生成分析数据集。
根据分析需求进行数据筛选和质量分析。
（3）方案设计
明确要分析的业务目标与相关假设。
定义数据集中的分析目标、样本与筛选条件。
设计所需变量、指标、可能的分析方法和产出。
规划分析的应用场景。
（4）建模与验证
1）决定是否需要分析建模：根据技术复杂度、业务效益和资源评估该分析需求是否需要分析建模。若需要分析建模且通过项目评审，则应进行高阶分析；若不需要建模分析，则运用BI分析。
2）建模与验证：根据数据分析方案创建模型，对模型的参数和变量进行调整，根据应用场景选择适用的模型，并与业务分析师确认模型成效与应用，并进行优化，进行模型相关验证（如准确度和稳定度评估）及效益评估。
3）试算分析：对数据分析方案中不需分析建模的场景和应用，根据数据分析方案进行分析结果的计算，并选择合适的展示方式。
4）编写数据分析线下验证报告：
记录分析结果与发现。
根据洞察发现，建议业务应用场景。
建议模型监测方式。
5）决定是否需要IT开发：根据模型验证成果（分析建模）、预估业务效益、IT开发所需的成本和资源来评估分析结果是否需要IT开发。若需要，则通过评审后转入IT开发流程；若不需要，则进入业务应用并结束流程
6）模型线上验证：
设定线上验证范围与场景。
进行线上验证，制定模型监控机制（含监控频次和监控要素），
生成分析模型线上验证报告。
进行业务试运行与推广。
7）转运营：与数据分析模型所属领域的业务代表确认转正式运营计划，启动业务正式运营。

5.4 本章小结

企业数据治理的最终目的是让数据更有效地服务于业务目标，创造价值。对于数字原生企业而言，原生入口提供的大规模、高质量的数据，可以快速地封装成企业级的API，满足业务侧的应用。华为作为非数字原生企业，在实践探索中发现，数字化转型的关键在于打通数据供应链，通过理解业务、识别数据资产、建设数据架构来推动组织间的共享和协作，标识安全隐私标签，从源头提升数据质量，并通过数据底座建设构建数据湖和数据主题联接两层，形成数据的逻辑集合，为业务可视化、分析、决策等数据消费提供数据服务，让企业数据成为能为业务带来价值的数据资产。