华为数据之道总结
第一章 数据驱动的企业数字化转型
1.1 非数字原生企业的数字化转型挑战
1.1.1 业态特征：产业链条长、多业态并存
1.1.2 运营环境：数据交互和共享风险高
1.1.3 IT建设过程：数据复杂、历史包袱重
1.1.4 数据质量：数据可信和一致化的要求程度高
1.2 华为数字化转型与数据治理
解决企业两大问题：成本和效率
1.2.1 华为数字化转型整体目标
明确要面向用户（企业客户、消费者、员工、合作伙伴、供应商）实现ROADS体验，持续提升效率、效益和客户满意度。逐步构建以"面向客户做生意"和"基于市场的创新"两个业务流为核心的"端到端"的数字化管理体系。
对内：各业务领域数字化、服务化，打通跨领域的信息断点，达到领先于行业的运营效率。
对外：ROADS：实时（Real-time）、按需（On-demand）、全在线（All-online）、服务自助（DIY）和社交化（Social）。
1.2.2 华为数字化转型蓝图及对数据治理的要求
统一规划、分层次展开，最终实现交互方式的转变，实现内部运营效率和效益的提升。
举措1：实现"客户交互方式"的转变，用数字化手段做厚、作深客户界面，实现与客户做生意更简单、更高效、更安全，提升客户体验满意度，帮助客户解决问题。
举措2：实现"作战模式"的转变，围绕两大主业务流，以项目为中心，对准一线精兵团队作战，率先实现基于ROADS的体验，达到领先于行业的运营效率。
举措3：实现"平台能力"提供方式的转变，实现关键业务对象的数字化并不断汇聚数据，实现流程数字化和能力化，支撑一线作战人员和客户的全连接。
举措4：实现"运营模式"的转变，基于统一数据底座，实现数字化运营与决策，简化管理，加大对一线人员的授权。此举措涉及数据治理和数字化运营，是华为数字化转型的关键，承接了打破数据孤岛、确保源头数据准确、促进数据共享、保障数据隐私与安全等目标。
举措5：云化、服务化的IT基础设施和IT应用，统一公司IT平台，同时构建智能服务。
华为数字化转型对数据治理的要求如下：
1）基于统一的数据管理规则，确保数据源头质量以及数据入湖，形成清洁、完整、一致的数据湖。
2）业务与数据双驱动，加强数据联接建设，并能够以数据服务方式，灵活满足业务自助式的数据消费需求。
3）针对汇聚的海量内外部数据，能够确保数据安全合规。
4）不断完善业务对象、过程和规则数字化，提升数据自动采集能力，减少人工录入。
1.3 华为数据治理实践
1.3.1 华为数据治理历程
第一阶段：设立数据管理专业组织，建立数据管理框架，发布数据政策，任命数据Owner，通过统一信息架构与标准、唯一可信的数据源、有效的数据质量度量改进机制，实现了：
1）持续提升数据质量，减少纠错成本：通过数据质量度量与持续改进，确保数据真实反映业务，降低运营风险。
2）数据全流程贯通，提升业务运作效率：通过业务数字化、标准化，借助IT技术，实现业务上下游信息快速传递、共享。
第二阶段：建设数据底座，汇聚企业全域数据并对数据进行联接，通过数据服务、数据地图、数据安全防护与隐私保护，实现了数据随需共享、敏捷自助、安全透明的目标。实现了：
1）业务可视，能够快速、准确决策：通过数据汇聚，实现业务状态透明可视，提供基于"事实"的决策支持依据。
2）人工智能，实现业务自动化：通过业务规则数字化、算法化，嵌入业务流，逐步替代人工判断。
3）数据创新，成为差异化竞争优势：基于数据的用户洞察，发现新的市场机会点。
1.3.2 华为数据工作的愿景与目标
愿景：实现业务感知、互联、智能和ROADS体验，支撑华为数字化转型
目标：清洁、透明、智慧数据，使能卓越运营和有效增长
实现愿景与目标所需的条件：数据自动采集、对象/规则/过程数字化、数据清洁、安全共享等特性
1.3.3 华为数据工作建设的整体思路和框架
建设思路：一方面要充分利用现有IT系统的存量数据资产；另一方面要构建一条从现实世界直接感知、采集、汇聚数据到数字世界的通道，不断驱动业务对象、过程与规则的数字化。
建设框架：
1）数据源：业务数字化是数据工作的前提，通过业务对象、规则与过程数字化，不断提升数据质量，建立清洁、可靠的数据源。
2）数据湖：基于"统筹推动、以用促建"的建设策略，严格按六项标准，通过物理与虚拟两种入湖方式，汇聚华为内部和外部的海量数据，形成清洁、完整、一致的数据湖。
3）数据主题联接：通过五种数据联接方式，规划和需求双驱动，建立数据主题联接，并通过服务支撑数据消费。
4）数据消费：对准数据消费场景，通过提供统一的数据分析平台，满足自助式数据消费需求。
5）数据治理：为保障各业务领域数据工作的展开，需建立统一的数据治理能力，如数据体系、数据分类、数据感知、数据质量、安全和隐私等。
第二章 建立企业级数据综合治理体系
2.1 建立公司级的数据治理政策
数据治理政策是华为数据治理的顶层设计，该政策在华为公司EMT（经营管理团队）汇报通过后，由总裁签发，该政策明确了数据工作在华为公司数据治理体系中的地位，体现了公司管理层对数据工作重要性的统一认知。
2.1.1 华为数据管理总纲
华为数据管理总纲明确了数据治理最基本的原则，包括信息架构、数据产生、数据应用及数据质量的职责和分工等，确保数据治理环境的有效构建。
（1）信息架构管理原则
第一条：建立企业级信息架构，统一数据语言。
第二条：所有变革项目须遵从数据管控要求。对于不遵从管控要求的变革项目，数据管控组织拥有一票否决权。
第三条：应用系统设计和开发应遵从企业级信息架构。关键应用系统必须通过应用系统认证。
（2）数据产生管理原则
第一条：数据规划对齐业务战略，业务战略规划必须包含关键数据举措及其路标规划。
第二条：公司数据Owner拥有公司数据管理的最高决策权，依托ESC（变革指导委员会）决策平台议事。各数据Owner承担数据工作路标、信息架构、数据责任机制和数据质量的管理责任。
第三条：关键数据须定义单一数据源，一点录入，多点调用。数据质量问题应在源头解决。
第四条：谁产生数据，谁对数据质量负责。数据Owner负责基于使用要求制定数据质量标准，且须征得关键使用部门的同意。
（3）数据应用管理规则
第一条：数据应在满足信息安全的前提下充分共享，数据产生部门不得拒绝跨领域的、合理的数据共享需求。
第二条：信息披露、数据安全管理、数据保管和个人数据隐私保护等必须遵循法律法规和道德规范的要求。公司保护员工、客户、商业伙伴和其他可识别个体的数据。
（4）数据问责与奖惩管理原则
各数据Owner应建立数据问题回溯和奖惩机制。对不遵从信息架构或存在严重数据质量问题的责任人进行问责。
2.1.2 信息架构管理政策
信息架构是公司统一的数据语言，是业务流打通、消除信息孤岛和提升业务流集成效率的关键要素。
（1）管理信息架构的角色与职责
第一条：公司数据Owner负责批准企业级信息架构，裁决重大信息架构问题和争议。
第二条：各数据Owner负责其所暇数据信息架构建设和维护，承接及落实公司的数据规划要求。
第三条：公司的数据管理专业组织作为公司数据工作的支撑组织，负责组织信息架构的建设、维护、落地及遵从管控，负责协调跨领域的信息架构冲突。各领域各事业群（BG）数据管理专业组织协助完成本领域信息架构建设和维护工作。
第四条：数据管控组织作为信息架构专业评审机构，确保信息架构的质量和集成。
（2）信息架构建设要求
第一条：关键数据应被识别、分类、定义及标准化，数据的定义在公司范围内应唯一，数据标准定义要考虑跨流程要求。
第二条：数据资产目录必须承接公司各业务环节的使用需求和报告分析最小粒度的要求。
第三条：信息架构驱动应用架构设计，合理规划数据分布。
第四条：应用系统数据库的设计和开发要遵循信息架构，减少数据冗余，实现接口标准化。
（3）信息架构遵从管控
第一条：变革项目必须遵从已发布的信息架构，变革项目的交付须包含信息架构内容。对现有架构的遵从是关键评审要素，对于不满足要求的变革项目，数据管控组织拥有一票选择权。
第二条：业务流程设计必须遵从已发布的信息架构，在流程说明文件、操作指导书或模版类文件中体现。对于不满足要求的流程，不予发布。
第三条：应用系统设计必须遵从已发布的信息架构。在应用架构交付件和应用系统设计交付件中体现。对于不满足要求的应用系统，不予上线。
2.1.3 数据源管理政策
数据源是指业务上首次正式发布某项数据的应用系统，经过数据管理专业组织认证，作为唯一数据源头被周边系统调用。
（1）数据源管理原则
第一条：所有关键数据必须认证数据源。关键数据是指影响公司经营、运营报告的数据，在公司范围内统一发布。
第二条：数据管理专业组织为关键数据指定源头，数据源必须遵从信息架构和标准，经信息架构专家委员会认证后成为数据源。
第三条：所有关键数据仅能在数据源录入、修改，全流程共享，其他调用系统不能修改。下游环节发现的数据源质量问题，应当在数据源进行修正。
第四条：所有应用系统必须从数据源或数据源镜像获取关键数据。
第五条：数据Owner确保数据源的数据质量，对不符合数据质量标准的数据源，必须限期整改。
（2）数据源认证标准
第一条：数据源是在信息链上正式发布数据的第一个数据存储系统。
第二条：数据源是某项数据唯一的录入点。
第三条：数据源必须是数据维护最为及时、正确、完整的数据存储系统。
第四条：数据源所在系统的性能和可用性应当满足其他调用系统的数据访问需求。
2.1.4 数据质量管理政策
通过制定数据质量管理政策，明确数据在创建、维护、应用过程中的规则及质量要求，确保数据真实可靠。
（1）数据质量管理职责及要求
第一条：各数据Owner负责保障所辖数据的质量，承接公司数据Owner设定的数据质量目标，制定数据质量标准及测评指标，持续度量与改进。
第二条：公司全员在业务执行过程中应确保业务记录满足数据质量要求。
第三条：财经各级CFO组织应遵循职业道德准则，诚实记录和报告财经数据，承担财务监控和及时报告责任。
第四条：公司各级数据管理专业组织为数据Owner提供数据质量管理专业支撑。
第五条：内控组织应将数据质量管控要素的执行情况纳入SACA（Semi-Annual Control Assessment，半年度控制评估）评估范围，推动数据质量问题的闭环管理。
第六条：内审部门作为独立机构，负责重大数据问题的审计和责任回溯。
（2）数据质量管理的业务规则和管理要求
第一条：流程建设应考虑数据质量要求，将数据的关键质量控制要素纳入关键控制点。
第二条：数据Owner负责基于使用要求制定数据质量标准，且须征得关键使用部门的同意。
第三条：数据创建应确保录入正确，关键数据应进行复核或审批。录入、复核和审批人员应掌握数据质量要求才能上岗。
第四条：对影响关键经营指标的数据造假行为采取零容忍态度。
第五条：上游环节应保证数据的真实、完整并及时传递到下游环节。下游环节为核实数据质量问题可调阅所需的上游环节的数据。
第六条：因外部原因频繁变化的基础数据（如汇率、税率等），数据Owner应及时维护并统一发布最新数据，各环节应适时刷新或引用。
第七条：数据质量应持续进行度量。数据Owner应主动解决长期影响业务运营和经营管理的数据问题。
第八条：报告和分析的层级和最小粒度应适度，能与最小业务信息单元相匹配。数据加工规则应相对稳定，报告加工过程可检视，数据可回溯、可解释。
2.2 融入变革、运营与IT的数据治理
2.2.1 建立管理数据流程
为了支撑企业数据资产从架构设计、质量管理到数据分析应用的全生命周期管理，需要在企业的流程架构中建立一个管理数据流程，明确数据管理的关键活动、角色，以及与周边组织的协作关系。
2.2.2 管理数据流程与管理变革项目、管理质量与运营之间的关系
企业在运营过程中，能力的提升和架构的调整依托于变革项目和改进项目的实施。变革项目和改进项目需要交付业务解决方案、数据解决方案、IT解决方案，其中数据解决方案包含信息架构设计、数据质量度量、改进方案和数据分析方案。支撑数据解决方案的角色为数据经理，数据经理统筹管理信息架构工程师、数据治理工程师、数据分析师和数据科学家，共同完成项目数据解决方案的交付和验证。
2.2.3 通过变革体系和运营体系进行决策
数据相关的重大决议由企业变革指导委员会决策，通过变革管理体系和流程运营体系实现落地。
2.2.4 数据治理融入IT实施
业务人员通过使用IT产品提供的功能和服务提升作业效率，因此，对业务数据的管理要求，必然要落实到IT产品的操作界面和数据库设计中，这样才能落实数据治理的要求。在华为的数据治理实践中，在IT产品团队中设置系统架构师和数据架构师角色，负责界面设计、数据库设计、数据集成方案设计，向上承接信息架构的设计要求。同时，在管理IT流程的设计规范中，明确界面的字段要遵从数据标准的定义，数据库表和字段的设计要承接信息架构的设计要求，从而达到数据治理融入IT实施流程的目标。
2.2.5 通过内控体系赋能数据治理
要对华为这样的大型企业实施数据治理是件非常复杂的事情，涉及上千个业务对象、上百个变革和优化改进项目的协同，仅仅通过数据管理部门对各个项目和部门的培训、指导、人员支持，不足以确保公司的治理目标和要求有效地贯彻到位。因此，华为通过内控体系，每年实施SACA评估和数据专项内部审计，揭示数据治理过程的问题，确定改进目标和责任人，从而保证数据治理机制的有效运作。
2.3 建立业务负责制的数据管理责任体系
业务即行为，行为即记录，记录即数据。公司的每一个数据，必须由对应的业务部门承担管理责任，且必须有唯一的数据Owner。
2.3.1 任命数据Owner和数据管家
分层级任命数据Owner，公司层级设置公司数据Owner，各业务领域设置领域数据Owner。公司数据Owner是公司数据战略的制定者、数据文化的营造者、数据资产的所有者和数据争议的裁决者，拥有公司数据日常管理的决策权。各级流程Owner就是该流程域的数据Owner，在公司数据Owner的统筹下负责所管理流程域的数据管理体系的建设和优化。各业务部门是执行规则，保证数据质量，进而推动规则优化的关键环节。通过主管机构正式任命各数据主题域和业务对象的数据Owner和数据管家。数据管家是数据Owner的助手，是数据Owner在数据管理方面的具体执行者。
公司数据Owner职责如下：
第一条：制定数据管理体系的愿景和路标。
第二条：传播数据管理理念，营造数据文化氛围。
第三条：建设和优化数据管理体系，包括组织与任命、授权与问责等。
第四条：批准公司数据管理的政策和法规。
第五条：裁决跨领域的数据及管理争议，解决跨领域的重大数据及管理问题。
领域数据Owner职责如下：
第一条：负责数据管理体系建设。数据Owner要负责所辖领域的数据管理体系建设和优化，传播数据管理理念，营造数据文化氛围。
第二条：负责信息架构建设。数据Owner要负责所辖领域的信息架构建设和维护，确保关键数据被识别、分类、定义及标准化，数据的定义在公司范围内唯一，数据标准制定要考虑跨流程要求。
第三条：负责数据质量管理。数据Owner要负责保障所辖领域的数据质量，承接公司设定的数据质量目标，制定数据质量标准及测评指标，持续度量与改进。
第四条：负责数据底座和数据服务建设。数据Owner要负责所辖领域数据入湖，建设数据服务，满足公司各个部门对本领域数据的需求。
第五条：负责数据争议裁决。数据Owner要建立数据问题回溯和奖惩机制，对所辖领域的数据问题及争议进行裁决，对不遵从信息架构或存在严重数据质量问题的责任人进行问责。
2.3.2 建立公司层面的数据管理组织
代表公司制定数据管理相关政策、流程、方法和支撑系统，制定公司数据管理的战略规划和年度计划并监控落实。建立并维护企业信息架构监控数据质量，披露重大数据问题，建立专业任职资格管理体系，提升企业数据管理能力，推动企业数据文化的建立和传播。
第三章 差异化的企业数据分类管理框架
目的：针对不同特性的数据采取不同的管理策略，以期实现最大的投入产出比。
3.1 基于数据特性的分类管理框架
分类：内部数据和外部数据、结构化数据和非结构化数据、元数据。其中结构化数据又细分为基础数据、主数据、事务数据、报告数据、观测数据和规则数据。
按数据主权分类：
External Data（外部数据）：
定义：华为通过公共领域获取的数据
特征：客观存在，其产生、修改不受我司的影响
Internal Data（内部数据）：
定义：企业内经营产生的数据
特征：在企业的业务流程中产生或在业务管理规定中定义，受企业经营影响
按数据存储特性分类：
Structured Data（结构化数据）：
定义：可以存储在关系数据库里，用二维表结构来表达实现的数据
特征：
1）可以用关系数据库存储
2）先有数据结构，再产生数据
Reference Data（基础数据）：
定义：用结构化的语言描述属性，用于分类或目录整编的数据，也称为参考数据
特征：
1）通常有一个有限的允许/可选值范围
2）静态数据，非常稳定，可以用作业务/IT的开关、职责/权限的划分或统计报告的维度
Master Data（主数据）：
定义：具有高业务价值的、可以在企业内跨流程跨系统被重复使用的数据，具有唯一、准确、权威的数据源
特征：
1）通常是业务事件的参与方，可以在企业内跨流程、跨系统重复调用
2）取值不受限于预先定义的数据范围
3）在业务事件发生之前就客观存在，比较稳定
4）主数据的补充描述可归入主数据范畴
Transactional Data（事务数据）：
定义：用于记录企业经营过程中产生的业务事件，其实质是主数据之间活动产生的数据
特征：
1）有较强的时效性，通常是一次性的
2）事务数据无法脱离主数据独立存在
Observational Data（观测数据）：
定义：观测者通过观测工具获取观测对象行为/过程的记录数据
特征：
1）通常数据量较大
2）数据是过程性的，主要用作监控分析
3）可以由机器自动采集
Conditional Data（规则数据）：
定义：结构化描述业务规则变量的数据（一般为决策表、关联关系表、评分卡等形式），是实现业务规则的核心数据
特征：
1）规则数据不可实例化，只以逻辑实体形式存在
2）规则数据的结构在纵向和横向两个维度上相对稳定，变化形式多为内容刷新
3）规则数据的变更对业务活动的影响是大范围的
Report Data（报告数据）：
定义：指对数据进行处理加工后，用作业务决策依据的数据
特征：
1）通常需要对数据进行加工处理
2）通常需要将不同来源的数据进行清洗、转换、整合，以便更好地进行分析
3）维度、指标值都可归入报告数据
Unstructured Data（非结构化数据）：
定义：形式相对不固定，不方便用数据库二维逻辑表来表现的数据
特征：
1）形式多样，无法用关系数据库存储
2）数据量通常较大
按描述数据手段分类：
Meta-data（元数据）：
定义：定义数据的数据，是有关一个企业所使用的物理数据、技术和业务流程、数据规则和约束以及数据的物理与逻辑结构的信息
特征：是描述性标签，描述了数据、相关概念以及它们之间的关系
3.2 以统一语言为核心的结构化数据管理
结构化数据的特点：以信息架构为基础，建立统一的数据资产目录、数据标准与模型
3.2.1 基础数据治理
基础数据用于对其他数据进行分类，在业界也称作参考数据。基础数据通常是静态的，一般在业务事件发生之前就已经预先定义。它的可选值数量有限，可以用作业务或IT的开关和判断条件。当基础数据的取值发生变化时，通常需要对流程和IT系统进行分析和修改，以满足业务需求。故基础数据的管理重点在于变更管理和统一标准管控。
3.2.2 主数据治理
主数据是参与业务事件的主体或资源，是具有高业务价值的、跨流程和跨系统重复使用的数据。主数据与基础数据有一定的相似性，都是在业务事件发生之前预先定义；但又与基础数据不同，主数据的取值不受限于预先定义的取值范围，而且主数据的记录的增加和减少一般不会影响流程和IT系统的变化。但是，主数据的错误可能导致成千上百的事务数据错误，因此主数据最重要的管理要求是确保同源多用和重点进行数据内容的校验。
主数据管理策略：
唯一性：主数据应该代表企业中的某个业务对象的唯一实例，以对应真实世界的对象。重复创建实例将导致数据的不一致，进而给业务流程带来问题。
联邦管控：联邦管控模型代表在中央制定政策、标准和模型，在地方由数据管家和用户一起在流程的各个层级中来实施这些政策、标准和模型。
单一数据源：为确保数据跨系统、跨流程的唯一性和一致性，需要为每个属性的创建、更新和读取确定一个应用系统作为数据源。
数据、流程、IT协同：正确的数据需要在正确的流程中创建、更新和使用，并在正确的应用系统中落地，这种协同将确保全公司范围内的数据质量。
事前的数据质量策略：应该在数据创建阶段就管理数据质量，而非在问题出现后被动解决。
3.2.3 事务数据治理
事务数据在业务和流程中产生，是业务事件的记录，其本身就是业务运作的一部分。事务数据是具有较强时效性的一次性业务事件，通长在事件结束后不在更新。事务数据会调用主数据和基础数据。
事务数据的治理重点是管理好事务数据对主数据和基础数据的调用，以及事务数据之间的关联关系，确保上下游信息传递顺畅。在事务数据的信息架构中需明确哪些属性是引用其他业务对象的，哪些是其自身特有的。对于引用的基础数据和主数据，要尽可能调用而不是重新创建。
3.2.4 报告数据治理
报告数据是指对数据进行加工处理后，用作业务决策依据的数据。它用于支持报告和报表的生成。
可分为：
用于报表项数据生成的事实表、指标数据、维度。
用于报表项统计和计算的统计函数、趋势函数及报告规则。
用于报表和报告展示的序列关系数据。
用于报表项描述的主数据、基础数据、事务数据、观测数据。
用于对报告进行补充说明的非结构化数据。
细分数据类型说明：
1）事实表：从业务活动或事件中提炼出来的性能度量。
特点：
每个事实表由颗粒度属性、维度属性、事务描述属性、度量属性组成；
事实表可分为基于明细构建的事实表和基于明细做过汇聚的事实表。
2）维度：用于观察和分析业务数据的视角，支持对数据进行汇聚、钻取、切片分析。
特点：
维度的数据一般来源于基础数据和主数据；
维度的数据一般用于分析视角的分类；
维度的数据一般有层级关系，可以向下钻取和向上聚合形成新的维度。
3）统计型函数：与指标高度相关，是对指标数据特征进一步的数学统计，例如均值、中位数、总和、方差等。
特点：
通常反映某一维度下指标的聚合情况、离散情况等特征；
其计算数值在报告中通常呈现为图标中的参考线。
4）趋势型函数：反映指标在时间维度上变化情况的统计方式，例如同比、环比、定基比等。
特点：
通常将当期值与历史某时点值进行比较；
调用时，需要收集指标的历史表现数据；
其计算数值在报告中通常呈现为图表中的趋势线。
5）报告规则数据：一种描述业务决策或过程的陈述，通常是基于某些约束下产生的结论或需要采取的某种措施。
特点：
将业务逻辑通过函数运算体现，通常一个规则包含多个运算和判断条件；
规则的计算结果一般不直接输出，需要基于计算结果翻译成业务语言后输出；
规则通常与参数表密切相关。
6）序列关系数据：反映报告中指标及其他数据序列关系的数据。
3.2.5 观测数据治理
观测数据是通过观测工具获取的数据，观测对象一般为人、事、物、环境。观测数据的感知方式有软感知和硬感知。
软感知：
使用软件或者各种技术进行数据收集，收集的对象存在于数字世界，通常不依赖与物理设备，一般是自动运行的程序或脚本。
硬感知：
利用设备或装置进行数据收集，收集的对象为物理世界的物理实体，或者是以物理实体为载体的信息，其数据的感知过程是数据从物理世界向数字世界的转化过程。
特征：
通常数据量较大且是过程性的；
由机器自动采集生成。
观测工具采集回来的原始数据（Raw Data），仅转换结构和格式，不做任何业务规则解析。
观测工具的元数据可以作为数据资产管理，原则上，观测对象要定义成业务对象进行管理，这是观测数据管理的前提条件。
3.2.6 规则数据治理
规则数据是结构化描述业务规则变量（一般为决策表、关联关系表、评分卡等形式）的数据，是实现业务规则的核心数据。
特征：
1）规则数据不可实例化；
2）规则数据包含判断条件和决策结果两部分信息，区别于描述事务分类信息的基础数据；
3）规则数据的结构在纵向（列）和横向（行）两个维度上相对稳定，变化形式多为内容刷新；
4）规则数据的变更对业务活动的影响是大范围的。
基本原则：
1）规则数据的管理是为了支持业务规则的结构化、信息化、数字化，目标是实现规则的可配置、可视化、可追溯；
2）规则数据的管理具有轻量化、分级的特点。重要的、调用量大、变动频繁的业务规则需要通过规则数据管理，使其从代码中解耦，进行资产注册；使用广泛的、有分析需求的规则数据需要通过注册入湖，实现共享和复用；
3）业务规则在架构层级上与流程中的业务活动相关联，是业务活动的指导和依据，业务活动的结果通过该业务活动的相关业务对象的属性来记录。业务规则通过业务活动对业务事实、业务行为进行限制，业务人员可以根据业务规则判断业务情况，采取具体行动。
4）业务规则包含规则变量和变量之间的关系，规则数据主要描述规则的变量部分，是支撑业务规则的核心数据。
运行规则所需的输入数据、输出数据，包括动态数据库访问对象、内存表缓存、Excel、XML处理类等，主要起支撑作用，不在规则数据的范畴。
规则数据必须有唯一的数据Owner，其负责开展规则数据的信息架构建设和维护、数据质量的监控与保障、数据服务建设、数据安全授权与定密等工作。相应的数据管家支持数据Owner对其所管辖的业务中的规则数据进行治理，包括建设和维护信息架构、确保架构落地遵从、例行监控数据质量等。
规则数据的元数据要记录与业务规则的关系（规则数据定义前应完成业务规则的识别和定义）。一个业务规则可以包含零个、一个或多个规则数据，一个规则数据在信息架构上对应一个逻辑数据实体，在物理实现上一般对应一个物理表。规则数据要遵从信息架构资产管理要求（包含明确规则数据的Owner、制定数据标准、明确数据源等），按照信息安全要求定密，以方便规则数据的管理、共享和分析。
3.3 以特征提取为核心的非结构化数据管理
非结构化数据治理核心：对其基本特征与内容进行提取，并通过元数据落地来开展的。
非结构化数据的元数据可以分为基本特征类（客观）和内容增强类(主观）两类。
基本特征类：
参考都柏林十五个核心元数据，实现对非结构化数据对象的规范化定义，如标题、格式、来源等。
内容增强类:
基于非结构化数据内容的上下文语境，解析目标文件对象的数据内容，加深对目标对象的客观理解，如标签、相似性检索、相似性连接等。
非结构化数据的元数据管理采用统分统管的原则，即基本特征类属性由公司进行统一管理，内容增强类属性由相关承担数据分析工作的项目组自行设计，但其分析结果都应由公司元数据管理平台自动采集后进行统一存储。
元数据管理平台通过"基本特征类元数据流"和"内容增强类元数据流"两条线来实现对非结构化数据的元数据管理和消费使用。
基本特征类元数据流：
元数据管理平台基于收到的各类非结构化数据源信息，自动完成基础特征类元数据的采集工作，按照管理规范和要求通过标准化、整合后存储在元数据管理平台中，并在完成元数据过滤、排序后将结果在元数据报告中进行可视化展示，以供用户消费使用。
内容增强类元数据流：
基于元数据管理平台中基本特征类元数据的信息，各数据分析项目组解析目标非结构化对象的数据内容，并将分析结果通过元数据采集、元数据标准化&整合后统一存放在元数据管理平台中，以供用户一并消费使用，增强用户体验。
3.4 以确保合规遵从为核心的外部数据管理
外部数据是指华为公司引入的外部组织或者个人拥有处置权利的数据，如供应商资质证明、消费者洞察报告等。外部数据治理的出发点是合规遵从优先，与内部数据治理的目的不同。
外部数据治理原则：
1）合规优先原则：遵从法律法规、采购合同、客户授信、公司信息安全与公司隐私保护政策等相关规定。
2）责任明确原则：所有引入的外部数据都要有明确的管理责任主体，承当数据引入方式、数据隐私要求、数据共享范围、数据使用授权、数据质量监管、数据退出销毁等责任。
3）有效流动原则：使用方优先使用公司已有数据资产，避免重复采购、重复建设。
4）可审计、可追溯原则：控制访问权限，留存访问日志，做到外部数据使用有记录、可审计、可追溯。
5）受控审批原则：在授权范围内，外部数据管理责任主体应合理审批使用方的数据获取要求。
所有采购的外部数据要注册，在合规的前提下鼓励数据共享，避免重复采购。其他方式引入的外部数据，由管理责任主体决定登记方式。根据法律条款和授权范围，外部数据管理责任主体有权决定外部数据是否入湖，若需入湖，必须遵从数据湖建设相应的流程和规范。同时，外部数据管理责任主体有义务告知使用方合规使用外部数据，对于不合规的使用场景，不予授权；数据使用方要遵从外部数据管理责任主体的要求，对不遵从要求所引起的后果承担责任。
3.5 作用于数据价值流的元数据管理
3.5.1 元数据治理面临的挑战
问题原因：业务元数据与技术元数据未打通；缺乏面向普通业务人员的准确、高效的数据搜索工具；
目标使命：入湖有依据，出湖可检索。
分类：
业务元数据：用户访问数据时了解业务含义的途径，包括资产目录、Owner、数据密集等。
技术元数据：实施人员开发系统时使用的数据，包括物理模型的表与字段、ETL规则、集成关系等。
操作元数据：数据处理日志及运营情况数据，包括调度频度、访问记录等。
数据源到消费五个环节：
数据消费侧：元数据能支持企业指标、报表的动态构建。
数据服务侧：元数据支持数据服务的统一管理和运营，并实现利用元数据驱动IT敏捷开发。
数据主题侧：元数据统一管理分析模型，敏捷响应井喷式增长的数据分析需求，支持数据增值、数据变现。
数据湖侧：元数据能实现暗数据的透明化，增强数据活性，并能解决数据治理与IT落地脱节的问题。
数据源侧：元数据支撑业务管理规则有效落地，保障数据内容合格、合规。
3.5.2 元数据管理架构及策略
产生元数据：制定元数据管理相关流程与规范的落地方案，在IT产品开发过程中实现业务元数据与技术元数据的连接。
采集元数据：通过统一的元模型从各类IT系统中自动采集元数据。
注册元数据：基于增量和存量两种场景，制定元数据注册方法，完成底座元数据注册工作。
运维元数据：打造元数据中心，管理元数据产生、采集、注册的全过程，实现元数据运维。
元数据管理方案：通过制定元数据标准、规范、平台与管控机制，建立企业级元数据管理体系，并推动其在公司各领域落地，支撑数据底座建设与数字化运营。
3.5.3 元数据管理
3.5.3.1 产生元数据
（1）明确业务元数据、技术元数据与操作元数据之间的关系，定义公司元数据模型。
（2）针对找数据及获取数据难的痛点，明确业务元数据、技术元数据、操作元数据的设计原则。
1）业务元数据设计原则：
a.一个主题域分组下有多个主题域，一个主题域下有多个业务对象，一个业务对象下有多个逻辑实体，一个逻辑实体下有多个属性，一个属性有一个数据标准。
b.每个数据标准可被一个或多个属性引用，每个属性归属于一个逻辑实体，每个逻辑实体归属于一个业务对象，每个业务对象归属于一个主题域，每个主题域归属于一个主题域分组。
2）技术元数据设计原则：
a.物理表设计须满足三范式，如为了降低系统的总体资源消耗，提高查询效率，可反范式设计。
b.物理表、视图和字段的设计须基于用途进行分类。
c.承载业务用途的物理表、虚拟表、视图必须与逻辑实体一一对应，承担业务用途的字段必须与属性一一对应。
d.系统间的数据传递须优先采用数据服务。
3）操作元数据的设计原则：
a.日志目的不同的进行分类设计，日志目的相同的进行相同设计。
（3）规范数据资产管理，设计数据资产编码规范。
1）数据资产编码规范
业务元数据：
主题域分组：公司顶层信息分类，通过数据视角体现公司最高层面关注的业务领域
主题域：互不重叠数据的高层面的分类，用于管理其下一级的业务对象
业务对象：业务领域重要的人、事、物，承载了业务运作和管理涉及的重要信息
逻辑实体：描述业务对象的某种业务特征属性的集合
属性：描述所属业务对象的性质和特征，反映信息管理最小粒度
数据标准：用于描述公司层面需共同遵守的属性层数据的含义和业务规则，相关标准一旦确定且发布，全公司范围内需严格遵守
技术元数据：
数据库：按照数据结构来组织、存储和管理数据的仓库
Schema：数据库对象的集合，一个用户一般对应一个Schema
表：分为物理表和虚拟表，物理表为数据库的核心组件，由行和列组成。行包括若干列信息项，一行数据称为一个或一条记录；列称为字段，用于描述相关数据的特征。虚拟表基于物理表进行定义，用于提供数据服务，但不实际存储数据，其数据使用方式和物理表一致
字段：表中的列信息
2）数据资产编码原则
数据资产编码（DAN）是通过一组数字、符号等组成的字符串去唯一标识华为公司内部每一个数据资产，基于此唯一标识，保证各业务领域对同一数据资产的理解和使用一致，它的设计原则遵循如下原则：
统一性原则：只能使用一套数据资产编码，以方便不同业务部门之间的沟通和IT应用之间的数据交换。
唯一性原则：每个数据资产只能用唯一的数据资产编码进行标识，不同数据资产的编码不允许重复，同一个编码也只能对应到一个数据资产上。
可读性原则：数据资产编码作为数据资产分类、检索的关键词和索引，需要具备一定的可读性，让用户通过编码就能初步判断其对应的数据资产类型。
扩展性原则：数据资产的编码要从数据管理角度适当考虑未来几年的业务发展趋势，其编码长度要能适当扩展，同时不影响整个编码体系。
3）业务元数据资产编码规则
业务元数据资产编码规则主要包含三部分：
第一部分为主题域分组的编码规则，主题域分组的编码规则由公司统一分配；
第二部分为主题域、业务对象、逻辑实体、属性的编码规则，这部分主要由数据治理平台按照编码规则自动生成；
第三部分主要为业务元数据包含的子类对应的数据资产类型代码。
3.5.3.2 采集元数据
元数据采集是指从生产系统、IT设计平台等数据源获取元数据，对元数据进行转换，然后写入元数据中心的过程。
元数据来源：
关系数据库：Oracle、MySQL、SQLServer、DB2等
建模工具：ERWin、PowerDesigner等
数据集成工具：DataStage、PowerCenter等
BI报表工具：Cognos、SQLServer ReportingServices等
调度工具：Automation
开发语言及脚本：Perl（日志方式）、SP（注释方式）
其他：元数据采集虚拟库等
操作步骤：
1）选择适配器：适配器是指针对不同的元数据来源，采用相应的采集方式获取元数据的程序，元数据的来源种类繁多，因而须选择相对应的适配器及元模型。
2）配置数据源：在确定数据源所选择的适配器类型、适配器版本、元模型的基础上，配置数据源的名称、连接参数和描述。
3）配置采集任务：配置采集任务为自动调度的工作单元，为元数据的采集提供自动化的、周期性的、定时的触发机制。
3.5.3.3 注册元数据
（1）元数据注册原则
1）数据Owner负责，是谁的数据就由谁负责业务元数据和技术元数据连接关系的建设和注册发布；
2）按需注册，各领域数据管理部根据数据搜索、共享的需求，推进元数据注册；
3）注册的元数据的信息安全密级为内部公开。
（2）元数据注册规范
1）准备度评估项包括如下检查要点：
a.IT系统名称必须是公司标准名称
b.数据资产目录是否经过评审并正式发布
c.数据Owner是否确定数据密级
d.物理表/虚拟表/视图名
2）元数据连接需遵从如下规范：
a.逻辑实体和物理表/虚拟表/视图一对一连接规范：在业务元数据与技术元数据连接过程中，必须遵从逻辑实体和物理表/虚拟表/视图一对一的连接原则，若出现一对多、多对一或多对多的情况，各领域需根据实际场景，参照元数据连接的设计模式进行调整。
b.业务属性与字段一对一连接规范：除了逻辑实体与物理表/虚拟表/视图要求一一对应外，属性和非系统字段也要求遵从一对一的连接原则，若出现属性与字段匹配不上的情况，可参考元数据关联的设计模式进行调整。
（3）元数据注册方法
一对一模式：
适用场景：适用于数据已发布信息架构和数据标准且物理落地，架构、标准与物理落地能一一对应的场景
解决方案：
1）将逻辑实体和物理表一对一连接
2）逻辑实体属性和物理表字段一对一连接
主从模式：
适用场景：适用于主表和从表结构一致，但数据内容基于某种维度分别存储在不同的物理表中的场景。
解决方案：
1）识别主物理表和从属物理表
2）以主物理表为核心，纵向UNION所有从属物理表，并固化为视图。
3）将视图、逻辑实体、字段和业务属性一对一连接。
主扩模式：
适用场景：适用于逻辑实体的大部分业务属性在主物理表，少数属性在其他物理表中的场景。
解决方案：
1）识别主物理表和扩展物理表。
2）以主物理表为核心，横向JOIN所有扩展物理表，完成扩展属性与主表的映射，并固话为视图。
3）将视图、逻辑实体、字段和业务属性一对一连接。
父子模式：
适用场景：适用于多个逻辑实体业务属性完全相同，按不同场景区分逻辑实体名称，但落地在同一张物理表的场景。
解决方案：
1）识别一张物理表和对应的多个逻辑实体
2）将物理表按场景拆分和多个逻辑实体一对一连接。
3）将物理表字段和多个逻辑实体属性一对一连接。
3.5.3.4 运维元数据
场景一：基于数据更新发现，数据源上游创建，下游更新
场景二：通过数据调用次数发现，某数据源上游调用次数<下游调用次数
场景三：虽制定了架构标准，但不知落地情况，比如某个属性建立了数据标准，但是却找不到对应落地的物理表字段
场景四：通过物理表的字段分析，发现很多字段缺少数据标准。
第四章 面向"业务交易"的信息架构建设
4.1 信息架构的四个组件
4.1.1 数据资产目录
L1主题域分组：描述公司数据管理的最高层级分类。
L2主题域：互不重叠的数据分类，管辖一组密切相关的业务对象，通常同一个主题域有相同的数据Owner。
L3业务对象：信息架构的核心层，用于定义业务领域重要的人、事、物，架构建设和治理主要围绕业务对象开展。同时，在企业架构（EA）的范畴内，信息架构（IA）也主要通过业务对象实现与业务架构（BA）、应用架构（AA）、技术架构（TA）的架构集成。
L4逻辑数据实体：描述一个业务对象在某方面特征的一组属性集合。
L5属性：信息架构的最小颗粒，用于客观描述业务对象在某方面的性质和特征。
4.1.2 数据标准
数据标准定义公司层面需共同遵守的属性层数据含义和业务规则，是公司层面对某个数据的共同理解，这些理解一旦被确定下来，就应作为企业层面的标准在企业内被共同遵守。
数据标准覆盖面：
（1）业务视角：用于统一业务侧语言和理解，明确定义每个属性所遵从的业务定义和用途、业务规则、同义词，并对名称进行统一定义，避免重复。
（2）技术视角：对IT实施形成必要的指引和约束，包括数据类型、长度，若存在多个允许值，则应对每个允许值进行明确的限定。
（3）管理视角：明确各业务部门在贯彻数据标准管理方面应承担的责任，包括业务规则责任主体、数据维护责任主体、数据监控责任主体，因为很多情况下这些责任并不是由一个业务部门来负责，所以必须在标准制定时就约定清楚。
数据标准规范：
（1）描述业务对象的特有属性应作为本业务对象的属性进行定义，并明确业务数据标准。
（2）引用其他业务对象的属性，若属性值可随本业务对象确定和更改，就应作为本业务对象的属性进行定义，并明确业务数据标准。
（3）引用其他业务对象的属性，若属性值取自引用业务对象相应时点的数值且后续不变更，就应纳入本业务对象的数据标准范围，并明确相应取值规则。
（4）引用其他业务对象的属性，若属性值与引用业务对象同步，就不需要重新定义数据标准。
（5）引用其他业务对象/逻辑数据实体的身份标识属性，应作为本业务对象的属性进行定义，但只能在业务数据标准中定义出处及引用规则，而不允许修改重新定义该属性本身的业务含义及业务规则。
4.1.3 数据模型
数据模型是从数据视角对现实世界特征的模拟和抽象，根据业务需求抽取信息的主要特征，反映业务信息（对象）之间的关联关系。
数据模型不仅能比较真实地模拟业务（场景），同时也是对重要业务模式和规则的固化。
4.1.4 数据分布
前三个组件主要是从静态角度对数据、数据关系进行定义，那么数据分布则定义了数据产生的源头及在各流程和IT系统间的流动情况。
数据分布的核心是数据源，指业务上首次正式发布某项数据的应用系统，并经过数据管理专业组织认证，作为企业范围内唯一数据源头被周边系统调用。
4.2 信息架构原则：建立企业层面的共同行为准则
原则一：数据按对象管理，明确数据Owner
原则二：从企业视角定义信息架构
原则三：遵从公司的数据分类管理框架
原则四：业务对象结构化、数字化
原则五：数据服务化，同源共享
4.3 信息架构建设核心要素：基于业务对象进行设计和落地
4.3.1 按业务对象进行架构设计
业务对象是指业务领域重要的人、事、物对象。业务对象承载了业务运作和管理涉及的重要信息，是信息架构中最重要的管理要素。
业务对象同时还是业务和IT的关键连接点，也是实现IA（信息架构）、BA（业务架构）、AA（应用架构）、TA（技术架构）集成的关键要素。
判定业务对象原则：
原则一：业务对象是指企业运作和管理中不可缺少的重要人、事、物
原则二：业务对象有唯一标识身份信息
原则三：业务对象相对独立并有属性描述
原则四：业务对象可实例化
4.3.2 按业务对象进行架构落地
概念数据模型是通过业务对象及业务对象之间的关系，从宏观角度分析和设计的企业核心数据结构。
逻辑数据模型是利用逻辑数据实体及实体间的关系，准确描述业务规则的逻辑实体关系。
物理数据模型是按照一定规则和方法，将逻辑数据模型中定义的逻辑数据实体、属性、属性约束、关系等内容，如实转化为数据库软件能识别的物理数据实体关系。
4.3.2.1 逻辑数据实体设计
设计规则：
（1）逻辑实体不能脱离业务对象独立存在，因此某个逻辑数据实体一定是用来描述一个特定的业务对象的，业务对象与逻辑数据实体的关系是一对一或一对多，不允许多对一的情况出现。
（2）描述业务对象不同业务特征的密切相关的一组属性集合，可以设计为一个逻辑数据实体。
（3）逻辑数据实体设计要遵循第三范式。在设计一个业务对象的逻辑数据实体时，每个逻辑数据实体的属性不要重复定义，不应包含其他逻辑实体中的非关键字类型的属性。
（4）提供数据服务或跨业务领域使用的基础数据，要单独设计逻辑数据实体。描述业务对象的若干属性，若能组合起来形成独特价值的数据服务，满足下游的数据消费需求，可以设计成一个逻辑数据实体。
（5）两个业务对象间的关系也可以设计成关系型逻辑数据实体，在数据资产目录中，可按业务发生的时间先后顺序，归属于后出现的业务对象。
4.3.2.2 一体化建模管理
4.4 传统信息架构向业务数字化扩展：对象、过程、规则
出现的问题：
（1）大量业务和作业所产生的数据并没有完整地被管理
（2）大量业务过程没有形成可视、可管理的数据
（3）大量业务规则缺乏管理、无法灵活使用
应对措施：
（1）对象数字化
对象数字化的目标是建立对象本体在数字世界的映射。这种映射不是传统意义上基于流程要求的少量数据的管理，而是管理某个对象的全量数据。
（2）过程数字化
仅仅管理好结果还不够，有时我们需要把作业过程记录下来，了解过程进度或者反过来改进结果。这种记录首先是不干预业务活动的，并且能够自动记录。
过程数字化要实现业务活动线上化，并记录业务活动的执行或操作轨迹，一般通过观测数据来实现轨迹记录。
（3）规则数字化
规则数字化的目的是把复杂场景下的复杂规则用数字化手段进行管理。良好的规则数字化管理，可以实现业务规则与IT应用解耦，所有关键业务规则数据要实现可配置，能够根据业务的变化灵活调整。
第五章 面向"联接共享"的数据底座建设
5.1 支撑非数字原生企业数字化转型的数据底座建设框架
数据底座实现目标：
（1）统一管理结构化、非结构化数据。将数据视为资产，能够追溯数据的产生者、业务源头以及数据的需求方和消费者等。
（2）打通数据供应通道，为数据消费提供丰富的数据原材料、半成品以及成品，满足公司自助分析、数字化运营等不同场景的数据消费需求。
（3）确保公司数据完整、一致、共享。监控数据全链路下的各个环节的数据情况，从底层数据存储的角度，诊断数据冗余、重复以及"僵尸"问题，降低数据维护和使用成本。
（4）保障数据安全可控。基于数据安全管理策略，利用数据权限控制，通过数据封装等技术手段，实现对涉密数据和隐私数据的合法、合规地消费。
5.1.1 数据底座的总体架构
由数据湖、数据主题联接组成，将公司内外部数据汇聚到一起，并对数据进行重新组织和联接，为业务可视化、分析、决策等提供服务。
数据湖是逻辑上各种原始数据的集合，还具备"海量"和"多样"特征。数据湖保留数据的原格式，原则上不对数据进行清洗、加工，但对于数据资产多源异构的场景需要整合处理，并进行数据资产注册。
数据主题联接是对数据湖的数据按业务流/事件、对象/主体进行联接和规则计算等处理，形成面向数据消费的主题数据，具有多角度、多层次、多粒度等特征，支撑业务分析、决策与执行。基于不同的数据消费述求，主要有多维模型、图模型、指标、标签、算法模型5种数据联接方式。
5.1.2 数据底座建设策略
策略：统筹推动、以用促建、急用先行
原则：
（1）数据安全原则
数据底座数据资产应遵循用户权限、数据密级、隐私级别等管理要求，以确保数据在存储、传输、消费等全过程中的数据安全。
技术手段包括但不限于授权管理、权限控制、数据加密、数据脱敏。
（2）需求、规划双轮驱动原则
数据底座数据资产基于业务规划和需求触发双驱动的原则进行建设，对核心数据资产优先建设。
（3）数据供应多场景原则
数据底座资产供应需根据业务需求提供离线/实时、物理/虚拟等不同的数据供应通道，满足不同的数据消费场景。
（4）信息架构遵从原则
数据底座数据资产应遵从公司的信息架构，必须经过IA-SAG（信息架构专家组）发布并完成注册。
5.2 数据湖：实现企业数据的"逻辑汇聚"
5.2.1 华为数据湖的3个特点
（1）逻辑统一
（2）类型多样
（3）原始记录
5.2.2 数据入湖的6个标准
（1）明确数据Owner
数据Owner由数据产生对应的流程Owner担任，是所辖数据端到端管理的责任人，负责对入湖的数据定义数据标准和密级，承接数据消费中的数据质量问题，并制定数据管理工作路标，持续提升数据质量。
（2）发布数据标准
入湖数据要有相应的业务数据标准。业务数据标准描述公司层面需共同遵守的"属性层"数据的含义和业务规则，是公司层面对某个数据的共同理解，一旦确定并发布，就需要作为标准在企业内被共同遵守。
数据标准信息如下：
数据资产目录：
主题域分组：公司顶层数据分类，通过数据视角体现最高层面关注的业务领域
主题域：互不重叠的高层面分类，用于管理下一级的业务对象
业务对象：业务领域重要的人、事、物，承载了业务运作和管理涉及的重要信息
逻辑数据实体：描述业务对象的某种业务特征属性的集合
业务属性：描述所属业务对象的性质和特征，反映信息管理最小粒度
定义及规则：
引用的数据标准：说明该业务属性是否是已定义的数据标准
业务定义：对业务属性的定义，解释业务属性是什么，对业务的作用
业务规则：业务属性的业务规则，包括但不限于业务属性在各场景下的变化规则和编码含义等
数据类型：业务定义的数据类型，例如文本、日期、数字等
数据长度：业务定义的数据长度
允许值：业务属性对应的允许值清单
数据示例：属性实例化的样例，用以帮助其他人员理解此业务属性
同义词：业务对于同一属性可能有不同的称呼，在此列出业务对此属性的其他称呼
标准应用范围：业务数据标准在全公司范围、领域或区域范围内遵从
责任主体：
业务规则责任主体：业务规则制定的责任部门
数据维护责任主体：数据维护的责任部门
数据质量监控责任主体：数据质量监控责任部门
（3）认证数据源
通过认证数据源，确保数据能从正确的数据源入湖。认证数据源应遵循公司数据源管理的要求，一般数据源是指业务上首次正式发布某项数据的应用系统，并经过数据管理专业组织认证。认证过的数据源作为唯一数据源头被数据湖调用。当承载数据源的应用系统出现合并、分拆、下线情况时，应及时对数据源进行失效处理，并启动新数据源认证。
（4）定义数据密级
定义数据密级是数据入湖的必要条件，为了确保数据湖中的数据能充分地共享，同时又不发生信息安全问题。数据定密的责任主体是数据Owner，数据管家有责任审视入湖数据密级的完整性，并推动、协调数据定密工作。数据定密在属性层级，根据资产的重要程度，定义不同等级。不同密级的数据有相应的数据消费要求，为了促进公司数据的消费，数据湖中的数据有相应的降密机制，到降密期或满足降密条件的数据应及时降密，并刷新密级信息。
（5）数据质量评估
数据质量是数据消费结果的保证，数据入湖不需要对数据进行清洗，但需要对数据质量进行评估，让数据的消费人员了解数据的质量情况，并了解消费该数据的质量风险。同时数据Owner和数据管家可以根据数据质量评估情况，推动源头数据质量的提升，满足数据质量的消费要求。
（6）元数据注册
元数据注册是指将入湖数据的业务元数据和技术元数据进行关联，包括逻辑实体与物理表的对应关系，以及业务属性和表字段的对应关系。通过联接业务元数据和技术元数据的关系，能够支持数据消费人员通过业务语义快速地搜索到数据湖中的数据，降低数据湖中数据消费门槛。
5.2.3 数据入湖方式
数据入湖遵循信息架构，以逻辑数据实体为粒度入湖，逻辑数据实体在首次入湖时应考虑信息的完整性。原则上，一个逻辑数据实体的所有属性应该一次性入湖，避免一个逻辑实体多次入湖，增加入湖工作量。
物理入湖：
将原始数据复制到数据湖中，包括批量处理、数据复制同步、消息和流集成等方式。
虚拟入湖：
原始数据不在湖中进行物理存储，而是建立对应虚拟表的集成方式实现入湖，实时性强，一般面向小数据量应用，大批量的数据操作可能会影响源系统。
入湖手段：
（1）批量集成（Bulk/Batch Data Movement）
对于需要进行复杂数据清理和转换且数据量较大的场景，批量集成是首选。通常调度作业每小时或每天执行，主要包含ETL和FTP等工具。批量集成不适合低数据延迟和高灵活性的场景。
（2）数据复制同步（Data Replication/Data Synchronization）
适用于需要高可用性和对数据源影响小的场景。使用基于日志的CDC捕获数据变更，实时获取数据。数据复制同步不适合处理各种数据结构以及需要清理和转换复杂数据的场景。
（3）消息集成（Message-Oriented Movement of Data）
通常通过API捕获或提取数据，适用于处理不同数据结构以及需要高可靠性和复杂转换的场景。尤其对于许多遗留系统、ERP和SaaS来说，消息集成是唯一的选择。消息集成不适合处理大量数据的场景。
（4）流集成（Stream Data Integration）
主要关注流数据的采集和处理，满足数据实时集成需求，处理每秒数万甚至数十万个事件流，有时甚至数以百万计的事件流。流集成不适合需要复杂数据清理和转换的场景。
（5）数据虚拟化（Data Virtualization）
对于需要低数据延迟、高灵活性和临时模式的消费场景，数据虚拟化是一个很好的选择。在数据虚拟化的基础上，通过共享数据访问层，分离数据源和数据湖，减少数据源变更带来的影响，同时支持数据实时消费。数据虚拟化不适合需要处理大量数据的场景。数据复制同步、数据虚拟化以及传统的ETL批量集成都属于数据湖主动拉的方式；流集成、消息集成属于数据源主动推送的方式。在特定的批量集成场景下，数据会以CSV、XML等格式，通过FTP推送给数据湖。
5.2.4 结构化数据入湖
结构化数据是指由二维表结构来逻辑表达和实现的数据，严格遵循数据格式与长度规范，主要通过关系型数据库存储和管理。
结构化数据入湖场景：
（1）企业数据管理组织基于业务需求主动规划和统筹
（2）响应数据消费方的需求
结构化数据入湖过程：
（1）数据入湖需求分析及管理
对于规划驱动入湖场景：由对应的数据代表基于数据湖的建设规划，输出入湖规划清单，清单包含主题域分组、主题域、业务对象、逻辑实体、业务属性、源系统物理表和物理字段等信息。
对于需求驱动入湖场景：由数据消费方的业务代表提出入湖需求，并提供数据需求的业务元数据和技术元数据信息，包括业务对象、逻辑实体、业务属性对应界面的截图。
（2）检查数据入湖条件和评估入湖标准
1）检查数据源准备度
数据有源是数据入湖的基本前提，数据源准备度检查不仅需要源系统的IT团队提供源系统的数据字典和数据模型并检查源系统的物理表规范度，而且需要数据代表评估源系统的数据质量。
2）评估入湖标准
a.明确数据Owner
b.发布数据标准
c.认证数据源
d.定义数据密级
e.评估入湖数据质量
（3）实施数据入湖
虚拟入湖：不要求历史数据、小批量数据且实时性要求高的场景；由数据代表实施；
物理入湖：要求历史数据、大批量数据且实时性不高的场景；由IT代表承接IT实施需求，设计集成方案和数据质量检测方案；
（4）注册元数据
元数据是数据共享和消费的前提，为数据导航和数据地图建设提供关键输入。虚拟表部署完成后或IT实施完成后，由数据代表检查并注册元数据，元数据注册应遵循企业元数据注册规范。
5.2.5 非结构化数据入湖
5.2.5.1 非结构化数据管理的范围
非结构化数据包括无格式的文本、各类格式的文档、图像、音频、视频等多样异构的格式文件。非结构化数据的管理不仅包括文件本身，而且包括对文件的描述属性，也就是非结构化的元数据信息。元数据信息包括文件对象的标题、格式、Owner等基本特征，还包括对数据内容的客观理解信息，如标签、相似性检索、相似性连接等。
5.2.5.2 非结构化数据入湖的4种方式
（1）基本特征元数据入湖
主要通过从源端集成的文档本身的基本信息入湖。入湖的过程中，数据内容仍存储在源系统，数据湖中仅存储非结构化数据的基本特征元数据。其入湖需满足以下条件：
a.已经设计了包含基本特征元数据的索引表。
b.已经设计了信息架构，如业务对象和逻辑实体。
c.已经定义了索引表中每笔记录对应文件的Owner、标准、密级，认证了数据源并满足质量要求。
元数据实体：
属性（基本特征类）
元数据元素：
数据（Code）：文件的唯一标识
数据类型：文本
数据长度：32
是否必填：是
有允许值：否
是否必填（Title）：赋予文件资源的名称
数据类型：文本
数据长度：256
是否必填：是
有允许值：否
类型（Type）：文件资源所属的类别，包括文档、图片、音频、视频
数据类型：文本
数据长度：32
是否必填：是
有允许值：有
格式（Format）：文件的物理格式，包括doc、xls、ppt、jpg、bmp等
数据类型：文本
数据长度：16
是否必填：是
有允许值：否
创建者（Creator）：创建资源内容的主要责任者
数据类型：文本
数据长度：32
是否必填：是
有允许值：否
主题（Subject）：资源内容的主题描述
数据类型：文本
数据长度：64
是否必填：否
有允许值：否
描述（Description）：资源内容的解释
数据类型：文本
数据长度：256
是否必填：否
有允许值：否
发布者（Publisher）：使资源成为可获得的责任实体
数据类型：文本
数据长度：32
是否必填：否
有允许值：否
其他责任者（Contributor）：资源生存期中做出贡献的其他实体，除制作者/创作者之外的其他撰稿人和贡献者
数据类型：文本
数据长度：32
是否必填：否
有允许值：否
创建日期（Create Date）：资源创建的时间
数据类型：日期
数据长度：/
是否必填：是
有允许值：否
发布日期（Publish Date）：资源发布的时间
数据类型：日期
数据长度：/
是否必填：否
有允许值：否
最后修改时间（Last Modify Date）：资源最近被修改的时间
数据类型：日期
数据长度：/
是否必填：是
有允许值：否
生效时间（Effective Date）：资源有效的开始时间
数据类型：日期
数据长度：/
是否必填：是
有允许值：否
失效时间（Failure Date）：资源有效的结束时间
数据类型：日期
数据长度：/
是否必填：是
有允许值：否
版本（Version）：资源的版本信息
数据类型：文本
数据长度：8
是否必填：是
有允许值：否
标识符（Identifier）：资源的唯一标识符
数据类型：文本
数据长度：64
是否必填：否
有允许值：否
语言（Language）：描述资源知识内容的语言、语种。文档、文本类资源的必填项
数据类型：文本
数据长度：16
是否必填：否
有允许值：否
来源（Source）：对当前资源来源的参照，包括组织、人、IT系统等
数据类型：文本
数据长度：64
是否必填：否
有允许值：否
关联（Relation）：与其他资源的索引关系，用关联ID来标引参考的相关索引、资源
数据类型：文本
数据长度：256
是否必填：否
有允许值：否
覆盖范围（Coverage）：资源使用的范围，如适用区域（地理位置）、业务领域、客户群、角色等
数据类型：文本
数据长度：256
是否必填：是
有允许值：否
密级（Security Classification/Rights）：文件的访问密级权限信息
数据类型：文本
数据长度：256
是否必填：是
有允许值：否
（2）文件解析内容入湖
对数据源的文件内容进行文本解析、拆分后入湖。原始文件存储在源系统，数据湖中存储解析后的内容增强元数据。
内容解析入湖需满足以下条件：
a.已经确定解析后的内容对应的Owner、密级和使用范围
b.已经获取解析前对应原始文件的基本特征元数据
c.已经确定内容解析后的存储位置，并保证至少一年内不会迁移
（3）文件关系入湖
根据知识图谱等应用案例在源端提取的文件上下文关系入湖。入湖的过程中，原始文件仍存储在源系统，数据湖中仅存储文件的关系等内容增强元数据。
文件关系入湖需同时满足如下条件：
a.已经确定文件对应的Owner、密级和使用范围
b.已经获取文件的基本特征元数据
c.已经确定关系实体的存储位置，并保证至少一年内不会迁移
（4）原始文件入湖
根据消费应用案例从源端把原始文件搬入湖。数据湖中存储原始文件并进行全生命周期管理。
原始文件入湖需同时满足如下条件：
a.已经确定原始文件对应的Owner、密级和使用范围
b.已经获取基本特征元数据
c.已经确定存储位置，并保证至少一年内不会迁移
5.3 数据主题联接：将数据转换为"信息"
5.3.1 5类数据主题联接的应用场景
（1）多维模型：
面向业务的多视角、多维度的分析，通过明确的业务关系，建立基于事实表、维度表以及相互间联接关系，实现多维数据查询和分析。
（2）图模型：
面向数据间的关联影响分析，通过建立数据对象以及数据实例之间的关系，帮助业务快速定位关联影响。
（3）标签：
对特定业务范围的圈定。在业务场景上下文背景中，运用抽象、归纳、推理等算法计算并生成目标对象特征的表示符号，是用户主观观察、认识和描述对象的一个角度。
（4）指标：
对业务结果、效率和质量的度量。依据明确的业务规则，通过数据计算得到衡量目标总体特征的统计数值，能客观表征企业某一业务活动中业务状况。
（5）算法模型：
面向智能分析的场景，通过数学建模对现实世界进行抽象、模拟和仿真，提供支撑业务判断和决策的高级分析方法。
5.3.2 多维模型设计
步骤：
（1）确定业务场景：
分析业务需求，识别需求中所涉及的业务流及其对应的逻辑数据实体和关联关系。如业务负责人（PO）履行全流程可视，首先需要识别监控的具体业务环节（如发货、开票等），再根据这些业务环节识别其对应的逻辑数据实体及关联关系。
（2）声明粒度：
粒度表示数据单元的细节程度或综合程度，细节程度越高，粒度越细；细节程度越低，粒度越粗。声明粒度是维度和事实表设计的重要步骤，声明粒度意味着精确定义事实表的每一行表示什么。
（3）维度设计：
维度是用于观察和分析业务数据的视角，支持对数据进行汇聚、钻取、切片分析。维度由层次结构（关系）、层级、成员、属性组成。维度可以分为基础树和组合树，维度基础树提供统一定义的、完整的层级结构和成员；维度组合树根据业务使用场景进行定制。维度设计需满足单一性、单向性和正交性。
1）单一性：
有且仅有一个视角，在同一个维度中不能穿插其他经营分析的视角。例如：区域维不含客户视角，产品维不含客户视角。
2）单向性：
"上大下小"，维度只能支撑自上而下的分解和自下而上的收敛，每个成员只能存在向上的收敛路径，不能具备向上和向下两个方向的收敛逻辑。
3）正交性：
成员两两不相交，同一成员不能同时拥有多个上级成员。
（4）事实表设计：
事实表存储业务过程事件的性能度量结果，由粒度属性、维度属性、事实属性和其他描述属性组成。
粒度属性是事实表的主键，通常由原始数据的主键或一组维度属性生成。
维度属性是从维度中继承的属性，可以只继承主键作为事实表的外键，也可以继承维度中全部或其他部分的属性。其他属性主要包括创建人、创建时间、最后修改人、最后修改时间等审计字段。
1）事实属性是可以对该颗粒度的事实进行定量的属性，大多数事实表包括一个或多个事实字段。
2）同一个事实表中不能存在多种不同粒度的事实。
3）尽可能包含所有与业务过程相关的事实，不包含与业务过程无关的事实。
4）对于不可相加的事实，需要分解为可加的事实。比如比率，需要分解为分子和分母。
5）事实的数值单位要保持一致。
5.3.3 图模型设计
图模型由节点和边组成。节点表示实体或概念，边则由属性或关系构成。实体指的是具有可区别性且独立存在的某种事务，如某一个人、某一个城市、某一种植物、某一种商品等，是图模型中的最基本元素；概念是对特征的组合而形成的知识单元，主要指集合、类别、对象类型、事务的种类，如人物、地理等；属性主要是指描述实体或概念的特征或特性，如人员的国籍、生日等。
图模型构建步骤：
（1）业务场景定义
业务场景决定信息涵盖范围，以及信息颗粒度的表示。信息颗粒度在图模型建设中，根据应用场景决定信息颗粒度以及图模型的精确性与有效性。同样的信息范围，颗粒度越细，图模型应用越广泛，关系越丰富，但冗余越多，知识消费越低效。信息颗粒度的原则是"能满足业务应用的最粗颗粒度"。
（2）信息收集
1）与应用场景直接相关的信息。
2）与应用场景间接相关，但可辅助理解问题的信息。这包括企业信息、专业领域信息、行业信息以及开放域信息。
（3）图建模
结合数据特点与应用场景。同样的数据从不同的视角可以得出不同的图模型。
（4）实体、概念、属性、关系的标注
公共类，如人名、机构名、地名、公司名、时间等；
企业类，如业务术语、企业部门等；
行业类，如金融行业、通信行业等。
（5）实体和概念的识别
可将业务输入与数据资产中已有的信息作为种子，运用命名实体识别（NER）的方法扩展出新实体概念，经业务确认后，列入实体、概念库。
（6）属性识别与关系识别
根据业务知识在模式层设计时定义，属性与关系相对稳定，其扩展场景不是很多。企业图模型的存储技术要综合考虑应用场景、图模型中节点和连接的数量、逻辑的复杂度、属性的复杂度，以及性能要求。一般建议采用混合存储的方式，用图数据库存储关系，关系型数据库或键值对存储属性。偏重逻辑推理的应用场景用RDF的存储方式，偏重图计算的应用场景选择属性图的存储方式。发挥两类数据存储和读写的各自优势。
知识计算主要是根据图谱提供的信息得到更多隐含的知识，如通过模式层以及规则推理技术可以获取数据中存在的隐含信息。
知识计算涉及三大关键技术：图挖掘计算、基于本体的推理、基于规则的推理。图挖掘计算是基于图论的相关算法，实现对图谱的探索和挖掘。
图挖掘计算分类：
1）图遍历：知识图谱构建完之后可以理解为是一张很大的图，可以去查询和遍历这个图，要根据图的特点和应用场景进行遍历。
2）图中的算法，如最短路径。
3）路径的探寻，即根据给定两个实体或多个实体去发现它们之间的关系。
4）权威节点的分析，社交网络分析使用较多。
5）族群分析。
6）相似节点的发现。
图挖掘计算在当前的应用场景中，基于业务连续性，通过查询遍历图模型，识别影响节点和影响范围，基于最短路径，辅助决策物流路线，在企业中的应用较为普遍。
图模型在企业中的价值，很大程度上取决于企业基于对象节点可以构建多完善的关系，此关系的构建是一个逐步完善的过程，基于业务场景不断补充和完善关系，这就是图模型的优势。当形成一个足够完善的企业级图模型后，领域分段的业务场景应用只需要裁剪部分节点和关系，就可以满足业务的需求、降低开发成本的目的。
5.3.4 标签设计
标签是根据业务场景的需求，通过对目标对象（含静态、动态特性）运用抽象、归纳、推理等算法得到的高度精炼的特征标识，用于差异化管理与决策。标签由标签和标签值组成，打在目标对象上。
标签分类：
（1）事实标签
描述了实体的客观事实，关注实体的属性特征。如一个部件是采购件还是非采购件，一名员工是男性还是女性等，标签来源于实体的属性，是客观和静态的；
（2）规则标签
属性&度量的统计结果，对数据加工处理后的标签，是属性与度量结合的统计结果。如货物是否是超重货物，产品是否是热销产品等，标签是通过属性结合一些判断规则生成的，是相对客观和静态的；
（3）模型标签
洞察业务价值导向的不同特征，是对于实体的评估与预测。如消费者的换机消费潜力是旺盛、普通还是低等，标签是通过属性结合算法生成的，是主观和动态的。
标签管理：
（1）标签体系建设
1）选定目标对象，根据业务需求确定标签所打的业务对象，业务对象范围参考公司发布的信息架构中的业务对象。
2）根据标签的复杂程度进行标签层级设计。
3）进行详细的标签和标签值设计，包括标签定义、适用范围、标签的生成逻辑等，如下：
a.事实标签应与业务对象中的属性和属性值保持一致，不允许新增和修改；
b.规则标签按照业务部门的规则进行相关设计；
c.模型标签根据算法模型生成。
（2）打标签
1）打标签数据存储结构
打标签是建立标签值与实例数据之间的关系，可以对一个业务对象、一个逻辑数据实体、一个物理表或一条记录打标签。
为了方便从"用户"视角查找、关联、消费标签，可增加用户表，将标签归属到该"用户"下，这里的"用户"可以是具体的人，也可以是一个组织、一个部门、一个项目等。
2）打标签的实现方法
a.事实标签：根据标签值和属性允许值的关系由系统自动打标签。
b.规则标签：设计打标签逻辑由系统自动打标签。
c.模型标签：设计打标签算法模型由系统自动打标签。
5.3.5 指标设计
指标是衡量目标总体特征的统计数值，是能表征企业某一业务活动中业务状况的数值指示器。指标一般由指标名称和指标数值两部分组成，指标名称及其含义体现了指标在质的规定性和量的规定性两方面的特点；指标数值反映了指标在具体时间、地点、条件下的数量表现。
根据指标计算逻辑是否含有叠加公式，可以把指标分为原子指标和复合指标。
原子指标：
数据通过添加口径/修饰词、维度卷积而成，口径/修饰词、维度均来源于指标数据中的属性。
复合指标：
由一个或多个原子指标叠加计算而成，其中维度、口径/修饰词均继承于原子指标，不能脱离原子指标维度和口径/修饰词的范围去产生新的维度和口径/修饰词。
说明：
指标数据：承载原子指标的数据表，例如门店明细表，其中度量为门店数量，通过[门店编码]卷积；属性包括门店等级、门店状态、门店形象等级、组织等级等。
维度：从属性中选取组织、渠道、门店形象等级。
口径/修饰词：[门店状态]等于[有效]，[有无促销员]等于[1]。
原子指标：由指标数据通过添加口径/修饰词、维度卷积而成，包括促销员覆盖门店数量、有效门店数量。
复合指标：由2个或2个以上指标叠加计算而成，包括[促销员门店覆盖率]=[促销员覆盖门店数量]÷[有效门店数量]
指标拆解过程：
解读指标定义，识别指标：通过与指标定义的业务管理部门沟通（通常为指标解释部门的业务人员），从业务角度了解指标基本信息、所需统计维度、指标度量场景和各场景下的计算逻辑和口径（包括剔除规则）、指标发布信息等。
基于指标叠加公式拆解指标：根据指标计算逻辑识别原子指标，明确原子指标中需要的口径/修饰词、维度信息，以及原子指标与复合指标间的支撑关系。
基于指标拆解结果，识别指标数据：识别原子指标的度量属性和支撑属性，并根据原子指标中的维度、口径修饰词匹配已发布业务对象的属性，形成指标数据。
数据匹配落地：补充指标、指标数据中的标准属性名称以及对应的落地物理表，支持用户自助实现指标计算，拉通指标设计和落地。
5.3.6 算法模型设计
算法是指训练、学习模型的具体计算方法，如求全局最优解，并使得这个过程高效且准确，其本质上是求数学问题的最优化解，即算法是利用样本数据生成模型的方法。算法模型是根据业务需求，运用数学方法对数据进行建模，得到业务最优解，主要用于业务智能分析。
算法模型在数据分析流程中产生，算法模型管理框架包括建模、模型资产管理和模型消费。公司各领域已相继开发出大量基于算法模型的分析应用，通过对算法模型资产注册逐步打造公司级的算法模型地图。
设计步骤：
（1）需求分析
1）业务驱动的分析需求识别
a.若要识别与业务运营优化相关的分析需求，就需要梳理业务需求的背景、现状与目标。
b.若由战略或变革提出可能的分析需求，则应进行战略目标解耦，识别分析需求，了解业务现状与制定目标。
c.初步识别分析结果的应用场景。
2）数据驱动的分析需求识别
a.在集成的数据环境中进行数据挖掘，探索可能的分析应用。
b.识别分析需求和确认应用领域。
c.初步识别分析结果的应用场景。
3）价值与可行性评估
a.确定数据分析主题
b.分析需求的业务价值评估，包括业务基线、分析主题的业务影响与可增进的效益。
c.分析前提与可行性，包括识别目前业务流程与可能的影响因素，探讨业务现状因素，并制定对应的分析解决方案，呈现出对应解决方案可提升的效益，对方案所需资源和数据的可行性进行评估。
d.根据相关的历史数据，进行假设和分析，并明确业务范围。
（2）数据准备
1）深入探索数据资产目录，识别与分析主题可能相关的数据。
2）提供数据源、数据标准、数据流等信息。
3）收集与整合原始数据，生成分析数据集。
4）根据分析需求进行数据筛选和质量分析。
（3）方案设计
1）明确要分析的业务目标与相关假设。
2）定义数据集中的分析目标、样本与筛选条件。
3）设计所需变量、指标、可能的分析方法和产出。
4）规划分析的应用场景
（4）建模与验证
1）决定是否需要分析建模：根据技术复杂度、业务效益和资源评估该分析需求是否需要分析建模。若需要分析建模且通过项目评审，则应进行高阶分析；若不需要建模分析，则运行BI分析。
2）建模与验证：根据数据分析方案创建模型，对模型的参数和变量进行调整，根据应用场景选择适用的模型，并与业务分析师确认模型成效与应用，并进行优化，进行模型相关验证及效益评估。
3）试算分析：对数据分析方案中不需分析建模的场景和应用，根据数据分析方案进行分析结果的计算，并选择合适的展示方式。
4）编写数据分析线下验证报告：
a.记录分析结果与发现。
b.根据洞察发现，建议业务应用场景。
c.建议模型检测方式。
5）决定是否需要IT开发：根据模型的验证成果（分析建模）、预估业务效益、IT开发所需的成本和资源来评估分析结果是否需要IT开发。若需要，则通过评审后转入IT开发流程；若不需要，则进入业务应用并结束流程。
6）模型线上验证：
a.设定线上验证范围与场景。
b.进行线上验证，制定模型监控机制（含监控频次和监控要素），生成分析模型线上验证报告。
c.进行业务试运行与推广。
7）转运营：与数据分析模型所属领域的业务代表确认转正式运营计划，启动业务正式运营。
第六章 面向"自助消费"的数据服务建设
6.1 数据服务：实现数据自助、高效、复用
6.1.1 什么是数据服务
基于数据分发、发布的框架，将数据作为一种服务产品来提供，以满足客户的实时数据需求，它能复用并符合企业和工业标准，兼顾数据共享和安全。
6.1.1.1 数据服务给企业带来的价值
（1）保障"数出一孔"，提升数据的一致性。通过服务获取数据的方式类似于"阅后即焚"，大部分情况下数据并不会在适用方的系统中落地，因此减少了数据的"搬家"，而一旦数据的使用方并不拥有数据，就减少了向下游二次传递所造成的数据不一致问题。
（2）数据消费者不用关注技术细节，可以满足不同类型的数据服务需求。对于数据消费者而言，不用再关心"我要的数据在哪里"。
（3）提升数据敏捷响应能力。数据服务一旦建设完成，并不需要按使用者重复构建集成通道，而是通过"订阅"该数据服务快速获取数据。
（4）满足用户灵活多样的消费诉求。数据服务的提供者并不需要关心用户怎么"消费"数据，避免了供应方持续开发却满足不了消费方灵活多变的数据使用述求的问题。
（5）兼顾数据安全。所有数据服务的使用都可管理，数据供应方能够准确、及时地了解"谁"使用了自己的数据，并且可以在数据服务建设中落实各种安全措施，确保数据使用的合规。
6.1.1.2 数据服务建设策略
首先应在企业层面制定统一的数据服务建设策略，此策略不能只关注数据服务的设计，而应该覆盖全生命周期的各个环节。
解决思路：
（1）要制定数据服务建设的方法，确保每个从事数据服务建设的人都明白数据一致性的要求，并且所提供的数据是可信的和可清洁的。
（2）要建立数据服务流程，以确保各个环节的有效协同，定义整个生命周期中每个角色的责任和有效输出。在企业中，应该有明确的部门负责数据服务流程的建设和看护，一方面要确保所制定的流程能在实际工作中落地，另一方面随着技术的演进和企业业务环节的变化，持续对流程进行优化和完善。
（3）要构建统一的数据服务能力中心，负责数据服务建设方法、规范、流程的落地，数据服务不同于传统集成方式，因此要有统一的平台提供能力保障。
数据服务建设标准：
（1）数据服务要满足可重用性、减少数据"搬家"
1）数据服务在实际或者可预见的时间范围内会被多个需求方消费。
2）数据服务面向场景进行消费时，无需重复落地。
（2）服务提供方在规划服务时应明确服务的用户是谁，并针对用户的场景和需求进行服务设计，同时定义SLA服务水平承诺。
1）服务要有业务Owner，业务Owner负责组织业务和IT一体化团队，主动进行服务规划和设计。
2）服务规划和设计人员在规划和设计任何服务时，都应考虑到服务可能会被重用。
3）服务规划需考虑价值，并优化对高价值的服务进行投资。
4）服务消费方应对服务提出改进需求，促进服务能力的持续提升。
（3）应用只能通过服务接口向其他应用开放其数据和功能，服务接口要稳定，应用间的通信也必须通过这些服务接口进行。
（4）所有的服务需在统一的服务管控平台中进行注册和发布。
（5）应根据不同场景选择合适的服务化架构粒度。
6.1.2 数据服务生命周期管理
6.1.2.1 数据服务的识别与定义
业务与数据握手，识别服务的业务价值、准入条件与服务类型，减少数据服务的重复建设，提升数据服务的重用度。
（1）分析数据服务需求：通过数据需求调研与需求交接，判断数据服务类型（面向系统或面向消费）、数据内容（指标/维度/范围/报表项）、数据源与时效性要求。
（2）识别可重用性：结合数据需求分析，通过数据服务中心匹配已有的数据服务，判断以哪种方式（新建服务、直接复用、服务变更）满足业务需求。对于已有的数据服务，必须使用服务化方式满足需求，减少数据"搬家"。
（3）判断准入条件：判断服务设计条件是否已具备，包括数据Owner是否明确、元数据是否定义、业务元数据和技术元数据是否建立联接、数据是否已入湖等。
（4）制定迭代计划：根据数据服务需求制定敏捷交付计划，快速满足数据服务需求。
在数据服务的识别和定义中，要特别注意数据服务的可重用性。所有的数据服务都是需求驱动产生的，如果没有需求方，那么这个数据服务就没有存在的价值。但是，重复建设也就成了数据服务建设中最大的风险之一。数据供应方很容易基于不同的数据消费方开发出不同的数据服务，而他们的数据需求往往是相似的，但数据供应方可能因为响应周期、客户（数据消费方）体验等压力，并没有花费精力去对来自各数据消费方的需求进行筛选和收敛，这就导致所建设的数据服务往往只是满足某个特定客户（数据消费方）的需求。如果数据服务不具备可重用性，那么它与传统的数据集成的方式相比，就并不具备优越性，有时甚至会导致更大的重复投资。因此，以数据服务需求分析为输入，通过服务可重用性判断已有数据服务对需求的满足情况，给出满足服务需求的策略，并结合准入条件的关键问题判断服务需求是否能够被快速满足。
通常可以从数据服务提供形式、数据服务提供内容两方面来判断服务的可重用性。
服务提供形式：
相同：
服务提供内容：内容完成相同
需求满足策略：复用
服务提供内容：若内容不满足，需要依据数据服务封装规范和要求判断是在原有的服务上变更还是新增服务
需求满足策略：变更/新增
不相同：
服务提供内容：-
需求满足策略：新增
此外还应重点关注的另一个要素是数据资产的可服务性，通常用于数据服务准入条件的判断，即某个数据资产是否已经具备对外提供服务的条件。在进行数据可服务性（准入条件）判断时，至少要考虑如下因素：
1）数据Owner是否明确？
2）数据是否有明确的安全密级定义？
3）元数据是否定义？
4）业务元数据和技术元数据是否建立联接？
5）面向数字化运营分析场景时，数据是否已入湖？
6.1.2.2 数据服务的设计与实现
在服务设计与实现阶段，要定义服务契约和数据契约，重点明确服务契约所涉及的服务责任主体、处理逻辑，并以数据契约规范服务的数据格式与数据的安全要求。
通过服务契约与数据契约，可以有效地管理在数据交互中可能存在的安全风险，数据供应方可以将一些安全要求通过契约实现。服务契约：包括服务的基本信息（数据服务提供方、数据服务的类型）、能力要求（服务的时效性、服务的处理逻辑、服务的安全策略、服务的SLA要求）等。
数据契约：包括数据契约描述、输入和输出参数、业务数据资产编码、物理落地资产编码等。
数据服务设计中应强调数据服务的颗粒度，数据服务颗粒度的大小直接影响着服务的可重用性，细粒度的服务更容易被重用。但是，如果我们只考虑可重用性，将导致产生大量颗粒度很小的数据服务，这将对系统的整体性能带来严重的影响，因此必须在服务粒度设计上维护一种平衡。
数据服务颗粒度通常应考虑以下原则：
（1）业务特性：将业务相近或相关、数据粒度相同的数据设计为一个数据服务。
（2）消费特性：将高频率同时访问、时效性要求相同的数据设计为一个数据服务。
（3）管理特性：综合考虑企业在数据安全管理策略方面的要求。
（4）能力特性：将单一能力模型设计为一个服务。
参考规范：
（1）同一种提供形式下，一个数据只能设计在一个数据服务中。
（2）按主题（业务对象）将相同维度的数据设计为一个数据服务。如果同一个主题下的指标数量过多，则需要考虑按"高概率同时使用、业务关联度紧密"的原则再进行划分。
（3）将同一个逻辑实体的数据设计为一个数据服务。
（4）将单一功能的算法、应用模型设计为一个服务。
为确保服务设计后能快速、有序落地，要建立数据服务的开发、测试、部署流程，通过技术、自动化工具、管理协同机制，确保数据服务敏捷交付，缩短数据服务建设周期。
数据开发、测试、部署应重点构建以下能力：
（1）服务需求接收与管理：明确数据管理部门、IT部门、业务代表的具体职责，通过三方共同协作，解决需求理解不透明导致开发过程反复出现的问题。
（2）构建自助式开发平台：通过简单配置的方式实现数据服务的开发，降低数据服务的开发门槛，缩短数据服务的开发周期。
（3）代码自动审查：通过自动化手段效验服务开发代码的性能及不规范等问题，阻断代码提交，直至问题解决。
（4）数据自动验证：构建数据自动测试能力，实现数据服务的数据量差异、字段差异、数据准确性差异的验证。
（5）功能自动测试：构建功能自动化测试能力，自动对数据服务SLA、查询出入参数进行自动检查，构建容错机制。
（6）服务部署：数据服务不涉及对数据的修改，采用实时部署的方式可缩短数据服务的实现周期，提升数据服务的敏捷响应能力。
6.1.2.2 数据服务的变更与下架
（1）数据服务变更管理
1）服务变更内容：包括数据服务的时效性、出入参数、服务处理逻辑、数据安全策略等。
2）服务变更影响：业务连续性影响、变更成本影响等。
（2）数据服务的下架管理
因为数据服务是基于用户需求产生的，而业务需求是动态变化的，因此需要持续将调用量很少甚至为零的数据服务从市场中下架，确保数据消费者总能拿到"最好的"数据服务。通常，数据服务的下架有两种情况：一种是有服务消费方主动提出的数据服务下架申请，可以称为"主动下架"；另一种是通过运营度量策略判断需要下架的数据服务，可以称为"被动下架"。
企业应制定针对不同场景的数据服务下架流程，确保数据服务下架前进行充分的影响度评估，并具备面向所有相关方的消息通知能力，确保实际下架前各消费方的知情权。另外，还应构建一定的自动化实施能力，在各方就数据服务下架达成一致后，系统自动执行数据服务下架动作。
6.1.3 数据服务分类与建设规范
数据服务是为了更好地满足用户的数据消费需求而产生的，因此数据消费方的差异是数据服务分类的最关键因素。
6.1.3.1 数据集服务
（1）数据集服务定义
数据集服务最主要的特征是有服务提供方提供相对完整的数据集合，消费方"访问"数据集合，并自行决定接下来的处理逻辑。
1）数据服务提供方被动地公开数据以供数据消费方检索。
2）数据服务提供方并不定义数据处理逻辑，但数据和数据处理逻辑仍由其控制。
3）数据服务的生命周期即数据访问授权的有效期。
（2）数据集服务建设规范
数据集服务主要面向自助分析场景提供相对完整的数据集合，故所提供的数据主要来自数据底座，包括"数据湖"和"主题联接"。
当所提供的数据来自数据湖时，建设规范如下：
1）允许将数据湖的同一个业务对象内的一个或多个资产封装为数据服务。
2）允许将数据湖内单个资产及其关联主数据合并封装为数据服务。
3）不允许将数据湖中跨业务对象的多个资产合并封装为一个数据服务。
当所提供的数据来自主题联接时，建设规范如下：
1）允许将单个主题联接的数据资产封装为一个或多个数据服务。
2）允许将由多个主题联接数据资产组成的多维模型整体封装为一个数据服务。
3）不允许将多个主题联接数据资产直接合并封装为一个数据服务。
6.1.3.2 数据API服务定义
（1）数据API服务特征
1）数据服务提供方基于随机的数据事件主动地传送数据。
2）数据服务提供方会基于事件定义数据处理逻辑，由消费方提前订阅并随机触发。
3）服务的生命周期跟着事件走，事件关闭，服务终止。
数据API服务是对用户随机数据事件的响应，这个需求往往伴随着用户的某个任务产生，随着任务的结束，整个服务也就完成了。
通过数据API服务，用户可以及时地获知任务的协同情况，并基于服务方的反馈结果，做出相应的调整。服务提供方和消费方是协同关系（互操作），而非交接棒关系（交换情报），有效提升了面向协同任务的互操作一致性。
（2）数据API服务VS数据集成服务
1）供应/消费数据服务：应用组件间传递的是基于数据服务契约的消息，即传递对数据进行逻辑操作的结果。
2）高聚合：订单服务使业务逻辑变得更加集中，易于数据同源管控。
3）松耦合：业务逻辑的变化对服务消费方没有直接影响。
6.1.4 打造数据供应的"三个1"
"三个1"是数据供应的整体目标，起点是需求方提出数据需求，终点为需求方拿到数据并可立即进行消费，具体衡量标准包括如下：
（1）1天：对于已发布数据服务的场景，从需求提出到消费者通过服务获取数据，在1天内完成。
（2）1周：对于已进底座但无数据服务的场景，从需求提出到数据服务设计落地、消费者通过服务获取数据，在一周内完成。
（1）1月：对于已结构化但未进底座的场景，从需求提出到汇聚入湖、数据主题联接、数据服务设计落地、消费者通过服务获取数据，在一个月内完成。
数据供应的"三个1"并不是单纯的度量指标，而是一整套瞄准最终数据消费体验的能力体系以及确保数据供应能力的管理机制，还包括组织职责的明确、流程规范的制定与落实、IT平台的建设和管理。
（1）组织职责的明确
1）构建专业的评审及仲裁组织。
2）承接各细分工作内容的角色职责。
（2）流程规范的制定与落实
1）统一的工作细分流程。
2）配置工作流程制定相应的管理规范，以指导开展工作。
3）配置IT平台制定相应的管理规范，以指导开展工作。
（3）IT平台的建设
1）度量、评价数据底座运营的效率和效益的具体指标。
2）支撑组织职责、流程规范、度量指标落地的IT工具。
（4）面向需求方的效率承诺度量
对所有供应团队形成明确、清晰的工作要求。
6.2 构建以用户体验为核心的数据地图
解决数据的"可供应性"后，企业应该帮助业务更便捷、更准确地找到它们所需要的数据，这就需要打造一个能够满足用户体验的"数据地图"。
6.2.1 数据地图的核心价值
数据供应者与消费者之间往往存在一种矛盾：供应者做了大量的数据治理工作、提供了大量的数据，但数据消费者却仍不满意，他们始终认为在使用数据之前存在两个重大困难。
（1）找数难
企业的数据分散存储在上千个数据库、上百万张物理表中，已纳入架构、经过质量、安全有效管理的数据资产也会超过上万个，并且还在持续增长中。
（2）读不懂
企业往往会面对数据库物理层和业务层脱离的现状，数据的最终消费用户无法直接读懂物理层数据，无法确认数据是否能满足需求，只能寻求IT人员支持，经过大量转换和人工效验，才最终确认可消费的数据，而熟悉物理层结构的IT人员，并不是数据的最终消费者。
企业在经营和运营过程中产生了大量数据，但只有让用户"找得到"、"读得懂"，能够准确地搜索、便捷地订阅这些数据，数据才能真正发挥价值。
数据地图（DMAP）是面向数据的最终消费用户针对数据"找得到"、"读得懂"的需求而设计的，基于元数据应用，以数据搜索为核心，通过可视化方式，综合反映有关数据的来源、数量、质量、分布、标准、流向、关联关系，让用户高效率地找到数据，读懂数据，支撑数据消费。
数据地图为四类关键用户群体提供服务：
（1）业务分析师
（2）数据科学家
（3）数据管家
（4）IT开发人员
6.2.2 数据地图的关键能力
（1）数据搜索
（2）排序推荐
1）被动响应推荐排序
用户在前端无须操作，通过推荐排序逻辑对结果集进行处理，完全基于数据管理分类、用户行为分析等输入。优点是提升了用户的体验，无须操作即可大概率定位到自己需要的数据资产；缺点是与用户之间缺乏交互，准确度因人而异。
2）主动管理推荐排序
通过数据管理侧的分类和通用性的标签进行分类管理，用户在使用过程中可以通过分类标签对搜索结果集进行再次过滤和定位。优点是与用户有一定的交互，让用户在使用时可以主动管理；缺点是基于管理侧和通用性收敛上来的标签难以满足个性化需求。
（3）数据样例
"读懂数据"是用户进行数据消费的基础，用户只有读懂数据，才可以准确判断数据的来源、质量、可信度等关键信息。除了可以通过提供数据资产的各类元数据信息来辅助用户读懂数据外，生产环境的实时数据对用户而言更有参考价值，因为生产环境直接采集的数据内容，与用户可消费的数据内容是一致的。
（4）资产/用户画像
资产/用户画像通过标签化的手段来对资产和用户进行清晰地描绘，有助于数据搜索和推荐排序的不断优化，贴近用户真实需求。基于用户画像、经验模型库和资产画像理解文本语义，可以提高搜索准确性，解决资产查不到、难挑选等问题，并通过业务运营不断优化资产搜索能力。
6.3 人人都是分析师
数据服务解决了"可供应性"，数据地图解决了"可搜索/可获取性"，当消费方获取数据后，提供"可分析"能力，帮助数据消费者结合自身需要获取想要的分析结果。
6.3.1 从"保姆"模式到"服务+自助"模式
过去业务部门只负责提出需求，所有的方案从设计到开发实现，统一由总部完成。强依赖于IT人员，贯穿整个数据分析过程，从获取数据、建模到设计报告，均需要IT人员的支撑，此模式存在如下问题：
（1）总部开发周期长，通常从需求提出到开发实现，需要多轮次需求解析和澄清。由于总部并不了解业务部门的实际业务，即使在方案设计阶段也可能需要再次对需求进行确认。IT开发完成后还需要进行严格的测试验证和部署，因此整个周期通常最短也需30天左右。
（2）无法满足灵活多变的业务要求。业务运营和业务作业不同，作业模式相对稳定，当大的场景不发生变化时，作业模式是基本稳定的。而业务运营是按需展开，往往是从问题出发，在业务开展过程中，可能出现的问题、风险是经常变化的，很可能任何一个内外部因素的变化就会带来新的业务运营关注点，而总部开发模式不可能实时满足所有区域的要求。
在上述背景下，提出"服务+自助"模式，可实现如下价值：
（1）数据分析消费周期极大缩短。当各业务部门需要进行数据分析消费时，可以直接调用已建好的数据服务进行自助分析，整个报表开发周期缩短为1~2天。
（2）发挥业务运营主观能动性。各业务部门是业务作业的责任主体，同时也对业务及经营结果负责，因此各业务部门是业务运营的第一责任人，同时也是最了解业务自身现状与问题的。通过自助模式，可以更有效地发挥各业务部门的主观能动性，真正将数据分析消费与业务运营改进相结合。
（3）减少"烟囱式系统"的重复建设。各业务部门在保证数据分析消费灵活性的同时，并不需要重复构建支撑消费的数据基础，所有公共数据的汇聚、数据联接都统一建设，在遵从隐私保护和安全防护要求的前提下以数据服务的形式充分共享。
6.3.2 打造业务自助分析的关键能力
6.3.2.1 针对三类角色提供的差异性服务
（1）面向业务分析师，提供自助分析能力，业务人员通过"拖、拉、拽"即可快速产生分析报告
1）基于多租户环境，提供数据资产订阅、报表作品搜索、服务订阅等能力
2）实现从数据查询到数据拖拽式分析的端到端的一站式自助作业，增强数据即席查询和数据建模能力。
3）提供数据搜索、数据获取、自助分析、数据消费等一站式自助分析服务，缩短报表开发周期。
4）支持租户管理、工具集管理、日志管理功能，集成数据底座权限模型，提供稳定的分析环境。
（2）面向数据科学家，提供高效的数据接入能力和常用的数据分析组件，快速搭建数据探索和分析环境
1）集成数据可视化、数据建模能力，降低数据分析门槛，提高平台的易用性。
2）识别公共诉求，提供R Studio、Zeppelin等工具集，增强NLP基础服务、人工智能等分析装备对于机会点的支撑能力，支撑各大数据分析应用场景。
3）提供源系统到分析平台的数据实时同步功能。
4）为数据科学家提供数据目录导航入口。
5）提供数据分析环境，支持权限申请和计算资源的分配，缩短建模周期。
（3）面向IT开发人员，提供云端数据开发、计算、分析、应用套件，支撑海量数据的分析与可视化，实现组件重用
1）整合数据接入、数据计算、数据挖掘、数据展示等能力，提供高效、安全的数据集成、数据开发、报告开发、数据管理等服务，减少重复建设，实现组件重用。
2）整合第三方资源，依托HIC能力通道，提供自助、按需、在线的基础数据服务，包括分布式处理、实时处理、内存计算等。
6.3.2.2 以租户为核心的自助分析关键能力
（1）多租户管理能力
（2）数据加工能力
（3）数据分析能力
1）即席查询
a.提供生产环境的实时数据内容，有助于用户通过筛选后的结果数据判断能否满足最终的分析需求。
b.分析结果支持以文件服务器的方式下载，满足本地化处理的需求，同时避免数据被过度共享。
2）可视化分析
a.数据打通，已授权加工后的数据可以直接进入分析工具进行分析操作。
b.最大程度利用各种分析工具的已有功能。
3）自助分享能力
a.对报表提供浏览和编辑能力，查找需要浏览的报表，选择查看、编辑、分享、删除功能。
b.提供对生成的报告定义密级的能力，报告生成者作为报告的Owner，定义密级和管控分享范围。
6.4 从结果管理到过程管理，从能"看"到能"管"
数据分析和消费本身只是一种手段而非目标，数据消费要产生价值，必须与业务密切结合。业务数字化运营是数据消费的最重要场景之一。
6.4.1 数据赋能业务运营
业务运营的本质是围绕业务战略"RUN"流程。运营过程中业务沿着流程周而复始地运转，在作业过程中识别并解决问题，应基于PDCA循环（戴明环）进行有质量的运营。而数字化运营旨在利用数字化技术获取、管理和分析数据，从而为企业的战略决策与业务运营提供可量化的、科学的支撑。
数字化运营归根结底是运营，旨在推动运营效率与能力的提升，所以它体现在具体的业务中，而不是一块新的业务，更多是在现有标准流程的基础上改进和完善。数字化运营的核心是数据，以及基于数据的精细化管理和科学决策分析。
业务数字化运营的目的不应只有"察（数字化看板）"，还应进一步实现"打（业务决策与执行）"，即支撑业务运营作战模式转变，提升运营效率。业务数字化运营要发挥对业务的指挥作用，要能够让上下同步感知业务运行态势，通过分工协作解决业务运作中的问题，提升运作效率。
业务数字化运营要同时具备多个能力，包括战略落地、业务可视化、预测预警、作业指挥、跨领域问题解决和联动指挥等。
（1）满足业务运营中数据实时可视化的需求
（2）满足业务运营中及时诊断预警的需求
（3）满足业务运营中复杂智能决策的需求
6.4.2 数据消费典型场景实践
步骤：
（1）业务需求提出
需求描述：明确业务需求的痛点、目标和收益
需求范围明确：报告的使用场景、角色/岗位；业务定义及规则的明确；业务活动的起点和终点
（2）数据需求解析
报告数据识别：列举所需数据、明确分析维度
分析报告模型设计：从可行性出发，识别分析视角的最小颗粒度
（3）数据搜索和获取
数据搜索：数据已入湖可申请使用；数据未入湖则推动数据Owner履行入湖作业
数据获取：根据数据的密级隐私标签等要素，通过相应的审批后方可获取所需数据
（4）数据服务提供
1）数据入湖
2）数据主题联接资产设计
3）数据服务开发落地
4）测试验证
5）数据资产注册
6）数据授权
（5）报告设计和展示
报告展示设计：将已有数据结合报告展示需求，进行报告界面设计与功能的开发
当业务部门产生数据消费需求后，可以方便地通过数据地图进行搜索。如果已经有数据服务可以支撑，则可以快速地订阅服务，从而直接进行数据分析消费；如果暂时没有数据服务可用，那么数据专业人员只需提供相应的数据服务，而无需为业务部门开发定制分析报告，这样就实现了数据供应和数据消费的高效协同。
6.4.3 华为数据驱动数字化运营的历程和经历
6.4.3.1 华为数字化运营的不同阶段
（1）"从行走到公交"阶段
（2）"从公交到自驾"阶段
（3）"从无序到有序"阶段
（4）"人工到智能"阶段
6.4.3.2 做好数字化运营的"三个要点、两个基础"
"三个要点"：发育、激励、分享。
"两个基础"：数据服务和IT平台。
第七章 打造"数字孪生"的数据全量感知能力
7.1 "全量、无接触"的数据感知能力框架
7.1.1 数据感知能力的需求起源：数字孪生
DT：
起源：起源于数字化制造中产品全生命周期的管理问题
适用对象：涵盖物、人、流程、地点、复杂对象等几乎所有物理实体对象，支撑物联网的发展，但往往只关注单个设备、产品或是它们的组合
模型数据：多来自仿真模型、CAD、BOM清单等物理对象的功能模型，数据多来自传感器、应用系统、维护日志等
运作方式：利用人工智能、机器学习对数字孪生对象进行仿真分析，通过数字孪生体对物理对象进行控制和仿真
目的意义：用以实时监控物理对象的运作、使用仿真分析实现对物理对象发展趋势的预测、控制以及优化
DTO：
起源：概念脱胎于数字孪生，并将其升华至组织的高度，起源于企业的数字化变革问题
适用对象：主要集中在企业这一复杂对象内部，关注流程、运营和绩效指标之间的相关关系，是DT概念在组织管理方向的延伸；将"人"这一元素融入数字孪生中
模型数据：企业内部的组织运作模型，数据来自组织流程、交易流、运营数据、指标绩效以及各类外部数据，例如客户用户体验反馈、市场行情变化等
运作方式：制定战略目标，设立实现这一目标的价值链，建立多重综合评价指标，树立场景意识，动态把握组织所处的环境，并最终制定决策
目的意义：帮助管理者实时了解企业运营情况，为企业数字化变革提供建议。并对一些不确定的因素做情景/模拟分析，为决策提供支持
可以先着手构建数据采集能力，完成数据感知、接入和存储，先让企业具备DTO应用的基础。
7.1.2 数据感知能力架构
"硬感知"：利用设备或装置进行数据的收集，收集对象为物理世界中的物理实体，或者是以物理实体为载体的信息、事件、流程等。
"软感知"：使用软件或者各种技术进行数据收集，收集的对象存在于数字世界，通常不依赖与物理设备，一般是自动运行的程序或脚本。
感知产生的数据还是孤立的物理对象的镜像，需要在企业这一复杂对象内部与其他数据资产一起，与流程、运营和指标之间建立关系，纳入企业的信息架构进行管理，才能真正打通从数据感知、生成到消费的链路。
这一切的最终目的是生成企业级的感知数据，形成数字孪生的基础，满足企业利用人工智能、机器学习对数字孪生对象进行仿真分析、控制并优化制定战略目标的需求，帮助企业动态把握组织所处的环境，帮助管理者实时了解企业运营情况，为企业数字化变革提供建议，通过这些数字化的手段持续变革创新、获取业务价值。
7.2 基于物理世界的"硬感知"能力
7.2.1 "硬感知"能力的分类
数据采集方式主要经历了人工采集和自动采集两个阶段。自动采集技术仍在发展中，不同的应用领域所使用的具体技术手段也不同。基于物理世界的"硬感知"依靠的就是数据采集，是将物理对象镜像到数字世界的主要通道，是构建数据感知的关键，是实现人工智能的基础。
"硬感知"：
条型码/二维码：
条形码或者条码是将宽度不等的多个黑条和空白，按照一定的编码规则排列，用以表达一组信息的图形标识符，通常一维条形码所能表示的字符集不过10个数字、26个英文字母及一些特殊字符，条码字符集所能表示的字符个数最多为128个ASCII字符，信息量非常有限。
二维码是用某种特定的几何图形按一定规律在平面上分布的黑白相间的图形，用来记录数据符号信息。二维码拥有庞大的信息携带量，能够把使用一维条码时存储于后台数据库中的信息包含在条码中，可以直接阅读条码得到相应的信息，并且二维码还有错误修正及防伪功能，增加了数据的安全性。
磁卡：
磁卡是一种卡片状的磁性记录介质，利用磁性载体记录字符与数字信息，用来保存身份信息。视使用基材的不同，可分为PET卡、PVC卡和纸卡三种；
视磁层构造的不同，为可分为磁条卡和全涂磁卡两种。
磁卡的优点是成本低，但缺点是保密性和安全性较差，使用磁卡的应用系统需要有可靠的计算机系统和中央数据库的支持。
RFID：
RFID（Radio Frequency Idetification，无线射频识别）是一种非接触式的自动识别技术，通过无线射频方式进行非接触双向数据通信，利用无线射频方式对记录媒体（电子标签或射频卡）进行读写，从而达到识别目标和数据交换的目的。
基于特别业务场景的需求，在RFID的基础上发展出了NFC（Near Field Communication，近场通信）。NFC本质上与RFID没有太大区别，在应用上的区别：
（1）NFC的距离小于10cm，所以具有很高的安全性，而RFID距离从几米到几十米都有。
（2）NFC仅限于13.56MHz的频段，与现有的非接触智能卡技术兼容，所以很多厂商和相关团体都支持NFC。而RFID标准较多，难以统一。
（3）RFID更多地被应用在生产、物流、跟踪、资产管理上，而NFC则在门禁、公交、手机支付等领域发挥着巨大作用。
OCR/ICR：
OCR（Optical Character Recognition，光学字符识别）是指电子设备（例如扫描仪或者数码相机）检查纸上打印的字符，通过边检测暗、亮的模式确定其形状，将其形状翻译成计算机文字的过程。如何除错或利用辅助信息提高识别正确率，是OCR的重要课题。
ICR（Intelligent Character Recognition，智能字符识别）是一种更先进的OCR。它植入了计算机深度学习的人工智能技术，采用语义推理和语义分析，根据字符上下文语句信息并结合语义知识库，对未识别部分的字符进行信息补全，解决了OCR的技术缺陷。
一个OCR识别系统，从影像到结果输出，须经过影像输入、影像预处理、文字特征抽取、对比识别，最后经人工校正将认错的文字更正，将结果输出。
目前OCR与ICR技术在业界有较为成熟的解决方案供应商，非数字原生企业无需自行研发就可以完成相关技术的部署和数据的采集。
图像数据采集：
图像数据采集是指利用计算机对图像进行采集、处理、分析和理解，以识别不同模式的目标和对象的技术，是深度学习算法的一种实践应用。
图像数据采集步骤：
采集/识别-->图像获取-->预处理-->模版创建-->数据库-->匹配-->结果
对象：
指纹：通过取像设备读取指纹图像，然后用计算机识别软件分析指纹的全局特征和指纹的局部特征
虹膜：虹膜识别技术是利用虹膜终身不变性和差异性的特点来识别身份的。虹膜是一种在眼睛中瞳孔内的织状物的各色环状物，每个虹膜都包含一个独一无二的基于水晶体、细丝、斑点、凹点、皱纹和条纹等特征的结构
视网膜：人体血管纹路也是具有独特性的，人的视网膜上面血管的图样可以利用光学方法透过人眼晶体来测定
面部：面部识别技术通过对面部特征和它们之间的关系（眼睛、鼻子和嘴的位置以及它们之间的相对位置）来进行识别，用于捕捉面部图像的两项技术为标准视频和热成像技术，视频摄像头不同，热成像技术并不需要较好的光源，即使在黑暗情况下也可以使用
掌纹：掌纹与指纹一样也具有稳定性和唯一性，利用掌纹的线特征、点特征、纹理特征、几何特征等完全可以确定一个人的身份，因此掌纹识别是基于生物特征身份认证技术的重要内容
人耳：一套完整的人耳自动识别系统一般包括一下几个过程：人耳图像采集、图像预处理、人耳图像的边缘检测与分割、特征提取、人耳图像的识别
音频数据采集：
语音识别技术也被称为自动语音识别（Automatic Speech Recognition，ASR），可将人类的语音中的词汇内容转换为计算机可读的输入，例如二进制编码、字符序列或者文本文件。
目前音频数据采集技术在业界有较成熟的解决方案供应商，可以很便捷地通过解决方案供应商的技术，完成技术的部署和数据的采集。
采集来的声音作为音频文件存储。音频文件是指通过声音录入设备录制的原始声音，直接记录了真实声音的二进制采样数据，是互联网多媒体重要的一种文件。音频获取途径包括下载音频、麦克风录制、MP3录音、录制计算机的声音、从CD中获取音频等。
视频数据采集：
视频是动态的数据，内容随时间而变化，声音与运动图像同步。通常视频信息体积较大，集成了影像、声音、文本等多种信息。
视频的获取方式包括网络下载、从VCD或DVD中捕获、从录像带中采集、利用摄像机拍摄等，以及购买视频素材、屏幕录制等。
传感器数据采集：
传感器是一种检测装置，能感受到被检测的信息，并能将检测到的信息按一定规律变换成信号或其他所需形式的信息输出，以满足信息的采集、传输、处理、存储、显示、记录等要求。信号类型包括IEPE信号、电流信息、脉冲信号、I/O信号、电阻变化信号等。
传感器数据的主要特点是多源、实时、时序化、海量、高噪声、异构、价值密度低等，数据通信和处理难度都较大。
工业设备数据采集：
工业设备数据是对工业机器设备产生数据的统称。在机器中有很多特定功能的元器件（阀门、开关、压力计、摄像头等），这些元器件接受工业设备和系统系统的命令开、关或上报数据。工业设备和系统能够采集、存储、加工、传输数据。工业设备目前应用在很多行业，有联网设备，也有未联网设备。
工业设备数据采集应用广泛，例如可编程逻辑控制器（PLC）现场监控、数控设备故障诊断与检测、专用设备等大型工控设备的远程监控等。
7.2.2 "硬感知"能力在华为的实践
7.2.2.1 门店数字化
7.2.2.2 站点数字化
7.3 基于数字世界的"软感知"能力
7.3.1 "软感知"能力的分类
"软感知"：
埋点：
埋点是数据采集领域，尤其是用户行为数据采集领域的术语，指的是针对特定用户行为或事件进行捕获的相关技术。埋点的技术实质，是监听软件应用运行过程中的事件，当需要关注的事件发生时进行判断和捕获。
埋点的主要作用是能够帮助业务和数据分析人员打通固有信息墙，为了解用户交互行为、扩宽用户信息和前移运营机会提供数据支撑。在产品数据分析的初级阶段，业务人员通过自有或第三方的数据统计平台了解APP用户访问的数据指标，包括新增用户数、活跃用户数等。这些指标能帮助企业宏观地了解用户访问的整体情况和趋势，从总体上把握产品的运营状况，通过分析埋点获取的数据，制定产品改进策略。
埋点技术分类：
（1）代码埋点
（2）可视化埋点
（3）全埋点
日志数据收集：
日志数据收集是实时收集服务器、应用程序、网络设备等生成的日志记录，此过程的目的是识别运行错误、配置错误、入侵尝试、策略违反或安全问题。
日志分类：
（1）操作日志：系统用户使用系统过程中的一系列操作记录。
（2）运行日志：用于记录网元设备或应用程序在运行过程中的状况和信息，包括异常的状态、动作、关键的事件等。
（3）安全日志：用于记录在设备侧发生的安全事件，如登录、权限等。
网络爬虫：
网络爬虫（Web Crawler）又称为网页蜘蛛、网络机器人，是按照一定的规则自动抓取网页信息的程序或脚本。
7.3.2 "软感知"能力在华为的实践
"软感知"主要面向产品持续运营提供服务，基于对产品日志、用户行为的感知，改善产品功能。数据管理平台的数字化运营，需要识别用户行为，进而提升运营效率和用户消费的体验。通过对平台埋点，捕捉用户在界面上从数据定位到最终消费的浏览过程和停留时间等信息，并关联用户的部门、职位、所在地等信息，自动生成用户画像和数据画像，确定细分用户范围，界定相同认知背景和业务场景的用户，提供可识别的分类资产用户搜索，界定数据资产分类，面向不同的用户界定不同的资产范围，减少匹配差异和搜索引擎复杂度，训练搜索引擎和推荐算法，提供最优数据推荐结果和排序位置。
7.4 通过感知能力推进企业业务数字化
7.4.1 感知数据在华为信息架构中的位置
感知数据生成后，需通过连接进入下一步环境，通过不同的数据类型，选择不同的数据接入方式。在确定接入方式之前，应思考如下：
（1）数据源的可用性分析
（2）接入的数据量大小
（3）数据接入过程是连续的还是按一定的时间间隔进行
（4）数据接入是拉（Pull）的方式还是推（Push）的方式
（5）在数据接入的过程中，是否需要做数据效验或数据标准化
（6）在接入过程中，是否需要对数据做进一步的处理，如数据聚合、数据分类等
接入方式：
批次接入（Batch Data）：
触发方式：固定时间间隔触发接入
频率：频率较低，数据接完成时间通常是小时级
数据源：RDBMS，Flat File，ERP、Cloud、DWH等
数据量：支持大批量接入和小批量接入
数据类型：结构化或非结构化数据
工具类型：CLI、ETL
按需接入（Ad-Hoc）：
触发方式：按需要触发接入
频率：频率较高，数据接完成时间通常是分钟或者秒级
数据源：通常是数据文件，spread sheet、RDBMS等
数据量：通常较小
数据类型：结构化或非结构化数据
工具类型：CLI、ETL、Data发现与预处理工具
实时接入（Real Time）：
触发方式：数据源产生数据时触发接入
频率：数据接完成时间通常是毫秒级
数据源：传感器，机器，网络路由器等
数据量：数据量比较大，但单条数据记录通常比较小
数据类型：结构化数据
工具类型：Message Queue、Stream处理工具
选择存储介质需考虑：
采集方式：
埋点：
数据类型：结构化数据
接入方式：实时
推荐存储介质：RDBMS
数据类型：非结构化数据
接入方式：批次、点对点
推荐存储介质：Document DB、Flat File
日志收集：
数据类型：结构化数据
接入方式：实时
推荐存储介质：RDBMS
数据类型：非结构化数据
接入方式：批次、点对点
推荐存储介质：Flat File
爬虫：
数据类型：结构化数据
接入方式：实时、半实时
推荐存储介质：RDBMS
数据类型：非结构化数据
接入方式：批次、点对点
推荐存储介质：Document DB、Flat File、Graph DB
条形码/二维码：
数据类型：结构化数据
接入方式：实时、半实时
推荐存储介质：RDBMS
磁卡：
数据类型：结构化数据
接入方式：实时、半实时
推荐存储介质：RDBMS
RFID：
数据类型：结构化数据
接入方式：实时、半实时
推荐存储介质：RDBMS
OCR/ICR：
数据类型：非结构化数据
接入方式：批次、点对点
推荐存储介质：Flat File
图像：
数据类型：非结构化数据
接入方式：批次、点对点
推荐存储介质：Graph DB
SRA：
数据类型：非结构化数据
接入方式：批次、点对点
推荐存储介质：Flat File
音频：
数据类型：非结构化数据
接入方式：批次、点对点
推荐存储介质：Object DB
视频：
数据类型：非结构化数据
接入方式：批次
推荐存储介质：Object DB
传感器：
数据类型：结构化数据
接入方式：实时
推荐存储介质：RDBMS
设备：
数据类型：结构化数据
接入方式：实时
推荐存储介质：RDBMS
典型数据库说明：
RDBMS：SQLServer、DB2、Oracle、MySQL
基于文件存储的数据库：MongoDB、ArangoDB、HBase、HDFS、OrientDB、Elastic、gunDB
基于对象存储的数据库：Versant、db4o、Objectivity、JADE、NDatabase
图数据库：Neo4j、Infnite Graph、Sparksee、Allegro Graph、WhiteDB
感知元数据管理内容：
（1）感知方式元数据：对数据感知的方法进行登记注册的过程，在后续的数据消费过程中可以知道数据来源。
（2）感知内容元数据：感知内容包括结构化数据和非结构化数据，所以元数据管理也分为结构化数据元数据和非结构化数据元数据。
观测数据识别业务对象建议：
（1）观测对象是一个时，观测数据挂靠在该业务对象下。
（2）观测对象是多个时，观测数据按大股东原则判断数据Owner和挂靠业务对象。
7.4.2 非数据原生企业数据感知能力的建设
埃森哲数字孪生调查总结：
（1）基础数字孪生
1）传统的模式，存储一些物体实体相关的静态数据，如属性信息、特征数据等。
2）通常是通过激光扫描仪或摄影测量技术获取的一个点的数据
3）可以作为更复杂数字孪生的基础
（2）被动数字孪生
1）提供了实体在某个时间点的虚拟呈现
2）存在3D模型、设计图纸或数字化呈现
3）无法保证数字模型的数据是最新的，所以无法建立物理实体和数字模型的相关性
4）使用扫描技术捕获物理实体的变化，将这些变化反映到数字孪生
（3）动态数字孪生
1）3D数字模型和物理实体之间的映射关系
2）数字模型实时呈现物理实体的状态
3）来自传感器/loT的实时数据提供了物理实体的状态，但信息流是单向的
（4）半智能数字孪生
1）物理实体和数字模型实现的信息的双向流通，通过数字孪生可以控制或改变物理实体
2）由设计工程师使用计算机辅助工程工具生成实体的3D模型，模型更加智能化，模型可以自动解析构成要素（BOM，模块等），并进行流程拆解等
（5）智能数字孪生
1）数字模型的数据和物理世界的数据保持实时同步，数字模型可以进行和物理实体相同的方法和行为
2）可以在虚拟空间运行数字模型，通过假设分析来执行物理实体的"假设方案"，进行预测物理实体的未来
构建感知能力方向选择：
（1）开发一个独特的物理对象感知能力可以获得收益的方向，包括改善运营、降低运营风险、降低成本、更好地为客户服务的机会，或者通过拥有质量更高、更全面的数据来进行更好的业务决策。
（2）在更复杂、更昂贵的环境中，更有可能低效感知能力构建的实现成本。
（3）组织是否拥有相关感知能力的前身，比如可以利用现有的、详细的元数据和模型。
（4）需要一个模型来支持极端的操作环境，比如远程或环境恶劣的地方。
（5）探索技术或商业模式的创新，比如增强现实的应用，或者实现资产货币化的新方法，或者提供前所未有的、差异化的服务水平等领域。
第八章 打造"清洁数据"的质量综合管理能力
8.1 基于PDCA的数据质量管理框架
8.1.1 什么是数据质量
数据质量描述：
（1）完整性：指数据在创建、传递过程中无缺失和遗漏，包括实体完整、属性完整、记录完整和字段值完整四个方面。
（2）及时性：指及时记录和传递相关数据，满足业务对信息获取的时间要求。数据交付要及时，抽取要及时，展现要及时。
（3）准确性：指真实、准确地记录原始数据，无虚假数据及信息。数据要准确反映其所建模的"真实世界"实体。
（4）一致性：指遵循统一的数据标准记录和传递数据和信息，主要体现在数据记录是否规范、数据是否符合逻辑。
（5）唯一性：指同一数据只能有唯一的标识符。体现在一个数据集中，一个实体只能出现一次，并且每个唯一实体有一个键值且该键值只指向该实体。
（6）有效性：指数据的值、格式和展现形式符合数据定义和业务定义的要求。
8.1.2 数据质量管理范围
8.1.3 数据质量的总体框架
（1）自上而下打造数据质量领导力
（2）全面推进数据质量持续改进机制
（3）不断加强数据质量能力保障
8.2 全面监控企业业务异常数据
8.2.1 数据质量规则
数据质量规则是判断数据是否符合数据质量要求的逻辑约束。数据质量的好坏直接影响监控的效果，因此如何设计数据质量规则很重要。
数据质量分类框架：
（1）单列数据质量规则。关注数据属性值得有无以及是否符合自身规范的逻辑判断。
（2）跨列数据质量规则。关注数据属性间关联关系的逻辑判断。
（3）跨行数据质量规则。关注数据记录之间关联关系的逻辑判断。
（4）跨表数据质量规则。关注数据集关联关系的逻辑判断。
8.2.2 异常数据监控
质量控制是通过监控质量形成过程，消除全过程中引起不合格或不满意效果的因素，以达到质量要求而采用的各种质量作业技术和活动。要保证最终交付质量，必须对过程进行质量控制，通常是在过程中设置关键质量控制点。
数据质量的目的是致力于满足数据质量要求，消除或减少异常数据。数据质量控制可以在数据的生命周期内的不同时点被应用，来测试数据的质量和其是否适合于其所在的系统。
8.2.2.1 识别监控对象范围，确定监控内容
数据质量控制从明确业务需求开始，根据业务规划和数据相关方的需求，阶段性确定数据质量控制范围。
（1）重要性原则
1）关键主数据和基础数据：公司级、领域级主数据，如产品、客户、供应商、组织、人员、站点。
2）关键的事务数据：主交易流的核心事务数据，如客户合同、BOQ、工程服务采购PR、S&OP计划、采购PO。
3）痛点问题：领域业务运营痛点问题、公司级变革、攻关项目、业务核心KPI等涉及的对象纳入度量，如产品Item。
（2）成本效益原则
1）运作成熟且质量较高的数据，或度量成本很高但预期的改进很少的数据，可不优先考虑。
2）数据管家也可通过收集业务需求、数据质量问题等其他途径从中筛选当前需监控的数据。
8.2.2.2 数据源剖析
在着手设计数据质量规则前，需对数据进行快速数据剖析，目的是分析数据源的内容、质量和结构，同时发现和分析数据源中的所有数据不规范问题和使数据项目处于危险中的隐藏数据问题。
（1）数据源内容
（2）数据源结构
（3）数据源质量
8.2.2.3 设计和配置监控规则，自动监测异常数据
8.3 通过数据质量综合水平牵引质量提升
8.3.1 数据质量度量运作机制
（1）度量模型
过程设计与执行结果并重，设计质量评估信息架构的建设，执行质量评估数据清洁。
（2）数据Owner职责要求
1）公司数据Owner：下达数据质量目标，并签发数据质量度量报告；基于数据质量结果及改进状况，对相应数据Owner进行奖励及问责。
2）各领域数据Owner：承接公司数据Owner设定的数据质量目标；明确数据质量问题改进责任人，并推动问题闭环管理；对数据质量度量责任，依据要求公司数据Owner述职。
（3）专业支撑组织职责要求
1）公司数据管理部：根据公司数据管理工作规划，制定数据质量目标；组织数据质量度量工作开展，发布公司数据质量度量报告；组织评审数据质量标准及指标，并验收数据质量问题闭环状况。
2）各领域数据管理部：基于公司数据质量度量工作要求，拟定数据质量标准并设计指标，执行数据质量度量；组织各领域业务专家，分析数据质量问题根因，制定改进举措及闭环管理。
（4）度量规则
1）度量对象选定原则：聚焦业务运营痛点数据和影响财报的关键数据。
2）度量频率：一年度量两次。上半年度量期间为1月~6月，重点监控质量改进状况；全年度量期间为1月~12月，综合评价质量达成水平。
3）度量方法：从"设计"及"执行"两个方面开展，通过"设计"明确架构及标准，通过"执行"反映其质量结果。
4）评价标准：统一采取百分率的方式评价，并根据度量得分划分为五档：
a.80%~100% 1等（满意）
b.60%~80% 2等（基本满意）
c.40%~60% 3等（略不满意）
d.20%~40% 4等（不满意）
e.0%~20% 5等（很不满意）
8.3.2 设计质量度量
为确保设计质量标准稳定，从信息架构的四个角度（数据资产目录、数据标准、数据模型、数据分布）进行综合评估，其范围覆盖度量期间内已通过IA-SAG评审发布的所有数据资产。当实际业务有例外场景时，可向IA-SAG专业评审团申请仲裁，若评审通过，则可采用白名单的方式进行管理。
（1）数据资产目录
1）业务对象需有明确、唯一的数据Owner，并对该业务对象全程端到端质量负责，如是否有定义数据质量目标、是否有数据质量工作规划等。
2）业务对象的元数据质量，如数据分类是否完整、业务定义是否准确、数据管家是否有效等。
3）资产目录完整性。
（2）数据标准
1）数据标准元数据质量，如数据标准是否唯一、业务用途及定义是否准确、各责任主体是否有效等。
2）所有业务对象应准确关联数据标准。
3）数据标准在IT系统及其对应的业务流程中应得到应用和遵从。
（3）数据模型
1）开发概念模型和逻辑模型，并通过IA-SAG评审。
2）物理数据模型设计应遵从数据模型设计，数据库中物理表的落地应遵循物理模型。
（4）数据分布
1）已认证数据源，并通过IA-SAG评审。
2）交易侧完整的信息链和数据流，并通过IA-SAG评审。
3）交易侧业务资产、数据湖、主题联接、数据服务、自助分析之间完整准确的血缘关系。
（5）设计质量打分模型
得分：
1分（差）：
数据资产目录：业务对象没有明确的定义及Owner，无法对该业务对象全流程端到端质量负责
数据标准：未发布完整的数据字典
数据模型：未发布IA-SAG评审后的概念模型
数据分布：未认证数据源
2分（中）：
数据资产目录：业务对象有明确的定义及Owner，承诺对该业务对象全流程端到端质量负责
数据标准：开发完整的数据字典，并通过IA-SAG评审
数据模型：开发和维护概念模型，并通过IA-SAG评审
数据分布：数据源认证并通过IA-SAG评审
3分（良）：
数据资产目录：
数据标准：数据标准通过GPO、BPO或GPC签发；数据标准在IT系统及其对应的业务流程中应得到应用和遵从。
数据模型：开发和维护逻辑模型，并通过IA-SAG评审
数据分布：明确数据血缘关系，并制定出合理的整改方案和路标
4分（优）：
数据资产目录：
数据标准：
数据模型：管理逻辑模型和物理模型之间关系，并确保物理模型的开发及维护遵从已发布的逻辑模型
数据分布：完成数据血缘信息链治理，确保数据高效传递，避免不必要的人工干预
5分（满分）：
a.管理面向未来3~5年的数据架构蓝图
b.全面实现满足业务主体数据化、业务场景数据化、业务规则数据化、业务决定算法化、业务流程自动化的要求
c.信息资产成为公司战略核心竞争力
8.3.3 执行质量度量
执行质量度量主要是从数据质量六性（一致性、完整性、及时性、唯一性、有效性、准确性）评估数据内容的清洁度，涉及三个要素：
（1）客户关注重要性：给客户运营带来直接影响的数据的客户关注重要性就高，如合同、PO、验收标准、开票数据等。
（2）法律财务风险性：与法律、财务的关联性强，一旦发生质量问题，会触犯法律或带来相关财务损失，那么该数据的法律财务风险性就高，如收入、成本等数据。
（3）业务流程战略性：数据所产生的业务流程如果是公司核心交易流程（如LTC流程）或战略地位高的流程（如IPD）流程，那么数据的业务流程战略性普遍会得到较高关注；若是相关支撑或使能流程（如变革流程、IT开发流程等），那么数据的业务流程战略性相对较弱。
8.3.3.1 确定度量指标
与度量对象一样，数据质量度量指标也往往来源于日常监控的数据质量规则，将业务属性层主规则通过叠加公式变成业务对象层度量指标。
数据质量规则的设计应让相关业务人员参与，以满足业务的使用场景。但当某些业务场景的规则不够清晰，或当前的技术手段无法较为准确地识别异常数据时，这类数据质量规则往往只能用于警示，不建议纳入度量。
参考原则：
（1）重要性原则：对核心数据、痛点问题较严重的数据，需重点考虑设计度量指标。
（2）成本效益原则：运作成熟且质量较高的数据，或度量成本很高但预期改进很少的数据，可以考虑简化度量指标或不度量。
（3）明确性原则：指标设计清晰、可衡量。
（4）分层分级原则：可根据不同层级的管理述求，设计分层分级的指标。
（5）持续度量原则：一次性就可解决问题的数据不需要度量。
叠加公式的建议计算规则：
（1）逻辑实体数据质量度量指标=〖属性数据质量异常数量/〖属性总量，我们称之为数据格面积算法。
（2）业务对象数据质量度量综合指标=Average（逻辑实体数据质量度量指标）。
8.3.3.2 确定数据质量衡量标准
数据质量衡量标准是指指标测评结果与用户质量述求的关系。
五分制：
1分：
用户感知：差
得分说明：指标未度量，或度量结果远不能达到数据质量要求，存在严重的数据质量问题
主数据：小于三西格玛（93.32%）
2分：
用户感知：中
得分说明：度量结果不能达到数据质量要求，存在较多的数据质量问题，影响较大
主数据：三西格玛（93.32%）~ 四西格玛（99.3797%）
3分：
用户感知：良
得分说明：度量结果基本达到数据质量要求，存在少量的数据质量问题，影响一般
主数据：四西格玛（99.379%）~ 五西格玛（99.977%）
4分：
用户感知：优
得分说明：度量结果完全达到数据质量要求，且基本不存在数据质量问题
主数据：五西格玛（99.977%）~ 五西格玛（100%）
5分：
用户感知：满分
得分说明：零缺陷（所有属性都没有任何异常，且长期不存在任何数据质量问题）
主数据：零缺陷
事务数据：
（1）事务数据指标按照主业务流、同类指标拉通原则
（2）按业务流：客户交易流、产品配置流、交付作业流、集成计划流等
（3）按六性：结合六性情况对指标相对拉通
原则性建议：
（1）主数据绝对拉通，采用业界通用的六西格玛要求。
（2）事务数据可依据各业务流进行相对拉通，但对于完整性和及时性这类较简易的数据质量要求，应相对严格。
（3）衡量标准的划分，数据管家应组织数据生产者和数据消费者共同协商讨论，达成一致。数据管家应从数据专业视角给出建议，数据生产者从其当前的数据管理、IT工具、人员技能等方面预估当前的数据质量水平，数据消费者从数据的使用视角提出数据质量要求。
（4）同一个业务对象下的不同业务属性的消费者不同，应综合所有消费者的述求，在业务对象层划分数据质量衡量标准，在同一业务对象下的可保留部分独立的数据质量规则，再逐一对业务对象下的所有度量指标划分质量衡量标准，最后再通过加权平均的方法收敛到业务对象层，即得到业务对象分。
8.3.3.3 执行度量
数据质量度量已流程化，因此我们可将其作为一次小型变革项目进行管理。根据度量运作机制，有公司数据管理部定期启动公司级数据质量度量。召开启动会议，明确本次数据质量度量细则，如数据质量度量目标、度量期间、度量范围、度量指标、计划进度等相关事宜，以确保数据质量度量工作有序、高效地开展，同时也确认数据质量度量结果的公正、有效。
8.3.4 质量改进
数据质量改进致力于增强满足数据质量要求的能力。数据质量改进消除系统性的问题，对现有的质量水平在控制的基础上加以提高，使质量达到一个新水平、新高度。
质量改进的步骤本身就是一个PDCA循环。质量改进包括涉及企业跨组织的变革性改进（BTMS）和企业各部门内部人员对现有过程进行渐进的持续改进（GPMS）。
质量活动：
维持：指维持现有的数据质量水平，其方法是数据质量控制；
改善：指改进目前的数据质量，其方法是主动采取措施，使数据质量在原有的基础上有突破性的提高，即数据质量改进。
数据质量控制的目的是维持某一特定的质量水平，控制系统的偶发性缺陷；而数据质量改进则是对某一特定的数据质量水平进行"突破性"的提升，使其在更高的目标水平下处于相对平衡的状态。控制是日常进行的工作，可以纳入流程体系的"操作规程"中加以贯彻执行，最好的手段就纳入流程体系进行标准化。质量改进则是一项阶段性的工作，达到既定目标之后，该项工作就完成了。质量改进的最终效果比原来维持效果好得多，这种工作必然要通过精心策划。质量改进要固化在流程体系中进行标准化，通过质量控制使得标准化的流程得以实施，达到新的质量水平。
质量控制是质量改进的前提，控制就意味着维持以前的水平，是PDCA改进循环中保证水平不下降的"努力的锲子"，是保证下一次改进的起点，而改进则是在起点基础上的变革和突破。如果不做好质量控制，质量水平就会下降，下次又在低水平重复，因此不能只关注质量改进，改进后关键还是要实施质量控制，二者交替进行，相辅相成。
第九章 打造"安全合规"的数据可控共享能力
9.1 内外部安全形式，驱动数据安全治理发展
9.1.1 数据安全成为国家竞争的新战场
9.1.2 数字时代数据安全的新变化
9.2 数字化转型下的数据安全共享
9.3 构建以元数据为基础的安全隐私保护框架
9.3.1 以元数据为基础的安全隐私治理
元数据就是描述数据的数据，即数据的上下文。而数据的管理要求、信息安全要求、隐私、网络安全要求等，都是数据的管理要素，当然也可以由元数据承载，用元数据来组织、来描述安全隐私管理策略和约束。
9.3.2 数据安全隐私分层分级管控策略
从公司层面，通过对整体内外部安全隐私管理政策的解读，将内部信息密级维度分为五类，要求组织间共享时一致遵从。
（1）外部公开：可以在公司外部公开发布的信息，不属于保密信息。
（2）内部公开：可以在全公司范围内公开，但不应向公司外部扩散的信息。
（3）秘密：是公司较为重要或敏感的信息，其泄露会是公司利益遭受损害，且影响范围较大。
（4）机密：是公司非常重要或敏感的信息，其泄露会使公司利益遭受较大损害，且影响范围广泛。
（5）绝密：是公司最重要或敏感的信息，其泄露会使公司利益遭受巨大损害，且影响范围巨大。
基于业务管理的述求，以内部信息密级维度为基础，从资产的维度增加两类划分，进行针对性管理。
（1）核心资产：对应绝密信息，特指公司真正具有商业价值的信息资产。
（2）关键资产：属于机密信息，特指对我司在消费者BG、5G领域领先战略竞争对手，在市场竞争中获胜起决定性作用的信息资产。
基于对GDPR的解读和企业内部的管理需求，将涉及潜在隐私管控需求的数据分为五类进行管理。
（1）个人数据：与一个身份已被识别或者身份可被识别的自然人（数据主体）相关的任何信息。
（2）敏感个人数据：指在个人基本权利和自由方面及其敏感，一旦泄露可能会造成人身伤害、财务损失、名誉损害、身份盗窃或欺诈、歧视性待遇等的个人数据。通常情况下，敏感个人数据包括但不限于可以揭示种族或血统、政治观点、宗教或哲学信仰、工会成员资格的数据，用于唯一识别自然人的基因数据、生物数据（如指纹），与自然人的健康、性取向相关的数据。
（3）商业联系个人数据：指自然人基于商业联系目的提供的可识别到个人的数据。
（4）一般个人数据：除敏感个人数据、商业联系人以外的个人数据，作为一般个人数据。
（5）特种个人数据：GDPR法律中明文确定的特殊种类个人数据，严禁物理入湖，严禁共享及分析。
9.3.3 数据底座安全隐私分级管控方案
（1）数据底座安全隐私管理政策：说明数据底座的责任边界，数据风险标识标准、数据加工、存储、流转规范。
（2）数据风险标识方案：平台提供的数据标识能力。
（3）数据保护能力架构：数据底座分级存储架构能力。
（4）数据组织授权管理：数据在组织内共享的规则。
（5）数据个人权限管理：个人访问数据的权限管理方案。
数据安全规范主体包括三部分：
（1）数据密级分级标准：数据定密的标准，包括外部公开、内部公开、秘密、机密、绝密五个等级。
（2）存储保护的基线：描述每一个级别的数据资产的存储要求以及入湖原则。
（3）流转审批层级：描述每一个级别的数据资产在申请数据共享时应该经过哪些控制审批。一般控制审批流程下，内部公开数据不需要审批，在流程中自动存档并知会数据消费方直属主管。秘密数据由消费方直属主管审批即可，机密数据需要数据生成方和消费双方数据Owner共同审批。
在隐私保护方面，数据底座隐私保护规定，总体原则是"个人数据原则上不入湖，并尽可能脱敏处理"。
隐私保护规范主体包括三部分：
（1）个人数据分类、分级标准：非个人数据、商业联系个人数据、一般个人数据、敏感个人数据，共4个级别。
（2）个人数据保护基线：根据个人数据分级，敏感个人数据、一般个人数据、商业联系人分别需要做不同程度的数据保护，其中法律明文规定的特种个人数据严禁入湖。
（3）流转审批层级：隐私审批层级基本与安全一致，但新增了隐私专员的介入，以专家评审身份，参与控制数据流转业务，判别数据消费的目的限制以及最小化授权。
9.3.4 分级标识数据安全隐私
在明确数据分类标准的基础上，还需要有具体的平台支撑数据风险标识。这就包括传统的元数据人工标识方案以及通过规则、AI自动推荐方案。
（1）人工识别数据风险。数据安全隐私分级标识必须基于元数据管理平台，在平台中构建对数据字段级别的风险标识。
（2）基于规则与AI的自动识别。在数字时代，随着数据资产的膨胀，数据风险标识工作量非常巨大，字段的数量是数据表数量的100倍有余，依靠人工的方式无法识别全面，需要通过工具，基于规则（正则表达式）以及AI机器学习的方式，构建自动推荐、识别风险标识的能力。
识别数据资产、管理元数据、标识安全隐私，只是"安全合规"共享数据的第一步。
9.4 "静""动"结合的数据保护与授权管理
9.4.1 静态控制：数据保护能力架构
9.4.1.1 存储保护
（1）高防区隔离：高防区隔离就是我们通过在数据底座独立部署单独的防火墙以及配合流向控制、堡垒机等措施，对高密资产重大防护。关键要点就是有独立的防火墙，并且内部区分脱敏开发区和明文业务访问区，让数据开发人员在脱敏区工作。高防区数据经过审核后才能发布到明文区，给业务部门使用。
（2）透明加密：透明加密就是对表空间进行加解密，进入表空间的表自动加密，有权限的应用读取表空间时就自动解密。主要用于防止黑客把库文件搬走。
（3）对称加密：对称加密指应用对数据字段应用对称加密算法进行加密，需要配合统一的密钥管理服务使用。
（4）静态脱敏：首先需要从技术角度制定出脱敏标准。脱敏不是单一的技术能力，而是多种脱敏算法的合集，包括加噪、替换、模糊等，每种数据类型应该有不同的脱敏标准。我们在ETL集成工具中增加脱敏API能力，可以对具体的字段进行脱敏，每类数据字段都依据脱敏标准执行。
9.4.1.2 访问控制
静态脱敏用于存储保护，而动态脱敏则是一项基于身份的访问控制。通常Web应用都是使用自己的菜单和角色权限进行职责分离，对于数据权限，很难做到字段级别的控制。而动态脱敏可以对某些数据表、数据字段根据身份进行脱敏，从而做到更细颗粒度的保护。
9.4.1.3 可追溯
在可追溯方面，业界有较为成熟的数据水印技术。在数据行、数据列中增加水印，不影响数据的关联与计算，适用于核心资产或敏感个人数据。一旦发生泄露，可以溯源定责。
9.4.2 动态控制：数据授权与权限管理
9.4.2.1 数据授权管理
数据授权和数据权限是两个不同的概念。数据授权主要是面向组织，指数据Owner对组织授予数据访问权的过程，让数据与组织绑定，为组织提供长期的数据订阅权限。数据授权包含两个场景：
（1）数据加工授权：由于数据主题联接资产建设中需要跨组织进行数据联接、加工、训练需要转移数据而发生的数据授权场景。
（2）数据消费授权：由于业务用户数据的分析需要订阅数据服务而发生的数据授权场景。
数据授权管理要基于数据风险标识和数据保护能力，既能在数据流转中落实安全隐私控制策略，让数据安全隐私政策落地，又能作为数据架构治理的抓手，融入架构审核，避免重复建设。
9.4.2.2 数据权限管理
数据权限管理是基于访问管控规范，对授予的数据访问权限进行管理的过程。面向个人和面向与岗位绑定的综合管理者的管理策略不同。
基于消费数据类型的差异，个人数据权限分为两大场景：
（1）业务分析师获取数据资产（原材料场景）。
（2）业务用户获取报告访问权限（成品场景）。
基于企业IAM（身份识别与访问管理）和IDM（账号权限管理），结合数据分级管理机制，让数据权限随人员流动而改变，并统一规则、集中管控高风险数据，实现对个人权限授予、销权、调动全生命周期集中管控。
第十章 未来已来：数据成为企业核心竞争力
10.1 数据：新的生产要素
10.1.1 数据被列为生产要素：制度层面的肯定
10.1.2 数据将进入企业的资产负债表
10.1.3 数据资产的价值由市场决定
10.2 大规模数据交互的企业数据生态
10.2.1 数据生态离不开底层技术的支持
10.2.2 数据主权是数据安全交换的核心
10.2.3 国际数据空间的目标与原则
10.2.4 多方安全计算强化数据主权
10.3 摆脱传统手段的数据管理方式
10.3.1 智能数据管理是数据工作的未来
10.3.2 内容级分析能力提供资产全景图
10.3.3 属性特征启发主外键智能联接
10.3.4 质量缺陷预发现
10.3.5 算法助力数据管理
10.3.6 数字道德抵御算法歧视
10.4 第四个世界：机器认知世界
10.4.1 真实唯一的"物理世界"和五彩缤纷的"人类认知世界"
10.4.2 映射"物理世界"的数字孪生--"数字世界"
10.4.3 "数字世界"中的智能认知--"机器认知世界"
参考书籍《华为数据之道》
