电网大规模数据仓库的数据接入研究与设计

李子乾 王乐之 张云志 张旭坤

1(国家电网公司客户服务中心 天津 300000)2(南瑞集团有限公司(国网电力科学研究院有限公司)江苏瑞中数据股份有限公司 江苏 南京 210000)

0 引 言

近年来，随着售电侧开放实施，电网业务得到迅速发展，相关的业务数据也呈现出了爆炸式的增长态势。为了提升运营效益、增强电网安全、提高客户服务质量、拓展新业务，国家电网公司对数据的运营发展提出了更高要求[1-2]。

根据国家电网公司“十三五”规划中“四全三化” 信息系统体系建设纲领，未来将建成“模型规范统一、数据干净透明、分析灵活智能”的全业务统一数据平台。国网客服中心(以下简称“中心”)作为供电服务业务的执行单位和营销决策的支撑机构，积累了全网客户数据和海量供电服务信息，并与电网营销、生产、运行等业务紧密关联，是整个电力系统中最为关键的一环。建设中心全业务统一数据平台，即实现中心全业务范围、全数据类型、全时间维度数据的统一存储、管理和服务，为中心实现精准营销、精准分析、精准服务、智慧化服务等目标提供数据保障，成为国网客服中心“十三五”信息化发展的重要目标。

中心全业务统一数据平台包含数据的集成、存储、分析、处理、发布等环节。本文重点关注95598全业务数据集成环节，针对海量结构化业务数据如何从原有业务系统有效地集成到大数据数据仓库的问题，结合实际场景，提出了一种将数据同步复制、ETL等数据接入技术相结合的解决方案。该方案能够满足多种业务应用需求，并保障数据接入过程中尽可能地减少对源端系统的影响。

1 业务数据类型分析

电网业务结构化数据包括：工单类数据、档案类数据、运营管理类数据、话务类数据、营销类数据、常识类数据等。数据规模之海量在国内外现有数据中心中尚数首例，对这些数据的整合极具挑战和开创性。

将数据从源系统接入和存储到数据仓库的过程中，必须要保证数据的正确性和完整性，同时还需要保障数据进入到新的环境中后能够满足所有业务的使用需求。此外从优化存储的角度应当具备除了冗余备份的需求以外，数据不应该存在重复存储。这就要求我们从存储的角度对业务数据再进行一次分类。

经过对业务数据的全面调研与分析，结合数据接入与存储的技术实现，我们将所有业务数据分为如下三大类：

1) 单纯增长类 此类数据表只存在插入操作。数据一旦插入到数据库中之后，将不会发生变更。此类表主要有：实时增长的话务表、定时增长的归档表、不定时增长或无增长的常量表。

2) 全更新类 此类数据表存在全部的增删改操作。在插入和删除方面，这些操作可能是实时的、定时的或不定时的，但在修改方面，只存在实时与不定时的修改，并不存在定时的修改操作。

3) 短期归档类 此类数据定时产生批量的增删操作，无修改操作。以工单表为例，某一种业务工单的记录表在存储方面会分为三张表存储：在线工单表，存在实时的插入、修改和定时的删除操作，属于全更新类；长期归档表，只存在定时的插入操作，属于单纯增长类；短期归档表，只存在定时插入和删除操作，每天在线表中完成的工单记录将从在线表中删除并插入到短期归档表，同时短期归档表中超过时限的记录将删除并插入到长期归档表。

2 大数据存储技术简析

2.1 数据仓库

数据仓库主要用于处理复杂的分析计算，并且提供直观易懂的查询结果来支撑决策。在大数据领域，现有的两大数据仓库为大规模并行处理MPP(massive parallel process)与Hive。它们各有优劣，适用于不同的场合。

MPP架构的新型数据库集群[3]，重点面向行业大数据，采用不共享架构，拥有高效的分布式计算模式，每个节点运行自己的操作系统和数据库。通过scan、sort和merge等操作符相对于使用MapReduce框架的Hive，能够更加实时地返回查询与计算结果。在企业BI分析、报表计算、查询分析等分析类应用领域有着极其广泛的应用[4]。

Hive相对于MPP在计算速度上存在劣势，但它的优势在于所依托的Hadoop体系，适用于更加复杂的数据挖掘、机器学习和计算模型等应用领域[5]。

