华为数据之道 拆书稿

这是一篇关于华为数据之道 拆书稿的思维导图，主要包括:一、数据驱动的企业数字化转型；二、建立企业级数据综合治理体系；三、差异化的企业数据分类管理框架；四、面向”业务交易“的信息架构建设；五、面向“联接共享”的数据底座建设；六、面向“自助消费”的数据服务建设等内容。

华为数据之道 读书笔记

• 一、 数据驱动的 企业数字化转型
  • 非数字原生企业的数字化转型挑战
    • 业态特征：产业链条长、多业态并存
    • 运营环境：数据交互和共享风险高
    • IT建设过程：数据复杂、历史包袱重
    • 数据质量：数据可信和一致化的要求程度高
  • 华为数字化转型与数据治理
    • 华为数字化转型整体目标
    • 华为数字化转型蓝图及对数据治理的要求
  • 华为数据治理实践
    • 华为数据治理历程
    • 华为数据工作的愿景与目标
    • 华为数据工作建设的整体思路与框架
  • 第一章小结
• 二、 建立企业级 数据综合治理体系
  • 建立公司级的数据治理政策
    • 华为数据管理总纲
    • 信息架构管理政策
    • 数据源管理政策
    • 数据质量管理政策
  • 融入变革、运营与IT的数据治理
    • 建立管理数据流程
    • 管理数据流程与管理变革项目、管理质量与运营之间的关系
    • 通过变革体系和运营体系进行决策
    • 数据治理融入IT实施
    • 通过内控体系赋能数据治理
  • 建立业务负责制的数据管理责任体系
    • 任命数据Owner和数据专家
    • 建立公司层面的数据管理组织
  • 第二章小结
• 三、 差异化的企业 数据分类管理框架
  • 基于数据特性的分类管理框架
  • 以统一语言为核心的结构化数据管理
    • 基础数据治理
    • 主数据治理
    • 事务数据治理
    • 报告数据治理
    • 观测数据治理
    • 规则数据治理
  • 以特征提取为核心的非结构化数据管理
  • 以确保合规新人为核心的外部数据管理
  • 作用于数据价值流的元数据管理
    • 元数据治理面临的挑战
      • 使命与目标：入湖有依据，出湖有检索
      • 元数据分为：业务、技术、操作三类
        • 业务元数据
          • 用访问数据时了解业务含义的途径，包括资产目录、OWNER、数据密级等
        • 技术元数据
          • 实施人员开发系统时使用的数据，包括物理模型的 表与字段、ETL规则、集成关系等。
        • 操作元数据
          • 数据处理日志及运营情况数据，包括调度频度、访 问记录等
      • 元数据于数字化价值流程中的价值
        • 数据消费侧
          • 元数据能支持企业指标、报表的动态构建
        • 数据服务侧
          • 元数据支持数据服务的统一管理和运营，并实现利 用元数据驱动IT敏捷开发。
        • 数据主题侧
          • 元数据统一管理分析模型，敏捷响应井喷式增长的 数据分析需求，支持数据增值、数据变现。
        • 数据湖侧
          • 元数据能实现暗数据的透明化，增强数据活性，并能 解决数据治理与IT落地脱节的问题
        • 数据源侧
          • 元数据支撑业务管理规则有效落地，保障数据内容合 格、合规。
    • 元数据管理架构及策略
      • 
      • 产生元数据
        • 制定元数据管理相关流程与规范的落地方案，在IT 产品开发过程中实现业务元数据与技术元数据的连接。
      • 采集元数据
        • 通过统一的元模型从各类IT系统中自动采集元数 据。
      • 注册元数据
        • 基于增量与存量两种场景，制定元数据注册方法， 完成底座元数据注册工作。
      • 运维元数据
        • 打造公司元数据中心，管理元数据产生、采集、注 册的全过程，实现元数据运维。
      • 元数据管理方案
        • 通过制定元数据标准、规范、平台与管控机 制，建立企业级元数据管理体系，并推动其在公司各领域落地， 支撑数据底座建设与数字化运营。
    • 元数据管理
      • 产生元数据
        • 明确业务元数据、技术元数据和操作元数据之间的关系，定义华为公司元数据模型
          • 
        • 针对找数据及获取数据难的痛点， 明确业务元数据、技术元 数据、操作元数据的设计原则。
          • 业务元数据设计原则
            • 一个主题域分组下有多个主题域，一个主题域下有多个业务对 象，一个业务对象下有多个逻辑实体，一个逻辑实体下有多个属 性，一个属性有一个数据标准。
            • 每个数据标准可被一个或多个属性引用，每个属性归属于一个逻 辑实体，每个逻辑实体归属于一个业务对象，每个业务对象归属于一个主题域，每个主题域归属于一个主题域分组。
          • 技术元数据设计原则
            • 物理表设计须满足三范式，如为了降低系统的总体资源消耗，提 高查询效率，可反范式设计。
            • 物理表、视图和字段的设计须基于用途进行分类。
            • 承载业务用途的物理表、虚拟表、视图必须与逻辑实体一一对 应，承载业务用途的字段必须与属性一一对应。
            • 系统间的数据传递须优先采用数据服务。
          • 操作元数据设计原则
            • 日志目的不同的进行分类设计，日志目的相同的进行相同设计 （非自研场景按软件包适配）。
        • 规范数据资产管理，设计数据资产编码规范
          • 数据资产编码规范
            • 华为数据资产编码的主要包括业务元数据和技术元数据两大类， 其中: 业务元数据包含主题域分组、主题域、业务对象、逻辑实体、属 性、数据标准； 技术元数据包含物理数据库、Schema、表、字段。
              • 
          • 数据资产编码原则
            • 数据资产编码（DAN）是通过一组数字、符号等组成的字符串去唯 一标识华为公司内部每一个数据资产，基于此唯一标识，保证各业务 领域对同一数据资产的理解和使用一致，
            • 统一性原则
              • 华为公司内部只能使用一套数据资产编码，以方便 不同业务部门之间的沟通和IT应用之间的数据交换
            • 唯一性原则
              • 每一个数据资产只能用唯一的数据资产编码进行标 识，不同数据资产的编码不允许重复，同一个编码也只能对应到 一个数据资产上
            • 可读性原则
              • 数据资产编码作为数据资产分类、检索的关键词和 索引，需要具备一定的可读性，让用户通过编码就能初步判断其 对应的数据资产类型
            • 扩展性原则
              • 数据资产的编码要从数据管理角度适当考虑未来几 年的业务发展趋势，其编码长度要能适当扩展，同时不影响整个 编码体系。
          • 业务元数据资产编码规则
            • 主题域
              • 分组的编码规则，主题域分组的编码由公司统一分配
            • 主题域、业务对象、逻辑实体、属性的编码规则
              • ，这部分主要由数据治 理平台按照编码规则自动生成；
            • 业务元数据包含的子类对应的数据资产类型代码
      • 采集元数据
        • 元数据采集是指从生产系统、IT设计平台等数据源获取元数据， 对元数据进行转换，然后写入元数据中心的过程。
        • 选择适配器
          • 适配器是指针对不同的元数据来源，采用相应的采集方式获取元 数据的程序，元数据的来源种类繁多，因而须选择相对应的适配器及 元模型。
        • 配置数据源
          • 配置数据源是采集元数据的关键，在确定数据源所选择的适配器 类型、适配器版本、元模型的基础上，配置数据源的名称、连接参数 和描述。
        • 配置采集任务
          • 采集任务为自动调度的工作单元，为元数据的采集提供自动化 的、周期性的、定时的触发机制。
      • 注册元数据
        • 大多数企业的数字化建设都存在增量和存量两种场景，如何同时 有效地管理这两种场景下的元数据就成了问题的关键。 华为通过标准的元数据注册规范和统一的元数据注册方法，实现了两种场景下业务元数据和技术元数据的高效连接，使业务人员能看懂数据、理解数 据，并通过数据底座实现数据的共享与消费。
        • 元数据注册原则
          • 数据Owner负责，是谁的数据就由谁负责业务元数据和技术元数据 连接关系的建设和注册发布
          • 按需注册，各领域数据管理部根据数据搜索、共享的需求，推进 元数据注册；
          • 注册的元数据的信息安全密级为内部公开。
        • 元数据注册规范
          • 通过“元数据注册三步法”完成元数据注册
          • 准备度评估项包括如下检查要点
            • IT系统名称必须是公司标准名称
            • 数据资产目录是否经过评审并正式发布；
            • 数据Owner是否确定数据密级
            • 物理表/虚拟表/视图名。
          • 元数据连接规范
            • 逻辑实体和物理表/虚拟表/视图一对一连接规范：
              • 在业务元数据 与技术元数据连接的过程中，必须遵从逻辑实体和物理表/虚拟 表/视图一对一的连接原则， 如果出现一对多、多对一或多对多的 情况，各领域需根据实际场景，参照元数据连接的设计模式进行 调整。
            • 业务属性与字段一对一连接规范
              • 除了逻辑实体与物理表/虚拟 表/视图要求一一对应外，属性和非系统字段（具备业务含义）也 要求遵从一对一的连接原则，如出现属性与字段匹配不上的情 况，可参考元数据关联的设计模式进行调整。
        • 元数据注册方法
          • 存量元数据注册
            • 华为设计了元数据注册的四大模式。 在符合元数 据设计规范的前提下，进行业务元数据与技术元数据的连接及注册
            • 一对一模式
              • 适用场景
                • 适用于数据已发布信息架构和数据标准且物理落地，架构、标准 与物理落地能一一对应的场景。
                • 适用于数据已发布信息架构和数据标准且物理落地，架构、标准 与物理落地能一一对应的场景。
              • 解决方案
                • 将逻辑实体和物理表一对一连接。
                • 逻辑实体属性和物理表字段一对一连接
              • 应用实例
                • 
            • 主从模式
              • 适用场景
                • 适用于主表和从表结构一致，但数据内容基于某种维度分别存储 在不同物理表中的场景。例如，按时间或项目归档，或按区域进行分 布式存储。
              • 解决方案
                • 识别主物理表和从属物理表
                • 以主物理表为核心，纵向UNION所有从属物理表，并固化为视图
                • 将视图、逻辑实体、字段和业务属性一对一连接
              • 应用实例
                • 
            • 主扩模式
              • 适用场景
                • 适用于逻辑实体的大部分业务属性在主物理表，少数属性在其他 物理表中的场景
              • 解决方案
                • 识别主物理表和扩展物理表。
                • 以主物理表为核心，横向JOIN所有扩展物理表，完成扩展属性与 主表的映射，并固化为视图
                • 将视图、逻辑实体、字段和业务属性一对一连接
              • 应用实例
                • 
            • 父子模式
              • 适用场景
                • 适用于多个逻辑实体业务属性完全相同，按不同场景区分逻辑实 体名称，但落地在同一张物理表的场景
              • 解决方案
                • 识别一张物理表和对应的多个逻辑实体
                • 将物理表按场景拆分和多个逻辑实体一对一连接
                • 将物理表字段和多个逻辑实体属性一对一连接
              • 应用实例
                • 
          • 增量元数据注册
            • 增量场景相对容易，在IT系统的设计与开发过程中，落实元数据 的相关规范，确保系统上线时即完成业务元数据与技术元数据连接， 通过元数据采集器实现元数据自动注册。
        • 完成元数据注册后，通过元数据中心自动发布
      • 运维元数据
        • 运维元数据是为了通过对元数据进行分析，发现数据注册、设 计、使用的现状及问题， 确保元数据的完整、准确。通过数据资产分 析，了解各区域/领域的数据注册情况， 进而发现数据在各信息系统使 用过程中存在的问题。 通过业务元数据与技术元数据的关联分析， 反向校验架构设计与落地的实施情况， 检查公司数据管理政策的执行情况。
        • 基于数据更新发现，数据源上游创建，下游更新
        • 通过数据调用次数发现，某数据源上游调用次数
        • 虽制定了架构标准，但不知落地情况，比如某个属性建 立了数据标准，但是却找不到对应落地的物理表字段；
        • 通过物理表的字段分析，发现很多字段缺少数据标准。
  • 第三章小结
    • 华为经过多年实践，已经建立了相对完整的数据分类管理框架， 为数据治理奠定了基础。随着数字化转型的深入开展，尤其是面向未 来海量的非结构化数据、IoT场景的观测数据、外部合规日趋严格的外 部数据等，华为将不断丰富每一类数据的治理实践。
