[[436702]]

【51CTO.com快譯】本文對軟件供應商為什么會為反向ETL引入新的解決方案，何時需要反向ETL，以及它如何適合企業(yè)的架構進行了分析和探討。而使用Apache Kafka等工具來處理動態(tài)數(shù)據(jù)的事件流是實時用例反向ETL的關鍵部分。

什么是ETL和反向ETL?

首先從了解術語開始，ETL和反向ETL是什么?

1.ETL(提取-轉換-加載)

ETL(提取-轉換-加載)是數(shù)據(jù)集成的常用術語。Informatica公司或Talend公司等供應商提供可視化編碼來實現(xiàn)強大的ETL管道。云計算將新的SaaS參與者和術語集成平臺即服務(iPaaS)帶入ETL市場，其供應商包括Boomi公司、SnapLogic公司或Mulesoft Anypoint公司。

大多數(shù)ETL工具針對大數(shù)據(jù)工作負載以批處理方式運行，或者使用SOAP/REST Web服務和API進行不可擴展的實時通信。ETL管道使用來自各種數(shù)據(jù)源的數(shù)據(jù)，對其進行轉換或聚合，并將處理之后的靜態(tài)數(shù)據(jù)存儲在數(shù)據(jù)接收器中，例如數(shù)據(jù)庫、數(shù)據(jù)倉庫或數(shù)據(jù)湖：

提取-加載-轉換(ELT)是一種非常相似的方法。但是，轉換和聚合發(fā)生在攝取到數(shù)據(jù)存儲區(qū)域之后：

Databricks和Snowflake等數(shù)據(jù)存儲和分析供應商推廣ELT方法也就不足為奇了。例如，Snowflake提出了“內部緩沖網(wǎng)格”，其中所有域和數(shù)據(jù)產(chǎn)品都構建在其云服務中。

2.反向ETL

顧名思義，反向ETL是ETL的反轉。這意味著將數(shù)據(jù)從數(shù)據(jù)存儲移動到第三方系統(tǒng)以“使數(shù)據(jù)可操作”的過程，正如解決方案的營銷人員所說：

數(shù)據(jù)從長期存儲系統(tǒng)(數(shù)據(jù)倉庫、數(shù)據(jù)湖)消耗。然后將數(shù)據(jù)推送到業(yè)務應用程序，例如Salesforce(CRM)、Marketo(營銷)或Service Now(客戶成功)，以利用它進行管道生成、營銷活動或客戶溝通。

用于反向ETL的產(chǎn)品和SaaS產(chǎn)品

人們只需在谷歌搜索引擎中搜索“反向ETL”，即可找到專門推銷其解決方案的供應商。他們還為“正常數(shù)據(jù)集成條款”支付廣告費用。因此，即使沒有搜索這些廠商，也很可能看到它們。這些廠商的大多數(shù)都是初創(chuàng)公司，他們圍繞反向ETL產(chǎn)品開展新業(yè)務。其軟件供應商包括Hightouch、Census、Grouparoo、Rudderstack、Omnata和Seekwell。

有趣的事實：如果搜索Snowflake的反向ETL，將搜索不到任何結果，因為他們希望將數(shù)據(jù)保存在他們的數(shù)據(jù)倉庫中。

所有ETL工具的一個關鍵優(yōu)勢和賣點是可視化編碼，因此是ETL管道開發(fā)和維護的上市時間。一些解決方案針對公民集成商(這是Gartner公司創(chuàng)造的術語)，即構建集成的業(yè)務人員。

1.反向ETL==銷售、營銷、客戶成功的實時數(shù)據(jù)

大多數(shù)反向ETL的成功案例都在談論關注銷售、營銷或客戶成功。這些用例吸引了業(yè)務部門。這些團隊不想購買像Informatica或Talend這樣的ETL工具。企業(yè)期望提供簡單直觀的用戶界面，就像公民集成商一樣。

供應商以業(yè)務人員為目標，并承諾提供簡化的技術基礎設施。例如，一家供應商表示，可以淘汰遺留中間件并減少ETL工作。而這讓人想到了“影子IT”。

盡管如此，了解一下反向ETL的用例：

• 在發(fā)生之前識別有風險的客戶和潛在的客戶流失。
• 通過關聯(lián)來自CRM和其他界面的數(shù)據(jù)來推動新的銷售。
• 用于向現(xiàn)有客戶進行交叉銷售和追加銷售的超個性化營銷。
• 運營分析以更快地監(jiān)控業(yè)務應用程序和數(shù)據(jù)的變化。
• 將數(shù)據(jù)復制到現(xiàn)代云計算應用程序，以獲得更好的報告功能和洞察力。

