[[436702]]

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

什么是ETL和反向ETL?

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

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

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

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

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

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

2.反向ETL

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

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

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

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

有趣的事實(shí)：如果搜索Snowflake的反向ETL，將搜索不到任何結(jié)果，因?yàn)樗麄兿Ｍ麑?shù)據(jù)保存在他們的數(shù)據(jù)倉庫中。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

眾所周知，SQL和CDC方法都有自己的用例，有時在工具和基礎(chǔ)設(shè)施方面有重疊。基于變更日志的CDC通常是首選的技術(shù)方法，而不是在重復(fù)計劃中與SQL同步數(shù)據(jù)或在通過調(diào)用API觸發(fā)時同步數(shù)據(jù)，無論是只使用事件流平臺還是特定的Revere ETL產(chǎn)品。

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

2.事件驅(qū)動架構(gòu)+流式ETL==內(nèi)置反向ETL

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

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

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

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

什么時候需要反向ETL?

從頭開始構(gòu)建的以事件流平臺為核心的全新架構(gòu)不需要反向ETL來消費(fèi)來自數(shù)據(jù)倉庫或數(shù)據(jù)湖的數(shù)據(jù)，因?yàn)槊總€消費(fèi)者已經(jīng)可以實(shí)時消費(fèi)數(shù)據(jù)。

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

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

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

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

反向ETL的Kafka示例

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

1.Apache Kafka+Salesforce+Oracle CDC+Snowflake

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

關(guān)于這個架構(gòu)的一些注意事項(xiàng)：

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

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

這種架構(gòu)真正解耦了應(yīng)用程序，避免了點(diǎn)對點(diǎn)的“意大利面條式”通信，并支持所有技術(shù)、云計算服務(wù)和通信模式。

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

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

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

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

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

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

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

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