• 四、 面向”业务交易“的 信息架构建设
  • 信息架构的 价值并不应局限于“支撑IT建设落地”， 而是更好地管理企业数据资 产，更好地提升整个业务交易链条的效率， 甚至基于信息架构重新审 视业务边界的划分和整合
  • 信息架构的四个组件
    • 企业在运作过程中， 首先需要管理好人和物等“资源”， 然后管理好各类资源之间的联系，即各类业务交易“事件”， 再对各类事件 的执行效果进行“整体描述和评估”， 最终实现组织目标和价值。 信息架构的目的就是定义好整个运作过程中涉及的各种人、事、 物资源， 并实施有效的治理，从而确保各类数据在企业各业务单元间 高效、准确地传递，上下游流程快速地执行和运作 
    • 数据资产目录
      • 数据资产目录形成完善的企业资产地图，也在一定程度上为企业 数据治理、业务变革提供了指引。 基于数据资产目录可以识别数据管 理责任，解决数据问题争议，帮助企业更好地对业务变革进行规划设 计，避免重复建设。 
      • L1为主题域分组 华为公司采用 业务管理边界划分方式， 即将L1主题域分组与流程架构L1相匹配，
        • 是描述公司数据管理的最高层级分类。 华为公司采用 业务管理边界划分方式， 即将L1主题域分组与流程架构L1相匹配，数据资产和华为业务GPO（全球流程责任人）相匹配，有利于更好地推进 各项数据工作。
        • 基于数据自身特征边界进行分类
        • 基于 业务管理边界进行分类
      • L2为主题域
        • 是互不重叠的数据分类，管辖一组密切相关的业务 对象，通常同一个主题域有相同的数据Owner。
      • L3为业务对象
        • 是信息架构的核心层，用于定义业务领域重要的 人、事、物，架构建设和治理主要围绕业务对象开展。同时，在企业 架构（EA）的范畴内，信息架构（IA）也主要通过业务对象实现与业 务架构（BA）、应用架构（AA）、技术架构（TA）的架构集成。
      • L4是逻辑数据实体
        • 是指描述一个业务对象在某方面特征的一组 属性集合
      • L5为属性
        • 是信息架构的最小颗粒，用于客观描述业务对象在某 方面的性质和特征。
    • 数据标准 数据标准是在企业范围内确保数据一致的关键 每个数据标准应覆盖下述要求:
      • 数据标准定义公司层面需共同遵守的属性层数据含义和业务规 则，是公司层面对某个数据的共同理解，这些理解一旦确定下来，就 应作为企业层面的标准在企业内被共同遵守。  以基础数据“运营商BG”为例，有的系统叫“carrier network”，有的系统叫“operator”，还有的系统叫“CNBG”，那么 在统计“运营商BG”视角的财务报告时，数据处理人员需要将标识为 “carrier network”“operator”“CNBG”的数据进行分类清洗和处 理，而不能直接卷积得到结果，增加了额外的处理时间和投入。如果 数据处理人员不清楚“运营商BG”这个数据在诸多系统中的名称不一 致的情况，那么很可能在统计时丢失部分数据，导致最终报告的失 真，最终可能误导决策。
      • 业务视角要求
        • 用于统一业务侧语言和理解，明确定义每个属性 所遵从的业务定义和用途、业务规则、同义词，并对名称进行统 一定义，避免重复。
      • 技术视角要求
        • 对IT实施形成必要的指引和约束，包括数据类型、长度，如果存在多个允许值，则应对每个允许值进行明确的限定。
      • 管理视角要求
        • 明确各业务部门在贯彻数据标准管理方面应承担 的责任， 包括业务规则责任主体、数据维护责任主体、数据监控 责任主体， 因为很多情况下这些责任并不是由同一个业务部门来负责， 所以必须在标准制订时就约定清楚。 例如，“客户合同” 中某些条款的规则制订者可能是财经部门，负责与客户达成约定并在系统中录入的可能是销售业务部门，而对整个客户合同数据 质量进行跟踪、监控的可能是数据专业部门。
      • 必要性与成本平衡下的数据标准统一选择
        • 为了实现在统一定义的必要性和成本之间取 得平衡，华为公司制订了数据标准规范，明确了在不同情况下哪些数 据应该制订统一的标准。
        • 描述业务对象的特有属性应作为本业务对象的属性进行定义，并 明确业务数据标准。
        • 引用其他业务对象的属性，如果属性值可随本业务对象确定和更 改，就应作为本业务对象的属性进行定义，并明确业务数据标 准。
        • 引用其他业务对象的属性，如果属性值取自引用业务对象相应时 点的数值且后续不变更，就应纳入本业务对象的数据标准范围， 并明确相应取值规则。
        • 引用其他业务对象的属性，如果属性值与引用业务对象同步，就 不需要重新定义数据标准。
        • 引用其他业务对象/逻辑数据实体的身份标识属性，应作为本业务 对象的属性进行定义，但只能在业务数据标准中定义出处及引用 规则，而不允许修改或重新定义该属性本身的业务含义及业务规 则。
    • 数据模型
      • 数据模型是从数据视角对现实世界特征的模拟和抽象，根据业务 需求抽取信息的主要特征，反映业务信息（对象）之间的关联关系。 数据模型不仅能比较真实地模拟业务（场景），同时也是对重要业务 模式和规则的固化。 例如在某个物流业务数据模型中，“运输申付单”与“运输委托”建立一对一关系，而“运输委托”与“派送任 务”建立多对多关系，那么这意味着业务部门可以根据发货效率和成 本的考虑将“运输委托”拆成分多个“派送任务”，但“派送任务” 必须在将一个运输委托完整执行后，才能申请向供应商付款。
    • 静态角度
    • 数据分布 定义了数据产生的源头及在各流程和IT系统间的 流动情况
      • 数据分布组件的核心是数据源，指业务上首次正式发布某 项数据的应用系统，并经过数据管理专业组织认证，作为企业范围内 唯一数据源头被周边系统调用。
      • 华为公司规定所有业务数据必须认证 数据源，并在公司范围内统一发布。
      • 为了更好地识别、管理数据在流 程和IT系统间的流动，可以通过信息链、数据流来进行描述，体现某 一数据在流程或应用系统中是如何被创建（Create）、读取 （Read）、更新（Update）、删除（Delete）的。
  • 信息架构原则：建立企业层面的共同行为准则， 治理目标：“数据同源一致”
    • 信息架构承载了企业如何管理数据资产的方法，需要从整个企业 层面制订统一的原则，这些原则不仅是对数据专业人员的要求，也是 对业务的要求，因为业务才是真正的数据Owner。所以，公司所有业务 部门都应该共同遵从信息架构原则。 华为首先确定了“数据同源一致”的治理目标，围绕目标的实现，制定了五条架构原则。各业务领域和变革项目应按照架构原则设 计其信息架构， 并由EAC（企业架构委员会）、IA-SAG（信息架构专家 组）指导和监督各领域落实企业架构原则，在一套规则的约束下，共 同建设一个企业级的信息架构。
    • 原则一：数据按对象管理，明确数据Owner
      • 数据要发挥作用，必然会在多个IT系统和流程中流转，并且越是重要的数据资产，所流经的业务环节就越多。例如，产品、人员、客户的数据几乎在所有流程中都会涉及，客户合同数据也会在整个业务 交易链条中流转，因此不应该以IT系统、业务流程边界来管理数据，而应该从数据本身出发，按对象进行数据全生命周期管理。 几乎所有的企业数据都是由业务产生的，IT人员无法对数据的定义、质量负责，因此需要在公司层面确定数据Owner。华为公司按照业务对象任命数据Owner，并且每个数据都只能有唯一的数据Owner。 数据Owner要负责所辖领域的信息架构建设和维护，负责保障所辖领域的数据质量，承接公司各个部门对本领域数据的需求，并有责任建立数 据问题回溯和奖惩机制，对所辖领域的数据问题及争议进行裁决，公司有权对不遵从信息架构或存在严重数据质量问题的责任人进行问责。
    • 原则二：从企业视角定义信息架构
      • 任何一个数据Owner都不只代表自己所辖业务范围的数据管理诉求，而是代表公司对数据进行管理。 华为在数据治理实践中，为了拉通各部门所产生的数据结构和流转路径，实现数据在企业内共享和流通的目标，明确要求： 各业务领域都需站在企业的视角定义信息架构，充分考虑数据的应用场景、范围和用户群体，参考业界实践和主流软件包，平衡和兼顾AS-IS（现状）和TO-BE（未来）诉求，在流程设计和IT实现中得到落实。 以前面的合同编号为例，销售部门作为数据Owner有责任定义合同 信息架构，但不应只考虑销售环节对合同编号的管理诉求，而是应该综合考虑供应、交付、财经等各个环节对合同的诉求，合同在整个交易链条中延伸的范围就是相应数据Owner所综合覆盖的范围。在这个链条中，任何业务部门对合同编号的诉求，都可以提交给数据Owner；同 时，合同数据Owner对所辖数据在整个企业范围内的架构的合理性和一 致性负责，如果某个业务环节私自定义了合同信息架构，那么数据 Owner有责任对该架构进行统一和整改。
    • 原则三：遵从公司的数据分类管理框架
      • 为了协同企业内各业务领域的数据治理，华为在实践中总结了各 类数据的内在特性，制定了统一的数据分类管理框架，公司所有业务 领域按照统一的分类框架进行数据治理。
    • 原则四：业务对象结构化、数字化
      • 华为在长期的数据治理过程中，制定了业务对象结构化、数字化 的架构设计原则，实现数据处理效率的提升，构建数据的处理和应用能力，支撑业务管理。 业务对象内容包括业务结果、业务规则、业务过程，并应打造相 应的数字化能力。
    • 原则五：数据服务化，同源共享
      • 随着企业业务规模的不断扩大，往往会随之产生大量的IT系统， 这样很容易出现数据多源头的情况，导致数据不可信、不可管。 为了有效地避免这些问题，华为制定了数据同源共享的架构原则，每一个数据有且只有单一数据源，数据使用方应从数据源获取数据，数据更改应在数据源进行。 为了克服企业业务和IT的复杂性这一客观现实，华为公司持续推进数据服务建设， 要求各数据Owner通过数据服务向各业务环节提供数据， 各业务环节也有责任通过服务来合理获取数据， 从而在整个企业层面实现数据的“一点定义、全局共享”。
  • 信息架构建设核心要素：基于业务对象进行设计和落地
    • 按业务对象进行架构设计
      • 规则： 在进行信息架构设计时， 架构师、业务代表、数据Owner通常会对业务对象的判定存在理解上的偏差， 从而产生争议。 数据治理部门需要制定一套确定性的规则，通过确定性的规则促进形成稳定的架构。 华为通过以下四条原则来判定业务对象。 概念： 业务对象是指业务领域中重要的人、事、物对象。 业务对象承载了业务运作和管理涉及的重要信息，是信息架构中最重要的管理要素。 业务对象同时还是业务和IT的关键连接点， 也是实现IA（信息架构）、BA（业务架构）、AA（应用架构）、TA（技术架构）集成的关 键要素。 示例： 以一个简化的交易场景为例（如图4-4所示），要完成一个交易， 实现商业价值的兑现，企业内的某个子公司，需要与法人客户签订客 户合同，在客户合同中，要明确交易的产品。在这个场景中，子公 司、法人客户、客户合同、产品是企业需要管理和控制的核心对象，要作为业务对象进行管理。 
      • 原则一：业务对象是指企业运作和管理中不可缺少的重要 人、事、物
        • 企业在设计业务对象时，围绕支持企业运作和管理的重要的人、 事、物去识别。 通常，一个业务对象会有相应的管理流程、管理组织，以及支持运作的IT系统。 比如“客户”这个对象，企业通常会建立类似客户管理部这样的组织，会采购或者开发CRM客户管理系统来支撑客户管理，会建立客户信息管理的一系列流程和规范来确保客户信 息的准确、合理、合规。 为了避免管理上的冲突，业务对象通常在企业内只能有一个唯一的数据Owner，由数据Owner制定相关的架构、标准和管理规则，用于监控和提升数据质量。
      • 原则二：业务对象有唯一身份标识信息
        • 企业要对业务对象进行管理，需要对所有业务对象的实例进行编码，确保每个对象的实例在企业范围内都有唯一的标识。 比如员工，企业需要为每个员工分配一个唯一的工号，如果工号出现重复，则可 能引起管理上的混乱，比如工资错发，任务指令接收不到等。 又比如产品，企业需要给每一种产品分配精确的分类编号，确保在研发组织内部、制造工厂、物流运输、销售回款各个部门和阶段，相同的产品 使用唯一相同的编号，不同的产品绝不出现相同编号。 企业的研发、生产、销售、核算各环节均采用产品的唯一编码进行标识和处理。
      • 原则三：业务对象相对独立并有属性描述
        • 业务对象需要通过大量属性来描述其各个方面的性质和特征，因此属性必定依附于某个业务对象而不可独立存在。 比如“名称”是个属性，单纯地记录“名称”这个属性，无任何业务含义， 因为“客户”有“名称”属性，“供应商”也有“名称”属性，“员工”也有“名称”属性。 业务对象可以独立地存储、传输、使用，业务对象之间可以有关联、依赖关系，但不应有包含或从属关系。 以“销售订单”为例（如图4-5所示），“销售订单”通常包含两个方面的信息。 一方面是销售订单中所销售产品的公共信息，比如归属的订单编号、订单名称、订单总价等，这类信息集中起来形成一个 叫“订单头”的逻辑数据实体。 另一方面是销售订单中某个产品的个性化信息，一个销售订单通常会销售多种产品，每种产品的价格和数量可能不一样，这些信息需要用另一个逻辑数据实体来记录，并用一 个“订单编码”属性来表示这些明细的销售产品归属于该销售订单里，同时不同产品按不同“订单行号”展示。 而“订单行号”是无法独立存在的，企业能够确保所有“订单编码”不会重复，但无法确保所有“订单行号”不会重复，并且这也没有必要，因为任何订单行都是隶属于某个订单的。 因此从这个例子可以看出，订单行是无法作为一个独立的业务对象而存在的，必须归属于“销售订单”这个业务对象。 
      • 原则四：业务对象可实例化
        • 在现实世界中，业务对象有大量的实例存在，并可感知、可获取。 以员工为例，就算是规模很小的企业，通常至少会有经理、业务员、会计等不同岗位的人员，每个员工的信息都可以视为一个实例； 而“员工入职类型”是对员工入职信息的一种分类，其本身是无法实例化的，因此“员工入职类型”这一基础数据应从属于员工业务对象下，而不能独立存在，员工业务对象Owner也应该同时负责“员工入职 类型”数据的生命周期管理。
    • 按业务对象进行架构落地
      • 通过：一体化建模管理 达到：1 概念模型与逻辑模型的一致性，主要通过逻辑数据实体的设计 管理来实现； 2 逻辑模型与物理模型的一致性 阐述： 信息架构向IT侧落地的主要交付件是数据模型。 数据模型本身有相对比较成熟的方法体系支撑，不同企业之间可能名称存在差异，但本质差别不大。 华为公司将数据模型分为三层：概念数据模型、逻辑 数据模型、物理数据模型，如图4-6所示  概念数据模型是通过业务对象及业务对象之间的关系，从宏观角度分析和设计的企业核心数据结构。 逻辑数据模型是利用逻辑数据实体及实体之间的关系，准确描述业务规则的逻辑实体关系。 物理数据模型是按照一定规则和方法，将逻辑数据模型中定义的逻辑数据实体、属性、属性约束、关系等内容，如实转换为数据库软件能识别的物理数据实体关系。
      • 1. 逻辑数据实体设计
        • 逻辑数据实体本质上是对描述业务对象的众多属性的归类， 业务对象无法直接指导IT系统的物理实现，也无法基于业务对象来审视物理设计是否满足业务需求， 因此需要通过逻辑数据实体及相应的逻辑数据模型来指导IT系统层面的数据设计。 在设计逻辑数据实体时，可参考如下几条主要规则。
        • 1）逻辑数据实体不能脱离业务对象独立存在，因此某个逻辑数据实体一定是用来描述一个特定的业务对象的，业务对象与逻辑数据实 体的关系是一对一或一对多，不允许多对一的情况出现。
        • 2）描述业务对象不同业务特征的密切相关的一组属性集合，可以设计为一个逻辑数据实体。
        • 3）逻辑数据实体设计要遵循第三范式。 在设计一个业务对象的逻辑数据实体时，每个逻辑数据实体的属性不要重复定义，不应包含其他逻辑数据实体中的非关键字类型的属性。
        • 4）提供数据服务或跨业务领域使用的基础数据，要单独设计逻辑数据实体。 描述业务对象的若干属性，如果能够组合起来形成独特价值的数据服务，满足下游的数据消费需求，可以设计成一个逻辑数据 实体。
        • 5）两个业务对象间的关系也可以设计成关系型逻辑数据实体，在数据资产目录中，可按业务发生的时间先后顺序，归属于后出现的业务对象。
      • 2. 一体化建模管理
        • 华为公司过去长期存在信息架构与IT开发实施“两张皮”的现象，数据人员和IT开发实施人员缺乏统一和协同，数据架构遵从无法进行实质、有效管理，信息架构资产和产品实现的物理表割裂、不匹配，同时各种数据模型资产缺失。 
        • 仅确保了元数据验证、发布和注册的一致性 =>构建数据标准池，实体属性只能从数据标准池选择；
        • 实现了产品数据模型管理和资产可视。 =>产品元数据和数据库自动比对和验证
        • 由于促成了产品元数据的持续运营，进而能够持续对物理模型进行规范，如整改、清理各类作废表等 =>产品元数据发布认证和信息资产打通
        • 产品逻辑模型和物理模型一体化设计，元数据管理和数据模型管理融合 =>基于交易侧产品元数据自助入湖
  • 传统信息架构向业务数字化扩展： 对象、过程、规则
    • 1）大量业务和作业所产生的数据并没有完整地被管理 =>对象数字化
      • 对策： 对象数字化的目标是建立对象本体在数字世界的映射。这种映射不是传统意义上基于流程要求的少量数据的管理，而是管理某个对象的全量数据  以产品研发和设计为例，信息架构过去只管理产品数据进入ERP管 道所必需的少量内容，如产品编码、描述、BOM清单等，而基于对象数 字化则需要建立完整的数字孪生（Digital Twin），也要管理与之相 应的完整信息架构。过去，供应部门经常抱怨产品研发部门所提供的 “重量”“体积”信息不准确，而研发部门又没有足够的人力在产品 进入生产环节前精准测量每个产品、部件、元器件。但是，实际上研 发在设计过程中会多次产生并使用这些重量和体积信息，因为这对研 发设计也同样重要。在推行对象数字化后，就可以通过数据感知等手 段在设计的各个环节记录上述这些数据，并按项目编码进行更新，这 样就可以向供应环节提供准确并且全量的数据。 问题： 很多情况下，并不是所有业务和作业所产生的数据都在系统中承载，因为大量IT系统中已经承载的数据，往往都是为了满足流程的标 准化需要而存在的。 例如，每个与客户签订的合同都非常复杂，包括诸多的条款，华为公司签订的合同通常会有上百页内容，但信息架构 往往只定义了数百个数据属性，IT系统中也只承载了这部分内容，而大量的数据是以文档的形式存在的。当要对某个合同进行签订前的评审时，如果想基于过去已签订的合同的条款进行基线参考和验证，那么是无法通过自动化手段高效实现的，只能通过人工翻阅历史合同来实现，完整性和准确性都无法保障，而且效率很低。
    • 2）大量业务过程没有形成可视、可管理的数据 =>过程数字化
      • 对策： 仅仅管理好结果还不够，有时我们需要把作业过程记录下来，了解过程进度或者反过来改进结果。 这种记录首先是不干预业务活动的，并且能够自动记录（例如，车辆行驶中自动监控是否存在交通违 规）。 过程数字化要实现业务活动线上化，并记录业务活动的执行或操 作轨迹，一般通过观测数据来实现轨迹记录，如图4-9所示。  以前面举过的物流场景为例，华为公司通过推进业务过程数字化，实现供应链对各类物流状态的实时感知和可视，大幅缩减了发货后反复人工沟通的成本。 问题： 业务在执行某个具体活动时是有大量作业过程的，但这部分数据往往并没有得到管理。例如，过去只记录了物流各个节点的实际到达信息，但缺乏过程信息记录，假如想实时了解具体的物流状态，只能 通过电话、邮件一次次询问，增加大量沟通成本，并且信息的及时性也得不到保障。
    • 3）大量业务规则缺乏管理、无法灵活使用 =>规则数字化
      • 对策： 规则数字化的目的是把复杂场景下的复杂规则用数字化手段进行管理。良好的规则数字化管理，应该能实现业务规则与IT应用解耦，所有关键业务规则数据要实现可配置，能够根据业务的变化灵活调 整，如图4-10所示。  同样以物流场景为例，通常业务希望基于计划对各个环节的物流 任务进行监控和预警，这需要大量的预警规则。例如，某个部件的物流周期是1周，当5天后要交付而对应物流还未发货，则应该预警。但 是，不同物料、不同场景、不同国家的供应能力往往是有差异的，并且随着环境经常动态变化，这就需要将对应的规则数据从IT应用中解 耦出来，单独定义这类数据资产的信息架构，从而使之能够灵活调整。这样，不同国家的业务人员就可以根据需要随时调整规则，而不用对现有IT系统进行大的改动，最大程度地满足业务灵活性的要求。
  • 第四章小结
    • 在企业数字化转型过程中，企业信息架构的定位、内涵和管理方式都在不断地演进。 信息架构的定位发生了根本性的变化，不再是对准IT功能或实现，而是对准整个企业的业务管理目标； 信息架构的内 涵也进行了极大的扩展，不再只是聚焦于进入类似ERP系统的结构化数 据， 而是对准整个企业在业务中产生的各种结构化数据、非结构化数据、内外部数据、过程类数据、规则类数据、IoT数据等； 信息架构的管理方式也发生了颠覆性的改变，不再是抽象化的、预先定义好的、 一次定义覆盖所有场景的标准，而是全量的、实时产生的、满足差异化要求的，甚至是随需定义的标准。 在这样的背景下，需要对原有信息架构框架和方法论不断进行审 视和优化，可能两年前刚刚确定的框架已经不能满足要求，甚至一年前发布的架构规则就要重新修订。 在企业实现数字化转型的过程中， 信息架构管理的结构、技术、组件、标准可能永远不会稳定，永远在进化
