1、ETL和ELT

        ETL是Extract、Transfrom、Load即抽取、转换、加载三个英文单词首字母的集合：

        E：抽取，从源系统(Souce)获取数据；

        T：转换，将源系统获取的数据进行处理加工，比如数据格式转化、数据精度转换、数据清洗、缺失数据补齐、异常数据排除等。

        L：加载，将数据加载到目标数据库(Target)。

        ELT也是同样三个单词的首字母组合，只是把T、L颠倒了下顺序。ETL强调的是先进性数据转换，然后再加载到目标。这个转换过程可以在原系统进行，也可以在中间环境进行进行。而ELT是把数据加载到数据仓库后再进行转化。ETL优势是充分利用各关联系统的性能，提高效率，但程序部署分散，运维成本较高。ELT是充分发挥数据仓库平台数据加工的高性能，并且可以保存原始数据方便后续复用。

        随着数据仓库平台的性能越来越高，容量成本越来越低，目前更多的是采用ELT方式，充分利用数据仓库的高性能，提高加工效率。但在数据加载前也需要进行数据编码转化、异常数据等影响加载的处理，确保数据正确加载到数据仓库平台，但不做数据逻辑加工。

        由于ETL出现较早，通常使用ETL来代表数据抽取加载和转换的统称。

2、ETL架构设计

        数据ETL需要有ETL服务器集群执行数据ETL作业来进行数据抽取、转换和加载，所有ETL作业的脚本部署多台ETL服务器上，ETL作业可以根据服务器资源由调度工具分配到任意一台ETL服务器执行，常见架构如下图：

        ETL架构不仅仅是作为数据仓库的架构，但也是全行批量数据交换的统一架构和标准，虽然数据仓库是其中最大的一个数据加载的目标系统和数据源系统，但从架构规划角度来看，需要从全行、全集团的角度来设计批量数据交换，考虑多机构间交互场景，减少不必要的转换，提高效率和稳定性。

        ETL服务器集群需要做到高可用，对于不能正常服务或负载过高的服务器，调度平台不会将作业分配到该服务器，所有的ETL作业脚本需要在每台服务器上部署，不能只部署一份代码到共享存储中。

        在硬件资源上，服务器的IO和内存需要配置较高，同是由于批量数据容量较大，网络带宽需要千兆以上，同时需要考虑在传输高峰不能影响交易系统的网络通讯。

（1）文件方式和端到端方式

         数据抽取和加载从是否经过中间落地成文件来区分主要有文件落地方式和端到端不落地（内存）的两种方式。文件方式指ETL服务器的抽取数据作业从源系统获取转焕为文件放到文件共享存储中，再由加载作业到目标系统中。端到端方式是ETL服务器从 源系统获取数据后在内存中直接加载到目标系统。

        从步骤中可以看出端到端方式在内存中直接加载，从单个作业速度对比来看速度应该更快，开发更简单，但端到端方式对内存资源要求较高，并行作业的最大值一般较文件低，同时文件具有以下好处：

        1）各数据库对文件导入和导出支持较好，一般都会提供专门的工具和高性能接口（如oracle sqlload导入文件和spool导出文件的性能较高）。因此大批量的数据抽取和加载作业的效率从整体看文件方式不一定比端到端的方式慢。

        2）文件方式耦合性比端到端低，如果发现数据加载出现问题，可以不用重新抽取数据，减少抽数对源系统的性能影响。

        3）文件通用性较好，如果涉及多网络或多机构之间的数据交换，A子公司的ETL服务器无法连接到B子公司的数据库。另外对于非结构化数据来源广泛，导出文件比较通用。

       具体采用文件方式，端到端方式还是两者都采用的方式，各公司需要考虑服务器资源、现有工具及数据库驱动性能、成本、数据交换场景等多种情况来确定。

（2）文件方式方案需要考虑的要点

       文件方式比较通用，多机构之间较多采用文件方式进行批量数据交互，但采用文件方式进行架构设计和开发时需要关注以下几点：

    1）统一的文件交换规范和文件传输平台

