写在前面：
数仓概念出现于上世纪90年代， 国内最早开始的数据仓库也都在90年代末了， 刚开始大家都是按照国外大厂的指导， 照猫画虎，逐步开始建立自己的数据仓库技术体系。
这个时候大家都关注怎么建立分析模型， 怎么进行数据分析来支持决策。但是随着系统越来越庞大， 数据量越来越多， 数据处理的效率，就越来越成为大家不得不关注的热点问题了。
到底应该ETL 还是ELT，看上去只是简单地调换了一下字母的顺序，是个简单的问题，但是大多数的问题都是一学就会， 一用就废。而事实上，顺序一换，这是对数据处理流程和方法论上进一步深化的过程。
责编 | 韩楠
约 2355 字 | 5 分钟阅读
以下，Enjoy~
作为数据仓库从业者， 数据的抽取转换加载是永远绕不开的， 虽然现在大家一谈到数据分析， 更多的人喜欢谈数据挖掘、深度学习、数据可视化。但是随着企业数据碎片化越来越严重， 另外更多的社交数据引入到数据仓库中之后， 数据的清洗， 预处理变得更加重要。
先来看看 ETL，全称为Extract - Transformation - Load，是三个单词首字母的缩写， 它生动地描述了数据仓库数据预处理当中的三个关键阶段。
首先是抽取（Extract）， 顾名思义，是从生产系统或者其他数据源中提取想要用到的字段， 然后用来支持后期的数据分析， 这个时候需要考虑最多的是这两个关键点：
• 哪些数据需要抽取出来？
• 利用什么手段来抽取？
哪些数据需要被抽取出来， 其实取决于几个因素：
01 ⎪ ETL 还是 ELT？
数仓概念出现于上世纪90年代， 国内最早开始的数据仓库也都在90年代末了， 刚开始大家都是按照国外大厂的指导， 照猫画虎，逐步开始建立自己的数据仓库技术体系。
这个时候大家都关注怎么建立分析模型， 怎么进行数据分析来支持决策。但是随着系统越来越庞大， 数据量越来越多， 数据处理的效率，就越来越成为大家不得不关注的热点问题了。
当时有人提出一个理论，到底应该ETL 还是ELT，看上去只是简单地调换了一下字母的顺序，但是事实上，这是对数据处理流程和方法论上进一步深化的过程。
ETL 和ELT， 简单地区别就是先转换再装载， 还是先装载再转换， 前者的主要支持者自然是传统的工具厂商 Data stage 和 Informatica ，因为在这种体系架构中， 需要有一个专门的Transformation Server， 数据的复杂处理和映射，主要在转换服务器上进行处理。
而ELT的主要支持者就是数据库厂商， 因为它们希望所有的数据处理工作都在数据库内部完成， 最大化地发挥数据库海量数据并行处理的能力。
两种方式各有优劣， ETL 重转换， 可以在转换服务器上直接进行复杂的处理， 但是受制于转换服务器的处理和吞吐能力， 海量数据的处理效率堪忧。
但是ELT的缺点在于：如果大量的数据转换都由存储过程实现的话， 那么整个数据处理过程中的元数据管理就变得非常困难。随着数据仓库的技术发展， 最终ELT 还是略占上风， 因为， 如果把数据仓库各层之间的汇总也看作是Transformation的话， 那自然是Load 在先， Transformation在后。
02 ⎪ 带来的问题
ELT大行其道的同时， 也给数据仓库的技术带来了几个问题， 下面我跟你简单说说。
第一个问题，就是大量的存储过程怎么调度的问题。 我见到过一家国内大型科技企业的数据仓库， 有超过一万个数据处理脚本。随着业务发展， 这些脚本的数量还是继续增加。
那么如此多的脚本，我们不得不去思考这样的几个问题：
• 怎么进行调度？
• 怎么实现断点续跑？
• 怎么进行小范围回退后重新启动而不需要所有一万多脚本重新跑？
• 一旦中间数据处理异常之后，如何清理错误的脏数据？
这么多的脚本进行调度，还有先后依赖关系，怎么确定ETL 脚本的分层管理， 如何实现整个调度过程的图形化展现和监控，就变成了一个新的问题。
第二个问题， 元数据管理的问题。 我记得我最初写ETL 脚本的时候， 只考虑了数据怎么从源取出来， 然后再怎么经过mapping ，生成最终结果， 中间的过程完全不需要对外输出过程信息。
但是这样一来， 我们就很容易陷入另外一种僵局， 就如同前面提到的那家企业， 一万多脚本， 鼎盛时期有400多开发人员在做开发， 但是一旦人员流失， 换新人怎么维护这个代码？难度自然就直线上升了。
同时， 如果在结果展示的时候 想知道某个数据，是经过什么口径统计过来的？那就完全不知道了， 因为整个脚本就是个黑盒子， 大家都不知道数据之间的继承沿革关系。所以怎么利用存储过程，自动生成ETL 元数据， 就是第二个问题。
第三个问题， 存储过程效率问题。 所有数据转换都利用数据库的特性， 那么这个时候的数据处理效率就会全面依赖数据库的特性，这种处理难以避免的就是多个大表Join， 排序。那么您选择的数据库在大表连接的时候怎样效率最高，怎么利用数据库提供的函数或者特性，加速数据处理效率，就变成了程序员必须要了解的一个知识点。
曾经碰到一个项目， 程序员对数据库特征不太了解， 同时为了程序易读， 就通过临时表来简化过程， 看上去是个很好的习惯。
但是极端情况下， 原来只需要一个复杂SQL 就能解决的问题， 数据反复写临时表20多次，系统上线之后，还在纳闷， 数据逻辑完全没变， 怎么就跑不动了呢？
03 ⎪ 写在最后
ETL 还是ELT ， 看上去是个简单的问题， 但是大多数的问题都是一学就会， 一用就废。就像在驾校学了怎么起步？怎么停车， 怎么换挡， 但是真正上路才发现还是会各种手忙脚乱。
就今天探讨的问题， 关键还是需要在设计ETL 和交付ETL 项目的时候， 要有大局观。多想想执行效率， 维护难度，多多输出元数据， 这样一来，我相信你就已经踏上了正确道路， 迈开了第一步。
欢迎在评论区与我分享你的想法。如果觉得这篇文章对你有帮助，或者有共鸣之处，也欢迎分享给你的朋友、同事，一起交流讨论。
THE END
转载请联系ITPUB官方公众号获得授权
—————————————————————————————————
欢迎各领域技术人员投稿
投稿邮箱 | hannan@it168.com