华为大数据开发平台 DataFactory 行业应用典型案例

本文将基于华为大数据开发平台 DataFactory 实践数据仓库的快速构建，学会基于 DataFactory 实践数据仓库模型设计，体验 DataFactory 独特的数据流设计工具，最后实战一站式数据开发，快速完成端到端流程。

1 业务背景介绍

假设有这样一个典型业务场景：

XX 公司计划建设数据中心统一数据底座（数据仓库），生产全国 XX 省份的通用数据模型，期望打破数据烟囱，构建场景化、通用性强、易用性高的数据标签体系。达到一点开发多点复用，支撑全国业务批量上线。

这里存在的问题在于：

1. 统一数据底座的业务复杂，且模型众多（多达数百个），需要按照客户规范进行模型分层

2. 数据仓库处理全国数据，每日接入的数据量十分巨大，达到 X PB/天，X 万亿条/天，因此对数据仓库的查询计算性能要求较高

在以上的基础上，客户的主要需求，可以看到主要是以查询为主：

1. 建立统一数据仓库，支持按业务主题进行数据查询

2. 支持按小时、天粒度查询主题数据

3. 支持分省查询主题数据

所谓业务主题，将业务逻辑划分成多个不同的模块，每个模块只关心一个点，最后形成一个网状主题集群，支撑整体的业务决策。

拿到这样一个工程，我们将主要完成一个工作：设计与开发数据应用

主要包括三个部分：

1. 数据编排工程（包括：逻辑模型、物理模型、数据流程）

2. 数据源（作为底层配置项，支持整体模型的定制）

3. 数据仓库（完成数据应用后，需要把数据加载到数据仓库中，构建完整的数据仓库模型体系）

接下来，我们将从逻辑模型、物理模型和数据流程来讲解如何设计和开发一个数据应用。

2 数据模型与数据流设计

2.1 数据模型基本概念

数据模型分类

数据模型可以分为如下 3 类：

• 概念数据模型（概念模型）：高层次静态业务结构和概念

• 逻辑数据模型（逻辑模型）：实体类型、数据属性（字段、类型）及各个实体之间的关系

• 物理数据模型（物理模型）：面向计算机的数据库或其他技术设计和实现

概念模型用一句话用来描述模型的作用，比如某个年级某个学生的一次考试成绩。

规定成绩的概念模型后，逻辑模型的数据属性可以包括为：姓名、年龄、班级、学科等以及这些字段的类型（整型、字符串）；而对于实体的关系，比如对比不同学校、不同区的成绩对比，需要建立不同实体之间的关系。

物理模型没有业务逻辑，主要是物理技术上的问题：用什么样的数据结构去存储，可以选择 MySQL、Oracle 或分布式集群。

数据模型设计顺序

模型设计的顺序应为：概念模型-> 逻辑模型 -> 物理模型

数据模型相互关系

这 3 个数据模型的关系是：

• 概念模型和逻辑模型是一对一关系

• 逻辑模型和物理模型是一对多的关系，一个逻辑模型实体可以有多个物理实现（一个逻辑设计既可以存储在 MySQL、又可以存储在 Oracle 中）

在 DataFactory 中，我们重点关注逻辑模型和物理模型的设计和开发，接下来会讲解如何设计逻辑模型。

2.2 设计逻辑模型

如何设计逻辑模型取决于面临实际的业务需求，在本场景中是构建一个数据仓库的需求。

数据仓库概念

数据仓库是一个面向主题的、集成的、相对稳定的、反映历史变化的数据集合，用于支持管理中的决策指定。

事务型数据库和数据仓库的区别

数据仓库与事务型数据库有着很大的差别，拿电商的一个订单举例：每笔订单都可以作为事务型数据库的一条记录，存放在数据库里，但是如果管理层想要知道当月 30-50 岁这个年龄段的客户主要购买了哪些类型的物品，事务型类型数据库就不太好统计。

因为事务型数据库不是面向数据分析来设计的，此时更合理的方式就是构建一个数据仓库，用于支持决策、面向分析型的数据处理。

下图是二者的区别：

关键点：

• 数据仓库用于支持决策，面向分析型数据处理，它不同于企业的事务型数据库；

