近年來，我們在數據科學和高級分析方面取得了一些進步，但許多項目仍然采用20世紀80年代的遺留技術：萃取(extract)、轉置(transform)和加載(load)，也就是我們所說的ETL。這讓數據架構師感到無比頭疼，但我們似乎又無法超越它，那有什么方法能改變這個局面嗎?

[[276358]]

在研究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的四種可能方法。

[[276359]]

1. 合并OLTP和OLAP

如果ETL是您的痛苦之源，那么可以避免它的一種方法是在相同的系統上運行所有內容。這種方法最好的例子是SAP的HANA，它最初是一個超快的內存分析數據庫，現在已經成長為ERP業務套件方面的核心事務數據庫。據說，這家德國軟件巨頭的整個業務包括OTP和OLAP都在一個相對較小的系統上運行。它并沒有完全消除對ETL的需求，但是它最小化了可能出錯的范圍。

如今，許多新的擴展關系數據庫還提倡使用“translytical”方法合并操作和分析操作，以加快處理時間。像Aersospike、MemSQL、Splice Machine和VoltDB這樣的供應商，將集群架構和內存處理結合起來，以支持非?？焖俚腟QL查詢處理，足以支持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應用過程中的問題。