数据之道读书笔记-06面向“自助消费”的数据服务建设

数据之道读书笔记-06面向“自助消费”的数据服务建设

数据底座建设的目标是更好地支撑数据消费，在完成数据的汇聚、整合、联接之后，还需要在供应侧确保用户更便捷、更安全地获取数据。一方面业务人员希望尽可能快速地获取各种所需的数据，另一方面要确保数据获取过程中满足安全、合规的要求。同时，业务人员消费数据时，也希望能够有更加灵活的使用数据、分析数据的方式，业务人员希望消费数据的自主性更强，并且不能忍受过去冗长、呆板的报表呈现方式。

在数据供应侧和消费侧的双重推动下，华为公司进行了基于数据服务提供“自助消费”的实践，打造了从数据供应到消费的完整链条。

---

6.1 数据服务：实现数据自助、高效、复用

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

我们来看两个不同场景下的相似案例。
图6-1是以交易侧（OLTP）客户合同为例，涉及近100个系统/工具、近200个集成关系，多种集成技术同时并存，复杂的集成关系导致出现各种数据质量问题，给企业的正常运作带来了很大的风险。

我们换个视角，从业务分析侧（OLAP）看看数据“搬家”造成的问题。以图6-2的经营数据为例，涉及7个领域的30多个系统的集成。在OLAP侧由于类似情况造成的数据“搬家”，可能需要上千万元的IT开发费用。而且，各分析系统对财务数据的使用和再加工，以及数据集成的时间差等，会造成与集团报告不一致，甚至导致安全审计风险。

从这两个案例可以看出，数据在不同的系统间不断“搬家”，数据的一致性很难得到保障，尤其是经过多次搬家后，源头数据往往和下游各系统之间的数据差异巨大。

同时，较复杂的数据集成还会导致企业管理成本上升，每个系统都存在数据的大量重复构建，这样一来，每当源头数据出现变化时，整个业务流上的相关系统都要执行变更。

这种通过集成获取数据的方式不仅会导致当前的诸多问题，而且会给未来的业务发展带来更大的挑战。以图6-3为例，如果不能满足新的协同方式、安全、数据使用模式等要求，将很难应对未来企业之间的交互协作。

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

6.1.1 什么是数据服务

参考IEEE规范，华为公司给出了数据服务的定义。数据服务是基于数据分发、发布的框架，将数据作为一种服务产品来提供，以满足客户的实时数据需求，它能复用并符合企业和工业标准，兼顾数据共享和安全。

以图6-4为例，数据服务和传统集成方式有很大区别，数据的使用方（不仅仅是IT系统人员，也可以是具体业务人员）不再需要点对点地寻找数据来源，再点对点地进行数据集成，从而形成错综复杂的集成关系，而是通过公共数据服务按需获取各类数据。

1. 数据服务给企业带来的价值
数据服务给企业带来了如图6-5所示的价值。

1）保障“数出一孔”，提升数据的一致性。通过服务获取数据的方式类似于“阅后即焚”，大部分情况下数据并不会在使用方的系统中落地，因此减少了数据“搬家”，而一旦数据的使用方并不拥有数据，就减少了向下游二次传递所造成的数据不一致问题。
2）数据消费者不用关注技术细节，可以满足不同类型的数据服务需求。对于数据消费者而言，不用再关心“我要的数据在哪里”，例如用户不需要知道这些数据来自哪个系统、哪个数据库、哪个物理表，只需要清楚自身的数据需求，就能找到对应的数据服务，进而获取数据。
3）提升数据敏捷响应能力。数据服务一旦建设完成，并不需要按使用者重复构建集成通道，而是通过“订阅”该数据服务快速获取数据。
4）满足用户灵活多样的消费诉求。数据服务的提供者并不需要关心用户怎么“消费”数据，避免了供应方持续开发却满足不了消费方灵活多变的数据使用诉求的问题。
5）兼顾数据安全。所有数据服务的使用都可管理，数据供应方能够准确、及时地了解“谁”使用了自己的数据，并且可以在数据服务建设中落实各种安全措施，确保数据使用的合规。
2. 数据服务建设策略
数据服务建设过程中，首先应该在企业层面制定统一的数据服务建设策略，如图6-6所示。这个策略不能只关注数据服务的设计，而应该覆盖全生命周期的各个环节。

1）要制定数据服务建设的方法，确保每个从事数据服务建设的人都明白数据一致性的要求，并且所提供的数据是可信的和清洁的。
2）要建立数据服务流程，以确保各个环节的有效协同，定义整个生命周期中每个角色的责任和有效输出。在企业中，应该有明确的部门负责数据服务流程的建设和看护，一方面要确保所制定的流程能够在实际工作中落地，另一方面随着技术的演进和企业业务环境的变化，持续对流程进行优化和完善。
3）要构建统一的数据服务能力中心，负责数据服务建设方法、规范、流程的落地，数据服务不同于传统集成方式，因此应该有统一的平台提供能力保障。
在数据服务建设中，应该为各个供应方树立统一的标准，并将这些标准以规范的形式进行固化，使所有数据服务建设都遵循同样的标准。
1）数据服务要满足可重用性、减少数据“搬家”。
数据服务在实际或者可预见的时间范围内会被多个需求方消费。
数据服务面向场景进行消费时，无须重复落地。
2）服务提供方在规划服务时应明确服务的用户是谁，并针对用户的场景和需求进行服务设计，同时定义SLA服务水平承诺。
服务要有业务Owner，业务Owner负责组织业务和IT一体化团队，主动进行服务规划和设计。
服务规划和设计人员在规划和设计任何服务时，都应考虑到服务可能会被重用。
服务规划需考虑价值，并优先对高价值的服务进行投资。
服务消费方应对服务提出改进需求，促进服务能力的持续提升。
3）应用只能通过服务接口向其他应用开放其数据和功能，服务接口要稳定，应用间的通信也必须通过这些服务接口进行。
需要说明的是，应用如果需要向其他应用开放其数据和功能，只能通过服务接口，服务接口应该易理解、易使用，达到服务市场准入标准。
4）所有的服务需在统一的服务管控平台中进行注册和发布。
需要说明的是，华为公司的IT服务（HIS）负责提供服务管控平台的注册和发布功能，通过HIS可查询到发布的所有服务。
5）应根据不同场景选择合适的服务化架构粒度。
需要说明的是，服务化要采用合适的架构粒度，不是越“微”越好，也不是越“灵活”越好。

