ETL的發(fā)展歷程是什么，很多新手對此不是很清楚，為了幫助大家解決這個難題，下面小編將為大家詳細(xì)講解，有這方面需求的人可以來學(xué)習(xí)下，希望你能有所收獲。

創(chuàng)新互聯(lián)建站專業(yè)為企業(yè)提供前郭網(wǎng)站建設(shè)、前郭做網(wǎng)站、前郭網(wǎng)站設(shè)計、前郭網(wǎng)站制作等企業(yè)網(wǎng)站建設(shè)、網(wǎng)頁設(shè)計與制作、前郭企業(yè)網(wǎng)站模板建站服務(wù)，十多年前郭做網(wǎng)站經(jīng)驗，不只是建網(wǎng)站，更提供有價值的思路和整體網(wǎng)絡(luò)服務(wù)。

ETL是什么？ETL是Extract（提?。?、Transformation（轉(zhuǎn)換）和Load（加載）的首字母縮寫。簡而言之，ETL就是在兩個位置之間拷貝數(shù)據(jù)。

• Extract（提取）：從不同類型的數(shù)據(jù)源（包括數(shù)據(jù)庫）讀取數(shù)據(jù)。

• Transform（轉(zhuǎn)換）：將提取的數(shù)據(jù)轉(zhuǎn)換成特定的格式。轉(zhuǎn)換還包括使用系統(tǒng)中其他數(shù)據(jù)來豐富數(shù)據(jù)內(nèi)容。

• Load（加載）：將數(shù)據(jù)寫入到目標(biāo)數(shù)據(jù)庫、數(shù)據(jù)倉庫或者另一個系統(tǒng)中。

根據(jù)基礎(chǔ)設(shè)施的不同，ETL可以劃分為兩大類。

傳統(tǒng)ETL  

以前，數(shù)據(jù)通常都保存在操作系統(tǒng)、文件和數(shù)據(jù)倉庫中。每天，數(shù)據(jù)都要在這些位置之間移動多次。ETL工具和腳本都是現(xiàn)寫現(xiàn)用。

傳統(tǒng)ETL的工作流

這個架構(gòu)非常難以管理，而且非常復(fù)雜。下面是傳統(tǒng)ETL架構(gòu)的一些缺點(diǎn)：

• 數(shù)據(jù)庫、文件和數(shù)據(jù)倉庫之間的處理以批次進(jìn)行。

• 目前，大多數(shù)公司都需要分析并操作實時數(shù)據(jù)。但是，傳統(tǒng)的工具不適合分析日志、傳感器數(shù)據(jù)、測量數(shù)據(jù)等。

• 非常大的領(lǐng)域數(shù)據(jù)模型需要全局的結(jié)構(gòu)。

• 傳統(tǒng)ETL處理非常慢、非常耗時，而且需要大量資源。

• 傳統(tǒng)架構(gòu)僅關(guān)注已有的技術(shù)。因此，每次引入新的技術(shù)，應(yīng)用程序和工具都要重新編寫。

隨著時間一天天過去，大數(shù)據(jù)改變了處理的順序。數(shù)據(jù)先提取并加載到一個倉庫中，并以原始格式保存。每當(dāng)數(shù)據(jù)分析師或其他系統(tǒng)需要數(shù)據(jù)時再進(jìn)行轉(zhuǎn)換。這個過程叫做ELT。不過這個過程最適合在數(shù)據(jù)倉庫中進(jìn)行處理。如Oracle Data Integration Platform Cloud等系統(tǒng)提供了該功能。

ETL的現(xiàn)狀
與十年前相比，當(dāng)今世界的數(shù)據(jù)和處理狀況已經(jīng)發(fā)生了巨大的變化。使用傳統(tǒng)ETL過程處理現(xiàn)代數(shù)據(jù)已經(jīng)力不從心。部分原因如下：

• 現(xiàn)代數(shù)據(jù)處理通常包括實時數(shù)據(jù)的處理，而且組織也需要對處理過程的實時洞察。

