一種基于Spark大數(shù)據(jù)處理平臺的查詢方法
【技術(shù)領域】
[0001] 本發(fā)明涉及一種數(shù)據(jù)處理的查詢方法，尤其涉及一種基于Spark大數(shù)據(jù)處理平臺 的查詢方法。
【背景技術(shù)】
[0002] 隨著互聯(lián)網(wǎng)的發(fā)展，數(shù)以萬計的網(wǎng)頁不斷涌現(xiàn)，而要搜索這些網(wǎng)頁首先要抓取存 儲，然后進行分析計算，google就是這么做的，但是日益龐大的數(shù)據(jù)使得存儲面臨著單臺機 器容量不夠的問題，查詢面臨著耗時太多的問題;針對這兩個問題，google提出了分布式存 儲和分布式并行計算的解決方案，而后來的hadoop產(chǎn)品是這種解決方案的源碼實現(xiàn)； hadoop提供了分布式文件系統(tǒng)HDFS和分布式并行計算框架MapReduce，隨著hadoop的發(fā)展， 其生態(tài)系統(tǒng)又不斷涌現(xiàn)新的項目產(chǎn)品，如Hbase、hive、pig等，但它們都是基于HDFS存儲層 和MapReduce計算框架，MapReduce通過在集群的多個節(jié)點上并行執(zhí)行計算，因此大大加快 了查詢的速度，但隨著數(shù)據(jù)量的日益增大，MapReduce漸漸顯得力不從心，于是基于內(nèi)存計 算的Spark計算框架應運而生，Spark的查詢速度相比hadoop提升了100倍，因此是目前最先 進的分布式并行計算框架；隨著Spark生態(tài)系統(tǒng)的發(fā)展，在其上又涌現(xiàn)出Spark SQL、Spark Streaming、ML1 ib、GraphX等，其中Spark SQL是針對SQL用戶開發(fā)的可以用SQL語言對結(jié)構(gòu) 化數(shù)據(jù)進行分析查詢的工具。
[0003] 如圖1所示，現(xiàn)有技術(shù)中，以使用Spark SQL應用程序為例，基于Spark大數(shù)據(jù)處理 平臺的查詢方法可以分為五個步驟：
[0004] 步驟I、Spark SQL應用程序接收用戶的SQL語句后，進行語法解析、執(zhí)行策略優(yōu)化、 job (查詢作業(yè))生成，最后通過調(diào)用Spark平臺中的SparkContext接口進行job的提交；
[0005] 步驟2、SparkContext收到job后，定義Task (計算任務)執(zhí)行成功后如何存儲計算 結(jié)果，然后提交job給eventProcessActor，接著等待eventProcessActor告知job執(zhí)行結(jié)束， 結(jié)束后將計算結(jié)果返回給Spark SQL;
[0006] 步驟3、eventProcessActor收到提交job的事件后，在各個節(jié)點分配多個Task開始 并行計算；
[0007] 步驟4、每個Task執(zhí)行完畢后向eventProcessActor報告狀態(tài)和結(jié)果， eventProcessActor統(tǒng)計job的所有Task是否全部完成，若完成，則通知SparkContext提交 的job已結(jié)束，SparkContext返回計算結(jié)果給Spark SQL;
[0008] 步驟5、Spark SQL得到計算結(jié)果后，先進行格式轉(zhuǎn)化，然后拷貝一份給輸出模塊， 最后由輸出模塊輸出結(jié)果。
[0009] 如圖2所示，步驟1主要是解析SQL語句的語法并生成一組代表一個Job的RDD，RDD 是一種分布式數(shù)據(jù)結(jié)構(gòu)，它描述了要處理的分布式存儲的數(shù)據(jù)以及怎樣處理的算法，因此 一個RDD就代表對數(shù)據(jù)的一個操作，一組RDD就是一個操作序列，按序完成了這一系列操作 后即代表完成了一次查詢計算；Spark采用了延遲執(zhí)行策略，即每個操作不先執(zhí)行，而是先 生成操作的序列，然后把這個序列發(fā)送給執(zhí)行器執(zhí)行;這一組RDD所代表的操作因為有序且 不循環(huán)，因此其組成的邏輯依賴圖又稱有向無環(huán)圖（DAG);在DAG中，下游的RDD是上游的RDD 執(zhí)行某個操作后生成的。
[0010]如圖3所示，步驟2主要是將D A G提交給處于另一個線程環(huán)境的 eventProcessActor，提交前，分配一塊內(nèi)存，并告知eventProcessActor當Task執(zhí)行成功后 往這塊內(nèi)存中存儲結(jié)果，提交后，當前線程掛起，等待eventProcessActor在job完成后喚醒 它，被喚醒后，此時所有Task已經(jīng)執(zhí)行結(jié)束，并且計算結(jié)果全部已經(jīng)存儲到事先分配的內(nèi)存 中；因此直接將這塊存儲了結(jié)果的內(nèi)存地址返回給Spark SQL模塊。由于要等到所有Task執(zhí) 行結(jié)束才能返回結(jié)果，因此客戶響應時間過長，事實上，每個Task的結(jié)果都是最終結(jié)果的一 個子集，沒有必要一起輸出所有的結(jié)果子集;另外，由于輸出前要存儲整個查詢結(jié)果，結(jié)果 的大小將直接受限于程序的堆棧大小。
[0011] 如圖4所示，步驟3主要是實現(xiàn)DAG階段的劃分以及每個階段Task集合的生成。每個 階段的所有Task執(zhí)行的都是相同的操作，只不過它們作用的數(shù)據(jù)不同罷了，因此它們可以 完全并行執(zhí)行;但是不同階段的Task就不一定能并行了。每個深灰色填充矩形代表一個數(shù) 據(jù)塊，并且每個數(shù)據(jù)塊都對應一個Task對其進行計算，由于RDD2的數(shù)據(jù)塊是根據(jù)RDD1的多 個數(shù)據(jù)塊計算得來的，因此就需要等待執(zhí)行RDDl的所有Task結(jié)束才能開始計算RDD2,所以 RDDl和RDD2需要分屬兩個不同的階段，而RDD2計算出RDD5時，每個數(shù)據(jù)塊都是獨立進行的， 互不依賴，RDD2中計算其中一個數(shù)據(jù)塊的Task不需要等待其它數(shù)據(jù)塊的Task結(jié)束即可開始 向RDD5生成的計算（此處是join操作），因此RDD2和RDD5可以同屬一個階段；同理，RDD3和 RDD4可以同屬一個階段，但RDD4不能和RDD5同屬一個階段；圖4中，stagel和stage2互不依 賴，可以并行執(zhí)行，stage3同時依賴stagel和stage2，因此必須等待stagel和stage2均完成 后才能執(zhí)行。
[0012] 如圖5所示，步驟4主要是最后一個階段的Task執(zhí)行成功后，將計算結(jié)果存儲到 SparkContext指定的內(nèi)存中；在圖5中，stagel和stage2的Task執(zhí)行結(jié)束后只生成中間結(jié) 果，stage3的每個Task才是最終結(jié)果，而最終輸出的結(jié)果是由stage3的每個Task的結(jié)果拼 接而成，在拼接的過程中可能會有排序。如圖6所示，如果查詢語句要求對結(jié)果進行排序，則 Task的結(jié)果按序存放，如果不對結(jié)果排序，則結(jié)果按照Task完成的先后順序排序，每次查詢 的結(jié)果排列順序?qū)⑹请S機的。對于結(jié)果排序的情況，既然每個Task知道它的結(jié)果應該排在 什么位置，那么應該排在首位的Task就已經(jīng)計算出了最終結(jié)果的頭部，可以立即通知客戶 了；對于結(jié)果不排序的情況，由于客戶不關心結(jié)果的排列順序，因此不管哪個Task先計算完 成，其結(jié)果就可以告知客戶了，沒有必要去等到其它Task，而且即使等待，最終的結(jié)果也是 按照它們執(zhí)彳丁完成的先后順序排序的。
[0013] 步驟5主要是對記錄行數(shù)組形式的結(jié)果格式化為字符串序列，每一行記錄轉(zhuǎn)換成 字符串格式，并且將列分隔符替換為制表符，最后輸出模塊在提取格式化后的結(jié)果時，復制 一份到輸出模塊，然后輸出。事實上，對結(jié)果的格式化不是必須的，格式化可能看起來更美 觀，但是卻消耗了大量內(nèi)存和性能，在某些情況下，數(shù)據(jù)本身已經(jīng)很工整了，此時就沒必要 去格式化。
[0014] 綜上所述，現(xiàn)有技術(shù)中基于Spark大數(shù)據(jù)處理平臺的查詢方法存在以下技術(shù)問題：
[0015] 1、目前Spark大數(shù)據(jù)處理平臺執(zhí)行查詢時，用戶響應時間過長，尤其是分析較大規(guī) 模數(shù)據(jù)時，其響應時間更是超出了用戶所能忍受的程度，并且隨著分析數(shù)據(jù)量的增大，這種 響應延遲也將同步增加。
[0016] 2、目前Spark大數(shù)據(jù)處理平臺不支持大規(guī)模查詢結(jié)果的輸出，默認配置只允許輸 出IG的查詢結(jié)果數(shù)據(jù)量，配置的過少，將不能充分利用內(nèi)存資源，配置的過多，若結(jié)果超出 實際剩余的內(nèi)存空間將導致內(nèi)存溢出異常;再者，對于內(nèi)存配置較低的機器環(huán)境，允許輸出 的數(shù)據(jù)量將進一步大大縮減。
[0017] 3、Spark SQL在獲取Spark大數(shù)據(jù)處理平臺的計算結(jié)果后，要進行一些格式轉(zhuǎn)化和 數(shù)據(jù)拷貝后才正式輸出，將造成內(nèi)存中相同或近似相同的數(shù)據(jù)有多個拷貝，浪費了內(nèi)存資 源，也降低了性能，也直接影響了用戶響應和結(jié)果存儲容量，并且這種影響會隨著輸出結(jié)果 的增大而增大。

【發(fā)明內(nèi)容】

[0018] 本發(fā)明要解決的技術(shù)問題是提供一種基于Spark大數(shù)據(jù)處理平臺的查詢方法，該 查詢方法在執(zhí)行常規(guī)的簡單查詢時(DAG階段比