6.1.2 数据服务生命周期管理

完整的数据服务生命周期包括服务识别与定义、服务设计与实现、服务运营三个主要阶段。
服务识别与定义：业务与数据握手，识别服务的业务价值、准入条件与服务类型，减少数据服务的重复建设，提升数据服务的重用度。
服务设计与实现：业务、数据、IT三方协同，使设计、开发、测试与部署快速迭代以实现服务的敏捷交付，缩短数据服务的建设周期。
服务运营：通过统一数据服务中心及服务运营机制，保障服务SLA与持续优化。
1. 数据服务的识别与定义
针对数据需求，规范数据服务识别过程，列出数据服务识别过程需要了解的关键内容，明确数据服务的实现方式和准入条件，提高数据服务的可复用性，减少重复建设，如图6-7所示。

1）分析数据服务需求：通过数据需求调研与需求交接，判断数据服务类型（面向系统或面向消费）、数据内容（指标/维度/范围/报表项）、数据源与时效性要求。
2）识别可重用性：结合数据需求分析，通过数据服务中心匹配已有的数据服务，判断以哪种方式（新建服务、直接复用、服务变更）满足业务需求。对于已有数据服务，必须使用服务化方式满足需求，减少数据“搬家”。
3）判断准入条件：判断服务设计条件是否已具备，包括数据Owner是否明确、元数据是否定义、业务元数据和技术元数据是否建立联接、数据是否已入湖等。
4）制定迭代计划：根据数据服务需求制定敏捷交付计划，快速满足数据服务需求。
在数据服务的识别和定义中，要特别注意数据服务的可重用性。所有的数据服务都是需求驱动产生的，如果没有需求方，那么这个数据服务就没有存在的价值。但是，重复建设也就成了数据服务建设中最大的风险之一。数据供应方很容易基于不同的数据消费方开发出不同的数据服务，而他们的数据需求往往是相似的，但数据供应方可能因为响应周期、客户（数据消费方）体验等压力，并没有花费精力去对来自各数据消费方的需求进行筛选和收敛，这就导致所建设的数据服务往往只是满足某个特定客户（数据消费方）的需求。如果数据服务不具备可重用性，那么它与传统的数据集成的方式相比，就并不具备优越性，有时甚至会导致更大的重复投资。

因此，以数据服务需求分析为输入，通过服务可重用性判断已有数据服务对需求的满足情况，给出满足服务需求的策略，并结合准入条件的关键问题判断服务需求是否能够被快速满足。

通常可以从数据服务提供形式、数据服务提供内容两方面来判断服务的可重用性，如图6-8所示。

在数据服务识别和定义阶段还应重点关注的另一个要素是数据资产的可服务性，通常用于数据服务准入条件的判断，即某个数据资产是否已经具备对外提供服务的条件。

在进行数据可服务性（准入条件）判断时，至少应充分考虑以下因素：
数据Owner是否明确？
数据是否有明确的安全密级定义？
元数据是否定义？
业务元数据和技术元数据是否建立联接？
面向数字化运营分析场景时，数据是否已入湖？
2. 数据服务的设计与实现
在服务设计与实现阶段，要定义服务契约和数据契约，重点明确服务契约所涉及的服务责任主体、处理逻辑，并以数据契约规范服务的数据格式与数据的安全要求。

通过服务契约与数据契约，可以有效地管理在数据交互中可能存在的安全风险，数据供应方可以将一些安全要求通过契约实现。例如，对某些高密级控制属性进行屏蔽。同时，供应方能够通过契约了解哪些消费者获取了数据以及使用的数量和频率等，如图6-9所示。

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

数据服务设计中应强调数据服务的颗粒度，数据服务颗粒度的大小直接影响着服务的可重用性，细粒度的服务更容易被重用。但是，如果我们只考虑可重用性，将导致产生大量颗粒度很小的数据服务，这将对系统的整体性能带来严重的影响，因此必须在服务粒度设计上维护一种平衡。

数据服务颗粒度通常应考虑以下原则

业务特性：将业务相近或相关、数据粒度相同的数据设计为一个数据服务。
消费特性：将高概率同时访问、时效性要求相同的数据设计为一个数据服务。
管理特性：综合考虑企业在数据安全管理策略方面的要求。
能力特性：将单一能力模型设计为一个服务。

基于上述原则，可以形成一些具体的用于指导实际执行的参考规范，如下所示。

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

为确保服务设计后能快速、有序落地，要建立数据服务的开发、测试、部署流程，通过技术、自动化工具、管理协同机制，确保数据服务敏捷交付，缩短数据服务建设周期，如图6-10所示。