此外，所有供應商都討論了上述用例的實時數(shù)據(jù)。但不幸的是，反向ETL是構建實時用例的巨大反模式。以下更詳細地探討原因。

2.反向ETL+數(shù)據(jù)湖+實時==神話

以上描述的一些用例非常好，具有巨大的商業(yè)價值。這些實時用例是使用活動中的事件流處理數(shù)據(jù)構建的。

如果將數(shù)據(jù)存儲在數(shù)據(jù)倉庫或數(shù)據(jù)湖中，則無法再實時處理它，因為它已經(jīng)處于靜止狀態(tài)。這些數(shù)據(jù)存儲是為索引、搜索、批處理、報告、模型訓練和其他在存儲系統(tǒng)中有意義的用例而構建的。但是不能從靜態(tài)存儲中實時消耗動態(tài)數(shù)據(jù)：

這就是事件流發(fā)揮重要作用的地方。Apache Kafka等平臺支持實時處理事務和分析工作負載的動態(tài)數(shù)據(jù)。因此了解現(xiàn)代企業(yè)架構，它利用事件流進行動態(tài)數(shù)據(jù)處理，利用數(shù)據(jù)倉庫或數(shù)據(jù)湖進行靜態(tài)數(shù)據(jù)處理。

企業(yè)架構中的反向ETL

以下探討反向ETL如何適應企業(yè)架構，以及何時需要一個單獨的工具。為此先了解反向ETL有什么作用?它從存儲中提取數(shù)據(jù)，轉換或聚合數(shù)據(jù)，然后將其攝取到業(yè)務應用程序中。

反向ETL有兩個選項：SQL查詢和變更數(shù)據(jù)捕獲(CDC)。

1.反向ETL==SQL查詢與變更數(shù)據(jù)捕獲

如果反向ETL工具使用SQL，那么它通常是對靜態(tài)數(shù)據(jù)的查詢。這一用例使業(yè)務人員能夠在直觀的用戶界面中創(chuàng)建查詢。其用例包括創(chuàng)建新的營銷活動或分析客戶成功之旅。基于SQL的反向ETL需要易于使用的直觀工具。

如果反向ETL工具提供實時數(shù)據(jù)關聯(lián)并推送通知，則它使用變更數(shù)據(jù)捕獲(CDC)。CDC是自動化的，可以實時處理數(shù)據(jù)存儲中的變化。管道包括來自不同數(shù)據(jù)源的數(shù)據(jù)關聯(lián)以及向業(yè)務應用程序發(fā)送實時推送消息?；贑DC的反向ETL需要可擴展、可靠的事件流基礎設施。

眾所周知，SQL和CDC方法都有自己的用例，有時在工具和基礎設施方面有重疊?；谧兏罩镜腃DC通常是首選的技術方法，而不是在重復計劃中與SQL同步數(shù)據(jù)或在通過調用API觸發(fā)時同步數(shù)據(jù)，無論是只使用事件流平臺還是特定的Revere ETL產(chǎn)品。

然而，更重要的問題是如何設計企業(yè)架構來避免對反向ETL的需求。

2.事件驅動架構+流式ETL==內置反向ETL

實時數(shù)據(jù)勝過處理過程較慢的數(shù)據(jù)。對于大多數(shù)用例來說都是如此。因此，事件驅動架構的興起勢不可擋：

現(xiàn)代事件驅動架構不需要反向ETL。它“內置”在開箱即用的架構中。如果合適且技術上可行，每個消費者都會直接實時消費數(shù)據(jù)。數(shù)據(jù)倉庫或數(shù)據(jù)湖仍然以近乎實時或批量的方式按自己的節(jié)奏使用它：

Kafka原生的流式SQL引擎ksqlDB提供了CDC功能和連續(xù)流處理。因此，如果營銷需要的急，甚至可以將ksqlDB稱為反向ETL工具。

如果想了解有關構建實時數(shù)據(jù)平臺的更多信息，人們可以查看一篇名為“Kappa架構是替代Lambda的主流”的文章。這篇文章探討了Uber、Shopify和Disney等公司如何為任何用例構建事件驅動的Kappa架構，其中包括實時、近實時、批處理和請求響應。

什么時候需要反向ETL?

從頭開始構建的以事件流平臺為核心的全新架構不需要反向ETL來消費來自數(shù)據(jù)倉庫或數(shù)據(jù)湖的數(shù)據(jù)，因為每個消費者已經(jīng)可以實時消費數(shù)據(jù)。

然而，為業(yè)務用戶提供接口并不能通過像Apache Kafka這樣的事件流平臺開箱即用地解決。而需要添加其他工具，例如Kafka CDC連接器或具有直觀用戶界面的第三方工具。因此，反向ETL可以在兩種情況下提供幫助：棕地架構和面向業(yè)務用戶的簡單工具。

