Skip to main content

Python BigData Starter CP02 大数据入门训练的三大主轴

2、用例规划

1-ETL 方案

​ 图2-1 一个典型的ETL方案

​ 要理解大数据处理,首先要回顾一下传统的数据仓库的构建方案, 上图是澳洲一家电信公司的在2012年的时候的一个方案。虽然这是一个非常经典的ETL方案,但是在现代的大数据处理项目中,依然可以参考其中的设计思路。从澳洲的方案中,我们可以发现这是一个完全基于组件化集成的方案,所以全面掌握不同部分的组件选型和集成技术,就可以为自主构建低成本的大数据方案打下坚实的基础。

在本培训课程规划的用例模型中,主要会考虑三方面内容

1,经典数据中心相关的ETL流转换处理用例。

2,经典数据中心相关的数据汇总统计相关的用例,并提供两种实现模型,一种是经典的基于数据库的方案,另外一种是现代大数据中常用的内存计算方案。

3,用于支撑现代大数据中心的并行计算相关的用例。

2.1、用例总体规划

python big data trail

​ 图2-2python 大数据入门之用例模块划分

从上图可见,相关的的用例划分,主要可以划分为三大部分,分别是:

1,流转换模块(**ETL**):流转换模块负责将多个不同的数据源中提取数据,经过归一化以后处理,生成为规范的格式,以便加载到数据库当中。

2,数据处理模块:数据处理模块可以从海量的数据中,进行一定策略的聚合,汇聚成为精简的数据。

2.1 DB**数据库处理模块**: 传统的数据处理,是基于关系型数据库的处理方式。

2.2 内存数据处理模块:当数据处理的复杂度到一定的程度,则需要借助一些python框架,实现高效的内存计算。

3,并行计算模块:当数据处理的规模比较大的情况下,则需要借助一些分布式的框架来实现,其中在流转换,和数据处理模块中需要引用上述并行计算模块。

以上是本培训课件的三大主轴,可以帮助具备基础python基础知识的朋友快速养成大数据方面的处理技能。

按照上述的主轴,我们可以进一步来细化需要的用例模型。

2.2 、流转换模块

流处理基础用例

​ 图2-3 流转换基础用例模型

​ 在整个大数据处理的各项原子处理模型中,流转换是整个处理过程的基石。虽然流转换的业务逻辑比较简单,但是流处理的过程需要和多个外部接口进行协同处理,在缺乏经验的情况下,很容易出错,影响项目的进展,所以,如果立志进行大数据处理的朋友,首先需要掌握必要的流转换技能。

下面,将相关的用例进行详细的描述。

2.2.1 流转换-用例故事

流转换处理**use case** 是一组非常基础的用例,也是非常重要的一组用例。他可以支撑很多现实的应用场景,掌握了这组用例的设计方法,就可以在很多场景下实现数据采集的工作。

​ 为了帮助读者理解这一组用例,下面讲述一个用例故事,来说明流转换用例的普适性。

流转换用例故事

​ 图2-4 流转换用例故事

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

银行交易清单

​ 图 2-5 银行交易清单包含的信息结构

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

​ 中心机房根据多张15分钟交易报表,会生成1小时粒度,24小时,天粒度的报表,并将相关的报表插入到数据库当中。

​ 这个流转换模块的用例故事,虽然这个故事比较简单, 但是确是一个非常典型的应用案例,有非常广泛的适用场景。

​ 根据上述的用例故事,我们来详细描述一下相关的用例。

2.3.2 多文件2CSV

​ 当中心服务器收集到多个交易报表文件以后,为了方便后续入库处理,可以将多个交易文件合并成一个文件,用例事件简述如下:

1,timer 扫描新到达的交易清单文件。

2,timer 读取一个文件,将文件转换为存在于内存中的中间流。

3,timer 提取其中的交易信息,写入一个临时的中间流中(保存结果集的)。

4,timer 关闭第一个文件对应的中间流。

5,timer 读取后续的文件,依次提取其中的交易信息结构,并追加到一个临时的中间流中,直到处理完最后一个文件。

6,timer 将用于保存结果集的中间流转换为文件流,并存入用于保存结果集的路径下。

2.3.3 XML 文件2CSV文件

XML文件是一种具有自描述特性的文件,所以非常适合表达一些复杂的数据结构,在大数据的ETL项目处理中,必然会涉及到这一类问题的处理,这是非常常见的一个用例。 相关的用例简要描述如下:

1, timer 扫描到需要处理XML文件。

2, timer 将需要提取的信息结构的配置文件装载到内存中,作为后续识别信息结构的参考依据。

3,timer首先读取xml文件的第一行数据,加载到内存当中。