服务需求接收与管理：明确数据管理部门、IT部门、业务代表的具体职责，通过三方共同协作，解决需求理解不透彻导致开发过程反复的问题。
构建自助式开发平台：通过简单配置的方式实现数据服务的开发，降低数据服务的开发门槛，缩短数据服务的开发周期。
代码自动审查：通过自动化手段校验服务开发代码的性能及不规范等问题，阻断代码提交，直到问题解决，做到事前规避。
数据自动验证：构建数据自动测试能力，实现数据服务的数据量差异、字段差异、数据准确性差异的验证。
功能自动测试：构建功能自动化测试能力，自动对数据服务SLA、查询出入参数进行自动检查，构建容错机制。
服务部署：数据服务不涉及对数据的修改，采用实时部署的方式可缩短数据服务的实现周期，提升数据服务的敏捷响应能力。
3. 数据服务的变更与下架
随着业务需求的不断变化，数据服务需要随之进行调整，因此在建设中也应做好数据服务的变更管理和下架管理。
（1）数据服务变更管理
可参考以下因素：
服务变更内容：包括数据服务的时效性、出入参数、服务处理逻辑、数据安全策略等。
服务变更影响：业务连续性影响、变更成本影响等。
（2）数据服务的下架管理
因为数据服务是基于用户需求产生的，而业务需求是动态变化的，因此需要持续将调用量很少甚至为零的数据服务从市场中下架，确保数据消费者总能拿到“最好的”数据服务。通常，数据服务的下架有两种情况：一种是由服务消费方主动提出的数据服务下架申请，可以称为“主动下架”；另一种是通过运营度量策略判断需要下架的数据服务（例如，三个月内无服务调用、重复的数据服务等），可以称为“被动下架”。

企业应制定针对不同场景的数据服务下架流程，确保数据服务下架前进行充分的影响度评估，并具备面向所有相关方的消息通知能力，确保实际下架前各消费方的知情权。另外，还应构建一定的自动化实施能力，在各方就数据服务下架达成一致后，系统自动执行数据服务下架动作。

6.1.3 数据服务分类与建设规范

数据服务是为了更好地满足用户的数据消费需求而产生的，因此数据消费方的差异是数据服务分类的最关键因素。具体包括两大类：数据集服务和数据API服务。
1. 数据集服务
（1）数据集服务定义
比较常见的数据消费者有两类：一类是真实的“人”，一类是“IT系统”。企业越来越强调各业务部门的自我运营，因此产生了大量自助分析消费者，这类消费者就是业务人员，甚至可能是管理者，他们通过各种数据分析工具，直接使用、消费数据。这种情况下，消费者是“访问”某个相对完整的“数据集”，这种消费方式称之为“数据集服务”。

数据集服务最主要的特征是由服务提供方提供相对完整的数据集合，消费方“访问”数据集合，并自行决定接下来的处理逻辑，如图6-11所示。

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

举例来说，数据服务供应方提供信息搜索、查询服务，但并不清楚用户的真实意图，用户可以自由地在服务提供方的地盘上“玩”数据。
（2）数据集服务建设规范
数据集服务主要面向自助分析场景提供相对完整的数据集合，因此所提供的数据主要来自数据底座，包括“数据湖”和“主题联接”。
当所提供的数据来自数据湖时，建设规范如图6-12所示。

1）允许将数据湖的同一个业务对象内的一个或多个资产封装为数据服务。
在部分实时性要求极高的场景下，例如，对于某个地区所有销售投标项目的实时状态可视化场景，可以将“投标项目（Proposal）”这个业务对象下的多个逻辑数据实体封装在一起，设计成可以支撑投标的实时可视化的数据服务。

2）允许将数据湖内单个资产及其关联主数据合并封装为数据服务。
在部分实时数据服务需求场景下，需要向用户提供相对完整的主数据或基础数据信息，以便于用户自助分析。例如，某个业务部门可能需要交付项目实施计划的数据服务，以便进行实时监控和指挥。当通过IT系统或应用实现该功能时，只需获取数据湖中原始的事务数据（交付项目实施计划明细），但在自助分析场景下，由于数据服务面对的是具体的业务人员，而业务人员不可能读懂任务ID、区域组织ID等物理层主键或外键，并且没有必要让每个自助分析人员都重复进行共性数据联接，因此可以在数据服务封装时，将必要的数据联接在一起，比如将“任务与任务资源关系”或“任务与区域组织关系”与交付项目实施计划明细合并封装为一个数据集服务。

3）不允许将数据湖中跨业务对象的多个资产合并封装为一个数据服务。
要注意数据服务合并封装的边界，数据服务的本质是将已有数据资产以服务的形式提供给消费者，而不是在服务中创建一个新的数据资产，面向OLAP的数据资产创建应该在数据主题联接完成，这在一定程度上也可以避免出现数据服务大量重复建设的情况。

当所提供的数据来自于主题联接时，建设规范如图6-13所示。

