本發(fā)明涉及企業(yè)海量歷史數(shù)據(jù)查詢業(yè)務，具體地，涉及一種用于數(shù)據(jù)存儲、查詢的方法及系統(tǒng)。

背景技術：

企業(yè)海量歷史數(shù)據(jù)包括企業(yè)各個業(yè)務系統(tǒng)產(chǎn)生的歷史業(yè)務基礎數(shù)據(jù)和歷史業(yè)務明細數(shù)據(jù)等，通常從各種關系型數(shù)據(jù)庫中抽取出來形成。

大中型企業(yè)的業(yè)務繁多，由多個業(yè)務系統(tǒng)所支撐。每個業(yè)務系統(tǒng)有獨立的應用程序，業(yè)務過程中產(chǎn)生的數(shù)據(jù)都存放在應用的關系數(shù)據(jù)庫中。

企業(yè)的業(yè)務過程產(chǎn)生的數(shù)據(jù)通?？煞譃闃I(yè)務基礎數(shù)據(jù)和業(yè)務明細數(shù)據(jù)。

業(yè)務基礎數(shù)據(jù)記錄了業(yè)務對象的基本信息。在金融行業(yè)，通常是客戶信息數(shù)據(jù)、賬戶信息數(shù)據(jù)等等；在制造行業(yè)，通常是原料信息數(shù)據(jù)、產(chǎn)品信息數(shù)據(jù)等等。

業(yè)務明細數(shù)據(jù)記錄了業(yè)務對象在業(yè)務過程中變遷歷史。在金融行業(yè)，通常是賬戶交易明細、用戶操作明細等等；在制造行業(yè)，通常是制作流轉明細、產(chǎn)品生產(chǎn)明細等等。

隨著企業(yè)業(yè)務的發(fā)展，企業(yè)歷史數(shù)據(jù)的查詢顯得愈加必要與重要，這些歷史數(shù)據(jù)查詢通常都是針對歷史明細數(shù)據(jù)的查詢，但也可能需要歷史基礎數(shù)據(jù)的組合。一方面，為了提供更加友好的客戶體驗，有必要將每個用戶涉及的歷史數(shù)據(jù)都提供實時查詢服務。歷史明細查詢需要面對眾多的歷史數(shù)據(jù)表，由于人力資源或預算的原因，應用系統(tǒng)無法為每個歷史明細都開發(fā)完整的查詢應用，需要有獨立的系統(tǒng)來統(tǒng)一完成對歷史數(shù)據(jù)的高并發(fā)在線查詢工作；另一方面，業(yè)務基礎數(shù)據(jù)和業(yè)務明細數(shù)據(jù)會隨著業(yè)務的增長和時間的推移而不斷膨脹，業(yè)務數(shù)據(jù)庫都是由傳統(tǒng)關系數(shù)據(jù)庫承擔，由于傳統(tǒng)數(shù)據(jù)庫本身性能、容量的限制，既無法在容量上存儲如此海量的歷史數(shù)據(jù)，也無法在性能上提供海量大規(guī)模數(shù)據(jù)的快速訪問，需要有突破傳輸關系數(shù)據(jù)庫的存儲、查詢平臺來提供海量歷史數(shù)據(jù)的存儲與查詢。

現(xiàn)有技術條件下，海量歷史數(shù)據(jù)的存儲和大規(guī)模復雜查詢是相悖的，更無法提供高并發(fā)在線級歷史數(shù)據(jù)查詢。由于歷史數(shù)據(jù)的體量巨大，往往只能解決海量歷史數(shù)據(jù)的歸檔存儲，但查詢使用過程繁瑣，操作極為麻煩，效率低下；而高并發(fā)在線級數(shù)據(jù)查詢只適用于小規(guī)模數(shù)據(jù)服務，對海量歷史數(shù)據(jù)卻無法滿足需求。