• 五、 面向“联接共享”的 数据底座建设
  • 在从信息化向数字化转型的过程中，企业积累了海量的数据，并且还在爆发式地增长。数据很多，但真正能产生价值的数据却很少。 数据普遍存在分散、不拉通的问题，缺乏统一的定义和架构，找到想 要的、能用的数据越来越难。 本章将讲述华为数据底座的总体架构和建设策略，详细说明华为如何通过数据湖和数据主题联接的建设，实现数据的汇聚和联接，打破数据孤岛和垄断，重建数据获取方式和次序。数据底座在华为数字 化转型中起着关键作用
  • 支撑非数字原生企业数字化转型的数据底座建设框架
    • 华为通过建设数据底座，将公司内外部的数据汇聚在一起，对数据进行重新组织和联接，让数据有清晰的定义和统一的结构，并在尊 重数据安全与隐私的前提下，让数据更易获取，最终打破数据孤岛和 垄断。通过数据底座，主要可以实现如下目标。 1）统一管理结构化、非结构化数据。将数据视为资产，能够追溯 数据的产生者、业务源头以及数据的需求方和消费者等。 2）打通数据供应通道，为数据消费提供丰富的数据原材料、半成 品以及成品，满足公司自助分析、数字化运营等不同场景的数据消费 需求。 3）确保公司数据完整、一致、共享。监控数据全链路下的各个环 节的数据情况，从底层数据存储的角度，诊断数据冗余、重复以及 “僵尸”问题，降低数据维护和使用成本。 4）保障数据安全可控。基于数据安全管理策略，利用数据权限控 制，通过数据服务封装等技术手段，实现对涉密数据和隐私数据的合 法、合规地消费。
    • 数据底座的总体架构
      • 华为数据底座由数据湖、数据主题联接两层组成，将公司内外部 的数据汇聚到一起，并对数据进行重新的组织和联接，为业务可视 化、分析、决策等提供数据服务，如图5-1所示 
      • 数据湖
        • 数据湖是逻辑上各种原始数据的集合，除了“原始”这一特征 外，还具有“海量”和“多样”（包含结构化、非结构化数据）的特 征。数据湖保留数据的原格式，原则上不对数据进行清洗、加工，但 对于数据资产多源异构的场景需要整合处理，并进行数据资产注册。 数据入湖必须要遵循6项标准，共同满足数据联接和用户数据消费 需求。
      • 数据主题
        • 数据主题联接是对数据湖的数据按业务流/事件、对象/主体进行 联接和规则计算等处理，形成面向数据消费的主题数据，具有多角 度、多层次、多粒度等特征，支撑业务分析、决策与执行。 基于不同 的数据消费诉求，主要有多维模型、图模型、指标、标签、算法模型5 种数据联接方式。
    • 数据底座的建设策略
      • 华为数据底座采取“统筹推动、以用促建、急用先 行”的建设策略
      • 1）数据安全原则
        • 数据底座数据资产应遵循用户权限、数据密级、隐私级别等管理 要求，以确保数据在存储、传输、消费等全过程中的数据安全。技术 手段包括但不限于授权管理、权限控制、数据加密、数据脱敏。
      • 2）需求、规划双轮驱动原则
        • 数据底座数据资产基于业务规划和需求触发双驱动的原则进行建设，对核心数据资产优先建设。
      • 3）数据供应多场景原则
        • 数据底座资产供应需根据业务需求提供离线/实时、物理/虚拟等 不同的数据供应通道，满足不同的数据消费场景。
      • 4）信息架构遵从原则
        • 数据底座数据资产应遵从公司的信息架构，必须经IA-SAG（信息 架构专家组）发布并完成注册。
  • 数据湖：实现企业数据的“逻辑汇聚”
    • 华为数据湖的3个特点
      • 
      • 1）逻辑统一
        • 华为数据湖不是一个单一的物理存储，而是根据数据类型、业务区域等由多个不同的物理存储构成，并通过统一的元数据语义层进行定义、拉通和管理。
      • 2）类型多样
        • 数据湖存放所有不同类型的数据，包括企业内部IT系统产生的结构化数据、业务交易和内部管理的非结构化的文本数据、公司内部园区各种传感器检测到的设备运行数据，以及外部的媒体数据等。
      • 3）原始记录
        • 华为数据湖是对原始数据的汇聚，不对数据做任何的转换、清 洗、加工等处理，保留数据最原始特征，为数据的加工和消费提供丰 富的可能。
    • 数据入湖的6个标准
      • 数据入湖是数据消费的基础，需要严格满足入湖的6项标准，包括明确数据Owner、发布数据标准、定义数据密级、明确数据源、数据质量评估、元数据注册。通过这6项标准保证入湖的数据都有明确的业务责任人，各项数据都可理解，同时都能在相应的信息安全保障下进行消费。
      • （1）明确数据Owner
        • 数据Owner由数据产生对应的流程Owner担任，是所辖数据端到端管理的责任人，负责对入湖的数据定义数据标准和密级，承接数据消费中的数据质量问题，并制定数据管理工作路标，持续提升数据质量
      • （2）发布数据标准
        • 入湖数据要有相应的业务数据标准。业务数据标准描述公司层面需共同遵守的“属性层”数据的含义和业务规则，是公司层面对某个数据的共同理解，这些理解一旦明确并发布，就需要作为标准在企业 内被共同遵守。数据标准的信息如表5-1所示。 
      • （3）认证数据源
        • 通过认证数据源，能够确保数据从正确的数据源头入湖。认证数据源应遵循公司数据源管理的要求，一般数据源是指业务上首次正式发布某项数据的应用系统，并经过数据管理专业组织认证。认证过的数据源作为唯一数据源头被数据湖调用。当承载数据源的应用系统出 现合并、分拆、下线情况时，应及时对数据源进行失效处理，并启动新数据源认证。
      • （4）定义数据密级
        • 定义数据密级是数据入湖的必要条件，为了确保数据湖中的数据能充分地共享，同时又不发生信息安全问题，入湖的数据必须要定 密。数据定密的责任主体是数据Owner，数据管家有责任审视入湖数据密级的完整性，并推动、协调数据定密工作。 数据定级密度在属性层 级，根据资产的重要程度，定义不同等级。不同密级的数据有相应的数据消费要求，为了促进公司数据的消费，数据湖中的数据有相应的降密机制，到降密期或满足降密条件的数据应及时降密，并刷新密级 信息。
      • （5）数据质量评估
        • 数据质量是数据消费结果的保证，数据入湖不需要对数据进行清洗，但需要对数据质量进行评估，让数据的消费人员了解数据的质量情况，并了解消费该数据的质量风险。 同时数据Owner和数据管家可以根据数据质量评估的情况，推动源头数据质量的提升，满足数据质量的消费要求。
      • （6）元数据注册
        • 元数据注册是指将入湖数据的业务元数据和技术元数据进行关联，包括逻辑实体与物理表的对应关系，以及业务属性和表字段的对应关系。通过联接业务元数据和技术元数据的关系，能够支撑数据消 费人员通过业务语义快速地搜索到数据湖中的数据，降低数据湖中数 据消费的门槛，能让更多的业务分析人员理解和消费数据。
    • 数据入湖方式
      • 数据入湖遵循华为信息架构，以逻辑数据实体为粒度入湖，逻辑 数据实体在首次入湖时应该考虑信息的完整性。原则上，一个逻辑数据实体的所有属性应该一次性进湖，避免一个逻辑实体多次入湖，增加入湖工作量。 数据入湖的方式主要有物理入湖和虚拟入湖两种，根据数据消费的场景和需求，一个逻辑实体可以有不同的入湖方式。两种入湖方式相互协同，共同满足数据联接和用户数据消费的需求，数据管家有责任根据消费场景的不同，提供相应方式的入湖数据。 物理入湖是指将原始数据复制到数据湖中，包括批量处理、数据复制同步、消息和流集成等方式。 虚拟入湖是指原始数据不在数据湖中进行物理存储，而是通过建立对应虚拟表的集成方式实现入湖，实时性强，一般面向小数据量应用，大批量的数据操作可能会影响源系统。  
      • 批量集成（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-3所示）。 
      • 1. 数据入湖需求分析及管理
      • 2. 检查数据入湖条件和评估入湖标准
        • （1）检查数据源准备度
          • 数据有源是数据入湖的基本前提，数据源准备度检查不仅需要源系统的IT团队提供源系统的数据字典和数据模型并检查源系统的物理表规范度，而且需要数据代表评估源系统的数据质量。
        • （2）评估入湖标准
          • 如果不满足任意一条入湖标准，就应推动源系统数据代表完 成整改，满足要求后方可实施数据入湖。
          • 明确数据Owner：
            • 为保证入湖数据的管理责任清晰，在数据入湖前 应明确数据Owner。
          • 发布数据标准：
            • 入湖数据应有数据标准，数据标准定义了数据属 性的业务含义、业务规则等，是正确理解和使用数据的重要依 据，也是业务元数据的重要组成部分。
          • 认证数据源：
            • 原则上以初始源进湖，数据源认证是保证数据湖数 据一致性和唯一性的重要措施。
          • 定义数据密级：
            • 定义完整、明确的数据密级是数据湖数据共享、 权限控制等的关键依据。信息安全管理专员向业务Owner提出定密 需求，并与业务Owner确定定密规则，确定数据密级、定密时间、 降密期/降密条件等，然后由信息安全管理专员在信息架构管理平 台注册密级信息。
          • 评估入湖数据质量：
            • 对入湖数据做质量评估，给入湖数据打质量 标签
      • 3. 实施数据入湖
        • 数据代表依据消费场景合理选择入湖方式，在不要求历史数据、 小批量数据且实时性要求高的场景，建议虚拟入湖；在要求历史数据、大批量数据且实时性要求不高的场景，可以物理入湖。 虚拟入湖由数据代表实施，数据代表负责设计和部署虚拟表。 物理入湖由对应数据湖的IT代表承接IT实施需求，设计集成方案和数据质量监测方案，实施数据入湖。数据代表组织UAT测试、上线验 证。
      • 4. 注册元数据
        • 元数据是公司的重要资产，是数据共享和消费的前提，为数据导航和数据地图建设提供关键输入。对元数据进行有效注册是实现上述目的的前提。 虚拟表部署完成后或IT实施完成后，由数据代表检查并注册元数据，元数据注册应遵循企业元数据注册规范。
    • 非结构化数据入湖
      • 1. 非结构化数据管理的范围
      • 2. 非结构化数据入湖的4种方式
        • 1）基本特征元数据入湖
        • 2）文件解析内容入湖
        • 3）文件关系入湖
        • 4）原始文件入湖
  • 数据主题联接：将数据转换为“信息”
    • 5类数据主题联接的应用场景
      • 
      • 多维模型是面向业务的多视角、多维度的分析，通过明确的业务 关系，建立基于事实表、维度表以及相互间联接关系，实现多维数据 查询和分析。例如，对订货数据从时间、区域、产品、客户等维度进 行多视角、不同粒度的查询和分析。
      • 图模型面向数据间的关联影响分析，通过建立数据对象以及数据 实例之间的关系，帮助业务快速定位关联影响。例如，查看某国家原 产地的项目的数据具体关联到哪个客户以及合同、订单、产品的详细 信息时，可以通过图模型快速分析关联影响，支撑业务决策。
      • 标签是对特定业务范围的圈定。在业务场景的上下文背景中，运 用抽象、归纳、推理等算法计算并生成目标对象特征的表示符号，是 用户主观观察、认识和描述对象的一个角度。例如，对用户进行画 像，识别不同的用户群，为产品设计和营销提供策略支持。
      • 指标是对业务结果、效率和质量的度量。依据明确的业务规则， 通过数据计算得到衡量目标总体特征的统计数值，能客观表征企业某 一业务活动中业务状况。例如，促销员门店覆盖率指标就是衡量一线 销售门店促销员的覆盖程度
      • 算法模型是面向智能分析的场景，通过数学建模对现实世界进行 抽象、模拟和仿真，提供支撑业务判断和决策的高级分析方法。例 如，预测未来18个月的销售量，需要数据科学家根据数据湖中的历史 订单、发货等数据通过决策树和基因算法进行数据建模，支持业务决 策。
    • 多维模型设计
      • 是面向业务的多视角、多维度的分析，通过明确的业务关系，建立基于事实表、维度表以及相互间联接关系，实现多维数据查询和分析。例如，对订货数据从时间、区域、产品、客户等维度进 行多视角、不同粒度的查询和分析。 多维模型是依据明确的业务关系，建立基于维度、事实表以及相 互间连接关系的模型，实现多角度、多层次的数据查询和分析。 如何设计出稳定、易扩展、高可用的数据模型来支持用户消费对数据主题联接至关重要。
      • （1）确定业务场景
        • 分析业务需求，识别需求中所涉及的业务流及其对应的逻辑数据实体和关联关系。 如业务负责人（PO）履行全流程可视，首先需要识别监控的具体业务环节（如发货、开票等），再根据这些业务环节识 别其对应的逻辑数据实体及关联关系，如图5-7所示 
      • （2）声明粒度
        • 粒度表示数据单元的细节程度或综合程度，细节程度越高，粒度越细；细节程度越低，粒度越粗。 声明粒度是维度和事实表设计的重要步骤，声明粒度意味着精确定义事实表的每一行表示什么。 针对监控PO履行这个场景，在做设计时首先要确认是监控PO的履行，还是具体到每个PO行的履行，不同的粒度会对应不同的事实表。
      • （3）维度设计
        • 维度是用于观察和分析业务数据的视角，支持对数据进行汇聚、 钻取、切片分析，如图5-8所示。 维度由层次结构（关系）、层级、成员、属性组成。 维度可以分为基础树和组合树，维度基础树提供统一定义的、完整的层级结构和成员；维度组合树根据业务使用场景进行定制。 
        • 单一性
          • 有且仅有一个视角，在同一个维度中不能穿插其他经营分析的视 角，例如，区域维不含客户视角，产品维不含客户视角等。图5-9中区 域维度客户视角不满足单一性要求。 
        • 单向性
          • “上大下小”，维度只能支撑自上而下的分解和自下而上的收 敛，每个成员只能存在向上的收敛路径，不能具备向上和向下两个方 向的收敛逻辑。图5-10中代表处维度低于国家维度，不满足单向性要 求。 
        • 正交性
          • 成员两两不相交，同一成员不能同时拥有多个上级成员，以产品 维为例，华为向客户提供的设备或服务都只能被准确地分配到唯一叶 子（最底层）节点，并以此路径进行收敛。图5-11中最小粒度成员 “无线专业服务”同时归属不同的上层节点，不满足正交性要求。 
      • （4）事实表设计
        • 事实表存储业务过程事件的性能度量结果，由粒度属性、维度属 性、事实属性和其他描述属性组成，  粒度属性是事实表的主键，通常由原始数据的主键或一组维度属 性生成。
        • 粒度属性
          • 粒度属性是事实表的主键，通常由原始数据的主键或一组维度属 性生成。
        • 维度属性
          • 维度属性是从维度中继承的属性，可以只继承主键作为事实表的 外键，也可以继承维度中全部或其他部分的属性。在上述例子中，事 实表中除了有币种ID，还可以带有币种编码和币种名称等属性。
        • 事实属性
          • 事实属性是可以对该颗粒度的事实进行定量的属性，大多数的事 实表包括一个或多个事实字段。
          • 同一事实表中不能存在多种不同粒度的事实，比如PO行明细事实 表中不应该包含PO总金额，否则PO总金额累加时会出现错误。
          • 对于不可相加的事实，需要分解为可加的事实。比如比率，需要 分解为分子和分母。
          • 事实的数值单位要保持一致。
          • 尽可能包含所有与业务过程相关的事实，不包含与业务过程无关 的事实，比如在设计“订单下单”这个业务过程的事实表时，不 应该存在“支付金额”这个支付业务过程的事实。‘
        • 其他属性
          • 其他属性主要包括创建人、创建时间、最后修改人、最后修改时 间等审计字段
    • 图模型设计
      • 图模型面向数据间的关联影响分析，通过建立数据对象以及数据实例之间的关系，帮助业务快速定位关联影响。 例如，查看某国家原产地的项目的数据具体关联到哪个客户以及合同、订单、产品的详细 信息时，可以通过图模型快速分析关联影响，支撑业务决策。 图模型作为当前流行的信息处理加工技术，自提出以来，迅速在学术界和工业界得到了普及，在智能推荐、决策分析等方面有着广泛的应用。 图模型由节点和边组成。节点表示实体或概念，边则由属性或关系构成。 实体指的是具有可区别性且独立存在的某种事物，如某一个人、某一个城市、某一种植物、某一种商品等，是图模型中的最基本元素； 概念是对特征的组合而形成的知识单元，主要指集合、类别、 对象类型、事物的种类，例如人物、地理等； 属性主要指描述实体或 概念的特征或特性，例如人员的国籍、生日等。我们以“哲学家”为 例设计图模型，如图5-13所示。  
      • 业务场景定义
        • 业务场景决定信息涵盖范围，以及信息颗粒度的表示。 以支撑业务连续性为例，因为不可抗力的影响，部分区域的供应商工厂无法正常生产和发货，涉及的信息包括供应商的信息、产能、元器件及内部 物料、合同和客户信息，要求能够根据用户输入的当前物料储备和合 同状态，获取影响内部物料、产品、合同交付和客户的清单和范围。 这种应用涉及对产品目录和配置的解读，需要对收集的信息进行最小采购器件的抽取。 信息颗粒度在图模型建设中是个不可忽视的问题，根据应用场景决定信息颗粒度以及图模型的精确性与有效性。 比如手机，有品牌、 型号、批次，直至手机整机。同样的信息范围，颗粒度越细，图模型应用越广泛，关系越丰富，但冗余越多，知识消费越低效。 信息颗粒度的原则是“能满足业务应用的最粗颗粒度”。
      • 信息收集
        • 与应用场景直接相关的信息。 例如，判断不可抗力供应中断影响的范围，直接相关的信息有物料信息、产品配置、合同信息等。
        • 与应用场景间接相关，但可辅助理解问题的信息。 这包括企业 信息、专业领域信息、行业信息以及开放域信息。
      • 图建模
        • 相同的数据可以有若干种模式的定义，良好的模式可以减少数据冗余，提高实体识别的准确率，在建模的过程中，要结合数据特点与应用场景来完成。 同样的数据从不同的视角可以得出不同的图模型。
      • 实体、概念、属性、关系的标注
        • 企业图模型中涉及的实体和概念可分为三类： 公共类:如人名、 机构名、地名、公司名、时间等； 企业类:如业务术语、企业部门 等； 行业类:如金融行业、通信行业等。
      • 实体和概念的识别
        • 企业图模型中实体、概念的识别可将业务输入与数据资产中已有的信息作为种子，运用命名实体识别（NER）的方法扩展出新实体概念，经业务确认后，列入实体、概念库。
      • 属性识别与关系识别
        • 企业图模型中的属性与关系一般是根据业务知识在模式层设计时定义，属性与关系相对稳定，其扩展场景不是很多。
        • 定义属性与关系
          • 企业图模型中的属性与关系一般是根据业务知识在模式层设计时定义，属性与关系相对稳定，其扩展场景不是很多。
        • 存储技术
          • 企业图模型的存储技术要综合考虑应用场景、图模型中节点和联接的数量、逻辑的复杂度、属性的复杂度，以及性能要求。 一般建议采用混合存储方式，用图数据库存储关系，关系型数据库或键值对存储属性。 偏重逻辑推理的应用场景用RDF的存储方式，偏重图计算的应用场景选择属性图的存储方式。 发挥两类数据存储和读写的各自优势。
        • 知识计算
          • 知识计算主要是根据图谱提供的信息得到更多隐含的知识，如通 过模式层以及规则推理技术可以获取数据中存在的隐含信息。 知识计算涉及三大关键技术：图挖掘计算、基于本体的推理、基于规则的推理。 图挖掘计算是基于图论的相关算法，实现对图谱的探索和挖掘。 图挖掘计算主要分为如下6类。 
          • 图遍历：知识图谱构建完之后可以理解为是一张很大的图，可以 去查询和遍历这个图，要根据图的特点和应用场景进行遍历。
          • 图里面经典的算法，如最短路径。
          • 路径的探寻，即根据给定两个实体或多个实体去发现它们之间的 关系。
          • 权威节点的分析，这在社交网络分析中使用较多。
          • 族群分析。
          • 相似节点的发现。
        • 在企业中的价值
          • 图挖掘计算在当前的应用场景中，基于业务连续性，通过查询遍 历图模型，识别影响节点和影响范围，基于最短路径，辅助决策物流线路，在企业中的应用较为普遍。 很大程度上取决于企业基于对象节点可以构建多完善的关系，这个关系的构建是一个逐步完善的过程，基于业务场景不断补充和完善关系，这就是图模型的优势。当形成一个足 够完善的企业级图模型后，领域分段的业务场景应用只需要裁剪部分节点和关系，就可以满足业务的需求，达到快速响应业务需求、降低开发成本的目的。
    • 标签设计
      • 标签是对特定业务范围的圈定。 在业务场景的上下文背景中，运用抽象、归纳、推理等算法计算并生成目标对象特征的表示符号，是用户主观观察、认识和描述对象的一个角度。 例如，对用户进行画像，识别不同的用户群，为产品设计和营销提供策略支持。 标签是根据业务场景的需求，通过对目标对象（含静态、动态特性）运用抽象、归纳、推理等算法得到的高度精练的特征标识，用于差异化管理与决策。 标签由标签和标签值组成，打在目标对象上，如 图5-16所示。 标签由互联网领域逐步推广到其他领域，打标签的对象也由用户、产品等扩展到渠道、营销活动等。 在互联网领域，标签有助于实现精准营销、定向推送、提升用户差异化体验等； 在行业领域，标签更多助力于战略分级、智能搜索、优化运营、精准营销、优化服务、 智慧经营等。 
      • 标签类别：事实标签、规则标签、模型标签
        • 事实标签是描述实体的客观事实，关注实体的属性特征，如一个部件是采购件还是非采购件，一名员工是男性还是女性等，标签来源 于实体的属性，是客观和静态的； 规则标签是对数据加工处理后的标签，是属性与度量结合的统计结果，如货物是否是超重货物，产品是否是热销产品等，标签是通过属性结合一些判断规则生成的，是相对客观和静态的； 模型标签则是洞察业务价值导向的不同特征，是对于实体的评估和预测，如消费者的换机消费潜力是旺盛、普通还是低等，标签是通过属性结合算法生成的，是主观和动态的。
      • 标签管理
        • 标签体系建设
          • （1）选定目标对象，根据业务需求确定标签所打的业务对象， 业务对象范围参考公司发布的信息架构中的业务对象。
          • （2）根据标签的复杂程度进行标签层级设计。
          • （3）进行详细的标签和标签值设计， 包括标签定义、适用范围、 标签的生成逻辑等：
            • 事实标签应与业务对象中的属性和属性值保持一致，不允许新增和修改；
            • 规则标签按照业务部门的规则进行相关设计；
            • 模型标签根据算法模型生成。
        • 打标签
          • （1）打标签数据存储结构
            • 打标签是建立标签值与实例数据的关系， 可以对一个业务对象、 一个逻辑数据实体、一个物理表或一条记录打标签。 为了方便从“用户”视角查找、关联、消费标签， 可增加用户表，将标签归属到该“用户”下， 这里的“用户”是泛指，可以是具体的人，也可以是一个组织、一个部门、一个项目等。
          • （2）打标签的实现方法
            • 事实标签：根据标签值和属性允许值的关系由系统自动打标签。 规则标签：设计打标签逻辑由系统自动打标签。 模型标签：设计打标签算法模型由系统自动打标签。
    • 指标设计
      • 指标是对业务结果、效率和质量的度量。 依据明确的业务规则， 通过数据计算得到衡量目标总体特征的统计数值，能客观表征企业某 一业务活动中业务状况。例如，促销员门店覆盖率指标就是衡量一线 销售门店促销员的覆盖程度 指标是衡量目标总体特征的统计数值，是能表征企业某一业务活动中业务状况的数值指示器。
      • 指标一般由指标名称和指标数值两部分组成， 指标名称及其含义体现了指标在质的规定性和量的规定性两个 方面的特点； 指标数值反映了指标在具体时间、地点、条件下的数量 表现。
      • 根据指标计算逻辑是否含有叠加公式，可以把指标分为原子指标 和复合指标两种类型。 原子指标是指标数据通过添加口径/修饰词、维度卷积而成，口径/修饰词、维度均来源于指标数据中的属性。 复合指标由一个或多个原子指标叠加计算而成，其中维度、口径/ 修饰词均继承于原子指标，不能脱离原子指标维度和口径/修饰词的范 围去产生新的维度和口径/修饰词。
        • 
        • 指标数据：承载原子指标的数据表，例如门店明细表，其中度量 为门店数量，通过【门店编码】卷积；属性包括门店等级、门店 状态、门店形象等级、组织等级等
        • 维度：从属性中选取组织、渠道、门店形象等级。
        • 口径/修饰词：【门店状态】等于【有效】，【有无促销员】等于 【1】
        • 原子指标：由指标数据通过添加口径/修饰词、维度卷积而成，包 括促销员覆盖门店数量、有效门店数量。
        • 复合指标：由2个或2个以上指标叠加计算而成，包括【促销员门 店覆盖率】=【促销员覆盖门店数量】÷【有效门店数量】。
      • 指标拆解
        • 指标拆解，是将指标对应到数据资产并进行结构化管理，支持指标服务化与自助需求的关键。 
        • 解读指标定义，识别指标
          • 通过与指标定义的业务管理部门沟通 （通常为指标解释部门的业务人员），从业务角度了解指标基本信息、所需统计维度、指标度量场景以及各场景下的计算逻辑和口径（包括剔除规则）、指标发布信息等。
        • 基于指标叠加公式拆解指标
          • 根据指标计算逻辑识别原子指标， 明确原子指标中需要的口径/修饰词、维度信息，以及原子指标与复合指标间的支撑关系。
        • 基于指标拆解结果，识别指标数据
          • 识别原子指标的度量属性和支撑属性，并根据原子指标中的维度、口径修饰词匹配已发布业 务对象的属性，形成指标数据。
        • 数据匹配落地
          • 补充指标、指标数据中的标准属性名称以及对应 的落地物理表，支持用户自助实现指标计算，拉通指标设计和落 地。
    • 算法模型设计
      • 指标是对业务结果、效率和质量的度量。 依据明确的业务规则，通过数据计算得到衡量目标总体特征的统计数值，能客观表征企业某一业务活动中业务状况。 例如，促销员门店覆盖率指标就是衡量一线销售门店促销员的覆盖程度 算法是指训练、学习模型的具体计算方法，也就是如何求解全局 最优解，并使得这个过程高效且准确，其本质上是求数学问题的最优化解，即算法是利用样本数据生成模型的方法。 算法模型是根据业务需求，运用数学方法对数据进行建模，得到业务最优解，主要用于业务智能分析。 算法模型在数据分析流程中产生，算法模型管理框架包括建模、 模型资产管理和模型消费。 公司各领域已相继开发出大量基于算法模型的分析应用，通过对算法模型资产注册逐步打造公司级的算法模型地图。 算法模型的设计步骤主要有需求评估、数据准备、方案设计和建模与验证。
      • （1）需求评估
        • 1）业务驱动的分析需求识别
          • 如果要识别与业务运营优化相关的分析需求，就需要梳理业务需求的背景、现状与目标。 若由战略或变革提出可能的分析需求，则应进行战略目标解耦，识别分析需求，了解业务现状与制定目标。 初步识别分析结果的应用场景。
        • 2）数据驱动的分析需求识别
          • 在集成的数据环境中进行数据挖掘，探索可能的分析应用。 识别分析需求和确认应用领域。 初步识别分析结果的应用场景。
        • 3）价值与可行性评估
          • 确定数据分析主题。 分析需求的业务价值评估，包括业务基线、分析主题的业务影响 与可增进的效益。 分析前提与可行性，包括识别目前业务流程与可能的影响因素， 探讨业务现状因素，并制定对应的分析解決方案，呈现出对应解 决方案可提升的效益，对方案所需资源和数据的可行性进行评 估。 根据相关的历史数据，进行假设和分析，并明确业务范围。
      • （2）数据准备
        • 深入探索数据资产目录，识别与分析主题可能相关的数据。 提供数据源、数据标准、数据流等信息。 收集与整合原始数据，生成分析数据集。 根据分析需求进行数据筛选和质量分析。
      • （3）方案设计
        • 明确要分析的业务目标与相关假设。 定义数据集中的分析目标、样本与筛选条件。 设计所需变量、指标、可能的分析方法和产出。 规划分析的应用场景。
      • （4）建模与验证
        • 1）决定是否需要分析建模：根据技术复杂度、业务效益和资源评 估该分析需求是否需要分析建模。若需要分析建模且通过项目评审， 则应进行高阶分析；若不需要建模分析，则运用BI分析。
        • 2）建模与验证：根据数据分析方案创建模型，对模型的参数和变 量进行调整，根据应用场景选择适用的模型，并与业务分析师确认模型成效与应用，并进行优化，进行模型相关验证（如准确度和稳定度 评估）及效益评估。
        • 3）试算分析：对数据分析方案中不需分析建模的场景和应用，根 据数据分析方案进行分析结果的计算，并选择合适的展示方式。
        • 4）编写数据分析线下验证报告： -记录分析结果与发现。 -根据洞察发现，建议业务应用场景。 -建议模型监测方式。
        • 5）决定是否需要IT开发：根据模型验证成果（分析建模）、预估 业务效益、IT开发所需的成本和资源来评估分析结果是否需要IT开 发。若需要，则通过评审后转入IT开发流程；若不需要，则进入业务 应用并结束流程
        • 6）模型线上验证： 设定线上验证范围与场景。 进行线上验证，制定模型监控机制（含监控频次和监控要素）， 生成分析模型线上验证报告。 进行业务试运行与推广。
        • 7）转运营：与数据分析模型所属领域的业务代表确认转正式运营 计划，启动业务正式运营。
  • 第五章小结 企业数据治理的最终目的是让数据更有效地服务于业务目标，创造价值。 对于数字原生企业而言，原生入口提供的大规模、高质量的 数据，可以快速地封装成企业级的API，满足业务侧的应用。 华为作为非数字原生企业，在实践探索中发现，数字化转型的关键在于打通数 据供应链，通过理解业务、识别数据资产、建设数据架构来推动组织 间的共享和协作，标识安全隐私标签，从源头提升数据质量，并通过数据底座建设构建数据湖和数据主题联接两层，形成数据的逻辑集合，为业务可视化、分析、决策等数据消费提供数据服务，让企业数据成为能为业务带来价值的数据资产