4,timer 将内存中的xml的行数据,和需要提取的信息结构的配置文件进行比对,提取需要的信息结构,并放入到一个用于保存结果集的内存中间流中。

5,timer将释放位于内存中已经处理完毕的xml行数据,继续读取下一行数据进行处理,直到处理完所有的行数据。

6,timer将用于保存结果集的中间流转换为文件流,并存入用于保存结果集的路径下,结果文件以csv的格式进行保存。

2.3.4 FTP 文件采集

​ FTP文件接口是在大数据ETL项目中最常见的一种数据共享接口,虽然目前市面上有不少FTP采集的工具,可以非常方便的基于服务器的定时调度程序来实现文件的采集处理。 但是,在商用的ETL项目中,这种方案的稳定性和容错性不高,必须要基于专用的FTP组件来实现高可用的FTP采集服务。相关的用例简要描述一下:

1,timer 定时连接到外部的FTP服务器,进入接口文件目录。

2, timer将遍历接口文件目录下的全部文件,获取文件的信息结构,并将当前文件的信息结构存入内存中的一个数组中。

3,timer将保存在持久化组件(数据库 或文件系统)中的上一次扫描的文件记录装载到内存中的另外一个数组中。

4,timer将两个数组进行比较,识别出其中增量的文件列表,作为新到达的文件列表。

5,timer根据新到达的文件列表,依次从接口文件目录下拷贝新到达的文件,保存在目标文件路径下。

6,timer拷贝完毕所有新到达文件以后,将更新的文件扫描记录拷贝到外部的持久化组件(数据库 或文件系统)中。

2.3.5 多文件压缩与解压

​ 在大数据处理的环节中,由于需要处理的原始文件,中间文件都比较大,假如不使用压缩格式的化,常常会消耗大量的硬盘资源。所以压缩格式的文件处理是在大数据ETL处理项目中非常核心的一个用例模型,下面将用例的事件模型简述如下:

1, timer 定期扫描source 文件夹,确定其中的文件的数量。

2, timer 提取一个文件,将他从文件流转换为压缩文件流格式。并写入到内存中的一个中间流中。

3, timer 继续处理第二个文件,转换为压缩文件流,并追加到内存中的中间流中。Timer继续对后续的文件进行处理,知道完成所有文件的压缩转换。

4, timer 将将缓存所有压缩文件流的中间流,转换为一个压缩中间流,并将这个中间流转换成为一个文件流。

5, timer 将这个文件流写入到send 文件夹中。

6,timer 定期扫描sender文件夹,发现其中存在一个双层打包的文件。就将他复制到receiver文件夹中。

7,timer从receiver文件夹中读取这个文件,转换为内存中的中间流。

8,timer对这个中间流进行解压缩流转换,识别出全部的子文件。

9,timer顺序对每个子文件进行加压缩流转换操作,并将加压以后的文件转换为文件流,拷贝到destination文件夹下。

​ 相关的用例故事见下图所显示:

USE case story 4 file compressing

​ 图 2-6 多文件压缩与解压的用例故事详解

2.3.6 流转换用例归一化

​ 回顾一下,前面的财富银行的流转换用例模型,我们可以详细设定一下的用例场景。

1,假设每个营业网点会根据客户交易的情况,产生客户交易单。为了保障交易单的扩展性,初始交易单是基于xml格式进行保存。每个交易产生一个xml文件。相关的xml文件放置在营业网点侧服务器的source文件夹下。

2,每隔5分钟, timer_site会定期扫描营业网点侧source文件夹下的所有xml文件,并通过双层打包操作,生成一个大的压缩文件,并将这个压缩文件放置在sender文件夹下。

3,每个15分钟,在sender文件夹下,会生成1到3个接口文件。相关的sender文件夹可以通过FTP接口访问。

4,每隔15分钟,位于中心机房服务器侧的timer_center 会启动FTP文件获取操作,将新生成的文件放置在中心机房服务器侧的receiver文件目录下。

5,timer_center将启动加压缩操作,将所有的文件加压到中心机房服务器侧的destination文件夹下。

6, timer_center将启动xml转换操作,将所以的xml文件依次转换为csv文件,并放置在服务器侧的temP路径下。

7,timer_center 将启动多个CSV文件的合并操作,合并成一个大的csv文件,并放置在loader路径下。

Normalized USE case story of stream

​ 图2-7 流转换用例模型归一化场景

从上图可见,虽然只是一个简单的数据ETL案例,也涉及到流转换模块的多个用例模型, 由此我们可以发现,流转换模块是一个非常基础,同时也是一个非常重要的用例模型。

2.3、 数据处理模块

