重点章节 1️⃣:差异化的数据分类管理【第二章】、信息架构【第三章】、数据底座【第三章】。

次重点 2️⃣:数据服务【第四章】、数据质量【第五章】、数据安全与隐私【第六章】。

其他 3️⃣:数据感知【第五章】、数据综合治理体系【第二章】、企业数字化转型【第三章】。

重要概念和知识点

• 数据治理

  对企业的数据管理和利用进行评估、指导和监督，通过提供不断创新的数据服务，为企业创造价值

• 数据源

  指业务上首次正式发布某项数据的应用系统，并经过数据管理专业组织认证，作为企业范围内唯一数据源头被周边系统调用。

• 数据Owner

  公司数据 Owner 是公司数据战略的制定者、数据文化的营造者、数据资产的所有者和数据
  争议的裁决者，拥有公司数据日常管理的最高决策权。

  数据 Owner 的职责包括：
  ① 负责数据管理体系建设。
  ② 负责信息架构建设。
  ③ 负责数据质量管理。
  ④ 负责数据底座和数据服务建设。
  ⑤ 负责数据争议裁决。

  数据Owner要负责所辖领域的信息架构建设和维护，负责保障所辖领域的数据质量，承接公司各个部门对本领域数据的需求，并有责任建立数据问题回溯和奖惩机制，对所辖领域的数据问题及争议进行裁决，公司有权对不遵从信息架构或存在严重数据质量问题的责任人进行问责。

• 主数据

  参与业务事件的主体或资源，是具有高业务价值的、跨流程和跨系统重复使用的数据。主数据与基础数据有一定的相似性， 都是在业务事件发生之前预先定义；但又与基础数据不同，主数据的取值不受限于预先定义的数据范围，而且主数据的记录的增加和减少一般不会影响流程和IT系统的变化

• 元数据

  定义数据的数据，是有关一个企业所使用的物理数据、技术和业务流程、数据规则和约束以及数据的物理与逻辑结构的信息

  元数据是描述数据的数据，用于打破业务和IT之间的语言障碍，帮助业务更好地理解数据。
  元数据通常分为业务、技术和操作三类。
  其中：

  1. 业务元数据：用户访问数据时了解业务含义的途径，包括资产目录、Owner、数据密级
     等。
  2. 技术元数据：实施人员开发系统时使用的数据，包括物理模型的表与字段、ETL 规则、
     集成关系等。
  3. 操作元数据：数据处理日志及运营情况数据，包括调度频度、访问记录等。

• 信息架构

  信息架构的目的就是定义好整个运作过程中涉及的各种人、事、物资源，并实施有效的治理，从而确保各类数据在企业各业务单元间高效、准确地传递，上下游流程快速地执行和运作。企业级信息架构（Information Architecture）是指以结构化的方式描述在业务运作和管理决策中所需要的各类信息及其关系的一套整体组件规范，包括数据资产目录、数据标准、企业级数据模型和数据分布四个组件。

• 数据标准

  数据标准定义公司层面需共同遵守的属性层数据含义和业务规则，是公司层面对某个数据的共同理解，这些理解一旦确定下来，就应作为企业层面的标准在企业内被共同遵守

  每个数据标准应该覆盖 以下三方面。

  1. 业务视角要求：用于统一业务侧语言和理解，明确定义每个属性所遵从的业务定义和用途、业务规则、同义词，并对名称进行统一定义，避免重复。
  2. 技术视角要求：对IT实施形成必要的指引和约束，包括数据类型、长度，如果存在多个允许值，则应对每个允许值进行明确的限定。
  3. 管理视角要求：明确各业务部门在贯彻数据标准管理方面应承担的责任，包括业务规则责任主体、数据维护责任主体、数据监控责任主体，因为很多情况下这些责任并不是由同一个业务部门来负责，所以必须在标准制订时就约定清楚。例如，“客户合同” 中某些条款的规则制订者可能是财经部门，负责与客户达成约定 并在系统中录入的可能是销售业务部门，而对整个客户合同数据质量进行跟踪、监控的可能是数据专业部门。

• 数据湖和入湖方式

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

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

• 数据主题联接和联接方式

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

• 数据服务和服务的颗粒度

  数据服务是基于数据分发、发布的框架，将数据作为一种服务产品来提供，以满足客户的实时数据需求，它能复用并符合企业和工业标准，兼顾数据共享和安全

  粒度表示数据单元的细节程度或综合程度，细节程度越高，粒度越细；细节程度越低，粒度越粗。声明粒度是维度和事实表设计的重要步骤，声明粒度意味着精确定义事实表的每一行表示什么。数据服务设计中应强调数据服务的颗粒度，数据服务颗粒度的大小直接影响着服务的可重用性和系统的整体性能，数据服务颗粒度通常应考虑的原则，如下：。
  1）业务特性：将业务相近或相关、数据粒度相同的数据设计为一个数据服务。
  2）消费特性：将高概率同时访问、时效性要求相同的数据设计为一 个数据服务。
  3）管理特性：综合考虑企业在数据安全管理策略方面的要求。
  4）能力特性：将单一能力模型设计为一个服务。

• 数据集服务Vs数据API服务

  数据服务分类：数据集服务和数据API服务

  • 数据集服务定义
    比较常见的数据消费者有两类：一类是真实的“人”，一类是 “IT系统”。消费者是“访问”某个相对完整的“数据集”，这种消费方式称之为 “数据集服务”。数据集服务最主要的特征是由服务提供方提供相对完整的数据集合，消费方“访问”数据集合，并自行决定接下来的处理逻辑，数据服务提供方被动地公开数据以供数据消费方检索。
    数据服务提供方并不定义数据处理逻辑，但数据和数据处理逻辑仍然由其控制。
    数据服务的生命周期即数据访问授权的有效期

  • 数据服务的另外一类消费者是“IT系统”，即面向某个IT系统提供数据事件驱动的“响应”，这种服务的封装方式与前面所提到的数据集不同，称为“数据API服务”。

    数据API服务是对用户随机数据事件的响应，这个需求往往伴随着用户的某个任务产生，随着任务的结束，整个服务也就完成了。通过数据API服务，用户可以及时地获知任务的协同情况，并基于服务方的反馈结果，做出相应的调整。服务供给方和消费方是协同关系（互操 作），而非交接棒关系（交换情报），有效提升了面向协同任务的互操作一致性。

    数据服务提供方基于随机的数据事件主动地传送数据。

    数据服务提供方会基于事件定义数据处理逻辑，由消费方提前订阅并随机触发。

    服务的生命周期跟着事件走，事件关闭了，服务就终止了。

  数据API服务与传统系统集成相比有明显的优势。

  供应/消费数据服务：应用组件间传递的是基于数据服务契约的消息，即传递对数据进行逻辑操作的结果。
  高聚合：订单服务使业务逻辑变得更加集中，易于数据同源管 控。
  松耦合：业务逻辑的变化对服务消费方没有直接影响。
  数据API服务的设计规范业界相对统一，不在这里详细说明。

• 数据质量度量

  企业数据质量管理是一个系统性的工程，华为数据质量从数据质量领导力、数据质量持续改
  进、数据质量能力保障三方面展开，有机结合形成联动。

  数据质量指“数据满足应用的可信程度”，从以下六个维度对数据质量进行描述：

  1. 完整性：指数据在创建、传递过程中无缺失和遗漏，包括实体完整、属性完整、记录完整和字段值完整四个方面。完整性是数据质量最基础的一项，例如员工工号不可为空。
  2. 及时性：指及时记录和传递相关数据，满足业务对信息获取的时间要求。数据交付要及时，抽取要及时，展现要及时。数据交付时间过长可能导致分析结论失去参考意义。
  3. 准确性：指真实、准确地记录原始数据，无虚假数据及信息。 数据要准确反映其所建模的“真实世界”实体。例如员工的身份信息必须与身份证件上的信息保持一致。
  4. 一致性：指遵循统一的数据标准记录和传递数据和信息，主要 体现在数据记录是否规范、数据是否符合逻辑。例如同一工号对应的不同系统中的员工姓名需一致。
  5. 唯一性：指同一数据只能有唯一的标识符。体现在一个数据集 中，一个实体只出现一次，并且每个唯一实体有一个键值且该键值只指向该实体。例如员工有且仅有一个有效工号。
  6. 有效性：指数据的值、格式和展现形式符合数据定义和业务定义的要求。例如员工的国籍必须是国家基础数据中定义的允许值。

