ETL处理流程与技术架构

1. 数据集成和ETL

随着移动互联网、云计算、物联网等信息技术的飞速发展，越来越多的数据被产生，整个社会正在加速进入了“大数据”时代。对于企业来说，数据已经成为企业的财富，也是一种重要的战略资源。但在一个企业中，不同类型的数据通常是分布在若干个独立的信息系统中。以运营商为例，用户的计费和账单信息由信息化或市场部门的经营分析系统生成和维护，而用户在网络中所产生的信令和上网行为记录则由网络运维部门的网络运维系统存储。由于种种历史和现实原因，这些独立的信息系统之间缺少统一的接口，且数据结构差异巨大，造成企业内部的数据融合困难，也无法充分挖掘数据所包含的经济和社会价值。

如何将这些相互关联的分布式异构数据源集成在一起，能够让上层用户无视不同系统的数据差异，透明的方式访问这些数据，就是数据集成所要解决的问题。下图给出了一个典型的商业智能（BI：Business Intelligence）系统架构。

可以看到数据集成包含了：ETL、主数据管理、数据质量监控、元数据管理、数据生命周期管理共五大功能模块。在这个专题中，我们将依次对这些功能模块进行详细介绍，本片公众号将重点介绍ETL的主要流程和技术架构。

2. ETL处理流程介绍

ETL是数据抽取、转换和装载（Extract，Transformation，Loading）的英文简称，是数据仓库获取高质量数据的关键环节，是对分散在各业务系统中的现有数据进行提取、转换、清洗和加载的过程，使这些数据成为商业智能系统需要的有用数据。ETL是数据集成的第一步，也是构建数据仓库最重要的步骤。

下面我们以从某运维平台获取的各省RNC基础工参数据为例说明主要的ETL处理流程。

上图给出了3个省级运维平台数据库中RNC基础工参数据的字段信息。通过对比，初步发现以下问题：

• 问题1： A、B省使用了中文表名、而C省使用了英文表名；
• 问题2： A省数据内容相对丰富，但是B省和C省都有不同程度的数据内容缺失情况，例如B省缺失“NodeB数量”等字段，C省缺失“所属SGSN”字段；
• 问题3：A、B、C省相同的字段内容使用了不同的名称，例如A省的“所属城市标识”分别对应B省的“城市标识”和C省的“city_id”。A省的“载频数目”对应B省的“载波数”和C省的”freq_num”；
• 问题4：A、B、C省均存在字段名称相近，但实际取值需要转换的字段。例如A省”厂商标识”字段取值为“1,2,3,4,5”，对应B省“厂商名称”字段的“华为、中兴、阿郎、诺西、爱立信”；
• 问题5：A、C省中”Iu接口配置带宽”单位为Mbps，但B省该字段的单位为bps，为便于后续分析对比，需要进行转换；
• 问题6：由于这是RNC基础工参信息表，所以“RNC标识”字段应为非空。但在实际数据中，却存在”RNC标识”为空的无效数据，需要清洗。

2.1 数据抽取（Data Extract）

数据抽取指的是从不同的网络、不同的操作平台、不同的数据库和数据格式、不同的应用中抽取数据的过程。在这个过程中，首先需要结合业务需求确定抽取的字段，形成一张公共需求表头，并且每个省的数据库字段也应与这些需求字段形成一一映射关系。这样通过数据抽取所得到的数据都具有统一、规整的字段内容，为后续的数据转换和加载提供基础。

在上图中可以观察到，虽然B省数据库中缺少“NodeB数量”、“单载频NodeB数量”、 “双载频NodeB数量”、 “三载频NodeB数量”信息，但这些信息能够较为重要，所以依然将这些字段包含在需求字段中，只是从B省抽取的数据中这些字段内容为空。

通过数据抽取，我们可以有效的解决刚才提到的问题1-3。但是需要特别说明的是，数据抽取并不仅仅是根据业务确定公共需求字段。更涉及到从不同类型的数据库（Oracle、Mysql、DB2、Vertica等）、不同类型的文件系统（Linux、Windows、HDFS）、以何种方式（数据库抽取、文件传输、流式）、何种频率（分钟、小时、天、周、月）、何种抽取方式（全量抽取、增量抽取）获取数据。所以具体的实现也包含了大量的工作和技术难点。

2.2 数据转换（Data Transformation）

数据转换就是处理抽取上来的数据中存在的不一致的过程。数据转换一般包括两类：

第一类：数据名称及格式的统一，即数据粒度转换、商务规则计算以及统一的命名、数据格式、计量单位等；针对问题4中的”厂商标识”字段，将取值统一为“华为、中兴、阿郎、诺西、爱立信”。这样就需要对A省的该字段取值“1,2,3,4,5”根据映射关系进行数据转换；而对于问题5中的”Iu接口配置带宽”字段，则将单位统一为Mbps，这样在对B省数据进行处理时，需要对取值除以1000000进行匹配。

