隨著信息化的不斷深入發展，數據生成速度正在提高，需要處理的數據量急速膨脹，大數據時代即將到來。所謂大數據指所涉及的數據量規模巨大，以至於無法通過主流軟體在合理的時間內進行處理的數據。在面對海量數據時，傳統關係資料庫雖然具有支持完整性約束、支持事務等優點，但是在大規模海量數據面前顯得力不從心。傳統關係資料庫主要存在以下問題，一是在數據格式轉化和存儲方面無法滿足海量數據處理對性能的要求；二是無法滿足動態擴展和高可用性的需求；三是傳統大型關係資料庫通常運行在大型設備上，成本高昂。大數據對數據的存儲和處理方法提出了新的要求。如何有效地對這些大規模數據進行存儲、查詢、分析，已經成為一個亟待解決的問題，因此我們介紹幾種數據查詢系統。
基本介紹
- 中文名：數據查詢系統
- 外文名：consensus data
- 原因：需要處理的數據量急速膨脹
- 意義：有效地對大規模數據進行查詢
- 特點：高可用性、高容錯性
- 套用領域：計算機
介紹,hadoop模式,架構,設計,Probery模式,介紹,系統架構,
介紹
人、機、物三元世界的高度融合引發了數據規模的爆炸式增長和數據模式的高度複雜化，世界已進入網路化的大數據時代，大數據查詢技術備受關注並且得到廣泛研究。
大數據查詢技術是大數據管理的核心技術之一，伴隨著雲計算技術以及 NoSQL(Not Only SQL) 資料庫技術的發展，針對大數據查詢已經產生了許多新型的查詢技術。目前，關於大數據的查詢技術都是完整查詢，即無論如何定義查詢條件匹配算法(近似或精確) ，無論如何對查詢結果集排序，查詢都將確定地返回所有匹配數據，查詢所需的時間代價較大。 然而，在大數據環境下，很多實際套用表明，人們並不需要確定完整的查詢結果，也不需要對結果精確排序(如 Top—k查詢 ) ，僅需要滿足一定完整性要求的部分查詢結果，或可以適當地損失查詢完整性來滿足性能要求。 例如，在智慧型終端迅速普及和高速發展的現代社會，人們在出行過程中更多地通過移動設備來查詢附近的酒店、景點等，由於移動設備網路速度的限制以及完整查詢較高的時間代價，對於給定的查詢條件，返回全部查詢結果需要消耗較高的時間代價，然而，人們並不需要返回的結果集是全部數據，相反對回響時間的要求會更高 ，可通過減少數據傳輸量以及最佳化查詢技術來滿足此需求。
這裡介紹兩種查詢系統，一種是基於hadoop模式的數據查詢系統，另一種是基於機率的數據查詢系統。
hadoop模式
架構
Hadoop是分散式集群系統架構，它具有高可用性、高容錯性和高可擴展性等優點，用戶可以在完全不了解底層實現細節的情形下，開發適合自身套用的分散式程式。Hadoop由HDFS、MapReduce、HBase、Hive和ZooKeeper等成員組成，其中最基礎最重要的兩種組成元素為底層用於存儲集群中所有存儲節點檔案的檔案系統HDFS（Hadoop Distributed File System）和上層用來執行MapReduce程式的引擎。
設計
本系統基於Hadoop平台，採用HBase資料庫存儲海量交易記錄，整體架構如下圖所示。按照數據的流向劃分，系統可以分為四層，分別是：數據源、數據接入層、存儲層和查詢層。
數據接入層設計
由於數據源包括多種類型，因此，在進行數據接入層設計的時候，一是要對數據源隱藏數據接入層對HBas資料庫操作的細節，為不同類型數據源的數據導入提供一個統一的接口。在數據接入層中要保存HBase資料庫集群的地址、服務連線埠、ZooKeeper集群的地址等信息；要完成與HBase集群的連線。最終，只需調用數據接入層提供的簡單接口就可以從數據源中將數據導入HBase資料庫，同時，還要考慮到不同的數據導入方式，對接口進行最佳化以提高記錄導入效率。
存儲層設計
該層的實現是由Hadoop平台實現。存儲資料庫選用Hadoop組件中的HBase資料庫。該層主要是負責存儲整個系統的底層結構化數據。通常，在傳統關係資料庫的表設計中，通常以編號（唯一標識一條記錄）為主鍵、以各個屬性為列，創建表。而Hbase是一個稀疏的，排序的，長期存儲在硬碟上的，多維度的，映射表。這張表的索引是行關鍵字，列關鍵字和時間戳。每個值是一個不解釋的字元數組，數據都是字元串。用戶在表格中存儲數據，每一行都有一個可排序的主鍵和任意多的列。由於是稀疏存儲的，所以同一張表的每一行數據都可以有截然不同的列。列名字的格式是“<family>：<label>”，都是由字元串組成，每一張表有一個family集合，這個集合是固定不變的，相當於表的結構，只能通過改變表結構來改變。但是label值相對於每一行來說都是可以改變的。
HBase中表的各列都屬於某個 Column Family，通過對 HBase 資料庫系統的研究和測試表明，HBase目前不能良好的處理包含多個Column Family 的表，這是因為當表中的某個 Column Family觸發 flush刷新操作時，與這個 Column Family 相鄰的 Column Family 也會因關聯效應而觸發flush 刷新操作，從而導致系統中產生大量的I/O，降低了整個系統的性能。
時間同步設計
Hadoop 是部署在大規模分散式環境中的，由於集群中的機器配置和狀態各異，導致每一台機器上的時間可能不同，例如，某一台機器上的時間比另外一台快幾分鐘甚至幾小時。在大規模的實際套用場景中，集群中節點時間不同步的現象是一直存在的。因此，在集群中需要通過網路時間同步協定(Network Time Protocol，NTP)自動同步節點時間。在集群中的節點上安裝並啟動時間同步服務，使各節點自動同步自己的時鐘。
Map/Reduce設計
在系統中，數據首先會輸入到GFS上，然後把輸入的數據進行分區，把從數據源導入的數據分割成M個大小均為6M-64M的塊送入Cluster，分布到不同的機器上並行執行。在集群節點上首先選擇一個核心節點作為主控制程式master，master控制任務的分配，總共有M個map任務和R個reduce任務需要分配。Master會選擇空閒的worker來分配map任務和reduce任務。用戶數據輸入後，會分配一個map任務給worker，worker讀取並處理相關的檔案塊。Worker讀取塊後會處理數據，分析出key/value然後傳遞給用戶定義的map函式。Map函式將中間結果暫時存放在緩衝的記憶體中。Map worker執行結束後，它把數據處理的地址通知到主控制器master，master更新自身的數據結構，並且負責把這些信息告知Reduce worker。Master的工作流程好比報刊的訂閱/發行業務流，每當master的緩衝檔案的位置信息的結構更新時，他就告訴所有的正在運行狀態的Reduce worker。Recude worker會疊代所有的排序後的中間數據集合，並且把key和相關的中間結果值集合傳遞給用戶定義的reduce函式。Reduce函式會將內容輸出到一個最終的檔案中。
容錯設計
對於worker來說，由於Master維護同一個任務下所有Map worker和Reduce work的狀態信息，進行周期性的更新，如果發現有不回應的，Master就猜測該worker所在節點可能出現故障，對於Map worker（即使它完成了），它會另外找一台機器在上面啟一個新的worker重新執行失效worker的任務，而對於Reduce worker，如果完成了的話，就不需要重新執行，負責需要和Map 一樣處理。重新執行Map時，Master會將新的Map worker信息告知Reduce。對於Master來說，一般採用兩種方式容錯，一是就是有多個master實例，備份的master實例是inactive狀態，但是保持數據結構和工作中的master一致。一旦工作中的master宕機，馬上替換掉。二是間隔一段時間會將整個數據結構持久化到全局檔案系統中（類似於寫日誌），宕機後，就從上一個checkpoint重新開始啟動master進程。
查詢層設計
查詢層為用戶提供同系統進行互動的界面，主要包括三個模組，分別是用戶登入模組、用戶註冊模組、數據查詢模組。用戶登入模組用於用戶的登入，只有當用戶輸入了正確的用戶名和密碼才能進入查詢模組，進行數據的查詢操作；用戶註冊模組提供用戶的註冊功能；數據查詢模組的功能是進行交易記錄的查詢，查詢模組包括查詢界面，數據分析解析模組和查詢結果處理模組等。
Probery模式
這裡介紹大數據環境下的機率查詢系統——Probery。
介紹
Probery 是基於Hadoop分散式檔案系統(Hadoop Distributed File System， HDFS)和MapReduce 編程模型設計的一種大數據機率查詢系統。 Probery採用了一種基於機率的近似完整性查詢技術，其近似性主要體現在數據查全的可能性上，即查詢到滿足查詢條件的所有數據的機率，本研究將其稱之為查全機率(Recall Probability )。查全機率的定義和傳統的近似查詢以及模糊查詢不同，它不度量結果與查詢條件的匹配程度，也不度量結果集大小 ，而度量結果集是完整數據集的可能性。查全機率很小的結果集也可能是完整的，也可能包含大部分結果；查全機率大的查詢並不一定比查全機率小的查詢包含更多結果。 Probery 通過降低查全的可能性來換取性能，並且通過機率計算來保證查詢結果的查全機率。
系統架構
Probery 是基於機率的大數據查詢系統，系統根據給定的查全機率查詢滿足查詢條件的數據。為了實現大數據的分散式存儲和高效查詢，Probery 基於 Hadoop 平台來對系統進行架構，通過將數據按機率劃分為多個檔案並存儲在分散式檔案系統上，以縮小數據的查詢範圍，且保證查詢的並行性；同時也使得系統具有較強的容錯能力和水平伸縮性。Probery系統架構共包括 Hadoop Cluster、Data Placer、Data Querist、Job Node 和 Service Facade 這5個系統組件 。
Data Placer
Data Placer 主要負責數據的裝載工作，Data Placer將來自Data Source 的數據按照機率分布函式裝載到 Hadoop Cluster 中，並記錄數據的放置次數， 以求解數據的存在機率，存在機率是 Probery 進行機率查詢的元數據 (Meta Data) ，在完成數據的裝載工作後，Data Placer 將元數據傳遞給 Data Querist，並由其進行管理和維護。
Data Querist
Data Querist 主要負責數據的機率查詢，是系統的核心組件。 Data Querist接收來自Job Node 的數據查詢請求，按照查詢要求返回滿足查詢條件的數據的位置分布信息(Distribution Info) 。
Job Node
Job Node 負責查詢作業的管理工作，Job Node 接收來自Service Facade 的查詢請求，包括查詢屬性集以及 查全機率(Query Attribute & RecallRatio) ，通過Data Querist 得到需要查詢數據的位置信息，依此生成MapReduce 作業(MapReduce Job ) ，將作業遞交給 Hadoop Cluster 處理 ，當 Hadoop Cluster 完成作業的處理工作後，Job Node 接收來自Hadoop Cluster 的作業狀態匯報，如果作業處理成功，則將查詢報告傳遞給 Service Facade， 通知Service Facade 去獲取作業結果，如果作業運行失敗，則會重新提交作業。
Hadoop Cluster
Hadoop Cluster將 Hadoop 框架搭建在一個可擴展的分散式節點上，主要負責數據的分散式存儲以及並行化查詢，其中，通過 HDFS 來實現數據的分散式存儲，通過 MapReduce 來實現數據的並行查詢。 當 Job Node提交一個 MapReduce 查詢作業 (MapReduce Job) 時，Hadoop Cluster 根據作業要求完成作業的處理工作，將作業結果保存在 HDFS上，將作業狀態匯報 (Job Report) 給 Job Node，然後等待 Service Facade 來讀取作業結果。
Service Facade