• 六、 面向“自助消费”的 数据服务建设
  • 在供应侧确保用户更便捷、更安全地获取数据。 一方面业务人员希望尽可能快速地获取各种所需的数据， 另一方面要确保数据获取过程中满足安全、合规的要求。 同时，业务人员消费数据时，也希望能够有更加灵活的使用数据、分析数据的方式， 业务人员希望消费数据的自主性更强，并且不能忍受过去冗长、 呆板的报表呈现方式。 在数据供应侧和消费侧的双重推动下，华为公司进行了基于数据服务提供“自助消费”的实践，打造了从数据供应到消费的完整链条。
  • 数据服务：实现数据自助、高效、复用
    • 异常情况： 1.复杂的集成关系导致出现各种数据质量问题； 2.数据“搬家”造成的上千万元的IT 开发费用； 各分析系统对财务数据的使用、再加工、集成的时间差等，造成报告不一致，甚至导致安全审计风险； 3.源头数据出现变化影响整个业务流程上的系统。
    • 什么是数据服务
      • 数据服务是基于数据分发、发布的框架，将数据作为一种服务产品来提供，以满足客户的实时数据需求，它能复用并符合企业和工业标准，兼顾数据共享和安全。 
      • 1. 数据服务给企业带来的价值 
        • 1）保障“数出一孔”，提升数据的一致性。通过服务获取数据的 方式类似于“阅后即焚”，大部分情况下数据并不会在使用方的系统中落地，因此减少了数据“搬家”，而一旦数据的使用方并不拥有数 据，就减少了向下游二次传递所造成的数据不一致问题。
        • 2）数据消费者不用关注技术细节，可以满足不同类型的数据服务 需求。对于数据消费者而言，不用再关心“我要的数据在哪里”，例 如用户不需要知道这些数据来自哪个系统、哪个数据库、哪个物理 表，只需要清楚自身的数据需求，就能找到对应的数据服务，进而获 取数据。
        • 3）提升数据敏捷响应能力。数据服务一旦建设完成，并不需要按 使用者重复构建集成通道，而是通过“订阅”该数据服务快速获取数 据。
        • 4）满足用户灵活多样的消费诉求。数据服务的提供者并不需要关 心用户怎么“消费”数据，避免了供应方持续开发却满足不了消费方 灵活多变的数据使用诉求的问题。
        • 5）兼顾数据安全。所有数据服务的使用都可管理，数据供应方能 够准确、及时地了解“谁”使用了自己的数据，并且可以在数据服务 建设中落实各种安全措施，确保数据使用的合规。
      • 2. 数据服务建设策略 
        • 在企业层面制定统一的数据服务建设策略，并且覆盖全生命周期的各个环节
          • 1）要制定数据服务建设的方法，确保每个从事数据服务建设的人 都明白数据一致性的要求，并且所提供的数据是可信的和清洁的。
          • 2）要建立数据服务流程，以确保各个环节的有效协同，定义整个 生命周期中每个角色的责任和有效输出。在企业中，应该有明确的部 门负责数据服务流程的建设和看护，一方面要确保所制定的流程能够 在实际工作中落地，另一方面随着技术的演进和企业业务环境的变 化，持续对流程进行优化和完善。
          • 3）要构建统一的数据服务能力中心，负责数据服务建设方法、规 范、流程的落地，数据服务不同于传统集成方式，因此应该有统一的 平台提供能力保障。
        • 在数据服务建设中，应该为各个供应方树立统一的标准，并将这些标准以规范的形式进行固化，使所有数据服务建设都遵循同样的标 准。
          • 1）数据服务要满足可重用性、减少数据“搬家” 数据服务在实际或者可预见的时间范围内会被多个需求方消费。 数据服务面向场景进行消费时，无须重复落地
          • 2）服务提供方在规划服务时应明确服务的用户是谁，并针对用户 的场景和需求进行服务设计，同时定义SLA服务水平承诺。 服务要有业务Owner，业务Owner负责组织业务和IT一体化团队， 主动进行服务规划和设计。 服务规划和设计人员在规划和设计任何服务时，都应考虑到服务可能会被重用。 服务规划需考虑价值，并优先对高价值的服务进行投资。 服务消费方应对服务提出改进需求，促进服务能力的持续提升。
          • 3）应用只能通过服务接口向其他应用开放其数据和功能，服务接口要稳定，应用间的通信也必须通过这些服务接口进行。 需要说明的是，应用如果需要向其他应用开放其数据和功能，只 能通过服务接口，服务接口应该易理解、易使用，达到服务市场准入 标准。
          • 4）所有的服务需在统一的服务管控平台中进行注册和发布。 需要说明的是，华为公司的IT服务（HIS）负责提供服务管控平台 的注册和发布功能，通过HIS可查询到发布的所有服务。
          • 5）应根据不同场景选择合适的服务化架构粒度。 需要说明的是，服务化要采用合适的架构粒度，不是越“微”越 好，也不是越“灵活”越好。
    • 数据服务生命周期管理
      • 1. 数据服务的识别与定义
        • 业务与数据握手，识别服务的业务价值、准入条件与服务类型，减少数据服务的重复建设，提升数据服务的重用度。 
        • 1）分析数据服务需求：通过数据需求调研与需求交接，判断数据服务类型（面向系统或面向消费）、数据内容（指标/维度/范围/报表项）、数据源与时效性要求
        • 2）识别可重用性：结合数据需求分析，通过数据服务中心匹配已有的数据服务，判断以哪种方式（新建服务、直接复用、服务变更） 满足业务需求。对于已有数据服务，必须使用服务化方式满足需求， 减少数据“搬家”。
        • 3）判断准入条件：判断服务设计条件是否已具备，包括数据 Owner是否明确、元数据是否定义、业务元数据和技术元数据是否建立 联接、数据是否已入湖等。
        • 4）制定迭代计划：根据数据服务需求制定敏捷交付计划，快速满足数据服务需求。 需求驱动与重复建设的矛盾化解 
          • 因此，以数据服务需求分析为输入，通过服务可重用性判断已有 数据服务对需求的满足情况，给出满足服务需求的策略，并结合准入 条件的关键问题判断服务需求是否能够被快速满足。 分析 在数据服务的识别和定义中，要特别注意数据服务的可重用性。 所有的数据服务都是需求驱动产生的，如果没有需求方，那么这个数据服务就没有存在的价值。但是，重复建设也就成了数据服务建设中最大的风险之一。 数据供应方很容易基于不同的数据消费方开发出不同的数据服务，而他们的数据需求往往是相似的，但数据供应方可能因为响应周期、客户（数据消费方）体验等压力，并没有花费精力去对来自各数据消费方的需求进行筛选和收敛，这就导致所建设的数据服务往往只是满足某个特定客户（数据消费方）的需求。 如果数据服务不具备可重用性，那么它与传统的数据集成的方式相比，就并不具备优越性，有时甚至会导致更大的重复投资。
        • 数据资产的可服务性，通常用于数据服务准入条件的判断，即某个数据资产是否已经具备对外提供服务的条件。
          • 数据Owner是否明确？
          • 数据是否有明确的安全密级定义？
          • 元数据是否定义？
          • 业务元数据和技术元数据是否建立联接？
          • 面向数字化运营分析场景时，数据是否已入湖？
      • 2. 数据服务的设计与实现
        • 业务、数据、IT三方协同，使设计、开发、测试与部署快速迭代以实现服务的敏捷交付，缩短数据服务的建设 周期。
        • 定义服务契约和数据契约
        • 设计服务颗粒度
        • 建议数据服务机制
      • 3. 数据服务的变更与下架
        • 通过统一数据服务中心及服务运营机制，保障服务SLA与持续优化。
    • 数据服务分类与建设规范
    • 打造数据供应的“三个1”
  • 构建以用户体验为核心的数据地图
    • 数据地图的核心价值
    • 数据地图的关键能力
  • 人人都是分析师
    • 从“保姆”模式到“服务+自助”模式
    • 打造业务自助分析的关键能力
  • 从结果管理到过程管理，从能“看”到能“管”
    • 数据赋能业务运营
    • 数据消费典型场景实践
    • 华为数据驱动数字化运营的历程和经验
  • 第六章小结