综上所述，MPP能够更好地帮助企业回顾过去，而Hive能够更好地帮助企业展望未来。在中心的全业务统一数据平台中将同时使用这两种数据仓库。本文所研究和设计的也就是如何给出一个切实可行的方式，将原有业务系统关系库中的海量结构化业务数据高效地接入这两个数据仓库中。

2.2 关系数据库

关系数据库主要用于基本的、日常的事务处理。在大数据体系架构中，当前主要使用的关系数据库为Mysql与Postgresql。

Postgresql与Oracle的存储架构最为接近，从Oracle将数据迁移到Postgresql中的成本很低[6]。但随着Mysql版本的不断提升，Mysql在互联网行业积累了大量的高可用架构、分布式架构与灾备经验[7]，其集群模式在功能性与性能方面都已经超过了Postgresql，并能够与Oracle分庭抗礼。当前企业的关系数据库集群越来越青睐使用Mysql存储事务用业务数据。

然而Mysql在高并发读写方面仍然存在一定的瓶颈，当数据量很大时Mysql的查询效率会变得很低，这也使得Mysql不适用于存储与查询大规模的业务数据。在中心的全业务统一数据平台的设计中，Mysql仅存储短期业务数据，用来支撑一些在线事务类业务应用。在此设计下，Mysql实际上也可以看作是一个缓存了近期数据的缓存库，我们考虑在将数据接入数据仓库的过程中，利用Mysql提供一些支撑。

3 复合式数据接入设计

3.1 系统架构概况

在国网客服中心全业务统一数据平台的建设中，需要接入的数据源端为生产环境中的多个Oracle集群。每个集群分别属于不同的系统，每个系统与多个业务紧密关联，支撑着电网营销、生产、运行中的各个环节，其安全性要求极高。从源端数据库获取数据时应保障对源端的影响最小，不能造成源端数据库运行缓慢，不能影响正常的业务生产。

数据接入的目标端为大数据集群。该大数据集群为广义上的大数据存储、处理与分析集群，包括Hadoop体系、MPP数据仓库、关系数据库以及相关的计算分析组件和数据流转组件。本文重点考虑的需要接入数据仓库的数据为各系统全量结构化业务数据。数据存入大数据集群后，需要能够同时支撑事务查询、BI分析、报表计算、查询分析、数据挖掘、业务预测等多种业务应用。这些数据具有表数量多、种类复杂、表中数据量大等特点。其中表数据的种类已经在第2节中作了阐述。在表数据量方面，约有4 000多张。在表数据量方面，单表中的数据量可达到8亿左右，总表数据量为PB级别。

此外，源端数据库与大数据集群为异地部署，数据传输方面受到距离的影响，存在一定的延迟。

3.2 数据接入方式分析

参照中心业务需求的不同，目前数据接入的方式主要有：ETL(Extract-Transform-Load)方式、数据库同步复制方式、文件导出导入方式。

3.2.1 ETL方式

ETL即数据抽取、转换、加载方式[8]。首先在数据抽取阶段将数据从源端读取出来，该过程使用源端数据库适用的读取方式进行读取，就目前常用的Oracle、Mysql等结构化数据库，通常采用jdbc方式进行读取。数据读取出来后，在数据转换阶段会将源端数据经过适当的加工与转换，使得数据满足目标端的存储需求，最终在数据加载阶段将处理好的数据加载到目标端数据库。

中心的源数据库为Oracle，采用ETL方式进行数据接入时采用的是jdbc连接。然而异地数据传输所产生的延迟对于jdbc连接访问会造成较大影响，当延迟过大时jdbc连接会因超时而断开。因此，在中心异地数据系统之间若采用基于jdbc方式读取数据，会存在不稳定问题。另一方面，ETL本身不具备实时数据抽取的功能，这一特点也是在本文所考虑的数据接入方案中需要注意的。

3.2.2 数据库同步复制方式

同步复制方式即实现数据在两个数据节点之间实时地保持一致的一种数据备份复制方式。目前在Oracle数据库集群环境中被广泛使用的同步复制软件为OGG(Oracle Golden Gate)。而对于异构数据库系统，OGG同样能够发挥其作用，实现大量数据亚秒级别的实时复制，且可以实现一对一、一对多、多对一、双向、点对点、级联等多种灵活的拓扑结构[9-11]。