• 异常数据监控

  质量控制是通过监控质量形成过程，消除全过程中引起不合格或不满意效果的因素，以达到质量要求而采用的各种质量作业技术和活动。要保证最终交付质量，必须对过程进行质量控制，通常是在过程中设置关键质量控制点。例如，可以在数据录入阶段设置规则程序，从源头避免不可接受的数据进入系统。
  数据质量控制的目的是致力于满足数据质量要求，消除或减少异常数据。数据质量控制可以在数据的生命周期内的不同时点被应用，来测试数据的质量和其是否适合于其所在的系统。
  异常数据监控分为以下三个步骤：

  1. 识别监控对象范围，确定监控内容
     1. 数据质量控制从明确业务需求开始，根据业务规划和数据相关方的需求，阶段性确定数据质量控制范围。
     2. 从定性、定量两个维度识别关键数据，定性维度参考以下原则
        1. 重要性原则：关键主数据和基础数据、关键的事务数据、痛点问题
        2. 成本效益原则
  2. 数据源剖析
     1. 在着手设计数据质量规则前，需对数据进行快速数据剖析，目的是分析数据源的内容、质量和结构，同时发现和分析数据源中的所有数据不规范问题和使数据项目处于危险中的隐藏数据问题。
     2. 可以从以下三个方面对数据源进行剖析
        1. 数据源内容
        2. 数据源结构：包括技术结构和业务结构。技术结构指空值频率、相异值频率、值范围（最大值、最小值）、模式、长度、数据类型。业务结构如组织结构存储是平面结构还是树状结构。
        3. 根据数据标准分析剖析结果的数据质量，例如必填字段是否有空值存储，有允许值列表中的值个数与相异值频率是否一致等
  3. 设计和配置监控规则，自动监测异常数据
     1. 数据质量监控平台已实现质量规则的可配置、数字化、快速部署、 自动监控识别异常数据等能力，并可随时间推移，制定周期性监控计 划，监视数据质量的进展情况，并通过虚拟化的方式快速、灵活发布监控结果。
     2. 可利用自助分析工具开发在线数据质量分析报告，通过前端工具 不仅能够查看监控结果汇总数据，而且能够通过钻取功能查看异常明细数据，以便业务人员准确定位业务系统的异常数据。

• 高防区隔离

  高防区隔离就是我们通过在数据底座独立部署单独的防火墙以及配合流向控制、堡垒机等措施，对高密资产重点防护。关键要点就是有独立的防火墙，并且内部区分脱敏开发区以及明文业务访问区，让数据开发人员在脱敏区工作。高防区数据经过审核后才能发布到明文区，给业务部门使用。

• 动态脱敏

  动态脱敏则是一项基于身份的访问控制。通常Web应用都是使用自己的菜单和角色权限进行职责分离，对于数据权限，很难做到字段级别的控制。而动态脱敏可以对某些数据表、数据字段根据身份进行脱敏，从而做到更细颗粒度的保护。