例如，一種現(xiàn)有技術為一種由通用關系數(shù)據(jù)庫存儲海量歷史數(shù)據(jù)并提供高并發(fā)在線查詢的方法。海量歷史數(shù)據(jù)的數(shù)據(jù)存儲、數(shù)據(jù)查詢都采用通用數(shù)據(jù)庫，業(yè)務邏輯在查詢過程中完成，并針對每個查詢業(yè)務提供固定的業(yè)務邏輯。所述方法包括：開發(fā)人員根據(jù)查詢需求，轉換需求為數(shù)據(jù)組織邏輯；開發(fā)人員用數(shù)據(jù)組織邏輯，將歷史數(shù)據(jù)組織為查詢數(shù)據(jù)；開發(fā)人員根據(jù)查詢需求，開發(fā)符合需求邏輯的查詢服務程序，并進行嚴格的驗證、測試和部署工作。查詢請求組件按新開發(fā)的查詢服務接口要求，查詢歷史數(shù)據(jù)。

由上述可知，該現(xiàn)有技術過程極為復雜，需要針對每個歷史查詢開發(fā)一個查詢服務，工作量巨大，查詢接口不一致，導致接口理解困難。該現(xiàn)有技術通常以關系數(shù)據(jù)庫作為查詢數(shù)據(jù)庫，受關系數(shù)據(jù)庫本身的限制，在應對海量歷史數(shù)據(jù)時存在擴展困難、性能低下的問題，無法以低成本方式提供極高并發(fā)的在線數(shù)據(jù)查詢。

技術實現(xiàn)要素：

鑒于現(xiàn)有技術的上述缺陷，本發(fā)明實施方式提供了一種用于數(shù)據(jù)存儲、查詢的方法及系統(tǒng)。

在對本發(fā)明的實施方式進行詳細說明之前，對相關的技術術語進行簡單解釋，如下：

源系統(tǒng)：企業(yè)IT建設中，根據(jù)業(yè)務活動產(chǎn)生數(shù)據(jù)并向其他系統(tǒng)提供數(shù)據(jù)內(nèi)容的系統(tǒng)。

Hadoop：一種分布式文件保存和計算框架，包括HDFS、MAPREDUCE等組件。HDFS為一種分布式文件系統(tǒng)，MAPREDUCE是分布式計算框架。

Hive：Hive是一個基于Hadoop，提供類似SQL的HQL操作，轉換為mapreduce作業(yè)對結構化數(shù)據(jù)進行分析的工具。

HBase：HBase是一個基于Hadoop的高可用、高并發(fā)、分布式、面向列、可伸縮的Key Value數(shù)據(jù)庫。

通用域：企業(yè)級SOA架構中，所有系統(tǒng)對外交換報文都通用的域(欄位)定義，通用域由企業(yè)級架構統(tǒng)一定義，所有報文中含義、閾值固定，不能用于其它用途域。

欄位屬性：企業(yè)級SOA架構中，描述報文域(欄位)的數(shù)據(jù)屬性，包括C(字符串)、D(數(shù)值)、N(數(shù)字)、GROUP(記錄集)等屬性。

一方面，本發(fā)明實施方式提供了一種數(shù)據(jù)存儲方法，其可以包括，但不限于：基于查詢需求組織源系統(tǒng)數(shù)據(jù)以形成查詢數(shù)據(jù)，將所述查詢數(shù)據(jù)以符合HBase標準進行存儲。

相應地，本發(fā)明實施方式提供了一種用于數(shù)據(jù)存儲的系統(tǒng)，可以包括：數(shù)據(jù)形成模塊，用于基于查詢需求組織源系統(tǒng)數(shù)據(jù)以形成查詢數(shù)據(jù)；數(shù)據(jù)存儲模塊，用于將所述查詢數(shù)據(jù)以符合HBase標準進行存儲。

另一方面，本發(fā)明實施方式提供了一種數(shù)據(jù)查詢方法，其可以包括，但不限于：接收查詢請求的請求報文；根據(jù)所述請求報文重組訪問HBase的接口；通過所述接口從HBase數(shù)據(jù)獲取查詢結果。