文件存储规范制定文件目录、文件命名、用户权限、文件校验、文件清理等规范，如果涉及到跨机构批量文件传输，还需要统一有文件传输平台，提供统一的文件高效传输、加密、校验、限流、文件夹同步等功能。国内银行使用较多的文件传输平台有东方通、神州数码等公司产品。

     文件目录规范中需要区分数据产生系统、数据使用系统、数据日期等，文件名中需要说明产生系统、文件内容描述、增量全量标志、数据日期等，规则举例如下：

        数据源系统/数据日期/目标系统/源系统_文件内容描述_数据日期_增全量标志_频率标志.txt

        举例：CBS/20190620/EDW/CBS_DEPOSIT-ACCOUT_20190620_ALL_D.txt

        说明：【CBS、EDW为系统名】【ALL为全量标志】【D为每日】

       2）文件格式：定长or 变长（分隔符）

定长：文件大，I/O资源消耗大，但能消除回车符、分隔符以及乱字符问题。

变长（分隔符）：文件小，处理性能高，但需处理异常情况较多：

         <1>分隔符：数据中存在分隔符，导致加载报错，可选用两个连续的不可见字符作为分隔符，基本可以解决该问题；

         <2>换行符：导出文件时一般以换行符作为一行数据的结束，如果导出工具支持可以改成不可见字符作为换行符，不支持的话导出时对数据中的换行符进行替换；

         <3>异常字符：如截取导致的半个UTF-8字符的编码或者HEX00等字符，一些数据库不支持会报错，一般这些字符发生在以前的主机上，异常情况下出现没处理，可以提前在源系统进行数据清洗或者导出时进行替换清洗。

        因此一般在这些问题都有较好解决方法不影响抽取加载作业效率的情况下，都会采用变长（分隔符）的方式。

    3）文件编码

        文件导出需要统一编码，一般采用UAT-8编码，适应多国字符，但如果只有国内应用，也可以考虑GB18030或GBK编码，因为这两种编码中文字符比UTF-8编码节省1/3多的存储空间。性能较好。

（3）端到端方式需要考虑的要点

1）工具选择

        目前市场上商用的ETL工具如DATASTAGE、INFORMATICA，开源的SQOOP都支持端到端的处理，商用工具还提供中间的图形化的数据转换编码功能，但商用软件一般成本较高，对于一些数据库的高性能驱动还需要收费，开源工具功能较通用，但性能需要优化，同时需要有一定的技术能力来定制功能和软件升级。

   2）驱动选择

        选择数据库提供的高性能原生（native）驱动，不要使用ODBC驱动，原生的驱动性能数倍于ODBC等通用驱动，采集数据较多时能很大提高效率。

   3）字符编码

       需要将数据从源系统导出时转换为目标数据库的编码格式，在全公司的数据库编码和数据仓库内的字符编码需要进行统一规范，既可以减少转换成本，也可以减少生僻字、无法转换等异常情况。

3、抽取和加载开发设计

（1）开发需求分析

        由于源系统和目标系统数据库不同，数据质量不高，需要注意之间不同数据库之间的字段类型、长度、精度的转换，为后续数据加工做好清洗：

        1）源系统字段没有明确精度和长度时，如Oracle中字段类型为number,没有定义精度，使用DATASTAGE时，当大于15位的number型数字接近最大值时会自动进位，所以在目标表设计字段精度时需要考虑这种异常情况。

        2）字符字段的全角和半角是否都统一为半角；

        3）字符字段左右空格是否都统一去掉；

        在开发抽取加载作业时，需要配置以下主要信息，这些信息需要在数据调研和需求分析时提前确定：