1）允许将单个主题联接的数据资产封装为一个或多个数据服务。数据服务在面对不同消费者的不同需求时，可以适当地拆分为多个数据服务，以便更好地提供给数据消费者，减少冗余数据，提升用户体验。例如，在封装“区域损益明细实际数据”服务时，集团职能部门和具体业务部门的需求可能是不同的，具体业务部门不需要精细到产品L3以下的明细数据。如果把产品L1～L5的所有明细都提供出来，数据量将会以百倍的规模增加，会极大地影响数据分析性能，这显然是不必要的。比较恰当的方式是将两类需求分别封装为不同的数据服务，并确保这些数据服务的数据来源于同一个主题联接数据资产。
2）允许将由多个主题联接数据资产组成的多维模型整体封装为一个数据服务。
在部分情况下，主题联接数据资产并不是以宽表的形式落地，而是以多维模型的形式存在，此时可以将多维模型整体封装为一个数据集服务。例如，可以将“预测多维分析模型”中的“区域组织维表、产品维表、预算事实表”等封装为一个服务，满足区域组织经营管理的需要。
3）不允许将多个主题联接数据资产直接合并封装为一个数据服务。
数据资产之间的联接属于主题联接范畴，应该首先沉淀为公共数据主题联接资产，再封装为服务。
2. 数据API服务定义
数据服务的另外一类消费者是“IT系统”，即面向某个IT系统提供数据事件驱动的“响应”，这种服务的封装方式与前面所提到的数据集不同，称为“数据API服务”。
（1）数据API服务特征
服务提供方“响应”消费方的服务请求，提供执行结果，如图6-14所示。

数据服务提供方基于随机的数据事件主动地传送数据。
数据服务提供方会基于事件定义数据处理逻辑，由消费方提前订阅并随机触发。
服务的生命周期跟着事件走，事件关闭了，服务就终止了。
例如，华为公司给OBS（Object Storage Service，对象存储服务）提供面向客户的服务能力评估和报价复核服务。

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

（2）数据API服务VS数据集成服务
数据API服务与传统系统集成相比有非常明显的优势，如图6-15所示。

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

6.1.4 打造数据供应的“三个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为例进行明确的承诺，并在公司层面进行公示，请所有数据需求方共同对供应能力进行监督。

6.2 构建以用户体验为核心的数据地图

在解决数据的“可供应性”之后，企业应该帮助业务更便捷、更准确地找到它们所需要的数据，这就需要打造一个能够满足用户体验的“数据地图”。

6.2.1 数据地图的核心价值

数据供应者与消费者之间往往存在一种矛盾：供应者做了大量的数据治理工作、提供了大量的数据，但数据消费者却仍然不满意，他们始终认为在使用数据之前存在两个重大困难。
1）找数难
企业的数据分散存储在上千个数据库、上百万张物理表中，已纳入架构、经过质量、安全有效管理的数据资产也会超过上万个，并且还在持续增长中。例如，用户需要从发货数据里对设备保修和维保进行区分，以便为判断哪类设备已过保（无法继续服务）提供准确依据，但生成和关联的交易系统有几十个，用户不知道应该从哪里获取这类数据，也不清楚获取的数据是否正确
2）读不懂
企业往往会面对数据库物理层和业务层脱离的现状，数据的最终消费用户无法直接读懂物理层数据，无法确认数据是否能满足需求，只能寻求IT人员支持，经过大量转换和人工校验，才最终确认可消费的数据，而熟悉物理层结构的IT人员，并不是数据的最终消费者。例如，当需要盘点研发内部要货情况的时候，就需要从供应链系统获取研发内部的要货数据，但业务用户不了解该系统复杂的数据存储结构（涉及超过40个表、1000余个字段），也不清楚每个字段名称下所包含的业务的含义和规则。

企业在经营和运营过程中产生了大量数据，但只有让用户“找得到”“读得懂”，能够准确地搜索、便捷地订阅这些数据，数据才能真正发挥价值。

数据地图（DMAP）是华为公司面向数据的最终消费用户针对数据“找得到”“读得懂”的需求而设计的，基于元数据应用，以数据搜索为核心，通过可视化方式，综合反映有关数据的来源、数量、质量、分布、标准、流向、关联关系，让用户高效率地找到数据，读懂数据，支撑数据消费。

数据地图作为数据治理成果的集散地，需要提供多种数据，满足多类用户、多样场景的数据消费需求，所以华为公司结合实际业务制定了如图6-20所示的数据地图框架。

数据地图为四类关键用户群体提供服务。
1）业务分析师
业务分析师是企业最大的数据消费群体，具有良好的业务背景，有些数据分析师本身就是业务人员，了解业务需求实质，理解业务含义，与利益相关者有良好的沟通。通过对数据的识别，借助数据分析工具，生成可供阅读的图表或者仪表板，使用分析结果识别问题，支撑决策。对数据可信度、业务含义、数据定位有强烈诉求。
2）数据科学家
数据科学家是指能采用科学方法、运用数据挖掘工具对复杂异构的数字、符号、文字、网址、音频或视频等信息进行数字化重现与认识，并能进行新的数据洞察的工程师或专家。对业务含义、数据关系有强烈诉求。
3）数据管家
公司数据管理体系的专业人员，负责协助数据Owner对数据信息架构进行管理，包括定义信息架构中的责任主体、密级/分类，为数据安全管理提供重要输入。通过信息架构设计，统一业务语言，明确管理责任，设定数据质量标准，拉通跨领域信息流，支撑运营和决策。对数据质量、信息架构、数据关系有强烈诉求。
4）IT开发人员
主要为企业的数据仓库开发人员，通过对物理表进行定位、识别和ETL，创建满足业务分析师或者应用平台所需要的模型或维表。对数据定位、数据关系有强烈诉求。

6.2.2 数据地图的关键能力

