了解一個開源工具，可以有效幫助人們解決NoSQL在數據輸入、處理、輸出方面困難。大數據時代，不了解NoSQL數據庫的程序員大抵應該是沒有的吧！

許多NoSQL數據庫缺少工具和分析。本文，將討論模式無關（schema-agnostic）的現代ETL方法如何為NoSQL供應商和客戶提供幫助。對于涉及數據的任何操作或者一般計算，都需要實施三件事：輸入、處理、輸出。

NoSQL在輸入、處理、輸出方面的困難：令人不安的真相

NoSQL數據庫是存儲不同數據（結構快速變化的數據）的絕佳方式，例如在無法控制源格式的時候。

然而，用戶往往缺乏的是先進的工具，首先要處理數據（輸入部分），通過工具對數據進行高級分析和數據科學（處理部分），最后是顯示結果或可視化用戶的NoSQL數據庫（輸出部分）中包含的內容。

長期以來，這并沒有成為NoSQL采用的一種障礙。傳統上，采用NoSQL的開發人員使用對數據庫開發友好的API來將其封裝在一個定制的應用程序中。這對早期的NoSQL市場發展非常有效。

盡管如此，為了這個市場繼續得到增長，并挑戰傳統的數據庫廠商，更多的人需要采用NoSQL，而不僅僅是API的開發人員使用。

即使是開發人員也不喜歡寫乏味的“管道代碼”（plumbing code），這只是將數據從一個地方連接到另一個地方的代碼。這樣的代碼既單調又重復。客戶也不喜歡它，因為任何需要代碼的地方都不可避免地意味著需要更多的維護，更重要的是要花很長時間來編寫和測試。這意味著部署像NoSQL這樣的新技術需要增加更多的成本。

同樣，在輸出方面，如果用戶無法快速查看可從數據中收集到的見解，則無法完全了解投資NoSQL數據庫技術的好處。而試圖對問題進行編碼會導致項目時間延長，并且與上述自定義編碼相關的成本也會增加。

許多NoSQL公司都試圖將SQL支持融入其產品中，以彌合傳統商業智能（BI）供應商與其產品之間的差距。這只是達到了部分成功。商業智能在創建可視化的最后階段是一種非常固定的模式。這些SQL層卻添加了一些限制，并消除了NoSQL數據庫提供的一些非常好的靈活性和內置功能。因此，這樣做的客戶并沒有充分認識到NoSQL數據庫可以提供的好處，從而降低了投資回報。

由于這些原因，在NoSQL數據庫中保持數據的輸入、處理、輸出的自定義編碼大大增加了用戶使用NoSQL的障礙，并限制了NoSQL市場的增長。

因此，用戶所需要的是圍繞這些NoSQL數據庫提供更好的工具。

現在可以使用哪些工具？

帶有用戶界面的工具，使非開發人員用戶能夠與保存在各種系統中的數據進行交互，并以可視方式創建數據處理，從而減少了使用新技術的障礙。在傳統的關系數據庫（RDBMS）空間中，采用ETL（提取、轉換、加載）工具執行此功能。

當然，歷史性的問題是用戶的ETL過程在創建時是固定模式。在設計ETL過程中，用戶可以有效地對這些字段進行硬編碼。如果底層結構改變，那么在最好的情況下，新的數據將被忽略。而最糟糕的情況是用戶的ETL工作中斷。

在NoSQL世界中，數據結構是多種多樣的，而且經常改變，固定模式的ETL在用戶所能做的事情上限制太多。

但是NoSQL仍然可以從類似的工具中受益，這種工具可以使非開發人員從各種系統讀取數據，清理數據，發現數據信息，將數據與其他數據源合并，執行統計分析，以及機器學習等對其進行高級操作，然后將豐富的數據和新的見解存儲到目標數據庫，這通常是NoSQL數據庫或用于內存存儲的快速報告。

這些工具對于采用NoSQL的客戶非常有用。

模式靈活的ETL工具

人們喜歡使用易于使用的工具，以便從技術投資中獲得快速的業務收益。并希望采用與NoSQL協同工作的模式自由ETL。

