Skip to main content

面向微服务的ETL用例设计

3 面向微服务的ETL用例设计

​ 根据前面第二章的规划,我们将首先介绍如何设计一个面向微

服务的ETL工具。 下面我们将详细说明一下相关的用例模型,和分析模型。

3.1 ETL工具用例故事

考虑到实现的简洁性,我们归纳的用例故事如下:

假设一个财富银行,他在一个城市有多个营业网点,在一个营业网点中,有客户来存钱和取钱,每一次交易会生成一张ticket,其中包含了交易时间,流水号,操作员,客户,交易类型,交易金额的资讯。 交易完成以后,交易的ticket 会生成一个文件,放置在FTP接口上。

为了及时的掌握各个营业网点的的交易情况,财富银行的中心机房会每15分钟从一个营业网点的FTP 接口机上提取前15分钟周期上的所有交易清单,并汇总为1张15分钟粒度的交易报表。

而我们的用例故事会集中在中心机房处理部分,我们做出如下的假设:

1,在中心机房的临时文件夹中,保存了CSV格式的交易清单。

2,对CSV格式的数据进行处理,提取其中需要的信息结构,生成临时结果文件,并将临时结果文件,拷贝到待装载文件夹下。

3,将待装载的结果文件,拷贝到数据库当中去。

相关的应用模型见下图所显示:

use case story ETL

图 3-1 用例故事

3.1.1 用例描述

下面将从对整个用例的事件序列进行描述:

1、 getter扫描临时文件夹(Temp file directory),发现新到达的网点交易文件,将新到达的网点交易文件拷贝到处理文件夹中(handle file directory),并将拷贝的网点交易文件文件记录信息,传入到数据库中的filelist表中。

2,getter 协调handler(同步或者异步通知) 对新到达的网点交易文件。

3,handler 负责处理新到达的网点交易文件,提取其中的有用的信息结构,生成结果文件。

4,handler 将结果文件拷贝到装载文件目录下(load file directory),下,并通知loader(同步或者异步通知)新到达的结果文件。

5,handler删除已经处理过的网元交易文件。

5, loader 负责处理新到达的结果文件,将结果文件拷贝到数据库中。

6,loader负责更新数据库中的filelist表,记录当前文件的处理完成时间。

7,loader 负责删除已经处理过的结果文件。

3.1.2 领域对象简述

XML ticket

相关的交易记录的对象模型。

交易序号交易时间交易网点操作员编号客户id客户名称交易类型交易金额
tac-0022.02E+11QLRop01cu01张三deposit5000
tac-0022.02E+11QLRop01cu01张三deposit5000

3.2 IPO 分析

下面将相关的IPO处理简要描述如下。

3.2.1 输入数据(I)

​ 为了简化问题的分析,我们假设在待处理文件目录下产生了3张ticket清单。分别是

QLR2019020710-001.csv

QLR2019020710-002.csv

QLR2019020710-003.csv

三个输入文件的路径均在一个特点路径下

每张清单对应的信息结构见下图所显示:

information model of ticket

​ 图3-1 银行交易单包含的信息结构

在这里,我们假设交易发生在银行是财富银行的QLR (青年路)网点

输入的文件如下:

3.2.2 启动程序的入参

入参1: 处理文件夹

在启动程序的时候,输入处理依赖的文件路径信息,相关的的入参为

1、 临时文件夹(Temp file directory)

2、处理文件夹(handle file directory)

3、装载文件目录(load file directory)

入参2: 期望输出的表名

bankticket

1.2.3 处理过程(P)

同用例的处理过程。

3.2.4 输出数据(O)

将原输入的CSV文件,全量拷贝到数据库中,通过表来保存。

其中表名来自入参。

3.2.5 返回值(return value)

程序执行以后,提供以下返回值。

1, 程序执行结果,成功返回0 ,失败返回 1;

2,如果执行成功,则反馈 [ insert table name, number of file handled, number of record inserted]

3,如果执行失败,则反馈错误的原因。

3.3 分析模型

​ 以上的case 是非常简单的一个case,但是却蕴含了大数据处理中最重要的一个ETL过程,在真实的项目中,和这个案例的区别是在于, 数据的规模大小不同,消耗的处理机资源各不相同而已。所以,我们需要相对透彻的钻研这个项目,理解一种面向微服务的设计模式。

ETL-component view

​ 图 3-2 面向对象的ETL 分析方案

从上图可见,在本案例中,将实现7种不同的实现方案。

下面将主要的方案说一下

1,sync OO ETL: 这个方案下,用于实现ETL处理的多个组件,采用的是紧密耦合的方案,如果组件1需要调用组件2,必须由组件1显式的来指定。

2、Async OO ETL :在这个方案下,用于实现ETL处理的多个组件,采用的是松散耦合的方式, 如果组件1需要调用组件2,组件1只需要发出调用的请求,具体哪个组件来处理,则由系统来决定。

​ 从上面的两种方案来看,虽然都是面向对象(Object oriented)的方案,但是有明显的区别。

1,采用sync OO ETL的好处是在于,整个方案的设计与实现非常简单, 但是当数据规模比较大的时候,这个方案处理效率不高,难以实现在多台机器上水平扩展。

2、采用async OO ETL的好处是在于,整个方案的设计与实现比较复杂,但是当数据规模比较大的时候,整个方案的处理效率高,花费硬件小,容易在多台机器上水平扩展。

3.4 再说“velocity”难题

​ 在大数据处理的四大难题中,“velocity”难题是很困难的一个问题,因为需要处理的数据管道非常大,而可用的物理计算机的资源非常的有限,如何通过有限的资源,在给定的时间内,将数据管道中新到达的数据处理完毕,直接决定了大数据项目处理实施成败的效果。

​ 所以决心进入大数据处理领域的工程是,首先要能够有信息处理好这个问题,而根据专家的建议,就是要能够方便的把数据处理的ETL任务,部署到多台服务器上,并充分利用服务器的CPU资源,实现高效的处理。 那么如何能够实现高效的处理呢? 这就需要我们采用async OO,也就是基于异步处理的面向对象的设计方案,设计出多个独立的原子组件,并明确原子组件之间的消息操作接口。 然后根据应用的特点,为不同的原子组件,配置需要的计算资源,整理起来以后就可以胜任高效ETL处理的目的。

​ 如果应用逻辑发生改变,部分原子组件需要调整,只需要个别原子组件的软件处理逻辑和硬件资源进行调整,就可以很方便的实现,能力的扩展。

3.5 微服务与大数据处理

​ 虽然微服务和大数据处理没有必然的联系,而在低成本的大数据处理方案中,为了实现充分利用硬件的目的,必须要合理的做微服务的拆分处理。

​ 所以,要打造一个成功的大数据处理方案,微服务是必要的设计技能。

Starter
MicroServ
Tutorials
Blog