專利名稱：基于MapReduce擴展框架的分布式SQL查詢方法
技術領域：
本發(fā)明涉及一種在分布式計算的環(huán)境下進行SQL查詢的方法，特別涉及一種利用MapReduce和內(nèi)存處理結(jié)合的方式處理SQL查詢的框架，屬于信息技術領域。
背景技術：
隨著互聯(lián)網(wǎng)技術和相關行業(yè)的發(fā)展，計算機行業(yè)面臨著指數(shù)增長的海量數(shù)據(jù)和更多的數(shù)據(jù)處理需求。面對這種狀況，一些新技術快速發(fā)展，包括并行數(shù)據(jù)庫、分布式處理等。MapReduce是一個處理海量數(shù)據(jù)的計算框架,非常適合分布式的計算系統(tǒng)。Hadoop是一個由Apache基金會開發(fā)的基于MapReduce框架的分布式數(shù)據(jù)處理系統(tǒng),有計算能力強、容錯性和數(shù)據(jù)可用性強、可擴展性強等特性。然而，這種傳統(tǒng)的MapReduce框架和Hadoop系統(tǒng)也有以下缺點 I、擅長處理批量處理的問題和非結(jié)構(gòu)化的數(shù)據(jù)，不擅長處理結(jié)構(gòu)化數(shù)據(jù)的處理。2、由于其高可擴展性，對于特定問題的處理需要用戶進一步編程解決。不存在針對某種問題的特定接口。3、由于其分布式的特點，存在著啟動時間長、負載不均衡、數(shù)據(jù)吞吐量大等相關問題，進一步導致處理延時較高，不能支持一些實時的查詢。針對以上問題，已經(jīng)有了多種對MapReduce框架的優(yōu)化和補充,使得MapReduce適用于迭代的計算模型、結(jié)構(gòu)化的數(shù)據(jù)處理、SQL查詢等特定應用。其中，由于SQL查詢是數(shù)據(jù)庫領域的重要應用，且其處理能力強大，有大量的研究和分布式環(huán)境下的SQL查詢相關。Hive和Google Dremel是兩個比較成功的系統(tǒng)。Hive是一個建立在Hadoop上的數(shù)據(jù)倉庫系統(tǒng),具有數(shù)據(jù)管理、數(shù)據(jù)查詢等功能。Hive定義了一個類似于SQL的查詢語言——HiveQL，支持SQL可以實現(xiàn)的絕大多數(shù)查詢，并且查詢接口簡單。Hive利用Hadoop的Hadoop文件系統(tǒng)(HadoopFile System, HDFS)存儲數(shù)據(jù)，利用Hadoop的MapReduce模塊進行數(shù)據(jù)處理的工作，并且有很強的數(shù)據(jù)容錯性和數(shù)據(jù)恢復能力?？傮w來看，Hive基本支持絕大多數(shù)分布式數(shù)據(jù)庫的功能，并且有更好的擴展性和規(guī)模性。然而，由于Hive的數(shù)據(jù)處理的功能仍然建立在Hadoop上，它仍然存在一些Hadoop系統(tǒng)的缺點，比如處理延時較高的問題。下面通過簡單分析Hive和Hadoop系統(tǒng)來說明這個問題。Hive的體系結(jié)構(gòu)如圖I。在Hive部分中，CLI、Web⑶I和JDBC/0DBC模塊都是向用戶提供的結(jié)構(gòu)，用戶通過接口提供查詢。Thrift Server是提供跨語言開發(fā)的服務器模塊，用來支持JDBC/ODBC。MetaStore模塊是用來保存數(shù)據(jù)的元數(shù)據(jù)的服務器模塊，Hive是用MySQL實現(xiàn)的,通過MetaStore可以高效地支持對數(shù)據(jù)的管理和查詢。Driver部分是Hive的核心，它包含編譯、優(yōu)化、執(zhí)行查詢?nèi)齻€模塊，功能是將用戶發(fā)出的查詢語句進行轉(zhuǎn)化和優(yōu)化，生成MapReduce程序并將其發(fā)送給Hadoop執(zhí)行。在Hive中，查詢的執(zhí)行交給Hadoop來完成。Driver生成的MapReduce任務將被提交給Hadoop的JobTracker, JobTracker負責建立任務、跟蹤任務運行狀態(tài)并將任務結(jié)果返還給Hive的Driver。Hive提交的MapReduce任務的執(zhí)行和普通的Hadoop的MapReduce任務的執(zhí)行基本相同。從上面對Hive框架的分析可以看出，Hive處理了上面提到的兩個問題。一方面在Hadoop的基礎上提供了一些針對SQL的特定接口，使得用戶可以方便地使用MapReduce框架進行SQL查詢；另一方面也針對MapReduce和SQL進行了優(yōu)化，通過使用MetaStore和查詢優(yōu)化的模塊對查詢?nèi)蝿者M行優(yōu)化，使得MapReduce模型可以對結(jié)構(gòu)化的數(shù)據(jù)進行處理。然而，由于Hive的查詢?nèi)蝿杖匀皇墙唤oHadoop系統(tǒng)完成，因而沒有解決Hadoop系統(tǒng)延遲較高的缺陷。 圖2是Hadoop系統(tǒng)的MapReduce框架。MapReduce任務執(zhí)行的一般流程是UMapper任務從HDFS上讀取數(shù)據(jù)塊(split)。2、每個Mapper任務調(diào)用map函數(shù)，對每一個數(shù)據(jù)塊進行處理，處理的結(jié)果寫入緩存或者磁盤。3、Mapper執(zhí)行完之后，數(shù)據(jù)在本地進行排序和合并(有可能經(jīng)過本地的combine)。4、經(jīng)過Shuffle階段,每個節(jié)點把本地數(shù)據(jù)發(fā)送給對應的Reducer所在的節(jié)點。5、在Reducer本地進行排序和合并。6、Reducer處理本地的數(shù)據(jù)，并將結(jié)果寫入HDFS。從上面的執(zhí)行流程來看，Map和Reduce階段中有大量的本地I/O操作，以及一些不必要的排序。以上這些流程都不是MapReduce框架必須的,而是Hadoop為了保證數(shù)據(jù)的高可用性和良好的擴展性而實現(xiàn)的。然而，這些操作也導致了 Hadoop系統(tǒng)執(zhí)行MapReduce任務延時較高，無法支持實時的查詢。如果想要在這一點上有所改進，必須要對Hadoop系統(tǒng)的體系結(jié)構(gòu)進行修改。Dremel是Google開發(fā)的供內(nèi)部員工使用的分布式數(shù)據(jù)查詢與分析系統(tǒng)。根據(jù)Google 的論文 Dremel: InteractiveAnalysis offfebScale Datasets.，這種系統(tǒng)適用于一些聚集操作的查詢，查詢處理的速度較快，可以用于一些實時的應用。DremeI的體系結(jié)構(gòu)如圖3所示。進行查詢的流程如下I、客戶端發(fā)起查詢，root server接收并解析查詢語句。2、root server將查詢語句分解成子查詢語句，將查詢發(fā)送給中間節(jié)點(intermediate server)執(zhí)行查詢。例如，對于查詢語句SELECT A, COUNT (B) FROM T GROUP BY A,將被分解為新的查詢語句
SELECT ArSifM(C) FROM (R11 UNION ALLGROUP BYA 和一些子查詢語句
R - = SELECT AfCOUMT(B) AS C FROM I, GROUP BY A，再將這些子查詢語句發(fā)送給中間節(jié)點。3、中間節(jié)點執(zhí)行子查詢,將本地的查詢結(jié)果發(fā)送給root server。4> root server在本地執(zhí)行合并結(jié)果的操作,輸出結(jié)果。Dremel的查詢流程，已經(jīng)脫離了普通的MapReduce框架。由于使用了這種特定的框架，加上一些針對聚集查詢的優(yōu)化，Dremel對針對聚集的查詢效率很高。然而，Dremel的這種特定框架使得它不能處理其他的問題，甚至連其他一些SQL查詢都無法處理(比如，無法處理SQL中的連接查詢)。因此，可以考慮一種更加通用的高效的分布式SQL執(zhí)行框架。

發(fā)明內(nèi)容
本發(fā)明的目的是提供一種分布式的SQL查詢處理框架，使得這種框架能夠適用于分布式的系統(tǒng)，同時提供類似于Hive的強大的查詢能力和類似Dremel的高效的處理速度。為了適應分布式的系統(tǒng),本發(fā)明建立在Hadoop的MapReduce框架的基礎上,并對框架進行修改，使得其在不失去擴展性的前提下增強對SQL查詢的擴展能力。本發(fā)明了提出一種基于MapReduce擴展框架的分布式SQL查詢方法,其步驟為I)客戶端發(fā)送查詢請求到查詢服務器模塊QueryServer，所述查詢服務器模塊包括SQL查詢接口、SLQ解析模塊和動態(tài)選擇模塊；2)所述SQL查詢接口接收到查詢請求，將所述請求發(fā)送到SQL解析模塊，所述解析模塊解析得到查詢請求的語義；3)所述動態(tài)選擇模塊根據(jù)查詢代價模型Cost Model和語義規(guī)則對該查詢語義進 行計算，預測出查詢結(jié)果需要的存儲空間，并選擇使用MapReduce查詢方式或內(nèi)存查詢方式；3_1)查詢方式為MapReduce查詢時,Job Tracker啟動執(zhí)行Map操作和Reduce操作；3-2)當查詢方式為內(nèi)存查詢時，Job Tracker啟動Map操作，并將查詢數(shù)據(jù)保存至本地服務器的內(nèi)存表中；4)當查詢結(jié)束，將本地查詢結(jié)果上傳至HDFS或數(shù)據(jù)處理服務器模塊DataProcessor。所述擴展框架基于內(nèi)存表構(gòu)架，建立由查詢服務器模塊啟動并管理的數(shù)據(jù)處理服務器模塊，所述數(shù)據(jù)處理服務模塊用于內(nèi)存查詢方式中與每一個map任務連接，收集map任務查詢結(jié)果并進行處理和輸出。Map操作和數(shù)據(jù)處理服務器模塊Data Processor使用Hadoop RPC接口連接,通過設置傳輸閾值控制每次傳輸?shù)臄?shù)據(jù)塊大小。所述SQL查詢接口面向用戶提供接口通過socket實現(xiàn),用于接收和返回客戶端查詢請求。所述SQL解析模塊通過antlr工具實現(xiàn)，所述antlr根據(jù)用戶提供的語法文件，生成對應的語法分析器。更進一步，所述SQL解析模塊解析得到查詢請求的語義，形成語法樹；所述語法樹是以SQL查詢中符號和操作符為節(jié)點的樹。更進一步，遍歷所述語法樹，并根據(jù)元組數(shù)據(jù)Meta Data的信息，得到查詢語義。更進一步，所述建立查詢代價模型相關參數(shù)信息根據(jù)元組數(shù)據(jù)Meta Data、查詢語句本身或者查詢的歷史記錄中取得包括表的模式信息、表中每列的平均數(shù)據(jù)大小、表中記錄的數(shù)量、表中每一列的數(shù)據(jù)分布情況、查詢條件。更進一步，所述語義規(guī)則的動態(tài)選擇方法根據(jù)查詢的種類、表的數(shù)據(jù)量信息來判斷查詢的執(zhí)行方式。更進一步,在內(nèi)存查詢時可通過MapScan掃描方法對數(shù)據(jù)進行查詢,將結(jié)果直接輸入到內(nèi)存表中。本發(fā)明的有益效果
I、給定SQL查詢語言，針對某些操作符號，如空間相對較小的選擇查詢、聚集查詢，引入了一種內(nèi)存表的方法。內(nèi)存表在QueryServer中，能夠接受來自不同分布式計算節(jié)點的計算結(jié)果。2、本發(fā)明引入了一種Map Scan的掃描方法，利用這種分布式操作，將結(jié)果直接輸入到內(nèi)存表。3、本發(fā)明的SQL優(yōu)化模塊能夠根據(jù)已有信息，選擇合適的執(zhí)行方式，包括Hadoop的MapReduce方式，直接文件操作方式，內(nèi)存表方式。綜上所述，本發(fā)明首先提出了利用內(nèi)存處理的方式處理SQL查詢的方法。通過Map任務和數(shù)據(jù)處理器的連接，在內(nèi)存中完成數(shù)據(jù)處理的過程，極大提高查詢的效率。其次，本發(fā)明利用查詢服務器模塊來實現(xiàn)與客戶端的交互和查詢處理方式的動態(tài)選擇。查詢服務器模塊提供兩種查詢執(zhí)行的方式利用MapReduce執(zhí)行的方式和利用內(nèi)存執(zhí)行的方式。通過這種動態(tài)選擇，能夠提高查詢的效率，同時保持MapReduce框架和Hadoop系統(tǒng)的擴展性和數(shù)據(jù)可用性。