采用同步复制方式能够保证中心全业务数据接入大数据集群后能够与数据源实时保持一致。然而其存在的问题在于大数据量初始化时会存在一定的困难。初始化时间将会比较长，此时间内会对数据库形成持续的访问压力，且一旦初始化过程中因网络或设备等原因造成了中断，则意味着所有数据要重新进行初始化。此外，OGG方式仅支持关系数据库之间的数据同步，无法做到与数据仓库之间建立数据同步。

3.2.3 文件导出导入方式

文件导出导入方式即先将源端数据以文件形式从数据库导出，再通过FTP等文件传输方式传输到目标端，再在目标端将文件导入到数据库中。

该方式适用于大批量数据一次性从一个数据库快速复制到另一个数据库中。但该复制过程是异步的，无法保障源端与目标端实时保持一致，且跨系统之间的文件导出导入过程中需要人工参与，同时做好敏感信息的保密工作。

3.3 存量数据接入设计

存量数据只需要一次性接入。考虑到其存量巨大，若直接采用ETL方式，则效率太低且异地数据传输时稳定性差。因此，我们选择将存量数据先采用文件形式从源端导出，再导入数据仓库所在本地系统。由于源端与目标端为异构数据库，且依据生产环境的运行规定，源端只允许导出dmp文件，因此需要在数据仓库本地部署一个小型的Oracle数据库作为数据中转站。将源端导出的dmp文件导入此Oracle中，然后再使用ETL方式从此Oracle将全量数据抽取到数据仓库。整个过程如图1所示。

图1 存量数据接入示意图

存量数据接入的全过程总结如下：

1) 源端业务系统将所需接入的表导出为dmp文件，同时记录存量数据范围，作为区分存量数据与增量数据的依据。

2) 将导出的dmp文件通过文件传输方式发送到目标端中转数据库所在服务器。

3) 将dmp文件导入目标端中转数据库。

4) 使用ETL方式将目标端中转数据库中的数据导入MPP数据仓库。

5) 导入成功完成后删除中转数据库中的数据。

6) 重复1)～5)的步骤直至完成所有表存量数据的接入。

3.4 增量数据接入设计

增量数据的接入需要考虑接入的频率。对于事务型查询的需求，数据要求是实时或准实时(分钟级)的，但查询的数据时间范围较小，通常不超过1年。对于BI分析、报表计算、查询分析、数据挖掘、业务预测等离线计算的场景，则只要增量数据满足离线计算的计算间隔即可，通常这个时间间隔按天或者按月计算，但查询的数据时间范围较大，最大可以达到全量级别。

鉴于这样的数据访问需求，我们使用Mysql作为增量数据接入MPP数据仓库前的缓存数据库，在此Mysql中缓存1年的数据以同时支撑事务型查询的需求。为了满足数据实时性的要求，我们采用OGG方式将数据从Oracle同步到Mysql，然后再用ETL方式根据离线计算场景的最小时间间隔将增量数据从Mysql抽取到MPP数据仓库中。

由于OGG方式要求源端与目标端数据表应保持一致，而我们在Mysql中不会存储与源端Oracle中相同的全量数据，因此OGG过程中需要对目标端做一些额外的处理。

我们通过OGG把日志解析成只有insert操作的日志，并在目标端数据表增加增删改的标识字段(增标识：i，改标识：u，删标识：d)，同时添加时间戳字段。

示例如下：

1) 用户删除一行记录，则把该被删除的行写入到目标端的Mysql表中，更新该记录增删改标识为‘d’，同时更新该记录变更的时间戳。

2) 用户修改一行记录，则把修改后的记录写入到目标端的Mysql表中，更新该记录的最新值，更新增删改标识为‘u’，同时更新该记录变更的时间戳。

3) 用户插入一条记录，则把该行记录写入到目标端的Mysql表中，新增记录并在该记录添加增删改标识为‘i’，同时添加记录被插入到数据库的时间戳。

只有OGG同步复制过程中能够从归档日志中读取到的数据，才可以添加到增加的字段中。本设计方案中，增删改标识和时间戳均可以从归档日志中获取，因此增加这两个字段是可行的。增加字段的示意图如图2所示。