数据地图重点提供数据搜索、排序推荐、数据样例、资产/用户画像等关键能力。
（1）数据搜索
数据搜索可以提高用户的搜索准确度，使用户能快速理解搜索出来的数据内容，通过组合搜索、筛选分类，数据标签等持续提升用户体验。
通过界面封装搜索引擎，只向用户暴露单一的搜索栏，通过搜索栏的单一或者组合搜索，发现数据。
以图6-21为例，当用户搜索“数据标准”时，既可以精确匹配名称的资产，通过关联搜索带出完全匹配的资产并进行展示，也可以在输入的关键词无法直接匹配逻辑实体或者物理表名称的情况下，执行模糊逻辑搜索，对所涉及的前分词、后分词、中间分词进行匹配，除了逻辑实体名称，也会涉及属性名称、业务描述等更多内容的匹配。
当没有完全匹配的直接资产时（如“人员”），会根据前后分词进行搜索，这样整体的结果记录会比较多，并会涵盖搜索属性名称或者业务定义中的“人员”关键词。

（2）排序推荐
排序推荐能让用户更容易地找到高质量、可消费的数据资产，缩小搜索结果集范围，减少数据识别和判断的时间，最终目标是让用户实现“所搜即所得”的效果。
对应搜索结果的推荐排序，主要在功能侧提供了两类服务，以便用户通过被动式和主动式的办法管理搜索结果。
1）被动响应推荐排序
用户在前端无须操作，通过推荐排序逻辑对结果集进行处理，完全基于数据管理分类、用户行为分析等输入。优点是提升了用户的体验，无须操作即可以大概率定位到自己需要的数据资产；缺点是与用户之间缺乏交互，准确度因人而异，需要积累大量管理分类和用户行为的输入作为参考。
2）主动管理推荐排序
通过数据管理侧的分类和通用性的标签进行分类管理，用户在使用过程中可以通过分类标签对搜索结果集进行再次过滤和定位。优点是与用户有一定的交互，让用户在使用的时候可以主动管理；缺点是基于管理侧和通用性收敛上来的标签难以满足个性化的需求。
接下来我们看两个示例。
示例1：以属性名称组合搜索为例，一组属性名称串联起来，连用“订单履行经理，BU，CF_EPD，ETRAK标识”组合搜索，结果集中全匹配、部分匹配的结果会按照前后的顺序进行排列，匹配程度越高的数据资产排序会越靠前，如图6-22所示。

示例2：以“合同”为关键词，相同关键词匹配程度、相同密级的情况下，合同维表的消费频率高于合同与项目关联信息的消费频率，排序优先，如图6-23所示。

（3）数据样例
“读懂数据”是用户进行数据消费的基础，用户只有读懂数据，才可以准确判断数据的来源、质量、可信度等关键信息。除了可以通过提供数据资产的各类元数据信息来辅助用户读懂数据外，生产环境的实时数据对用户而言更有参考价值，因为生产环境直接采集的数据的内容，与用户可消费的数据内容是一致的。
接下来看一个样例数据查看的示例：
用户在搜索结果中点击样例数据，能够自动读取数据库名称，并根据对象编号，查找数据库记录表，实现生产环境数据的样例查看，如图6-24所示。

（4）资产/用户画像
资产/用户画像通过标签化的手段来对资产和用户进行清晰地描绘，有助于数据搜索和推荐排序的不断优化，贴近用户真实需求。
基于用户画像、经验模型库和资产画像理解文本语义，可以提高搜索准确性，解决资产查不到、难挑选等问题，并通过业务运营不断优化资产搜索能力，如图6-25所示。

6.3 人人都是分析师

数据服务解决了“可供应性”，数据地图解决了“可搜索/可获取性”，当消费方获取数据后，提供“可分析”能力，帮助数据消费者结合自身需要获取想要的分析结果。

6.3.1 从“保姆”模式到“服务+自助”模式

过去，各业务部门的分析诉求往往通过公司总部“保姆式”开发模式来满足，即业务部门只负责提出需求，所有的方案从设计到开发实现，统一由总部完成。这也是传统意义上的数据仓库的标准报告生成方式，强依赖于IT人员，贯穿整个数据分析过程，从获取数据、建模到设计报告，均需要IT人员的支撑，如图6-26所示。这种模式存在多个问题，如下所示。

1）总部开发周期长，通常从需求提出到开发实现，需要多轮次需求解析和澄清。由于总部并不了解业务部门的实际业务，即使在方案设计阶段也可能需要再次对需求进行确认。IT开发完成后还需要进行严格的测试验证和部署，因此整个周期通常最短也需要30天左右。

2）无法满足灵活多变的业务要求。业务运营和业务作业不同，作业模式相对稳定，当大的场景不发生变化时，作业模式是基本稳定的。而业务运营是按需开展的，往往是从问题出发，在业务开展过程中，可能出现的问题、风险是经常变化的，很可能任何一个内外部因素的变化就会带来新的业务运营关注点，而总部开发模式不可能实时满足所有区域的要求。

在这种背景下，提出了“服务+自助”模式（如图6-27所示），即公司总部只提供统一的数据服务和分析能力组件服务，各业务部门可以根据业务需要进行灵活的数据分析消费，数据分析的方案和结果由业务自己完成。这一模式有如下价值。

1）数据分析消费周期极大缩短。当各业务部门需要进行数据分析消费时，可以直接调用已建好的数据服务进行自助分析，整个报表开发周期缩短为1～2天。
2）发挥业务运营主观能动性。俗话说“高手在民间”，各业务部门是业务作业的责任主体，同时也对业务及经营结果负责，因此各业务部门是业务运营的第一责任人，同时也是最了解业务自身现状与问题的。通过自助模式，可以更有效地发挥各业务部门的主观能动性，真正将数据分析消费与业务运营改进相结合。
3）减少“烟囱式系统”的重复建设。各业务部门在保证数据分析消费灵活性的同时，并不需要重复构建支撑消费的数据基础，所有公共的数据汇聚、数据联接都统一建设，在遵从隐私保护和安全防护要求的前提下以数据服务的形式充分共享。

