《华为数据之道》学习笔记
# 1-3章:数字化转型面临的挑战和数字化转型的理念
# 第一章:数据驱动企业的数字化转型
# 华为数字化转型与数据治理
社会经济大环境的变化、行业趋势的变化、竞争对手的压力、公司的战略优化、自身经营的改善等是企业数字化转型最主要的驱动力
CIO陶竟文提出“实现全联接的智能华为,成为行业标杆“的数字化转型目标(如下图)
# 华为数字化转型整体目标
**对内:**各业务领域数字化、服务化、打通跨领域的信息断点,达到领先行业的运营效率。逐步构建以“面向客户做生意”和“基于市场的创新”两个业务流为核心的“端到端”的数字化管理体系。
**对外:**对准5类客户的ROADS体验,实现与客户做生意更简单、更高效、更安全、提升客户满意度。
ROADS:
实时:Real-time
按需:On-demand
全在线:All-online
服务自助:DIY
社交化:Social
# 华为数字化转型及对数据治理的要求
(如下图:华为数字化转型蓝图)
# 华为数据治理实践
# 华为数字治理历程
第一阶段:2007-2016年
设立数据管理专业组织,建立数据管理框架,发布数据管理政策,任命数据owner
实现了如下目标:
持续提升数据质量,减少纠错成本
数据全流程贯通,提升业务运作效率
第二阶段:2017年至今
实现了如下数据价值
业务可视,能够快速,准确决策
人工智能,实现业务自动化
数据创新,成为差异化竞争优势
华为数据治理的两个阶段(如下图)
# 华为数据工作的愿景与目标
华为公司基于多业务、全球化、分布式管理等业务战略规划和数 字化转型诉求,明确了华为数据工作的愿景,即“实现业务感知、互 联、智能和ROADS体验,支撑华为数字化转型”。华为数据工作的目标 为“清洁、透明、智慧数据,使能卓越运营和有效增长”。为确保数 据工作的愿景与目标达成,需要实现数据自动采集、对象/规则/过程 数字化、数据清洁、安全共享等特性(如图1-6所示)。
# 华为数据工作建设的整体思路和框架
作为非数字原生企业,我们认为数字化转型的关键要素之一是在 现实世界的基础上构建一个跨越孤立系统、承载业务的“数字孪生” 的数字世界。通过在数字世界汇聚、联接与分析数据,进行描述、诊 断和预测,最终指导业务改进。在实现策略上,数字世界一方面要充 分利用现有IT系统的存量数据资产,另一方面要构建一条从现实世界 直接感知、采集、汇聚数据到数字世界的通道,不断驱动业务对象、 过程与规则的数字化。华为数据工作建设的整体思路如图1-7所示。
华为经过多年实践,形成了一套数据工作框架。
- 数据源:业务数字化是数据工作的前提,通过业务对象、规则 与过程数字化,不断提升数据质量,建立清洁、可靠的数据源。
- 数据湖:基于“统筹推动、以用促建”的建设策略,严格按六 项标准,通过物理与虚拟两种入湖方式,汇聚华为内部和外部的海量 数据,形成清洁、完整、一致的数据湖。
- 数据主题联接:通过五种数据联接方式,规划和需求双驱动, 建立数据主题联接,并通过服务支撑数据消费。
- 数据消费:对准数据消费场景,通过提供统一的数据分析平 台,满足自助式数据消费需求。
- 数据治理:为保障各业务领域数据工作的有序开展,需建立统 一的数据治理能力,如数据体系、数据分类、数据感知、数据质量、 安全与隐私等。
数据体系建设的整体框架(如图1-8所示),基于统一的规则与平 台,以业务数字化为前提,数据入湖为基础,通过数据主题联接并提 供服务,支撑业务数字化运营。
# 第二章:建立企业级数据综合治理体系
# 建立公司级的数据治理政策
# (1)信息架构管理原则
第一条:建立企业级信息架构,统一数据语言。 第二条:所有变革项目须遵从数据管控要求。对于不遵从管控要求的变革项目,数据管控组织拥有一票否决权。 第三条:应用系统设计和开发应遵从企业级信息架构。关键应用系统必须通过应用系统认证。
# (2)数据产生管理原则
第一条:数据规划对齐业务战略,业务战略规划必须包含关键数据举措及其路标规划。 第二条:公司数据Owner拥有公司数据管理的最高决策权,依托ESC(变革指导委员会)决策平台议事。各数据Owner承担数据工作路标、信息架构、数据责任机制和数据质量的管理责任。 第三条:关键数据须定义单一数据源,一点录入,多点调用。数据质量问题应在源头解决。 第四条:谁产生数据,谁对数据质量负责。数据Owner负责基于使用要求制定数据质量标准,且须征得关键使用部门的同意。
# (3)数据应用管理原则
第一条:数据应在满足信息安全的前提下充分共享,数据产生部门不得拒绝跨领域的、合理的数据共享需求。 第二条:信息披露、数据安全管理、数据保管和个人数据隐私保护等必须遵守法律法规和道德规范的要求。公司保护员工、客户、商业伙伴和其他可识别个体的数据。
# (4)数据问责与奖惩管理原则
各数据Owner应建立数据问题回溯和奖惩机制。对不遵从信息架构或存在严重数据质量问题的责任人进行问责。
# 融入变革、运营与IT的数据治理
# 建立管理数据流程
华为将“管理数据”流程定位为“管理BT&IT”流程下的一个L2流程,下设“管理信息架构”“管理数据质量”“管理数据分析”3个子流程,如下图所示:
管理数据流程关键角色及职责设置(如下图)
#
# 管理数据流程与管理变革项目、管理质量与运营之间的关系
企业在运营过程中,能力的提升和架构的调整依托于变革项目和 改进项目的实施。变革项目和改进项目需要交付业务解决方案、数据 解决方案、IT解决方案,其中数据解决方案包含信息架构设计、数据 质量度量、改进方案和数据分析方案。支撑数据解决方案的角色为数 据经理,数据经理统筹管理信息架构工程师、数据治理工程师、数据 分析师和数据科学家,共同完成项目数据解决方案的交付和验证。具 体的管理数据流程与管理变革项目、管理质量与运营之间的关系如图 2-3所示。
# 通过变革体系和运营体系进行决策
在华为的数据治理实践中,数据相关的重大决议由企业变革指导 委员会决策,通过变革管理体系和流程运营体系实现落地,如图2-4所 示。
# 数据治理融入IT实施
业务人员通过使用IT产品提供的功能和服务提升作业效率,因此,对业务数据的管理要求,必然要落实到IT产品的操作界面和数据库设计中,这样才能落实数据治理的要求。在华为的数据治理实践中,在IT产品团队中设置系统架构师和数据架构师角色,负责界面设计、数据库设计、数据集成方案设计,向上承接信息架构的设计要 求。同时,在管理IT流程的设计规范中,明确界面的字段要遵从数据 标准的定义,数据库表和字段的设计要承接信息架构的设计要求,从而达到数据治理融入IT实施流程的目标。
# 通过内控体系赋能数据治理
要对华为这样的大型企业实施数据治理是件非常复杂的事情,涉及上千个业务对象、上百个变革和优化改进项目的协同,仅仅通过数据管理部门对各个项目和部门的培训、指导、人员支持,不足以确保公司的治理目标和要求有效地贯彻到位。因此,华为通过内控体系,每年实施SACA评估和数据专项内部审计,揭示数据治理过程的问题, 确定改进目标和责任人,从而保证数据治理机制的有效运作。
# 建立业务负责制的数据管理责任体系
业务即行为,行为即记录,记录即数据。华为公司的每一个数据,必须由对应的业务部门承担管理责任,且必须有唯一的数据 Owner。业务负责制的数据管理责任体系,是华为数据治理体系多年实践经验的结晶,是确保体系发挥作用的基石。
# 任命数据Owner和数据管家
华为按分层分级原则任命数据Owner,在公司层面设置公司数据Owner,在各业务领域设置领域数据Owner,这样既能确保公司数据工作统筹规划,也能同时兼顾各业务领域灵活多变的特征。 公司数据Owner职责 公司数据Owner是公司数据战略的制定者、数据文化的营造者、数据资产的所有者和数据争议的裁决者,拥有公司数据日常管理的最高决策权,职责如下所示。
第一条:制定数据管理体系的愿景和路标。
第二条:传播数据管理理念,营造数据文化氛围。
第三条:建设和优化数据管理体系,包括组织与任命、授权与问责等。
第四条:批准公司数据管理的政策和法规。
第五条:裁决跨领域的数据及管理争议,解决跨领域的重大数据及管理问题。
各级数据Owner职责 各级流程Owner就是该流程域的数据Owner,在公司数据Owner的统筹下负责所管理流程域的数据管理体系的建设和优化。各业务部门是执行规则,保证数据质量,进而推动规则优化的关键环节。通过主管机构正式任命各数据主题域和业务对象的数据Owner和数据管家,数据Owner的职责可以归纳为以下五条。
第一条:负责数据管理体系建设。数据Owner要负责所辖领域的数据管理体系建设和优化,传播数据管理理念,营造数据文化氛围。
第二条:负责信息架构建设。数据Owner要负责所辖领域的信息架构建设和维护,确保关键数据被识别、分类、定义及标准化,数据的定义在公司范围内唯一,数据标准制定要考虑跨流程要求。
第三条:负责数据质量管理。数据Owner要负责保障所辖领域的数据质量,承接公司设定的数据质量目标,制定数据质量标准及测评指标,持续度量与改进。
第四条:负责数据底座和数据服务建设。数据Owner要负责所辖领域数据入湖,建设数据服务,满足公司各个部门对本领域数据的需求。
第五条:负责数据争议裁决。数据Owner要建立数据问题回溯和奖惩机制,对所辖领域的数据问题及争议进行裁决,对不遵从信息架构或存在严重数据质量问题的责任人进行问责。
数据管家是数据Owner的助手,是数据Owner在数据管理方面的具体执行者。
# 建立公司层面的数据管理组织
华为在企业范围内建立了一个公司级数据管理部,代表公司制定数据管理相关的政策、流程、方法和支撑系统,制定公司数据管理的战略规划和年度计划并监控落实。建立并维护企业信息架构,监控数据质量,披露重大数据问题,建立专业任职资格管理体系,提升企业数据管理能力,推动企业数据文化的建立和传播。
数据管理组织中各个组织的职责和分工如下所示。
1)体系建设者
第一条:负责数据管理的战略、规划、政策、规则的制定。
第二条:负责数据管理体系建设。
第三条:数据架构及核心数据资产管理。
第四条:确保公司数据质量水平。
2)能力中心
第一条:构建数据管理的方法、工具、平台。
第二条:负责专业能力的开发和建设,包括数据架构、数据分
析、信息管理、数据质量管理。
3)业务的数据伙伴
第一条:面向业务,提供数据解决方案,解决业务数据痛点。
第二条:支撑业务数据需求。
第三条:向业务提供标准化的主数据或基础数据服务。
4)文化倡导者
第一条:在公司范围建设追求卓越、“谁创建(录入)数据,谁对数据质量负责”的文化。
第二条:用数据支撑业务决策的文化。 同时,在数据工作的不同阶段,分场景组建了不同的虚拟数据团队,如信息架构建设工作组、数据质量执行组、元数据工作组等,以保障跨领域数据工作的有序开展。
当面对数字化转型这一时代挑战时,华为建立的一整套数据治理体系,使得华为公司拥有从容面对的底气。2017年华为启动数字化转型后,也极大提升了华为的数据治理能力,在实践中形成了数据全生命周期的治理规范与方案。
如下图所示
# 第三章:差异化的企业数据分类管理框架
不同的企业或组织基于不同的目的,可以从多个角度对数据进行分类,如结构化数据和非结构化数据、内部数据和外部数据、原始数 据和衍生数据、明细数据和汇总数据等。华为在业界的数据分类基础 上,结合自身多年的实践,已形成完整的数据分类管理框架。华为对 数据进行分类的目的,是为了针对不同特性的数据采取不同的管理策 略,以期实现最大的投入产出比。
# 基于数据特性的分类管理框架
华为根据数据特性及治理方法的不同对数据进行了分类定义:
- 内部数据
- 外部数据
- 结构化数据
- 基础数据
- 主数据
- 事务数据
- 报告数据
- 观测数据
- 规则数据
- 非结构化数据
- 元数据
下图是针对上面数据分类的详细定义及特征描述
不同分类的数据,其治理方法有所不同。如基础数据内容的变更通常会对现有流程、IT系统产生影响,因此基础数据的管理重点在于变更管理和统一标准管控。主数据的错误可能会导致成百上千的事务数据错误,因此主数据的管理重点是确保同源多用、重点进行数据内容的校验等。
# 以统一语言为核心的结构化数据管理
结构化数据包括基础数据、主数据、事务数据、报告数据、观测 数据、规则数据。结构化数据的共同特点是以信息架构为基础,建立 统一的数据资产目录、数据标准与模型。本节将重点介绍六类结构化 数据的治理方法。
# 基础数据治理
基础数据通常是静态的(如国家、币种),一般在业务事件发生之前就已经预先定义。它的可选值数量有限,可以用作业务或IT的开关和判断条件。当基础数据的取值发生变化的时候,通常需要对流程和IT系统进行分析和修改,以满足业务需求。因此,基础数据的管理重点在于变更管理和统一标准管控。
治理基础数据的价值如下图
华为建立了一个完整的基础数据管理框架(如下图所示),通过明确各方的管理责任、发布相关的流程和规范以及建立基础数据管理平台等来确保基础数据的有效管理。
# 主数据治理
**主数据是参与业务事件的主体或资源,是具有高业务价值的、跨流程和跨系统重复使用的数据。**主数据与基础数据有一定的相似性,都是在业务事件发生之前预先定义;但又与基础数据不同,主数据的取值不受限于预先定义的数据范围,而且主数据的记录的增加和减少一般不会影响流程和IT系统的变化。
**但是,主数据的错误可能导致成百上千的事务数据错误,**因此主数据最重要的管理要求是确保同源多用和重点进行数据内容的校验。华为的主数据管理策略如下图所示:
鉴于主数据管理的重要性,对于每个重要的主数据,都会发布相应的管理规范,数据管家依据数据质量标准定期进行数据质量的度量与改进。
同时,对于主数据的集成消费按照如下管理框架进行管理,如图 3-6所示。
华为客户主数据治理案例,具体可参考《华为数据之道》
# 事务数据治理
事务数据在业务和流程中产生,是业务事件的记录,其本身就是业务运作的一部分。 事务数据是具有较强时效性的一次性业务事件,通常在事件结束后不再更新。 事务数据会调用主数据和基础数据。 以客户框架合同为例,核心属性有32个,其中调用基础数据和主数据24个,占75%; 客户框架合同本身特有的属性8个,占25%。 同时,框架合同也引用了机会点的编码和投标项目的编码等事务数据的信息。 因此,事务数据的治理重点就是管理好事务数据对主数据和基础数据的调用,以及事务数据之间的关联关系,确保上下游信息传递顺畅。在事务数据的信息架构中需明确哪些属性是引用其他业务对象的,哪些是其自身特有的。对于引用的基础数据和主数据,要尽可能调用而不是重新创建。
# 报告数据治理
报告数据是指对数据进行处理加工后,用作业务决策依据的数据。它用于支持报告和报表的生成。 用于报告和报表的数据可以分为如下几种:
用于报表项数据生成的事实表、指标数据、维度。
用于报表项统计和计算的统计函数、趋势函数及报告规则。
用于报表和报告展示的序列关系数据。
用于报表项描述的主数据、基础数据、事务数据、观测数据。
用于对报告进行补充说明的非结构化数据。
# 观测数据治理
观测数据是通过观测工具获取的数据,观测对象一般为人、事、物、环境。相比传统数据, 观测数据通常数据量较大且是过程性的,由机器自动采集生成。不同感知方式获取的观测数据,其数据资产管理要素不同。 观测数据的感知方式可分为软感知和硬感知。软感知是使用软件或者各种技术进行数据收集,收集的对象存在于数字世界,通常不依赖于物理设备,一般是自动运行的程序或脚本;硬感知是利用设备或装置进行数据收集,收集的对象为物理世界中的物理实体,或者是以物理实体为载体的信息,其数据的感知过程是数据从物理世界向数字世界的转化过程。 观测数据的特征有如下几点:
观测数据通常数据量较大且是过程性的,主要用作监控分析。 例如,视频监控器产生的视频数据、操作系统产生的日志记录数据等;
观测数据由机器自动采集生成。例如,各种传感器或探针记录观测对象产生的数据;
观测数据是观测工具采集回来的原始数据(Raw Data),仅转换结构和格式,不做任何业务规则解析。
# 规则数据治理
在业务规则管理方面,华为经常面对“各种业务场景业务规则不同,记不住,找不到”“大量规则在政策、流程等文件中承载,难以遵守”“各国规则均不同,IT能否一国一策、快速上线”等问题。规则数据是结构化描述业务规则变量(一般为决策表、关联关系表、评分卡等形式)的数据,是实现业务规则的核心数据,如业务中普遍存在的基线数据。 规则数据主要有以下特征:
- 规则数据不可实例化;
- 规则数据包含判断条件和决策结果两部分信息,区别于描述事物分类信息的基础数据;
- 规则数据的结构在纵向(列)、横向(行)两个维度上相对稳定,变化形式多为内容刷新;
- 规则数据的变更对业务活动的影响是大范围的。
其基本原则为:
- 规则数据的管理是为了支撑业务规则的结构化、信息化、数字化,目标是实现规则的可配置、可视化、可追溯。
- 不同于标准化的信息架构管理,规则数据的管理具有轻量化、分级的特点。重要的、调用量大、变动频繁的业务规则需要通过规则数据管理,使其从代码中解耦,进行资产注册;使用广泛的、有分析需求的规则数据需要通过注册入湖,实现共享和复用。
- 业务规则在架构层次上与流程中的业务活动相关联,是业务活动的指导和依据,业务活动的结果通过该业务活动的相关业务对象的属性来记录。业务规则通过业务活动对业务事实、业务行为进行限制,业务人员可以根据业务规则判断业务情况,采取具体行动。
- 业务规则包含规则变量和变量之间的关系,规则数据主要描述规则的变量部分,是支撑业务规则的核心数据(如下图所示)
规则数据这块暂时没太理解,不过目前应该不是首要数据治理对象
# 以特征提取为核心的非结构化数据管理
相较于结构化数据,非结构化元数据管理除了需要管理文件对象的标题、格式、Owner等基本特征和定义外,还需对数据内容的客观理解进行管理,如标签、相似性检索、相似性连接等,以便于用户搜索和消费使用。因此,非结构化数据的治理核心是对其基本特征与内容进行提取,并通过元数据落地来开展的。非结构化数据的管理模型如图3-11所示。
# 以确保合规遵从为核心的外部数据管理
外部数据是指华为公司引入的外部组织或者个人拥有处置权利的数据,如供应商资质证明、消费者洞察报告等。外部数据治理的出发点是合规遵从优先,与内部数据治理的目的不同。 外部数据的治理主要遵循以下原则。
- 合规优先原则:遵从法律法规、采购合同、客户授权、公司信息安全与公司隐私保护政策等相关规定。
- 责任明确原则:所有引入的外部数据都要有明确的管理责任主体,承担数据引入方式、数据安全要求、数据隐私要求、数据共享范围、数据使用授权、数据质量监管、数据退出销毁等责任。
- 有效流动原则:使用方优先使用公司已有数据资产,避免重复采购、重复建设。
- 可审计、可追溯原则:控制访问权限,留存访问日志,做到外部数据使用有记录、可审计、可追溯。
- 受控审批原则:在授权范围内,外部数据管理责任主体应合理
- 审批使用方的数据获取要求。
# 作用于数据价值流的元数据管理
无论结构化数据,还是非结构化数据,或者外部数据,最终都会通过元数据治理落地。华为将元数据治理贯穿整个数据价值流,覆盖从数据产生、汇聚、加工到消费的全生命周期。
# 元数据治理面临的挑战
华为在进行元数据治理以前,遇到的元数据问题主要表现为数据找不到、读不懂、不可信,数据分析师们往往会陷入数据沼泽中,例如以下常见的场景。
某子公司需要从发货数据里对设备保修和维保进行区分,用来不对过保设备进行服务场景分析。为此,数据分析师需面对几十个IT系统,不知道该从哪里拿到合适的数据。因盘点内部要货的研发领料情况,需要从IT系统中获取研发内部的要货数据,面对复杂的数据存储结构(涉及超过40个物理表和超过1000个字段)、物理层和业务层脱离的情况,业务部门的数据分析师无法读懂物理层数据,只能提出需求向IT系统求助。某子公司存货和收入管理需要做繁重的数据收集与获取工作,运行一次计划耗时超过20个小时。同时,由于销售、供应、交付各领域计划的语言不通,还需要数据分析师进行大量人工转换与人工校验。
元数据管理的痛点
为解决以上痛点,华为建立了公司级的元数据管理机制。制定了统一的元数据管理方法、机制和平台,拉通业务语言和机器语言。确保数据“入湖有依据,出湖可检索”成为华为元数据管理的使命与目标。基于高质量的元数据,通过数据地图就能在企业内部实现方便的数据搜索。 元数据是描述数据的数据,用于打破业务和IT之间的语言障碍,帮助业务更好地理解数据。元数据通常分为业务、技术和操作三类。
- 业务元数据:用户访问数据时了解业务含义的途径,包括资产目录、Owner、数据密级等。
- 技术元数据:实施人员开发系统时使用的数据,包括物理模型的表与字段、ETL规则、集成关系等。
- 操作元数据:数据处理日志及运营情况数据,包括调度频度、访问记录等。
在企业的数字化运营中,元数据作用于整个价值流,在从数据源到数据消费的五个环节中都能充分体现元数据管理的价值。
- 数据消费侧:元数据能支持企业指标、报表的动态构建。
- 数据服务侧:元数据支持数据服务的统一管理和运营,并实现利用元数据驱动IT敏捷开发。
- 数据主题侧:元数据统一管理分析模型,敏捷响应井喷式增长的数据分析需求,支持数据增值、数据变现。
- 数据湖侧:元数据能实现暗数据的透明化,增强数据活性,并能解决数据治理与IT落地脱节的问题。
- 数据源侧:元数据支撑业务管理规则有效落地,保障数据内容合格、合规。
# 元数据管理架构及策略
元数据管理架构包括产生元数据、采集元数据、注册元数据和运维元数据。
产生元数据:制定元数据管理相关流程与规范的落地方案,在IT产品开发过程中实现业务元数据与技术元数据的连接。
采集元数据:通过统一的元模型从各类IT系统中自动采集元数据。
注册元数据:基于增量与存量两种场景,制定元数据注册方法,完成底座元数据注册工作。
运维元数据:打造公司元数据中心,管理元数据产生、采集、注册的全过程,实现元数据运维。
元数据管理方案:通过制定元数据标准、规范、平台与管控机制,建立企业级元数据管理体系,并推动其在公司各领域落地,支撑数据底座建设与数字化运营。
华为元数据管理整体方案
# 元数据管理
- 产生元数据
(1)明确业务元数据、技术元数据和操作元数据之间的关系,定义华为公司元数据模型,如图3-15所示。
(2)针对找数据及获取数据难的痛点,明确业务元数据、技术元数据、操作元数据的设计原则。
1)业务元数据设计原则
一个主题域分组下有多个主题域,一个主题域下有多个业务对象,一个业务对象下有多个逻辑实体,一个逻辑实体下有多个属性,一个属性有一个数据标准。每个数据标准可被一个或多个属性引用,每个属性归属于一个逻辑实体,每个逻辑实体归属于一个业务对象,每个业务对象归属于一个主题域,每个主题域归属于一个主题域分组。
2)技术元数据设计原则
物理表设计须满足三范式,如为了降低系统的总体资源消耗,提高查询效率,可反范式设计。物理表、视图和字段的设计须基于用途进行分类。承载业务用途的物理表、虚拟表、视图必须与逻辑实体一一对应,承载业务用途的字段必须与属性一一对应。系统间的数据传递须优先采用数据服务。
3)操作元数据设计原则
日志目的不同的进行分类设计,日志目的相同的进行相同设计(非自研场景按软件包适配)。
(3)规范数据资产管理,设计数据资产编码规范
1)数据资产编码规范
华为数据资产编码的主要包括业务元数据和技术元数据两大类,其中业务元数据包含主题域分组、主题域、业务对象、逻辑实体、属性、数据标准;技术元数据包含物理数据库、Schema、表、字段。具体的定义与描述如表3-2所示。
2)数据资产编码原则
数据资产编码(DAN)是通过一组数字、符号等组成的字符串去唯一标识华为公司内部每一个数据资产,基于此唯一标识,保证各业务领域对同一数据资产的理解和使用一致,它的设计遵循以下原则。
- 统一性原则:华为公司内部只能使用一套数据资产编码,以方便不同业务部门之间的沟通和IT应用之间的数据交换。
- 唯一性原则:每一个数据资产只能用唯一的数据资产编码进行标识,不同数据资产的编码不允许重复,同一个编码也只能对应到一个数据资产上。
- 可读性原则:数据资产编码作为数据资产分类、检索的关键词和索引,需要具备一定的可读性,让用户通过编码就能初步判断其对应的数据资产类型。
- 扩展性原则:数据资产的编码要从数据管理角度适当考虑未来几年的业务发展趋势,其编码长度要能适当扩展,同时不影响整个编码体系。
3)业务元数据资产编码规则 业务元数据资产编码规则主要包含三个部分:
第一部分为主题域分组的编码规则,主题域分组的编码由公司统一分配;
第二部分为主题域、业务对象、逻辑实体、属性的编码规则,这部分主要由数据治理平台按照编码规则自动生成;
第三部分主要为业务元数据包含的子类对应的数据资产类型代码。
采集元数据 元数据采集是指从生产系统、IT设计平台等数据源获取元数据,对元数据进行转换,然后写入元数据中心的过程。元数据的来源可分为如表3-3所示的六类。
选择适配器:适配器是指针对不同的元数据来源,采用相应的采集方式获取元数据的程序,元数据的来源种类繁多,因而须选择相对应的适配器及元模型。
配置数据源:配置数据源是采集元数据的关键,在确定数据源所选择的适配器:类型、适配器版本、元模型的基础上,配置数据源的名称、连接参数和描述。
配置采集任务:采集任务为自动调度的工作单元,为元数据的采集提供自动化的、周期性的、定时的触发机制。
注册元数据 大多数企业的数字化建设都存在增量和存量两种场景,如何同时有效地管理这两种场景下的元数据就成了问题的关键。华为通过标准的元数据注册规范和统一的元数据注册方法,实现了两种场景下业务元数据和技术元数据的高效连接,使业务人员能看懂数据、理解数据,并通过数据底座实现数据的共享与消费。
(1)元数据注册原则 元数据注册的原则包括如下三点:
- 数据Owner负责,是谁的数据就由谁负责业务元数据和技术元数据连接关系的建设和注册发布;
- 按需注册,各领域数据管理部根据数据搜索、共享的需求,推进元数据注册;
- 注册的元数据的信息安全密级为内部公开。
(2)元数据注册规范
通过“元数据注册三步法”完成元数据注册,如图3-16所示。
1)准备度评估项包括如下检查要点:
- IT系统名称必须是公司标准名称;
- 数据资产目录是否经过评审并正式发布;
- 数据Owner是否确定数据密级;
- 物理表/虚拟表/视图名。
2)元数据连接需遵从以下规范。
- 逻辑实体和物理表/虚拟表/视图一对一连接规范:在业务元数据与技术元数据连接的过程中,必须遵从逻辑实体和物理表/虚拟表/视图一对一的连接原则,如果出现一对多、多对一或多对多的情况,各领域需根据实际场景,参照元数据连接的设计模式进行调整。
- 业务属性与字段一对一连接规范:除了逻辑实体与物理表/虚拟表/视图要求一一对应外,属性和非系统字段(具备业务含义)也要求遵从一对一的连接原则,如出现属性与字段匹配不上的情况,可参考元数据关联的设计模式进行调整。
完成元数据注册后,通过元数据中心自动发布。
(3)元数据注册方法 元数据注册分为增量元数据注册和存量元数据注册两种场景。
- 增量场景相对容易,在IT系统的设计与开发过程中,落实元数据的相关规范,确保系统上线时即完成业务元数据与技术元数据连接,通过元数据采集器实现元数据自动注册。
- 针对存量场景,华为设计了元数据注册的四大模式。在符合元数据设计规范的前提下,进行业务元数据与技术元数据的连接及注册。
模式一:一对一模式 适用场景 适用于数据已发布信息架构和数据标准且物理落地,架构、标准与物理落地能一一对应的场景。 **解决方案 **
- 将逻辑实体和物理表一对一连接。
- 逻辑实体属性和物理表字段一对一连接。
模式二:主从模式 **适用场景 ** 适用于主表和从表结构一致,但数据内容基于某种维度分别存储在不同物理表中的场景。例如,按时间或项目归档,或按区域进行分布式存储。 解决方案 识别主物理表和从属物理表。以主物理表为核心,纵向UNION所有从属物理表,并固化为视图。将视图、逻辑实体、字段和业务属性一对一连接。
模式三:主扩模式 **适用场景 ** 适用于逻辑实体的大部分业务属性在主物理表,少数属性在其他物理表中的场景。 **解决方案 ** 识别主物理表和扩展物理表。以主物理表为核心,横向JOIN所有扩展物理表,完成扩展属性与主表的映射,并固化为视图。将视图、逻辑实体、字段和业务属性一对一连接。
模式四:父子模式 **适用场景 ** 适用于多个逻辑实体业务属性完全相同,按不同场景区分逻辑实 体名称,但落地在同一张物理表的场景。 **解决方案 **
- 识别一张物理表和对应的多个逻辑实体。
- 将物理表按场景拆分和多个逻辑实体一对一连接。
- 将物理表字段和多个逻辑实体属性一对一连接。
运维元数据 运维元数据是为了通过对元数据进行分析,发现数据注册、设计、使用的现状及问题,确保元数据的完整、准确。通过数据资产分析,了解各区域/领域的数据注册情况,进而发现数据在各信息系统使用过程中存在的问题。通过业务元数据与技术元数据的关联分析,反向校验架构设计与落地的实施情况,检查公司数据管理政策的执行情况。 主要分为如下四个场景。
场景一:基于数据更新发现,数据源上游创建,下游更新;
场景二:通过数据调用次数发现,某数据源上游调用次数<下游调用次数;
场景三:虽制定了架构标准,但不知落地情况,比如某个属性建立了数据标准,但是却找不到对应落地的物理表字段;
场景四:通过物理表的字段分析,发现很多字段缺少数据标准。
# 4-6章:数据治理工作中的三项重点建设任务
# 第四章:面向“业务交易”的信息架构建设
# 信息架构的四个组件
企业在运作过程中,首先需要管理好人和物等“资源”,然后管理好各类资源之间的联系,即各类业务交易“事件”,再对各类事件的执行效果进行“整体描述和评估”,最终实现组织目标和价值。
信息架构的目的就是定义好整个运作过程中涉及的各种人、事、物资源,并实施有效的治理,从而确保各类数据在企业各业务单元间高效、准确地传递,上下游流程快速地执行和运作。
华为的企业级信息架构(Information Architecture)是指以结构化的方式描述在业务运作和管理决策中所需要的各类信息及其关系的一套整体组件规范,包括数据资产目录、数据标准、企业级数据模型和数据分布四个组件,如下图所示:
# 数据资产目录
数据资产目录形成完善的企业资产地图,也在一定程度上为企业数据治理、业务变革提供了指引。基于数据资产目录可以识别数据管理责任,解决数据问题争议,帮助企业更好地对业务变革进行规划设计,避免重复建设。数据资产目录分为5层,涵盖华为公司的所有业务数据资产,如下图所示:
- L1为主题域分组:是描述公司数据管理的最高层级分类。业界通常有两种数据资产分类方式:基于数据自身特征边界进行分类和基于业务管理边界进行分类。华为公司为了强化企业内业务部门的数据管理责任,更好地推进数据资产建设、数据治理和数据消费建设,采用业务管理边界划分方式,即将L1主题域分组与流程架构L1相匹配,数据资产和华为业务GPO(全球流程责任人)相匹配,有利于更好地推进各项数据工作。
- L2为主题域:是互不重叠的数据分类,管辖一组密切相关的业务对象,通常同一个主题域有相同的数据Owner。
- L3为业务对象:是信息架构的核心层,用于定义业务领域重要的人、事、物,架构建设和治理主要围绕业务对象开展。同时,在企业架构(EA)的范畴内,信息架构(IA)也主要通过业务对象实现与业务架构(BA)、应用架构(AA)、技术架构(TA)的架构集成。
- L4是逻辑数据实体:是指描述一个业务对象在某方面特征的一组属性集合。
- L5为属性:是信息架构的最小颗粒,用于客观描述业务对象在某方面的性质和特征。
# 数据标准
数据标准定义公司层面需共同遵守的属性层数据含义和业务规则,是公司层面对某个数据的共同理解,这些理解一旦确定下来,就应作为企业层面的标准在企业内被共同遵守。
华为公司对业务数据标准有严格的限定,每个数据标准应该覆盖以下三方面。
- 业务视角要求:用于统一业务侧语言和理解,明确定义每个属性所遵从的业务定义和用途、业务规则、同义词,并对名称进行统一定义,避免重复。
- 技术视角要求:对IT实施形成必要的指引和约束,包括数据类型、长度,如果存在多个允许值,则应对每个允许值进行明确的限定。
- 管理视角要求:明确各业务部门在贯彻数据标准管理方面应承担的责任,包括业务规则责任主体、数据维护责任主体、数据监控责任主体,因为很多情况下这些责任并不是由同一个业务部门来负责,所以必须在标准制订时就约定清楚。例如,“客户合同”中某些条款的规则制订者可能是财经部门,负责与客户达成约定并在系统中录入的可能是销售业务部门,而对整个客户合同数据质量进行跟踪、监控的可能是数据专业部门。
由于企业IT系统数据较多,哪些情况下的数据应该制订统一的标准?
- 描述业务对象的特有属性应作为本业务对象的属性进行定义,并明确业务数据标准。
- 引用其他业务对象的属性,如果属性值可随本业务对象确定和更改,就应作为本业务对象的属性进行定义,并明确业务数据标准。
- 引用其他业务对象的属性,如果属性值取自引用业务对象相应时点的数值且后续不变更,就应纳入本业务对象的数据标准范围,并明确相应取值规则。
- 引用其他业务对象的属性,如果属性值与引用业务对象同步,就不需要重新定义数据标准。
- 引用其他业务对象/逻辑数据实体的身份标识属性,应作为本业务对象的属性进行定义,但只能在业务数据标准中定义出处及引用规则,而不允许修改或重新定义该属性本身的业务含义及业务规则。
# 数据模型
数据模型是从数据视角对现实世界特征的模拟和抽象,根据业务需求抽取信息的主要特征,反映业务信息(对象)之间的关联关系。 数据模型不仅能比较真实地模拟业务(场景),同时也是对重要业务模式和规则的固化。例如在某个物流业务数据模型中,“运输申付单”与“运输委托”建立一对一关系,而“运输委托”与“派送任务”建立多对多关系,那么这意味着业务部门可以根据发货效率和成本的考虑将“运输委托”拆成分多个“派送任务”,但“派送任务”必须在将一个运输委托完整执行后,才能申请向供应商付款。
# 数据分布
如果说前三个组件主要是从静态角度对数据、数据关系进行定义,那么数据分布则定义了数据产生的源头及在各流程和IT系统间的流动情况。数据分布组件的核心是数据源,指业务上首次正式发布某项数据的应用系统,并经过数据管理专业组织认证,作为企业范围内唯一数据源头被周边系统调用。华为公司规定所有业务数据必须认证数据源,并在公司范围内统一发布。为了更好地识别、管理数据在流程和IT系统间的流动,可以通过信息链、数据流来进行描述,体现某一 数 据 在 流 程 或 应 用 系 统 中 是 如 何 被 创 建 ( Create ) 、 读 取(Read)、更新(Update)、删除(Delete)的。
# 信息架构原则:建立企业层面的共同行为准则
信息架构承载了企业如何管理数据资产的方法,需要从整个企业层面制订统一的原则,这些原则不仅是对数据专业人员的要求,也是对业务的要求,因为业务才是真正的数据Owner。所以,公司所有业务部门都应该共同遵从信息架构原则。华为首先确定了“数据同源一致”的治理目标,围绕目标的实现,制定了五条架构原则。各业务领域和变革项目应按照架构原则设计其信息架构,并由EAC(企业架构委员会)、IA-SAG(信息架构专家组)指导和监督各领域落实企业架构原则,在一套规则的约束下,共同建设一个企业级的信息架构。
# 原则一:数据按对象管理,明确数据Owner
几乎所有的企业数据都是由业务产生的,IT人员无法对数据的定义、质量负责,因此需要在公司层面确定数据Owner。华为公司按照业务对象任命数据Owner,并且每个数据都只能有唯一的数据Owner。数据Owner要负责所辖领域的信息架构建设和维护,负责保障所辖领域的数据质量,承接公司各个部门对本领域数据的需求,并有责任建立数据问题回溯和奖惩机制,对所辖领域的数据问题及争议进行裁决,公司有权对不遵从信息架构或存在严重数据质量问题的责任人进行问责。
# 原则二:从企业视角定义信息架构
任何一个数据Owner都不只代表自己所辖业务范围的数据管理诉求,而是代表公司对数据进行管理。
# 原则三:遵从公司的数据分类管理框架
为了协同企业内各业务领域的数据治理,华为在实践中总结了各类数据的内在特性,制定了统一的数据分类管理框架,公司所有业务领域按照统一的分类框架进行数据治理。
# 原则四:业务对象结构化、数字化
华为在长期的数据治理过程中,制定了业务对象结构化、数字化的架构设计原则,实现数据处理效率的提升,构建数据的处理和应用能力,支撑业务管理。 业务对象内容包括业务结果、业务规则、业务过程,并应打造相应的数字化能力。
# 原则五:数据服务化,同源共享
华为制定了数据同源共享的架构原则,每一个数据有且只有单一数据源,数据使用方应从数据源获取数据,数据更改应在数据源进行。 为了克服企业业务和IT的复杂性这一客观现实,华为公司持续推进数据服务建设,要求各数据Owner通过数据服务向各业务环节提供数据,各业务环节也有责任通过服务来合理获取数据,从而在整个企业层面实现数据的“一点定义、全局共享”。
# 信息架构建设核心要素:基于业务对象进行设计和落地
# 按业务对象进行架构设计
业务对象是指业务领域中重要的人、事、物对象。业务对象承载了业务运作和管理涉及的重要信息,是信息架构中最重要的管理要素。 业务对象同时还是业务和IT的关键连接点,也是实现IA(信息架构)、BA(业务架构)、AA(应用架构)、TA(技术架构)集成的关键要素。
以一个简化的交易场景为例(如图4-4所示),要完成一个交易,实现商业价值的兑现,企业内的某个子公司,需要与法人客户签订客户合同,在客户合同中,要明确交易的产品。在这个场景中,子公司、法人客户、客户合同、产品是企业需要管理和控制的核心对象,要作为业务对象进行管理。
在进行信息架构设计时,架构师、业务代表、数据Owner通常会对业务对象的判定存在理解上的偏差,从而产生争议。数据治理部门需要制定一套确定性的规则,通过确定性的规则促进形成稳定的架构。
华为通过以下四条原则来判定业务对象。
原则一:业务对象是指企业运作和管理中不可缺少的重要人、事、物
原则二:业务对象有唯一身份标识信息
原则三:业务对象相对独立并有属性描述
原则四:业务对象可实例化
# 按业务对象进行架构落地
信息架构向IT侧落地的主要交付件是数据模型。数据模型本身有相对比较成熟的方法体系支撑,不同企业之间可能名称存在差异,但本质差别不大。华为公司将数据模型分为三层:概念数据模型、逻辑数据模型、物理数据模型 本节讲的是一些数据建模相关知识,可自行深入学习
# 传统信息架构向业务数字化扩展:对象、过程、规则
# 本章前面提到,华为公司的信息架构最初是为了满足“信息化”和“业务上ERP”过程中提出的数据管理要求,但随着数字化转型的深入,发现既有信息架构已经无法满足自身业务需要,主要体现在以下几个方面。
- 大量业务和作业所产生的数据并没有完整地被管理
- 大量业务过程没有形成可视、可管理的数据
- 大量业务规则缺乏管理、无法灵活使用
因此,华为公司在传统信息架构的基础上,提出了面向数字化转型的扩展:对象数字化、过程数字化、规则数字化,并打造与之相应的能力。
1)对象数字化
对象数字化的目标是建立对象本体在数字世界的映射。这种映射不是传统意义上基于流程要求的少量数据的管理,而是管理某个对象的全量数据,如下图所示。
过程数字化
仅仅管理好结果还不够,有时我们需要把作业过程记录下来,了解过程进度或者反过来改进结果。这种记录首先是不干预业务活动的,并且能够自动记录(例如,车辆行驶中自动监控是否存在交通违规)。
规则数字化
规则数字化的目的是把复杂场景下的复杂规则用数字化手段进行管理。良好的规则数字化管理,应该能实现业务规则与IT应用解耦,所有关键业务规则数据要实现可配置,能够根据业务的变化灵活调整,如下图所示:
同样以物流场景为例,通常业务希望基于计划对各个环节的物流任务进行监控和预警,这需要大量的预警规则。例如,某个部件的物流周期是1周,当5天后要交付而对应物流还未发货,则应该预警。但是,不同物料、不同场景、不同国家的供应能力往往是有差异的,并且随着环境经常动态变化,这就需要将对应的规则数据从IT应用中解耦出来,单独定义这类数据资产的信息架构,从而使之能够灵活调整。这样,不同国家的业务人员就可以根据需要随时调整规则,而不 用对现有IT系统进行大的改动,最大程度地满足业务灵活性的要求。
在企业实现数字化转型的过程中,信息架构管理的结构、技术、组件、标准可能永远不会稳定,永远在进化。
# 第五章:面向“联接共享”的数据底座建设
在从信息化向数字化转型的过程中,企业积累了海量的数据,并且还在爆发式地增长。数据很多,但真正能产生价值的数据却很少。数据普遍存在分散、不拉通的问题,缺乏统一的定义和架构,找到想要的、能用的数据越来越难。
# 支撑非数字原生企业数字化转型的数据底座建设框架
华为通过建设数据底座,将公司内外部的数据汇聚在一起,对数据进行重新组织和联接,让数据有清晰的定义和统一的结构,并在尊重数据安全与隐私的前提下,让数据更易获取,最终打破数据孤岛和垄断。通过数据底座,主要可以实现如下目标。
- 统一管理结构化、非结构化数据。将数据视为资产,能够追溯数据的产生者、业务源头以及数据的需求方和消费者等。
- 打通数据供应通道,为数据消费提供丰富的数据原材料、半成品以及成品,满足公司自助分析、数字化运营等不同场景的数据消费需求。
- 确保公司数据完整、一致、共享。监控数据全链路下的各个环节的数据情况,从底层数据存储的角度,诊断数据冗余、重复以及“僵尸”问题,降低数据维护和使用成本。
- 保障数据安全可控。基于数据安全管理策略,利用数据权限控制,通过数据服务封装等技术手段,实现对涉密数据和隐私数据的合法、合规地消费。
# 数据底座的总体架构
华为数据底座由数据湖、数据主题联接两层组成,将公司内外部的数据汇聚到一起,并对数据进行重新的组织和联接,为业务可视化、分析、决策等提供数据服务,如下图所示。
数据湖是逻辑上各种原始数据的集合,除了“原始”这一特征外,还具有“海量”和“多样”(包含结构化、非结构化数据)的特征。数据湖保留数据的原格式,原则上不对数据进行清洗、加工,但对于数据资产多源异构的场景需要整合处理,并进行数据资产注册。
数据入湖必须要遵循6项标准,共同满足数据联接和用户数据消费需求。
数据主题联接是对数据湖的数据按业务流/事件、对象/主体进行联接和规则计算等处理,形成面向数据消费的主题数据,具有多角度、多层次、多粒度等特征,支撑业务分析、决策与执行。基于不同的数据消费诉求,主要有多维模型、图模型、指标、标签、算法模型5种数据联接方式。
# 数据底座的建设策略
数据底座建设不能一蹴而就,要从业务出发,因势利导,持续进行。具体来说,华为数据底座采取“统筹推动、以用促建、急用先行”的建设策略,根据公司数字化运营的需要,由公司数据管理部统一规划,各领域分别建设,以满足本领域和跨领域的数据需求。其中,数据Owner是各领域数据底座建设的第一责任人,各领域数据部负责执行。数据底座资产建设遵从下面四项原则。
- 数据安全原则:数据底座数据资产应遵循用户权限、数据密级、隐私级别等管理要求,以确保数据在存储、传输、消费等全过程中的数据安全。技术手段包括但不限于授权管理、权限控制、数据加密、数据脱敏。
- 需求、规划双轮驱动原则:数据底座数据资产基于业务规划和需求触发双驱动的原则进行建设,对核心数据资产优先建设。
- 数据供应多场景原则:数据底座资产供应需根据业务需求提供离线/实时、物理/虚拟等不同的数据供应通道,满足不同的数据消费场景。
- 信息架构遵从原则:数据底座数据资产应遵从公司的信息架构,必须经IA-SAG(信息架构专家组)发布并完成注册。
# 数据湖:实现企业数据的“逻辑汇聚”
# 华为数据湖的3个特点
华为数据湖(如图5-2所示)是逻辑上对内外部的结构化、非结构化的原始数据的逻辑汇聚。数据入湖要遵从6项入湖标准,基于6项标准保证入湖的质量,同时面向不同的消费场景提供两种入湖方式,满足数据消费的要求。经过近两年的数据湖建设,目前已经完成1.2万个逻辑数据实体、28万个业务属性的入湖,同时数据入湖在华为公司也形成了标准的流程规范,每个数据资产都要入湖成为数据工作的重要标准。
华为数据湖主要有以下几个特点。
- 逻辑统一:华为数据湖不是一个单一的物理存储,而是根据数据类型、业务区域等由多个不同的物理存储构成,并通过统一的元数据语义层进行定义、拉通和管理。
- 类型多样:数据湖存放所有不同类型的数据,包括企业内部IT系统产生的结构化数据、业务交易和内部管理的非结构化的文本数据、公司内部园区各种传感器检测到的设备运行数据,以及外部的媒体数据等。
- 原始记录 :华为数据湖是对原始数据的汇聚,不对数据做任何的转换、清洗、加工等处理,保留数据最原始特征,为数据的加工和消费提供丰富的可能。
# 数据入湖的6个标准
数据入湖是数据消费的基础,需要严格满足入湖的6项标准,包括明确数据Owner、发布数据标准、定义数据密级、明确数据源、数据质量评估、元数据注册。通过这6项标准保证入湖的数据都有明确的业务责任人,各项数据都可理解,同时都能在相应的信息安全保障下进行消费。
- 明确数据Owner:数据Owner由数据产生对应的流程Owner担任,是所辖数据端到端管理的责任人,负责对入湖的数据定义数据标准和密级,承接数据消费中的数据质量问题,并制定数据管理工作路标,持续提升数据质量。
- 发布数据标准:入湖数据要有相应的业务数据标准。业务数据标准描述公司层面需共同遵守的“属性层”数据的含义和业务规则,是公司层面对某个数据的共同理解,这些理解一旦明确并发布,就需要作为标准在企业内被共同遵守。数据标准的信息如下表所示。
- 认证数据源:通过认证数据源,能够确保数据从正确的数据源头入湖。认证数据源应遵循公司数据源管理的要求,一般数据源是指业务上首次正式发布某项数据的应用系统,并经过数据管理专业组织认证。认证过的数据源作为唯一数据源头被数据湖调用。当承载数据源的应用系统出现合并、分拆、下线情况时,应及时对数据源进行失效处理,并启动新数据源认证。
- 定义数据密级:定义数据密级是数据入湖的必要条件,为了确保数据湖中的数据能充分地共享,同时又不发生信息安全问题,入湖的数据必须要定密。数据定密的责任主体是数据Owner,数据管家有责任审视入湖数据密级的完整性,并推动、协调数据定密工作。数据定级密度在属性层级,根据资产的重要程度,定义不同等级。不同密级的数据有相应的数据消费要求,为了促进公司数据的消费,数据湖中的数据有相应的降密机制,到降密期或满足降密条件的数据应及时降密,并刷新密级信息。
- 数据质量评估:数据质量是数据消费结果的保证,数据入湖不需要对数据进行清洗,但需要对数据质量进行评估,让数据的消费人员了解数据的质量情况,并了解消费该数据的质量风险。同时数据Owner和数据管家可以根据数据质量评估的情况,推动源头数据质量的提升,满足数据质量的消费要求。
- 元数据注册:元数据注册是指将入湖数据的业务元数据和技术元数据进行关联,包括逻辑实体与物理表的对应关系,以及业务属性和表字段的对应关系。通过联接业务元数据和技术元数据的关系,能够支撑数据消费人员通过业务语义快速地搜索到数据湖中的数据,降低数据湖中数据消费的门槛,能让更多的业务分析人员理解和消费数据。
# 数据入湖方式
数据入湖遵循华为信息架构,以逻辑数据实体为粒度入湖,逻辑数据实体在首次入湖时应该考虑信息的完整性。原则上,一个逻辑数据实体的所有属性应该一次性进湖,避免一个逻辑实体多次入湖,增加入湖工作量。 数据入湖的方式主要有物理入湖和虚拟入湖两种,根据数据消费的场景和需求,一个逻辑实体可以有不同的入湖方式。两种入湖方式相互协同,共同满足数据联接和用户数据消费的需求,数据管家有责任根据消费场景的不同,提供相应方式的入湖数据。物理入湖是指将原始数据复制到数据湖中,包括批量处理、数据复制同步、消息和流集成等方式。虚拟入湖是指原始数据不在数据湖中进行物理存储,而是通过建立对应虚拟表的集成方式实现入湖,实时性强,一般面向小数据量应用,大批量的数据操作可能会影响源系统。
数据入湖有以下5种主要技术手段。
- 批量集成(Bulk/Batch Data Movement) :对于需要进行复杂数据清理和转换且数据量较大的场景,批量集成是首选。通常,调度作业每小时或每天执行,主要包含ETL、ELT和FTP等工具。批量集成不适合低数据延迟和高灵活性的场景。
- 数据复制同步(Data Replication/Data Synchronization) :适用于需要高可用性和对数据源影响小的场景。使用基于日志的CDC捕获数据变更,实时获取数据。数据复制同步不适合处理各种数据结构以及需要清理和转换复杂数据的场景。
- 消息集成(Message-Oriented Movement of Data) :通常通过API捕获或提取数据,适用于处理不同数据结构以及需要高可靠性和复杂转换的场景。尤其对于许多遗留系统、ERP和SaaS来说,消息集成是唯一的选择。消息集成不适合处理大量数据的场景。
- 流集成(Stream Data Integration) :主要关注流数据的采集和处理,满足数据实时集成需求,处理每秒数万甚至数十万个事件流,有时甚至数以百万计的事件流。流集成不适合需要复杂数据清理和转换的场景。
- 数据虚拟化(Data Virtualization) :对于需要低数据延迟、高灵活性和临时模式(不断变化下的模式)的消费场景,数据虚拟化是一个很好的选择。在数据虚拟化的基础上,通过共享数据访问层,分离数据源和数据湖,减少数据源变更带来的影响,同时支持数据实时消费。数据虚拟化不适合需要处理大量数据的场景。
5种数据入湖的方式对比
# 结构化数据入湖
结构化数据入湖过程包括:数据入湖需求分析及管理、检查数据入湖条件和评估入湖标准、实施数据入湖、注册元数据
- 数据入湖需求分析及管理:
对于规划驱动入湖场景而言,由对应的数据代表基于数据湖的建 设规划,输出入湖规划清单,清单包含主题域分组、主题域、业务对 象、逻辑实体、业务属性、源系统物理表和物理字段等信息。 对于需求驱动入湖场景而言,由数据消费方的业务代表提出入湖 需求,并提供数据需求的业务元数据和技术元数据的信息,包括业务 对象、逻辑实体、业务属性对应界面的截图。 无论是主动规划还是被动响应需求,入湖需求清单必须通过业务 代表和数据代表的联合评审。当业务代表和数据代表就评审结论发生 争议时,可到专业评审组织申请仲裁。
- 检查数据入湖条件和评估入湖标准
在数据入湖前要检查数据源准备度和评估数据入湖标准。 (1)检查数据源准备度
- 数据有源是数据入湖的基本前提,数据源准备度检查不仅需要源系统的IT团队提供源系统的数据字典和数据模型并检查源系统的物理表规范度,而且需要数据代表评估源系统的数据质量。
(2)评估入湖标准 入湖标准包括以下几点。 明确数据Owner:为保证入湖数据的管理责任清晰,在数据入湖前应明确数据Owner。 发布数据标准:入湖数据应有数据标准,数据标准定义了数据属性的业务含义、业务规则等,是正确理解和使用数据的重要依据,也是业务元数据的重要组成部分。 认证数据源:原则上以初始源进湖,数据源认证是保证数据湖数据一致性和唯一性的重要措施。 定义数据密级:定义完整、明确的数据密级是数据湖数据共享、权限控制等的关键依据。信息安全管理专员向业务Owner提出定密需求,并与业务Owner确定定密规则,确定数据密级、定密时间、降密期/降密条件等,然后由信息安全管理专员在信息架构管理平台注册密级信息。 评估入湖数据质量:对入湖数据做质量评估,给入湖数据打质量标签。如果不满足上述任意一条入湖标准,就应推动源系统数据代表完成整改,满足要求后方可实施数据入湖。
- 实施数据入湖
数据代表依据消费场景合理选择入湖方式,在不要求历史数据、小批量数据且实时性要求高的场景,建议虚拟入湖;在要求历史数据、大批量数据且实时性要求不高的场景,可以物理入湖。虚拟入湖由数据代表实施,数据代表负责设计和部署虚拟表。物理入湖由对应数据湖的IT代表承接IT实施需求,设计集成方案和数据质量监测方案,实施数据入湖。数据代表组织UAT测试、上线验证。 4. 注册元数据 元数据是公司的重要资产,是数据共享和消费的前提,为数据导航和数据地图建设提供关键输入。对元数据进行有效注册是实现上述目的的前提。虚拟表部署完成后或IT实施完成后,由数据代表检查并注册元数据,元数据注册应遵循企业元数据注册规范。
# 非结构化数据入湖
非结构化数据入湖的4种方式
非结构化数据入湖包括基本特征元数据入湖、文件解析内容入湖、文件关系入湖和原始文件入湖4种方式,其中基本特征元数据入湖是必选内容,后面三项内容可以根据分析诉求选择性入湖和延后入湖,如图5-5所示。
1)基本特征元数据入湖
主要通过从源端集成的文档本身的基本信息入湖。入湖的过程中,数据内容仍存储在源系统,数据湖中仅存储非结构化数据的基本特征元数据。基本特征元数据入湖需同时满足如下条件。
- 已经设计了包含基本特征元数据的索引表。
- 已经设计了信息架构,如业务对象和逻辑实体。
- 已经定义了索引表中每笔记录对应文件的Owner、标准、密级,认证了数据源并满足质量要求。
参考都柏林核心元数据,非结构化数据的基本特征类属性元数据规范如表5-4所示。
2)文件解析内容入湖
对数据源的文件内容进行文本解析、拆分后入湖。入湖的过程中,原始文件仍存储在源系统,数据湖中仅存储解析后的内容增强元数据。内容解析入湖需同时满足如下条件。
- 已经确定解析后的内容对应的Owner、密级和使用的范围。
- 已经获取了解析前对应原始文件的基本特征元数据。
- 已经确定了内容解析后的存储位置,并保证至少一年内不会迁移。
3)文件关系入湖 根据知识图谱等应用案例在源端提取的文件上下文关系入湖。入湖的过程中,原始文件仍存储在源系统,数据湖中仅存储文件的关系等内容增强元数据。文件关系入湖需同时满足如下条件:
- 已经确定文件对应的Owner、密级和使用的范围。
- 已经获取了文件的基本特征元数据。
- 已经确定了关系实体的存储位置,并保证至少一年内不会迁移。
4)原始文件入湖 根据消费应用案例从源端把原始文件搬入湖。数据湖中存储原始文件并进行全生命周期管理。原始文件入湖需同时满足如下条件。
已经确定原始文件对应的Owner、密级和使用的范围。
已经获取了基本特征元数据。
已经确定了存储位置,并保证至少一年内不会迁移。
# 数据主题联接:将数据转换为“信息”
# 5类数据主题联接的应用场景
在数字化转型的背景下,华为的数据消费已经不再局限于传统的报表分析,还要支持用户的自助分析、实时分析,通过数据的关联,支持业务的关联影响分析以及对目标对象做特征识别,进行特定业务范围圈定、差异化管理与决策等。这些分析需求也不再是对单一数据的分析,往往需要对跨领域的数据进行联接后再进行综合分析。 目前,数据湖汇聚了大量的原始数据,用户不再需要到各个源系统调用数据,而是统一从数据湖调用。由于数据湖中的数据零散且数据结构都与源系统一致,严格遵从三范式,即使每个数据都有详细的定义和解释,用户也很难知道数据之间的关联关系。例如,消费者BG做设备收入预测需要的数据有产品、订单、计划等超过150个物理表信息,这些表没有进行联接,没有形成有用信息,是很难支撑用户进行分析的。 华为在数据湖的基础上通过建立数据联接层,基于不同的分析场景,通过5类联接方式将跨域的数据联接起来,将数据由“原材料”加工成“半成品”和“成品”,支撑不同场景的数据消费需求,如图5-6所示。
# 多维模型设计
多维模型是依据明确的业务关系,建立基于维度、事实表以及相互间连接关系的模型,实现多角度、多层次的数据查询和分析。如何设计出稳定、易扩展、高可用的数据模型来支持用户消费对数据主题联接至关重要。
多维模型设计有4个主要步骤,包括确定业务场景、声明粒度、维度设计和事实表设计。
- 确定业务场景:分析业务需求,识别需求中所涉及的业务流及其对应的逻辑数据实体和关联关系。如业务负责人(PO)履行全流程可视,首先需要识别监控的具体业务环节(如发货、开票等),再根据这些业务环节识别其对应的逻辑数据实体及关联关系,如图5-7所示。
- 声明粒度:粒度表示数据单元的细节程度或综合程度,细节程度越高,粒度越细;细节程度越低,粒度越粗。声明粒度是维度和事实表设计的重要步骤,声明粒度意味着精确定义事实表的每一行表示什么。针对监控PO履行这个场景,在做设计时首先要确认是监控PO的履行,还是具体到每个PO行的履行,不同的粒度会对应不同的事实表。
- 维度设计:维度是用于观察和分析业务数据的视角,支持对数据进行汇聚、钻取、切片分析,如图5-8所示。维度由层次结构(关系)、层级、成员、属性组成。
维度可以分为基础树和组合树,维度基础树提供统一定义的、完整的层级结构和成员;维度组合树根据业务使用场景进行定制。
维度设计需要满足单一性、单向性和正交性。
单一性:有且仅有一个视角,在同一个维度中不能穿插其他经营分析的视角,例如,区域维不含客户视角,产品维不含客户视角等。图5-9中区域维度客户视角不满足单一性要求。
2)单向性 :“上大下小”,维度只能支撑自上而下的分解和自下而上的收敛,每个成员只能存在向上的收敛路径,不能具备向上和向下两个方向的收敛逻辑。图5-10中代表处维度低于国家维度,不满足单向性要求。
3)正交性:成员两两不相交,同一成员不能同时拥有多个上级成员,以产品维为例,华为向客户提供的设备或服务都只能被准确地分配到唯一叶子(最底层)节点,并以此路径进行收敛。图5-11中最小粒度成员“无线专业服务”同时归属不同的上层节点,不满足正交性要求。
(4)事实表设计
事实表存储业务过程事件的性能度量结果,由粒度属性、维度属性、事实属性和其他描述属性组成,如图5-12所示。
粒度属性是事实表的主键,通常由原始数据的主键或一组维度属性生成。
维度属性是从维度中继承的属性,可以只继承主键作为事实表的外键,也可以继承维度中全部或其他部分的属性。在上述例子中,事实表中除了有币种ID,还可以带有币种编码和币种名称等属性。
- 事实属性是可以对该颗粒度的事实进行定量的属性,大多数的事实表包括一个或多个事实字段。
- 同一事实表中不能存在多种不同粒度的事实,比如PO行明细事实表中不应该包含PO总金额,否则PO总金额累加时会出现错误。
- 尽可能包含所有与业务过程相关的事实,不包含与业务过程无关的事实,比如在设计“订单下单”这个业务过程的事实表时,不应该存在“支付金额”这个支付业务过程的事实。
- 对于不可相加的事实,需要分解为可加的事实。比如比率,需要分解为分子和分母。
- 事实的数值单位要保持一致。
其他属性主要包括创建人、创建时间、最后修改人、最后修改时间等审计字段。
注解:多维模型设计这块内容,类似于数仓的数仓星型模型建模,维度和事实的建设类似总线矩阵设计
# 图模型设计
图模型作为当前流行的信息处理加工技术,自提出以来,迅速在学术界和工业界得到了普及,在智能推荐、决策分析等方面有着广泛的应用。
图模型由节点和边组成。节点表示实体或概念,边则由属性或关系构成。实体指的是具有可区别性且独立存在的某种事物,如某一个人、某一个城市、某一种植物、某一种商品等,是图模型中的最基本元素;概念是对特征的组合而形成的知识单元,主要指集合、类别、对象类型、事物的种类,例如人物、地理等;属性主要指描述实体或概念的特征或特性,例如人员的国籍、生日等。我们以“哲学家”为例设计图模型,如图5-13所示。
图模型构建包含几个关键步骤,如图5-14所示。
第一步:业务场景定义。
业务场景决定信息涵盖范围,以及信息颗粒度的表示。以支撑业务连续性为例,因为不可抗力的影响,部分区域的供应商工厂无法正常生产和发货,涉及的信息包括供应商的信息、产能、元器件及内部物料、合同和客户信息,要求能够根据用户输入的当前物料储备和合同状态,获取影响内部物料、产品、合同交付和客户的清单和范围。这种应用涉及对产品目录和配置的解读,需要对收集的信息进行最小采购器件的抽取。
信息颗粒度在图模型建设中是个不可忽视的问题,根据应用场景决定信息颗粒度以及图模型的精确性与有效性。比如手机,有品牌、型号、批次,直至手机整机。同样的信息范围,颗粒度越细,图模型应用越广泛,关系越丰富,但冗余越多,知识消费越低效。信息颗粒度的原则是“能满足业务应用的最粗颗粒度”。
第二步:信息收集。 信息的选取要考虑两个方面的内容。 1)与应用场景直接相关的信息。例如,判断不可抗力供应中断影响的范围,直接相关的信息有物料信息、产品配置、合同信息等。 2)与应用场景间接相关,但可辅助理解问题的信息。这包括企业信息、专业领域信息、行业信息以及开放域信息。
第三步:图建模。 相同的数据可以有若干种模式的定义,良好的模式可以减少数据冗余,提高实体识别的准确率,在建模的过程中,要结合数据特点与应用场景来完成。同样的数据从不同的视角可以得出不同的图模型。
第四步:实体、概念、属性、关系的标注。 企业图模型中涉及的实体和概念可分为三类:公共类,如人名、机构名、地名、公司名、时间等;企业类,如业务术语、企业部门等;行业类,如金融行业、通信行业等。
第五步:实体和概念的识别。 企业图模型中实体、概念的识别可将业务输入与数据资产中已有的信息作为种子,运用命名实体识别(NER)的方法扩展出新实体概念,经业务确认后,列入实体、概念库。
第六步:属性识别与关系识别。 企业图模型中的属性与关系一般是根据业务知识在模式层设计时定义,属性与关系相对稳定,其扩展场景不是很多。 企业图模型的存储技术要综合考虑应用场景、图模型中节点和联接的数量、逻辑的复杂度、属性的复杂度,以及性能要求。一般建议采用混合存储方式,用图数据库存储关系,关系型数据库或键值对存储属性。偏重逻辑推理的应用场景用RDF的存储方式,偏重图计算的应用场景选择属性图的存储方式。发挥两类数据存储和读写的各自优势。 知识计算主要是根据图谱提供的信息得到更多隐含的知识,如通过模式层以及规则推理技术可以获取数据中存在的隐含信息。知识计算涉及三大关键技术:图挖掘计算、基于本体的推理、基于规则的推理。图挖掘计算是基于图论的相关算法,实现对图谱的探索和挖掘。
图挖掘计算主要分为如下6类。
- 图遍历:知识图谱构建完之后可以理解为是一张很大的图,可以 去查询和遍历这个图,要根据图的特点和应用场景进行遍历。
- 图里面经典的算法,如最短路径。
- 路径的探寻,即根据给定两个实体或多个实体去发现它们之间的关系。
- 权威节点的分析,这在社交网络分析中使用较多。
- 族群分析。
- 相似节点的发现。
图挖掘计算如图5-15所示。
图挖掘计算在当前的应用场景中,基于业务连续性,通过查询遍历图模型,识别影响节点和影响范围,基于最短路径,辅助决策物流线路,在企业中的应用较为普遍。
图模型在企业中的价值,很大程度上取决于企业基于对象节点可以构建多完善的关系,这个关系的构建是一个逐步完善的过程,基于业务场景不断补充和完善关系,这就是图模型的优势。当形成一个足够完善的企业级图模型后,领域分段的业务场景应用只需要裁剪部分节点和关系,就可以满足业务的需求,达到快速响应业务需求、降低开发成本的目的。
# 标签设计
标签是根据业务场景的需求,通过对目标对象(含静态、动态特性)运用抽象、归纳、推理等算法得到的高度精练的特征标识,用于差异化管理与决策。标签由标签和标签值组成,打在目标对象上,如图5-16所示。
标签由互联网领域逐步推广到其他领域,打标签的对象也由用户、产品等扩展到渠道、营销活动等。在互联网领域,标签有助于实现精准营销、定向推送、提升用户差异化体验等;在行业领域,标签更多助力于战略分级、智能搜索、优化运营、精准营销、优化服务、智慧经营等。
标签分为事实标签、规则标签和模型标签,如图5-17所示。
- **事实标签:**是描述实体的客观事实,关注实体的属性特征,如一个部件是采购件还是非采购件,一名员工是男性还是女性等,标签来源于实体的属性,是客观和静态的;
- **规则标签:**是对数据加工处理后的标签,是属性与度量结合的统计结果,如货物是否是超重货物,产品是否是热销产品等,标签是通过属性结合一些判断规则生成的,是相对客观和静态的;
- **模型标签:**则是洞察业务价值导向的不同特征,是对于实体的评估和预测,如消费者的换机消费潜力是旺盛、普通还是低等,标签是通过属性结合算法生成的,是主观和动态的。
标签管理分为标签体系建设和打标签。
标签体系建设
选定目标对象,根据业务需求确定标签所打的业务对象,业务对象范围参考公司发布的信息架构中的业务对象。
根据标签的复杂程度进行标签层级设计。
进行详细的标签和标签值设计,包括标签定义、适用范围、标签的生成逻辑等:
- 事实标签应与业务对象中的属性和属性值保持一致,不允许新增和修改;
- 规则标签按照业务部门的规则进行相关设计;
- 模型标签根据算法模型生成。
- 打标签 (1)打标签数据存储结构 打标签是建立标签值与实例数据的关系,可以对一个业务对象、一个逻辑数据实体、一个物理表或一条记录打标签。为了方便从“用户”视角查找、关联、消费标签,可增加用户表,将标签归属到该“用户”下,这里的“用户”是泛指,可以是具体的人,也可以是一个组织、一个部门、一个项目等。
(2)打标签的实现方法
- 事实标签:根据标签值和属性允许值的关系由系统自动打标签。
- 规则标签:设计打标签逻辑由系统自动打标签。
- 模型标签:设计打标签算法模型由系统自动打标签
# 指标设计
指标是衡量目标总体特征的统计数值,是能表征企业某一业务活动中业务状况的数值指示器。指标一般由指标名称和指标数值两部分组成,指标名称及其含义体现了指标在质的规定性和量的规定性两个方面的特点;指标数值反映了指标在具体时间、地点、条件下的数量表现。
根据指标计算逻辑是否含有叠加公式,可以把指标分为原子指标和复合指标两种类型。
- 原子指标是指标数据通过添加口径/修饰词、维度卷积而成,口径/修饰词、维度均来源于指标数据中的属性。
- 复合指标由一个或多个原子指标叠加计算而成,其中维度、口径/修饰词均继承于原子指标,不能脱离原子指标维度和口径/修饰词的范围去产生新的维度和口径/修饰词。
指标和数据的关系如图5-18所示。
说明:
- 指标数据:承载原子指标的数据表,例如门店明细表,其中度量为门店数量,通过【门店编码】卷积;属性包括门店等级、门店状态、门店形象等级、组织等级等。
- 维度:从属性中选取组织、渠道、门店形象等级。
- 口径/修饰词:【门店状态】等于【有效】,【有无促销员】等于 【1】。
- 原子指标:由指标数据通过添加口径/修饰词、维度卷积而成,包括促销员覆盖门店数量、有效门店数量。
- 复合指标:由2个或2个以上指标叠加计算而成,包括【促销员门店覆盖率】=【促销员覆盖门店数量】÷【有效门店数量】。
如何按需求进行指标拆解,是将指标对应到数据资产并进行结构化管理,支持指标服务化与自助需求的关键。指标的拆解过程主要包括指标拆解需求澄清、指标拆解设计、指标数据与数据资产匹配3个阶段,如图5-19所示。
- 解读指标定义,识别指标:通过与指标定义的业务管理部门沟通(通常为指标解释部门的业务人员),从业务角度了解指标基本信息、所需统计维度、指标度量场景以及各场景下的计算逻辑和口径(包括剔除规则)、指标发布信息等。
- 基于指标叠加公式拆解指标:根据指标计算逻辑识别原子指标,明确原子指标中需要的口径/修饰词、维度信息,以及原子指标与复合指标间的支撑关系。
- 基于指标拆解结果,识别指标数据:识别原子指标的度量属性和支撑属性,并根据原子指标中的维度、口径修饰词匹配已发布业务对象的属性,形成指标数据。
- 数据匹配落地:补充指标、指标数据中的标准属性名称以及对应的落地物理表,支持用户自助实现指标计算,拉通指标设计和落地。
# 算法模型设计
算法是指训练、学习模型的具体计算方法,也就是如何求解全局最优解,并使得这个过程高效且准确,其本质上是求数学问题的最优化解,即算法是利用样本数据生成模型的方法。算法模型是根据业务需求,运用数学方法对数据进行建模,得到业务最优解,主要用于业务智能分析。 算法模型在数据分析流程中产生,算法模型管理框架包括建模、模型资产管理和模型消费。公司各领域已相继开发出大量基于算法模型的分析应用,通过对算法模型资产注册逐步打造公司级的算法模型地图。
算法模型的设计步骤主要有需求评估、数据准备、方案设计和建模与验证。 **(1)需求评估 ** 1)业务驱动的分析需求识别 如果要识别与业务运营优化相关的分析需求,就需要梳理业务需求的背景、现状与目标。 若由战略或变革提出可能的分析需求,则应进行战略目标解耦, 识别分析需求,了解业务现状与制定目标。 初步识别分析结果的应用场景。 2)数据驱动的分析需求识别
- 在集成的数据环境中进行数据挖掘,探索可能的分析应用。
- 识别分析需求和确认应用领域。
- 初步识别分析结果的应用场景。
3)价值与可行性评估
- 确定数据分析主题。
- 分析需求的业务价值评估,包括业务基线、分析主题的业务影响与可增进的效益。
- 分析前提与可行性,包括识别目前业务流程与可能的影响因素,探讨业务现状因素,并制定对应的分析解決方案,呈现对应解决方案可提升的效益,对方案所需资源和数据的可行性进行评估。
- 根据相关的历史数据,进行假设和分析,并明确业务范围。
**(2)数据准备 **
- 深入探索数据资产目录,识别与分析主题可能相关的数据。
- 提供数据源、数据标准、数据流等信息。
- 收集与整合原始数据,生成分析数据集。
- 根据分析需求进行数据筛选和质量分析。
**(3)方案设计 **
- 明确要分析的业务目标与相关假设。
- 定义数据集中的分析目标、样本与筛选条件。
- 设计所需变量、指标、可能的分析方法和产出。
- 规划分析的应用场景
(4)建模与验证 1)决定是否需要分析建模:根据技术复杂度、业务效益和资源评 估该分析需求是否需要分析建模。若需要分析建模且通过项目评审, 则应进行高阶分析;若不需要建模分析,则运用BI分析。 2)建模与验证:根据数据分析方案创建模型,对模型的参数和变 量进行调整,根据应用场景选择适用的模型,并与业务分析师确认模 型成效与应用,并进行优化,进行模型相关验证(如准确度和稳定度 评估)及效益评估。 3)试算分析:对数据分析方案中不需分析建模的场景和应用,根 据数据分析方案进行分析结果的计算,并选择合适的展示方式。 4)编写数据分析线下验证报告:
- 记录分析结果与发现。
- 根据洞察发现,建议业务应用场景。
- 建议模型监测方式。
5)决定是否需要IT开发: 根据模型验证成果(分析建模)、预估业务效益、IT开发所需的成本和资源来评估分析结果是否需要IT开 发。若需要,则通过评审后转入IT开发流程;若不需要,则进入业务应用并结束流程 6)模型线上验证:
- 设定线上验证范围与场景。
- 进行线上验证,制定模型监控机制(含监控频次和监控要素),生成分析模型线上验证报告。
- 进行业务试运行与推广。
7)转运营: 与数据分析模型所属领域的业务代表确认转正式运营计划,启动业务正式运营。
# 第六章:面向“自助消费”的数据服务建设
数据底座建设的目标是更好地支撑数据消费,在完成数据的汇聚、整合、联接之后,还需要在供应侧确保用户更便捷、更安全地获取数据。一方面业务人员希望尽可能快速地获取各种所需的数据,另一方面要确保数据获取过程中满足安全、合规的要求。同时,业务人员消费数据时,也希望能够有更加灵活的使用数据、分析数据的方式,业务人员希望消费数据的自主性更强,并且不能忍受过去冗长、呆板的报表呈现方式。 在数据供应侧和消费侧的双重推动下,华为公司进行了基于数据服务提供“自助消费”的实践,打造了从数据供应到消费的完整链条。
# 数据服务:实现数据自助、高效、复用
# 什么是数据服务?
参考IEEE规范,华为公司给出了数据服务的定义。数据服务是基于数据分发、发布的框架,将数据作为一种服务产品来提供,以满足客户的实时数据需求,它能复用并符合企业和工业标准,兼顾数据共享和安全。
数据服务给企业带来的价值
保障“数出一孔”,提升数据的一致性。通过服务获取数据的 方式类似于“阅后即焚”,大部分情况下数据并不会在使用方的系统 中落地,因此减少了数据“搬家”,而一旦数据的使用方并不拥有数 据,就减少了向下游二次传递所造成的数据不一致问题。
数据消费者不用关注技术细节,可以满足不同类型的数据服务 需求。对于数据消费者而言,不用再关心“我要的数据在哪里”,例 如用户不需要知道这些数据来自哪个系统、哪个数据库、哪个物理 表,只需要清楚自身的数据需求,就能找到对应的数据服务,进而获 取数据。
提升数据敏捷响应能力。数据服务一旦建设完成,并不需要按 使用者重复构建集成通道,而是通过“订阅”该数据服务快速获取数 据。
满足用户灵活多样的消费诉求。数据服务的提供者并不需要关 心用户怎么“消费”数据,避免了供应方持续开发却满足不了消费方 灵活多变的数据使用诉求的问题。
兼顾数据安全。所有数据服务的使用都可管理,数据供应方能 够准确、及时地了解“谁”使用了自己的数据,并且可以在数据服务 建设中落实各种安全措施,确保数据使用的合规。
2. 数据服务建设策略
数据服务建设过程中,首先应该在企业层面制定统一的数据服务建设策略,如图6-6所示。这个策略不能只关注数据服务的设计,而应该覆盖全生命周期的各个环节
- 要制定数据服务建设的方法,确保每个从事数据服务建设的人都明白数据一致性的要求,并且所提供的数据是可信的和清洁的。
- 要建立数据服务流程,以确保各个环节的有效协同,定义整个生命周期中每个角色的责任和有效输出。在企业中,应该有明确的部门负责数据服务流程的建设和看护,一方面要确保所制定的流程能够在实际工作中落地,另一方面随着技术的演进和企业业务环境的变化,持续对流程进行优化和完善。
- 要构建统一的数据服务能力中心,负责数据服务建设方法、规范、流程的落地,数据服务不同于传统集成方式,因此应该有统一的平台提供能力保障。
在数据服务建设中,应该为各个供应方树立统一的标准,并将这些标准以规范的形式进行固化,使所有数据服务建设都遵循同样的标准。
- 数据服务要满足可重用性、减少数据“搬家”。
数据服务在实际或者可预见的时间范围内会被多个需求方消费。数据服务面向场景进行消费时,无须重复落地。
- 服务提供方在规划服务时应明确服务的用户是谁,并针对用户的场景和需求进行服务设计,同时定义SLA服务水平承诺。服务要有业务Owner,业务Owner负责组织业务和IT一体化团队,主动进行服务规划和设计。服务规划和设计人员在规划和设计任何服务时,都应考虑到服务可能会被重用。服务规划需考虑价值,并优先对高价值的服务进行投资。服务消费方应对服务提出改进需求,促进服务能力的持续提升。
- 应用只能通过服务接口向其他应用开放其数据和功能,服务接口要稳定,应用间的通信也必须通过这些服务接口进行。需要说明的是,应用如果需要向其他应用开放其数据和功能,只能通过服务接口,服务接口应该易理解、易使用,达到服务市场准入标准。
- 所有的服务需在统一的服务管控平台中进行注册和发布。需要说明的是,华为公司的IT服务(HIS)负责提供服务管控平台的注册和发布功能,通过HIS可查询到发布的所有服务。
- 应根据不同场景选择合适的服务化架构粒度。
注:需要说明的是,服务化要采用合适的架构粒度,不是越“微”越好,也不是越“灵活”越好。
# 数据服务生命周期管理
完整的数据服务生命周期包括服务识别与定义、服务设计与实现、服务运营三个主要阶段。
服务识别与定义:业务与数据握手,识别服务的业务价值、准入条件与服务类型,减少数据服务的重复建设,提升数据服务的重用度。 服务设计与实现:业务、数据、IT三方协同,使设计、开发、测试与部署快速迭代以实现服务的敏捷交付,缩短数据服务的建设周期。 服务运营:通过统一数据服务中心及服务运营机制,保障服务SLA与持续优化。
- 数据服务的识别与定义
针对数据需求,规范数据服务识别过程,列出数据服务识别过程需要了解的关键内容,明确数据服务的实现方式和准入条件,提高数据服务的可复用性,减少重复建设,如图6-7所示。
1)分析数据服务需求:通过数据需求调研与需求交接,判断数据服务类型(面向系统或面向消费)、数据内容(指标/维度/范围/报表项)、数据源与时效性要求。 2)识别可重用性:结合数据需求分析,通过数据服务中心匹配已有的数据服务,判断以哪种方式(新建服务、直接复用、服务变更)满足业务需求。对于已有数据服务,必须使用服务化方式满足需求,减少数据“搬家”。 3)判断准入条件:判断服务设计条件是否已具备,包括数据Owner是否明确、元数据是否定义、业务元数据和技术元数据是否建立联接、数据是否已入湖等。 4)制定迭代计划:根据数据服务需求制定敏捷交付计划,快速满足数据服务需求。
在数据服务的识别和定义中,要特别注意数据服务的可重用性。所有的数据服务都是需求驱动产生的,如果没有需求方,那么这个数据服务就没有存在的价值。但是,重复建设也就成了数据服务建设中最大的风险之一。数据供应方很容易基于不同的数据消费方开发出不同的数据服务,而他们的数据需求往往是相似的,但数据供应方可能因为响应周期、客户(数据消费方)体验等压力,并没有花费精力去对来自各数据消费方的需求进行筛选和收敛,这就导致所建设的数据服务往往只是满足某个特定客户(数据消费方)的需求。如果数据服务不具备可重用性,那么它与传统的数据集成的方式相比,就并不具备优越性,有时甚至会导致更大的重复投资。
因此,以数据服务需求分析为输入,通过服务可重用性判断已有数据服务对需求的满足情况,给出满足服务需求的策略,并结合准入条件的关键问题判断服务需求是否能够被快速满足。
通常可以从数据服务提供形式、数据服务提供内容两方面来判断服务的可重用性,如图6-8所示。
在数据服务识别和定义阶段还应重点关注的另一个要素是数据资产的可服务性,通常用于数据服务准入条件的判断,即某个数据资产是否已经具备对外提供服务的条件。
在进行数据可服务性(准入条件)判断时,至少应充分考虑以下因素:
数据Owner是否明确?
数据是否有明确的安全密级定义?
元数据是否定义?
业务元数据和技术元数据是否建立联接?
面向数字化运营分析场景时,数据是否已入湖?
- 数据服务的设计与实现
在服务设计与实现阶段,要定义服务契约和数据契约,重点明确服务契约所涉及的服务责任主体、处理逻辑,并以数据契约规范服务的数据格式与数据的安全要求。
通过服务契约与数据契约,可以有效地管理在数据交互中可能存在的安全风险,数据供应方可以将一些安全要求通过契约实现。例如,对某些高密级控制属性进行屏蔽。同时,供应方能够通过契约了解哪些消费者获取了数据以及使用的数量和频率等,如图6-9所示。
**服务契约:**包括服务的基本信息(数据服务提供方、数据服务的类型)、能力要求(服务的时效性、服务的处理逻辑、服务的安全策略、服务的SLA要求)等。 **数据契约:**包括数据契约描述、输入和输出参数、业务数据资产编码、物理落地资产编码等。
数据服务设计中应强调数据服务的颗粒度,数据服务颗粒度的大小直接影响着服务的可重用性,细粒度的服务更容易被重用。但是,如果我们只考虑可重用性,将导致产生大量颗粒度很小的数据服务,这将对系统的整体性能带来严重的影响,因此必须在服务粒度设计上维护一种平衡。 数据服务颗粒度通常应考虑以下原则。
- 业务特性:将业务相近或相关、数据粒度相同的数据设计为一个数据服务。
- 消费特性:将高概率同时访问、时效性要求相同的数据设计为一个数据服务。
- 管理特性:综合考虑企业在数据安全管理策略方面的要求。
- 能力特性:将单一能力模型设计为一个服务。
基于上述原则,可以形成一些具体的用于指导实际执行的参考规范,如下所示。
- 同一种提供形式下,一个数据只能设计在一个数据服务中。
- 按主题(业务对象)将相同维度的数据设计为一个数据服务。如果同一个主题下的指标数量过多,则需要考虑按“高概率同时使用、业务关联度紧密”的原则再进行划分。
- 将同一个逻辑实体的数据设计为一个数据服务。
- 将单一功能的算法、应用模型设计为一个服务。
数据服务研发流程:
- 服务需求接收与管理:明确数据管理部门、IT部门、业务代表的具体职责,通过三方共同协作,解决需求理解不透彻导致开发过程反复的问题。
- 构建自助式开发平台:通过简单配置的方式实现数据服务的开发,降低数据服务的开发门槛,缩短数据服务的开发周期。
- 代码自动审查:通过自动化手段校验服务开发代码的性能及不规范等问题,阻断代码提交,直到问题解决,做到事前规避。
- 数据自动验证:构建数据自动测试能力,实现数据服务的数据量差异、字段差异、数据准确性差异的验证。
- 功能自动测试:构建功能自动化测试能力,自动对数据服务SLA、查询出入参数进行自动检查,构建容错机制。
- 服务部署:数据服务不涉及对数据的修改,采用实时部署的方式可缩短数据服务的实现周期,提升数据服务的敏捷响应能力。
数据服务的变更与下架 随着业务需求的不断变化,数据服务需要随之进行调整,因此在建设中也应做好数据服务的变更管理和下架管理。 (1)数据服务变更管理 可参考以下因素: 服务变更内容:包括数据服务的时效性、出入参数、服务处理逻辑、数据安全策略等。 服务变更影响:业务连续性影响、变更成本影响等。 (2)数据服务的下架管理 因为数据服务是基于用户需求产生的,而业务需求是动态变化的,因此需要持续将调用量很少甚至为零的数据服务从市场中下架, 确保数据消费者总能拿到“最好的”数据服务。通常,数据服务的下架有两种情况:
- **主动下架:**一种是由服务消费方主动提出的数据服务下架申请,可以称为“主动下架”;
- **被动下架:**另一种是通过运营度量策略判断需要下架的数据服务(例如,三个月内无服务调用、重复的数据服务等),可以称为“被动下架”。
#
# 数据服务分类与建设规范
数据服务是为了更好地满足用户的数据消费需求而产生的,因此数据消费方的差异是数据服务分类的最关键因素。具体包括两大类:**数据集服务和数据API服务。 ** 3. 数据集服务 (1)数据集服务定义 比较常见的数据消费者有两类:一类是真实的“人”,一类是“IT系统”。企业越来越强调各业务部门的自我运营,因此产生了大量自助分析消费者,这类消费者就是业务人员,甚至可能是管理者,他们通过各种数据分析工具,直接使用、消费数据。这种情况下,消费者是“访问”某个相对完整的“数据集”,这种消费方式称之为“数据集服务”。 数据集服务最主要的特征是由服务提供方提供相对完整的数据集合,消费方“访问”数据集合,并自行决定接下来的处理逻辑。 数据服务提供方被动地公开数据以供数据消费方检索。数据服务提供方并不定义数据处理逻辑,但数据和数据处理逻辑仍然由其控制。数据服务的生命周期即数据访问授权的有效期。
(2)数据集服务建设规范 数据集服务主要面向自助分析场景提供相对完整的数据集合,因此所提供的数据主要来自数据底座,包括“数据湖”和“主题联接”。 当所提供的数据来自数据湖时,建设规范如图6-12所示。
规范如下:
1)允许将数据湖的同一个业务对象内的一个或多个资产封装为数据服务。
2)允许将数据湖内单个资产及其关联主数据合并封装为数据服务。
3)不允许将数据湖中跨业务对象的多个资产合并封装为一个数据服务。
数据API服务定义
数据服务的另外一类消费者是“IT系统”,即面向某个IT系统提供数据事件驱动的“响应”,这种服务的封装方式与前面所提到的数据集不同,称为“数据API服务”。
(1)数据API服务特征
服务提供方“响应”消费方的服务请求,提供执行结果。具体特征如下:
- 数据服务提供方基于随机的数据事件主动地传送数据。
- 数据服务提供方会基于事件定义数据处理逻辑,由消费方提前订阅并随机触发。
- 服务的生命周期跟着事件走,事件关闭了,服务就终止了。
(2)数据API服务VS数据集成服务
数据API服务与传统系统集成相比有非常明显的优势,如图6-15所示。
供应/消费数据服务:应用组件间传递的是基于数据服务契约的消息,即传递对数据进行逻辑操作的结果。
高聚合:订单服务使业务逻辑变得更加集中,易于数据同源管控。
松耦合:业务逻辑的变化对服务消费方没有直接影响。
# 打造数据供应的“三个1”
数据服务改变了传统的数据集成方式,所有数据都通过服务对外提供,用户不再直接集成数据,而是通过服务获取。因此,数据服务应该拉动数据供应链条的各个节点,以方便用户能准确地获取数据为重要目标。 数据供应到消费的完整链条如图6-16所示,当用户所需数据处于链条上的不同节点时,提供服务的周期是有差异的。
下图是数据供应链(资料参考:埃森哲数据供应链方法论)
华为公司为确保整个数据供应链条的高效协同,制订了“三个1”作为拉通各个供应环节的整体目标,确保每个环节能够形成合力并对准最终用户,如图6-17所示。
“三个1”是数据供应的整体目标,起点是需求方提出数据需求,终点为需求方拿到数据并可立即进行消费,具体衡量标准包括如下内容。
- 1天:对于已发布数据服务的场景,从需求提出到消费者通过服务获取数据,在1天内完成。
- 1周:对于已进底座但无数据服务的场景,从需求提出到数据服务设计落地、消费者通过服务获取数据,在1周内完成。
- 1月:对于已结构化但未进底座的场景,从需求提出到汇聚入湖、数据主题联接、数据服务设计落地、消费者通过服务获取数据,在1个月内完成。
数据供应的“三个1”并不是单纯的度量指标,而是一整套瞄准最终数据消费体验的能力体系以及确保数据供应能力的管理机制,还包括组织职责的明确、流程规范的制定与落实、IT平台的建设和管理,如图6-18所示。
(1)组织职责的明确
- 构建专业的评审及仲裁组织。
- 承接各细分工作内容的角色职责。
(2)流程规范的制定与落实
- 统一的工作细分流程。
- 配合工作流程制定相应的管理规范,以指导开展工作。
- 配合IT平台制定相应的管理规范,以指导开展工作。
(3)IT平台的建设
- 度量、评价数据底座运营的效率和效益的具体指标。
- 支撑组织职责、流程规范、度量指标落地的IT工具。
(4)面向需求方的效率承诺度量
对所有供应团队形成明确、清晰的工作要求。在华为的内部实践中,会以图6-19为例进行明确的承诺,并在公司层面进行公示,请所有数据需求方共同对供应能力进行监督。
# 构建以用户体验为核心的数据地图
在解决数据的“可供应性”之后,企业应该帮助业务更便捷、更准确地找到它们所需要的数据,这就需要打造一个能够满足用户体验的“数据地图”。
# 数据地图的核心价值
数据供应者与消费者之间往往存在一种矛盾:供应者做了大量的数据治理工作、提供了大量的数据,但数据消费者却仍然不满意,他们始终认为在使用数据之前存在两个重大困难。 1)找数难 企业的数据分散存储在上千个数据库、上百万张物理表中,已纳入架构、经过质量、安全有效管理的数据资产也会超过上万个,并且还在持续增长中。例如,用户需要从发货数据里对设备保修和维保进行区分,以便为判断哪类设备已过保(无法继续服务)提供准确依据,但生成和关联的交易系统有几十个,用户不知道应该从哪里获取这类数据,也不清楚获取的数据是否正确。 2)读不懂 企业往往会面对数据库物理层和业务层脱离的现状,数据的最终消费用户无法直接读懂物理层数据,无法确认数据是否能满足需求,只能寻求IT人员支持,经过大量转换和人工校验,才最终确认可消费的数据,而熟悉物理层结构的IT人员,并不是数据的最终消费者。例如,当需要盘点研发内部要货情况的时候,就需要从供应链系统获取研发内部的要货数据,但业务用户不了解该系统复杂的数据存储结构(涉及超过40个表、1000余个字段),也不清楚每个字段名称下所包含的业务的含义和规则。
企业在经营和运营过程中产生了大量数据,但只有让用户“找得到”“读得懂”,能够准确地搜索、便捷地订阅这些数据,数据才能真正发挥价值。
数据地图(DMAP)是华为公司面向数据的最终消费用户针对数据“找得到”“读得懂”的需求而设计的,基于元数据应用,以数据搜索为核心,通过可视化方式,综合反映有关数据的来源、数量、质量、分布、标准、流向、关联关系,让用户高效率地找到数据,读懂数据,支撑数据消费。
数据地图作为数据治理成果的集散地,需要提供多种数据,满足多类用户、多样场景的数据消费需求,所以华为公司结合实际业务制定了如图6-20所示的数据地图框架。
数据地图为四类关键用户群体提供服务。
1)业务分析师
业务分析师是企业最大的数据消费群体,具有良好的业务背景,有些数据分析师本身就是业务人员,了解业务需求实质,理解业务含义,与利益相关者有良好的沟通。通过对数据的识别,借助数据分析工具,生成可供阅读的图表或者仪表板,使用分析结果识别问题,支撑决策。对数据可信度、业务含义、数据定位有强烈诉求。
2)数据科学家
数据科学家是指能采用科学方法、运用数据挖掘工具对复杂异构的数字、符号、文字、网址、音频或视频等信息进行数字化重现与认识,并能进行新的数据洞察的工程师或专家。对业务含义、数据关系有强烈诉求。
3)数据管家
公司数据管理体系的专业人员,负责协助数据Owner对数据信息架构进行管理,包括定义信息架构中的责任主体、密级/分类,为数据安全管理提供重要输入。通过信息架构设计,统一业务语言,明确管理责任,设定数据质量标准,拉通跨领域信息流,支撑运营和决策。对数据质量、信息架构、数据关系有强烈诉求。
4)IT开发人员
主要为企业的数据仓库开发人员,通过对物理表进行定位、识别和ETL,创建满足业务分析师或者应用平台所需要的模型或维表。对数据定位、数据关系有强烈诉求。
# 数据地图的关键能力
数据地图重点提供数据搜索、排序推荐、数据样例、资产/用户画像等关键能力。
(1)数据搜索
数据搜索可以提高用户的搜索准确度,使用户能快速理解搜索出来的数据内容,通过组合搜索、筛选分类,数据标签等持续提升用户体验。
通过界面封装搜索引擎,只向用户暴露单一的搜索栏,通过搜索栏的单一或者组合搜索,发现数据。
(2)排序推荐
排序推荐能让用户更容易地找到高质量、可消费的数据资产,缩小搜索结果集范围,减少数据识别和判断的时间,最终目标是让用户实现“所搜即所得”的效果。
对应搜索结果的推荐排序,主要在功能侧提供了两类服务,以便用户通过被动式和主动式的办法管理搜索结果。
1)被动响应推荐排序
用户在前端无须操作,通过推荐排序逻辑对结果集进行处理,完全基于数据管理分类、用户行为分析等输入。优点是提升了用户的体验,无须操作即可以大概率定位到自己需要的数据资产;缺点是与用户之间缺乏交互,准确度因人而异,需要积累大量管理分类和用户行为的输入作为参考。
2)主动管理推荐排序
通过数据管理侧的分类和通用性的标签进行分类管理,用户在使用过程中可以通过分类标签对搜索结果集进行再次过滤和定位。
优点是与用户有一定的交互,让用户在使用的时候可以主动管理;
缺点是基于管理侧和通用性收敛上来的标签难以满足个性化的需求。
(3)数据样例
“读懂数据”是用户进行数据消费的基础,用户只有读懂数据,才可以准确判断数据的来源、质量、可信度等关键信息。除了可以通过提供数据资产的各类元数据信息来辅助用户读懂数据外,生产环境的实时数据对用户而言更有参考价值,因为生产环境直接采集的数据的内容,与用户可消费的数据内容是一致的。
用户在搜索结果中点击样例数据,能够自动读取数据库名称,并根据对象编号,查找数据库记录表,实现生产环境数据的样例查看,如图6-24所示。
(4)资产/用户画像
资产/用户画像通过标签化的手段来对资产和用户进行清晰地描绘,有助于数据搜索和推荐排序的不断优化,贴近用户真实需求。
基于用户画像、经验模型库和资产画像理解文本语义,可以提高搜索准确性,解决资产查不到、难挑选等问题,并通过业务运营不断优化资产搜索能力,如图6-25所示。
# 人人都是分析师
数据服务解决了“可供应性”,数据地图解决了“可搜索/可获取性”,当消费方获取数据后,提供“可分析”能力,帮助数据消费者结合自身需要获取想要的分析结果。
# 从“保姆”模式到“服务+自助”模式 (目前现状)
过去,各业务部门的分析诉求往往通过公司总部“保姆式”开发模式来满足,即业务部门只负责提出需求,所有的方案从设计到开发实现,统一由总部完成。这也是传统意义上的数据仓库的标准报告生成方式,强依赖于IT人员,贯穿整个数据分析过程,从获取数据、建模到设计报告,均需要IT人员的支撑,如图6-26所示。
这种模式存在多个问题,如下所示。
- 1)总部开发周期长,通常从需求提出到开发实现,需要多轮次需求解析和澄清。由于总部并不了解业务部门的实际业务,即使在方案设计阶段也可能需要再次对需求进行确认。IT开发完成后还需要进行严格的测试验证和部署,因此整个周期通常最短也需要30天左右。
- 2)无法满足灵活多变的业务要求。业务运营和业务作业不同,作业模式相对稳定,当大的场景不发生变化时,作业模式是基本稳定的。而业务运营是按需开展的,往往是从问题出发,在业务开展过程中,可能出现的问题、风险是经常变化的,很可能任何一个内外部因素的变化就会带来新的业务运营关注点,而总部开发模式不可能实时满足所有区域的要求。
在这种背景下,提出了“服务+自助”模式(如图6-27所示),即公司总部只提供统一的数据服务和分析能力组件服务,各业务部门可以根据业务需要进行灵活的数据分析消费,数据分析的方案和结果由业务自己完成。
这一模式有如下价值。
- 数据分析消费周期极大缩短。当各业务部门需要进行数据分析消费时,可以直接调用已建好的数据服务进行自助分析,整个报表开发周期缩短为1~2天。
- 发挥业务运营主观能动性。俗话说“高手在民间”,各业务部门是业务作业的责任主体,同时也对业务及经营结果负责,因此各业务部门是业务运营的第一责任人,同时也是最了解业务自身现状与问题的。通过自助模式,可以更有效地发挥各业务部门的主观能动性,真正将数据分析消费与业务运营改进相结合。
- 减少“烟囱式系统”的重复建设。各业务部门在保证数据分析消费灵活性的同时,并不需要重复构建支撑消费的数据基础,所有公共的数据汇聚、数据联接都统一建设,在遵从隐私保护和安全防护要求的前提下以数据服务的形式充分共享。
# 打造业务自助分析的关键能力
华为公司将自助分析作为一种公共能力,在企业层面进行了统一构建。
一方面,面向不同的消费用户提供了差异性的能力和工具支撑;
另一方面,引入了“租户”概念,不同类型的用户可以在一定范围内分析数据、共享数据结果。
4. 针对三类角色提供的差异性服务
面向三类角色的分析架构能力如图6-28所示。
(1)面向业务分析师,提供自助分析能力,业务人员通过“拖、拉、拽”即可快速产生分析报告
- 基于多租户环境,提供数据资产订阅、报表作品搜索、服务订阅等能力。
- 实现从数据查询到数据拖拽式分析的端到端的一站式自助作业,增强数据即席查询和数据建模等功能。
- 提供数据搜索、数据获取、自助分析、数据消费等一站式自助分析服务,缩短报表开发周期。
- 支持租户管理、工具集管理、日志管理功能,集成数据底座权限模型,提供稳定的分析环境。
目前仲谋已实现
(2)面向数据科学家,提供高效的数据接入能力和常用的数据分析组件,快速搭建数据探索和分析环境
- 集成数据可视化、数据建模能力,降低数据分析门槛,提高平台的易用性。
- 识别公共诉求,提供R Studio、Zeppelin等工具集,增强NLP基础服务、人工智能等分析装备对于机会点的支撑能力,支撑各种大数据分析应用场景。
- 提供源系统到分析平台的数据实时同步功能。
- 为数据科学家提供数据目录导航入口。
- 提供数据分析环境,支持权限申请和计算资源的分配,缩短建模周期。
(3)面向IT开发人员,提供云端数据开发、计算、分析、应用套件,支撑海量数据的分析与可视化,实现组件重用
- 整合数据接入、数据计算、数据挖掘、数据展现等能力,提供高效、安全的数据集成、数据开发、报告开发、数据管理等服务,减少重复建设,实现组件重用。
- 整合第三方资源,依托HIC能力通道,提供自助、按需、在线的基础数据服务,包括分布式处理、实时处理、内存计算等。
- 以租户为核心的自助分析关键能力
(1)多租户管理能力
租户是指把数据、分析工具、计算资源有机组合的工作环境,用户可以在租户内自助完成数据搜索、数据加工、在线分析、报表共享等工作。
多租户技术也称多重租赁技术,是一种软件架构技术。多租户技术可以实现多个租户之间共享系统实例,同时也可以实现租户的系统实例的个性化定制。通过使用多租户技术可以保证系统共性的部分被共享,个性的部分被单独隔离。例如,按国家设定不同租户,这样在本租户内共享该国的经营分析结果,共同进行异常分析和经营改进;同时,该租户数据对其他国家屏蔽,避免了数据扩散等安全风险。
为了合理分配软硬件资源,满足各领域在线、自助、个性化的数据分析诉求,促进数据的安全共享和价值变现,明确了租户申请、租户命名、数据准备、数据同步、数据加工、数据申请、权限管理、安全与隐私、运维与运营等方面的要求,旨在通过正确的引导,确保数据消费的便捷、高效与安全合规,支持公司的数字化转型。
在多租户建设中,相对于技术层面的解决方案,租户管理的职责需要在企业里建立共识,将共识以标准规范的形式固化下来。租户自助分析能力架构如图6-29所示。
租户的4个关键角色如下所示。
- 租户Owner:租户管理的第一责任人,由公司正式任命的管理者或者变革项目经理担任,是租户内数据消费的总责任人。
- 租户管理员:由租户Owner指定并授权,是对租户内资产、用户、报告的日常维护、配置、授权承担具体管理职责的人员。
- 查看者:申请并被允许加入租户,只对租户内的报告有查看权限的租户用户。
- 分析师:申请并被允许加入租户,对数据资产可执行申请数据入租户、申请租户授权、通过分析工具分析数据、制作报告、查看报告、分享报告等操作的租户用户。
(2)数据加工能力
在同一个租户空间内,对数据进行关联、过滤等操作,满足最终分析报告的数据需求。
用户可将多个数据进行关联,构建自己的宽表,可对宽表进行数据过滤,选择合适的字段以及增加计算字段,如图6-30所示。
(3)数据分析能力
基于消费场景,利用租户内授权的数据资产,通过分析工具对数据进行分析并生成可视化报告。
用户可以选择即席查询自行配置各类条件后的结果数据,再基于这些数据直接链接到不同的分析工具,进行进一步的数据分析。
1)即席查询
提供通过筛选条件展示结果数据的能力
- 提供生产环境的实时数据内容,有助于用户通过筛选后的结果数据判断能否满足最终的分析需求。
- 分析结果支持以文件服务器的方式下载,满足本地化处理的需求,同时避免数据被过度共享。
2)可视分析(也就是目前仲谋的自助分析模块)
查看已授权并加工好的数据的详情,进入可视化分析阶段,充分利用企业现有的分析工具,或打通主流的商业分析工具,减少开发成本,降低学习成本,如图6-32所示。
(4)自助分享能力
基于自助分享能力,可以对分析报告进行密级设定和权限管理,向租户个人或者群体分享报告,不仅可以分享给本租户内指定的用户,而且可以进行跨租户分享。这样一方面可以扩大报告的使用范围,降低报告重复建设过程中的成本,另一方面也有助于解决分析结果不一致的问题。
# 从结果管理到过程管理,从能“看”到能“管”
数据分析和消费本身只是一种手段而不是目标,数据消费要真正产生价值,必须与业务密切结合。业务数字化运营是华为公司数据消费的最重要场景之一。
# 数据赋能业务运营
业务运营的本质是围绕业务战略“RUN”流程。运营过程中业务沿着流程周而复始地运转,在作业过程中识别并解决问题,应基于PDCA循环(戴明环)进行有质量的运营。而数字化运营旨在利用数字化技术获取、管理和分析数据,从而为企业的战略决策与业务运营提供可量化的、科学的支撑。
数字化运营归根结底是运营,旨在推动运营效率与能力的提升,所以它体现在具体的业务中,而不是一块新的业务,更多是在现有标准流程的基础上改进和完善。数字化运营的核心是数据,以及基于数据的精细化管理和科学决策分析。企业业务数字化运营模式如图6-33所示。
业务数字化运营的目的不应只有“察(数字化看板)”,还应该进一步实现“打(业务决策与执行)”,即支撑业务运营作战模式转变,提升运营效率。业务数字化运营要发挥对业务的指挥作用,要能够让上下同步感知业务运行态势,通过分工协作解决业务运作中的问题,提升运作效率。
业务数字化运营要同时具备多个能力,包括战略落地、业务可视化、预测预警、作业指挥、跨领域问题解决和联动指挥等。
基于数据底座的数字化运营模式(如图6-34所示)支撑着华为公司大量相对独立的业务作战单元和业务部门,基于自身业务进行持续运营,提升业务效率和业务盈利水平。同时,也解决了过去普遍存在的“线下会议多、手工报告多”等问题,避免让大量作战人员将精力消耗在事务性工作中。
(1)满足业务运营中数据实时可视化的需求
过去,数据的展现时间与数据在业务中的真实发生时间往往有相当长的时间间隔。某个具体的作业数据进入系统后,要经过复杂的集成和长时间的等待才能体现在报表中,业务部门无法第一时间掌握真实的工作进度,也就无法在第一时间进行业务管理。例如,分包商进行站点作业时,相关数据往往要第二天或更晚才能体现在监控报告中,等到平台能根据这些信息采取行动时,也无法在作业时发挥作用。假如,站点出现物料问题或安装质量问题,可能会导致分包商重复上站,额外增加了成本。通过实时数据入湖和联接方案,业务可以 第一时间获取作业监控信息,从而根据实际情况进行灵活调整,一次性把工作做对。基于实时数据的可视化能力,还能够支持业务在线会议,通过数据底座提供的服务将数据层层下钻,从过去的纸面报告或PPT材料变成可视化的业务场景。
(2)满足业务运营中及时诊断预警的需求
通过数字化手段,在获取业务运营数据的同时,可以根据实际场景差异,灵活配置各种规则类数据,通过分析平台的规则引擎,帮助业务提前感知业务问题、自动预警潜在风险,从而有效支撑业务的快速响应。例如,根据每个国家的供应能力预设不同的预警规则,当供应出现瓶颈或问题时,会自动触发预设的预警规则,从而对下一步的设备交付环节进行风险预警,提醒业务部门及时对交付计划进行调整,避免影响客户界面的交付承诺。
(3)满足业务运营中复杂智能决策的需求
通过数据分析模型对数据底座中的海量数据进行挖掘,智能分析业务问题的本质,洞察趋势并推荐方案,从而支持业务的客观、精准决策。例如,基于数据分析的统计预测构建不同的计划方法模型,支撑供应网络多级库存优化、多场景计划决策,应用数字化技术提高计划决策的效率和质量。
# 数据消费典型场景实践
为了更好地实现数据消费,华为公司通过5个步骤来管理从需求到自助分析的过程,包括业务需求提出、数据解析、数据搜索和获取、数据服务提供、自助报告设计和展示,如图6-35所示。
当业务部门产生数据消费需求后,可以方便地通过数据地图进行搜索。如果已经有数据服务可以支撑,那么就能够快速地订阅服务,从而直接进行数据分析消费;如果暂时没有数据服务可用,那么数据专业人员也只需要提供相应的数据服务,而不需要为业务部门开发定制分析报告,这样就实现了数据供应和数据消费的高效协同。
实例1:经营管理实践 过去,经营管理多为事后管理,通过每月下任务令进行业务改进,整个问题从发现到解决周期长,且存在大量人工动作,耗散大量业务精力。
- 数据滞后,经营过程非实时可视,主要为事后管理。
- 按月做经营分析,从经营数据产生到下发任务令需0.5~1个月。
- 缺少集成管理平台,手工做经营分析,线下管理任务令。
传统经营管理过程如图6-36所示。
通过数字化运营实现事中监控和及时改进,达到经营过程可视化、报告在线分析、实时社交讨论、及时经营改进的目的。
- 数据在线转变为事中监控,随时可拉通审视规模、盈利、效率全经营指标。
- 经营管理模式改变,实时分析经营风险,会上聚焦重大风险决策,高效运作。
- 在统一平台进行监控、预警、协调、任务管理,从战略、执行到经营过程和结果实现闭环。
基于数字化运营的经营管理过程如图6-37所示。
**实例2:风险管理实践 **
过去,业务风险管理主要依赖事后审查,业务发生一段时间后再通过CT(Compliance Test,流程遵从性测试)、SACA(Semi-Annual Control Assessment,半年度控制评估)、稽核、审计等方式进行事后管理,业务根据审查要求提供相应“证据”。每一次核查都要先定位系统,先由核查人员自己在系统的海量数据中找问题,再约谈相关业务人员确定问题及其原因,这个过程中又存在多轮PK,然后再由责任人负责改进,最终还要由核查人员检查实际落实情况。整个过程不仅消耗大量精力,而且业务往往是被动改进,并不是主动进化。
- 落实主要依靠流程规则,细则多,执行难。
- 海量线下数据整理和分析,定位内控问题原因难。
- 流程控制评估、遵从性评估、主动性审视、稽核、审计多方事后清理。
传统风险管理方式如图6-38所示。
通过数字化运营,可以实现业务实时自检,风险实时在线审视和预警,风险任务快速关闭,不需要完全依赖事后核查,而是业务人员主动遵从。用数据规则替代人工的分析、检查和回溯,大大提高了风险管理的实时性,从事后管理变为事中管理,部分业务部门的量化风险降低超过50%。
- 在业务风险控制点打探针,及时发现问题。
- 实现风险量化可视,实时预警。
- 实时在线下达风险点的改进任务令,及时改善。
基于数字化运营的风险管理方式如图6-39所示。
# 华为数据驱动数字化运营的历程和经验
华为数字化运营的不同阶段
数字化运营本身是一种实践,每个企业数字化运营的道路都不相同,华为公司通过数据赋能业务运营是从2016年开始的,中间经历了不同阶段,也走过一些弯路,如图6-40所示。
(1)“从行走到公交”阶段
大部分情况下采取“机关建、业务部门用”的方式。虽然通过数据治理达到了“数据清洁”的目标,也能够实现一定程度的经营和运营数据的可视化,但仍存在机关开发永远满足不了业务部门需求的问题,尤其是不同国家的业务场景各有差异,机关开发无法满足根据业务场景进行灵活运营的目的,机关开发往往疲于奔命,而业务部门满意度仍然不高。
(2)“从公交到自驾”阶段
由于自研和引进了业界先进的分析工具,各区域开始按需以自助的形式生成各种分析报表。在满足各国家、各业务部门特定需求和灵活变化方面,收到了一些效果。但在该阶段,数据从供应到消费的整个过程处于“无序”状态,业务自助分析“野蛮生长”,大量数据是以离线手工获取方式为主,数据的完整性和可靠性存在很大问题,也存在大量的数据安全隐患。
(3)“从无序到有序”阶段
通过数据底座建设实现生态共建、平台共享的效果。随着数据服务的大量建设,逐步覆盖了80%的场景,使得各种数据消费的效率更高、安全性更好,减少了大量重复建设。通过前台统一入口,大大提升了运营分析的性能体验。另外,还打造了从“业务部门回到机关”通道,对各个国家的优秀典型场景进行归纳,业务部门的优秀实践反向纳入数据底座形成公共数据服务和报表卡片,各个国家可以通过自助分析平台实现对优秀实践的快速复制。
(4)“人工到智能”阶段
在原有的数据实时可视化的基础上,逐步增加动态及时预警能力、智能分析和方案推荐能力、任务自动执行能力,支撑业务数字化运营达到更高层面。业务数字化运营逐步从单一报表可视化,扩展到业务监控、预测、预警、协调、调度、决策、指挥等7个场景的持续打造,最终实现企业数字化运营“平时值班、战时指挥、察打一体”目标,如图6-41所示。
做好数字化运营的“三个要点、两个基础”
业务数字化运营不是某个能力的单独应用,需要多种能力的联合推动。在初期孵化过程中,尤其应该关注企业数字化运营的“三个要点、两个基础”。
“三个要点”是指数字化运营中的“发育、激励、分享”。在面向各业务部门的数字化运营能力的“发育”过程中,要做好自助分析能力赋能,识别关键核心人员并通过培训与实战的方式帮助他们掌握自助分析的基本能力,同时机关专家要做好现场支持,帮助各业务分析人员“上马”。在数字化运营实践中要充分激励原创,采取各种方式保护原创,同时鼓励各业务部门充分共享优秀实践。同时,机关要发挥归纳和总结作用,从各地优秀实践中识别真正具有共性的典型场景和典型数据联接模型,不仅可以使自助分析性能更好,还可以推动优秀实践在各个业务部门快速复制,达到“从1到N”的效果。
“两个基础”是指数字化运营中的“数据服务和IT平台”。数据服务是整个数字化消费的关键,也是业务数字化运营的重要基础。IT平台包括分析平台和数据分析结果呈现前台,其中分析平台承载企业的公共分析能力建设,并重点面向业务分析师提供自助分析能力;数据分析结果呈现前台承载了公共场景的市场能力,支撑典型场景的快速分享。
企业开展数字化运营的关键要素,如下图:
对于非数字原生企业来说,打造企业级的全面的数据服务和面向业务的自助消费,将会是一个长期的过程,中间会遇到大量的困难和挑战。一方面,面临着大量遗留资产和平台的改造;另一方面,面临着诸多技术上的不确定因素。数据服务本身的能力还需要不断改进,在稳定性方面与传统方式还存在一定的差距;整个企业的认知还需要不断加强,很多业务部门还没有完全适应这种模式的转变;人员能力还需要不断提升,很多“业务专家”还不具备“业务数据分析专家”的能力。
但是,未来的方向是确定的,企业数字化转型的决心是确定的,尽管有这样或那样的困难,但数据服务是数据成为业务的“可消费产品”的最关键要素之一,我们应该坚持数据服务化的道路,充分学习和利用各种先进实践和先进技术,不断充实和加强自身能力,让数据服务发挥更大的价值。
# 7-9章:数据治理的三项关键能力
# 第七章:打造“数字孪生”的数据全量感知能力
一个或一组特定装置的数字复制品,能够抽象表达真实装置并可以此为基础进行真实条件或模拟条件下的测试。该概念源于对装置的信息和数据进行更清晰的表达的期望,希望能够将所有信息放在一起进行更高层次的分析。数字孪生(Digital Twin,DT)即由此概念衍生而出并沿用至今。
# “全量、无接触”的数据感知能力框架
# 数据感知能力的需求起源:数字孪生
业务数 字化整体方案如图7-1所示。
# 数据感知能力架构
随着企业业务数字化转型的推进,非数字原生企业对数据的感知 和获取提出了新的要求和挑战,原有信息化平台的数据输出和人工录 入能力已经远远满足不了企业内部组织在数字化下的运作需求。企业 需要构建数据感知能力,采用现代化手段采集和获取数据,减少人工 录入。数据感知能力架构如图7-2所示。
数据感知可分为“硬感知”和“软感知”,面向不同场景。“硬 感知”主要利用设备或装置进行数据的收集,收集对象为物理世界中 的物理实体,或者是以物理实体为载体的信息、事件、流程等。而 “软感知”使用软件或者各种技术进行数据收集,收集的对象存在于 数字世界,通常不依赖物理设备进行收集。如图7-3所示。
感知产生的数据还是孤立的物理对象的镜像,需要在企业这一复 杂对象内部与其他数据资产一起,与流程、运营和指标之间建立关 系,纳入企业的信息架构进行管理,才能真正打通从数据感知、生成 到消费的链路。 当然,这一切的最终目的是生成企业级的感知数据,形成数字孪 生的基础,满足企业利用人工智能、机器学习对数字孪生对象进行仿 真分析、控制并优化制定战略目标的需求,帮助企业动态把握组织所 处的环境,帮助管理者实时了解企业运营情况,为企业数字化变革提 供建议,通过这些数字化的手段持续变革创新、获取业务价值。
# 基于物理世界的“硬感知”能力
数据采集方式主要经历了人工采集和自动采集两个阶段。自动采 集技术仍在发展中,不同的应用领域所使用的具体技术手段也不同。 基于物理世界的“硬感知”依靠的就是数据采集,是将物理对象镜像 到数字世界中的主要通道,是构建数据感知的关键,是实现人工智能 的基础。
# “硬感知”能力的分类
基于当前的技术水平和应用场景,我们将“硬感知”分为9类,每 一类感知方式都有自身的特点和应用场景,如图7-4所示。
- 条形码与二维码 条形码或者条码是将宽度不等的多个黑条和空白,按一定的编码规则排列,用以表达一组信息的图形标识符,通常一维条形码所能表示的字符集不过10个数字、26个英文字母及一些特殊字符,条码字符集所能表示的字符个数最多为128个ASCII字符,信息量非常有限。二维码是用某种特定的几何图形按一定规律在平面上分布的黑白相间的图形,用来记录数据符号信息。二维码拥有庞大的信息携带量,能够把使用一维条码时存储于后台数据库中的信息包含在条码中,可以直接阅读条码得到相应的信息,并且二维码还有错误修正及防伪功能,增加了数据的安全性。
- 磁卡 磁卡是一种卡片状的磁性记录介质,利用磁性载体记录字符与数字信息,用来保存身份信息。视使用基材的不同,可分为PET卡、PVC卡和纸卡三种;视磁层构造的不同,又可分为磁条卡和全涂磁卡两种。磁卡的优点是成本低,这是它容易推广的原因,但缺点也比较明显,例如卡的保密性和安全性较差,使用磁卡的应用系统需要有可靠的计算机系统和中央数据库的支持。
- RFID RFID(Radio Frequency Identification,无线射频识别)是一种非接触式的自动识别技术,通过无线射频方式进行非接触双向数据通信,利用无线射频方式对记录媒体(电子标签或射频卡)进行读写,从而达到识别目标和数据交换的目的。基于特别业务场景的需求,在RFID的基础上发展出了NFC(NearField Communication,近场通信)。NFC本质上与RFID没有太大区 别,在应用上的区别如下。
- NFC的距离小于10cm,所以具有很高的安全性,而RFID距离从几米 到几十米都有。
- NFC仅限于13.56MHz的频段,与现有非接触智能卡技术兼容,所以 很多的厂商和相关团体都支持NFC。而RFID标准较多,难以统一, 只能在特殊行业有特殊需求的情况下,采用相应的技术标准
- RFID更多地被应用在生产、物流、跟踪、资产管理上,而NFC则在 门禁、公交、手机支付等领域发挥着巨大的作用。
- OCR和ICR OCR(Optical Character Recognition,光学字符识别)是指电子设备(例如扫描仪或者数码相机)检查纸上打印的字符,通过边检测暗、亮的模式确定其形状,将其形状翻译成计算机文字的过程。如何除错或利用辅助信息提高识别正确率,是OCR的重要课题。ICR(Intelligent Character Recognition,智能字符识别)是一种更先进的OCR。它植入了计算机深度学习的人工智能技术,采用语义推理和语义分析,根据字符上下文语句信息并结合语义知识库,对未识别部分的字符进行信息补全,解决了OCR的技术缺陷。一个OCR识别系统,从影像到结果输出,须经过影像输入、影像预处理、文字特征抽取、比对识别,最后经人工校正将认错的文字更正,将结果输出。目前OCR和ICR技术在业界有较为成熟的解决方案供应商,非数字原生企业不需要自行研发就可以完成相关技术的部署和数据的采集。
- 图像数据采集 图像数据采集是指利用计算机对图像进行采集、处理、分析和理解,以识别不同模式的目标和对象的技术,是深度学习算法的一种实践应用。 图像数据采集的步骤如图7-5所示。
音频数据采集 语 音 识 别 技 术 也 被 称 为 自 动 语 音 识 别 ( Automatic Speech Recognition,ASR),可将人类的语音中的词汇内容转换为计算机可读的输入,例如二进制编码、字符序列或者文本文件。目前音频数据采集技术在业界也有较为成熟的解决方案供应商,可以很便捷地通过解决方案供应商的技术,完成技术的部署和数据的采集。 采集来的声音作为音频文件存储。音频文件是指通过声音录入设备录制的原始声音,直接记录了真实声音的二进制采样数据,是互联网多媒体中重要的一种文件。音频获取途径包括下载音频、麦克风录制、MP3录音、录制计算机的声音、从CD中获取音频等。
视频数据采集 视频是动态的数据,内容随时间而变化,声音与运动图像同步。通常视频信息体积较大,集成了影像、声音、文本等多种信息。视频的获取方式包括网络下载、从VCD或DVD中捕获、从录像带中采集、利用摄像机拍摄等,以及购买视频素材、屏幕录制等。
传感器数据采集 传感器是一种检测装置,能感受到被检测的信息,并能将检测到的信息按一定规律变换成信号或其他所需形式的信息输出,以满足信息的采集、传输、处理、存储、显示、记录等要求。信号类型包括IEPE信号、电流信号、电压信号、脉冲信号、I/O信号、电阻变化信号等。 传感器数据的主要特点是多源、实时、时序化、海量、高噪声、异构、价值密度低等,数据通信和处理难度都较大。
工业设备数据采集 工业设备数据是对工业机器设备产生数据的统称。在机器中有很多特定功能的元器件(阀门、开关、压力计、摄像头等),这些元器件接受工业设备和系统的命令开、关或上报数据。工业设备和系统能够采集、存储、加工、传输数据。工业设备目前应用在很多行业,有联网设备,也有未联网设备。工业设备数据采集应用广泛,例如可编程逻辑控制器(PLC)现场监控、数控设备故障诊断与检测、专用设备等大型工控设备的远程监控等。
# “硬感知”能力在华为的实践
案例一:门店数字化
如图7-6所示,采用7种数据采集方式,支撑持续提升运营效率与消费者体验。通过光线传感器和温度传感器,自动调节窗帘、灯光,温度随环境改变,并与店门、窗帘、灯光、空调、屏幕、防盗系统联动,打造智能绿色门店环境。通过实物管理感知,样机自动申报位置与状态,异常告警,自动上报消费者在门店体验过程中的行为,结合消费者体验情况优化陈列、营销设计、产品设计。通过视频感知客流与热区,管理门店各片区人流密度与停留时间,优化陈列与营销,实时调整服务人力与资源配置。
案例二:站点数字化
如图7-7所示,站点主要在高层或者在野外环境中,勘测和日常维 护难度都比较大,通过360度全景拍照和OCR,构建站点物理对象完整 的围栏尺寸、塔高、机房尺寸、设备尺寸、天线挂高、走线距离、天 线的方位角、下倾角、扇区等数字镜像,实现在数字化站点勘测规 划,现实站点直接施工,避免在现场反复勘测、设计调整。
# 基于数字世界的“软感知”能力
# “软感知”能力的分类
物理世界的“硬感知”是将物理对象构建到数字世界中的主要通 道,是构建数据孪生的关键,而已经存在于数字世界中的那些分散、 异构信息,可通过“软感知”能力来利用。目前“软感知”比较成 熟,并随着数字原生企业的崛起而得到了广泛的应用。我们将“软感 知”分为3类,如图7-8所示。
埋点 埋点是数据采集领域,尤其是用户行为数据采集领域的术语,指的是针对特定用户行为或事件进行捕获的相关技术。埋点的技术实质,是监听软件应用运行过程中的事件,当需要关注的事件发生时进行判断和捕获。 埋点的主要作用是能够帮助业务和数据分析人员打通固有信息墙,为了解用户交互行为、扩宽用户信息和前移运营机会提供数据支撑。在产品数据分析的初级阶段,业务人员通过自有或第三方的数据统计平台了解App用户访问的数据指标,包括新增用户数、活跃用户数等。这些指标能帮助企业宏观地了解用户访问的整体情况和趋势,从总体上把握产品的运营状况,通过分析埋点获取的数据,制定产品改进策略。 埋点技术在当前主要有以下几类,每一类都有自己独特的优缺点,可以基于业务的需求,匹配使用。代码埋点是目前比较主流的埋点方式,业务人员根据自己的统计需求选择需要埋点的区域及埋点方式,形成详细的埋点方案,由技术人员手工将这些统计代码添加在想要获取数据的统计点上。可视化埋点通过可视化页面设定埋点区域和事件ID,从而在用户操作时记录操作行为。 全埋点是在SDK部署时做统一的埋点,将App或应用程序的操作尽量多地采集下来。无论业务人员是否需要埋点数据,全埋点都会将该处的用户行为数据和对应产生的信息全采集下来。
日志数据采集
日志数据收集是实时收集服务器、应用程序、网络设备等生成的日志记录,此过程的目的是识别运行错误、 配置错误、入侵尝试、策略违反或安全问题。 在企业业务管理中,基于IT系统建设和运作产生的日志内容,可以将日志分为三类。 因为系统的多样化和分析维度的差异,日志管理 面临着诸多的数据管理问题。
- 操作日志,指系统用户使用系统过程中的一系列的操作记录。此日志有利于备查及提供相关安全审计的资料料。
- 运行日志,用于记录网元设备或应用程序在运行过程中的状况和 信息,包括异常的状态、动作、关键的事件等。
- 安全日志,用于记录在设备侧发生的安全事件,如登录、权限 等
- 网络爬虫 网络爬虫(Web Crawler)又称为网页蜘蛛、网络机器人,是按照一定的规则自动抓取网页信息的程序或者脚本。搜索和数字化运营需求的兴起,使得爬虫技术得到了长足的发展,爬虫技术作为网络、数据库与机器学习等领域的交汇点,已经成为满足个性化数据需求的最佳实践。Python、Java、PHP、C#、Go等语言都可以实现爬虫,特别是Python中配置爬虫的便捷性,使得爬虫技术得以迅速普及,也促成了政府、企业界、个人对信息安全和隐私的关注。
#### “软感知”能力在华为的实践
“软感知”主要面向产品持续运营提供服务,基于对产品日志、 用户行为的感知,改善产品功能。以华为内部数据管理平台为例(如 图7-9所示),数据管理平台的数字化运营,需要识别用户行为,进而 提升运营效率与用户数据消费的体验。通过对平台埋点,捕捉用户在 界面上从数据定位到最终消费的浏览过程和停留时间等信息,并关联 用户的部门、职位、所在地等信息,自动生成用户画像和数据画像, 确定细分用户范围,界定相同认知背景和业务场景的用户,提供可识 别的分类资产用于搜索,界定数据资产分类,面向不同用户界定不同 的资产范围,减少匹配差异和搜索引擎复杂度,训练搜索引擎和推荐 算法,提供最优数据推荐结果和排序位置。

