本發(fā)明涉及數據庫領域，特別涉及一種Hadoop數據庫HBase的查詢方法及裝置。

背景技術：

HBase(Hadoop Database，Hadoop數據庫)是一個開源、分布式、面向列存儲、可伸縮的非關系數據庫，HBase構建在HDFS(Hadoop Distributed File System,Hadoop分布式文件系統(tǒng))之上，用于對海量數據隨機、實時的訪問。HBase采用RPC(Remote Procedure Call Protocol，遠程過程調用協(xié)議)機制作為主要通信手段?？蛻舳薈lient通過RPC機制與HMaster(Hadoop Master，Hadoop管理器)和HRegionServer(Hadoop Region Server，Hadoop地區(qū)服務器)進行通信以發(fā)送操作請求。HMaster響應管理類的操作，HRegionServer響應數據的讀寫操作。

現有HBase的查詢方法采用基于單請求隊列CallQueue的優(yōu)先級調度策略，作業(yè)隊列維護開銷大。當有新作業(yè)到達時，需要對整個隊列重新排序，增加了等待作業(yè)隊列的維護開銷。而嚴格地按優(yōu)先級次序來完成作業(yè)調度，還可能導致低優(yōu)先級的作業(yè)長期得不到執(zhí)行，使得整個HBase集群的服務質量無法保證。且未考慮如何為高優(yōu)先級用戶提供更優(yōu)質的服務體驗。

現有HBase的查詢方法主要針對單一應用、用戶的詳單查詢業(yè)務。當多個用戶同時使用HBase做詳單查詢時，無法靈活地根據用戶身份、優(yōu)先級，來分配合適的查詢資源，無法實現云計算形態(tài)的大數據服務。

技術實現要素：

本發(fā)明要解決的技術問題是提供一種Hadoop數據庫HBase的查詢方法及裝置，解決現有技術中HBase的查詢方法無法保證整體用戶的體驗，不能為 高優(yōu)先級用戶提供更優(yōu)質服務，無法實現云計算形體的大數據服務的問題。

為解決上述技術問題，本發(fā)明的實施例提供一種Hadoop數據庫HBase的查詢方法，包括：

接收用戶的查詢請求，并將所述查詢請求反序列化成Call查詢作業(yè)；

獲取所述Call查詢作業(yè)所歸屬用戶的用戶優(yōu)先級；

根據預先設置的用戶優(yōu)先級和查詢優(yōu)先級的對應關系，將所述Call查詢作業(yè)放到多個請求隊列CallQueue中的一個請求隊列CallQueue中，其中每個請求隊列CallQueue具有一個查詢優(yōu)先級，不同請求隊列CallQueue之間的查詢優(yōu)先級不同；

根據所述請求隊列CallQueue的查詢優(yōu)先級，處理所述請求隊列CallQueue中的Call查詢作業(yè)，得到查詢結果；以及

將所述查詢結果返回給用戶。

其中，所述查詢方法還包括：

建立一個資源跟蹤線程，監(jiān)聽每個請求隊列CallQueue的隊列信息，并根據所述隊列信息對所述請求隊列CallQueue進行動態(tài)資源調度。

其中，所述隊列信息包括負載數量和平均響應時延，所述動態(tài)資源包括請求隊列CallQueue的隊列資源；

相應地，所述建立一個資源跟蹤線程，監(jiān)聽每個請求隊列CallQueue的隊列信息，并根據所述隊列信息對所述請求隊列CallQueue進行動態(tài)資源調度，具體包括：

建立一個資源跟蹤線程，監(jiān)聽每個請求隊列CallQueue的負載數量和平均響應時延；

根據所述負載數量和所述平均響應時延，對所述請求隊列CallQueue的隊列資源進行調度。

其中，所述根據所述負載數量和所述平均響應時延，對所述請求隊列CallQueue的隊列資源進行調度，具體包括：

根據所述負載數量和所述平均響應時延，從多個請求隊列CallQueue中，獲取負載數量小于隊列資源限定的最大門限值，且平均響應時延大于預設閾值的請求隊列CallQueue的空閑隊列資源；

將所述空閑隊列資源分配給負載數量大于隊列資源限定的最大門限值或平均響應時延小于預設閾值的請求隊列CallQueue。

