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

[[276358]]

在研究ETL的代替者之前，讓我們先看看這項技術(shù)的起源。上世紀(jì)80年代和90年代，隨著企業(yè)在生產(chǎn)數(shù)據(jù)庫中積累了越來越多的事務(wù)性數(shù)據(jù)，它們意識到需要專門的商業(yè)智能(BI)系統(tǒng)來進(jìn)行分析和報告。在許多方面，BI將“p”重新放到了企業(yè)資源規(guī)劃(ERP)中。

數(shù)據(jù)倉庫有多種用途。首先，除了核心生產(chǎn)系統(tǒng)之外，它還為連接和分析來自多個源的數(shù)據(jù)提供了一個通用的位置。它還避免了影響支持生產(chǎn)ERP系統(tǒng)的服務(wù)器及其底層關(guān)系數(shù)據(jù)庫。數(shù)據(jù)倉庫是分析師研究數(shù)據(jù)和嘗試新想法的有效手段。

由于BI項目的數(shù)據(jù)將來自于各種來源——包括在線事務(wù)處理(OLTP)系統(tǒng)、市場營銷和客戶關(guān)系管理，甚至是從第三方數(shù)據(jù)代理那里購買。因此公司需要更多專為處理數(shù)據(jù)類型和工作負(fù)載而定制的數(shù)據(jù)庫軟件。從Arbor Software的Essbase開始，出現(xiàn)了一種新的多維數(shù)據(jù)庫，用于支持在線分析處理(OLAP)工作負(fù)載。

但是將這些豐富的OLTP和客戶數(shù)據(jù)遷移到OLAP系統(tǒng)中并不是一項簡單的任務(wù)。生產(chǎn)數(shù)據(jù)庫以不同的方式存儲數(shù)據(jù)，對必須費(fèi)力映射到數(shù)據(jù)倉庫的列使用特殊的命名約定。其中一些源系統(tǒng)甚至不是關(guān)系數(shù)據(jù)庫，而是專有的大型機(jī)文件系統(tǒng)或平面文件存儲，這更加大了難度。除了事務(wù)性數(shù)據(jù)之外，還有時間序列和地理數(shù)據(jù)，所有這些數(shù)據(jù)都必須經(jīng)過調(diào)整，以適應(yīng)所選擇的模式。

將所有這些數(shù)據(jù)轉(zhuǎn)換為數(shù)據(jù)倉庫中一致且可用的格式仍然是一項艱巨的任務(wù)。公司雇傭大量的專家和顧問來編寫和維護(hù)定制的ETL腳本，這些腳本可以將數(shù)據(jù)敲入數(shù)據(jù)倉庫中使用的特定模式。無論何時更改源數(shù)據(jù)庫表或文件，下游ETL腳本都需要進(jìn)行調(diào)整，以確保數(shù)據(jù)倉庫繼續(xù)提供相同的數(shù)據(jù)。

除了ETL的維護(hù)噩夢之外，它的批處理特性是另一個很大的缺點，尤其是在只關(guān)注當(dāng)下的環(huán)境中。更新數(shù)據(jù)倉庫中成千上萬個表的ETL作業(yè)通常在夜間運(yùn)行，此時生產(chǎn)處于停頓狀態(tài)。其他時候，公司每天運(yùn)行多個ETL作業(yè)，希望為不斷使用各種SQL查詢訪問數(shù)據(jù)倉庫的分析師提供更新鮮、更有洞察力的見解。

盡管在ETL上花費(fèi)了大量時間和金錢，公司仍然會遇到很大的問題。為了確保干凈準(zhǔn)確的數(shù)據(jù)通過ETL到達(dá)，并且防止垃圾數(shù)據(jù)填滿數(shù)據(jù)倉庫，應(yīng)該制定詳細(xì)的流程。很多人都能迅速完成大任務(wù)，但是當(dāng)涉及到數(shù)據(jù)定義時，會有很大的困難。數(shù)據(jù)也會隨著時間的推移而改變，影響分析查詢的結(jié)果，使其與早期比較不再那么準(zhǔn)確。

ETL的使用既痛苦又昂貴且容易失敗，但我們能做些什么呢?事實上，許多公司已采取各種方法來解決這一難題。以下是避免ETL的四種可能方法。

[[276359]]

1. 合并OLTP和OLAP

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

如今，許多新的擴(kuò)展關(guān)系數(shù)據(jù)庫還提倡使用“translytical”方法合并操作和分析操作，以加快處理時間。像Aersospike、MemSQL、Splice Machine和VoltDB這樣的供應(yīng)商，將集群架構(gòu)和內(nèi)存處理結(jié)合起來，以支持非?？焖俚腟QL查詢處理，足以支持Web和移動應(yīng)用程序并對它們進(jìn)行實時分析(但不一定是像ERP這樣的核心業(yè)務(wù)應(yīng)用程序)。

Forrester分析師Noel Yuhanna和Mike Gualtieri在2015年表示傳統(tǒng)的ETL流程無法實現(xiàn)實時更改。Translytical克服了這一挑戰(zhàn)，為關(guān)鍵業(yè)務(wù)數(shù)據(jù)提供了實時、可靠的視圖，確保信息來源準(zhǔn)確以及整個組織的一致性。