12类感知能力在企业中的应用,突破了原有人工维护数据的局 限。但是不管是“软感知”还是“硬感知”,产生的数据在没有纳入 企业整体的数据管理体系情况下,如果只以独立数据的形式存在,是 无法应对复杂的企业数字化变革的。
### 通过感知能力推进企业业务数字化
#### 感知数据在华为信息架构中的位置
感知可以应用于广泛的物理世界和数字世界,感知范围可以从 人、物、作业、地点扩展到复杂环境。成熟的用例倾向于以物和人为 中心。而在企业中,只有将感知数据纳入整体的数据体系中,才能发 挥感知数据的价值。
华为数据治理下的感知能力对接了数据供应链(Data Supply Chain),数据从感知采集到最终的分析消费,都纳入公司级的信息架 构,作为数据资产来进行管理,如图7-10所示。

感知数据生成后,需要通过连接进入下一步环境,通过不同的数 据类型,选择不同的数据接入方式。在确定数据接入方式之前,需要 重点考虑以下几个问题。
- 数据源的可用性分析。
- 接入的数据量大小。
- 数据接入过程是连续的还是按一定的时间间隔进行。
- 数据接入是拉(Pull)的方式还是推(Push)的方式。
- 在数据接入的过程中,是否需要做数据校验或数据标准化。
- 在接入的过程中,是否需要对数据做进一步的处理,如数据聚 合、数据分类等。
感知数据的接入方式与工具如图7-11所示。
根据不同的数据采集方式、采集内容和接入方式,选择合适的存 储介质。在选择存储介质的时候需要考虑如表7-2所示的因素。
作为数据资产管理的核心,感知元数据管理应该包含两个方面的 内容,如图7-12所示。
- 感知方式元数据:对数据感知的方法进行登记注册的过程,在后 续的数据消费的过程中可以知道数据来源。
- 感知内容元数据:感知内容包括结构化数据和非结构化数据,所 以元数据管理也分为结构化数据元数据和非结构化数据元数据。
感知得到的数据是企业信息架构的一部分,在数据分类中需要基 于感知采集方式的差异,制定不同的管理办法。 观测工具和观测对象都要纳入信息架构中,定义业务对象对其进 行管理。观测数据在资产管理中识别业务对象时,可以采用以下两个 建议:
观测对象是一个时,观测数据挂靠在该业务对象下。
观测对象是多个时,观测数据按大股东原则判定数据Owner和挂靠 业务对象。
# 非数字原生企业数据感知能力的建设
因为非数字原生企业的业务特征、数字化基础和数据管理阶段都 不一样,数据感知和采集工具的成熟度也不一致,考虑技术发展和成 本的制约因素,企业一般会逐步构建感知能力,完善企业数字孪生。 我们参考埃森哲关于数字孪生的调查总结出了图7-13所示的数字孪生 成熟阶段。
如果非数字原生企业需要构建感知能力,可以考虑从以下几个方 向来选择,关键是能力的构建始终要贴合业务,尽快促成业务价值的 呈现。
开发一个独特的物理对象感知能力可以获得收益的方向,包括改 善运营、降低运营风险、降低成本、更好地为客户服务的机会, 或者通过拥有质量更高、更全面的数据来进行更好的业务决策。
在更复杂、更昂贵的环境(例如工业机器和企业资产)中,更有 可能抵消感知能力构建的实现成本。
组织是否拥有相关感知能力的前身,比如可以利用现有的、详细 的元数据和模型(例如BOM、CAD和仿真模型)。
需要一个模型来支持极端的操作环境,比如远程或环境恶劣的地 方。
探索技术或商业模式的创新,比如增强现实的应用,或者实现资 产货币化的新方法,或者提供前所未有的、差异化的服务水平等 领域。
# 第八章:打造“清洁数据”的质量综合管理能力
越来越多的企业应用和服务都基于数据而建,数据质量是数据价 值得以发挥的前提。例如企业运营效率主要依赖于数据获取的准确性 和及时性,企业客户关系管理系统中的错误或不完整数据将导致客户 沟通不顺畅,影响客户满意度。 随着数据类型、数据来源的不断丰富以及数据量的飞速增长,企 业面临数据质量问题的概率显著增加。数据质量是一个复杂问题,往 往是多种因素综合作用的结果,解决数据质量问题要从机制、制度、 流程、工具、管理等多个方面发力。 本章讲述数据质量基本概念和管理框架,详细说明数据质量控 制、数据质量改进、数据质量度量的基本方法。
# 基于PDCA的数据质量管理框架
企业数据来源于多个不同的业务系统,数据流转、处理环节多, 用“Garbage in Garbage out(垃圾进,垃圾出)”原则保证数据质 量已成为数字化转型企业的共识。企业数据质量管理是一个系统性的 工程,华为数据质量从数据质量领导力、数据质量持续改进、数据质 量能力保障三方面展开,有机结合形成联动。
# 什么是数据质量
ISO9000标准对质量的定义为“产品固有特性满足要求的程度”, 其中“要求”指“明示的、隐含的或必须履行的需求或期望”,强调 “以顾客为关注焦点”。 在Won Kim的论文“A Taxonomy of Dirty Data”中,数据质量被 定义为“适合使用”,即数据适合使用的程度、满足特定用户期望的 程度。 数据质量不是追求100%,而是从数据使用者的角度定义,满足业 务、用户需要的数据即为“好”数据。 华为数据质量指“数据满足应用的可信程度”,从以下六个维度 对数据质量进行描述。
以下是数据质量的重点
完整性:指数据在创建、传递过程中无缺失和遗漏,包括实体 完整、属性完整、记录完整和字段值完整四个方面。完整性是数据质 量最基础的一项,例如员工工号不可为空。
及时性:指及时记录和传递相关数据,满足业务对信息获取的 时间要求。数据交付要及时,抽取要及时,展现要及时。数据交付时 间过长可能导致分析结论失去参考意义。
准确性:指真实、准确地记录原始数据,无虚假数据及信息。 数据要准确反映其所建模的“真实世界”实体。例如员工的身份信息 必须与身份证件上的信息保持一致。
一致性:指遵循统一的数据标准记录和传递数据和信息,主要 体现在数据记录是否规范、数据是否符合逻辑。例如同一工号对应的 不同系统中的员工姓名需一致。
唯一性:指同一数据只能有唯一的标识符。体现在一个数据集 中,一个实体只出现一次,并且每个唯一实体有一个键值且该键值只 指向该实体。例如员工有且仅有一个有效工号。
有效性:指数据的值、格式和展现形式符合数据定义和业务定 义的要求。例如员工的国籍必须是国家基础数据中定义的允许值。
# 数据质量管理范围
提到数据质量管理,经常有人会问:数据质量和流程质量有什么 区别?流程质量是基于流程结果评估业务执行的好坏,数据质量更关 注业务对象、业务规则、业务过程、业务结果等数据是否得到了及时 记录。以采购验收为例,采购验收及时性属于流程质量,送达到验收 所需时间满足3天的SLA即属于流程质量合格;而验收数据录入及时性 属于数据质量,验收到录入所需时间满足1天的SLA即属于数据质量合 格。
# 数据质量的总体框架
华为以ISO8000质量标准体系为依据,设计了PDCA(Plan、Do、 Check、Action、计划、执行、检查、处理)持续改进的数据质量管理 框架,如图8-1所示。
数据质量管理以数据清洁为目标,以业务需求为驱动,通过PDCA 的循环,提升数据质量,达到数据质量结果满意。领导力模块通过制 定政策、规范来构建数据质量管理机制,对数据质量的工作起牵引作 用。能力保障模块构建完整的数据组织、流程和工具,起到支撑作用。
自上而下打造数据质量领导力 数据质量政策应该有不同的层次,数据质量的管控要兼顾宏观方 面的指导原则以及微观层面的具体操作要求,引导正确的业务行为, 提升企业成员的数据质量意识。
全面推进数据质量持续改进机制 提升数据质量是为了满足业务应用,业务战略变化会产生新数 据,对数据应用提出更高的要求,使得数据质量管理范围、目标发生 变化,因此数据质量管理是动态、持续的循环过程。
不断加强数据质量能力保障 数据质量管理具有专业性,需要专业团队制定数据质量管理策 略、流程、规范等,通过技术工具实现自动融入日常业务。通过不断 提升数据质量管理组织的管理水平、改善数据质量工具平台,使企业 数据质量获得进一步提高。
# 全面监控企业业务异常数据
不论做了多少数据质量预防措施,实施多严格的数据质量过程控 制,只要涉及人为干预,总会存在数据质量的问题。为了避免或降低 数据质量对业务的影响,要能及时发现数据质量问题。问题的发现既 可以“正向”主动监控,也可以“逆向”通过下游环节反馈问题来识 别。主动发现、制定解决方案、采取行动,比被动采取补救措施效果 更好,并且代价更小。数据质量监控环节必不可少,本节重点讲述基 于异常数据的数据质量监控。
# 数据质量规则
异常数据是不满足数据标准、不符合业务实质的客观存在的数 据,如某位员工的国籍信息错误、某位客户的客户名称信息错误等。 数据在底层数据库多数是以二维表格的形式存储,每个数据格存 储一个数据值。若想从众多数据中识别出异常数据,就需要通过数据 质量规则给数据打上标签。 数据质量规则是判断数据是否符合数据质量要求的逻辑约束。在 整个数据质量监控的过程中,数据质量规则的好坏直接影响监控的效 果,因此如何设计数据质量规则很重要。 依据数据在数据库落地时的质量特性及数据质量规则类型,设计 如下四类数据质量分类框架。
单列数据质量规则。关注数据属性值的有无以及是否符合自身 规范的逻辑判断。
跨列数据质量规则。关注数据属性间关联关系的逻辑判断。
跨行数据质量规则。关注数据记录之间关联关系的逻辑判断。
跨表数据质量规则。关注数据集关联关系的逻辑判断。
华为结合ISO8000数据质量标准、数据质量控制与评估原则(国标 SY/T 7005—2014),共设计了15类规则,具体如图8-2所示。
各种规则说明:
当我们发现某个数据格的数据异常时,往往会思考这一列其他的 数据格是否也存在同样的问题,是否应该对这一列的其他数据格进行 检查。因此数据质量规则一般以业务属性(即数据列)为对象,数据 质量规则类型为颗粒度进行设计和应用。这样既方便获取业务属性的 整体数据质量状况,又可清晰定位异常数据、识别严重问题、制定解 决方案,同时数据质量规则也不会因互相交织而过于庞大,方便后续 的运营维护。
我们以员工“邮箱地址”业务属性为例设计数据质量规则进行数 据质量检查。根据业务问题反馈、数据源剖析及15类数据质量规则对 数据遍历的综合结果,我们设计了“不可为空类”“语法约束类” “格式规范类”三个数据质量规则进行数据质量检查。同时对这三个 子规则向上收敛,形成“邮箱地址”业务属性的完整的主规则,这种 层级关系我们称之为“规则树”,如图8-3所示。
通过规则树,我们既能统计出共有多少员工的“邮箱地址”数据 异常,又可分别统计各子规则的异常数量,从而快速识别出当前哪个 问题更严重(异常数量越多,问题越严重)。因此我们在制定相应的 解决方案时,可能会优先解决问题严重的子规则。
在如图8-4所示的规则应用结果中,我们可以看到6位员工的“邮 箱地址”有异常,其中“不可为空类”的异常有5个,占比最大,且解 决此问题的技术手段简单,成本较低。因此我们决定先解决邮箱地址 “不可为空”的问题,在数据产生系统中根据数据质量规则增加防呆 设计。
这里需要强调的是,并不是每一个属性都会涉及上述15类规则, 例如“记录唯一类”规则,适用于“员工ID”但不适用于“员工姓 名”;“值域约束类”规则,仅适用于有枚举值列表的业务属性。同 时,随着解决方案的落地、历史数据的清理、新需求的开发,需要进 行监控的数据质量规则也会随之新增、变更、取消。例如上面所提到 的“邮箱地址”的“不可为空类”规则,当IT系统实现了防呆功能且 完成历史数据清理后,监控持续一段时间里异常率都为0,则规则可下 线。所以,数据质量规则的生命周期是随着数据治理范围的扩大和数 据治理程度的深入而更新的。
# 异常数据监控
质量控制是通过监控质量形成过程,消除全过程中引起不合格或 不满意效果的因素,以达到质量要求而采用的各种质量作业技术和活 动。要保证最终交付质量,必须对过程进行质量控制,通常是在过程 中设置关键质量控制点。例如,可以在数据录入阶段设置规则程序, 从源头避免不可接受的数据进入系统。
数据质量控制的目的是致力于满足数据质量要求,消除或减少异 常数据。数据质量控制可以在数据的生命周期内的不同时点被应用, 来测试数据的质量和其是否适合于其所在的系统。
华为通过数据质量监控平台,以异常数据管理为核心,实施数据 质量控制,如图8-5所示。
- 识别监控对象范围,确定监控内容
数据质量控制从明确业务需求开始,根据业务规划和数据相关方的需求,阶段性确定数据质量控制范围。从定性、定量两个维度识别关键数据,定性维度参考以下原则。
- 重要性原则
- 关键主数据和基础数据:公司级、领域级主数据,如产品、客户、供应商、组织、人员、站点。
- 关键的事务数据:主交易流的核心事务数据,如客户合同、BOQ、工程服务采购PR、S&OP计划、采购PO。
- 痛点问题:领域业务运营痛点问题、公司级变革、攻关项目、业务核心KPI等涉及的对象纳入度量,如产品Item。
- 成本效益原则
- 运作成熟且质量较高的数据,或度量成本很高但预期的改进很少的数据,可不优先考虑。
- 数据管家也可通过收集业务需求、数据质量问题等其他途径从中筛选当前需监控的数据。
领域数据质量策划样例如图8-6所示,图中领域数据质量监测范围选择,以当期业务运营重点工作“1个全局运营场景、4个核心领域运营场景、2个质量运营场景”作为基础范围,再按照重要性打分排序,筛选出数据质量监控优先级高的业务对象。之后,通过运营管理重点、影响范围、数据质量痛点、下游流程路径选择、与其他属性有逻辑关系等因素,确定业务对象的关键属性集。明确关键数据范围后,通过IT工具配置数据质量规则,识别异常数据。
- 数据源剖析 在着手设计数据质量规则前,需对数据进行快速数据剖析,目的是分析数据源的内容、质量和结构,同时发现和分析数据源中的所有数据不规范问题和使数据项目处于危险中的隐藏数据问题。
数据剖析摘要视图示例如图8-7所示,其显示了配置文件中所有列和规则的属性。摘要视图包含属性的可视化表示形式。电子版图看不清楚,请参考纸质书
- 数据源内容:如从上述数据源剖析结果的摘要视图中,我们可 以了解到此表包含员工工号、姓名等内容,即列信息等。
- 数据源结构:包括技术结构和业务结构。技术结构指空值频 率、相异值频率、值范围(最大值、最小值)、模式、长度、数据类 型。业务结构如组织结构存储是平面结构还是树状结构。
- 数据源质量:根据数据标准分析剖析结果的数据质量,例如必 填字段是否有空值存储,有允许值列表中的值个数与相异值频率是否 一致等。 数据剖析可以更好地识别需要监控数据的质量要素,如图8-8所 示。
3. 设计和配置监控规则,自动监测异常数据
上一节已详细讲述了如何设计质量规则,部署质量监控规则,对 目标数据进行质量监控,并对发现的数据异常情况进行告警。目前华 为数据质量监控平台已实现质量规则的可配置、数字化、快速部署、 自动监控识别异常数据等能力,并可随时间推移,制定周期性监控计 划,监视数据质量的进展情况,并通过虚拟化的方式快速、灵活发布 监控结果,如图8-9所示。
可利用自助分析工具开发在线数据质量分析报告,通过前端工具 不仅能够查看监控结果汇总数据,而且能够通过钻取功能查看异常明 细数据,以便业务人员准确定位业务系统的异常数据。
# 通过数据质量综合水平牵引质量提升
通过数据质量度量综合评价公司整体数据质量水平,制定数据质 量基线,披露数据质量问题与短板,促进问题改进,推动数据Owner承 接数据质量改进目标,持续提升数据质量,实现数据清洁。
# 数据质量度量运作机制
(1)度量模型
过程设计与执行结果并重,设计质量评估信息架构的建设,执行 质量评估数据清洁。数据质量度量模型如图8-10所示。
(2)数据Owner职责要求
- 1)公司数据Owner:下达数据质量目标,并签发数据质量度量报 告;基于数据质量结果及改进状况,对相应数据Owner进行奖励及问 责。
- 2)各领域数据Owner:承接公司数据Owner设定的数据质量目标; 明确数据质量问题改进责任人,并推动问题闭环管理;对数据质量度 量结果负责,依据要求向公司数据Owner述职。
(3)专业支撑组织职责要求
- 1)公司数据管理部:根据公司数据管理工作规划,制定数据质量 目标;组织数据质量度量工作开展,发布公司数据质量度量报告;组 织评审数据质量标准及指标,并验收数据质量问题闭环状况。
- 2)各领域数据管理部:基于公司数据质量度量工作要求,拟定数 据质量标准并设计指标,执行数据质量度量;组织各领域业务专家, 分析数据质量问题根因,制定改进举措及闭环管理。
(4)度量规则
度量对象选定原则:聚焦业务运营痛点数据和影响财报的关键 数据。
度量频率:一年度量两次。上半年度量期间为1月~6月,重点 监控质量改进状况;全年度量期间为1月~12月,综合评价质量达成水 平。
度量方法:从“设计”及“执行”两个方面开展,通过“设 计”明确架构及标准,通过“执行”反映其质量结果。
评价标准:统一采取百分率的方式评价,并根据度量得分划分 如表8-2所示的五档。
# 设计质量度量
为确保设计质量标准稳定,从信息架构的四个角度(数据资产目 录、数据标准、数据模型、数据分布)进行综合评估,其范围覆盖度 量期间内已通过IA-SAG评审发布的所有数据资产。当实际业务有例外 场景时,可向IA-SAG专业评审团申请仲裁,若评审通过,则可采用白 名单的方式进行管理。 (1)数据资产目录
业务对象需有明确、唯一的数据Owner,并对该业务对象全流 程端到端质量负责,如是否有定义数据质量目标、是否有数据质量工 作规划等。
业务对象的元数据质量,如数据分类是否完整、业务定义是否 准确、数据管家是否有效等。
资产目录完整性。
(2)数据标准
- 数据标准元数据质量,如数据标准是否唯一、业务用途及定义 是否准确、各责任主体是否有效等。
- 所有业务对象应准确关联数据标准。
- 数据标准在IT系统及其对应的业务流程中应得到应用和遵从。
(3)数据模型
- 开发概念模型和逻辑模型,并通过IA-SAG评审。
- 物理数据模型设计应遵从逻辑数据模型设计,数据库中物理表 的落地应遵循物理模型。
(4)数据分布
- 已认证数据源,并通过IA-SAG评审。
- 交易侧完整的信息链和数据流,并通过IA-SAG评审。
- 交易侧业务资产、数据湖、主题联接、数据服务、自助分析之 间完整准确的血缘关系。
(5)设计质量打分模型
# 执行质量度量
执行质量度量主要是从数据质量六性(一致性、完整性、及时 性、唯一性、有效性、准确性)评估数据内容的清洁度,涉及三个要 素:客户关注重要性、法律财务风险性、业务流程战略性。业务领域 也可根据阶段性的管理重点和诉求调整评估的要素。
- 客户关注重要性:给客户运营带来直接影响的数据的客户关注重 要性就高,如合同、PO、验收标准、开票数据等。
- 法律财务风险性:与法律、财务的关联性强,一旦发生质量问 题,会触犯法律或带来相关财务损失,那么该数据的法律财务风 险性就高,如收入、成本等数据。
- 业务流程战略性:数据所产生的业务流程如果是公司核心交易流 程(如LTC流程)或战略地位高的流程(如IPD流程),那么数据 的业务流程战略性普遍会得到较高关注;如果是相关支撑或使能 流程(如变革流程、IT开发流程等),那么数据的业务流程战略 性相对较弱。
关键数据对象评分表如图8-12所示。
确定度量指标
与度量对象一样,数据质量度量指标也往往来源于日常监控的数 据质量规则,将业务属性层主规则通过叠加公式变成业务对象层度量 指标。
数据质量规则的设计应让相关业务人员参与,以满足业务的使用 场景。但当某些业务场景的规则不够清晰,或当前的技术手段无法较 为准确地识别异常数据时,这类数据质量规则往往只能用于警示,不 建议纳入度量。例如数据标准的唯一性规则,通过判断数据标准被业 务属性的引用次数来定义。当某数据标准被引用次数少于10次时,我 们认为这类数据标准可能存在冗余的风险,但不能完全确定为异常数 据。此类规则若纳入度量考核,后续需投入大量的人工核对成本。其 次,数据质量规则应可支撑持续度量。例如某些完整性的数据质量规 则,可设置必填项,一次性解决其数据质量问题,此类数据质量规则 不建议纳入数据质量度量。
数据质量指标同时参考5项原则进行设置。
- 重要性原则:对核心数据、痛点问题较严重的数据,需重点考虑 设计度量指标。
- 成本效益原则:运作成熟且质量较高的数据,或度量成本很高但 预期改进很少的数据,可以考虑简化度量指标或不度量。
- 明确性原则:指标设计清晰、可衡量。
- 分层分级原则:可根据不同层级的管理诉求,设计分层分级的指 标。
- 持续度量原则:一次性就可解决问题的数据不需要度量。
一个业务对象下有如此多的数据质量规则,如何叠加形成数据质 量度量指标呢?对于叠加公式,我们建议使用以下计算规则。 1)逻辑实体数据质量度量指标=∑属性数据质量异常数量/∑属性 数据总量,我们称之为数据格面积算法 2)业务对象数据质量度量综合指标= Average(逻辑实体数据质 量度量指标)。 不直接在业务对象层采用数据格面积算法,是为了避免重要的错 误数据被“淹没”。我们以业务对象“采购PO”中的逻辑实体“PO头 信息”和“PO行信息”为示例进行阐述。
- 每年“PO头信息”的数据量大概为“PO行信息”的数据量的 1/100。
- “PO头信息”中业务属性“汇率类型”异常率为50%,即100个 PO头信息中有50个汇率类型错误。“PO行信息”中业务属性“品类” 异常率为10%,即10 000个PO行信息中,有1000个“品类”信息。
- 若我们在业务对象层级采用数据格面积算法作为其度量指标, 则业务对象综合数据质量异常率为:(50 + 1000)/(100 + 10 000)≈10.4%。这就基本忽略了“PO头信息”中业务属性“汇率类 型”这个重要异常率。
当然企业也可根据公司自身的数据特点,制定相应的叠加公式进 行综合计算。例如可以对业务对象下逻辑实体异常率进行加权平均, 而权重比例可参考其数据量的差异倍数进行设置。
确定数据质量衡量标准
数据质量衡量标准是指指标测评结果与用户质量诉求的关系。华 为主要采用五个等级(差、中、良、优、满分)来衡量和拉通数据质 量满足消费者的应用程度,如表8-3所示。为了让读者能更深入地了解 五分制的目的和用途,这里我们列举两个对比示例。
示例一:企业供应商数量为2000家,其供应商账号信息中的“收 款账号”信息准确率为90%,即有200位供应商的“付款账号”数据错 误,这意味着有10%的应付可能出现付款错误。对于这个准确率数据, 消费者是不能接受的。
示例二:企业度量“员工现居住地址准确率”结果为90%。调研统 计结果表明有50%的员工处于租房状态,因此数据消费者认为当前的数 据质量可以满足他们的应用要求。
从上述两个示例我们会发现,不同数据的数据消费者对其要求不 同,不能单纯以度量结果来衡量数据质量的好坏,因此需要有一个衡 量标准。为避免衡量标准的参差不齐,我们有一些原则性的建议。 1)主数据绝对拉通,采用业界通用的六西格玛要求。 2)事务数据可依据各业务流进行相对拉通,但对于完整性和及时 性这类较简易的数据质量要求,应相对严格。 3)衡量标准的划分,数据管家应组织数据生产者和数据消费者共 同协商讨论,达成一致。数据管家应从数据专业视角给予建议,数据 生产者从其当前的数据管理、IT工具、人员技能等方面预估当前的数 据质量水平,数据消费者从数据的使用视角提出数据质量要求。
这里还需要说明一点,同一个业务对象下的不同业务属性的消费 者不同。那么如何综合所有消费者的诉求,在业务对象层级划分数据 质量衡量标准呢?这里我们建议同一业务对象下的可保留部分独立的 数据质量规则,再逐一对业务对象下的所有度量指标划分质量衡量标 准,最后再通过加权平均的方法收敛到业务对象层,即得到业务对象 分。 执行度量 数据质量度量已流程化,因此我们可将其作为一次小型变革项目 进行管理。根据度量运作机制,由公司数据管理部定期启动公司级数 据质量度量。召开启动会议,明确本次数据质量度量细则,如数据质 量度量目标、度量期间、度量范围、度量指标、计划进度等相关事 宜,以确保数据质量度量工作有序、高效地开展,同时也确认数据质 量度量结果的公正、有效。
# 质量改进
数据质量改进致力于增强满足数据质量要求的能力。数据质量改 进消除系统性的问题,对现有的质量水平在控制的基础上加以提高, 使质量达到一个新水平、新高度。 质量改进的步骤本身就是一个PDCA循环。质量改进包括涉及企业 跨组织的变革性改进(BTMS)和企业各部门内部人员对现有过程进行 渐进的持续改进(GPMS)。华为公司也出现过针对一些问题年年改进 但是年年问题再次发生的现象,最为关键的原因就是没有真正按照质 量改进的步骤开展工作,没有用质量改进的方法把真正的根因识别出 来加以改进并固化到流程体系中。因此,规范改进过程并按照过程规 范实施管理改进是非常关键的。 华为定义的改进过程框架是一个大的PDCA循环。通过管理层 (ST)的管理评审以及变革与改进的规划,识别变革与改进项目,每 个项目按照规范的项目群管理运作流程或者改进过程框架实施改进。 改进成果固化到流程及管理体系中并实施推广执行,执行后再通过质 量组织进行客户满意度管理、度量、审核与变革进度指标评估等,将 再次识别改进作为管理评审的输入,最终形成大的改进循环。
数据质量改进流程如图8-13所示。
在这里我们说明一下数据质量控制和数据质量改进的关系。质量 活动通常分为两类:维持与改善。维持是指维持现有的数据质量水 平,其方法是数据质量控制;改善是指改进目前的数据质量,其方法 是主动采取措施,使数据质量在原有的基础上有突破性的提高,即数 据质量改进。
从结果的角度来说,数据质量控制的目的是维持某一特定的质量 水平,控制系统的偶发性缺陷;而数据质量改进则是对某一特定的数 据质量水平进行“突破性”的提升,使其在更高的目标水平下处于相 对平衡的状态。控制是日常进行的工作,可以纳入流程体系的“操作 规程”中加以贯彻执行,最好的手段就是纳入流程体系进行标准化。 质量改进则是一项阶段性的工作,达到既定目标之后,该项工作就完 成了。质量改进的最终效果比原来维持下的效果好得多,这种工作必 然需要精心策划。质量改进要固化在流程体系中进行标准化,通过质 量控制使得标准化的流程得以实施,达到新的质量水平。
质量控制是质量改进的前提,控制就意味着维持以前的质量水 平,是PDCA改进循环中保证水平不下降的“努力的楔子”,是保证下 一次改进的起点,而改进则是在起点基础上的变革和突破。如果不做 好质量控制,质量水平就会下降,下次又在低水平重复,因此不能只 关注质量改进,改进后关键还是要实施质量控制,二者交替进行,相 辅相成。
# 第九章:打造“安全合规”的数据可控共享能力
如何让数据在安全合规的前提下最大程度地发挥价值?这 是数字化转型中的关键问题,如果数据的安全问题得不到妥善解决, 那么宁愿数字化转型慢一点,或者不转型,也不能在错误的方向上渐 行渐远。
# 内外部安全形势,驱动数据安全治理发展
# 数据安全成为国家竞争的新战场
随着近年来大数据、数字化转型的兴起,数据的价值获得了极大 的提升,数据已成为企业和国家的“战略资源”和“生产要素”。 在工业时代,政府通过控制货物、人员、资金的流动来形成国家 壁垒、实现国际影响力;到了数字时代,货物、人员、资金可以全世 界自由流动,而跨区的数据流动反而受限制。数据管控力将成为衡量 国家竞争能力的重要指标。 通过分析各国对网络安全、数据保护、隐私保护的立法进展,可 以看出各国的立法进度都在加快。隐私保护立法都在向欧盟GDPR看 齐,从原来依靠道德约束保护隐私,上升至法律约束。数字时代带来 了新的发展机遇,也给数据安全带来了新的挑战。
# 数字时代数据安全的新变化
伴随着大数据、人工智能、区块链、物联网、5G等新技术的快速 迭代和持续创新,各种新兴技术被越来越广泛地应用到各行各业,企 业内、不同企业间、不同行业间的数字化迁移速度不断加快。但是我 们一定要认识到,现在的网络是不安全的,包括“云”也不是绝对安 全的,2019年以来数据泄露事件频发,从数据上看,勒索软件、网络 攻击的次数与2018年相比翻了25倍。“网络不安全”不再是偶然,而 是常态,不容忽视。
从泄露的根因分析统计来看,随着数字化技术和能力的普及,泄 露的路径越来越多元,已经不再限于“黑客攻击”,更多的是企业内 部人员、离职员工、第三方外包的泄露行为。所以说“堡垒再坚固, 也容易从内部攻破”,这些泄露都不是由技能高超的黑客造成的,而 只是因为企业自身安全管理上的疏忽。图9-1为安华金和发布的《数据 安全治理白皮书》中关于数据泄露的相关案例截图。
# 数字化转型下的数据安全共享
数据安全是从决策到技术、从管理制度到工具支撑,自上而下贯 穿整个组织的完整链条。
非数字原生企业信息化程度差,存在割裂的信息孤岛,阻碍了企 业的数字化转型。随着非数字原生企业的逐步转型,企业拥有的数据 资产越来越庞大。商品的价值原理告诉我们: “买方的市场需求决定 一件商品的价值。”那数据安全的核心价值就是“让数据使用更安 全”。换句话说,数据安全与隐私保护的目标就是解决如何在安全前 提下充分共享数据,如图9-2所示。
如果数据安全共享这件事情没有做好,不单数字化转型的成果无 法呈现业务价值,很有可能企业多年积累的经营成果也付之一炬。
华为最近几年推进数字化转型,并梳理全部数据资产,明确了数 据分类、数据标准、数据分布、元数据注册、访问方式、使用频率 等。数据进底座、生成“数据地图”“数据随需共享”,成了华为数 据治理的主要目标,让数据充分共享并为业务带来价值则是数据治理 的主题。华为在全球范围内共享的数据服务有几万个,覆盖全球多个 国家和不同的业务场景。
数据是不能藏起来的,数据存储起来就是为了消费,为了创造价 值,支撑业务的决策、运营、经营、现场作业。大量的共享对安全提 出了更高的要求,必须在安全、合规的基础上,才能共享数据。
企业在加速数字化转型,通过挖掘数据的价值抓住巨大的发展机 遇。同时,企业面临的风险也在剧增,这些风险源于外部法律要求、 网络安全威胁,也有来自内部数据的大量汇聚和充分共享。
充分认识到数据安全、隐私保护的价值后,我们还需要知道具体 怎么解决数据的安全隐私问题。数据安全治理绝不是一套IT工具组合 的产品级解决方案,而是从决策层到技术层、从管理制度到工具支 撑,自上而下贯穿整个组织架构的完整链路。
# 构建以元数据为基础的安全隐私保护框架
# 以元数据为基础的安全隐私治理
有决策权的公司高层已经意识到安全隐私的重要性,在变革指导 委员会以及各个高层会议纪要中都明确指明安全隐私是变革优先级非 常高的主题,安全是一切业务的保障。
基于这个大前提,我们构建了以元数据为基础的安全隐私保护框 架。在实际的管理流程中,如何利用元数据来管理好我们的安全隐私 呢?安全隐私保护好比治疗过程,我们需要先做全面的体检(元数据 发现),建立病历(信息架构、数据分类等),然后由专业的医生给 出治理策略,也就是策略制定与执行数据保护和控制。整个过程都是 以元数据为基础的,如图9-3所示。
元数据就是描述数据的数据,即数据的上下文。而数据的管理要 求、信息安全要求、隐私、网络安全要求等,都是数据的管理要素, 当然也可以由元数据承载,用元数据来组织、来描述安全隐私管理策 略和约束,如图9-4所示。
# 数据安全隐私分层分级管控策略
在数据安全隐私管理政策一致性上,全球网络安全与隐私保护办 公室和公司信息安全部发布了整体的管理策略,对整个信息安全管 理、隐私保护治理体系进行了分层映射,共同管理,如图9-5所示。
# 数据底座安全隐私分级管控方案
数据底座是“数据随需共享”的关键。在数据底座建设工作开始 之前,业务经常面临的一个问题是,在做数据分析洞察时数据获取 难,甚至有时即使知道数据在哪儿也拿不到。 例如某经营单元在构建其自身的经营分析指标沙盘时,需要用到 61项指标。但由于数据获取没有明确的规则,需要逐个向各数据Owner 索取相应授权,造成了“自己产生的数据自己无权访问”的现象。导 致以上问题的原因就在于,公司虽然发布了数据共享的政策,但由于 政策未完全落地,数据授权和权限控制机制不完善,导致数据获取需 要通过邮件等方式层层审批,尤其是跨业务领域的数据获取需求,往 往需要审批一二个月,极大地影响了业务决策的效率。 但是在数据底座建设好以后,我们又面临另一个重大问题,那就 是在大量的数据汇聚到数据底座之后,如何才能保证这些数据的安 全?当前在数据底座中已有超过数万个逻辑数据实体,上百万张物理 表,如果没有完善的安全管理措施,这些数据一旦泄露将会是一个巨 大的灾难。 所以公司数据底座从建设起,就与公司安全、隐私治理体系之间 建立了紧密的关系,在遵从公司安全隐私管理策略的同时,数据底座 根据需要,发布相关操作流程、规范,指导数据工作。在应用数据安 全与隐私保护框架和方法基础上,构建了数据底座的安全隐私五个子 方案包。
- 数据底座安全隐私管理政策:说明数据底座的责任边界,数据 风险标识标准、数据加工、存储、流转规范
- 数据风险标识方案:平台提供的数据标识能力。
- 数据保护能力架构:数据底座分级存储架构能力。
- 数据组织授权管理:数据在组织内共享的规则。
- 数据个人权限管理:个人访问数据的权限管理方案。
数据底座的安全隐私保护方案如图9-6所示。
在数据安全方面,根据公司信息保密规定,数据底座安全管理总 体原则与数据管理原则是一致的,即“核心资产安全优先,非核心资 产效率优先”。数据安全管理的基本原则如图9-7所示。
数据安全规范主体包括三部分。
- 数据密级分级标准:数据定密的标准,包括外部公开、内部公 开、秘密、机密、绝密五个等级。
- 存储保护的基线:描述每一个级别的数据资产的存储要求以及 入湖原则。
- 流转审批层级:描述每一个级别的数据资产在申请数据共享时 应该经过哪些控制审批。一般控制审批流程下,内部公开数据不需要 审批,在流程中自动存档并知会数据消费方直属主管。秘密数据由消 费方直属主管审批即可,机密数据需要数据生成方和消费方双方数据 Owner共同审批。
在隐私保护方面,根据公司隐私保护总体纲领文件和数据底座自 身的特点,发布了数据底座隐私保护规定,总体原则是“个人数据原 则上不入湖,并尽可能脱敏处理”。数据底座隐私保护管理原则如图 9-8所示。
隐私保护规范主体包括三部分。
- 个人数据分类、分级标准:非个人数据、商业联系个人数据、 一般个人数据、敏感个人数据,共4个级别
- 个人数据保护基线:根据个人数据分级,敏感个人数据、一般 个人数据、商业联系人分别需要做不同程度的数据保护,其中法律明 文规定的特种个人数据严禁入湖。
- 流转审批层级:隐私审批层级基本与安全一致,但新增了隐私 专员的介入,以专家评审身份,参与控制数据流转业务,判别数据消 费的目的限制以及最小化授权。
# 分级标识数据安全隐私
在明确数据分类分级标准的基础上,还需要有具体的平台支撑数 据风险标识。这就包括传统的元数据人工标识方案以及通过规则、AI 自动推荐方案。 1)人工识别数据风险。数据安全隐私分级标识必须基于元数据管 理平台,在平台中构建对数据字段级别的风险标识。 2)基于规则与AI的自动识别。在数字时代,随着数据资产的膨 胀,数据风险标识工作量非常巨大,字段的数量是数据表数量的100倍 有余,依靠人工的方式无法识别全面,需要通过工具,基于规则(正 则表达式)以及AI机器学习的方式,构建自动推荐、识别风险标识的 能力。
在数字时代,数据的安全隐私也得到了越来越多企业的重视,这 其中也包括非数字原生企业,因为这类企业手中的生产工艺和研发数 据中往往包含大量的专利成果和机密配方,而识别数据资产、管理元 数据、标识安全隐私,只是“安全合规”共享数据的第一步。
# “静”“动”结合的数据保护与授权管理
# 静态控制:数据保护能力架构
在充分识别数据风险并标识数据安全隐私后,数据底座产品还需 要提供不同程度的数据保护能力。数据保护能力包括存储保护、访问 控制、可追溯三种,每种保护能力都面向不同的业务管理需求,如图 9-9所示。
存储保护 存储保护能力包括面向表级管理的高防区隔离、透明加密和基于字段级的对称加密和静态脱敏。 1)高防区隔离:高防区隔离就是我们通过在数据底座独立部署单独的防火墙以及配合流向控制、堡垒机等措施,对高密资产重点防护。关键要点就是有独立的防火墙,并且内部区分脱敏开发区以及明文业务访问区,让数据开发人员在脱敏区工作。高防区数据经过审核后才能发布到明文区,给业务部门使用。 2)透明加密:透明加密就是对表空间进行加解密,进入表空间的表自动加密,有权限的应用读取表空间的表时就自动解密。主要用于防止黑客把库文件搬走。 3)对称加密:对称加密指应用对数据字段应用对称加密算法进行加密,需要配合统一的密钥管理服务使用。 4)静态脱敏:首先需要从技术角度制定出脱敏标准。脱敏不是单一的技术能力,而是多种脱敏算法的合集,包括加噪、替换、模糊等,每种数据类型应该有不同的脱敏标准。我们在ETL集成工具中增加脱敏API能力,可以对具体的字段进行脱敏,每类数据字段都依据脱敏标准执行。
访问控制 静态脱敏用于存储保护,而动态脱敏则是一项基于身份的访问控制。通常Web应用都是使用自己的菜单和角色权限进行职责分离,对于数据权限,很难做到字段级别的控制。而动态脱敏可以对某些数据表、数据字段根据身份进行脱敏,从而做到更细颗粒度的保护。
可追溯 在可追溯方面,业界有比较成熟的数据水印技术。简单来说,是直接改动数据,在数据行、数据列中增加水印,不影响数据的关联与计算,适用于核心资产或敏感个人数据。一旦发生泄露,可以溯源定责。
# 动态控制:数据授权与权限管理
对数据的保护,只是采取合理和适当的措施保护信息资源,但是 数据在组织内部肯定是要流动的,需要被加工、消费,需要创造价 值。而脱离业务流,脱离生产、决策的数据,是死的字节,不能称其 为数据资产。 数据授权管理 数据授权和数据权限是两个不同的概念。数据授权主要是面向组 织,指数据Owner对组织授予数据访问权的过程,让数据与组织绑定, 为组织提供长期的数据订阅权限。数据授权包含两个场景。
数据加工授权:由于数据主题联接资产建设中需要跨组织进行 数据联接、加工、训练需要转移数据而发生的数据授权场景。
数据消费授权:由于业务用户数据的分析需要订阅数据服务而 发生的数据授权场景。
数据授权管理要基于数据风险标识和数据保护能力,既能在数据 流转中落实安全隐私控制策略,让数据安全隐私政策落地,又能作为 数据架构治理的抓手,融入架构审核,避免重复建设。
数据权限管理
数据权限管理是基于访问管控规范,对授予的数据访问权限进行 管理的过程。面向个人和面向与岗位绑定的综合管理者的管理策略不 同。
面向个人,指业务制定数据访问管控规范,授予个人数据访问权 限的过程,具有与个人绑定、短期有效的特点。基于消费数据类型的 差异,个人数据权限分为两大场景(如图9-10所示)。
1)业务分析师获取数据资产(原材料场景)。
2)业务用户获取报告访问权限(成品场景)。
基于企业IAM(身份识别与访问管理)和IDM(账号权限管理), 结合数据分级管理机制,让数据权限随人员流动而改变,并统一规 则、集中管控高风险数据,实现对个人权限授予、销权、调动全生命 周期集中管控。
而对于综合管理者,引用人力资源管理岗的信息,当管理者被任 命或者调动交接后,会执行相应的授权和销权操作。这个过程是全自 动的,无须管理层的操作,在有效权限管理的基础上提升了用户在权 限管理下进行数据消费的效率和体验,如图9-11所示。
为打造“安全合规”的数据可控共享能力,我们践行了数据安全 隐私管理不仅仅是一套IT工具组合的思路,基于安全隐私的两个公司 级治理文件,通过“数据底座共享与安全管理规定”和“数据底座的 隐私保护规定”,落实管理要求,分别建设了数据标识、存储保护、 授权控制、访问控制的能力。同时平台调用了传统IT安全措施,通过 态势感知、堡垒机、日志服务等,结合数据安全治理方法与传统的IT 安全手段,做好数据的内外合规,形成完整的数据安全与隐私保护, 实现让数据使用更安全这一目标。
数据安全与隐私保护能力架构如图 9-12所示。
# 10章:对数据治理未来的思考
# 第十章:未来已来:数据成为企业核心竞争力
未来已来:数据成为企业核心竞争力 数字化转型不能一蹴而就,数据治理也不是一朝一夕之功。数字 化转型带来机遇的同时,也给整个企业的数据治理带来了新的挑战。 基于对华为公司数字化转型的解读,我们建立了数据综合治理体 系,发布了信息架构,构建了数据湖、数据底座,打造了数据感知、 安全合规能力,提升了数据质量。但是,在数据成为新的生产要素, 数据成为企业核心竞争力的情况下,未来已来,面对这样一个新的、 复杂的内外部环境,非数字原生企业在数据治理的问题上,做了哪些 思考?我们应当如何应对?
# 数据:新的生产要素
数字化变革改变了人们看待数据的方式。数据不再仅仅被视为商 业活动的副产品,而是战略资源,是发展和提供新型数字产品与服 务、建立新型数字商业模式的基础。
# 数据被列为生产要素:制度层面的肯定
数据作为生产要素的美好前景在我们眼前展开:加快数据要素价 格市场化改革,健全数据要素市场运行机制,并提供组织保障已经提 上了议事日程。各地区、各部门间的数据共享交换将得到快速推进, 数据共享的责任将进一步明确,公共的、基础的数据资源将得到有效 流动。在数据开发利用规范化和数据采集标准化的基础上,数字经济 会不断涌现新产业、新业态和新模式。与此同时,数据管理制度得到 进一步统一规范,数据质量和规范性不断提高,数据分类分级安全保 护制度不断完善,企业商业秘密和个人隐私数据得到更好的保护。
# 数据将进入企业的资产负债表
数据能创造价值,但数据创造价值的功能并不能由数据自身来直 接实现,数据要素也不能直接参与价值分配,而是要经过数据创造、 加工并传输给数据要素使用者后,才能创造价值,进而参与价值分 配。由此可见,在数字时代,能否掌握数据资产并将其有效转化为生 产要素,已经成为衡量一个企业核心竞争力的决定性因素。
# 数据资产的价值由市场决定
数据资产的定价权掌握在市场手中,这就意味着数据资产价值的 公允计量取决于市场参与者通过使用资产而创造经济利益的能力,只 有努力提高企业自身利用数据资产提升生产效率的能力,才能主导数 据资产的市场定价权。我们利用数据资产来提升生产效率的能力,主 要体现在提升营收、提高效率、提高质量、提升速度、增加柔性、降 低成本、减低风险、品牌增值等方面。而传统做法中,基于数据自身 属性(比如数据的数量、质量、及时性、稀缺性、稳定性以及法律限 制等)来决定价格的方式,相比之下就缺乏对数据价值的想象力。
# 大规模数据交互的企业数据生态
# 数据生态离不开底层技术的支撑
在万物互联的智能世界,数据工作所依赖的绝不是一个封闭的系 统,而是一个开放的生态。尤其是在大数据时代到来之后,多类型、 多形态的数据可能会给我们带来超出预期的收益。对数据生态的梳理 和发掘,也会降低依赖于单一数据供应来源所导致的单点失效的风 险。 未来的业务不断变化和发展,企业对于数据的需求没有边界。如 何建立跨越企业边界的数据共享平台,建立安全可信的数据生态,以 尽可能低的成本交换数据、共享数据,将是一个长期而具有挑战性的 课题。 由于数据的可复制特性,我们在实施企业内外部的数据共享场景 时,存在很大的痛点:在企业间大规模数据交互的场景下,双方通过 协议合同定义了严格的数据处理流程条款,包括对逾期数据的及时删 除等,这就需要企业投入不少的IT及业务人力来保障条款的落实,以 满足内外部合规的要求。 因此,我们的数据生态建设目标是:从依赖管理手段到依赖自动 化技术,增强数据管理的可信、透明;通过基于密码学和区块链技术 的智能合约代码化,支撑商业生态系统的数据安全交换;构建统一标 准的数据交换空间,实现与客户、合作伙伴协同的数据生态体验。
# 数据主权是数据安全交换的核心
在数据生态系统中,大规模交互的数据是一种战略资源。数据主 权是数据生态系统中数据安全交换的核心。数据主权是自然人或公司 实体对其数据进行排他性自决的权利。
数据主权的提出,旨在建立一种便于在数据生态圈内交换数据同 时确保数据主权的架构方法,使企业能够在安全可信的数据生态系统 中发挥数据的价值。基于数据主权保护的原理,数据所有者在将数据 发送给数据消费者之前,需要将访问及使用控制信息附加到数据中, 数据消费者只有完全同意该原则才可以使用该数据。
数据主权与云主权、数据采集组件的主权共同构成了完整的生态 主权。
那么,数据主权管理与我们所熟知的数据所有权管理有什么区别 呢?数据所有权管理针对的是数据提供,确保数据同源可信,数出一 孔;数据主权管理针对的是数据访问与使用,确保数据安全共享,防 止数据滥用。数据生态下的安全交换架构如图10-1所示。
企业内部的数据孤岛可以通过数据底座的建设融合在一起,而企 业间的数据孤岛就没有这么容易改变了。近年来,以欧盟GDPR为代表 的数据隐私监管力度加强,企业对数据共享的态度更为谨慎了。企业 间数据生态的建设呼唤新技术的支持,传统的电子数据交换模式已经 不能适应现代的业务和监管要求。
# 国际数据空间的目标与原则
国际数据空间(International Data Spaces,IDS)是一个虚拟 数据空间。它利用现有数据标准和数据技术以及公认的数据治理模 型,推动数据在可信的商业生态系统中进行安全、标准化的交换并促 进数据连接,从而为各种智能服务场景及跨公司业务流程提供基础设 施,同时确保参与其中的数据所有者的数据主权得到保障。为了履行 这项职能,IDS不存储信息,而是通过身份提供者及经认证的连接器组 件,在经认定的通信伙伴之间建立安全交换。外部数据交换是企业的 业务交流过程中的一个重要方面,来自外部合作伙伴的数据可用于提 升运营服务。 IDS协会作为一个非营利组织,推动了一系列研发活动以及标准化 工作。来自世界各地不同行业、不同规模的众多公司均已加入该协 会,成为不可或缺的一部分,确保整体的架构得到发展。 数字化会促使各组织之间共享更多的数据。IDS很早就认识到,即 使在其组织之外,数据所有者也需要掌控其数据资产。因此,IDS倡议 将数据主权作为体系架构开发的一个核心层面。数据主权可定义为自 然人或法人实体对其数据享有完全自决的权利,IDS倡议为该项特定权 利及在商业生态系统中进行安全、可信的数据交换的需求等相关内容 提出一个参考架构模型。
# 多方安全计算强化数据主权
除了基于公钥基础设施(PKI)的数据共享以外,联邦学习也是构 建良好的数据生态、突破企业数据墙有力的技术武器。联邦学习技术 底层依赖于同态加密、秘密共享、散列、梯度交换等多种多方安全计 算机制,在算法层面上可以灵活支持多方安全计算模式下的逻辑回 归、Boosting(提升法)、联邦迁移学习等多种算法模型,可以实现 在保护本地数据的前提下让多个数据拥有方联合建立共有的数据挖掘 模型,从而实现以隐私保护和数据安全为前提的互利共赢。基于联邦 学习技术构建的新型数据生态,有利于打破企业间数据壁垒,实现大 范围、高密度的数据空前的融合协作,辅以密码学、区块链等相关技 术,必将实现一幅前所未有的惠及各行各业的数据生态场景。
# 摆脱传统手段的数据管理方式
智能数据管理是数据工作的未来 在以传统方式对数据实施管理和治理的过程中,数据工作者和业 务方都需要投入相当多的人力和资源,才能达成管理目标,其中的艰 辛,相信各位业内人士都深有体会。而随着智能大数据时代的到来, 各行各业都看到了摆脱传统工作方式的希望。在数据工作方面更是如 此,因为我们的工作对象天然具有极高的数字化程度、极具规模的体 量、强大的内生关联度,我们更需要应用智能化、数字化的新方法来 提升工作效率和效果,借助于数据挖掘、机器学习、数据可视化等方 法来更深入地了解海量、复杂、多维、高度互联的数据,让企业的海 量数据更加透明、可知、易用。 内容级分析能力提供资产全景图 举个例子,初步完成数据的架构工作并构建了企业级的数据湖之 后,我们就可以基于多维数据特征的可视化分析技术,对数据质量进 行内容级分析,采用特征工程方法,建立数据内容的多维模型,在高 维空间进行多维度聚类,利用可视化投影技术在二维平面进行渲染展 示。与传统的表格式数据展示不同,这种基于内容解析的数据资产智 能分析会有诸多强大的应用场景,全景展示所有已经进入企业数据湖 的表字段及其关系结构只是其中最为直接和显而易见的应用。 属性特征启发主外键智能联接 数据表之间的主外键关系是ER模型中的重要组成部分,蕴含了对 后续数据加工利用有重大价值的信息。然而,出于对性能等因素的考 量,很多实现场景并未将这一信息传递到数据供应链的下一阶段,造 成重要信息丢失,给数据管理带来了不小的困扰。传统IT系统及其开 发造成的这一困境,是否可以利用先进的数据分析技术予以弥补乃至 解决呢?我们观察到,在全景图中若干个属性字段投影位置重叠,表 明它们的数据指纹几乎一致,很有可能是可以做主题连接的主外键。 基于这一启发,辅以对主外键关系存在诸多属性约束的条件的帮助, 通过实验证实,我们可以以很高的准确率重建已经丢失的主外键关 系,加速主题连接的创建和拓展,让已有数据通过更多、更准确的连 接发挥更大的业务价值。 质量缺陷预发现 数据质量话题,在前面已经有专门章节论述,这里不再赘述。我 们想补充的是,除了已有的基于规则对质量的方方面面进行有尺度的 微观管控和宏观治理之外,我们也可以利用大数据分析方法,进行介 观层面的分析管理。之所以称之为介观层面,是因为通过大数据分析 与可视化方法,我们可以以极快的速度在宏观和微观之间切换,以前 所未有的人机交互的方式观察数据分布和异常,从而在很大程度上提 升管理水平和效率。简单来说,比如我们观察到,相似类型的数据通 常呈聚集状态,远离数据群的属性节点则往往需要质量人员的更多关 注。 算法助力数据管理 另外,我们可以利用基于密码学的资产指纹技术来更好地管理数 据架构。由于大量数据表中含有相同或相似的字段,且判断两张数据 表是否同源比较耗时,因此我们对每张数据表的字段名进行快速编 码,实现数据表快速比对判重,而不受表中各字段排列顺序影响。我 们已经为物理级数据资产建立了数据架构指纹库,支持快速查询、资 产去重、篡改发现、资产比对。 随着计算能力的不断提升和智能算法的不断优化,我们越来越能 够对数据的实质内容而不仅仅是元数据进行深入分析。相信在不久的 将来,我们会看到越来越多的智能数据分析算法应用于企业内部的数 据管理和治理任务中,让我们数据工作者从繁重的数据处理分析中解 脱出来,有更多的时间思考、设计和解决数据管理的本质问题,既能 下沉到数据里触摸到落地的细节,又能上升到整个全景把握好宏观趋 势。 数字道德抵御算法歧视 基于数据的算法因其黑盒的特性而在某种程度上诱导人类让出了 自己的决策权,我们应该如何重建数据空间里的信任关系呢?数据道 德准则的建立迫在眉睫。我们需要对数据流程上的各个环节所受的影 响进行分类,谨慎评估潜在的道德和伦理风险,充分测试、模拟和评 估数据系统,提高算法模型的透明度,遵循最佳实践进行数据分享。 采集数据之前要取得知情同意,对数据匿名化的能力和限度有充分认 知,从而有效地保护数字道德不受到我们自己亲手构建的系统的伤 害。
# 第四个世界:机器认知世界
真实唯一的“物理世界”和五彩缤纷的“人 类认知世界”
映射“物理世界”的数字孪生——“数字世界”
二十世纪四十年代,数学家香农提出的采样定理是数字化技术的 重要基础,即在一定条件下用离散的序列可以完全代表一个连续函 数。基于香农定律的现代数字技术,我们已经可以通过对物理世界的 感知,构建出完整映射的数字世界,“数字孪生”“数字世界”等概 念应运而生。“数字世界”的形成,使我们可以通过对“数字世界” 的认知来达到对现实“物理世界”的认知,消除了认知过程中在时间 和空间上的约束,大大提升了人类对物理世界的认知能力。
目前,“物理世界”“数字世界”的表述和概念已被广为接受, 当然还有我们前面提到的“人类认知世界”。按照概念出现的先后顺 序,我们不妨称“物理世界”为第一世界,“人类认知世界”为第二 世界,“数字世界”为第三世界(如图10-2所示)。
“数字世界”中的智能认知——“机器认知世界”
随着以算法、算力和数据为基础的人工智能的发展和广泛应用, 我们可以认为出现了第四个世界——“机器认知世界”,即基于大量 数据,各种人工智能“机器”按照各自的算法对映射到数字世界中的 事物进行认知,其认知结论会直接影响人类的决策和行动,如流行的 购物网站的智能推荐、汽车自动驾驶的智能判断、股票交易员数据处 理分析的智能助手等。
数据成为企业的生产要素,将带来数据确权体系和数据市场基础 设施建设的浪潮。大规模数据交互将构成庞大的企业数据生态,数据 管理手段也将全面智能化。“物理世界”“人类认知世界”“数字世 界”和“机器认知世界” 将构成全新的“智能世界”,数据将成为四 个世界相互联接转换的枢纽,成为智能世界的支柱之一。数据治理将 面临一系列全新的问题与挑战。 未来已来,让我们共同努力,把数字世界带入每个人、每个家 庭、每个组织,构建万物互联的智能世界。
完结