• 系統(tǒng)需要在數(shù)據(jù)流上執(zhí)行ETL，不能使用批處理，而且應(yīng)該能夠自動伸縮以處理更高的數(shù)據(jù)流量。

• 一些單服務(wù)器的數(shù)據(jù)庫已經(jīng)被分布式數(shù)據(jù)平臺（如Cassandra、MongoDB、Elasticsearch、SAAS應(yīng)用程序等）、消息傳遞機(jī)制（Kafka、ActiveMQ等）和幾種其他類型的端點(diǎn)代替。

• 系統(tǒng)應(yīng)該能夠以可管理的方式加入額外的數(shù)據(jù)源或目的地。

• 應(yīng)當(dāng)避免由于“現(xiàn)寫現(xiàn)用”的架構(gòu)導(dǎo)致的重復(fù)數(shù)據(jù)處理。

• 改變數(shù)據(jù)捕獲技術(shù)的方式，從要求傳統(tǒng)ETL與之集成，變成支持傳統(tǒng)操作。

• 數(shù)據(jù)源多樣化，而且需要考慮新需求的可維護(hù)性。

• 源和目標(biāo)端點(diǎn)應(yīng)該與業(yè)務(wù)邏輯解耦合。使用數(shù)據(jù)映射層，將新的源和端點(diǎn)無縫地銜接，而且不影響數(shù)據(jù)轉(zhuǎn)換過程。

數(shù)據(jù)映射層

• 接收到的數(shù)據(jù)應(yīng)當(dāng)在轉(zhuǎn)換（或執(zhí)行業(yè)務(wù)規(guī)則）之前進(jìn)行標(biāo)準(zhǔn)化。

• 數(shù)據(jù)應(yīng)該在轉(zhuǎn)換之后、發(fā)布到端點(diǎn)之前轉(zhuǎn)換成特定的格式。

• 數(shù)據(jù)清理并不是現(xiàn)代世界中唯一的數(shù)據(jù)轉(zhuǎn)換過程。數(shù)據(jù)轉(zhuǎn)換還需要滿足組織的許多業(yè)務(wù)需求。

• 目前的數(shù)據(jù)處理通常包含過濾、連接、聚合、序列、模式和豐富化，以執(zhí)行復(fù)雜的業(yè)務(wù)邏輯。

數(shù)據(jù)處理過程

拯救世界的流式ETL
新的數(shù)據(jù)需求是驅(qū)動組織前進(jìn)的動力。許多組織中的絕大多數(shù)傳統(tǒng)系統(tǒng)依然能夠運(yùn)行，這些系統(tǒng)使用的都是數(shù)據(jù)庫和文件系統(tǒng)。這些組織也在嘗試新的系統(tǒng)和新技術(shù)。這些技術(shù)能夠處理大數(shù)據(jù)和增長和更快的數(shù)據(jù)速率（如每秒上萬條記錄），如Kafka、ActiveMQ等。使用流式ETL繼承架構(gòu)，組織不需要計劃、設(shè)計并實現(xiàn)一個復(fù)雜的架構(gòu)，就能填補(bǔ)傳統(tǒng)系統(tǒng)和現(xiàn)代系統(tǒng)之間的空白。流式ETL架構(gòu)師可伸縮的、可管理的，還能處理大容量、結(jié)構(gòu)多樣的實時數(shù)據(jù)。將數(shù)據(jù)提取和加載從數(shù)據(jù)轉(zhuǎn)換中解耦合，就構(gòu)成了源-目的地模型，該模型可以讓系統(tǒng)與未來的新技術(shù)向前兼容。這個功能可以通過許多系統(tǒng)實現(xiàn)，如Apache Kafka（配合KSQL）、Talend、Hazelcast、Striim和WS02 Streaming Integrator（配合Siddhi IO）。
現(xiàn)代ETL功能  