相應地，本發(fā)明實施方式提供了一種用于數(shù)據(jù)查詢的系統(tǒng)，可以包括：請求接收模塊，用于接收查詢請求的請求報文；接口重組模塊，用于根據(jù)所述請求報文重組訪問HBase的接口；結果獲取模塊，用于通過所述接口從HBase數(shù)據(jù)獲取查詢結果。

根據(jù)本發(fā)明實施方式，將海量歷史明細數(shù)據(jù)存放在大數(shù)據(jù)Hadoop HBase集群中，利用HBase集群提供的高并發(fā)毫秒級響應能力，以低成本獲得高TPS的查詢能力；同時提供一個統(tǒng)一的查詢接口服務，對外發(fā)布一致的數(shù)據(jù)查詢服務，使得數(shù)據(jù)的查詢更加簡單容易。

附圖說明

圖1是示出了根據(jù)本發(fā)明實施方式的數(shù)據(jù)存儲方法的流程圖；

圖2是示出了根據(jù)本發(fā)明實施方式的數(shù)據(jù)查詢方法的流程圖；

圖3示出了根據(jù)本發(fā)明實施方式的用于數(shù)據(jù)存儲的系統(tǒng)；

圖4示出了圖3所示的用于數(shù)據(jù)存儲的系統(tǒng)的數(shù)據(jù)形成模塊；

圖5示出了圖3所示的用于數(shù)據(jù)存儲的系統(tǒng)的數(shù)據(jù)存儲模塊；

圖6示出了根據(jù)本發(fā)明實施方式的用于數(shù)據(jù)查詢的系統(tǒng)；

圖7示出了根據(jù)本發(fā)明實施方式的查詢數(shù)據(jù)邏輯組織流程；

圖8示出了根據(jù)本發(fā)明實施方式的查詢數(shù)據(jù)存儲流程；

圖9示出了根據(jù)本發(fā)明實施方式的查詢服務建立流程；

圖10示出了根據(jù)本發(fā)明實施方式的查詢服務提供流程。

具體實施方式

為了便于理解本發(fā)明技術方案的各個方面、特征以及優(yōu)點，下面結合附圖對本發(fā)明進行具體描述。應當理解，下述的各種實施方式只用于舉例說明，而非用于限制本發(fā)明的保護范圍。

圖1是示出了根據(jù)本發(fā)明實施方式的數(shù)據(jù)存儲方法的流程圖。在本發(fā)明的一種實施方式中，所述數(shù)據(jù)存儲方法可以包括：

S101.基于查詢需求組織源系統(tǒng)數(shù)據(jù)以形成查詢數(shù)據(jù)，

S102.將所述查詢數(shù)據(jù)以符合HBase標準進行存儲。

在本發(fā)明的一種可選實施方式中，S101可以包括：將所述源系統(tǒng)數(shù)據(jù)放置到Hadoop HDFS上以形成基于Hive的原始數(shù)據(jù)；利用SQL語句將所述原始數(shù)據(jù)組織為符合查詢需求的查詢數(shù)據(jù)。其中，可選地，將所述源系統(tǒng)數(shù)據(jù)放置到Hadoop HDFS上以形成基于Hive的原始數(shù)據(jù)可以包括：將所述源系統(tǒng)數(shù)據(jù)保存到Hadoop HDFS上以形成Hive原始數(shù)據(jù)表，分析所述原始數(shù)據(jù)以創(chuàng)建符合查詢需求的HBase表。可選地，利用SQL語句將所述原始數(shù)據(jù)組織為符合查詢需求的查詢數(shù)據(jù)可以包括：根據(jù)所述Hive原始數(shù)據(jù)表的字段結構形成SQL語句；分析所形成的SQL語句，生成HDFS上的TXT文本文件。

在本發(fā)明的另一種可選實施方式中，S102可以包括：根據(jù)組織邏輯形成所述TXT文本文件各字段與HBase各字段之間的映射；將所述TXT文本文件轉換為符合HBase存儲規(guī)范的HFile文件；將所述HFile文件合并到HBase集群中形成HBase Region，并使所述Region處于在線狀態(tài)，以供查詢。其中，HBase在邏輯上的存儲最小單位是Region(分區(qū))，物理上來說是HFile。每個Region由多個HFile組成。