6.3.2 打造业务自助分析的关键能力

华为公司将自助分析作为一种公共能力，在企业层面进行了统一构建。一方面，面向不同的消费用户提供了差异性的能力和工具支撑；另一方面，引入了“租户”概念，不同类型的用户可以在一定范围内分析数据、共享数据结果。
1. 针对三类角色提供的差异性服务
面向三类角色的分析架构能力如图6-28所示。

（1）面向业务分析师，提供自助分析能力，业务人员通过“拖、拉、拽”即可快速产生分析报告
基于多租户环境，提供数据资产订阅、报表作品搜索、服务订阅等能力。
实现从数据查询到数据拖拽式分析的端到端的一站式自助作业，增强数据即席查询和数据建模等功能。
提供数据搜索、数据获取、自助分析、数据消费等一站式自助分析服务，缩短报表开发周期。
支持租户管理、工具集管理、日志管理功能，集成数据底座权限模型，提供稳定的分析环境。
（2）面向数据科学家，提供高效的数据接入能力和常用的数据分析组件，快速搭建数据探索和分析环境
集成数据可视化、数据建模能力，降低数据分析门槛，提高平台的易用性。
识别公共诉求，提供R Studio、Zeppelin等工具集，增强NLP基础服务、人工智能等分析装备对于机会点的支撑能力，支撑各种大数据分析应用场景。
提供源系统到分析平台的数据实时同步功能。
为数据科学家提供数据目录导航入口。
提供数据分析环境，支持权限申请和计算资源的分配，缩短建模周期。
（3）面向IT开发人员，提供云端数据开发、计算、分析、应用套件，支撑海量数据的分析与可视化，实现组件重用
整合数据接入、数据计算、数据挖掘、数据展现等能力，提供高效、安全的数据集成、数据开发、报告开发、数据管理等服务，减少重复建设，实现组件重用。
整合第三方资源，依托HIC能力通道，提供自助、按需、在线的基础数据服务，包括分布式处理、实时处理、内存计算等。
2. 以租户为核心的自助分析关键能力
（1）多租户管理能力
租户是指把数据、分析工具、计算资源有机组合的工作环境，用户可以在租户内自助完成数据搜索、数据加工、在线分析、报表共享等工作。

多租户技术也称多重租赁技术，是一种软件架构技术。多租户技术可以实现多个租户之间共享系统实例，同时也可以实现租户的系统实例的个性化定制。通过使用多租户技术可以保证系统共性的部分被共享，个性的部分被单独隔离。例如，按国家设定不同租户，这样在本租户内共享该国的经营分析结果，共同进行异常分析和经营改进；同时，该租户数据对其他国家屏蔽，避免了数据扩散等安全风险。

为了合理分配软硬件资源，满足各领域在线、自助、个性化的数据分析诉求，促进数据的安全共享和价值变现，明确了租户申请、租户命名、数据准备、数据同步、数据加工、数据申请、权限管理、安全与隐私、运维与运营等方面的要求，旨在通过正确的引导，确保数据消费的便捷、高效与安全合规，支持公司的数字化转型。
在多租户建设中，相对于技术层面的解决方案，租户管理的职责需要在企业里建立共识，将共识以标准规范的形式固化下来。租户自助分析能力架构如图6-29所示。

租户的4个关键角色如下所示。
租户Owner：租户管理的第一责任人，由公司正式任命的管理者或者变革项目经理担任，是租户内数据消费的总责任人。
租户管理员：由租户Owner指定并授权，是对租户内资产、用户、报告的日常维护、配置、授权承担具体管理职责的人员。
查看者：申请并被允许加入租户，只对租户内的报告有查看权限的租户用户。
分析师：申请并被允许加入租户，对数据资产可执行申请数据入租户、申请租户授权、通过分析工具分析数据、制作报告、查看报告、分享报告等操作的租户用户。
（2）数据加工能力
在同一个租户空间内，对数据进行关联、过滤等操作，满足最终分析报告的数据需求。
用户可将多个数据进行关联，构建自己的宽表，可对宽表进行数据过滤，选择合适的字段以及增加计算字段，如图6-30所示。

（3）数据分析能力
基于消费场景，利用租户内授权的数据资产，通过分析工具对数据进行分析并生成可视化报告。
用户可以选择即席查询自行配置各类条件后的结果数据，再基于这些数据直接链接到不同的分析工具，进行进一步的数据分析。
1）即席查询
提供通过筛选条件展示结果数据的能力，如图6-31所示。

提供生产环境的实时数据内容，有助于用户通过筛选后的结果数据判断能否满足最终的分析需求。
分析结果支持以文件服务器的方式下载，满足本地化处理的需求，同时避免数据被过度共享。
2）可视分析
查看已授权并加工好的数据的详情，进入可视化分析阶段，充分利用企业现有的分析工具，或打通主流的商业分析工具，减少开发成本，降低学习成本，如图6-32所示

数据打通，已授权加工后的数据可以直接进入分析工具进行分析操作。
最大程度利用各种分析工具的已有功能。
（4）自助分享能力
基于自助分享能力，可以对分析报告进行密级设定和权限管理，向租户个人或者群体分享报告，不仅可以分享给本租户内指定的用户，而且可以进行跨租户分享。这样一方面可以扩大报告的使用范围，降低报告重复建设过程中的成本，另一方面也有助于解决分析结果不一致的问题。
对报表提供浏览和编辑能力，查找需要浏览的报表，选择查看、编辑、分享、删除功能。
提供对生成的报告定义密级的能力，报告生成者作为报告的Owner，定义密级和管控分享范围。