• 数据保护能力架构

  在充分识别数据风险并标识数据安全隐私后，数据底座产品还需要提供不同程度的数据保护
  能力。数据保护能力包括存储保护、访问控制、可追溯三种，每种保护能力都面向不同的业
  务管理需求。

  为打造“安全合规”的数据可控共享能力，我们践行了数据安全隐私管理不仅仅是一套IT工具组合的思路，基于安全隐私的两个公司级治理文件，通过“数据底座共享与安全管理规定”和“数据底座的 隐私保护规定”，落实管理要求，分别建设了数据标识、存储保护、 授权控制、访问控制的能力。同时平台调用了传统IT安全措施，通过态势感知、堡垒机、日志服务等，结合数据安全治理方法与传统的IT安全手段，做好数据的内外合规，形成完整的数据安全与隐私保护， 实现让数据使用更安全这一目标。数据安全与隐私保护能力架构如图。

  [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-yqebwqL3-1639643992172)(https://s3-us-west-2.amazonaws.com/secure.notion-static.com/8164a1e5-1ba3-464e-9d85-81c145880ad3/Untitled.png)]

• 数据授权VS数据权限管理

数据授权和数据权限是两个不同的概念。

数据授权主要是面向组织，指数据Owner对组织授予数据访问权的过程，让数据与组织绑定，为组织提供长期的数据订阅权限。数据授权包含两个场景。
1）数据加工授权：由于数据主题联接资产建设中需要跨组织进行数据联接、加工、训练需要转移数据而发生的数据授权场景。
2）数据消费授权：由于业务用户数据的分析需要订阅数据服务而发生的数据授权场景。

数据权限管理是基于访问管控规范，对授予的数据访问权限进行管理的过程。面向个人和面向与岗位绑定的综合管理者的管理策略不同。

面向个人，指业务制定数据访问管控规范，授予个人数据访问权限的过程，具有与个人绑定、短期有效的特点。基于消费数据类型的差异，个人数据权限分为两大场景：1）业务分析师获取数据资产（原材料场景）2）业务用户获取报告访问权限（成品场景）。

基于企业IAM（身份识别与访问管理）和IDM（账号权限管理）， 结合数据分级管理机制，让数据权限随人员流动而改变，并统一规 则、集中管控高风险数据，实现对个人权限授予、销权、调动全生命周期集中管控。

问题与思考: .

1. 元数据与数据治理中的关系?

   元数据是描述数据的数据，用于打破业务和IT之间的语言障碍， 帮助业务更好地理解数据。元数据通常分为业务、技术和操作三类。
   业务元数据：用户访问数据时了解业务含义的途径，包括资产目录、Owner、数据密级等。
   技术元数据：实施人员开发系统时使用的数据，包括物理模型的表与字段、ETL规则、集成关系等。
   操作元数据：数据处理日志及运营情况数据，包括调度频度、访问记录等。

   基于高质量的元数据，通过数据地图就能在企业内部实现方便的数据搜索。

   无论结构化数据，还是非结构化数据，或者外部数据，最终都会通过元数据治理落地。华为
   将元数据治理贯穿整个数据价值流，覆盖从数据产生、汇聚、加工到消费的全生命周期。

   在企业的数字化运营中，元数据作用于整个价值流，在从数据源到数据消费的五个环节中都能充分体现元数据管理的价值。
   1）数据消费侧：元数据能支持企业指标、报表的动态构建
   2）数据服务侧：元数据支持数据服务的统一管理和运营，并实现利用元数据驱动IT敏捷开发。
   3）数据主题侧：元数据统一管理分析模型，敏捷响应井喷式增长的数据分析需求，支持数据增值、数据变现。
   4）数据湖侧：元数据能实现暗数据的透明化，增强数据活性，并能解决数据治理与IT落地脱节的问题。
   5）数据源侧：元数据支撑业务管理规则有效落地，保障数据内容合格、合规。

   元数据管理架构包括产生元数据、采集元数据、注册元数据和运维元数据

2. 主数据在数据治理中的地位?

   主数据是参与业务事件的主体或资源，是具有高业务价值的、跨流程和跨系统重复使用的数据。主数据与基础数据有一定的相似性， 都是在业务事件发生之前预先定义；但又与基础数据不同，主数据的取值不受限于预先定义的数据范围，而且主数据的记录的增加和减少一般不会影响流程和IT系统的变化。但是，主数据的错误可能导致成百上千的事务数据错误，因此主数据最重要的管理要求是确保同源多用和重点进行数据内容的校验。主数据管理策略：唯一性、联邦控制、单一数据源、【数据、流程、IT协同】、事前的数据质量策略。

   主数据范围包括客户、产品、供应商、组织、人员主题， 每个主数据都有相应的架构、流程及管控组织来负责管理。鉴于主数据管理的重要性，对于每个重要的主数据，都会发布相应的管理规范，数据管家依据数据质量标准定期进行数据质量的度量与改进。 同时，对于主数据的集成消费按照如下管理框架进行管理

3. 数字化转型与数据治理的关系?
   面向数字化转型的扩展：对象数字化、过程数字化、规则数字化，并打造与之相应的能力。

   1）对象数字化
   对象数字化的目标是建立对象本体在数字世界的映射。这种映射不是传统意义上基于流程要求的少量数据的管理，而是管理某个对象的全量数据
   在推行对象数字化后，就可以通过数据感知等手 段在设计的各个环节记录上述这些数据，并按项目编码进行更新，这样就可以向供应环节提供准确并且全量的数据。

   2）过程数字化
   过程数字化要实现业务活动线上化，并记录业务活动的执行或操作轨迹，一般通过观测数据来实现轨迹记录

   3）规则数字化
   规则数字化的目的是把复杂场景下的复杂规则用数字化手段进行管理。良好的规则数字化管理，应该能实现业务规则与IT应用解耦， 所有关键业务规则数据要实现可配置，能够根据业务的变化灵活调整。

   华为数字化转型蓝图包括 5 项举措：
   举措 1：实现“客户交互方式”的转变，
   举措 2：实现“作战模式”的转变，
   举措 3：实现“平台能力”提供方式的转变，
   举措 4：实现“运营模式”的转变，
   举措 5：云化、服务化的 IT 基础设施和 IT 应用，统一公司 IT 平台，同时构建智能服务。
   其中，举措 4 涉及数据治理和数字化运营，是华为数字化转型的关键，承接了打破数据孤
   岛、确保源头数据准确、促进数据共享、保障数据隐私与安全等目标。华为数字化转型对数
   据治理的要求如下：
   1）基于统一的数据管理规则，确保数据源头质量以及数据入湖，形成清洁、完整、一致的
   数据湖，这是华为数字化转型的基础。
   2）业务与数据双驱动，加强数据联接建设，并能够以数据服务方式，灵活满足业务自助式
   的数据消费诉求。
   3）针对汇聚的海量内外部数据，能够确保数据安全合规。
   4）不断完善业务对象、过程与规则数字化，提升数据自动采集能力，减少人工录入。
   华为数据工作建设的整体框架：
   1）数据源：业务数字化是数据工作的前提，通过业务对象、规则与过程数字化，不断提升
   数据质量，建立清洁、可靠的数据源。
   2）数据湖：基于“统筹推动、以用促建”的建设策略，严格按六项标准，通过物理与虚拟两种
   入湖方式，汇聚华为内部和外部的海量数据，形成清洁、完整、一致的数据湖。
   3）数据主题联接（中台）：通过五种数据联接方式，规划和需求双驱动，建立数据主题联接，
   并通过服务支撑数据消费。
   2）和 3）与数字底座相关
   4）数据消费：对准数据消费场景，通过提供统一的数据分析平台，满足自助式数据消费需
   求。
   5）数据治理：为保障各业务领域数据工作的有序开展，需建立统一的数据治理能力，如数
   据体系、数据分类、数据感知、数据质量、安全与隐私等。

4. 传统数据集成方式的问题与解决? .

   过去，数据获取大部分依赖于传统集成方式，即将数据从一个系统复制到另一个系统。随着企业规模的扩大，需要在几十个甚至上百个IT系统中进行数据集成，这样一来，随着系统集成的复杂度的提升，会带来一系列数据质量问题。

   数据在不同的系统间不断“搬家”，数据的一致性很难得到保障，尤其是经过多次搬家后，源头数据往往和下游各系统之间的数据差异巨大。
   同时，较复杂的数据集成还会导致企业管理成本上升，每个系统都存在数据的大量重复构建，这样一来，每当源头数据出现变化时， 整个业务流上的相关系统都要执行变更。
   这种通过集成获取数据的方式不仅会导致当前的诸多问题，而且会给未来的业务发展带来更大的挑战。

   解决：在这样的背景下，华为公司进行了大规模的数据服务建设，通过数据服务替代原有数据集成方式，解决了数据交互过程中的诸多问题，取得了数据获取效率和数据安全之间的平衡。

5. 大数据治理的重要作用？

   有效的大数据治理能够促进大数据服务创新和价值的创造

   科学的大数据治理框架有助于提升组织的大数据管理和决策水平

   有效的大数据治理能够产生高质量的数据，增强数据可信度，降低成本

   有效的大数据治理有助于提高合规监管和安全控制，并降低成本

重要知识点

数据治理（第一章）

大数据的基本特征

“大数据”具有四个基本特征：大量（Volume）、多样（Variety）、时效(Velocity）、价值（Value），即4V特征。

• 大量——规模巨大：PB，最基本特征，3个原因（移动互联网+传感器+处理数据的理念和方法改变）
• 多样——类型多样：结构化数据 、半结构化数据和非结构化数据(大部分）
• 时效一一生成和处理速度极快：以数据流的形式产生、快速流动、迅速消失；流量不平稳的；用户对系统的响应时间敏感( 3、5s)；大数据区别于传统海量数据的最显著特征 ，也是大数据处理技术与传统数据挖掘技术的本质不同
• 价值一一价值巨大但密度很低：大数据价值密度的高低与数据总量的大小成反比

数据管理与信息管理

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-T4hdyiYD-1639643992199)(https://s3-us-west-2.amazonaws.com/secure.notion-static.com/1dcc6d40-d4ec-42e8-a0a1-e0499ff05715/Untitled.png)]

• 狭义数据治理：数据资源及其应用过程中相关管控活动、绩效和风险管理的集合，保证数据资产的高质量、安全及持续改进。狭义的数据治理的驱动力最早源自两个方面：
  • 内部风险管理的需要
  • 外部监管和合规的需要
• 广义数据治理：含义大于狭义数据治理，包括数据管理和数据价值“变现”，具体包含数据架构、主数据、数据指标、时序数据、数据质量、数据安全等一系列数据管理活动的集合。

数据治理的概念内涵

1. 明确数据治理的目标
   • 在管理数据资产的过程中，确保数据的相关决策始终是正确 、及时和有前瞻性的 ，确保数据管理活动始终处于规范 、有序和可控的状态，确保数据资产得到正确有效的管理，并最终实现数据资产价值的最大化 。
2. 理解数据治理的职能
   • 决定如何作决定
   • 评估 、指导和监督
3. 把握数据治理的核心
   • 数据资产管理的决策权分配和职责分工是数据治理的核心（确保决策正确有效的核心机制）
   • 数据治理并不涉及具体的管理活动 ，而是专注于通过什么机制才能确保做出正确的决策
4. 数据治理必须遵循过程和遵守规范
   • 过程主要用于描 述治理的方法和步骤，它应该是正式、书面、可重复和可循环的
   • 遵循标准的、成熟的、获得广泛认可的过程，并且严格遵守相关规范

数据治理本质上就是：对企业的数据管理和利用进行评估、指导和监督，通过提供不断创新的数据服务，为企业创造价值

数据治理与数据管理

治理和管理是完全不同的活动：治理负责对管理活动进行评估、指导和监督，而管理根据治理所作的决策来具体计划 、建设和运营。

数据治理对数据管理具有领导职能，即指导如何正确履行数据管理职能

数据治理和IT治理

参与到决策过程中的人：一是大数据利益相关者 ，二是大数据治理委员会（中心决策层） ，三是大数据管理者（执行层） ，四是数据专家，并且数据专家应该加入到治理委员会中辅助做出决策 。

大数据治理的管理者视图（顶层架构）“五域模型”，即管控域、过程域（方法论）、治理域（治理主体）、技术域（支撑手段）、价值域

核心内容

完整的大数据治理包括战略、组织、制度、流程、绩效、标准、工具及数据价值、数据共享、数据变现。

下面将大数据治理的重要作用概括为四点：

• 有效的大数据治理能够促进大数据服务创新和价值创造。
• 科学的大数据治理框架有助于提升组织的大数据管理和决策水平。
• 有效的大数据治理能够产生高质量的数据，增强数据可信度，降低成本。
• 有效的大数据治理有助于提高合规监管和安全控制，并降低风险。

数据综合治理体系（3️⃣）

公司级的数据治理政策

1. 数据管理总纲：数据管理总纲明确了数据治理最基本的原则，包括信息架构、数据产生、数据应用及数据质量的职责和分工等，确保数据治理环境的有效构建。
2. 信息架构管理政策：信息架构是公司统一的数据语言，是业务流打通、消除信息孤岛和提升业务流集成效率的关键要素。通过明确对信息架构的管理要求，规范信息架构的建设和遵从原则，使公司的信息资产得到有效管理和重用。
3. 数据源管理政策：数据同源是数据治理的核心观点之一。数据源是指业务上首次正式发布某项数据的应用系统，经过数据管理专业组织认证，作为唯一数据源头被周边系统调用。通过明确公司在数据源建设和数据源使用方面的总体原则和要求，确保数据源头的统一，以及跨流程、跨系统数据的唯一性和一致性。包括
   1）数据源管理原则；
   2）数据源认证标准
4. 数据质量管理政策：数据质量的持续提升是华为数据治理的核心目标。通过制定数据质量管理政策，明确数据在创建、维护、应用过程中的规则及质量要求，确保数据真实可靠。包括
   1）数据质量管理职责及要求
   2）数据质量管理的业务规则和管理要求。

差异化的企业数据分类管理框架（ 1️⃣）

基于数据特性的分类管理框架

根据数据特性及治理方法的不同对数据进行了分类定义：内部数据和外部数据、结构化数据和非结构化数据、元数据。

数据分类定义

不同分类的数据，其治理方法有所不同。如基础数据内容的变更通常会对现有流程、IT系统产生影响，因此基础数据的管理重点在于变更管理和统一标准管控。主数据的错误可能会导致成百上千的事务 数据错误，因此主数据的管理重点是确保同源多用、重点进行数据内容的校验等。

以统一语言为核心的结构化数据管理

结构化数据的共同特点是以信息架构为基础，建立统一的数据资产目录、数据标准与模型

1. 基础数据治理

   1. 基础数据用于对其他数据进行分类，在业界也称作参考数据。基础数据通常是静态的（如国家、币种），一般在业务事件发生之前就已经预先定义。它的可选值数量有限，可以用作业务或IT的开关和判断条件。当基础数据的取值发生变化的时候，通常需要对流程和IT系 统进行分析和修改，以满足业务需求。因此，基础数据的管理重点在于变更管理和统一标准管控。 基础数据在支撑场景分流、流程自动化、提升分析质量方面起着关键作用
   2. 治理基础数据的价值
      1. 外部协同有效性
      2. 业务场景数字化
      3. 业务规则自动化
      4. 业务分析准确性
   3. 完整的基础数据治理框架

2. 主数据处理

   1. 主数据是参与业务事件的主体或资源，是具有高业务价值的、跨流程和跨系统重复使用的数据。主数据与基础数据有一定的相似性， 都是在业务事件发生之前预先定义；但又与基础数据不同，主数据的取值不受限于预先定义的数据范围，而且主数据的记录的增加和减少 一般不会影响流程和IT系统的变化。但是，主数据的错误可能导致成 百上千的事务数据错误，因此主数据最重要的管理要求是确保同源多用和重点进行数据内容的校验。

   2. 主数据管理策略

   3. 主数据范围包括客户、产品、供应商、组织、人员主题， 每个主数据都有相应的架构、流程及管控组织来负责管理。鉴于主数据管理的重要性，对于每个重要的主数据，都会发布相应的管理规范，数据管家依据数据质量标准定期进行数据质量的度量与改进。 同时，对于主数据的集成消费按照如下管理框架进行管理，如图所示

      数据消费层：数据消费层包括所有消费数据的IT产品团队，负责提出数据集成需求和集成接口实施

      主数据服务实施层：负责主数据集成解决方案的落地，包括数据服务的IT实施和数据服务的配置管理。

      主数据服务设计层：为需要集成主数据的IT产品团队提供咨询和方案服务，负责受理主数据集成需求，制定主数据集成解决方案，维护主数据的通用数据模型。

      管控层：管控层由信息架构专家组担任，负责主数据规则的制定与发布，以及主数据集成争议或例外的决策。

      • 客户主数据治理

        客户数据在全流程中的及时性、准确性、完整性、一致性、有效性、唯一性是业务高效运作、经营可控的重要保障。客户数据可能会存在以下几个方面的问题。
        第一，客户信息不完整，且下游系统未严格遵循数据源头所定义的标准。
        第二，数据架构不灵活、紧耦合，不能有效支撑多BG的业务管理。
        第三，下游系统集成管理不严格，存在多源头录入。
        第四，客户数据源头的数据质量管理控制点无法延伸到下游的各集成IT系统中。
        为彻底解决客户数据问题，制订客户数据管理及服务化架构方案，以客户数据质量为核心，严控数据流入与流出两个端口，搭建客户数据管理及服务平台，统一数据架构和标准，通过服务化架构实现“数出一孔”，提升财报准确性、提升运作效率、降低运营风险 ，客户主数据治理框架如下图所示。

        [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-oAVE7RqM-1639643992212)(https://s3-us-west-2.amazonaws.com/secure.notion-static.com/c4187104-5f67-4ee4-8c16-f0b3abbcd58d/Untitled.png)]

        以客户数据架构的重构和管理为基础，制订了Account & Legal Entity两级架构

3. 事务数据治理

   事务数据在业务和流程中产生，是业务事件的记录，其本身就是业务运作的一部分。事务数据是具有较强时效性的一次性业务事件， 通常在事件结束后不再更新。
   事务数据的治理重点就是管理好事务数据对主数据和基础数据的调用，以及事务数据之间的关联关系，确保上下游信息传递顺畅。在事务数据的信息架构中需明确哪些属性是引用其他业务对象的，哪些是其自身特有的。对于引用的基础数据和主数据，要尽可能调用而不是重新创建。

4. 报告数据治理
   报告数据是指对数据进行处理加工后，用作业务决策依据的数据。它用于支持报告和报表的生成。用于报告和报表的数据可以分为如下几种。

   1. 用于报表项数据生成的事实表【从业务活动或者事件中提炼出来的性能度量。其特点为：每个事实表由颗粒度属性、维度属性、事务描述属性、度量属性组成；事实表可以分为基于明细构建的事实表和基于明细做过汇聚的事实表】、指标数据、维度【用于观察和分析业务数据的视角，支持对数据进行汇聚、钻取、切片分析。其特点为：维度的数据一般来源于基础数据和主数据；维度的数据一般用于分析视角的分类； 维度的数据一般有层级关系，可以向下钻取和向上聚合形成新的维度】。
   2. 用于报表项统计和计算的统计型函数【与指标高度相关，是对指标数量特征进一步的数学统计，例如均值、中位数、总和、方差等。其特点为：通常反映某一维度下指标的聚合情况、离散情况等特征； 其计算数值在报告中通常呈现为图表中的参考线】、趋势函数【反映指标在时间维度上变化情况的统计方式，例如同比、环比、定基比等。其特点为：通常将当期值与历史某时点值进行比较； 调用时，需要收集指标的历史表现数据； 其计算数值在报告中通常呈现为图表中的趋势线】及报告规则【一种描述业务决策或过程的陈述，通常是基于某些约束下产生的结论或需要采取的某种措施。其特点为：将业务逻辑通过函数运算体现，通常一个规则包含多个运算和判 断条件； 规则的计算结果一般不直接输出，需要基于计算结果翻译成业务 语言后输出； 规则通常与参数表密切相】。
   3. 用于报表和报告展示的序列关系数据【反映报告中指标及其他数据序列关系的数据】。
   4. 用于报表项描述的主数据、基础数据、事务数据、观测数据。
   5. 用于对报告进行补充说明的非结构化数据。

5. 观测数据治理

   观测数据是通过观测工具获取的数据，观测对象一般为人、事、 物、环境。相比传统数据，观测数据通常数据量较大且是过程性的，由机器自动采集生成。不同感知方式获取的观测数据，其数据资产管理要素不同。 观测数据的感知方式可分为软感知和硬感知。软感知是使用软件 或者各种技术进行数据收集，收集的对象存在于数字世界，通常不依赖于物理设备，一般是自动运行的程序或脚本；硬感知是利用设备或 装置进行数据收集，收集的对象为物理世界中的物理实体，或者是以物理实体为载体的信息，其数据的感知过程是数据从物理世界向数字世界的转化过程。

6. 规则数据治理

   规则数据是结构化描述业务规则变量（一般为决策表、关联关系表、评分卡等形式）的数据，是实现业务规则的核心数据，如业务中普遍存在的基线数据

   1）规则数据的管理是为了支撑业务规则的结构化、信息化、数字化，目标是实现规则的可配置、可视化、可追溯。
   2）不同于标准化的信息架构管理，规则数据的管理具有轻量化、分级的特点。重要的、调用量大、变动频繁的业务规则需要通过规则数据管理，使其从代码中解耦，进行资产注册；使用广泛的、有分析需求的规则数据需要通过注册入湖，实现共享和复用。
   3）业务规则在架构层次上与流程中的业务活动相关联，是业务活动的指导和依据，业务活动的结果通过该业务活动的相关业务对象的 属性来记录。业务规则通过业务活动对业务事实、业务行为进行限 制，业务人员可以根据业务规则判断业务情况，采取具体行动。
   4）业务规则包含规则变量和变量之间的关系，规则数据主要描述规则的变量部分，是支撑业务规则的核心数据。

   运行规则所需要的输入数据、输出数据，包括动态数据库访问对象、内存表缓存、Excel、XML处理类等，主要起支撑作用，不在规则数据的范畴。规则数据必须有唯一的数据Owner

   以特征提取为核心的非结构化数据管理

   非结构化数据包括无格式文本、各类格式文档、图像、音频、视频等多种异构的格式文件，较之结构化 数据，其更难标准化和理解，因此在存储、检索以及消费使用时需要智能化的IT技术与之匹配。
   相较于结构化数据，非结构化元数据管理除了需要管理文件对象的标题、格式、Owner等基本特征和定义外，还需对数据内容的客观理解进行管理，如标签、相似性检索、相似性连接等，以便于用户搜索和消费使用。因此，非结构化数据的治理核心是对其基本特征与内容进行提取，并通过元数据落地来开展的。非结构化数据的管理模型如图所示。

   元数据管理平台通过“基本特征类元数据流”和“内容增强类元数据流”两条线来实现对非结构化数据的元数据管理和消费使用。
   1）基本特征类元数据流元 数据管理平台基于收集到的各类非结构化数据源信息，自动完成基础特征类元数据的采集工作，按照管理规范和要求通过标准化、 整合后存储在元数据管理平台中，并在完成元数据过滤、排序后将结果在元数据报告中进行可视化展示，以供用户消费使用。
   2）内容增强类元数据流 基于元数据管理平台中基本特征类元数据的信息，各数据分析项目组解析目标非结构化对象的数据内容，并将分析结果通过元数据采集、元数据标准化&整合后统一存放在元数据管理平台中，以供用户一并消费使用，增强用户体验。 非结构化数据的处理过程如图所示。

以确保合规遵从为核心的外部数据管理

外部数据是指公司引入的外部组织或者个人拥有处置权利的数据，如供应商资质证明、消费者洞察报告等。外部数据治理的出发点是合规遵从优先，与内部数据治理的目的不同。
外部数据的治理主要遵循以下原则。
1）合规优先原则
2）责任明确原则
3）有效流动原则
4）可审计、可追溯原则
5）受控审批原则

作用于数据价值流的元数据管理

• 元数据问题主要表现为数据找不到、读不懂、不可信。根本原因就在于业务元数据与技术元数据未打通，导致业务读不懂IT系统中的数据

• 元数据是描述数据的数据，用于打破业务和IT之间的语言障碍， 帮助业务更好地理解数据

  • 业务元数据：用户访问数据时了解业务含义的途径，包括资产目录、Owner、数据密级等
  • 技术元数据：实施人员开发系统时使用的数据，包括物理模型的表与字段、ETL规则、集成关系等。
  • 操作元数据：数据处理日志及运营情况数据，包括调度频度、访问记录等。

• 元数据作用
  在企业的数字化运营中，元数据作用于整个价值流，在从数据源到数据消费的五个环节中都能充分体现元数据管理的价值。

  • 数据消费侧：元数据能支持企业指标、报表的动态构建
  • 数据服务侧：元数据支持数据服务的统一管理和运营，并实现利用元数据驱动IT敏捷开发
  • 数据主题侧：元数据统一管理分析模型，敏捷响应井喷式增长的 数据分析需求，支持数据增值、数据变现
  • 数据湖侧：元数据能实现暗数据的透明化，增强数据活性，并能 解决数据治理与IT落地脱节的问题
  • 数据源侧：元数据支撑业务管理规则有效落地，保障数据内容合格、合规。

• 元数据管理架构和策略

  元数据管理架构包括产生元数据、采集元数据、注册元数据和运维元数据。

  元数据管理方案：通过制定元数据标准、规范、平台与管控机制，建立企业级元数据管理体系，并推动其在公司各领域落地， 支撑数据底座建设与数字化运营。

  • 产生元数据

    • 元数据模型

    • 针对找数据及获取数据难的痛点，明确业务元数据、技术元数据、操作元数据的设计原则

    • 规范数据资产管理，设计数据资产编码规范数据资产编码规范

      数据资产编码（DAN）是通过一组数字、符号等组成的字符串去唯 一标识华为公司内部每一个数据资产，基于此唯一标识，保证各业务 领域对同一数据资产的理解和使用一致，它的设计遵循以下原则

      • 统一性
      • 唯一性
      • 可读性
      • 扩展性

  • 采集元数据

    元数据采集是指从生产系统、IT设计平台等数据源获取元数据， 对元数据进行转换，然后写入元数据中心的过程。元数据的来源可分为如表所示的六类。

    1）选择适配器
    适配器是指针对不同的元数据来源，采用相应的采集方式获取元数据的程序，元数据的来源种类繁多，因而须选择相对应的适配器及元模型。
    2）配置数据源
    配置数据源是采集元数据的关键，在确定数据源所选择的适配器类型、适配器版本、元模型的基础上，配置数据源的名称、连接参数 和描述。
    3）配置采集任务
    采集任务为自动调度的工作单元，为元数据的采集提供自动化的、周期性的、定时的触发机制

  • 注册元数据

    1）元数据注册原则

    • 数据Owner负责，是谁的数据就由谁负责业务元数据和技术元数据连接关系的建设和注册发布
    • 按需注册，各领域数据管理部根据数据搜索、共享的需求，推进元数据注册
    • 注册的元数据的信息安全密级为内部公开。

    2. 元数据注册规范

    3. 元数据注册方法

    元数据注册分为增量元数据注册和存量元数据注册两种场景。

    • 增量场景相对容易，在IT系统的设计与开发过程中，落实元数据的相关规范，确保系统上线时即完成业务元数据与技术元数据连接， 通过元数据采集器实现元数据自动注册
    • 存量场景，设计了元数据注册的四大模式。在符合元数据设计规范的前提下，进行业务元数据与技术元数据的连接及注册
      • 一对一模式
        • 适用场景：适用于数据已发布信息架构和数据标准且物理落地，架构、标准 与物理落地能一一对应的场景。
        • 解决方案：将逻辑实体和物理表一对一连接。 逻辑实体属性和物理表字段一对一连接
      • 主从模式
        • 适用场景：适用于主表和从表结构一致，但数据内容基于某种维度分别存储 在不同物理表中的场景。例如，按时间或项目归档，或按区域进行分 布式存储。
        • 解决方案：识别主物理表和从属物理表。 以主物理表为核心，纵向UNION所有从属物理表，并固化为视图。将视图、逻辑实体、字段和业务属性一对一连接。
      • 主扩模式
        • 适用场景：适用于逻辑实体的大部分业务属性在主物理表，少数属性在其他物理表中的场景。
        • 解决方案：识别主物理表和扩展物理表。 以主物理表为核心，横向JOIN所有扩展物理表，完成扩展属性与 主表的映射，并固化为视图。 将视图、逻辑实体、字段和业务属性一对一连接。
      • 父子模式
        • 适用场景：适用于多个逻辑实体业务属性完全相同，按不同场景区分逻辑实 体名称，但落地在同一张物理表的场景
        • 解决方案：识别一张物理表和对应的多个逻辑实体。 将物理表按场景拆分和多个逻辑实体一对一连接。 将物理表字段和多个逻辑实体属性一对一连接

  • 运维元数据

    运维元数据是为了通过对元数据进行分析，发现数据注册、设计、使用的现状及问题，确保元数据的完整、准确。通过数据资产分析，了解各区域/领域的数据注册情况，进而发现数据在各信息系统使用过程中存在的问题。通过业务元数据与技术元数据的关联分析，反向校验架构设计与落地的实施情况，检查公司数据管理政策的执行情况。

    主要分为如下四个场景。
    场景一：基于数据更新发现，数据源上游创建，下游更新；
    场景二：通过数据调用次数发现，某数据源上游调用次数<下游调用次数；
    场景三：虽制定了架构标准，但不知落地情况，比如某个属性建 立了数据标准，但是却找不到对应落地的物理表字段；
    场景四：通过物理表的字段分析，发现很多字段缺少数据标准。

面向“业务交易”的信息架构建设(1️⃣)

四个组件

事件、财务、经营、资源

信息架构的目的就是定义好整个运作过程中涉及的各种人、事、物资源，并实施有效的治理，从而确保各类数据在企业各业务单元间 高效、准确地传递，上下游流程快速地执行和运作。企业级信息架构（Information Architecture）是指以结构化的方式描述在业务运作和管理决策中所需要的各类信息及其关系的一套整体组件规范，包括数据资产目录、数据标准、企业级数据模型和数据分布四个组件，如图所示。

• 数据资产目录

• 数据标准

  数据标准定义公司层面需共同遵守的属性层数据含义和业务规则，是公司层面对某个数据的共同理解，这些理解一旦确定下来，就应作为企业层面的标准在企业内被共同遵守

  每个数据标准应该覆盖 以下三方面。

  1. 业务视角要求：用于统一业务侧语言和理解，明确定义每个属性 所遵从的业务定义和用途、业务规则、同义词，并对名称进行统一定义，避免重复。
  2. 技术视角要求：对IT实施形成必要的指引和约束，包括数据类型、长度，如果存在多个允许值，则应对每个允许值进行明确的限定。
  3. 管理视角要求：明确各业务部门在贯彻数据标准管理方面应承担的责任，包括业务规则责任主体、数据维护责任主体、数据监控责任主体，因为很多情况下这些责任并不是由同一个业务部门来负责，所以必须在标准制订时就约定清楚。例如，“客户合同” 中某些条款的规则制订者可能是财经部门，负责与客户达成约定 并在系统中录入的可能是销售业务部门，而对整个客户合同数据质量进行跟踪、监控的可能是数据专业部门。

  为了实现在统一定义的必要性和成本之间取得平衡，制订数据标准规范，明确了在不同情况下哪些数据应该制订统一的标准。

  1. 描述业务对象的特有属性应作为本业务对象的属性进行定义，并明确业务数据标准。

  2. 引用其他业务对象的属性，如果属性值可随本业务对象确定和更改，就应作为本业务对象的属性进行定义，并明确业务数据标准。

  3. 引用其他业务对象的属性，如果属性值取自引用业务对象相应时点的数值且后续不变更，就应纳入本业务对象的数据标准范围， 并明确相应取值规则。

     引用其他业务对象的属性，如果属性值与引用业务对象同步，就不需要重新定义数据标准。
     引用其他业务对象/逻辑数据实体的身份标识属性，应作为本业务对象的属性进行定义，但只能在业务数据标准中定义出处及引用规则，而不允许修改或重新定义该属性本身的业务含义及业务规则。

• 数据模型

  数据模型是从数据视角对现实世界特征的模拟和抽象，根据业务需求抽取信息的主要特征，反映业务信息（对象）之间的关联关系。 数据模型不仅能比较真实地模拟业务（场景），同时也是对重要业务模式和规则的固化。

• 数据分布

  如果说前三个组件主要是从静态角度对数据、数据关系进行定 义，那么数据分布则定义了数据产生的源头及在各流程和IT系统间的流动情况。数据分布组件的核心是数据源，指业务上首次正式发布某项数据的应用系统，并经过数据管理专业组织认证，作为企业范围内唯一数据源头被周边系统调用。公司规定所有业务数据必须认证数据源，并在公司范围内统一发布。为了更好地识别、管理数据在流程和IT系统间的流动，可以通过信息链、数据流来进行描述，体现某一数据 在 流程或应用系统中是如何被创建（ Create ） 、 读 取 （Read）、更新（Update）、删除（Delete）的。

信息架构原则：建立企业层面的共同行为准则

1. 数据按对象管理，明确数据Owner

   在公司层面确定数据Owner。华为公司按照业务对象任命数据Owner，并且每个数据都只能有唯一的数据Owner。数据Owner要负责所辖领域的信息架构建设和维护，负责保障所辖领域的数据质量，承接公司各个部门对本领域数据的需求，并有责任建立数据问题回溯和奖惩机制，对所辖领域的数据问题及争议进行裁决，公司有权对不遵从信息架构或存在严重数据质量问题的责任人进行问责。

2. 从企业视角定义信息架构

   任何一个数据Owner都不只代表自己所辖业务范围的数据管理诉求，而是代表公司对数据进行管理。

   以前面的合同编号为例，销售部门作为数据Owner有责任定义合同信息架构，但不应只考虑销售环节对合同编号的管理诉求，而是应该综合考虑供应、交付、财经等各个环节对合同的诉求，合同在整个交易链条中延伸的范围就是相应数据Owner所综合覆盖的范围。在这个链条中，任何业务部门对合同编号的诉求，都可以提交给数据Owner；同时，合同数据Owner对所辖数据在整个企业范围内的架构的合理性和一致性负责，如果某个业务环节私自定义了合同信息架构，那么数据 Owner有责任对该架构进行统一和整改。

3. 遵从公司的数据分类管理框架

   为了协同企业内各业务领域的数据治理，在实践中总结了各类数据的内在特性，制定了统一的数据分类管理框架，公司所有业务领域按照统一的分类框架进行数据治理。

4. 业务对象结构化、数字化

   在长期的数据治理过程中，制定了业务对象结构化、数字化的架构设计原则，实现数据处理效率的提升，构建数据的处理和应用能力，支撑业务管理。

   业务对象内容包括业务结果、业务规则、业务过程，并应打造相应的数字化能力。

5. 数据服务化，同源共享

   每一个 数据有且只有单一数据源，数据使用方应从数据源获取数据，数据更改应在数据源进行。为了克服企业业务和IT的复杂性这一客观现实， 公司持续推进数据服务建设，要求各数据Owner通过数据服务向各 业务环节提供数据，各业务环节也有责任通过服务来合理获取数据， 从而在整个企业层面实现数据的“一点定义、全局共享”。

信息架构建设核心要素：基于业务对象进行设计和落地

• 按业务对象【业务领域中重要的人、事、物对象】进行架构设计

判定业务对象的四个原则：

1. 业务对象是指企业运作和管理中不可缺少的重要人、事、物
2. 业务对象有唯一身份标识信息
3. 业务对象相对独立并有属性描述
4. 业务对象可实例化

• 按业务对象进行架构落地

  架构在落地过程中“不走形”，要控制好两个关键点： 一个是概念模型与逻辑模型的一致性，主要通过逻辑数据实体的设计管理来实现；另一个是逻辑模型与物理模型的一致性，主要通过一体化建模管理来实现。

• 传统信息架构向业务数字化扩展：对象、过程、 规则

  • 对象数字化

    对象数字化的目标是建立对象本体在数字世界的映射。这种映射 不是传统意义上基于流程要求的少量数据的管理，而是管理某个对象的全量数据

  • 过程数字化

    过程数字化要实现业务活动线上化，并记录业务活动的执行或操作轨迹，一般通过观测数据来实现轨迹记录

  • 规则数字化

    规则数字化的目的是把复杂场景下的复杂规则用数字化手段进行管理。良好的规则数字化管理，应该能实现业务规则与IT应用解耦， 所有关键业务规则数据要实现可配置，能够根据业务的变化灵活调整

面向“联接共享”的数据底座建设( 1️⃣)

数据底座的总体架构

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

数据底座的建设策略

数据Owner是各领域数据底座建设的第一责任人，各领域数据部负责执行

数据底座资产建设遵从下面四项原则

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

数据湖

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

数据湖主要有以下几个特点：1）逻辑统一 2）类型多样 3）原始记录

• 数据入湖的6个标准

  • 明确数据Owner
  • 发布数据标准
  • 认证数据源
  • 定义数据密级
  • 数据质量评估
  • 元数据注册

• 数据入湖方式

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

  数据入湖的方式主要有物理入湖和虚拟入湖两种，根据数据消费的场景和需求，一个逻辑实体可以有不同的入湖方式。物理入湖是指将原始数据复制到数据湖中，包括批量处理、数据复制同步、消息和流集成等方式。虚拟入湖是指原始数据不在数据湖中进行物理存储，而是通过建立对应虚拟表的集成方式实现入湖，实时性强，一般面向小数据量应用，大批量的数据操作可能会影响源系统。
  数据入湖有以下5种主要技术手段。

  1. 批量集成（Bulk/Batch Data Movement）
     对于需要进行复杂数据清理和转换且数据量较大的场景，批量集成是首选。通常，调度作业每小时或每天执行，主要包含ETL、ELT和 FTP等工具。批量集成不适合低数据延迟和高灵活性的场景
  2. 数据复制同步（Data Replication/Data Synchronization）
     适用于需要高可用性和对数据源影响小的场景。使用基于日志的 CDC捕获数据变更，实时获取数据。数据复制同步不适合处理各种数据结构以及需要清理和转换复杂数据的场景。
  3. 消息集成（Message-Oriented Movement of Data）
     通常通过API捕获或提取数据，适用于处理不同数据结构以及需要高可靠性和复杂转换的场景。尤其对于许多遗留系统、ERP和SaaS来说，消息集成是唯一的选择。消息集成不适合处理大量数据的场景。
  4. 流集成（Stream Data Integration）
     主要关注流数据的采集和处理，满足数据实时集成需求，处理每秒数万甚至数十万个事件流，有时甚至数以百万计的事件流。流集成不适合需要复杂数据清理和转换的场景。
  5. 数据虚拟化（Data Virtualization）
     对于需要低数据延迟、高灵活性和临时模式（不断变化下的模式）的消费场景，数据虚拟化是一个很好的选择。在数据虚拟化的基础上，通过共享数据访问层，分离数据源和数据湖，减少数据源变更带来的影响，同时支持数据实时消费。数据虚拟化不适合需要处理大 量数据的场景。

结构化数据入湖

结构化数据是指由二维表结构来逻辑表达和实现的数据，严格遵循数据格式与长度规范，主要通过关系型数据库进行存储和管理。

触发结构化数据入湖的场景有两种：

1. 企业数据管理组织基于业务需求主动规划和统筹
2. 响应数据消费方的需求

结构化数据入湖过程包括

数据入湖需求分析及管理、检查数据 入湖条件和评估入湖标准、实施数据入湖、注册元数据。

非结构化数据入湖

非结构化数据更难以标准化和理解，因而非结构化数据的管理不仅包括文件本身， 而且包括对文件的描述属性，也就是非结构化的元数据信息。这些元数据信息包括文件对象的标题、格式、Owner等基本特征， 还包括对数据内容的客观理解信息，如标签、相似性检索、相似性连接等。

• 非结构化数据入湖的4种方式

  非结构化数据入湖包括基本特征元数据入湖、文件解析内容入湖、文件关系入湖和原始文件入湖4种方式，其中基本特征元数据入湖是必选内容，后面三项内容可以根据分析诉求选择性入湖和延后入湖，如图所示。

  • 基本特征元数据入湖
    主要通过从源端集成的文档本身的基本信息入湖。入湖的过程中，数据内容仍存储在源系统，数据湖中仅存储非结构化数据的基本特征元数据。基本特征元数据入湖需同时满足如下条件

    已经设计了包含基本特征元数据的索引表。 已经设计了信息架构，如业务对象和逻辑实体。 已经定义了索引表中每笔记录对应文件的Owner、标准、密级，认证了数据源并满足质量要求。

  • 文件解析内容入湖
    对数据源的文件内容进行文本解析、拆分后入湖。**入湖的过程中，原始文件仍存储在源系统，数据湖中仅存储解析后的内容增强元数据。**内容解析入湖需同时满足如下条件。

    • 已经确定解析后的内容对应的Owner、密级和使用的范围。
    • 已经获取了解析前对应原始文件的基本特征元数据。
    • 已经确定了内容解析后的存储位置，并保证至少一年内不会迁移。

  • 文件关系入湖

    根据知识图谱等应用案例在源端提取的文件上下文关系入湖。入湖的过程中，原始文件仍存储在源系统，数据湖中仅存储文件的关系等内容增强元数据。文件关系入湖需同时满足如下条件：

    • 已经确定文件对应的Owner、密级和使用的范围。
    • 已经获取了文件的基本特征元数据。
    • 已经确定了关系实体的存储位置，并保证至少一年内不会迁移。

  • 原始文件入湖
    根据消费应用案例从源端把原始文件搬入湖。数据湖中存储原始文件并进行全生命周期管理。原始文件入湖需同时满足如下条件。

    • 已经确定原始文件对应的Owner、密级和使用的范围。
    • 已经获取了基本特征元数据。
    • 已经确定了存储位置，并保证至少一年内不会迁移。

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

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

• 多维模型

  面向业务的多视角、多维度的分析，通过明确的业务关系，建立基于事实表、维度表以及相互间联接关系，实现多维数据查询和分析

  如，对订货数据从时间、区域、产品、客户等维度进行多视角、不同粒度的查询和分析

  维度设计需要满足：1.单一性、2.单向性、3.正交性

  多维模型设计有4个主要步骤，包括确定业务场景、声明粒度、维度设计和事实表设计

• 图模型

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

  节点表示实体或概念，边则由属性或关系构成。实体指的是具有可区别性且独立存在的某种事物，如某一个 人、某一个城等，是图模型中的最基本元素；概念是对特征的组合而形成的知识单元，主要指集合、类别、 对象类型、事物的种类，例如人物、地理等；属性主要指描述实体或 概念的特征或特性，例如人员的国籍、生日等

  标签分为事实标签、规则标签和模型标签

• 标签

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

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

• 指标

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

  指标一般由指标名称和指标数值两部分组成，指标名称及其含义体现了指标在质的规定性和量的规定性两个方面的特点；指标数值反映了指标在具体时间、地点、条件下的数量表现。
  可以把指标分为原子指标和复合指标两种类型。
  1、原子指标是指标数据通过添加口径/修饰词、维度卷积而成，口径/修饰词、维度均来源于指标数据中的属性。
  2、复合指标由一个或多个原子指标叠加计算而成，其中维度、口径/ 修饰词均继承于原子指标，不能脱离原子指标维度和口径/修饰词的范 围去产生新的维度和口径/修饰词。指标和数据的关系如图所示。

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

• 算法模型

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

  算法是指训练、学习模型的具体计算方法，也就是如何求解全局最优解，并使得这个过程高效且准确，其本质上是求数学问题的最优化解，即算法是利用样本数据生成模型的方法。算法模型是根据业务需求，运用数学方法对数据进行建模，得到业务最优解，主要用于业务智能分析。
  算法模型管理框架包括建模、 模型资产管理和模型消费。算法模型的设计步骤主要有需求评估、数据准备、方案设计和建模与验证。

面向“自助消费”的数据服务建设( 2️⃣)

数据服务是基于数据分发、发布的框架，将数据作为一种服务产品来提供，以满足客户的实时数据需求，它能复用并符合企业和工业标准，兼顾数据共享和安全

数据服务建设策略

1）要制定数据服务建设的方法，确保每个从事数据服务建设的人都明白数据一致性的要求，并且所提供的数据是可信的和清洁的。
2）要建立数据服务流程，以确保各个环节的有效协同，定义整个生命周期中每个角色的责任和有效输出。
3）要构建统一的数据服务能力中心，负责数据服务建设方法、规范、流程的落地，数据服务不同于传统集成方式，因此应该有统一的平台提供能力保障。

数据服务生命周期管理

完整的数据服务生命周期包括服务识别与定义、服务设计与实现、服务运营三个主要阶段。

1. 服务识别与定义

   业务与数据握手，识别服务的业务价值、准入条件与服务类型，减少数据服务的重复建设，提升数据服务的重用度。

2. 服务设计与实现

   业务、数据、IT三方协同，使设计、开发、测试与部署快速迭代以实现服务的敏捷交付，缩短数据服务的建设周期。

   在服务设计与实现阶段，要定义服务契约和数据契约，重点明确服务契约所涉及的服务责任主体、处理逻辑，并以数据契约规范服务的数据格式与数据的安全要求。通过服务契约与数据契约，可以有效地管理在数据交互中可能存在的安全风险，数据供应方可以将一些安全要求通过契约实现。同时，供应方能够通过契约了解哪些消费者获取了数据以及使用的数量和频率等

   • 服务契约：包括服务的基本信息（数据服务提供方、数据服务的类型）、能力要求（服务的时效性、服务的处理逻辑、服务的安全策略、服务的SLA要求）等。
   • 数据契约：包括数据契约描述、输入和输出参数、业务数据资产编码、物理落地资产编码等。

   服务的颗粒度

   数据服务设计中应强调数据服务的颗粒度，数据服务颗粒度的大小直接影响着服务的可重用性和系统的整体性能，数据服务颗粒度通常应考虑的原则，如下：。
   1）业务特性：将业务相近或相关、数据粒度相同的数据设计为一个 数据服务。
   2）消费特性：将高概率同时访问、时效性要求相同的数据设计为一 个数据服务。
   3）管理特性：综合考虑企业在数据安全管理策略方面的要求。
   4）能力特性：将单一能力模型设计为一个服务。

   基于上述原则，可以形成一些具体的用于指导实际执行的参考规范
   1）同一种提供形式下，一个数据只能设计在一个数据服务中。
   2）按主题（业务对象）将相同维度的数据设计为一个数据服务。如果同一个主题下的指标数量过多，则需要考虑按“高概率同时使用、业务关联度紧密”的原则再进行划分。
   3）将同一个逻辑实体的数据设计为一个数据服务。
   4）将单一功能的算法、应用模型设计为一个服务。

3. 服务运营

   通过统一数据服务中心及服务运营机制，保障服务SLA 与持续优化

数据服务分类：数据集服务和数据API服务

数据集服务定义
比较常见的数据消费者有两类：一类是真实的“人”，一类是 “IT系统”。消 费者是“访问”某个相对完整的“数据集”，这种消费方式称之为 “数据集服务”。数据集服务最主要的特征是由服务提供方提供相对完整的数据集合，消费方“访问”数据集合，并自行决定接下来的处理逻辑，如图所示。

数据服务提供方被动地公开数据以供数据消费方检索。
数据服务提供方并不定义数据处理逻辑，但数据和数据处理逻辑 仍然由其控制。
数据服务的生命周期即数据访问授权的有效期。

数据API服务

数据服务的另外一类消费者是“IT系统”，即面向某个IT系统提 供数据事件驱动的“响应”，这种服务的封装方式与前面所提到的数 据集不同，称为“数据API服务”

数据API服务是对用户随机数据事件的响应，这个需求往往伴随着用户的某个任务产生，随着任务的结束，整个服务也就完成了。通过数据API服务，用户可以及时地获知任务的协同情况，并基于服务方的反馈结果，做出相应的调整。服务供给方和消费方是协同关系（互操 作），而非交接棒关系（交换情报），有效提升了面向协同任务的互操作一致性。

数据服务的另外一类消费者是“IT系统”，即面向某个IT系统提供数据事件驱动的“响应”，这种服务的封装方式与前面所提到的数据集不同，称为“数据API服务”。

数据服务提供方基于随机的数据事件主动地传送数据。

数据服务提供方会基于事件定义数据处理逻辑，由消费方提前订阅并随机触发。

服务的生命周期跟着事件走，事件关闭了，服务就终止了。

打造“清洁数据”的质量综合管理能力( 2️⃣)

数据质量不是追求100%，而是从数据使用者的角度定义，满足业务、用户需要的数据即为“好”数据。数据质量指“数据满足应用的可信程度”，从以下六个维度对数据质量进行描述：
1、完整性：指数据在创建、传递过程中无缺失和遗漏，包括实体完整、属性完整、记录完整和字段值完整四个方面。完整性是数据质量最基础的一项，例如员工工号不可为空。
2、及时性：指及时记录和传递相关数据，满足业务对信息获取的 时间要求。数据交付要及时，抽取要及时，展现要及时。数据交付时间过长可能导致分析结论失去参考意义。
3、准确性：指真实、准确地记录原始数据，无虚假数据及信息。 数据要准确反映其所建模的“真实世界”实体。例如员工的身份信息必须与身份证件上的信息保持一致。
4、一致性：指遵循统一的数据标准记录和传递数据和信息，主要 体现在数据记录是否规范、数据是否符合逻辑。例如同一工号对应的不同系统中的员工姓名需一致。
5、唯一性：指同一数据只能有唯一的标识符。体现在一个数据集 中，一个实体只出现一次，并且每个唯一实体有一个键值且该键值只指向该实体。例如员工有且仅有一个有效工号。
6、有效性：指数据的值、格式和展现形式符合数据定义和业务定义的要求。例如员工的国籍必须是国家基础数据中定义的允许值。

数据质量规则

异常数据是不满足数据标准、不符合业务实质的客观存在的数据，如某位员工的国籍信息错误、某位客户的客户名称信息错误等。
数据在底层数据库多数是以二维表格的形式存储，每个数据格存储一个数据值。若想从众多数据中识别出异常数据，就需要通过数据质量规则给数据打上标签。

数据质量规则是判断数据是否符合数据质量要求的逻辑约束。在整个数据质量监控的过程中，数据质量规则的好坏直接影响监控的效果，因此如何设计数据质量规则很重要。设计如下四类数据质量分类框架：
1、单列数据质量规则。关注数据属性值的有无以及是否符合自身规范的逻辑判断。
2、跨列数据质量规则。关注数据属性间关联关系的逻辑判断。
3、跨行数据质量规则。关注数据记录之间关联关系的逻辑判断。
4、跨表数据质量规则。关注数据集关联关系的逻辑判断。

据质量规则一般以业务属性（即数据列）为对象，数据质量规则类型为颗粒度进行设计和应用

并不是每一个属性都会涉及上述15类规则

异常数据监控

质量控制是通过监控质量形成过程，消除全过程中引起不合格或不满意效果的因素，以达到质量要求而采用的各种质量作业技术和活动。要保证最终交付质量，必须对过程进行质量控制，通常是在过程中设置关键质量控制点。例如，可以在数据录入阶段设置规则程序，从源头避免不可接受的数据进入系统。
数据质量控制的目的是致力于满足数据质量要求，消除或减少异常数据。数据质量控制可以在数据的生命周期内的不同时点被应用，来测试数据的质量和其是否适合于其所在的系统。
异常数据监控分为以下三个步骤：
1、识别监控对象范围，确定监控内容
2、数据源剖析
3、设计和配置监控规则，自动监测异常数据

设计质量度量

从信息架构的四个角度（数据资产目录、数据标准、数据模型、数据分布）进行综合评估

执行质量度量

从数据质量六性（一致性、完整性、及时性、唯一性、有效性、准确性）评估数据内容的清洁度，涉及三个要素：客户关注重要性、法律财务风险性、业务流程战略性。业务领域也可根据阶段性的管理重点和诉求调整评估的要素。

客户关注重要性：给客户运营带来直接影响的数据的客户关注重要性就高，如合同、PO、验收标准、开票数据等。

法律财务风险性：与法律、财务的关联性强，一旦发生质量问题，会触犯法律或带来相关财务损失，那么该数据的法律财务风险性就高，如收入、成本等数据

业务流程战略性：数据所产生的业务流程如果是公司核心交易流程（如LTC流程）或战略地位高的流程（如IPD流程），那么数据 的业务流程战略性普遍会得到较高关注；如果是相关支撑或使能流程（如变革流程、IT开发流程等），那么数据的业务流程战略性相对较弱。关键数据对象评分表如下。

PDCA循环：通过管理层 （ST）的管理评审以及变革与改进的规划，识别变革与改进项目，每个项目按照规范的项目群管理运作流程或者改进过程框架实施改进。改进成果固化到流程及管理体系中并实施推广执行，执行后再通过质 量组织进行客户满意度管理、度量、审核与变革进度指标评估等，将再次识别改进作为管理评审的输入，最终形成大的改进循环。

数据质量控制和数据质量改进的关系

质量活动通常分为两类：维持与改善。维持是指维持现有的数据质量水平，其方法是数据质量控制；改善是指改进目前的数据质量，其方法是主动采取措施，使数据质量在原有的基础上有突破性的提高，即数据质量改进。从结果的角度来说，数据质量控制的目的是维持某一特定的质量水平，控制系统的偶发性缺陷；而数据质量改进则是对某一特定的数据质量水平进行“突破性”的提升，使其在更高的目标水平下处于相 对平衡的状态。控制是日常进行的工作，可以纳入流程体系的“操作 规程”中加以贯彻执行，最好的手段就是纳入流程体系进行标准化。 质量改进则是一项阶段性的工作，达到既定目标之后，该项工作就完成了。质量改进的最终效果比原来维持下的效果好得多，这种工作必然需要精心策划。质量改进要固化在流程体系中进行标准化，通过质量控制使得标准化的流程得以实施，达到新的质量水平。质量控制是质量改进的前提，控制就意味着维持以前的质量水平，是PDCA改进循环中保证水平不下降的“努力的楔子”，是保证下 一次改进的起点，而改进则是在起点基础上的变革和突破。如果不做好质量控制，质量水平就会下降，下次又在低水平重复，因此不能只关注质量改进，改进后关键还是要实施质量控制，二者交替进行，相辅相成。

打造“安全合规”的数据可控共享能力( 2️⃣)

数据安全防护关键技术

1. 大数据加密技术
2. 访问控制技术：主要分为自主访问控制和强制访问控制
3. 安全威胁的预测分析技术
4. 大数据稽核和审计技术：对大数据系统内部系统间或服务间的隐秘存储通道进行稽核 ，对大数据平台发送和接收信息进行审核，可以有效发现大数据平台内部的信息安全问题，从而降低大数据的信息安全风险
5. 大数据安全漏洞：主要是指大数据平台和服务程序由于设计缺陷或人为因素留下的后门和问题，安全漏洞攻击者能够在未授权的情况下利用该漏洞访问或破坏大数据平台及其数据。
6. 基于大数据的认证技术：利用大数据技术采集用户行为及设备行为的数据，并对这些数据进行分析，获得用户行为和设备行为特征，进而通过鉴别操作者行为及其设备行为来确定身份，实现认证，从而能够弥补传统认证技术中的缺陷

数据安全治理绝不是一套IT工具组合的产品级解决方案，而是从决策层到技术层、从管理制度到工具支撑，自上而下贯穿整个组织架构的完整链路。

建以元数据为基础的安全隐私保护框架

数据安全隐私分层分级管控策略

从公司层面，通过对整体内外部安全隐私管理政策的解读，将内部信息密级维度分为五类，要求组织间共享时一致遵从：外部公开、内部公开、秘密、机密、绝密

基于业务管理的诉求，以内部信息密级维度为基础，从资产的维度增加两类划分，进行针对性管理：核心资产（绝密信息）、关键资产（机密信息）

数据底座安全隐私分级管控方案

1）数据底座安全隐私管理政策：说明数据底座的责任边界，数据风险标识标准、数据加工、存储、流转规范。
2）数据风险标识方案：平台提供的数据标识能力。
3）数据保护能力架构：数据底座分级存储架构能力。
4）数据组织授权管理：数据在组织内共享的规则。
5）数据个人权限管理：个人访问数据的权限管理方案。

在数据安全方面，根据公司信息保密规定，数据底座安全管理总 体原则与数据管理原则是一致的，即“核心资产安全优先，非核心资产效率优先”。

在隐私保护方面，根据公司隐私保护总体纲领文件和数据底座自身的特点，发布了数据底座隐私保护规定，总体原则是“个人数据原则上不入湖，并尽可能脱敏处理”

“静”“动”结合的数据保护与授权管理

1. 静态控制：数据保护能力架构

   数据保护能力包括存储保护、访问控制、可追溯三种

   1. 存储保护

      • 高防区隔离：高防区隔离就是我们通过在数据底座独立部署单独的防火墙以及配合流向控制、堡垒机等措施，对高密资产重点防护。关键要点就是有独立的防火墙，并且内部区分脱敏开发区以及明文业务访问区，让数据开发人员在脱敏区工作。高防区数据经过审核后才能发布到明文区，给业务部门使用。
      • 透明加密：透明加密就是对表空间进行加解密，进入表空间的表自动加密，有权限的应用读取表空间的表时就自动解密。主要用于防止黑客把库文件搬走。
      • 对称加密：对称加密指应用对数据字段应用对称加密算法进行加密，需要配合统一的密钥管理服务使用。
      • 静态脱敏：首先需要从技术角度制定出脱敏标准。脱敏不是单 一的技术能力，而是多种脱敏算法的合集，包括加噪、替换、模糊等，每种数据类型应该有不同的脱敏标准。我们在ETL集成工具中增加脱敏API能力，可以对具体的字段进行脱敏，每类数据字段都依据脱敏标准执行。

   2. 访问控制

      动态脱敏则是一项基于身份的访问控制。通常Web应用都是使用自己的菜单和角色权限进行职责分离，对于数据权限，很难做到字段级别的控制。而动态脱敏可以对某些数据表、数据字段根据身份进行脱敏，从而做到更细颗粒度的保护。

   3. 可追溯

      在可追溯方面，业界有比较成熟的数据水印技术。简单来说，是直接改动数据，在数据行、数据列中增加水印，不影响数据的关联与计算，适用于核心资产或敏感个人数据。一旦发生泄露，可以溯源定责

2. 动态控制：数据授权与权限管理

   • 数据授权主要是面向组织，指数据Owner对组织授予数据访问权的过程，让数据与组织绑定，为组织提供长期的数据订阅权限。数据授权包含两个场景。
     1）数据加工授权：由于数据主题联接资产建设中需要跨组织进行数据联接、加工、训练需要转移数据而发生的数据授权场景。
     2）数据消费授权：由于业务用户数据的分析需要订阅数据服务而发生的数据授权场景。
   • 数据权限管理，是基于访问管控规范，对授予的数据访问权限进行 管理的过程

数据所有权管理针对的是数据提供，确保数据同源可信，数出一孔；数据主权管理针对的是数据访问与使用，确保数据安全共享，防止数据滥用。

打造“数字孪生”的数据全量感知能力( 3️⃣)

数据感知可分为“硬感知”和“软感知”，面向不同场景。“硬 感知”主要利用设备或装置进行数据的收集，收集对象为物理世界中 的物理实体，或者是以物理实体为载体的信息、事件、流程等。而 “软感知”使用软件或者各种技术进行数据收集，收集的对象存在于数字世界，通常不依赖物理设备进行收集。
感知产生的数据还是孤立的物理对象的镜像，需要在企业这一复 杂对象内部与其他数据资产一起，与流程、运营和指标之间建立关系，纳入企业的信息架构进行管理，才能真正打通从数据感知、生成到消费的链路。