第二类：数据仓库中存在源数据库中可能不存在的数据，因此需要进行字段的组合、分割或计算。以运营商获取的用户上网详单为例，需要根据用户上网内容和流量类型确定用户使用的业务类型（流媒体、即时通信、下载、浏览等），生成相应字段。并对单个用户在单个小区的各类型业务流量、次数、时间进行汇总统计

数据转换实际上还包含了数据清洗的工作，需要根据业务规则对异常数据进行清洗，保证后续分析结果的准确性。问题6中“RNC标识”为空的字段将会被清除。

2.3 数据加载（Data Loading）

数据装载的主要任务是将经过清洗后的干净的数据集按照物理数据模型定义的表结构装入目标数据仓库的数据表中，并允许人工干预，以及提供强大的错误报告、系统日志、数据备份与恢复功能。整个操作过程往往要跨网络、跨操作平台。在实际的工作中，数据加载需要结合使用的数据库系统（Oracle、Mysql、Spark、Impala等），确定最优的数据加载方案，节约CPU、硬盘IO和网络传输资源。

3. 分布式ETL技术架构

传统ETL通常都是采用昂贵的ETL工具（Datastage、SSIS等）基于高性能的小型机完成。这种方式已经难以满足“大数据”时代下TB甚至PB级的数据ETL需求，如何在有限的时间内，高效高质量的完成海量数据的ETL工作，对ETL技术的架构设计也提出了更高的要求。

目前主流的解决方案是通过对传统ETL进行横向扩展，将ETL工作转化为并行或分布式的架构，从而缩短数据处理时间。目前基于分布式的ETL技术架构有以下两种：

3.1 基于多Agent方式的ETL技术架构

该方法是将多Agent系统技术⋯1引入到分布式计算环境中，该分布式ETL框架把数据抽取、数据转换和数据加载分别对应成各个Agent，同时把每一个模块比如元数据管理、作业管理和转换函数管理等各对应到一个Agent，然后利用Agent之间的协作性、主动性和交互性来构建分布式ETL框架。

上图给出了基于Agent的分布式ETL架构。其中”ETL任务设计”模块向用户提供ETL工作流的设计界面。”ETL任务管理”模块则是分布式ETL的协调中心，向上（用户）承接ETL作业的上传、转换函数的定义和日志浏览功能，向下（ETL执行）基于元数据提供ETL作业转换规则和作业调度。”ETL任务执行”模块则是具体的执行引擎，分布在各个实体服务器上。通过各个Agent协作完成ETL的任务。

这种架构可以较好的解决分布式系统中的负载均衡问题，而且也能够实现准实时的数据解析和入库。但是该方式不能较好的保证各个Agent的稳定性，一旦某个Agent出现故障，将会使整个系统处于崩溃状态，甚至有可能导致数据的丢失。

3.2 基于MapReduce的ETL技术架构

Hadoop技术在其诞生之初就是定位于大数据的存储、分析。所以在hadoop框架下基于MapReduce实现ETL也是很多企业自然而然的选择。

上图中给出了一个典型的基于MapReduce的ETL技术架构。 服务端主要包括元数据管理模块、执行引擎模块、数据访问模块。元数据管理模块是系统的基础模块，它描述了系统中所有数据结构的定义，提供元数据存储、访问的服务。系统的其他模块通过公共接口从元数据管理模块获得元数据信息。另外，元数据管理模块提供接口用来导入导出元数据。执行引擎模块是系统的核心模块，又分为流程解析和流程执行两个模块。在流程解析模块，执行引擎获取执行流程的元数据信息，根据这些信息，生成相应的工作流。流程执行模块完成从数据转换到数据解析的所有任务。数据访问模块提供公共的数据访问接口，它屏蔽了各种数据源之间的差异，以一种统一的方式对数据进行查询、删除、修改。

在基于MapReduce的ETL技术框架下，开发人员只需要Map和Reduce两个函数进行数据转换的并行处理，并基于hadoop生态圈所提供的API接口进行数据抽取和加载。这样可以提高开发效率，而且系统的并行处理能力也有成熟hadoop生态圈得以保证。但是MapReduce程序启动较为耗时，并不适用于数据的实时加载和入库，而且MapReduce作业流程的优化也需要投入大量的时间。

4. 小结

在本文中我们简单介绍了数据集成，并结合具体案例说明了ETL处理流程，并对两种分布式ETL技术架构并进行了介绍和比较。在随后的文章中，我们将基于某省级运营商的大数据分析需求，提供相应的ETL技术架构和实现方案。