如今的數據往往來自文件系統、數據湖或存儲庫。

為了滿足各類業務需求，我們必須將數據與其他數據源的記錄系統相集成，從而支持分析、面向客戶的應用程序或者內部工作流。

而這又帶來了新的問題——我們該如何選擇正確的數據集成工具，從而對各類數據加以歸納?

今天的文章將就此展開探討。

數據不在一個數據庫，文件系統，數據庫或存儲庫中。

為了滿足許多業務需求，必須將數據與其他數據源的記錄系統集成，然后用于分析，面向客戶的應用程序或內部工作流程。

例子包括：　　

·來自電子商務應用程序的數據與用戶分析，客戶關系管理中的客戶數據以及其他主數據源集成在一起，以建立客戶群并定制營銷信息。　　

·物聯網傳感器數據與運營和財務數據庫中的數據相關聯，以控制吞吐量并報告制造過程的質量。　　

·員工工作流應用程序，可將跨多個SaaS平臺和內部數據源的數據和工具連接到一個易于使用的移動界面。　　

許多組織也對數據科學家，數據分析師和創新團隊提出了數據要求，他們在集成內部和外部數據源方面的需求日益增長：　　

·開發預測模型的數據科學家通常會加載多種外部數據源，例如計量經濟學，天氣，人口普查和其他公共數據，然后將其與內部資源融合。　

·試驗人工智能的創新團隊需要匯總可用于訓練和測試算法的大型復雜數據源。　　

·業務和數據分析師，特別是曾經在電子表格中執行分析的數據驅動營銷部門，現在可能需要更復雜的工具來加載，加入和處理多個數據饋送。　

1. 數據技術與功能市場規模龐大　　

問題是：用什么工具和做法來整合數據源?

什么平臺被用來自動化操作數據?

正在委托哪些工具供數據科學家和數據分析師在使用新數據源時更加努力?

在開發跨多個數據源和API進行交易的應用程序時，有效的開發和開發工具能夠實現更快速的應用程序開發?　　

由于許多組織具有不同類型，數量和速度的數據，并隨著時間的推移而產生不同的業務需求，因此可能已有不同的方法和工具用于集成數據。

很容易堅持這些，并將它們擴展到新的使用案例。雖然使用數據工具的任何人可能比其他人更熟悉一種方法，但對于具有多種業務和用戶需求的組織而言，應用一刀切的數據集成方法可能并不是最佳選擇。　　此外，隨著越來越多的組織投資于數據解決方案，大數據解決方案有一個健康的市場。

結果是現在有許多新的平臺和工具來支持數據集成和處理。　　

有了這么多的工具，希望將數據處理作為核心功能的組織應考慮各種工具類型，根據業務和技術需要應用這些工具類型。

與數據技術合作或負責數據技術的技術人員應該熟悉可用工具的類型。

在這里，我調查了七種主要類型的工具：　　

·編程和腳本數據集成　　

·傳統的提取，轉換和加載(ETL)工具　　

·數據高速公路SaaS平臺　　

·面向用戶和數據科學家的數據準備工具　　

·用于應用程序開發的API和數據集成　　

·具有數據集成功能的大數據企業平臺　　

·AI注入數據集成平臺　　

2. 數據集成編程與腳本　　

對于任何具有基本編程技能的人來說，將數據從源文件移動到目標文件的最常見方式是開發一個簡短的腳本。

這可以在具有存儲過程的數據庫內完成，作為按預定作業運行的腳本完成，也可以是部署到無服務器體系結構的小型數據處理代碼片段。　　

這些腳本通常以幾種模式之一運行。

它們可以按照預定義的時間表運行，也可以作為由事件觸發的服務運行，或者在滿足定義的條件時作出響應。

他們可以從多個來源獲取數據，在將數據傳送到目標數據源之前加入，過濾，清理驗證和轉換數據。　　腳本是移動數據的快捷方式，但它不被認為是專業級的數據處理方法。

要成為生產級的數據處理腳本，它需要自動執行處理和傳輸數據所需的步驟，并處理多種操作需求。

例如，如果腳本正在處理大量數據或快速移動的數據，則可能需要使用Apache Spark或其他并行處理引擎來運行多線程作業。

如果輸入數據不干凈，程序員應該啟用異常處理并在不影響數據流的情況下踢出記錄。

程序員還應該執行重要的計算步驟記錄以便于調試。　　

編寫腳本來支持這些操作需求并不是微不足道的。

