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

[[276358]]

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

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

由于BI項(xiàng)目的數(shù)據(jù)將來自于各種來源——包括在線事務(wù)處理(OLTP)系統(tǒng)、市場(chǎ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)中并不是一項(xiàng)簡單的任務(wù)。生產(chǎn)數(shù)據(jù)庫以不同的方式存儲(chǔ)數(shù)據(jù)，對(duì)必須費(fèi)力映射到數(shù)據(jù)倉庫的列使用特殊的命名約定。其中一些源系統(tǒng)甚至不是關(guān)系數(shù)據(jù)庫，而是專有的大型機(jī)文件系統(tǒng)或平面文件存儲(chǔ)，這更加大了難度。除了事務(wù)性數(shù)據(jù)之外，還有時(shí)間序列和地理數(shù)據(jù)，所有這些數(shù)據(jù)都必須經(jīng)過調(diào)整，以適應(yīng)所選擇的模式。

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

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

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

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

[[276359]]

1. 合并OLTP和OLAP

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

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

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

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

2. 給ELT一個(gè)機(jī)會(huì)

ETL中一個(gè)受歡迎的轉(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中，客戶可以快速地存儲(chǔ)大量原始數(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)換管道，那么您一定會(huì)大吃一驚。因?yàn)樗麑?shí)際上是在編寫ELT工作，這是Spark最大的用例之一。Spark背后的Databricks公司于2017年推出了Delta，可以說是ELT和數(shù)據(jù)轉(zhuǎn)換即服務(wù)。ELT方法也用于一些NoSQL數(shù)據(jù)庫。

3.實(shí)時(shí)流式ETL

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

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

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

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

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

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

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

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

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