其中，每個請求隊列CallQueue預先配置有不同的處理線程資源，所述隊列信息包括Call查詢作業(yè)數量和平均響應時延，所述動態(tài)資源包括請求隊列CallQueue的處理線程資源；

相應地，建立一個資源跟蹤線程，監(jiān)聽每個請求隊列CallQueue的隊列信息，并根據所述隊列信息對所述請求隊列CallQueue進行動態(tài)資源調度，具體包括：

建立一個資源跟蹤線程，監(jiān)聽每個請求隊列CallQueue的Call查詢作業(yè)數量和平均響應時延；

根據所述Call查詢作業(yè)數量和所述平均響應時延，對所述請求隊列CallQueue的處理線程資源進行調度。

其中，所述根據所述Call查詢作業(yè)數量和所述平均響應時延，對所述請求隊列CallQueue的處理線程資源進行調度，具體包括：

根據所述Call查詢作業(yè)數量和所述平均響應時延，從多個請求隊列CallQueue中，獲取Call查詢作業(yè)數量小于處理線程資源具有的線程數量，且平均響應時延大于預設閾值的請求隊列CallQueue的空閑處理線程資源；

將所述空閑處理線程資源分配給Call查詢作業(yè)數量大于處理線程資源具有的線程數量或平均響應時延小于預設閾值的請求隊列CallQueue。

其中，所述獲取所述Call查詢作業(yè)所歸屬用戶的用戶優(yōu)先級，具體為：

根據所述Call查詢作業(yè)的網絡互聯協(xié)議IP地址，獲取所述Call查詢作業(yè)所歸屬用戶的用戶優(yōu)先級。

為解決上述技術問題，本發(fā)明的實施例還提供一種Hadoop數據庫HBase的查詢裝置，包括：

接收模塊，用于接收用戶的查詢請求，并將所述查詢請求反序列化成Call查詢作業(yè)；

獲取模塊，用于獲取所述Call查詢作業(yè)所歸屬用戶的用戶優(yōu)先級；

存放模塊，用于根據預先設置的用戶優(yōu)先級和查詢優(yōu)先級的對應關系，將所述Call查詢作業(yè)放到多個請求隊列CallQueue中的一個請求隊列CallQueue 中，其中每個請求隊列CallQueue具有一個查詢優(yōu)先級，不同請求隊列CallQueue之間的查詢優(yōu)先級不同；

處理模塊，用于根據所述請求隊列CallQueue的查詢優(yōu)先級，處理所述請求隊列CallQueue中的Call查詢作業(yè)，得到查詢結果；以及

返回模塊，用于將所述查詢結果返回給用戶。

其中，所述查詢裝置還包括：

調度模塊，用于建立一個資源跟蹤線程，監(jiān)聽每個請求隊列CallQueue的隊列信息，并根據所述隊列信息對所述請求隊列CallQueue進行動態(tài)資源調度。

其中，所述隊列信息包括負載數量和平均響應時延，所述動態(tài)資源包括請求隊列CallQueue的隊列資源；

相應地，所述調度模塊具體包括：

第一監(jiān)聽模塊，用于建立一個資源跟蹤線程，監(jiān)聽每個請求隊列CallQueue的負載數量和平均響應時延；

第一調度子模塊，用于根據所述負載數量和所述平均響應時延，對所述請求隊列CallQueue的隊列資源進行調度。

其中，每個請求隊列CallQueue預先配置有不同的處理線程資源，所述隊列信息包括Call查詢作業(yè)數量和平均響應時延，所述動態(tài)資源包括請求隊列CallQueue的處理線程資源；

相應地，所述調度模塊具體包括：

第二監(jiān)聽模塊，用于建立一個資源跟蹤線程，監(jiān)聽每個請求隊列CallQueue的Call查詢作業(yè)數量和平均響應時延；

第二調度子模塊，用于根據所述Call查詢作業(yè)數量和所述平均響應時延，對所述請求隊列CallQueue的處理線程資源進行調度。

其中，所述獲取模塊進一步用于根據所述Call查詢作業(yè)的網絡互聯協(xié)議IP地址，獲取所述Call查詢作業(yè)所歸屬用戶的用戶優(yōu)先級。