有人會說：“ETL永遠不會那么靈活，在NoSQL中不會幫助我們！”其實并不是這樣。人們發現有一種方法可以執行模式自由的ETL，支持數百個數據的源和匯，機器學習以及將數據提供給可視化業務分析/商業智能儀表板層。還有一個開源的核心。

這個特殊的技巧是在Pentaho平臺的兩個特征之內進行的。這可以為Pentaho平臺企業版的所有者和供應商工作。確實如此。

但是，如果用戶不確定是否可以幫助解決NoSQL靈活架構工具問題的話，用戶不相信這個產品，也不會通過Pentaho數據集成使用開源ETL工具。

Pentaho數據集成看起來像所有其他固定模式的ETL工具。如果拖動導入步驟并將其指向數據源，則在數據流中看到的字段是在數據源中看到的字段，并且對于“轉換”（或流）的其余部分來說是固定的。

Pentaho數據集成（PDI）的元數據注入

Pentaho數據集成雖然有一個獨特的功能，稱為元數據注入。這使得父類轉換能夠動態地設置子轉換中的步驟配置。它用于許多稍微不同的轉換的地方。

元數據注入的一個很好的用例就是讀取一個數據源（例如一個關系數據庫）的位置，然后將這個數據結構發送到一個目標系統（例如一個NoSQL數據庫）。用戶可能會開發一個轉換來讀取其銷售表，并將其加載到銷售JSON文檔中，另一個轉換為客戶詳細信息，另一個轉換為In-Flight購物籃等等。

雖然為500個源表創建500個這樣的代碼會很糟糕。而這是大多數其他ETL工具面臨的問題。所有這些轉換看起來都是一樣的。他們可能會有十個步驟來加載數據，設置一些臨時變量（如JSON集合名稱，也許是在目標JSON結構中的一些常量或計算字段），然后將數據加載到特定的集合中。

500個轉換乘以10個步驟= 人工配置5000個步驟，這對于工作人員來說不堪重負。

元數據注入的好處在于用戶可以創建單個轉換來執行此加載，但是可以通過父轉換對其實施參數化。甚至可以在單個作業中配置此父轉換項，并在輸入數據源列表上循環以執行此項工作。

因此，現在只需創建兩個轉換：一個包含十個步驟，一個包含十個步驟的父步驟，循環遍歷表集，并使用元數據注入調用子轉換。兩個轉變總共只有20個步驟。工作人員可以進行輕松處理。

因此，利用Pentaho數據集成的元數據注入支持，使用足夠靈活的ETL工具可以將不同結構加載到NoSQL中，甚至可以實現更低的成本。

PDI輔助數據發現和語義關系發現

但是如何在Hadoop或NoSQL中加載一個可變數據湖，其中包含變化很大的結構呢？

那么，Pentaho數據集成也可以加載這些數據。用戶可以加載JSON數據（例如也支持XML），并將其解析到Pentaho中。 JSON輸入步驟也支持元數據注入。因此，用戶可以對數據進行采樣（即使只記錄一個記錄），然后調用調用元數據注入轉換來處理具有不同架構的數據。

甚至可以做更多的一些東西

行業專家日前與其數據科學團隊的同事共同開發了一個自定義的步驟，實現了更多的功能，它將在轉換中分析流中的所有數據，并輸出有關它的匯總統計數據。

其步驟所做的是確定每個數據的類型（不考慮源系統中的數據類型），并確定該字段是分類的還是連續的。它計算唯一的、空值和連續字段的數量，計算最小、最大、中位數和平均值，以及偏度和離散度。

簡而言之，需要確定源系統中每個字段和每個數據的組成。然后，將這些元數據存儲起來，以便通過元數據注入來驅動ETL過程

在NoSQL的世界里，變得相關的是從各種來源加載大量的數據，并通過數據科學，而不是通過人工配置來確定數據實體如何在系統間相互鏈接。

使用這種方法，結合元數據注入將允許Pentaho轉換加載多個數據源，并向集成開發人員提供組織數據中存在的實體以及這些實體之間關系的建議。

基本上，用戶可以使用Pentaho來發現整個組織數據之間的語義聯系。

然后，用戶可以使用這些信息動態地配置其目標系統和元數據注入，以加載數據并將其融合，并在目標（可能是NoSQL數據庫）中建立關系、語義關系模型和其他元數據。