圖2是示出了根據(jù)本發(fā)明實施方式的數(shù)據(jù)查詢方法的流程圖。在本發(fā)明的一種實施方式中，所述數(shù)據(jù)查詢方法可以包括：

S201.接收查詢請求的請求報文；

S202.根據(jù)所述請求報文重組訪問HBase的接口；

S203.通過所述接口從HBase數(shù)據(jù)獲取查詢結果。

在本發(fā)明的一種可選實施方式中，S202可以包括：拆解所述請求報文，得到請求域中Json字符串、關鍵域域值；解析請求域中的Json字符串得到關鍵信息；根據(jù)所述關鍵信息重組為訪問HBase的接口。可選地，所述關鍵信息包括下述中的一種或多種：要查詢的HBase表名、條件字段及條件值、返回字段列表。

在本發(fā)明的另一種可選實施方式中，S203可以包括：所述接口通過HBase API訪問HBase數(shù)據(jù)，獲得查詢結果數(shù)據(jù)；將所述查詢結果數(shù)據(jù)封裝為Json字符串；將封裝的Json字符串封裝到XML報文中；通過XML報文輸出查詢結果。

圖3示出了根據(jù)本發(fā)明實施方式的用于數(shù)據(jù)存儲的系統(tǒng)。在本發(fā)明實施方式中，所述系統(tǒng)可以包括用于基于查詢需求組織源系統(tǒng)數(shù)據(jù)以形成查詢數(shù)據(jù)的數(shù)據(jù)形成模塊310和用于將所述查詢數(shù)據(jù)以符合HBase標準進行存儲的數(shù)據(jù)存儲模塊320。

在本發(fā)明的一種可選實施方式中，如圖4所示，所述數(shù)據(jù)形成模塊可以包括原始數(shù)據(jù)形成單元410和查詢數(shù)據(jù)形成單元420。其中，原始數(shù)據(jù)形成單元410用于將所述源系統(tǒng)數(shù)據(jù)放置到Hadoop HDFS上以形成基于Hive的原始數(shù)據(jù)，可選地，可以包括：將所述源系統(tǒng)數(shù)據(jù)保存到Hadoop HDFS上以形成Hive原始數(shù)據(jù)表，分析所述原始數(shù)據(jù)以創(chuàng)建符合查詢需求的HBase表。查詢數(shù)據(jù)形成單元420用于利用SQL語句將所述原始數(shù)據(jù)組織為符合查詢需求的查詢數(shù)據(jù)，可選地，可以包括：根據(jù)所述Hive原始數(shù)據(jù)表的字段結構形成SQL語句；分析所形成的SQL語句，生成HDFS上的TXT文本文件。

在本發(fā)明的另一種實施方式中，如圖5所示，所述數(shù)據(jù)存儲模塊可以包括：

映射形成單元510，用于根據(jù)組織邏輯形成所述TXT文本文件各字段與HBase各字段之間的映射；

文件轉換單元520，用于將所述TXT文本文件轉換為符合HBase存儲規(guī)范的HFile文件；

文件合并單元530，用于將所述HFile文件合并到HBase集群中形成HBase Region，并使所述Region處于在線狀態(tài)。

圖6示出了根據(jù)本發(fā)明實施方式的用于數(shù)據(jù)查詢的系統(tǒng)。在本發(fā)明實施方式中，所述系統(tǒng)可以包括：

請求接收模塊610，用于接收查詢請求的請求報文；

接口重組模塊620，用于根據(jù)所述請求報文重組訪問HBase的接口；

結果獲取模塊630，用于通過所述接口從HBase數(shù)據(jù)獲取查詢結果。

可選地，接口重組模塊620根據(jù)所述請求報文重組訪問HBase的接口可以包括：拆解所述請求報文，得到請求域中Json字符串、關鍵域域值；解析請求域中的Json字符串得到關鍵信息；根據(jù)所述關鍵信息重組為訪問HBase的接口。其中，所述關鍵信息可以包括下述中的一種或多種：要查詢的HBase表名、條件字段及條件值、返回字段列表。