本發(fā)明的上述技術方案的有益效果如下：

在本發(fā)明實施例中，首先將接收的用戶的查詢請求反序列化成Call查詢作業(yè)；然后獲取Call查詢作業(yè)所歸屬用戶的用戶優(yōu)先級；再根據預先設置的用戶優(yōu)先級和查詢優(yōu)先級的對應關系，將Call查詢作業(yè)放到多個請求隊列 CallQueue中的一個請求隊列CallQueue中，其中每個請求隊列CallQueue具有一個查詢優(yōu)先級，不同請求隊列CallQueue之間的查詢優(yōu)先級不同；然后根據請求隊列CallQueue的查詢優(yōu)先級，處理請求隊列CallQueue中的Call查詢作業(yè)，得到查詢結果；最后將查詢結果返回給用戶。通過采用多請求隊列CallQueue調度，使不同優(yōu)先級的用戶查詢請求享有不同的查詢資源，在保證整體用戶體驗的同時，為高優(yōu)先級用戶提供了更優(yōu)質的服務體驗，實現了云計算形態(tài)的大數據服務。

附圖說明

圖1為本發(fā)明實施例的Hadoop數據庫HBase的查詢方法流程圖；

圖2為本發(fā)明實施例的Hadoop數據庫HBase的查詢方法一具體實現系統(tǒng)的第一結構示意圖；

圖3為本發(fā)明實施例的Hadoop數據庫HBase的查詢方法一具體實現系統(tǒng)的第二結構示意圖；

圖4為本發(fā)明實施例的Hadoop數據庫HBase的查詢方法應用一具體實現系統(tǒng)的流程圖；

圖5為本發(fā)明實施例的Hadoop數據庫HBase的查詢裝置的結構示意圖。

具體實施方式

為使本發(fā)明要解決的技術問題、技術方案和優(yōu)點更加清楚，下面將結合附圖及具體實施例進行詳細描述。

本發(fā)明實施例的Hadoop數據庫HBase的查詢方法，在保證整體用戶體驗的同時，為高優(yōu)先級用戶提供了更優(yōu)質的服務體驗。

如圖1所示，本發(fā)明實施例的Hadoop數據庫HBase的查詢方法，包括：

步驟11，接收用戶的查詢請求，并將所述查詢請求反序列化成Call查詢作業(yè)。

步驟12，獲取所述Call查詢作業(yè)所歸屬用戶的用戶優(yōu)先級。

步驟13，根據預先設置的用戶優(yōu)先級和查詢優(yōu)先級的對應關系，將所述Call查詢作業(yè)放到多個請求隊列CallQueue中的一個請求隊列CallQueue中， 其中每個請求隊列CallQueue具有一個查詢優(yōu)先級，不同請求隊列CallQueue之間的查詢優(yōu)先級不同。

這里，用戶優(yōu)先級和查詢優(yōu)先級按照優(yōu)先級別一一對應，如最高用戶優(yōu)先級對應最高查詢優(yōu)先級，最低用戶優(yōu)先級對應最低用戶優(yōu)先級。且每個請求隊列CallQueue根據查詢優(yōu)先級的不同享有不同規(guī)格的查詢資源，如具有最高查詢優(yōu)先級的請求隊列CallQueue享有最高規(guī)格的查詢資源，具有最低查詢優(yōu)先級的請求隊列CallQueue享有最低規(guī)格的查詢資源。

步驟14，根據所述請求隊列CallQueue的查詢優(yōu)先級，處理所述請求隊列CallQueue中的Call查詢作業(yè)，得到查詢結果；以及

步驟15，將所述查詢結果返回給用戶。

本發(fā)明實施例的Hadoop數據庫HBase的查詢方法，通過采用多請求隊列CallQueue調度，可靈活地根據用戶優(yōu)先級，來分配合適的查詢資源，使不同優(yōu)先級的用戶查詢請求享有不同規(guī)格的查詢資源，從而最終控制不同優(yōu)先級用戶的查詢請求的響應時延有差異。在保證整體用戶體驗的同時，為高優(yōu)先級用戶提供了更優(yōu)質的服務體驗，實現了云計算形態(tài)的大數據服務。