• 数据仓库是对多个异构的数据源有效集成，集成后按照主题进行了重组，并包含历史数据，而且存放在数据仓库中的数据一般不再修改

数据仓库特点

• 面向主题

• 集成性

• 稳定性

• 企业范围

• 历史性

数据仓库模型分层

数据仓库中模型众多，复杂度高，特别是模型之间会有大量互相依赖的情况。为了避免出现层级混乱，循环依赖等问题，需要一套行之有效的模型组织、管理方法，这就是模型分层。

下图是一个数据仓库模型的典型分层模式：

最底层是 ODS 层：数据贴源层，通常将数据来源原封不动地存储一份，也可以进行一些简单的清洗操作。作用是统一一个异构数据源，从不同的数据库获取的数据来源，通过 ODS 屏蔽底层差别，统一加载和管理数据。

第二层是 DW 层：数据仓库层，对数据进行清洗、规范化、关联、聚合等操作。也可以不止一层，可以按照层级细分为 DWS、DWB、DWD 等，这一层是数据模型的主要层级，面向业务，最终呈现到上级的分好的主题。

第三层是 ADS 层：数据应用层，面向不同部门、不同业务需求进行定制化开发，提供报表数据。

设计良好的分层模型，在面对新需求时，可以基本保持 DW 层的稳定，仅仅通过新增 ADS 层模型的方式满足需求。相对的，如果在频繁地在实现新需求时修改 DW 层模型（需求打穿到 DW 层），则代码 DW 层模型设计尚需改进。

模型分层的优点

模型分层的作用：

• 明确模型作用：每一个模型都有自己所属的层级，每个层级的功能和职责是明确的

• 拆分复杂问题：将复杂的数据处理步骤拆解为多个简单层，每个层级只解决特定问题

• 应用与底层解耦：有新需求/需求变更时，只需要重新组织生成上层应用的数据处理逻辑。中低层可复用性高，提高新需求的响应速度

介绍完数据模型的基本概念之后，来看一下如何根据需求来进行模型设计。

逻辑模型设计实例

需求分析

需求描述：统计某省视频业务每日下行时延在 50 ms 内的请求占比

通过需求分解，理清业务模型归属主题，数据来源，关联详单等。确定业务模型的依赖树：

操作步骤：

1. 确定业务归属主题

2. 确定主题数据来源

3. 确定数据所属详单

除了左侧的四层模型，还需要 DIM 的维度表——为了数据分析提供各种角度。接下来从下自上详细介绍模型依赖树中各个层级的功能与业务逻辑。

ODS（数据贴源层/ Operation Data Store)

ODS 模型的作用主要是将来自各个数据源的业务数据导入到大数据平台，作为业务数据的快照存储。

因此模型结构通常和源数据保持一致，不做任何处理。但也可以进行一些简单的数据清洗工作，例如处理空值，处理不符合长度要求的值，统一异构数据源字段名，回填一些必要的值等。

主要职责包括：

• 作为业务数据的快照

• 从异构数据源获取数据

• 统一异构模型字段名

• 初步数据清洗

针对下图中 HTTP 网络时延详单模型字段中：

1. 需要进行统一异构模型字段名：比如上图中的序列 6 字段 imsi 和序列 7 字段 msicdn 在 S1U HTTP 和 N3HTTP 中的填写规则就不一样，imsi 的两个填写规则分别为IMSI 和 SUPI ; msisdn 为 MSISDN 和 GPSI。所以 ODS 层需要统一异构模型字段名。

2. 可能需要初步数据清洗的数据：data_id、hour_id、prov_id 等回填值或其他非法值。

DWD（数据明细层/Data Warehouse Details）

DWD 模型是数据仓库层的基础层，也是贴源层和数据仓库之间的隔离层。这一层可以进行一些维表关联、汇聚计算等操作，主要用于统计业务数据

主要职责包括：

• 维表关联

• 汇聚计算

• 进一步数据清洗

针对下面 HTTP 业务体验指标模型字段：

维表关联：需求是视频业务，有些字段能表示业务属性，比如 servname , 通过 servname 关联业务大小关联业务大小类维表 dim_service_type ，得到业务大类