6.4 从结果管理到过程管理，从能“看”到能“管”

数据分析和消费本身只是一种手段而不是目标，数据消费要真正产生价值，必须与业务密切结合。业务数字化运营是华为公司数据消费的最重要场景之一。

6.4.1 数据赋能业务运营

业务运营的本质是围绕业务战略“RUN”流程。运营过程中业务沿着流程周而复始地运转，在作业过程中识别并解决问题，应基于PDCA循环（戴明环）进行有质量的运营。而数字化运营旨在利用数字化技术获取、管理和分析数据，从而为企业的战略决策与业务运营提供可量化的、科学的支撑。
数字化运营归根结底是运营，旨在推动运营效率与能力的提升，所以它体现在具体的业务中，而不是一块新的业务，更多是在现有标准流程的基础上改进和完善。数字化运营的核心是数据，以及基于数据的精细化管理和科学决策分析。企业业务数字化运营模式如图6-33所示。

业务数字化运营的目的不应只有“察（数字化看板）”，还应该进一步实现“打（业务决策与执行）”，即支撑业务运营作战模式转变，提升运营效率。业务数字化运营要发挥对业务的指挥作用，要能够让上下同步感知业务运行态势，通过分工协作解决业务运作中的问题，提升运作效率。
业务数字化运营要同时具备多个能力，包括战略落地、业务可视化、预测预警、作业指挥、跨领域问题解决和联动指挥等。
基于数据底座的数字化运营模式（如图6-34所示）支撑着华为公司大量相对独立的业务作战单元和业务部门，基于自身业务进行持续运营，提升业务效率和业务盈利水平。同时，也解决了过去普遍存在的“线下会议多、手工报告多”等问题，避免让大量作战人员将精力消耗在事务性工作中。

（1）满足业务运营中数据实时可视化的需求
过去，数据的展现时间与数据在业务中的真实发生时间往往有相当长的时间间隔。某个具体的作业数据进入系统后，要经过复杂的集成和长时间的等待才能体现在报表中，业务部门无法第一时间掌握真实的工作进度，也就无法在第一时间进行业务管理。例如，分包商进行站点作业时，相关数据往往要第二天或更晚才能体现在监控报告中，等到平台能根据这些信息采取行动时，也无法在作业时发挥作用。假如，站点出现物料问题或安装质量问题，可能会导致分包商重复上站，额外增加了成本。通过实时数据入湖和联接方案，业务可以第一时间获取作业监控信息，从而根据实际情况进行灵活调整，一次性把工作做对。基于实时数据的可视化能力，还能够支持业务在线会议，通过数据底座提供的服务将数据层层下钻，从过去的纸面报告或PPT材料变成可视化的业务场景。

（2）满足业务运营中及时诊断预警的需求
通过数字化手段，在获取业务运营数据的同时，可以根据实际场景差异，灵活配置各种规则类数据，通过分析平台的规则引擎，帮助业务提前感知业务问题、自动预警潜在风险，从而有效支撑业务的快速响应。例如，根据每个国家的供应能力预设不同的预警规则，当供出现瓶颈或问题时，会自动触发预设的预警规则，从而对下一步的设备交付环节进行风险预警，提醒业务部门及时对交付计划进行调整，避免影响客户界面的交付承诺。
（3）满足业务运营中复杂智能决策的需求
通过数据分析模型对数据底座中的海量数据进行挖掘，智能分析业务问题的本质，洞察趋势并推荐方案，从而支持业务的客观、精准决策。例如，基于数据分析的统计预测构建不同的计划方法模型，支撑供应网络多级库存优化、多场景计划决策，应用数字化技术提高计划决策的效率和质量。

6.4.2 数据消费典型场景实践

为了更好地实现数据消费，华为公司通过5个步骤来管理从需求到自助分析的过程，包括业务需求提出、数据解析、数据搜索和获取、数据服务提供、自助报告设计和展示，如图6-35所示。

当业务部门产生数据消费需求后，可以方便地通过数据地图进行搜索。如果已经有数据服务可以支撑，那么就能够快速地订阅服务，从而直接进行数据分析消费；如果暂时没有数据服务可用，那么数据专业人员也只需要提供相应的数据服务，而不需要为业务部门开发定制分析报告，这样就实现了数据供应和数据消费的高效协同。
可以通过一些具体的数字化运营实例看看数据如何发挥作用。
实例1：经营管理实践
过去，经营管理多为事后管理，通过每月下任务令进行业务改进，整个问题从发现到解决周期长，且存在大量人工动作，耗散大量业务精力。数据滞后，经营过程非实时可视，主要为事后管理。
按月做经营分析，从经营数据产生到下发任务令需0.5～1个月。缺少集成管理平台，手工做经营分析，线下管理任务令。
传统经营管理过程如图6-36所示。

通过数字化运营实现事中监控和及时改进，达到经营过程可视化、报告在线分析、实时社交讨论、及时经营改进的目的。
数据在线转变为事中监控，随时可拉通审视规模、盈利、效率全经营指标。
经营管理模式改变，实时分析经营风险，会上聚焦重大风险决策，高效运作。
在统一平台进行监控、预警、协调、任务管理，从战略、执行到经营过程和结果实现闭环。
基于数字化运营的经营管理过程如图6-37所示。