在選擇性實施方式中，結果獲取模塊630通過所述接口從HBase數(shù)據(jù)獲取查詢結果可以包括：所述接口通過HBase API訪問HBase數(shù)據(jù)，獲得查詢結果數(shù)據(jù)；將所述查詢結果數(shù)據(jù)封裝為Json字符串；將封裝的Json字符串封裝到XML報文中；通過XML報文輸出查詢結果。

根據(jù)本發(fā)明實施方式，將海量歷史明細數(shù)據(jù)存放在大數(shù)據(jù)Hadoop HBase集群中，利用HBase集群提供的高并發(fā)毫秒級響應能力，以低成本獲得高TPS的查詢能力；同時提供一個統(tǒng)一的查詢接口服務，對外發(fā)布一致的數(shù)據(jù)查詢服務，使得數(shù)據(jù)的查詢更加簡單容易。

下面將從查詢數(shù)據(jù)組織、查詢數(shù)據(jù)存儲、查詢服務建立、查詢服務提供這四個關鍵步驟來講述本發(fā)明技術方案。

查詢數(shù)據(jù)邏輯組織

整個查詢服務是基于Hadoop大數(shù)據(jù)平臺的存儲、計算框架實現(xiàn)，因此數(shù)據(jù)邏輯組織、數(shù)據(jù)計算需要在Hadoop中實現(xiàn)。

查詢數(shù)據(jù)由源系統(tǒng)數(shù)據(jù)組織形成，源系統(tǒng)數(shù)據(jù)需要先放置到Hadoop HDFS之上，并形成Hive表，使得源系統(tǒng)數(shù)據(jù)形成基于Hive的原始數(shù)據(jù)。

數(shù)據(jù)邏輯組織將原來在查詢時才進行的業(yè)務邏輯組織的操作前置，通過分析需求后，利用SQL語句將Hive表中原始數(shù)據(jù)組織為符合查詢需求的查詢數(shù)據(jù)，可確保查詢數(shù)據(jù)符合查詢需求，簡化后續(xù)查詢時的用數(shù)邏輯。

如圖7所示，查詢服務邏輯組織可包括：

701～702、源系統(tǒng)數(shù)據(jù)保存到Hadoop HDFS之上，并形成Hive原始數(shù)據(jù)表；

703～704、分析原始數(shù)據(jù)，設計HBase表的主鍵Key及二級索引Key，創(chuàng)建符合查詢需求的HBase表；

705、以查詢需求為目標導向，根據(jù)原始數(shù)據(jù)表的字段結構，形成SQL語句，完成數(shù)據(jù)過濾、合并、多表關聯(lián)等操作，在此期間注意形成的數(shù)據(jù)要符合HBase的主鍵條件；

706、運行分析組織形成的SQL語句，結果落地為HDFS上的TXT文本文件。

查詢數(shù)據(jù)存儲

基于HBase的查詢需要將數(shù)據(jù)以符合HBase的標準進行存儲，將組織結果的TXT文本文件存儲為HBase集群的HFile文件，在HBase集群中支撐海量數(shù)據(jù)的分布式存儲，并將數(shù)據(jù)以低延時高并發(fā)的形式提供出來。

如圖8所示，查詢數(shù)據(jù)存儲可包括：

801、根據(jù)組織邏輯，形成HDFS TXT文本文件各字段與HBase各字段之間的映射；

802～803、利用HBase自身的Bulkloader工具(一種開源加載類，提供簡單的載入函數(shù)，不管要載入的是xml、swf還是聲音文件，都只使用同一接口)，將HDFS TXT文本轉換為符合HBase存儲規(guī)范的HFile文件；

804～805、將HFile文件合并到HBase集群中形成新的HBase Region，并使各個Region處于Online狀態(tài)，數(shù)據(jù)即可提供查詢服務。

查詢服務建立

查詢服務由一組Web應用集群提供WebService服務組成。查詢服務建立時充分考慮到兼容性、可控性和可靠性，查詢服務由J2EE應用程序形成，可由單一小組負責開發(fā)、測試、運維與升級。查詢服務只需要建立一次，即可服務于所有HBase表的查詢。