為了使多個請求隊列CallQueue都保持較高的運行效率，從而保證整體用戶的體驗，本發(fā)明的具體實施例中，所述查詢方法還可以包括：

步驟16，建立一個資源跟蹤線程，監(jiān)聽每個請求隊列CallQueue的隊列信息，并根據所述隊列信息對所述請求隊列CallQueue進行動態(tài)資源調度。

當然可以理解的是，步驟16可以是針對上述步驟13中所提及的請求隊列CallQueue進行動態(tài)資源調度。

此時，通過對請求隊列CallQueue進行動態(tài)資源調度，實現了多個請求隊列CallQueue之間的動態(tài)資源平衡，使多個請求隊列CallQueue都能保持在較高的運行效率，保證了整體用戶的體驗。

這里，可將監(jiān)聽到的隊列信息存入日志文件中，方便讀取和使用。

其中，所述隊列信息可包括負載數量和平均響應時延，所述動態(tài)資源可包括請求隊列CallQueue的隊列資源；

相應地，上述步驟16具體可以包括：

步驟161，建立一個資源跟蹤線程，監(jiān)聽每個請求隊列CallQueue的負載 數量和平均響應時延；

步驟162，根據所述負載數量和所述平均響應時延，對所述請求隊列CallQueue的隊列資源進行調度。

此時，通過監(jiān)聽請求隊列CallQueue的負載數量和平均響應時延，以對請求隊列CallQueue的隊列資源進行調度，可使負載較重的請求隊列CallQueue也具有充足的隊列資源。保證了負載較重的請求隊列CallQueue的運行效率，避免了負載過重的請求隊列CallQueue運行效率過慢，影響用戶體驗的問題，從而有效提高了整體用戶的體驗。

進一步的，上述步驟162具體可以包括：

步驟1621，根據所述負載數量和所述平均響應時延，從多個請求隊列CallQueue中，獲取負載數量小于隊列資源限定的最大門限值，且平均響應時延大于預設閾值的請求隊列CallQueue的空閑隊列資源。

這里，由于享有不同規(guī)格查詢資源的請求隊列CallQueue要求的響應時延也不同，因此可預先根據查詢優(yōu)先級設定每個請求隊列CallQueue要求的平均響應時延的閾值，以根據該閾值判斷請求隊列CallQueue的平均響應時延是否滿足對應查詢優(yōu)先級的要求。從而保證不同優(yōu)先級用戶的用戶體驗。

這里，若某個請求隊列CallQueue的負載數量小于隊列資源限定的最大門限值，且平均響應時延大于預設閾值，則該請求隊列CallQueue具有多余的隊列資源，且滿足自身查詢優(yōu)先級的要求。

步驟1622，將所述空閑隊列資源分配給負載數量大于隊列資源限定的最大門限值或平均響應時延小于預設閾值的請求隊列CallQueue。

這里，若某個請求隊列CallQueue的負載數量大于隊列資源限定的最大門限值，且平均響應時延小于預設閾值，則該請求隊列CallQueue的負載較重，隊列資源不夠用，且無法滿足自身查詢優(yōu)先級的要求。

此時，通過將獲取的空閑隊列資源給負載較重的請求隊列CallQueue。保證了負載較重的請求隊列CallQueue的運行效率，避免了負載過重的請求隊列CallQueue運行效率過慢，影響用戶體驗的問題，從而有效提高了整體用戶的體驗。

其中，每個請求隊列CallQueue預先配置有不同的處理線程資源，所述隊 列信息可包括Call查詢作業(yè)數量和平均響應時延，所述動態(tài)資源可包括請求隊列CallQueue的處理線程資源；

相應地，上述步驟16具體可以包括：

步驟163，建立一個資源跟蹤線程，監(jiān)聽每個請求隊列CallQueue的Call查詢作業(yè)數量和平均響應時延；

步驟164，根據所述Call查詢作業(yè)數量和所述平均響應時延，對所述請求隊列CallQueue的處理線程資源進行調度。

