近年来，我们在数据科学和高级分析方面取得了一些进步，但许多项目仍然采用20世纪80年代的遗留技术：萃取(extract)、转置(transform)和加载(load)，也就是我们所说的ETL。这让数据架构师感到无比头疼，但我们似乎又无法超越它，那有什么方法能改变这个局面吗？
在研究ETL的代替者之前，让我们先看看这项技术的起源。上世纪80年代和90年代，随着企业在生产数据库中积累了越来越多的事务性数据，它们意识到需要专门的商业智能(BI)系统来进行分析和报告。在许多方面，BI将“p”重新放到了企业资源规划(ERP)中。
数据仓库有多种用途。首先，除了核心生产系统之外，它还为连接和分析来自多个源的数据提供了一个通用的位置。它还避免了影响支持生产ERP系统的服务器及其底层关系数据库。数据仓库是分析师研究数据和尝试新想法的有效手段。
由于BI项目的数据将来自于各种来源——包括在线事务处理(OLTP)系统、市场营销和客户关系管理，甚至是从第三方数据代理那里购买。因此公司需要更多专为处理数据类型和工作负载而定制的数据库软件。从Arbor Software的Essbase开始，出现了一种新的多维数据库，用于支持在线分析处理(OLAP)工作负载。
但是将这些丰富的OLTP和客户数据迁移到OLAP系统中并不是一项简单的任务。生产数据库以不同的方式存储数据，对必须费力映射到数据仓库的列使用特殊的命名约定。其中一些源系统甚至不是关系数据库，而是专有的大型机文件系统或平面文件存储，这更加大了难度。除了事务性数据之外，还有时间序列和地理数据，所有这些数据都必须经过调整，以适应所选择的模式。
将所有这些数据转换为数据仓库中一致且可用的格式仍然是一项艰巨的任务。公司雇佣大量的专家和顾问来编写和维护定制的ETL脚本，这些脚本可以将数据敲入数据仓库中使用的特定模式。无论何时更改源数据库表或文件，下游ETL脚本都需要进行调整，以确保数据仓库继续提供相同的数据。
除了ETL的维护噩梦之外，它的批处理特性是另一个很大的缺点，尤其是在只关注当下的环境中。更新数据仓库中成千上万个表的ETL作业通常在夜间运行，此时生产处于停顿状态。其他时候，公司每天运行多个ETL作业，希望为不断使用各种SQL查询访问数据仓库的分析师提供更新鲜、更有洞察力的见解。
尽管在ETL上花费了大量时间和金钱，公司仍然会遇到很大的问题。为了确保干净准确的数据通过ETL到达，并且防止垃圾数据填满数据仓库，应该制定详细的流程。很多人都能迅速完成大任务，但是当涉及到数据定义时，会有很大的困难。数据也会随着时间的推移而改变，影响分析查询的结果，使其与早期比较不再那么准确。
ETL的使用既痛苦又昂贵且容易失败，但我们能做些什么呢？事实上，许多公司已采取各种方法来解决这一难题。以下是避免ETL的四种可能方法。
1. 合并OLTP和OLAP
如果ETL是您的痛苦之源，那么可以避免它的一种方法是在相同的系统上运行所有内容。这种方法最好的例子是SAP的HANA，它最初是一个超快的内存分析数据库，现在已经成长为ERP业务套件方面的核心事务数据库。据说，这家德国软件巨头的整个业务包括OTP和OLAP都在一个相对较小的系统上运行。它并没有完全消除对ETL的需求，但是它最小化了可能出错的范围。
如今，许多新的扩展关系数据库还提倡使用“translytical”方法合并操作和分析操作，以加快处理时间。像Aersospike、MemSQL、Splice Machine和VoltDB这样的供应商，将集群架构和内存处理结合起来，以支持非常快速的SQL查询处理，足以支持Web和移动应用程序并对它们进行实时分析(但不一定是像ERP这样的核心业务应用程序)。
Forrester分析师Noel Yuhanna和Mike Gualtieri在2015年表示传统的ETL流程无法实现实时更改。Translytical克服了这一挑战，为关键业务数据提供了实时、可靠的视图，确保信息来源准确以及整个组织的一致性。
Garter支持一种类似于混合事务分析（HTAP）的方法。 NoSQL数据库供应商Couchbase通过其嵌入式SQL ++引擎支持这种方法用于查询JSON数据，亚马逊也是如此。
2. 给ELT一个机会
ETL中一个受欢迎的转折是改变处理顺序。不是在ETL过程中进行所有重要的数据转换，而是在将其加载到数据仓库之后再进行转换——因此是ELT而不是ETL。这种方法在更现代的数据湖中很流行，在现代数据湖中，数据语义和模式不像在传统数据仓库中那样严格执行(如果它们被强制执行的话)。
ELT在Hadoop中很受欢迎，在Hadoop中，客户可以快速地存储大量原始数据，然后在稍后运行大量批处理工作，为后续处理(包括SQL分析和机器学习)准备数据。
如果您的数据工程师正在使用Apache Spark为下游数据科学和分析工作负载开发数据转换管道，那么您一定会大吃一惊。因为他实际上是在编写ELT工作，这是Spark最大的用例之一。Spark背后的Databricks公司于2017年推出了Delta，可以说是ELT和数据转换即服务。ELT方法也用于一些NoSQL数据库。
3.实时流式ETL
一些公司采用的是流式ETL方法，而不是事后批量转换数据，即数据到达现场后不断进行处理和细化。这种方法可能不适用于传统的ERP数据，但对于处理不断增长的Web和移动应用程序数据(本质上是时间序列)来说，它可能是绝对必要的。
通过在数据到达时直接处理数据，开发人员可以避免在一个单独的ETL阶段来处理数据。本质上说，这就是Apache Storm的创建者Nathan Marz在2011年提出的Lambda架构，其中一个加速层 (Storm)可以快速处理数据，但可能不是100%准确，而批处理层 (Hadoop)可以在稍后修复任何错误。
Apache Kafka的联合创作者Jay Kreps在构思Kappa架构时也想到了类似的解决方案，这是Lambda的一个精简版本，不包含单独的加速和批处理层。相反，Kafka在流媒体事件数据生成过程中扮演着核心角色。
4. 直接数据映射
最小化ETL的另一个选项称为直接数据映射，即源数据直接在其所在位置查询，而不是将其移动到数据仓库。这是Incorta所支持的方法，该公司由甲骨文(Oracle)前高管Osama Elkady于几年前创建。
Incorta的直接数据映射方法仍然要求用户将数据移动到数据湖，比如HDFS、S3或Azure Data Lake，并将其存储为高度压缩的Parquet文件。但是，通过在“提取”和“加载”步骤之间注入元数据标记，它可以允许客户跳过“T”部分。
“Incorta想表达的是，如果我们只将数据加载到另一个仅用于分析的数据库中，会发生什么，如果我们按原样获取数据而不必对数据进行扁平处理，会怎么样？” Elkady指出: “它可以将查询时间从小时级缩短到秒级。”
Incorta的方法很有效果，正如最近一轮3000万美元的C轮融资所显示的那样。这家硅谷公司正在吸引大量客户，包括苹果(Apple)、博通(Broadcom)和星巴克(Starbucks)。Elkady表示:“如果客户无法实时查看运营数据，无论是制造业务、零售业务还是仓库管理，都可能会损失数百万美元。”
目前我们没有办法完全摒除ETL以及应用它的麻烦。在完全使用相同一致数据格式的系统之前，仍然需要从一个地方获取数据并为其应用做好准备，然后加载数据。但是，数据转换的新方法可以帮助避免ETL应用过程中的问题。
原文网址：https://www.datanami.com/2019/09/03/can-we-stop-doing-etl-yet/