如上所述，傳統(tǒng)系統(tǒng)通常將所有數(shù)據(jù)都放到數(shù)據(jù)庫和文件系統(tǒng)中，以便進(jìn)行批處理。這個場景說明了為何傳統(tǒng)的事件源（如文件、改變數(shù)據(jù)捕獲（Change Data Capture，簡稱CDC））要與新的流式集成平臺集成。我們來考慮一個工廠中的實際應(yīng)用場景，它有以下功能。傳統(tǒng)系統(tǒng)：

• 將所有生產(chǎn)數(shù)據(jù)放到文件系統(tǒng)和數(shù)據(jù)庫中，數(shù)據(jù)的格式各異。

• 每小時或每天對數(shù)據(jù)進(jìn)行處理。

• 處理來自CDC的事件。

• 處理新系統(tǒng)通過HTTP收到的以事件為中心的數(shù)據(jù)。

• 將處理過的事件發(fā)送到多個目的地。

• 監(jiān)視當(dāng)前的庫存，在需要新庫存的時候發(fā)送通知。

• 使用庫存數(shù)量查看分析結(jié)果。

傳統(tǒng)的ETL工具：

• 下述處理的ETL邏輯是重復(fù)的：

• 對于每個結(jié)構(gòu)不同的文件和數(shù)據(jù)庫。

• 當(dāng)目標(biāo)或源端點(diǎn)的數(shù)量增加時。

• 重復(fù)的業(yè)務(wù)邏輯很難管理和伸縮。

• 分析和監(jiān)視所需的數(shù)據(jù)計算是重復(fù)的。

流式平臺架構(gòu)如何解決現(xiàn)代ETL問題：

現(xiàn)代流式平臺的工作流

• 源（例如文件、CDC、HTTP）和目標(biāo)端點(diǎn)（如Kafka、Elasticsearch、Email）從處理過程中解耦合：

• 目標(biāo)、源和存儲API連接到多個數(shù)據(jù)源。

• 即使源和目標(biāo)中的數(shù)據(jù)結(jié)構(gòu)不同，數(shù)據(jù)映射（如data mapper）層和流SQL（如Query1）也會把從多個源接收到的事件轉(zhuǎn)換成通用的源定義（如Stream1），以便以后進(jìn)行處理。

• 流平臺架構(gòu)可以連接傳統(tǒng)類型的數(shù)據(jù)源（如文件和CDC），和廣泛應(yīng)用的現(xiàn)代數(shù)據(jù)源（如HTTP）。

• 傳統(tǒng)系統(tǒng)和現(xiàn)代系統(tǒng)生成的事件都用同一個工作流進(jìn)行接收和分析。

• 聚合（如Aggregation1）按照每分鐘、每小時等頻率針對需要的屬性進(jìn)行計算。

• 數(shù)據(jù)隨時按需進(jìn)行匯總，不需要對整個數(shù)據(jù)集進(jìn)行處理和匯總。應(yīng)用程序和可視化、監(jiān)視工具可以通過提供的API訪問匯總后的數(shù)據(jù)。

• 可以無縫地添加并改變一個或多個業(yè)務(wù)邏輯（如BusinessRule1）。

• 可以添加任何邏輯，而無需改變已有組件。如上例中，根據(jù)BusinessRule1，當(dāng)緊急程度升高時，就會觸發(fā)一條Email消息。

通過上述架構(gòu)，我們可以看到為了ETL數(shù)據(jù)處理，流式平臺與傳統(tǒng)系統(tǒng)集成，如文件、CDC與使用Kafka和HTTP的現(xiàn)代系統(tǒng)的結(jié)合。

看完上述內(nèi)容是否對您有幫助呢？如果還想對相關(guān)知識有進(jìn)一步的了解或閱讀更多相關(guān)文章，請關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道，感謝您對創(chuàng)新互聯(lián)的支持。

名稱欄目：ETL的發(fā)展歷程是什么
轉(zhuǎn)載來源：http://chinadenli.net/article32/giijpc.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供Google、電子商務(wù)、標(biāo)簽優(yōu)化、小程序開發(fā)、移動網(wǎng)站建設(shè)、全網(wǎng)營銷推廣

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)