此時，通過監(jiān)聽請求隊列CallQueue的Call查詢作業(yè)數量和平均響應時延，以對請求隊列CallQueue的處理線程資源進行調度，可使具有較多Call查詢作業(yè)數量的請求隊列CallQueue具有充足的處理線程資源，從而保證了每個請求隊列CallQueue查詢作業(yè)的順利進行，進而保證了用戶體驗。

進一步的，上述步驟164具體可以包括：

步驟1641，根據所述Call查詢作業(yè)數量和所述平均響應時延，從多個請求隊列CallQueue中，獲取Call查詢作業(yè)數量小于處理線程資源具有的線程數量，且平均響應時延大于預設閾值的請求隊列CallQueue的空閑處理線程資源。

步驟1642，將所述空閑處理線程資源分配給Call查詢作業(yè)數量大于處理線程資源具有的線程數量或平均響應時延小于預設閾值的請求隊列CallQueue。

此時，通過將獲取的空閑處理線程資源分配給Call查詢作業(yè)數量較多的請求隊列CallQueue，保證了Call查詢作業(yè)數量較多的請求隊列CallQueue查詢處理的順利進行，從而保證了處理效率和用戶體驗。

優(yōu)選的，上述步驟1642之后，若所述空閑處理線程資源所在的請求隊列CallQueue的Call查詢作業(yè)數量增加到大于自身處理線程資源具有的線程數量，則收回所述空閑處理線程資源到該請求隊列CallQueue。

本發(fā)明的具體實施例中，上述步驟12具體可為：

步驟121，根據所述Call查詢作業(yè)的網絡互聯協(xié)議IP地址，獲取所述Call查詢作業(yè)所歸屬用戶的用戶優(yōu)先級。

此時，通過Call查詢作業(yè)的IP地址可準確獲取到Call查詢作業(yè)所歸屬的用戶，進而獲取到Call查詢作業(yè)所歸屬用戶的用戶優(yōu)先級，提高了操作的準確性和處理效率。

下面對本發(fā)明的一具體實現實施例舉例說明如下。

如圖2-3所示，本發(fā)明實施例的Hadoop數據庫HBase的查詢方法可通過接聽Listener模塊、連接Connection模塊、CallQueues模塊、處理Handlers模塊、請求隊列監(jiān)聽CallQueues Tracker模塊、Hadoop進程間通信調度HBaseIPCScheduler模塊和應答Responder模塊實現。

其中，上述步驟11可通過接聽Listener模塊來實現。Listener模塊包括多個子線程讀取Reader模塊和一個主線程Listener模塊。主線程Listener模塊負責接收用戶的查詢請求。子線程Reader模塊負責連接具體的查詢操作，將查詢請求反序列化成Call查詢作業(yè)。

其中，上述步驟12和步驟13可通過連接Connection模塊實現。具體的，Connection模塊從Listener模塊中讀出Call查詢作業(yè)，并根據Call查詢作業(yè)的IP地址獲取所歸屬用戶的用戶優(yōu)先級，最后根據預先設置的用戶優(yōu)先級和查詢優(yōu)先級的對應關系，將Call查詢作業(yè)放到多個請求隊列CallQueue中的一個請求隊列CallQueue中。

這里，多個請求隊列CallQueue可通過CallQueues模塊進行管理，且請求隊列CallQueue的數量可由HBase數據庫的管理員進行設置。由于用戶優(yōu)先級與請求隊列CallQueue的查詢優(yōu)先級一一對應，所以管理員通過設置用戶優(yōu)先級的數量n，便可決定請求隊列CallQueue的數量。如用戶優(yōu)先級的數量為n個，則請求隊列CallQueue的數量也為n個：P1CallQueue、P2CallQueue、…、PnCallQueue，其中n為大于或等于1的整數。

進一步的，上述步驟14可通過處理Handlers模塊實現。其中處理Handlers模塊包括多個與請求隊列CallQueue相對應的Handlers單元，每個Handlers單元根據對應請求隊列CallQueue的查詢優(yōu)先級，處理該請求隊列CallQueue中的Call查詢作業(yè)。

