NoSQL為什麼需要模式自由的ETL工具 ？

  瞭解一個開源工具，可以有效幫助人們解決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資料來源訪問他們選擇的商業智慧工具中的儀表盤。

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

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/31077337/viewspace-2154062/，如需轉載，請註明出處，否則將追究法律責任。