承接上一章，介绍下对etl各个模块部分进行实施开发设计的具体讲解：
ETL分模块标准化实施
上图是数据仓库ETL程序的组成结构，下面对ETL程序怎么实施做详细的讲解。
完整的ETL程序满足ETL过程中的元信息维护、ETL通用功能、调度三大部分，部署在LINUX环境下。程序以PYTHON+SHELL+SQL三种主要语言完成，分别应对不同的功能场景。
使用sqlite作为元信息的存储库，是因为基于数据库读取数据可以以比较少的代码来读取元信息以生成ETL中各个功能环节对应的脚本代码，同时sqlite作为文件式数据库，备份及恢复都十分简单。
但sqlite也有缺点：SQLITE在同时读写数据时存在死锁的问题，导致部分需要经常读写的状态类表无法使用sqlite（主要就是调度的作业状态配置表），因此后续还是考虑使用mysql或者其他小型关系型数据库来做元信息库。
基于shell实现通用化的数据采集、数据文件卸载分发、作业调度、数据同步等功能，这些脚本程序均为通用式程序，通过输入参数的不同，实现对不同数据对象的标准化流程处理。
在作业服务器安装TDH客户端程序TDH-CLIENT，实现在作业服务器上能够执行HDFS、beeline、hbase shell、sqoop等命令来操作TDH组件和数据，主要是实现数据库内的模型数据处理、统一的历史数据存储处理、数据服务视图的创建及授权维护等。
ETL所有依赖的元数据信息，需要妥善的存储和维护，因此首先对存储元信息的数据结构进行分类设计：
- META-元信息
包括定义etl功能所有配置表的数据结构，以及全局通用的信息表（全局参数表、异构数据库字段类型映射表、上下游系统信息表），是描述元数据的元数据结构表。 - LOAD-采集信息
保存为实现采集功能所需要的数据结构信息，同时，贴源数据的历史数据存储处理也依赖采集模块中登记的结构信息。 - TRANS-转换
保存为数据仓库模型的结构信息以及为实现生成数据逻辑处理程序的mapping逻辑信息。 - SERVE-服务
数据仓库需要为下游提供数据查询接口及数据文件卸载分发服务，这里保存数据接口视图的mapping信息以及卸载分发文件所依赖的配置信息。 - SCHE-调度
保存需实现调度的作业信息以及作业与作业之间的依赖关系。 - CHECK-检核
保存为实现对数据质量进行校验的校验规则以及模型字段与校验规则的映射关系信息。
这些元信息表都是设计为关系型数据库表结构的方式，每个表都有对应的EXCEL模板，数据开发人员开发时，主要是按照元信息的结构要求去填写配置表，通过对EXCEL的模板进行明确规范的标准化设计，可以最大限度的保证所有数据开发人员所实现的功能是统一的风格，并减少出现错误的概率。
以数据采集信息配置文档为例，其结构如下图所示：
对采集过程中需要的各种元素，需数据开发人员确定表名、类型（状态表或流水表）、采集方式、文件名称、文件格式、编码格式、分隔符等等信息，然后按照相应的格式规范去填写完成采集任务配置的开发。
数据开发人员完成EXCEL配置文档的开发后，由统一的初始化程序，读取excel的内容，存储到sqlite元信息库文件中。初始化程序不光实现配置数据的读取，也实现基于配置数据初始化数据仓库的整个环境，包括建库、建表、程序生成编译、配置数据同步到数仓库等等，如下图所示：
初始化所需要执行的各类操作通过统一的入口程序，以不同参数方式来实现，方便对应的程序开发工作。
数据采集
数据采集实现将数据从源系统抽取转移采集到数据仓库中，这里只简单说下对批量类数据采集的流程的设计
传统数据仓库类项目的数据采集工作都是基于类似kettle、datastage、informatic等ETL工具来实现的，现在基于大数据平台的数据采集工作已经不再推荐使用这种方式，一般是通过类似sqoop这样的抽取工具实现直接的抽取，或者通过hdfs实现对卸数的数据文件进行获取检验并加载的过程。
使用sqoop方式比较简单，只需要定义及配置好数据源信息、采集数据结构，通过拼接sql调用sqoop命令的方式即可实现数据采集动作，因此其过程是可以通用化实现的；
使用文件方式会比较复杂，原因在于文件的规范性难以得到保障。在实际客户项目经验中，总是会存在与设计主流的文件规范格式冲突的情况，导致数据文件不规范，而hdfs本身不会对文件格式进行校验，加载后如果数据文件存在格式错误，相应的数据也会出错。
因此文件采集过程中需要定义数据结构信息的同时，还需要对文件的格式信息进行定义和配置，并在加载过程中进行相应的校验处理，通用程序可以覆盖80%的情况，简单的配置即可实现采集功能。
一般常用的文件检核和处理内容包括以下几种：
历史数据处理
数据仓库区别于ods一大重要特征是需要对数据历史进行备份处理，方便在时间维度上对数据进行分析，因此对采集的数据进行历史的备份也是etl中重要的功能。
一般对历史数据处理的方式基于数据形式的不同可以分为状态类数据表的拉链存储和流水类表的每日增量镜像两种方式，不过基于实际情况也会有其他的处理方式，但总体上这两种是居大多数。
历史处理的这个过程也是完全可以通过配置实现通用化处理的：
通过定义统一的拉链标识字段，只需要输入表的字段结构、主键信息等内容即可使用动态sql的方式拼接处理sql语句，实现通用过程。
模型加工
现在数据仓库的模型加工基本上都要求基于mapping文档来实现，目的是方便对数据处理逻辑的管理及传承，并可以进行数据加工链条的上下游血缘分析工作。
因此通用程序通过对模型加工处理逻辑进行配置定义和解析，实现各种类型的数据加工sql的自动生成和编译工作。
数据卸载分发
数据卸载分发是数据仓库建成后工作量最大的需求任务，也是可以通过配置化通用化程序来实现快速便捷的开发过程：
数据视图
大数据平台构建数据仓库的同时，随着规模的扩大，还会在其上构建很多集市、应用，包括报表等，数据仓库在对这类应用提供数据时，无需通过卸载分发的方式，而是通过开放数据结构的方式，一般情况下我们推荐使用数据视图。
对数据视图进行分类可以包含
全映射视图，即对数仓模型的完全镜像；
脱敏视图，即对数仓模型的字段增加脱敏函数的数据视图；
定制视图，根据接口需求进行特定逻辑的视图，可以是对字段的筛选、字段加工、条件过滤等。
这些可以通过配置表进行登记，还可以方便后续的视图管理工作。
数据校验
数据仓库模型加工完成后，会有大量数据验证工作，其中有一些验证工作是可以提取出相似的内容进行通用化处理的，比如字段的数据质量情况校验。
可以定义一些字段质量规则，比如不允许为空、长度不能为1等等，然后配置模型与质量规则（或者更高一层次的数据标准与质量规则）的映射关系，然后通过通用程序实现校验的执行和结果的标准化定义输出：
作业调度
最后，对ETL实现调度的部分也可以有一些思路来改善我们使用control-m 、JCM等调度工具的问题。比如大量的采集、历史加工及数据卸载作业，其调度模式是一样的，完全可以批量的去配置并实现各种依赖关系。后台通过服务式的调度进程，来实现作业的依赖触发运行，而不用像使用其他调度工具还需要不断的在界面进行配置和导入导出工作。
以上就是对数仓ETL功能设计的一些思路提炼，不一定都好，也不一定在实际的项目工作中都能用到，只要有一些思路能帮助我们在开发部署时减轻工作量，并且更容易维护管理，那就是有帮助的（对于我们项目来说，通过提交excel文档方式去生产投产而不是提交代码方式能帮我们省却好多流程环节和项目文档呀...)
