大众点评ETL数据传输平台需求用例分析

1.1 功能分析

1.1.1 调度系统

 

              图 3.1  调度系统用例图

调度系统负责ETL数据传输平台的运行、监控和资源分配（如图3.1）。

1) 定时调度。ETL任务无论是抽取还是转换类型都必须每天在特定时间（一般是晚上）被调度起来完成当天增量数据的传输，所以一般ETL传输平台必须有定时调度的功能。

2) 支持集群和并发。现在工业生产环境单机性能已经不能满足大中型企业的ETL需求，所以ETL传输平台必须能够运行在多台机器上，数据的抽取和写入目标表一般是ETL任务的时间瓶颈所在，加入并发机制能够大大缩短ETL任务时间，提供资源的利用效率。

3) 监控和日志。ETL任务抽取和转换过程中很可能出现部分失败或者超时现象，甚至异常终止也是常见的。或者数据ETL的结果存在错误与源数据并不一致。一个好的数据传输平台必须有好的告警、日志机制。并且每个任务都要数据一致性检查和部分失败容忍度，不合格则认定此次任务传输失败。

4) 资源管理。无论是执行机资源还是公共资源如Hadoop集群，Hive和Mysql等，他们的量或者并发数都是有限的，调度机在给准备运行的任务分配资源时，必须检查资源是否超过一定的限度，否则一旦任务依赖的资源超出限度，容易引起大批量的任务运行异常。

5) 任务隔离。任务运行环境是共用执行机环境，当一个耗资源的任务在运行时将会极大的影响其他任务运行，这对中小任务来说是不公平的（因为没有证据表明数据量大的任务重要性就高），而且ETL任务时间要求并不是那么紧迫。所以任务的运行环境隔离是非常有必要的。

1.1.2 数据交换

 

图 3.2  数据交换模块用例图

数据交换模块负责ETL传输平台的数据同步（如图3.2）。

1) 异构连接：数据交换模块应该能够连接到绝大部分的种类的数据源和文  件格式并提供以下的基本功能：从各种关系型和NoSql数据库获取数据，如常见的Mysql、Oracle、Hive、Hbase、Redis等;从有分隔符或者固定格式的文本文件中获取数据，如Hive Text文件或者Lzo文件，Hbase的Hfile，前后端的日志文件等。此外，有的ETL工具还能够从办公软件中获取数据，但在国内这一般能通过以上两种方式解决。

2) 数据同步：数据交换模块应该能够在不同数据库之间同步数据。同步时数据传输方式有增量传输和全量传输方式。增量传输方式依赖于CDC（增量数据捕获）机制，CDC的实现有基于自增字段或时间戳字段等。

3) 合理分片。数据交换工具由于要运行多线程技术读写数据，就必须更具数据源和目标的类型特点进行读写任务分片，合理的分片机制能够有效提高数据交换的效率。

4) 预、后处理。在数据传输开始之前，我们必须先做一些如连接、数据源是否有有效数据等检查工作。写入数据目的地之前、我们必须先连接然后清理目标库中可能与本次传输重复的数据然后再写入。写入完成后，在做一些如中间表清理等工作。这样才能保证多次重复传输不产生一致性问题。

5) 过程统计。一次数据传输是一个复杂的过程，只有对整个数据传输过程进行监控并有效统计才能了解任务传输实时状态、总体情况和数据量大小。特别的，一次传输任务是否成功也要根据读与写成功的行数之差是否在可容忍的范围内判断。

1.1.3 开发前台

 

图 3.3  开发前台模块用例图

开发前台模块负责ETL解决方案的任务设计、实例状态查询、代码上线、日志查看等（如图3.3）。

1) 任务设计：任务设计就是在图形化界面上配置ETL任务。这里的任务或者是一次传输、或者是一次转换（这里转换可以是多个转换的组合）。还可以配置多个上下游任务组合成任务流，一个任务流对应一个完整的ETL过程。

2) 代码上线：一般的ETL解决方案的代码通过用户的设计的任务自动生成，但是对有专业数据团队的来说，除了传输类型的任务、任务的代码可以自己编写脚本实现，然后上传到我们的执行机上。

3) 任务管理：用户可以查看和修改自己的任务配置，修改后的配置只对任务的下次运行生效。由于任务在企业里是团队级别的，所以你还可以查询同一团队的任务。

4) 实例管理：用户可以查看实例及其上下游的运行状态，如果运行异常，还可以查看实例的运行日志进行调试。同时用户可以对实例进行管理，如挂起，重跑置为成功等。

5) 任务预跑：任务运行起来有两种可能，一种是到指定触发时间被调度系统调度起来。二是预跑模式。即立刻被调度系统调度而不等待。这种运行模式主要是为了一次补足历史数据，这种运行模式数据的传输方式是全量传输。

6) 工作流的强、弱依赖。工作流里的任务上下游关系具有强依赖关系和弱依赖关系两种。强依赖关系的任务之间的执行顺序必须予以保证，弱依赖任务关系的任务之间的执行顺序只是建议保证。弱依赖用于有非必需数据的任务依赖关系。

7) 用户权限管理。用户在开发前台进行数据开发必须申请成为平台开发者，有些功能由于涉及数据安全或者紧缺资源还必须区分管理员权限和一般开发者权限。

8) 元数据管理。元数据管理是任何ETL工具都必须具有的基本功能。元数据包括三种：数据元数据、转换元数据和过程元数据。数据元数据是指输入输出数据源的连接信息、字段和类型。转换元数据是指转换过程中字段与字段之间的映射规则和血缘关系。过程元数据是指在ETL过程中的统计，如传输成功、失败的行数，传输的时间以及传输的效率等。

1.2 非功能分析

一个企业级的ETL解决方案需要运行良好，除了强大的功能外，还需要满足一些非功能的因素。

1) 平台独立。一个ETL解决方案必须在任何平台上运行，包括各种操作系统等。然而要完全满足这一要求会使系统很臃肿且难以维护，因此有一个折中方案是解决方案的Client端平台独立，但Server端的生产环境统一使用Linux集群。

2) 设计灵活性。ETL解决方案是为了提高ETL团队的开发效率，但如果过于自动化而忽略了现实的复杂性，固定的套路可能使你的工具脱离生产实践而备受限制，最后被淘汰。

3) 拓展性。任何一款ETL解决方案都不可能考虑了所有可能的因素，因此提供一个整体的框架并预留扩展的办法是明智的选择。将来你可能会有新的数据源类型、或者新的功能要加入你的解决方案，措手不及将让你的代码偏离原来的初衷而变得笨拙。

4) UI需求。完全的手工操作是笨拙的，低效的。配置和管理ETL任务提供必要的图形界面具有必要性。甚至查看日志分析调试，数据传输质量检查等工作也可以放在界面上给用户提供服务。

5) 模块低耦合。一个ETL解决方案可以由多部分构成，如果各部分耦合太高，对一个部分进行改进和升级就要对整体进行替换，这大大提高了升级和维护的成本。因此如果ETL平台各部分耦合较低，则可以由专门团队维护，升级一个模块对其他模块并无影响，这就有效提高了开发效率和降低了维护难度。

6) 高效传输。虽然ETL解决方案是非业务系统，对传输速度的要求比不是特别高。然而传输速度的提升还是很有意义的，它能够有效的提高集群等计算机资源的利用效率，提高数据平台各项数据工作的效率，因此一个好的ETL解决方案必须有较高的数据传输和处理效率。

1.3 本章小结

本章主要是根据上章的流行传输方案的介绍，并结合该企业的ETL需求的具体情况，对互联网企业典型的ETL传输平台的功能性需求和非功能性需求进行了描述。