对于做过 BI 开发的朋友,ETL 并不陌生,只要涉及到数据源的数据抽取、数据的计算和处理过程的开发,都是 ETL,ETL 就这三个阶段,Extraction 抽取,Transformation 转换,Loading 加载。
从不同数据源抽取数据 EXTRACTION ,按照一定的数据处理规则对数据进行加工和格式转换 TRASFORMATION,最后处理完成的输出到目标数据表中也有可能是文件等等,这个就是 LOADING。
再通俗一点讲,ETL 的过程就跟大家日常做菜一样,需要到菜市场的各个摊位买好菜,把菜买回来要摘一下,洗一洗,切一切最后下锅把菜炒好端到饭桌上。菜市场的各个摊位就是数据源,做好的菜就是最终的输出结果,中间的所有过程像摘菜、洗菜、切菜、做菜就是转换。
在开发的时候,大部分时候会通过 ETL 工具去实现,比如常用的像 KETTLE、PENTAHO、IBM DATASTAGE、INFORNAICA、微软 SQL SERVER 里面的 SSIS 等等,在结合基本的 SQL 来实现整个 ETL 过程。
也有的是自己通过程序开发,然后控制一些数据处理脚本跑批,基本上就是程序加 SQL 实现。
哪种方式更好,也是需要看使用场景和开发人员对那种方式使用的更加得心应手。我看大部分软件程序开发人员出身的,碰到数据类项目会比较喜欢用程序控制跑批,这是程序思维的自然延续。纯 BI 开发人员大部分自然就选择成熟的 ETL 工具来开发,当然也有一上来就写程序脚本的,这类 BI 开发人员的师傅基本上是程序人员转过来的。
用程序的好处就是适配性强,可扩展性强,可以集成或拆解到到任何的程序处理过程中,有的时候使用程序开发效率更高。难就难在对维护人员有一定的技术要求,经验转移和可复制性不够。
用 ETL 工具的好处,第一是整个 ETL 的开发过程可视化了,特别是在数据处理流程的分层设计中可以很清晰的管理。第二是链接到不同数据源的时候,各种数据源、数据库的链接协议已经内置了,直接配置就可以,不需要再去写程序去实现。第三是各种转换控件基本上拖拉拽就可以使用,起到简化的代替一部分 SQL 的开发,不需要写代码去实现。第四是可以非常灵活的设计各种 ETL 调度规则,高度配置化,这个也不需要写代码实现。
所以在大多数通用的项目中,在项目上使用 ETL 标准组件开发会比较多一些。
ETL 从逻辑上一般可以分为两层,控制流和数据流,这也是很多 ETL 工具设计的理念,不同的 ETL 工具可能叫法不同。
控制流就是控制每一个数据流与数据流处理的先后流程,一个控制流可以包含多个数据流。比如在数据仓库开发过程中,第一层的处理是ODS层或者Staging 层的开发,第二层是 DIMENSION维度层的开发,后面几层就是DW 事实层、DM数据集市层的开发。通过ETL的调度管理就可以让这几层串联起来形成一个完整的数据处理流程。
数据流就是具体的从源数据到目标数据表的数据转换过程,所以也有 ETL 工具把数据流叫做转换。在数据流的开发设计过程中主要就是三个环节,目标数据表的链接,这两个直接通过 ETL 控件配置就可以了。中间转换的环节,这个时候就可能有很多的选择了,调 SQL 语句、存储过程,或者还是使用 ETL 控件来实现。
有的项目上习惯使用 ETL 控件来实现数据流中的转换,也有的项目要求不使用标准的转换组件使用存储过程来调用。也有的是因为数据仓库本身这个数据库不支持存储过程就只能通过标准的SQL来实现。
我们通常讲的BI数据架构师其实指的就是ETL的架构设计,这是整个BI项目中非常核心的一层技术实现,数据处理、数据清洗和建模都是在ETL中去实现。一个好的ETL架构设计可以同时支撑上百个包就是控制流,每一个控制流下可能又有上百个数据流的处理过程。之前写过一篇技术文章,大家可以搜索下关键字 BIWORK ETL 应该在网上还能找到到这篇文章。这种框架设计不仅仅是ETL框架架构上的设计,还有很深的ETL项目管理和规范性控制器思想,包括后期的运维,基于BI的BI分析,ETL的性能调优都会在这些框架中得到体现。因为大的BI项目可能同时需要几十人来开发ETL,框架的顶层设计就很重要。