Garter支持一種類似于混合事務(wù)分析(HTAP)的方法。 NoSQL數(shù)據(jù)庫供應(yīng)商Couchbase通過其嵌入式SQL ++引擎支持這種方法用于查詢JSON數(shù)據(jù)，亞馬遜也是如此。

2. 給ELT一個機(jī)會

ETL中一個受歡迎的轉(zhuǎn)折是改變處理順序。不是在ETL過程中進(jìn)行所有重要的數(shù)據(jù)轉(zhuǎn)換，而是在將其加載到數(shù)據(jù)倉庫之后再進(jìn)行轉(zhuǎn)換——因此是ELT而不是ETL。這種方法在更現(xiàn)代的數(shù)據(jù)湖中很流行，在現(xiàn)代數(shù)據(jù)湖中，數(shù)據(jù)語義和模式不像在傳統(tǒng)數(shù)據(jù)倉庫中那樣嚴(yán)格執(zhí)行(如果它們被強(qiáng)制執(zhí)行的話)。

ELT在Hadoop中很受歡迎，在Hadoop中，客戶可以快速地存儲大量原始數(shù)據(jù)，然后在稍后運(yùn)行大量批處理工作，為后續(xù)處理(包括SQL分析和機(jī)器學(xué)習(xí))準(zhǔn)備數(shù)據(jù)。

如果您的數(shù)據(jù)工程師正在使用Apache Spark為下游數(shù)據(jù)科學(xué)和分析工作負(fù)載開發(fā)數(shù)據(jù)轉(zhuǎn)換管道，那么您一定會大吃一驚。因為他實際上是在編寫ELT工作，這是Spark最大的用例之一。Spark背后的Databricks公司于2017年推出了Delta，可以說是ELT和數(shù)據(jù)轉(zhuǎn)換即服務(wù)。ELT方法也用于一些NoSQL數(shù)據(jù)庫。

3.實時流式ETL

一些公司采用的是流式ETL方法，而不是事后批量轉(zhuǎn)換數(shù)據(jù)，即數(shù)據(jù)到達(dá)現(xiàn)場后不斷進(jìn)行處理和細(xì)化。這種方法可能不適用于傳統(tǒng)的ERP數(shù)據(jù)，但對于處理不斷增長的Web和移動應(yīng)用程序數(shù)據(jù)(本質(zhì)上是時間序列)來說，它可能是絕對必要的。

通過在數(shù)據(jù)到達(dá)時直接處理數(shù)據(jù)，開發(fā)人員可以避免在一個單獨的ETL階段來處理數(shù)據(jù)。本質(zhì)上說，這就是Apache Storm的創(chuàng)建者Nathan Marz在2011年提出的Lambda架構(gòu)，其中一個加速層 (Storm)可以快速處理數(shù)據(jù)，但可能不是100%準(zhǔn)確，而批處理層 (Hadoop)可以在稍后修復(fù)任何錯誤。

Apache Kafka的聯(lián)合創(chuàng)作者Jay Kreps在構(gòu)思Kappa架構(gòu)時也想到了類似的解決方案，這是Lambda的一個精簡版本，不包含單獨的加速和批處理層。相反，Kafka在流媒體事件數(shù)據(jù)生成過程中扮演著核心角色。

4. 直接數(shù)據(jù)映射

最小化ETL的另一個選項稱為直接數(shù)據(jù)映射，即源數(shù)據(jù)直接在其所在位置查詢，而不是將其移動到數(shù)據(jù)倉庫。這是Incorta所支持的方法，該公司由甲骨文(Oracle)前高管Osama Elkady于幾年前創(chuàng)建。

Incorta的直接數(shù)據(jù)映射方法仍然要求用戶將數(shù)據(jù)移動到數(shù)據(jù)湖，比如HDFS、S3或Azure Data Lake，并將其存儲為高度壓縮的Parquet文件。但是，通過在“提取”和“加載”步驟之間注入元數(shù)據(jù)標(biāo)記，它可以允許客戶跳過“T”部分。

“Incorta想表達(dá)的是，如果我們只將數(shù)據(jù)加載到另一個僅用于分析的數(shù)據(jù)庫中，會發(fā)生什么，如果我們按原樣獲取數(shù)據(jù)而不必對數(shù)據(jù)進(jìn)行扁平處理，會怎么樣?” Elkady指出: “它可以將查詢時間從小時級縮短到秒級。”

Incorta的方法很有效果，正如最近一輪3000萬美元的C輪融資所顯示的那樣。這家硅谷公司正在吸引大量客戶，包括蘋果(Apple)、博通(Broadcom)和星巴克(Starbucks)。Elkady表示:“如果客戶無法實時查看運(yùn)營數(shù)據(jù)，無論是制造業(yè)務(wù)、零售業(yè)務(wù)還是倉庫管理，都可能會損失數(shù)百萬美元。”

目前我們沒有辦法完全摒除ETL以及應(yīng)用它的麻煩。在完全使用相同一致數(shù)據(jù)格式的系統(tǒng)之前，仍然需要從一個地方獲取數(shù)據(jù)并為其應(yīng)用做好準(zhǔn)備，然后加載數(shù)據(jù)。但是，數(shù)據(jù)轉(zhuǎn)換的新方法可以幫助避免ETL應(yīng)用過程中的問題。