它要求開發人員預測數據集成和相應程序可能出現的問題。

另外，開發自定義腳本在使用許多實驗數據源時可能不具有成本效益。

最后，數據集成腳本通常難以完成知識轉移知識，并且難以跨多個開發人員進行維護。　　

出于這些原因，具有較大數據集成需求的組織通常會超越編程和腳本數據集成。　　

3. 傳統提取、轉換與加載(簡稱ETL)工具　　

自20世紀70年代以來，抽取，轉換和加載(ETL)技術已經出現，IBM，Informatica，Microsoft，Oracle，Talend等平臺在功能，性能和穩定性方面已經成熟。

這些平臺提供可視化編程工具，讓開發人員能夠分解并自動執行從源中提取數據，執行轉換并將數據推送到目標存儲庫的步驟。

由于它們是可視化的，并將數據流分解為原子步驟，與難以解碼的腳本相比，管道更易于管理和增強。

另外，ETL平臺通常提供操作界面來顯示數據管道崩潰的位置并提供重啟它們的步驟。　　

多年來，ETL平臺增加了許多功能。

大多數人可以處理來自數據庫，平面文件和Web服務的數據，無論他們是在本地，在云中還是在SaaS數據存儲中。

它們支持各種數據格式，包括關系數據，XML和JSON等半結構化格式，以及非結構化數據和文檔。

許多工具都使用Spark或其他并行處理引擎來并行化作業。企業級ETL平臺通常包括數據質量功能，因此數據可以通過規則或模式進行驗證，并將異常發送給數據管理員進行解決。　　

一個常見的ETL示例是組織何時將銷售前景的新文件加載到CRM中。

在加載之前，這些數據源通常需要清理物理和電子郵件地址，這可以通過使用規則和標準數據源進行轉換來完成。

然后將清理后的記錄與CRM中已經存在的記錄進行匹配，以便現有記錄得到增強，同時添加之前沒有的數據并添加新記錄。

如果ETL很難確定某行是匹配還是新記錄，則可以將其標記為要審查的異常。　　當數據源持續提供新數據并且目標數據存儲的數據結構不會頻繁更改時，通常會使用ETL平臺。

這些平臺專為開發人員編寫ETL而設計，因此對于混合專有，商業和開放數據存儲的數據流操作最為有效。　　

4. 面向SaaS平臺的數據高速公路　　

但是，是否有更有效的方法從常見數據源中提取數據?也許主要數據目標是從Salesforce，Microsoft Dynamics或其他常見CRM程序中提取帳戶或客戶聯系人。

或者，營銷人員希望從Google Analytics等工具中提取網絡分析數據，或試圖將客戶數據推送到營銷工具(如Mailchimp)中。

您應該如何防止SaaS平臺成為云中的數據孤島，并輕松實現雙向數據流?　　

如果您已經擁有ETL平臺，請查看供應商是否提供通用SaaS平臺的標準連接器，或者有可以從開發合作伙伴處購買的市場。　　

如果您沒有在ETL平臺上進行投資，并且您的數據集成需求主要是連接通用平臺，那么您可能需要一個易于使用的工具來構建簡單的數據高速公路。　　

Scribe，Snaplogic和Stitch等數據高速公路工具提供了簡單的網絡界面，可以連接到常見的數據源，選擇感興趣的領域，執行基本轉換，并將數據推送到常用目的地。　　

數據高速公路的另一種形式有助于更接近實時地整合數據。

它通過觸發器進行操作，因此當源系統中的數據發生更改時，可以將其操作并推送到輔助系統。

IFTTT，Workato和Zapier就是這類工具的例子。

這些工具對于將單個記錄從一個SaaS平臺轉移到另一個SaaS平臺時使用“如果是這樣的”邏輯特別有用。在評估它們時，請考慮它們集成的平臺數量，處理邏輯的功能和簡單性以及價格，以及特定于您的需求的任何因素。　　

5. 面向用戶與數據科學家的數據準備工具　　

當非技術和技術含量較低的用戶想要加載和清理新的數據源時，有一種新的數據準備工具針對這些用戶，以幫助他們執行數據集成。　　

要實施基本的數據集成和混合，請考慮貴組織中任何商業智能系統已提供的數據集成功能。

Looker，QlikView和Tableau等工具提供基本的數據集成，建模和轉換。

您還可以使用它們發布和共享虛擬數據源。　　

如果數據科學家和數據分析師正在處理大量數據源或花費大量時間來處理數據，則與BI工具集成的數據準備工具可能是明智的投資。　　