（2）全表字段自动加载

       一般开发时会采用固定字段抽取加载的方式，但由于源系统的表结构会经常变化，比如增加字段，字段长度变长，如果每次变化都要随之修改，许多时间会耗费在这些小修小改中，因此在进行抽取和加载时，需要根据源系统表结构自动生成对应的抽取脚本、目标表结构、加载脚本，自动适应源系统的表结构变化。

 （3）源系统数据表变化通知和监控

        虽然抽取和加载作业可以适应源系统表结构变化，但字段长度、精度变化、字段删除、代码值变化和字段含义变化会对后续数据加工作业带来影响。因此源系统需要将这些变更提前告知数据仓库或目标系统，否则就会产生生产问题，但源系统开发同事往往会产生遗漏，因此在公司数据治理制度中明确开发分工、数据问题责任界定。如在每次版本需求分析时需要考虑数据变化对数据仓库及其它系统的影响，并在测试阶段提前进行影响测试。在上线前也需要检查下系统表结构变化的DDL文件，分析影响并通知影响系统。

        由于源系统字段的变化会影响到后续的数据流向的所有系统，因此在数据仓库的模型设计时需要提前设计冗余，减少字段长度、精度变化的影响，比如源系统字段长度是128，在数据仓库主数据模型中可以设计为500。减少对后续数据使用系统的影响。具体影响分析工具会在后续的“元数据管理”中详细说明。

        由于只靠源系统的通知并不完全可靠，还需要做好源数据表结构变化和代码值变化的监控，每天对抽取的表结构和上一日进行比对，代码值与代码值映射表中比对，对发现未告知的情况进行邮件告警，并评估影响、及时处理，以免问题积累，需耗费大量精力修复。

 （4）自动化脚本生成及执行

       对于抽取加载作业需要做成标准化程序，即一个程序处理所有的抽取加载作业，根据不同的配置信息来完成所有作业，在调度工具中的所有抽取加载作业指向的是同一个程序，由这个程序根据传入的作业名和日期自动化生成脚本并执行。这样对于开发只是进行配置信息的确认和导入即可，不需要涉及代码开发。

       许多ETL工具需要开发脚本再执行，特别一些商用的软件如DATASTAGE还提供了可视化的开发界面，但这样开发也比较耗时，对于使用的ETL工具如DATASTAGE、SQOOP也支持编程和脚本调用作业，所以可以用统一的程序来调用ETL工具进行抽取加载数据。提高开发效率，以下是供参考的流程。

（5）监控及异常处理

        数据抽取和加载作业是数据仓库每天第一批作业，如果发生问题往往对整个批处理时效产生较大影响，甚至影响监管报送时效。因此需要对作业进行监控，及时预警。

       因此在开发抽取和加载作业时，需要注意：

        1）统一返回码并提供错误信息；

        2）抽取和加载作业必须支持重跑，也就是在作业任何阶段发生异常时可直接重做，需要设计时考虑异常中断下，如何恢复初始数据；

        3）调度平台需要根据抽取加载作业返回码判断作业是否成功，是否可以继续，对于异常情况需要及时与行内监控预警系统对接，按预警级别发送作业错误告警信息；

        4）调度平台需要获取到作业的日志，对于一些ETL工具，这部分需要进行集成，以便减少后台日志查看的工作量，直接在调度平台进行问题定位。

（6）开发分工

        ETL作为全行或全公司的批量数据交互基础架构，需要在全行或全公司进行规范和开发流程培训。ETL服务器及工具、抽取加载的标准程序由统一团队来维护，需要进行权限分配并提供培训及技术支持。那对于抽取加载作业具体由源系统还是目标系统来开发不同的公司有不同的做法，

        １）由源系统开发，如果源系统是将数据加工结果给到目标系统，由于比较熟悉数据，一般由源系统加工完后直接开发抽取加载作业将数据提供给目标系统；

        ２）由目标系统开发，目标系统比较熟悉数据用途及优先级，如果全表抽取的话数据加工主要在目标系统，由目标系统来开发抽取加载作业，源系统只需要做好数据权限分配即可。

        ３）由数据仓库团队统一开发，一般公司较小时可以由统一团队来开发，但随着开发项目增多，会出现瓶颈，影响效率，需要由各数据使用方来开发抽取加载作业。