如圖9所示，查詢服務建立可以包括：

901、根據(jù)通用報文思想，設計通用服務報文，充分考慮報文的普適性；

902、設計應用程序架構，包括用戶認證設計、流量控制設計、應用多活設計等；

903、開發(fā)應用程序，解耦并形成查詢接收層、安全控制層、邏輯重組層、數(shù)據(jù)訪問層、結果重組層、結果組裝層；

904～906、經(jīng)過應用功能性測試、壓力測試后，發(fā)布應用程序并部署。

為了確保查詢服務建立一次即可支持所有HBase表的查詢，需要對查詢服務中的報文進行有效定義。查詢服務報文定義如下：

由于在報文中定義了要查詢的HBase表名、條件字段及條件值、返回字段列表等關鍵信息，使得一次定義多次查詢成為可能。

為了支持某些日期、時間字段的范圍查詢，則查詢條件的鍵需以“min”+“-”或者“max”+“-”開頭(注意是減號而不是下劃線)，“min”開頭表示查詢范圍的下限，“max”開頭表示查詢范圍的上限，未標識的其它字段為相等查詢，min、max域為可選域，大小寫不敏感，如"min-tx_dt":"20140901"。在某些支持主鍵的模糊查詢時，則查詢條件的值需帶上“％”，并且只支持前綴匹配“condition％”，如"ci_cust_no":"622301001％"。

查詢服務提供

用戶查詢請求發(fā)送到查詢服務后，查詢服務對所有查詢請求采用同樣一套邏輯，過程中要經(jīng)過請求接收層、安全控制層、邏輯重組層、數(shù)據(jù)訪問層、結果重組層、結果組裝層，才能將符合條件的結果封裝為接口定義的內(nèi)容輸出。如圖10所示，查詢服務提供可包括：

1001～1002、接收請求報文內(nèi)容，拆解報文，得到請求域中的Json字符串、關鍵域域值；

1003～1004、根據(jù)內(nèi)存中駐留的流控策略，比對關鍵域域值，確認是否響應該查詢請求；

1005～1006、解析請求域中的Json字符串，得到要查詢的HBase表名、過濾字段名及過濾值(或條件字段及條件值)、返回字段列表等信息；根據(jù)該部分信息重組為訪問HBase的接口；

1007～1008、訪問HBase的接口通過HBase API，訪問HBase數(shù)據(jù)，可選地，有匯總、計算記錄等情況的，還需要調(diào)用通用的協(xié)處理接口；

1009～1010、將查詢結果數(shù)據(jù)封裝為Json字符串，并封裝到Webservice的XML報文中，完成數(shù)據(jù)查詢；

發(fā)明技術方案帶來的有益效果

能夠滿足海量結構化歷史數(shù)據(jù)的存儲；

能夠為用戶提供高度可擴展的低成本海量數(shù)據(jù)高TPS查詢方法；

能夠利用一個統(tǒng)一的查詢服務，解決絕大多數(shù)HBase表數(shù)據(jù)的高并發(fā)在線查詢，極大提高數(shù)據(jù)查詢實施效率，降低實施風險。

通過以上的實施方式的描述，本領域的技術人員可以清楚地了解到本發(fā)明可借助軟件結合硬件平臺的方式來實現(xiàn)。基于這樣的理解，本發(fā)明的技術方案對背景技術做出貢獻的全部或者部分可以以軟件產(chǎn)品的形式體現(xiàn)出來，該計算機軟件產(chǎn)品可以存儲在存儲介質中，如ROM/RAM、磁碟、光盤等，包括若干指令用以使得一臺計算機設備(可以是個人計算機，服務器，或者網(wǎng)絡設備等)執(zhí)行本發(fā)明各個實施例或者實施例的某些部分所述的方法。

本領技術人員應當理解，以上所公開的僅為本發(fā)明的實施方式而已，當然不能以此來限定本發(fā)明之權利范圍，依本發(fā)明實施方式所作的等同變化，仍屬本發(fā)明權利要求所涵蓋的范圍。