[[436702]]

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

什么是ETL和反向ETL?

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

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

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

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

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

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

2.反向ETL

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

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

用于反向ETL的產品和SaaS產品

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

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

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

1.反向ETL==銷售、營銷、客戶成功的實時數據

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

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

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

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

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

2.反向ETL+數據湖+實時==神話

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

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

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

企業架構中的反向ETL

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

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

1.反向ETL==SQL查詢與變更數據捕獲

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

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

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

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

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

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

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

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

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

什么時候需要反向ETL?

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

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

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

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

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

反向ETL的Kafka示例

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

1.Apache Kafka+Salesforce+Oracle CDC+Snowflake

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

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

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

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

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

2.使用Kafka在動態中利用Splunk攝取層

避免存儲系統需要反向ETL的另一個選擇是利用現有的存儲攝取層。

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

不要設計靜態數據來反轉

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

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

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

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