近年来，我们在数据科学和高级分析方面取得了一些进步，但许多项目仍然采用20世纪80年代的遗留技术：萃取(extract)、转置(transform)和加载(load)，也就是我们所说的ETL。这让数据架构师感到无比头疼，但我们似乎又无法超越它，那有什么方法能改变这个局面吗？在研究ETL的代替者之前，让我们先看看这项技术的起源。上世纪80年代和90年代，随着企业在生产数据库中积累了越来越多的事务性数据，它们意识到需要专门的商业智能(BI)系统来进行分析和报告。在许多方面，BI将“p”重新放到了企业资源规划(ERP)中。
数据仓库有多种用途。首先，除了核心生产系统之外，它还为连接和分析来自多个源的数据提供了一个通用的位置。它还避免了影响支持生产ERP系统的服务器及其底层关系数据库。数据仓库是分析师研究数据和尝试新想法的有效手段。
由于BI项目的数据将来自于各种来源——包括在线事务处理(OLTP)系统、市场营销和客户关系管理，甚至是从第三方数据代理那里购买。因此公司需要更多专为处理数据类型和工作负载而定制的数据库软件。从Arbor Software的Essbase开始，出现了一种新的多维数据库，用于支持在线分析处理(OLAP)工作负载。
但是将这些丰富的OLTP和客户数据迁移到OLAP系统中并不是一项简单的任务。生产数据库以不同的方式存储数据，对必须费力映射到数据仓库的列使用特殊的命名约定。其中一些源系统甚至不是关系数据库，而是专有的大型机文件系统或平面文件存储，这更加大了难度。除了事务性数据之外，还有时间序列和地理数据，所有这些数据都必须经过调整，以适应所选择的模式。
将所有这些数据转换为数据仓库中一致且可用的格式仍然是一项艰巨的任务。公司雇佣大量的专家和顾问来编写和维护定制的ETL脚本，这些脚本可以将数据敲入数据仓库中使用的特定模式。无论何时更改源数据库表或文件，下游ETL脚本都需要进行调整，以确保数据仓库继续提供相同的数据。
来自 “ ITPUB博客 ” ，链接：https://blog.itpub.net/69905323/viewspace-2656304/ ，如需转载，请注明出处，否则将追究法律责任。