图2 OGG过程中增加字段示意图

该同步复制策略的特点如下：

1) 目标端Mysql可以只保存近期一段时间内的数据，不用缓存全量数据。

2) OGG在做update和delete操作时不会因为目标端缺少数据报错。

3) 不需要做源业务系统到mysql数据库的数据初始化工作，即mysql中不需要存储源业务系统的历史数据。

增量数据进入到Mysql中后，将数据通过ETL方式做简单的清洗转换即可很方便地将数据抽取到MPP数据仓库中。该清洗转换的核心工作在于将Mysql中的数据解析后在MPP数据仓库中进行数据更新。该过程具体设计如下：

1) 针对每一张表，逐行读取抽取区间(依据每次ETL抽取的时间间隔所选定的时间区间)内的每条记录。

2) 对于增删改标记为‘i’的记录，将其解析为在MPP数据仓库中可执行的一条insert语句。

3) 对于增删改标记为‘u’的记录，将其解析为在MPP数据仓库中可执行的一条delete语句和一条insert语句。

4) 对于增删改标记为‘d’的记录，将其解析为在MPP数据仓库中可执行的一条delete语句。

5) 将每条解析后的语句按顺序在MPP数据仓库中执行，从而完成数据更新。

由于数据通过OGG方式同步复制到Mysql的时候，所有数据库操作已经是按时间戳逐行插入的，从而在逐行解析过程中并不需要进行额外的排序工作。

整个增量数据接入过程如图3所示。

图3 增量数据接入示意图

增量数据接入的全过程总结如下：

1) 通过OGG方式将源端Oracle中数据同步复制到Mysql中，OGG过程中添加增删改标识、时间戳字段。

2) 定期通过ETL方式将数据解析转换后存入MPP数据仓库。

3.5 Hive中数据的接入

针对数据挖掘、业务预测等业务场景，需要将数据接入到Hive中进行计算。Hive中只需要存储计算需要用到的数据。根据业务需求在MPP数据仓库中对全量业务数据进行轻度汇总和重度汇总形成若干数据集市后，无论存量数据还是增量数据，都采用ETL方式(例如sqoop等)将数据分批接入Hive中即可[11]。

4 实验与验证

本方案的核心和瓶颈在于3.4节的增量数据接入部分，因此本次实验针对增量数据接入场景搭建环境并进行了实验。环境中中包含一个Oracle集群、一个Mysql集群、一个MPP数据仓库集群和一个Hive集群。各集群概况如表1所示。

表1 增量数据接入实验环境

在Oracle向Mysql数据库进行数据同步时观测各类型数据量、源端与目标端服务器性能数值如表2所示。

表2 Oracle向Mysql数据同步实验结果

在Mysql向MPP数据仓库解析接入时观测各类型数据量、源端与目标端服务器性能数值如表3所示。

表3 Mysql向MPP解析接入实验结果

综合上述实验结果，数据能够高效而准确地同步且对源端和目标端服务器性能影响较小，满足中心信息系统实时业务响应速度需求和安全运行需求。

5 结 语

在信息发展速度越来越快的今天，传统数据库架构已经越发难以满足更加复杂、更加多样化的业务需求，包括电网在内的各大行业正在积极开展传统数据库架构向大数据技术下数据架构的转型工作。其中一大重点和难点在于如何有效实现从传统数据库向大数据技术下数据存储载体进行的数据迁移。在这方面，数量最多需求最大的就是结构化数据从传统数据库向大数据数据仓库迁移的问题。

本文分析了国网客服中心在建设全业务统一数据平台过程中的数据与业务需求。结合现有系统的客观条件，提出了ETL、同步复制、文件导出导入相结合的复合式数据接入设计方案。经过实验验证，该方案能够有效实现异构数据库之间的数据流转，且在存量数据接入和增量数据接入两个环节均能将对源端生产系统造成的压力降至最低。同时通过Mysql关系数据库、MPP数据仓库和Hive相结合的方式满足事务查询、BI分析、报表计算、查询分析、数据挖掘、业务预测等多种业务应用。本文方案是一种切实可行且具有较高应用价值的数据接入方案。