当ETL组件将数据完成了数据的准备工作以后,我们就会针对数据做进一步的处理。

将简要介绍一下数据处理模块的应用场景。

2.3.1 数据处理的层次

7-数据处理的层次

​ 图2-8 数据处理的层次

​ 从上图可见,建造一个IT系统,基本上需要处理四个层面的问题,就是:

1,首先数据能够存储。

2,其次是利用工具可以查看到数据

3,第三是能够对数据进行各种各样的加工,产生信息。

4,第四是能够在信息中加以提炼,找出正确的内容,形成情报。

​ 一般来说,越上层的结果,对客户的价值越大,越底层的内容,对客户的价值不大。

​ 在第二章介绍的流转换用例,主要是实现将应用领域的多种格式的数据源进行整理,转换和汇集, 归一化形成可以访问的数据(data)。所以ETL组件,这样是解决数据应用的第一个层级和第二个层面的问题。

​ 而假如入要解决第三个层面的问题,也就是从海量的数据中提取方便理解信息(information),这就是数据处理模块需要解决的问题。

​ 一般来说,越是底层的处理过程,需要利用的基础框架比较分散,对IT的基础技术要求越高,对应用分析的难度比较小;而越是高层的处理过程,因为有一些通用的处理框架可以利用, 可以降低对IT的基础技术的要求, 但是因为和应用的关联性比较高,所以需求分析的难度比较高

2.3.2 数据处理-用例故事

​ 在数据处理模块中,我们主要是要实现从data 到 information 的转换过程,在这个过程中,我们其实已经开始从海量的数据中提取到数据的价值,这个过程就有点类似于蜜蜂酿蜜的过程。

蜜蜂酿蜜

​ 图 2-9 蜜蜂酿蜜与“大数据炼金”

​ 蜜蜂采集到花蜜以后,经过脱水,提炼和转换的过程,形成蜂皇浆,这个就是我们方便使用的形态。 所以回到前面介绍的财富银行的故事。

​ 前面章节已经讲过,经过流转换模块的四大用例, 我们已经可以收集到一个营业网点的在15分钟的交易清单列表, 那么作为银行总部,就希望在第一时间掌握以下的资讯。

1,一个营业网点在15分钟内交易的次数,和交易的金额数量、

2,一个特定用户在15分钟内交易的次数,和交易的金额数量。

3,上述两个报表,在每个小时和每天的统计数据。

2.3.3 数据处理-用例概述

​ 基于上面的用例故事,并结合基础的数据处理要求,我们在这个模块中需要处理的用例模型见下图。

use case model-data handling

​ 图 2-10 数据处理模块包含的用例模型

​ 从上图可见,在本阶段,我们希望能够对海量的数据进行处理,形成我们需要汇总数据。而结合上一个章节介绍的用例故事,可以提炼用例中包含的领域对象模型。

Domain object model of  data handling

​ 图2-11 银行数据处理模块包含的领域对象模型

​ 结合上面的领域对象模型,我们可以发现虽然原始的交易数据比较多,但是经过提炼处理以后,可以非常方便的掌握每个营业网点,和每个客户的总体交易信息。这就是从数据到信息的价值。

2.3.4 数据报表生成

​ 经过流转换模块以后,我们已经获得了1个营业网点在15分钟粒度的交易信息,那么我们就需要生成相关的统计报表。相关的用例简要说明如下。

1,timer 每15分钟,扫描新生成的交易清单文件(CSV格式)。

2,timer 首先以交易网点,和交易类型为关键字,进行统计,对15分钟粒度类发送的交易次数,交易金额进行累加,生成网点粒度的统计报表。

3,timer继续以客户id ,和交易类型为关键字,进行统计,针对15分钟粒度发生交易次数,交易金额进行累加,生成客户维度的统计报表。

4,timer将两个报表进行持久化处理。

2.3.5 数据汇总

​ 生成好15分钟粒度的报表以后,我们还需小时粒度的报表,和天粒度报表。相关的用例简单描述如下。

1,timer 在每个小时的特定时间周期启动, 首先进行扫描前一个小时周期中是否已经生成了四个15分钟粒度的报表。

2,假如前一个小时周期的四个15分钟粒度的报表报表已经准备好,则进行汇总处理。

3, timer首先以交易网点,和交易类型为关键字,进行汇总统计,形成小时粒度的汇总报表。

4,timer继续以客户id ,和交易类型为关键字,进行汇总统计,形成小时粒度的汇总报表。

5,两个报表生成以后,则将报表进行持久化处理。

​ 以上是小时粒度报表汇总的用例模型, 而天粒度的报表汇总的用例模型和上述处理过程基本类似,在这里就不再最重复介绍了。