如請求隊列CallQueue包括：P1CallQueue、P2CallQueue、…、PnCallQueue，則Handlers模塊包括：P1Handlers、P2Handlers、…、PnHandlers。且P1Handlers處理P1CallQueue隊列中的查詢作業(yè)，P1Handlers處理P1CallQueue隊列中的查詢作業(yè)，PnHandlers處理PnCallQueue隊列中的查詢作業(yè)。如圖3所示，假定n為3，則請求隊列CallQueue的數量為3個：P1CallQueue、P2CallQueue、 P3CallQueue，且Handlers模塊包括：P1Handlers、P2Handlers、P3Handlers。

這里，每個請求隊列CallQueue預先配置有不同的處理線程資源，該處理線程資源即Handlers單元根據請求隊列CallQueue的查詢優(yōu)先級，預先分配的處理線程資源。其中，所有Handlers單元的處理線程資源總和不能超過Handlers模塊具有的總資源：P1Handlers+P2Handlers+…+PnHandlers≤hbase.regionserver.handler.count。

其中，上述步驟16可通過請求隊列監(jiān)聽CallQueues Tracker模塊、Hadoop進程間通信調度HBaseIPCScheduler模塊實現。

CallQueues Tracker模塊新建一個資源跟蹤線程，實時對每個請求隊列CallQueue的負載數量、Call查詢作業(yè)數量和平均響應時延等進行統(tǒng)計，并將統(tǒng)計結果存入日志文件，作為動態(tài)資源調度的依據。

HBaseIPCScheduler模塊根據負載數量、Call查詢作業(yè)數量和平均響應時延，對請求隊列CallQueue進行動態(tài)資源調度。這里，HBaseIPCScheduler模塊的調度策略可參照容量調度器Yarn的模型實現，對不同優(yōu)先級用戶采用不同的策略，保證高優(yōu)先級用戶查詢作業(yè)先執(zhí)行，對低優(yōu)先級用戶查詢作業(yè)兼顧公平性。

具體的，HBaseIPCScheduler模塊在根據負載數量和平均響應時延，判斷某個請求隊列CallQueue具有空閑隊列資源時，可將空閑隊列資源動態(tài)分配給負載較重的請求隊列CallQueue，以保證負載較重的請求隊列CallQueue的處理效率。HBaseIPCScheduler模塊在根據Call查詢作業(yè)數量和平均響應時延，判斷某個請求隊列CallQueue的處理Handlers具有空閑處理線程資源時，可將處理線程資源動態(tài)分配給Call查詢作業(yè)數量較多的請求隊列CallQueue，以保證請求隊列CallQueue查詢處理的順利進行，提高了處理效率，保證了整體用戶的體驗。也可在空閑處理線程資源所在的請求隊列CallQueue的Call查詢作業(yè)數量增加時，收回該空閑處理線程資源。

如當請求隊列P1CallQueue中待處理的Call查詢作業(yè)數量小于P1Handlers具有的線程數量，且平均響應時延大于預設閾值時，則可將多余的處理線程資源分配給負載較重的P2CallQueue或P3CallQueue使用。當P1CallQueue負載增加時，則收回分出的處理線程資源，用于處理P1CallQueue的作業(yè)。

進一步的，上述步驟15可通過應答Responder模塊實現，Responder模塊將查詢結果返回給用戶。

如圖4所示，應用如圖2所示的系統(tǒng)，本發(fā)明實施例的Hadoop數據庫HBase的查詢方法，包括：

步驟S01，配置參數：用戶優(yōu)先級的數量n、Handlers模塊具有的總資源(hbase.regionserver.handler.count)、每個請求隊列CallQueue(P1CallQueue、P2CallQueue、…、PnCallQueue)對應的Handlers單元(P1Handlers、P2Handlers、…、PnHandlers)的處理線程資源等。例如：n＝3、hbase.regionserver.handler.count＝100，P1Handlers＝50、P2Handlers＝30、P3Handlers＝20。然后根據配置參數，初始化CallQueues模塊和Handlers模塊。

步驟S02，Listener模塊接收用戶的查詢請求，將查詢請求反序列化成Call查詢作業(yè)。

步驟S03，Connection模塊從Listener模塊中讀出Call查詢作業(yè)，根據Call查詢作業(yè)的IP地址獲取所歸屬用戶的用戶優(yōu)先級，并根據用戶優(yōu)先級與查詢優(yōu)先級的對應關系，將Call查詢作業(yè)放入對應的CallQueue隊列中。