汇聚计算：比如，HTTP 业务 TCP 下行 RTT 总时延字段，通过 sum(if TCP_STATUS=0 then RTT_DL else 0 end) 来统计 HTTP 业务的 TCP 下行 RTT 总时延；

HTTP 业务 TCP 上行 RTT 总次数字段的汇聚计算，通过 sum(if TCP STATUS=0 then RTT DLNUM else 0 end) 来统计 HTTP 业务的 TCP 上行 RTT 总次数。

DWS（数据服务层/Data Warehouse Service)

DWS 模型基于 DWD 的基础数据，是数据仓库的上层，将计算得到的业务数据整合汇总，成为某一主题域的数据服务层。一般是宽表，用于支撑后续的业务查询、OLAP 分析、数据分发等。

这一层的模型可以依赖多个 DWD 模型，也可以依赖其他的 DWS 模型，具体依赖方式取决于主题域的业务含义。同时，这一层的模型可以进行不同粒度的汇聚，以方便上层查询。

主要职责：

• 构造宽表，汇集主题内所有业务数据

• 按照不同业务粒度进行进一步汇聚

比如，以下的用户-小区数据业务模型字段摘选：

• dws_user_cell_h : h 就是 hour，支持从小时的粒度查询

• dws_user_cell_d：d 就是 day，从天数的粒度支持查询

ADS （数据应用层/Application Data Service)

最后到了数据模型的最上层，ADS 模型主要是提供数据产品和数据分析使用的数据。可以基于 DWS 提供的各领域业务模型进行灵活定制。ADS 模型层通常是变化最频繁的。

主要职责包括：

• 提供精细度更高的业务数据

• 面向灵活需求，快速开发

针对某省视频类 KQI 指标(ads_ms_video_d) 模型字段：

视频业务下行 rtt 时间 0~ 50 毫秒占比，统计方法为：

1. 计算视频业务下行 rtt 时间 0~50 毫秒次数：sum(video_dl_rtt_0_50_num)
   

2. 计算视频业务请求次数：sum(video_xdr_count)
   

3. 最后得出视频业务下行 rtt 时间 0~ 50 毫秒占比：video_dl_rtt_0_50_num/video_xdr_count
   

因为这里统计的是天粒度，所以数据来源表为上层的 dws_user_cell_d 模型。

维度表（Dimension Table）

最后介绍了维度表，维度表用于事实表中的一些细分字段和它们的上层业务含义关联起来，为数据分析提供各类角度。

举如下例子：

为了支持分省查询主题数据，通过某种方式关联，在详单中查找省份键 vprovince 字段：

通过详单的 servname 取到业务类型 service_type，就可以取到哪些详单是我们的视频业务：

逻辑模型讲到这里，接下来介绍物理模型如何设计。

2.3 设计物理模型

物理模型设计

物理模型设计师为了补充逻辑模型中缺少的特定技术上下文。需要根据实际业务场景，技术能力进行设计。

比如上图中：

• ods_rtt_h 模型的数据源来源于 HDFS 和 Kafka，最终加载到 SparkSql 中，因此有三个数据，所以我们需要基于 ods_rtt_h 这同一个逻辑模型设计三个不同的物理模型。

• 其他数据上层模型都是存储在 SparkSql 中，因此不需要设计多个物理模型

然后看到数据粒度——小时/天，也是根据模型的业务逻辑来设计的，以小时为主，到了 dws 层为了满足不同的需求，设计出：以小时为主的模型 dws_user_cell_h 和以天为主的模型 dws_user_cell_d

分表/分区也是和物理的存储技术息息相关，为了高效的查询和计算，按照天/小时/省份查询的需求，所以设计分区字段 date_id 、hour_id 和 prov_id

老化时间也是一个比较重要的属性，数据仓库的存储空间有限，对于底层模型来说，数据量大的老化时间越短，高层模型的老化时间更长 N days。

物理模型设计总结

• ODS 模型需要关注集成业务数据的数据源，可能会有多种异构数据源。

• 低层的模型，由于数据量较大，应该使用存储大量数据能力更强的存储介质，而老化时间应该设得更短

• 高层的模型，数据量相对较小，甚至可以使用普通事务型数据库存储，老化时间可以更长

• 为了提高数据处理、查询性能，应设计合适的索引/分表/分区策略，使用恰当的存储格式