实例2：风险管理实践
过去，业务风险管理主要依赖事后审查，业务发生一段时间后再通过CT（Compliance Test，流程遵从性测试）、SACA（Semi-AnnualControl Assessment，半年度控制评估）、稽核、审计等方式进行事后管理，业务根据审查要求提供相应“证据”。每一次核查都要先定位系统，先由核查人员自己在系统的海量数据中找问题，再约谈相关业务人员确定问题及其原因，这个过程中又存在多轮PK，然后再由责任人负责改进，最终还要由核查人员检查实际落实情况。整个过程不仅消耗大量精力，而且业务往往是被动改进，并不是主动进化。
落实主要依靠流程规则，细则多，执行难。海量线下数据整理和分析，定位内控问题原因难。流程控制评估、遵从性评估、主动性审视、稽核、审计多方事后清理。
传统风险管理方式如图6-38所示。

通过数字化运营，可以实现业务实时自检，风险实时在线审视和预警，风险任务快速关闭，不需要完全依赖事后核查，而是业务人员主动遵从。用数据规则替代人工的分析、检查和回溯，大大提高了风险管理的实时性，从事后管理变为事中管理，部分业务部门的量化风险降低超过50%。
在业务风险控制点打探针，及时发现问题。
实现风险量化可视，实时预警。
实时在线下达风险点的改进任务令，及时改善。
基于数字化运营的风险管理方式如图6-39所示。

6.4.3 华为数据驱动数字化运营的历程和经验

1. 华为数字化运营的不同阶段
数字化运营本身是一种实践，每个企业数字化运营的道路都不相同，华为公司通过数据赋能业务运营是从2016年开始的，中间经历了不同阶段，也走过一些弯路，如图6-40所示。

（1）“从行走到公交”阶段
大部分情况下采取“机关建、业务部门用”的方式。虽然通过数据治理达到了“数据清洁”的目标，也能够实现一定程度的经营和运营数据的可视化，但仍存在机关开发永远满足不了业务部门需求的问题，尤其是不同国家的业务场景各有差异，机关开发无法满足根据业务场景进行灵活运营的目的，机关开发往往疲于奔命，而业务部门满意度仍然不高。
（2）“从公交到自驾”阶段
由于自研和引进了业界先进的分析工具，各区域开始按需以自助的形式生成各种分析报表。在满足各国家、各业务部门特定需求和灵活变化方面，收到了一些效果。但在该阶段，数据从供应到消费的整个过程处于“无序”状态，业务自助分析“野蛮生长”，大量数据是以离线手工获取方式为主，数据的完整性和可靠性存在很大问题，也存在大量的数据安全隐患。
（3）“从无序到有序”阶段
通过数据底座建设实现生态共建、平台共享的效果。随着数据服务的大量建设，逐步覆盖了80%的场景，使得各种数据消费的效率更高、安全性更好，减少了大量重复建设。通过前台统一入口，大大提升了运营分析的性能体验。另外，还打造了从“业务部门回到机关”通道，对各个国家的优秀典型场景进行归纳，业务部门的优秀实践反向纳入数据底座形成公共数据服务和报表卡片，各个国家可以通过自助分析平台实现对优秀实践的快速复制。
（4）“人工到智能”阶段
在原有的数据实时可视化的基础上，逐步增加动态及时预警能力、智能分析和方案推荐能力、任务自动执行能力，支撑业务数字化运营达到更高层面。业务数字化运营逐步从单一报表可视化，扩展到业务监控、预测、预警、协调、调度、决策、指挥等7个场景的持续打造，最终实现企业数字化运营“平时值班、战时指挥、察打一体”目标，如图6-41所示。

2. 做好数字化运营的“三个要点、两个基础”
业务数字化运营不是某个能力的单独应用，需要多种能力的联合推动。在初期孵化过程中，尤其应该关注企业数字化运营的“三个要点、两个基础”。
“三个要点”是指数字化运营中的“发育、激励、分享”。在面向各业务部门的数字化运营能力的“发育”过程中，要做好自助分析能力赋能，识别关键核心人员并通过培训与实战的方式帮助他们掌握自助分析的基本能力，同时机关专家要做好现场支持，帮助各业务分析人员“上马”。在数字化运营实践中要充分激励原创，采取各种方式保护原创，同时鼓励各业务部门充分共享优秀实践。同时，机关要发挥归纳和总结作用，从各地优秀实践中识别真正具有共性的典型场景和典型数据联接模型，不仅可以使自助分析性能更好，还可以推动优秀实践在各个业务部门快速复制，达到“从1到N”的效果。
“两个基础”是指数字化运营中的“数据服务和IT平台”。
数据服务是整个数字化消费的关键，也是业务数字化运营的重要基础。IT平台包括分析平台和数据分析结果呈现前台，其中分析平台承载企业的公共分析能力建设，并重点面向业务分析师提供自助分析能力；数据分析结果呈现前台承载了公共场景的市场能力，支撑典型场景的快速分享。
具体如图6-42所示。

6.5 本章小结

对于非数字原生企业来说，打造企业级的全面的数据服务和面向业务的自助消费，将会是一个长期的过程，中间会遇到大量的困难和挑战。一方面，面临着大量遗留资产和平台的改造；另一方面，面临着诸多技术上的不确定因素。数据服务本身的能力还需要不断改进，在稳定性方面与传统方式还存在一定的差距；整个企业的认知还需要不断加强，很多业务部门还没有完全适应这种模式的转变；人员能力还需要不断提升，很多“业务专家”还不具备“业务数据分析专家”的能力。

但是，未来的方向是确定的，企业数字化转型的决心是确定的，尽管有这样或那样的困难，但数据服务是数据成为业务的“可消费产品”的最关键要素之一，我们应该坚持数据服务化的道路，充分学习和利用各种先进实践和先进技术，不断充实和加强自身能力，让数据服务发挥更大的价值。