步驟S04，CallQueueTrackers模塊新建資源跟蹤線程，定時對每個請求隊列CallQueue的負載數量、Call查詢作業(yè)數量、平均響應時間等進行統(tǒng)計，將結果存入日志文件，并反饋給HBaseIPCScheduler模塊，作為動態(tài)調整資源的依據。

步驟S05，HBaseIPCScheduler模塊根據負載數量、Call查詢作業(yè)數量和平均響應時間對多個請求隊列CallQueue進行調度。

步驟S06，Handlers模塊執(zhí)行相應請求隊列CallQueue的查詢作業(yè)，將查詢結果返回給Responder模塊。

步驟S07，Responder模塊將查詢結果返回給用戶。

本發(fā)明實施例的Hadoop數據庫HBase的查詢方法，通過采用多請求隊列CallQueue調度，可靈活地根據用戶優(yōu)先級，來分配合適的查詢資源，使不同優(yōu)先級的用戶查詢請求享有不同規(guī)格的查詢資源，從而最終控制不同優(yōu)先級用戶的查詢請求的響應時延有差異。為高優(yōu)先級用戶提供了更優(yōu)質的服務體驗，實現了云計算形態(tài)的大數據服務。且使多個請求隊列CallQueue都保持在較高 的運行效率，有效保證了整體用戶的體驗。

現有技術中，HRegionServer端的RPC通信被實現為一個反應器Reactor模式的請求/響應隊列模型。所有的查詢請求在HRegionServer端被解碼后放入請求隊列CallQueue，交給處理器Handler線程池處理，Handler線程池不斷地從請求隊列CallQueue里取得查詢請求，交給HRegionServer執(zhí)行查詢，并將執(zhí)行結果以響應隊列ResponseQueue形式，依次返回給查詢客戶端。

現有HBase的查詢方法采用基于單請求隊列CallQueue的優(yōu)先級調度策略，無法保證整體用戶的體驗，不能為高優(yōu)先級用戶提供更優(yōu)質服務，無法實現云計算形體的大數據服務。

本發(fā)明實施例的Hadoop數據庫HBase的查詢方法，解決了現有技術的不足，在保證整體用戶體驗的同時，為高優(yōu)先級用戶提供了更優(yōu)質的服務體驗，實現了云計算形態(tài)的大數據服務。

如圖5所示，本發(fā)明的實施例還提供了一種Hadoop數據庫HBase的查詢裝置，包括：

接收模塊，用于接收用戶的查詢請求，并將所述查詢請求反序列化成Call查詢作業(yè)；

獲取模塊，用于獲取所述Call查詢作業(yè)所歸屬用戶的用戶優(yōu)先級；

存放模塊，用于根據預先設置的用戶優(yōu)先級和查詢優(yōu)先級的對應關系，將所述Call查詢作業(yè)放到多個請求隊列CallQueue中的一個請求隊列CallQueue中，其中每個請求隊列CallQueue具有一個查詢優(yōu)先級，不同請求隊列CallQueue之間的查詢優(yōu)先級不同；

處理模塊，用于根據所述請求隊列CallQueue的查詢優(yōu)先級，處理所述請求隊列CallQueue中的Call查詢作業(yè)，得到查詢結果；以及

返回模塊，用于將所述查詢結果返回給用戶。

本發(fā)明實施例的Hadoop數據庫HBase的查詢裝置，通過采用多請求隊列CallQueue調度，可靈活地根據用戶優(yōu)先級，來分配合適的查詢資源，使不同優(yōu)先級的用戶查詢請求享有不同規(guī)格的查詢資源，從而最終控制不同優(yōu)先級用戶的查詢請求的響應時延有差異。在保證整體用戶體驗的同時，為高優(yōu)先級用戶提供了更優(yōu)質的服務體驗，實現了云計算形態(tài)的大數據服務。

本發(fā)明的具體實施例中，所述查詢裝置還包括：

調度模塊，用于建立一個資源跟蹤線程，監(jiān)聽每個請求隊列CallQueue的隊列信息，并根據所述隊列信息對所述請求隊列CallQueue進行動態(tài)資源調度。