圖I是現(xiàn)有技術中Hive的系統(tǒng)流程圖。圖2是現(xiàn)有技術中Hadoop的MapReduce的系統(tǒng)架構(gòu)圖。圖3是現(xiàn)有技術中Dremel的系統(tǒng)架構(gòu)圖。圖4為本發(fā)明基于MapReduce擴展框架的分布式SQL查詢方法系統(tǒng)架構(gòu)圖。圖5為本發(fā)明基于MapReduce擴展框架的分布式SQL查詢方法流程圖。
具體實施例方式下面詳細說明本發(fā)明的實現(xiàn)步驟和具體方法。本發(fā)明的實現(xiàn)是基于Hadoop的，主要實現(xiàn)內(nèi)容包括在Hadoop外層包裝了 SQL查詢的接口和SQL解析、優(yōu)化的工具，以及對傳統(tǒng)的MapReduce任務框架的修改和動態(tài)選擇。下面首先給出整個分布式SQL查詢框架的結(jié)構(gòu)圖，說明整個工作流程和主要模塊的任務，最后分別描述每個模塊的具體實現(xiàn)。本發(fā)明的系統(tǒng)架構(gòu)如圖4所示。由于本發(fā)明的最終目的是構(gòu)建一個基于MapReduce思想的SQL查詢框架，因此系統(tǒng)架構(gòu)圖中一方面包含和Hive類似的SQL查詢處理、優(yōu)化的模塊，包括查詢服務器模塊(Query Server)、元數(shù)據(jù)管理(Meta Data)和查詢客戶端(Client),另一方面也包含基于Hadoop的傳統(tǒng)的MapReduce框架,包含Job Tracker、Map Task、ReduceTask,以及對MapReduce框架的修改部分，即修改過的Map Task和數(shù)據(jù)處理服務器模塊(Data Processor).此處用一個例子來描述整個系統(tǒng)的流程。以查詢SELECT A, COUNT(B)FROM T GROUP BY A為例。當用戶從客戶端提交查詢時，查詢服務器模塊(Query Server)首先接受這個查詢,然后調(diào)用解析工具,將查詢解析成語法樹，再做進一步分析。當語法樹生成之后，查詢服務器模塊將調(diào)用元數(shù)據(jù)，預測查詢的存儲代價。查詢服務器模塊將根據(jù)元數(shù)據(jù)中保存的表T的信息，包括T的總的記錄的數(shù)量和占用空間、T表中A列數(shù)據(jù)的分布情況等信息，建立一個代價模型，并根據(jù)這個代價模型預估查詢結(jié)果需要的內(nèi)存空間。根據(jù)預測的查詢的存儲代價，查詢服務器模塊將選擇一個執(zhí)行方式。對于存儲代價較大的查詢，例如，如果上例中T表的A列是一個長文本，平均有IKB大小，而總的記錄數(shù)量預測有幾千萬條，那么這樣的查詢將被認為是一個復雜查詢，只能交給傳統(tǒng)的MapReduce框架去完成。相反，對于一般的查詢，存儲代價不大，查詢服務器模塊將選擇內(nèi)存的執(zhí)行方式。確定執(zhí)行方式之后，查詢服務器模塊將建立MapReduce任務,并根據(jù)查詢的語句和選擇的執(zhí)行方式為MapReduce任務設定參數(shù)。對于內(nèi)存的執(zhí)行方式，查詢服務器模塊還將建立一個數(shù)據(jù)處理服務器模塊(Data Processor )，用于收集保存在內(nèi)存中的中間結(jié)果。之后，查詢服務器模塊將把任務提交給Hadoop的JobTracker。JobTracker接受任務之后,將啟動對應的Map任務。對于MapReduce的執(zhí)行方式，JobTracker還將啟動Reduce任務；對于內(nèi)存的執(zhí)行方式，JobTracker不會啟動Reduce任 務。Map任務獲得的中間結(jié)果將暫時地保存在內(nèi)存中，并由數(shù)據(jù)處理服務器模塊收集之后進行進一步處理并輸出。最后，查詢服務器模塊將收集數(shù)據(jù)處理服務器模塊中保存的結(jié)果，或者從HDFS上收集Reduce輸出的結(jié)果，返回給客戶端。以上就是基于MapReduce和內(nèi)存處理的SQL查詢框架。下面進一步描述各個模塊的具體設計和實現(xiàn)。I、查詢服務器模塊模塊(QueryServer模塊)QueryServer模塊是本發(fā)明的核心模塊。它提供的功能包括SQL查詢接口、SQL解析和優(yōu)化、執(zhí)行方式的動態(tài)選擇。SQL查詢接口是QueryServer向外部提供的接口。本發(fā)明使用socket實現(xiàn)了這一接口。用戶只需要通過客戶端提交查詢語句，客戶端會利用socket將查詢語句發(fā)送給QueryServer0另一方面，當查詢處理結(jié)束時，查詢接口將從數(shù)據(jù)處理服務器模塊和HDFS上收集查詢的結(jié)果，同樣通過Socket的方式發(fā)送給客戶端。SQL解析的模塊是通過antlr工具實現(xiàn)的。antlr是一個java的語法分析工具。根據(jù)提供的語法文件，anti會生成對應的語法分析器。當SQL查詢接口接收到一個SQL語句時，語法分析器將解析SQL語句，生成對應的語法樹。語法樹是以SQL查詢中的符號和操作符為節(jié)點的一棵樹。遍歷這棵樹，同時根據(jù)Meta Data的信息，即可得到整個查詢的語義。在得到查詢語句的語義之后，需要為查詢設定查詢的參數(shù)和查詢的條件。這是SQL解析的目標之一?？紤]到MapReduce框架中很難使用全局的變量，本發(fā)明中使用Hadoop的Configuration類來設定查詢的參數(shù)。Configuration類是在Hadoop中全局維護的信息，因此每個節(jié)點或每個任務都可以讀取Conf i gurat i on類的內(nèi)容。但是，由于Conf i gurat i on類只能支持類似key-value對的name-property這樣的屬性對,不能支持XML格式的參數(shù)設置的方式，因此必須為不同的參數(shù)設置帶有序號的屬性名。具體來說，以WHERE子句的參數(shù)為例，我們首先可以在Configuration中設置一個屬性SelectConditionNumber,來標識一個WHERE子句有幾個邏輯判斷條件,然后需要設置下標從I到SelectConditionNumber的邏輯判斷條件，即從 Configuration 中讀取 SelectConditionl, SelectCondition2 等,再設置邏輯判斷條件的連接符(and, or),即從Configuration中讀取ConditionConjunctionl,ConditionConjunction2等。這樣，在MapReduce任務執(zhí)行過程中，只需要讀取Configuration中的有關信息，即可設置WHERE子句的選擇條件。其他的SQL查詢中的操作和對象也都可以用類似的方式進行設置。執(zhí)行方式的動態(tài)選擇是保證效率和強大的查詢能力的核心部分。本發(fā)明設計的內(nèi)存處理的執(zhí)行方式比MapReduce的執(zhí)行框架效率高，但是相應的，查詢結(jié)果必須能夠保持在內(nèi)存中。對于大量數(shù)據(jù)的復雜查詢，需要使用傳統(tǒng)的MapReduce框架處理。因此，這種動態(tài)選擇的機制就是必須的。動態(tài)選擇的機制有兩種基于規(guī)則的和基于代價模型的。本發(fā)明中同時使用了兩種選擇機制，并對兩種機制加以結(jié)合。基于規(guī)則的動態(tài)選擇機制主要是根據(jù)查詢的種類、表的數(shù)據(jù)量等直觀的信息，來判斷查詢的執(zhí)行方式。表的數(shù)據(jù)量的信息一定程度上反映結(jié)果的數(shù)據(jù)量?？紤]到數(shù)據(jù)的均勻分布等特點，可以估計出查詢結(jié)果的數(shù)據(jù)量，從而判斷出查詢結(jié)果是否能夠在內(nèi)存中處理。如果可以在內(nèi)存中處理，則可以直接使用內(nèi)存處理的方式執(zhí)行查詢。
同時，查詢種類也能一定程度上幫助選擇執(zhí)行方式。一般地，SQL查詢可以分為兩種類型包含聚集語義的和不包含聚集語義的。此處的聚集語義不僅包含聚集函數(shù)的操作，也包括GROUP BY操作、連接操作等。而不包含聚集語義的操作則主要是SELECT操作?？紤]傳統(tǒng)的MapReduce框架。對于不包含聚集語義的查詢，是不需要Reduce過程的(只需要將數(shù)據(jù)分發(fā)出來，而不需要進一步的合并數(shù)據(jù))；對于包含聚集語義的查詢，總是需要Reduce過程的。而根據(jù)前面的描述，傳統(tǒng)的MapReduce框架和Hadoop系統(tǒng)的效率瓶頸主要在于Shuffle階段和Reduce階段。因此對于不包含聚集語義的操作，完全可以使用傳統(tǒng)的不包含Reduce階段的MapReduce框架,而且不會過多影響效率。另一方面,對于復雜的連接操作，查詢結(jié)果一般是以乘積的方式增長。這樣的查詢一般無法在內(nèi)存中處理?；诖鷥r模型的動態(tài)選擇機制則是根據(jù)已有的信息，建立相關參數(shù)和存儲代價的模型，通過模型來預測本次查詢的存儲代價。此處的相關參數(shù)包括表的模式信息、表中每列的平均數(shù)據(jù)大小、表中記錄的數(shù)量、表中每一列的數(shù)據(jù)分布情況、查詢條件等。這些信息都可以從Meta Data、查詢語句本身或者查詢的歷史記錄中取得。例如，下面這個模型是一個根據(jù)數(shù)據(jù)的信息建立的對于簡單的Select語句模型 rcsuhSizc = ^ rcsuili 'OluinnSizei * IabieSize * qiierySelcctivily這里，可以通過對Hadoop系統(tǒng)的數(shù)據(jù)流和分析建立模型，例如論文Profiling,what-ifanalysis, and cost-based optimizationof MapReduce programs 中建立的代價模型；也可以通過一些模型工具，把以上的相關參數(shù)作為輸入?yún)?shù)，建立黑盒模型。建立模型之后，即可通過本次查詢的信息預測本次查詢的存儲處理代價。除了上述的動態(tài)選擇機制，查詢服務器模塊還應提供回滾機制，當上面的動態(tài)選擇錯誤而導致查詢執(zhí)行出錯時，查詢服務器模塊可以回滾查詢的執(zhí)行過程，保證查詢的正確性。2、數(shù)據(jù)處理服務器模塊(Data Processor模塊)當使用內(nèi)存處理機制處理數(shù)據(jù)時，系統(tǒng)還需要維護一塊內(nèi)存區(qū)域來存儲和處理內(nèi)存中的數(shù)據(jù)。因此，當查詢服務器模塊確定使用內(nèi)存處理方式執(zhí)行查詢時，需要建立并維護一個數(shù)據(jù)處理服務器模塊。這個數(shù)據(jù)處理的服務器模塊本質(zhì)是一個支持多種操作的內(nèi)存表。在內(nèi)存處理的執(zhí)行方式下，map任務的本地數(shù)據(jù)都將通過RPC連接到數(shù)據(jù)處理服務器模塊，并將本地的數(shù)據(jù)保存在服務器模塊的內(nèi)存表中。當所有map任務結(jié)束后，數(shù)據(jù)處理服務器模塊中的數(shù)據(jù)進行進一步的處理。本發(fā)明中，內(nèi)存表的實現(xiàn)是一個類似于MapReduce框架中的鍵值對。其中每一個key對應的值應該是一個鏈表，保存該鍵對應的所有值，從而可以在保存中間結(jié)果的基礎上，進一步地在內(nèi)存表中進行處理。以SELECT A，COUNT(B)FROM T GROUP BY A這個簡單查詢?yōu)槔Ｃ總€map任務保存每一個A的值對應的在本地的B的個數(shù)。當map統(tǒng)計完本地的數(shù)據(jù)之后，將這個數(shù)據(jù)發(fā)送給數(shù)據(jù)處理服務器模塊，以Ai: Count(B)il, count (B)i2，count (B)
i3......形式保存到數(shù)據(jù)服務器模塊的內(nèi)存表中，其中Ai = Count(B)ij表示在第j個map任務
中，相同的Ai對應的B的個數(shù)。然后再內(nèi)存表中匯總鍵Ai對應的所有count(B)u，就可以得到查詢的結(jié)果。另一方面，為了保證系統(tǒng)的功能足夠，這個內(nèi)存表應該實現(xiàn)去重、排序、求極值等基本功能。
3、Map Task在本發(fā)明中，Map Task的實現(xiàn)與傳統(tǒng)的MapReduce任務處理SQL查詢有所不同?？紤]到系統(tǒng)需要支持兩種查詢的執(zhí)行方式，Map Task應該以兩種不同的形式，即傳統(tǒng)的MapReduce形式和與內(nèi)存處理形式。傳統(tǒng)的MapReduce 形式的 Map Task,需要首先讀取 Hadoop Configuration,獲取查詢的相關參數(shù)和查詢條件，并根據(jù)這些查詢條件，建立對數(shù)據(jù)的過濾器。然后根據(jù)查詢的內(nèi)容，從指定的路徑讀取數(shù)據(jù)，進行查詢和過濾，并將過濾的結(jié)果寫入HDFS。在任務結(jié)束后，JobTracker啟動Reduce任務繼續(xù)處理數(shù)據(jù)。內(nèi)存處理形式的Map Task，首先需要連接數(shù)據(jù)處理服務器模塊。之后和傳統(tǒng)的Map Task相同，讀取查詢的參數(shù)并對數(shù)據(jù)進行處理。處理的過程中，Map Task不能將數(shù)據(jù)寫入HDFS，而應保存在本地的內(nèi)存中。當本地內(nèi)存滿時，Map Task應將本地的數(shù)據(jù)傳輸給數(shù)據(jù)處理服務器模塊，從而清除本地的數(shù)據(jù)繼續(xù)存儲。當任務結(jié)束時，JobTracker不再啟動Reduce任務處理數(shù)據(jù)。另外,對于最終結(jié)果較小的查詢,Map Task可以直接采用Map Scan的方式，直接從HDFS中讀取數(shù)據(jù)并存儲在內(nèi)存表中，即可作為最終結(jié)果。
權利要求
1.一種基于MapReduce擴展框架的分布式SQL查詢方法,其步驟為 1)客戶端發(fā)送查詢請求到查詢服務器模塊QueryServer，所述查詢服務器模塊包括SQL查詢接ロ、SLQ解析模塊和動態(tài)選擇模塊； 2)所述SQL查詢接ロ接收到查詢請求，將所述請求發(fā)送到SQL解析模塊，所述解析模塊解析得到查詢請求的語義； 3)所述動態(tài)選擇模塊根據(jù)查詢代價模型CostModel和語義規(guī)則對該查詢語義進行計算，預測出查詢結(jié)果需要的存儲空間，并選擇MapReduce查詢方式或內(nèi)存查詢方式； 3-1)查詢方式為MapReduce查詢時，Job Tracker啟動執(zhí)行Map操作和Reduce操作； 3-2)當查詢方式為內(nèi)存查詢吋，Job Tracker啟動Map操作，并將查詢數(shù)據(jù)保存至本地服務器的內(nèi)存表中； 4)當查詢結(jié)束，將本地查詢結(jié)果上傳至HDFS或數(shù)據(jù)處理服務器模塊DataProcessor。
2.如權利要求I所述的基于MapReduce擴展框架的分布式SQL查詢方法,其特征在于，所述擴展框架基于內(nèi)存表構(gòu)架，建立由查詢服務器模塊啟動并管理的數(shù)據(jù)處理服務器模塊，所述數(shù)據(jù)處理服務模塊用于內(nèi)存查詢方式中與每ー個map任務連接，收集map任務查詢結(jié)果并進行處理和輸出。
3.如權利要求I所述的基于MapReduce擴展框架的分布式SQL查詢方法,其特征在于，Map操作和數(shù)據(jù)處理服務器模塊Data Processor使用Hadoop RPC接ロ連接,通過設置傳輸閾值控制每次傳輸?shù)臄?shù)據(jù)塊大小。
4.如權利要求I所述的基于MapReduce擴展框架的分布式SQL查詢方法,其特征在于，所述SQL查詢接ロ面向用戶提供接ロ通過socket實現(xiàn),用于接收和返回客戶端查詢請求。
5.如權利要求I所述的基于MapReduce擴展框架的分布式SQL查詢方法,其特征在于，所述SQL解析模塊通過antlr工具實現(xiàn)，所述antlr根據(jù)用戶提供的語法文件，生成對應的語法分析器。
6.如權利要求5所述的基于MapReduce擴展框架的分布式SQL查詢方法,其特征在于，所述SQL解析模塊解析得到查詢請求的語義，形成語法樹；所述語法樹是以SQL查詢中符號和操作符為節(jié)點的樹。
7.如權利要求6所述的基于MapReduce擴展框架的分布式SQL查詢方法,其特征在于，遍歷所述語法樹，井根據(jù)元組數(shù)據(jù)Meta Data的信息，得到查詢語義。
8.如權利要求I所述的基于MapReduce擴展框架的分布式SQL查詢方法,其特征在于，所述建立查詢代價模型相關參數(shù)信息根據(jù)元組數(shù)據(jù)Meta Data、查詢語句本身或者查詢的歷史記錄中取得，包括表的模式信息、表中每列的平均數(shù)據(jù)大小、表中記錄的數(shù)量、表中每一列的數(shù)據(jù)分布情況、查詢條件。
9.如權利要求I所述的基于MapReduce擴展框架的分布式SQL查詢方法,其特征在于，所述語義規(guī)則的動態(tài)選擇方法根據(jù)查詢的種類、表的數(shù)據(jù)量信息來判斷查詢的執(zhí)行方式。
10.如權利要求I所述的基于MapReduce擴展框架的分布式SQL查詢方法,其特征在于，在內(nèi)存查詢時可通過MapScan掃描方法對數(shù)據(jù)進行查詢，將結(jié)果直接輸入到內(nèi)存表中。
全文摘要
本發(fā)明涉及基于MapReduce擴展框架的分布式SQL查詢方法，1)客戶端發(fā)送查詢請求到查詢服務器模塊QueryServer，所述查詢服務器模塊包括SQL查詢接口、SLQ解析模塊和動態(tài)選擇模塊；2)所述SQL查詢接口接收到查詢請求，將所述請求發(fā)送到SQL解析模塊，所述解析模塊解析得到查詢請求的語義；3)所述動態(tài)選擇模塊根據(jù)查詢代價模型Cost Model和語義規(guī)則對該查詢語義進行計算，預測出查詢結(jié)果需要的存儲空間，并選擇MapReduce查詢方式或內(nèi)存查詢方式；4)當查詢結(jié)束，將本地查詢結(jié)果上傳至HDFS或數(shù)據(jù)處理服務器模塊Data Processor。本發(fā)明基于內(nèi)存的拓展框架，利用內(nèi)存處理的方式處理SQL查詢，在內(nèi)存中完成數(shù)據(jù)處理，提高查詢的效率。同時查詢服務器模塊實現(xiàn)與客戶端的交互和查詢處理方式的動態(tài)選擇。
文檔編號G06F17/30GK102799622SQ201210209080
公開日2012年11月28日 申請日期2012年6月19日 優(yōu)先權日2012年6月19日
發(fā)明者王衎, 高軍, 王騰蛟, 楊冬青, 唐世渭 申請人:北京大學