• 七、 打造“数字孪生”的 数据全量感知能力
  • “全量、无接触”的数据感知能力框架
    • 数据感知能力的需求起源：数字孪生
    • 数据感知能力架构
  • 基于物理世界的“硬感知”能力
    • “硬感知”能力的分类
    • “硬感知”能力在华为的实践
  • 基于数字世界的“软感知”能力
    • “软感知”能力的分类
    • “软感知”能力在华为的实践
  • 通过感知能力推进企业业务数字化
    • 感知数据在华为信息架构中的位置
    • 非数字原生企业数据感知能力的建设
  • 第七章小结
• 八、 打造“清洁数据”的 质量综合管理能力
  • 基于PDCA的数据质量管理框架
    • 什么是数据质量
    • 数据质量的管理范围
    • 数据质量的总体框架
  • 全面监控企业业务异常数据
    • 数据质量规则
    • 异常数据监控
  • 通过数据质量综合水平牵引质量提升
    • 数据质量度量运作机制
    • 设计质量度量
    • 执行质量度量
    • 质量改进
  • 第八章小结
• 九、 打造“安全合规”的 数据可控共享能力
  • 内外部安全形式，驱动数据安全治理发展
    • 数据安全成本国家竞争的新战场
    • 数字时代数据安全的新变化
  • 数字化转型下的数据安全共享
  • 构建以元数据为基础的安全隐私保护框架
    • 以元数据为基础的安全隐私治理
    • 数字安全隐私分层分级管控策略
    • 数据底座安全隐私分级管控方案
    • 分级标识数据安全隐私
  • “静”“动”结合的数据保护与授权管理
    • 静态控制：数据保护能力架构
    • 动态控制：数据授权与权限管理
  • 第九章小结