设计完物理模型之后，可以进行数据流的设计。

2.4 设计数据流

数据流设计基于物理模型设计进行，根据模型的数据源、粒度、映射逻辑等属性，补充数据流必要的技术细节。

1. 使用的引擎主要由数据源和数据处理周期决定

• ODS 流程从 Kafka 和 HDFS 接入数据，且持续接入，持续处理适合使用流处理引擎

• 其他流程的执行周期批次最短在一小时，因此适合使用批处理

1. 由于数据接入延迟等原因，批处理流程在处理数据时应有适当周期和时延，时延和调度相关

2. 根据模型映射逻辑简单说明需要使用到的算子：抽取算子（来源：从哪获取数据）、转换算子（连接、分组、转换、联合等）、加载算子（目标数据源：SparkSQL 加载）

3. 具体的字段映射关系，转换/统计公式等设计，已由逻辑模型承载

3 使用 DataFactory 开发模型和数据流

3.1 开发逻辑模型

模型可以单独使用一个工程管理，也可以和流程结合在一个工程中

• 对于低层的稳定业务模型，使用单独工程管理可以方便权限控制，统一修改等

• 对于上层容易变化的模型，可以和流程放在一个工程中。按照具体的需求进行工程划分，使得维护与演进更灵活

在模型管理中创建逻辑模型，确定字段名称与数据类型，如图：

3.2 配置数据源

根据需求配置各类数据源，数据源承载了存储、计算资源的物理信息，较为稳定。一次配置，长期使用

如图：

3.3 开发物理模型

1. 基于逻辑模型创建物理模型

2. 物理模型的列结构由逻辑模型自动生成，但需要注意部分字段类型需要手动调整（如日期类型），如图：

1. 创建物理模型时，针对不同的物理数据源，配置物理信息，如主题、文件路径、分区信息、老化周期等，如图：

3.4 开发数据流

1. 基于模型，映射关系和数据流设计进行数据流设计

1. 完成数据流开发后，需要进行计算集群配置，提供集群数据源，资源分配等信息

1. 根据数据流设计，开发流处理、批处理、统一调度流程，并配置调度时间

4 开发实战演练

回顾全文中介绍的数据应用全景：

实现新需求：按小时粒度，统计某省（PROV_ID=666）TCP 下行业务的平均实验，数据加载到 HDFS 指定目录

1. 首先设计逻辑模型 ADS_666_AVG_DELAY_H：包含日期、小时、省分区、视频下行平均时延 4 个字段，定义好类型 VARCHAR(255)、VARCHAR(255) 、NUMERIC(18,0) 、NUMERIC(18,8) ，对应到 HDFS 物理数据类型为：string、string、long、double 类型 。

2. 设计物理模型：按照业务逻辑来设计。数据粒度为小时；不涉及分表分区，老化时间为不老化

3. 设计数据流：使用引擎为批处理，周期为小时，无时延，抽取算子为 SparkSql 抽取，转换算子包括过滤，分组和转换，加载算子为 HDFS 加载

环境实操：

1. 登录

1. 创建逻辑模型

1. 输入实体名称

1. 编辑属性信息

1. 保存并发布，逻辑模型创建完毕

1. 创建物理模型

创建成功后，会看到一个刚刚创建的物理模型：

1. 创建数据流

1. 在线调测，得到最终想要的结果

5 总结

5.1 开发数据应用的步骤

回顾本文开发数据应用的步骤：

1. 业务背景和需求分析

2. 设计数据模型和数据流

3. 开发数据模型和数据流

4. 在线调测快速验证数据流

5. 打包为应用，安装运行

5.2 为什么使用数据编排开发数据应用

1. 一站式数据开发，模型、数据源、数据流开发在同一个页面完成

2. 低代码拖拽式开发，上手简单、功能强大

3. 模型与流程可以沉淀为资产，方便复用及二次开发

4. 使用在线调测，快速验证数据流功能

最后，本文介绍了华为云大数据平台 DataFactory 典型案例开发，从需求、设计到实践演示完整的开发流程，完成简单高效的开发。

本文参与华为云社区【内容共创】活动第 19 期。

https://bbs.huaweicloud.com/blogs/370132

任务13：GDE直播公开课：学了这么多理论，该上场实战了