什么是數據爭奪?這是業務用戶和數據科學家需要在數據源上進行的所有工作，以使其可用于分析。

它通常從分析數據開始，逐場分析顯示有多少百分比有數值與數據集有什么不同值。

使用配置文件數據，分析師會清理具有不同值的字段(例如“紐約”和“紐約”)，合并和刪除字段，或使用公式創建計算字段。

他們還可以執行行級操作，如刪除重復項和合并記錄。　　

數據準備工具通常圍繞類似電子表格的用戶界面進行設計，以便讓用戶可視化數據配置文件并混合數據源。

但與傳統電子表格不同，這些工具捕獲用戶執行的數據處理步驟并啟用可視化和編輯操作。

這些工具中的大多數可以使用它們捕獲的這些腳本來自動化具有持續運營需求的數據饋送的數據流。　　有獨立的數據準備工具，如Alteryx，Paxata和Trifacta。

另外，傳統的ETL廠商如IBM和Talend已經開發了面向商業用戶和數據科學家的數據準備工具。　　

6. 用于應用程序開發的API與數據集成方案　　

如果您的目標是開發需要連接到多個數據源和API的Web或移動應用程序，則有API和應用程序開發工具可以簡化這些集成。

這些工具不是將數據集成到中央存儲庫中，而是提供各種選項，以便在使用多個API和數據源時支持更快的應用程序開發。　　

應用程序集成有幾種不同的平臺類型和工具提供者Dell Boomi，Jitterbit和Mulesoft等平臺旨在簡化API和數據訪問，并充當數據總線以集中交互。

像Built.io，OutSystems和Pow Wow Mobile這樣的低代碼和移動開發平臺可以實現集成，并提供開發和開發環境，以快速構建和運行應用程序。　　

7. 大數據企業平臺與數據集成功能　　

如果您正在Hadoop或其他大數據平臺之上開發功能，您可以選擇將數據集成到這些數據存儲：　　

·您可以開發腳本或使用支持大數據平臺的ETL工具作為端點。　　

·您可以選擇具有ETL，數據治理，數據質量，數據準備和主數據功能的端到端數據管理平臺。　　

你可以做到這一點。　　

許多提供ETL工具的供應商也出售具有這些增加的大數據功能的企業平臺。

還有像Datameer和Unifi這樣的新興平臺可以實現自助服務(如數據準備工具)，但是可以在支持供應商的Hadoop發行版之上運行。　　

8. AI驅動型數據集成平臺　　

在跨腳本，ETL，數據準備，應用程序集成服務和大數據平臺的過程中，為開發人員，數據科學家，數據管理員和分析人員提供了大量實際的手動數據集成工作。

供應商知道這一點，而一些下一代數據集成工具和功能將包括人工智能(AI)功能，以幫助自動化重復性任務或識別難以找到的數據模式。

例如，Informatica正在營銷Claire，“智能數據平臺”，而Snaplogic正在營銷Iris，它“推動自我驅動整合”。　

9. 找到正確的數據集成工具組合　　

考慮到平臺類型，每個空間競爭的供應商數量以及用于分類選項的分析師術語，數據集成選項列表可能令人望而生畏。

那么，您如何才能為現在和未來的數據集成需求決定正確的工具組合?　　

簡單的答案是它需要一些紀律。

首先清點已經使用的工具，編制成功應用的使用案例的編目，并成功地使用這些工具捕獲人員。

向他們提供其他難以實施解決方案的示例用例，因此在尋找其他工具時可能會有所幫助。　　

了解數據集成主題專家的感受。

也許有數據集成腳本需要持續維護，財務團隊對重復性工作感到沮喪，或者使用ETL解決方案進行開發對于營銷團隊的需求來說太慢了。

也許數據科學家花費大量的時間用一種編程語言來糾纏數據并創建一個龐大的代碼庫。

也許很多數據集成需求都與少數標準平臺相關，并且標準化集成方法將帶來運營收益。　　

通過一個清單，數據集成專家團隊可以在請求新的或增強的數據集成時審查實施選項。

如果新的請求像已經實施并且正在工作的請求，則團隊應該有信心再次應用它。

如果不是，它可以選擇嘗試使用現有工具進行實施，或者考慮使用新工具進行概念驗證，如果這是一個高度不同的數據集成工作。　　

當有新的業務需求和不斷變化的技術環境時，這種整合用例和審查新用例的規范是最佳實踐。