​ 另外,数据汇总有两种方案,我们会优先介绍基于python的内存计算的数据汇总方案,并附带介绍基于数据库的数据汇总方案。

2.3.6 数据入库

​ 在经典数据仓库的应用中,关系型数据库是非常经典的一个数据持久化组件。而在大数据处理的应用中,虽然也使用了一些分布式的数据持久化方案,但是关系型数据库依然也扮演了一个非常角色。所以利用数据库作为持久化方案也是一种非常重要的应用方案。

​ 为了方便原型试验,我们选择postgres-sql作为案例进行讲解。相关的用例说明如下。

1,timer定期扫描结果集合文件。如果结果集文件存在,则准备进行数据入库操作。

2,timer 读取数据库连接配置数据,并启动数据库连接。

3,timer 将结果集文件传送到数据库当中,

4,数据拷贝完毕以后,timer就释放数据连接。

2.4、 并行计算模块

2.4.1 大数据处理的“4V难题”与对策

大数据的4V 难题

​ 图 2-12 大数据处理的“4V”难题

​ 随着5G,物联网和工业4.0的普及,大数据人才需求量日益大增, 但是大数据处理和我们传统的数据处理存在很大的不同。 而大数据处理的第一个难题就是velocity 难题。也就是说,我们需要非常高效的处理数据。

​ 我们知道任何一个大数据项目的预算是有限的,这其中有一个瓶颈就是计算资源方面的预算,无论是租用公有云平台,还是自己搭建私有云平台吗,都是一笔昂贵的开销,所以如何使用最少的硬件来满足velocity 难题的挑战,是大数据项目成败的关键。

​ 而要破解这个velocity难题,有一个非常重要的要求就是:

1**,尽量高的利用CPU**资源。

2**,尽量低的利用内存资源。**

3**,在多机的环境下,一定要把每台服务器都充分的使用**。

​ 要实现这个技术要求, 我们需要以下方面的专业组件

1,灵活的任务调度框架

2, 基于生产者-消费者模型的任务拆分

3, 服务的异步化协调。

​ 上述的原则虽然讲解起来比较通俗易懂,而实现起来确实比较抽象和艰困的,因为这些设计原则以及设计到大数据方案中最本质的技术难点,我们还是结合原子用例的方式来进行介绍。

2.4.3并行计算-用例故事

​ 在前面介绍的,假设一个财富银行,他在一个城市有多个营业网点,我们假设他的银行网点的个数有100个,并希望能够及时的生成全市的汇总报表,那么在这种情况下,数据处理的时效性,就变得非常重要。具体来说,有以下三个难点:

1, 如何尽快从100个营业网点的接口服务器上,取得双层压缩的文件,并放置在本地的receiver 目录下?

2,如何尽量快的将双层打包文件,经过解压处理,并生成csv文件。

3,在进行数据汇总处理的时候,需要对任务级联处理,方便的控制这种级联?

当问题的复杂度到了这种程度, 就不仅仅是一个编程层面需要解决的问题,而是系统架构层面需要解决的问题。

2.4.3 并行计算-用例模型

​ 在并行计算部分,我们不会创造新的用例,而是会在原有用例的基础上,引入并行计算的处理要求, 下面将需要并行处理的用例重新进行说明,并简要说明需要依赖的并行计算技术。

并行计算

​ 图2-13 基于并行计算扩展的用例模型

​ 在本章节中,我们将介绍并行计算的主要两个手段,一个是基于多进程的多核计算,和基于异步任务协同处理的多机计算。

​ 在这里多机协同计算的难点比较高, 在后面将会详细解析介绍,其中的生产者-消费者处理模型。 这一部分的内容,也是整个培训课件中,最精华的部分,掌握了这一部分的内容,就基本掌握了分布方式大数据处理的基本技术。

2.5、章节规划

​ 以上是,本培训教程中的用例规划,总共包含了7大用例模型,其中有三个用例模型将会介绍基于分布式并行计算方案的处理方案。主要的章节划分为三大区块。

1,流转换模块-介绍如何进行常规的流转换用例,实现数据归一化的目的。主要是解决如何实现数据应用的storage,data层面的问题

2,数据处理模块:介绍如何将数据进行统计和汇总,形成汇总级别的统计报表。主要是解决数据应用的information层面的问题。

3,并行计算模块:介绍如何利用有限的计算资源,实现快速的实现流转换,和数据处理操作,主要解决大数据处理的4V难题中的velocity难题。

​ 经过以上三大模块的训练,读者就可以掌握,如何实现在大数据的应用场景下,实现从storage, data,information 三个层面的数据应用能力。

Starter
MicroServ
Tutorials
Blog