如果用戶有成千上萬的源記錄類型，并且不希望在NoSQL數據庫（不管是文檔存儲區還是混合文檔圖/三重存儲）中人工配置這些元模型，這一點尤其有用。

工作人員在現有的演示銷售數據信息上運行了這個功能，并驚奇地發現語義圖在發現之后是多么有用。所有主要實體都在語義圖上出現在屏幕上，顯示出已發現的關系和數據類型，以及關聯的強度。

基本上，在NoSQL中使用Pentaho數據集成在數據發現、建模和數據加載開發方面為用戶節省了幾個月的的時間。

數據處理怎么樣？

Pentaho數據集成還在Pentaho市場上提供了無數的數據科學插件，統計功能和第三方插件。這意味著任何數據處理、數據工程、特性創建、統計建模或機器學習都需要用戶執行，用戶可以使用Pentaho進行編排。

無論底層數據存儲如何，Pentaho都可以成為這樣一個中心，因此客戶不必依靠數據庫供應商來嵌入這些設施，而NoSQL數據庫公司不需要投入數百萬美元的費用來構建它們。

即使在Spark，Python或R中集成機器學習，也只是一個簡單的例子，將單個步驟拖放到一個轉換上。

可視化NoSQL保存的數據

企業版Pentaho平臺的另一個強大功能就是Pentaho數據集成與Pentaho Business Analytics相結合來揭示數據服務。

數據服務在Pentaho數據集成（PDI）轉換中配置。用戶點擊任何一個步驟，然后說：“我現在所擁有的數據流，我想公開為JDBC兼容的數據源。”它可以是任何東西，例如一個CSV文件，一組NoSQL記錄等。當它被暴露時，數據集被賦予一個名稱，并且可以從任何JDBC兼容的商業智能工具連接到它。

這個數據服務可以有多個選項。為了減少對源系統的負載，它可以在一段時間內緩存和刷新。它還可以關鍵地將通過JDBC傳遞的WHERE子句“下推”（push down）到源系統中配置的“輸入”步驟。

這到底意味著什么？

可以把客戶編號“下推”到首先傳遞給NoSQL數據庫的查詢中，而不是從其NoSQL數據庫加載所有的客戶銷售，并將它們緩存在內存中。所以，數據服務就等同于帶有參數的簡單函數調用，只加載需要的數據來回答傳遞給數據服務的查詢。這比傳統的SQL翻譯層執行速度快得多。

Pentaho平臺可以為任何支持查詢，搜索或過濾的數據源執行此操作。例如，開發了數據服務來為使用MongoDB和MarkLogic服務器的客戶完成這項工作。例如，有一個本地的MongoDB步驟，使用MarkLogic的REST API將查詢下推到NoSQL數據庫。這很容易。然后，將其公開給Pentaho商業分析儀表板，可以在筆記本電腦上查詢和查看幾千條記錄，并在幾秒鐘內執行。

一旦想到如何做到這一點，花費五分鐘的時間來開發轉換，使用PDI將客戶數據加載到NoSQL中，另外五分鐘用于數據服務轉換，再用五分鐘用于配置儀表板。所以，從加載數據到洞察分析只有15分鐘。這很簡單。

當然，使用元數據注入和變量模式開發許多這些轉換將比這個簡單的例子花費更長的時間，但是與編寫數據加載代碼相比，這樣做速度更快，更不用說隨著時間的推移而進行的維護和開發。這里的ETL模型基本上是可視化構建和記錄的XML文件。

總結

在Pentaho數據集成（PDI）中，NoSQL社區可以訪問創建無架構和可變架構數據加載以及數據科學和集成轉換的能力，同時避免創建大量的轉換。從而，大大減少與NoSQL系統相關的執行成本。如果需要動態調用，也可以稱之為REST。

NoSQL社區還可以通過PDI Data Services over NoSQL數據源訪問他們選擇的商業智能工具中的儀表盤。

而且這個平臺目前已經可以使用，并且具有一個開源內核。建議可以下載并嘗試一下。

總結

以上是生活随笔為你收集整理的NoSQL为什么需要模式自由的ETL工具：不知道的大概都没用过！的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。