在棕地架構中的數(shù)據(jù)可以靜態(tài)存儲，業(yè)務人員需要在業(yè)務應用程序中使用它。對于銷售、營銷或客戶成功用例，需要將數(shù)據(jù)從數(shù)據(jù)存儲中推出：

與傳統(tǒng)的ETL和iPaaS解決方案相比，面向業(yè)務人員的簡單集成工具更加直觀且易于使用。即使采用全新的方法，反向ETL工具可能仍然是最簡單的解決方案，并提供最佳的上市時間。

此外，需要記住的是，Salesforce或SAP等現(xiàn)代工具已經(jīng)提供了基于事件的界面。Elastic、Splunk或Snowflake等數(shù)據(jù)存儲供應商也在流媒體層上進行了大量投資，以與Apache Kafka等工具進行本地集成。與業(yè)務應用程序的集成可以通過實時事件流而不是通過來自數(shù)據(jù)存儲的反向ETL進行集成。出于這些原因需要評估的業(yè)務問題，以及是否需要事件流平臺、反向ETL工具或兩者的組合。

反向ETL的Kafka示例

以下來看兩個具體的例子。

1.Apache Kafka+Salesforce+Oracle CDC+Snowflake

以下架構結合了實時數(shù)據(jù)流、變更數(shù)據(jù)捕獲、數(shù)據(jù)湖和反向ETL云服務：

關于這個架構的一些注意事項：

• 中樞神經(jīng)系統(tǒng)是一個事件流平臺(Confluent Cloud)，提供可擴展的實時數(shù)據(jù)流和任何數(shù)據(jù)源和接收器之間的真正解耦。
• SaaS云服務(Salesforce)為基于事件的實時集成提供了本地的異步API。
• 使用Confluent的Oracle CDC連接器用于Kafka Connect，通過更改數(shù)據(jù)捕獲將傳統(tǒng)關系數(shù)據(jù)庫(Oracle)與反向ETL集成。
• 使用Kafka Streams和ksqlDB等流處理工具連續(xù)處理來自所有數(shù)據(jù)源的數(shù)據(jù)。
• 將數(shù)據(jù)攝取到數(shù)據(jù)倉庫(Snowflake)中，該數(shù)據(jù)倉庫配置為Confluent Cloud完全托管的Kafka Connect連接器的一部分。
• 業(yè)務用戶利用專用的反向ETL解決方案(Seekwell)將數(shù)據(jù)從數(shù)據(jù)倉庫(Snowflake)獲取到業(yè)務應用程序(Google Sheets)中。

基礎設施提供了一個基于事件的、可擴展的、可靠的實時神經(jīng)系統(tǒng)。每個應用程序都可以實時使用和處理動態(tài)數(shù)據(jù)(如果需要)。靜態(tài)數(shù)據(jù)存儲是批處理用例的補充，并與基于事件的平臺集成。

這種架構真正解耦了應用程序，避免了點對點的“意大利面條式”通信，并支持所有技術、云計算服務和通信模式。

2.使用Kafka在動態(tài)中利用Splunk攝取層

避免存儲系統(tǒng)需要反向ETL的另一個選擇是利用現(xiàn)有的存儲攝取層。

Confluent的Splunk S2S連接器就是一個很好的例子。假設企業(yè)已經(jīng)擁有數(shù)百或數(shù)千個通用轉發(fā)器(UF)和重型轉發(fā)器(HF)。在這種情況下，這種方法允許用戶經(jīng)濟高效且可靠地將數(shù)據(jù)從Splunk Forwarders讀取到Kafka。它使用戶能夠將數(shù)據(jù)從通用轉發(fā)器轉發(fā)到Kafka主題中，以解鎖數(shù)據(jù)的分析能力：

不要設計靜態(tài)數(shù)據(jù)來反轉

良好的企業(yè)架構不應該一開始就以規(guī)劃反向ETL為目標。只有在數(shù)據(jù)靜態(tài)存儲的棕地架構中才需要它，而不是為實時和批量數(shù)據(jù)接收器構建基于事件的架構。反向ETL支持影子IT和意大利面條式架構。事件流本質上支持實時數(shù)據(jù)集成。

然而，反向ETL工具適用于棕地方法(在理想情況下通過持續(xù)更改數(shù)據(jù)捕獲，而不是重復的SQL)或如果業(yè)務用戶需要簡單、直觀的用戶界面。因此，事件流和反向ETL是互補的。同樣，事件流和數(shù)據(jù)倉庫/數(shù)據(jù)湖是互補的。

原文標題：When to Use Reverse ETL and When It Is an Anti-pattern，作者：Kai Wähner

【51CTO譯稿，合作站點轉載請注明原文譯者和出處為51CTO.com】