其中，所述隊列信息包括負載數量和平均響應時延，所述動態(tài)資源包括請求隊列CallQueue的隊列資源；

相應地，所述調度模塊具體包括：

第一監(jiān)聽模塊，用于建立一個資源跟蹤線程，監(jiān)聽每個請求隊列CallQueue的負載數量和平均響應時延；

第一調度子模塊，用于根據所述負載數量和所述平均響應時延，對所述請求隊列CallQueue的隊列資源進行調度。

進一步的，所述第一調度子模塊包括：

第二獲取模塊，用于根據所述負載數量和所述平均響應時延，從多個請求隊列CallQueue中，獲取負載數量小于隊列資源限定的最大門限值，且平均響應時延大于預設閾值的請求隊列CallQueue的空閑隊列資源；

第一分配模塊，用于將所述空閑隊列資源分配給負載數量大于隊列資源限定的最大門限值或平均響應時延小于預設閾值的請求隊列CallQueue。

其中，每個請求隊列CallQueue預先配置有不同的處理線程資源，所述隊列信息包括Call查詢作業(yè)數量和平均響應時延，所述動態(tài)資源包括請求隊列CallQueue的處理線程資源；

相應地，所述調度模塊具體包括：

第二監(jiān)聽模塊，用于建立一個資源跟蹤線程，監(jiān)聽每個請求隊列CallQueue的Call查詢作業(yè)數量和平均響應時延；

第二調度子模塊，用于根據所述Call查詢作業(yè)數量和所述平均響應時延，對所述請求隊列CallQueue的處理線程資源進行調度。

進一步的，所述第二調度子模塊包括：

第三獲取模塊，用于根據所述Call查詢作業(yè)數量和所述平均響應時延，從多個請求隊列CallQueue中，獲取Call查詢作業(yè)數量小于處理線程資源具有的線程數量，且平均響應時延大于預設閾值的請求隊列CallQueue的空閑處理線程資源；

第二分配模塊，用于將所述空閑處理線程資源分配給Call查詢作業(yè)數量大于處理線程資源具有的線程數量或平均響應時延小于預設閾值的請求隊列CallQueue。

其中，所述獲取模塊進一步用于根據所述Call查詢作業(yè)的網絡互聯協(xié)議IP地址，獲取所述Call查詢作業(yè)所歸屬用戶的用戶優(yōu)先級。

下面對本發(fā)明的一具體實現實施例舉例說明如下。

如圖2-3所示，上述接收模塊可通過Listener模塊實現，上述獲取和存放可通過Connection模塊實現，上述處理模塊可通過Handlers模塊實現，上述調度模塊可通過請求隊列監(jiān)聽CallQueues Tracker模塊和Hadoop進程間通信調度HBaseIPCScheduler模塊實現，上述返回模塊可通過Responder模塊實現。

本發(fā)明實施例的Hadoop數據庫HBase的查詢方法，通過采用多請求隊列CallQueue調度，可靈活地根據用戶優(yōu)先級，來分配合適的查詢資源，使不同優(yōu)先級的用戶查詢請求享有不同規(guī)格的查詢資源，從而最終控制不同優(yōu)先級用戶的查詢請求的響應時延有差異。為高優(yōu)先級用戶提供了更優(yōu)質的服務體驗，實現了云計算形態(tài)的大數據服務。且使多個請求隊列CallQueue都保持在較高的運行效率，有效保證了整體用戶的體驗。

本發(fā)明實施例的Hadoop數據庫HBase的查詢裝置，解決了現有技術的不足，在保證整體用戶體驗的同時，為高優(yōu)先級用戶提供了更優(yōu)質的服務體驗，實現了云計算形態(tài)的大數據服務。

需要說明的是，該實現Hadoop數據庫HBase的查詢裝置是與上述Hadoop數據庫HBase的查詢方法相對應的裝置，其中上述方法實施例中所有實現方式均適用于該裝置的實施例中，也能達到同樣的技術效果。

以上所述是本發(fā)明的優(yōu)選實施方式，應當指出，對于本技術領域的普通技術人員來說，在不脫離本發(fā)明所述原理的前提下，還可以作出若干改進和潤飾，這些改進和潤飾也應視為本發(fā)明的保護范圍。