在TDH大数据平台上进行数据仓库ETL功能设计（一）
今年利用一个新的项目机会，对过往在TDH（星环的大数据平台产品）上做etl实现的功能做一些总结和重新优化设计并在这个项目中进行应用，因为过往的经验或者习惯的问题，以前在TDH上除了调度这块依赖于类似control-M这种调度平台之外，像数据采集、卸载分发、数据加工等处理过程都时采用自己开发的脚本或者存储过程实现的，在新的设计中依然是这样的思路。主要是因为目前在大数据平台上做ETL的开发，需实现采集、处理的作业都是成千上万的，使用各类ETL工具及调度工具会使得作业开发工作量特别的大，而且容易出错。
这个设计虽然是基于TDH设计的，但其思路在CDH、华为以及开源平台上也同样可以，无法是一些具体的细节功能实现起来有些区别。
这份材料是设计初期思路确定后对项目组内的人员进行的培训，因为项目组内第一次接触TDH或者HADOOP平台的人是大多数，甚至很多连数据仓库是什么都处于懵懂状态的人，所以在培训时也比较注重讲细节简化说明，便于理解。
讲解分三个部分：
- 数仓定位与TDH
- 数仓组成结构分析
- 分模块标准化实施
第一部分先简单介绍下数据仓库的定位及主要功能，同时说明下TDH的架构和对应数仓所需要使用的组件。
第二部分就是以独特的视角对数据仓库内所包含的内容进行拆解分析。
第三部分就是对数据仓库所需要实现的ETL功能进行分模块标准化的开发实施进行设计上的讲解。
数仓定位与TDH
数据仓库定位与职能
数据仓库在企业中核心的定位就是实现统一的数据采集、加工、安全管理以及提供数据服务的中心平台，为各类基于数据的应用体系建设的基础设施工程。
其中最基础的核心职能就是基于一个统一平台实现数据汇集、数据整合加工以及数据服务三部分功能。
数据汇集实现将行内有需求价值的IT系统数据、手工业务数据等采集汇总到一个数据库系统内；
数据整合加工实现将汇集的数据从时间、业务分类、功能等多个角度进行合理的加工处理，实现合理高效的数据存储，降低对数据进行理解、检索查询的难度。
数据服务即实现相关系统、业务人员对整合数据基于多种方式的查询服务需求。
数据仓库逻辑架构
为简化对数据仓库逻辑架构的理解，最简单的数据仓库逻辑架构如上图所示。
一般我们所熟悉的数据仓库架构都是描述分层架构，这是数据仓库的数据架构。对ETL来说，其实不管有多少数据层级，都可以归类为三个数据区域：临时区、模型区、服务区，三个区域划分的依据是从其功能需求定位来区分的。临时区是为了实现数据的落地接入、模型区是为了实现统一规范的数据整合加工、服务区是为了实现数据对外提供服务。因为功能定位不同，其数据结构特征会不同，因而也会影响到相应ETL功能的实现逻辑。
为实现数据仓库的数据架构，就需要实现一些必要的ETL功能，包括：
- 抽取采集，实现将数据源数据接入到数据仓库的数据库系统。
- 转换装载，实现数据模型的加工处理以及服务接口的加工处理。
- 数据接口，实现数据对外开放及数据卸载分发等服务功能。
- 数据检核，实现对数据加工结果进行准确性检查、数据质量检查的功能。
-
作业调度与监控，实现以事件驱动及依赖出发方式将ETL功能作业进行调度执行和监控的功能。
这部分是ETL功能体系在设计时，需要考虑的最基本的几个大分类功能。
TDH大数据平台
上图是目前TDH的产品架构图，可看到TDH为了应对不同的数据处理、使用场景，基于spark技术核心完善或自研了众多的产品组件，为企业进行大数据建设提供多种工具手段。
本次讲解的数据仓库我们重点还是关注实现常规的批数据处理流程，涉及相关的组件就比较基础，包含TDH运行所依赖的基础部分以及inceptor（对应HIVE、IMPALA等）、hyperbase（对应hbase）等计算组件，星环的STUDIO工具除了waterdrop用来实现类似oracle plsql developer的桌面工具功能需求，用处比较多。其他的工具基本都不太适用于企业去做大型数据仓库的要求，面对大作业量的情况使用起来还是相对繁琐。
image.png
核心组件INCEPTOR，以对PL/SQL语法的高度支持，非常方便实现数据仓库的数据处理逻辑。
hyperbase数据库使用于比较多的索引查询场景以及ETL处理过程中所需要的配置数据存放和读取。
其他像hdfs和sqoop工具是为了方便数据的上传下载，kerberos安全认证方便对数据进行一个权限的管理。
数仓组成分析
数据仓库的组成
我们通常情况下接触的数据仓库，都是理解为ETL+模型，那么对于ETL就包括数据采集、清洗、标准化等内容，模型呢就包含了各种主题模型、维度模型等构成的数据表。因为我们要研究ETL怎么实现，模型其实也是ETL中做数据转换中的一部分，那么我们换一种思路，尝试去理解分析下一个标准的数据仓库，它的组成部分有什么。
就如上图所示，我把一个通常意义上的数据仓库分为以下几部分：
- 数据来源
ETL中最基础的采集部分，所涉及的就是数据来源部分，通常我们认为上游的数据提供方不是数据仓库的组成部分，但实际上，上游系统的很多内容都是数据仓库必须要有的内容，它们肯定是数据仓库重要的组成部分，这部分内容至少要包含以下内容：
- 数据来源名称
- 数据来源类型
- 数据获取方式
- 数据获取格式
- 数据获取策略
- 元数据
只有获取了这部分内容，才能去制定数据采集的功能设计、临时区数据结构的设计、日终调度的设计。所以数据来源信息是数据仓库的重要组成部分。
- 数据结构
数据结构就是数据仓库的数据库设计，包括临时区、模型区、服务区的业务数据表、字段、主键等元数据信息，同时也包括为了实现ETL而进行登记的配置表结构、日志表结构等等。 - ETL程序
顾名思义，指的是实现数据仓库具体的基本功能的程序代码，在我们的设计中ETL程序是一整套的通用代码，能够实现包括数据采集、整合转换、历史处理、接口配置等功能。基于这些ETL程序，实现一个个具体的ETL作业的开发部署运行。 - 调度监控
调度是指所有批处理作业按照一定的顺序和规则跑批执行的能力，通常是基于类似control-M这种调度工具，在我们的设计中通过shell写一些服务化进程可实现一定的调度功能，能够对并发量、优先顺序、依赖触发、重复触发、异常报警等需求进行支持，同时开发工作量相比工具使用更小。但相应的，需要开发单独的web功能来实现对作业执行情况的监控。 - 数据备份
数据备份是数据仓库众多组成部分中比较容易被忽视或者说轻视的部分，通常说到数据备份都知道一些简单的数据备份手段，但实际上数据备份的概念还可能更多，至少要考虑如下几个部分：
- 备份数据范围，临时区、模型区，服务区是否备份呢？
- 备份周期，临时区7D？模型区1Y？服务区30D？
- 备份方式，文件备份？灾备平台数据同步？
以上这几个是从完整的数据仓库组成内容去思考的角度，从功能和内容上看，感觉一个数据仓库的东西并不多，可是当所接入的数据表成千上万，所设计建设的模型以及对外开放的数据服务接口成百上千时，如果没有对这些内容进行一个合理的存放读取设计、功能开发设计，那么在这个数据仓库常年累月的新增需求开发过程中，其庞大而糟乱的组成会让从一开始就参与并维持它运行的人在项目组成员中成为大神一样的人物的同时，也让新进入项目组的成员越来越难以驾驭掌控这个庞大的系统了。
数据来源、数据结构、ETL程序的细化讲解
数据来源分类
数据来源根据来源和形式的不同可以有多种分类方式，每种分类方式其实意味着在做数据采集时所需要注意和解决的问题，比如对于数据库直连采集这种情况，就要求在做ETL程序开发时，解决如何定位数据库地址和登陆信息并按照灵活的查询方式进行数据抽取的功能实现。总的来说，数据来源的内容通常决定了数据采集功能所依循的原则、规范和流程。
数据结构信息
数据仓库的数据结构信息非常的繁杂，如图所示，从分类上就可以分成至少8种，细分类可能就更多，对于这部分数据，因为直接影响数据仓库是否能正常运行，在生产环境对它们的维护从来都是小心小心再小心，但是往往仍不能避免出现问题。对其进行详细的梳理分类，并设计工具实现有效的管理，避免在生产环境频繁的变更以及直接的手工操作是改善的手段。
ETL程序通用化
数据仓库的ETL功能一般都是类似的。比如数据采集，对于同是通过文件方式进行采集的方式来说，其流程都是类似的：对接入的数据文件检查合法性-》通过put上传到hdfs上-》构建外表实现数据访问。所以，没有必要针对具体的采集数据表进行单独的作业程序开发（包括采用informatic这种ETL工具的方式），那样是平白增加了开发的工作量和出错的概率，以及排查问题时的复杂性。可以通过对每一类功能进行规范的、标准化的设计，进而通过配置表的方式实现通用化功能，后续开发人员只需要通过修改配置、执行测试并完成部署投产的功能就可以极大的提高ETL作业开发的便捷度，降低出错的概率。
作业调度
作业调度就是数据仓库运行的大脑，对于作业调度工具来说，其实现的基本功能是根据依赖关系、优先级、时间要求对不同类别的程序或者脚本能够触发执行，并能得到具体作业的运行状态结果，提供监控报警通知的功能。
作业类别、作业依赖、作业执行、作业监控以及告警通知是作业调度的组成部分。
数据备份
数据备份包含对原系统文件的每日备份、配置数据的备份、程序备份、模型数据备份及部分。
现在在TDH这类大数据平台上实现数据备份，都是充分利用HDFS分布式的特性，将文件基于一定的规则和策略存放到HDFS上，并通过专门的程序脚本实现定向的查询获取。
大数据平台灾备平台要实现数据同步，也有专门的技术，distcp能实现不同HDFS集群之间的数据互传，数据同步功能以此为核心，但还需要解决如何调度的问题。