• 十、 未来已来，数据成为 企业核心竞争力
  • 数据：新的生产要素
    • 数据被列为生产要素：制度层面的肯定
    • 数据将进入企业的资产负债表
    • 数据资产的价值由市场决定
  • 大规模数据交互的企业数据生态
    • 数据生态离不开底层技术的支撑
    • 数据主权是数据安全交换的核心
    • 国际数据空间的目标与原则
    • 多方安全计算强化数据主权
  • 摆脱传统手段的数据管理方式
    • 智能数据管理是数据工作的未来
    • 内容分析能力提供资产全景图
    • 属性特征启发主外键智能联接
    • 质量缺陷预发现
    • 算法助力数据管理
    • 数字首先抵御算法歧视
  • 第四个世界：机器认知世界
    • 真实唯一的“物理世界”和五彩缤纷的“人类认知世界”
    • 映射“物理世界”的数字孪生--“数字世界”
    • “数字世界”中的智能认知--“机器认知世界”
  • 第十章小结
• 浮动主题
• 对数据治理未来的思考， 畅想了AI治理、数据主权和数据生态建 设。
• 介绍了数据治理的三项关键能力： 数据的全量感知、综合质量提升、可控共享。
• 分别从 非数字原生企业、企业管理、数据特性等角度， 解析企业数字化转型前提条件。
• 介绍了数据治理工作中的三项重点建设任 务： 信息架构、数据底座、数据服务。