面向OLAP的大規(guī)模分布式內存列式數據庫查詢引擎.pdf_第1頁
已閱讀1頁,還剩85頁未讀, 繼續(xù)免費閱讀

下載本文檔

版權說明:本文檔由用戶提供并上傳,收益歸屬內容提供方,若內容存在侵權,請進行舉報或認領

文檔簡介

1、聯機分析處理(On-line Analytical Processing, OLAP)是數據庫領域的主要應用,但隨著數據量的日益膨脹,如何在海量數據中快速挖掘出數據潛在的價值成為當下數據庫領域的一個重大挑戰(zhàn)。現有的分布式數據庫系統(tǒng)在查詢引擎的選擇上分為兩大類,一類是采用通用計算引擎諸如Map/Reduce或Spark,其最大的缺陷在于,Map/Reduce和Spark在計算模型上仍然屬于同步計算模型,在計算上存在同步過程,導致較大的查詢

2、延遲,此外基于Spark的分布式數據庫系統(tǒng)存在過高的計算內存開銷。另一類分布式數據庫系統(tǒng)采用專用分布式查詢引擎,諸如Impala以及HAWQ等。這類系統(tǒng)將傳統(tǒng)數據庫查詢模型并行化,一定程度上突破了傳統(tǒng)數據的計算瓶頸,然而這類數據庫依然存在如下不足:1)計算模型沿用傳統(tǒng)數據庫的volcano模型即按行查詢,然而在OLAP業(yè)務中,采用按行查詢的方式會引入過多的中間數據導致額外的運算開銷。2)在分布式計算任務調度上沒有很好的調度算法來提升整體

3、的查詢速度以及集群資源利用率。
  本文針對上述系統(tǒng)中存在的缺陷,提出了一種新型的面向OLAP的大規(guī)模分布式內存列式數據庫查詢引擎,該引擎在處理海量數據時擁有較低的查詢延遲以及內存開銷。論文主要有三方面工作:1)對時下業(yè)界熱門的分布式數據庫查詢引擎進行研究與分析,按照通用數據庫計算引擎和專用數據庫計算引擎對其進行分類,提煉其主要優(yōu)缺點;將分布式計算任務調度抽象為工作流調度問題(workflow scheduling),研究對比現有

4、的啟發(fā)式算法,主要包括List Scheduling類算法與遺傳算法。2)設計并實現了一套高效的基于列式語義的分布式內存數據庫計算引擎,支持從SQL解析到結果數據生成這一完整的查詢流程,支持海量數據的實時查詢并具有良好的容錯性能。3)設計并實現了一套分布式任務調度優(yōu)化算法,能靈活適應變化的查詢場景并快速提供有效的調度優(yōu)化方案。
  在系統(tǒng)設計與實現上,本文主要有三點創(chuàng)新:1)采用數據流圖表示SQL查詢任務,按照列式數據庫語義,全異

5、步地推進任務的執(zhí)行,消除在同步計算模型中因同步過程所帶來的計算開銷。2)設計并實現高效的列式中間數據結構,具有很好的序列化與反序列化性能并能有效減少內存碎片。3)結合深度增強學習算法與傳統(tǒng)啟發(fā)式調度算法提出了一種新型的分布式任務調度方法來解決工作流調度問題,具有很好的靈活性以及調度結果。
  最后,本文從查詢引擎計算模型的查詢性能以及調度優(yōu)化算法的調度效果兩方面對查詢引擎進行測試。其中,針對查詢性能的測試,本文引入標準的面向OLA

6、P數據庫測試集TPC-H對查詢引擎進行全面的功能測試以及性能測試;針對調度優(yōu)化算法,將本文所設計的算法與其他經典的啟發(fā)式算法調度結果進行對比。測試結果顯示,本文所設計的查詢引擎在單表掃描語句性能上是Spark-SQL的10倍,是Hive-on-tez的20倍,在Join語句性能上和Spark-SQL持平,在分組聚合語句上性能是Spark-SQL的5倍。在內存開銷上本文設計的查詢引擎是Spark-SQL的1/8。在調度優(yōu)化算法上,調度結果

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯系上傳者。文件的所有權益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網頁內容里面會有圖紙預覽,若沒有圖紙預覽就沒有圖紙。
  • 4. 未經權益所有人同意不得將文件中的內容挪作商業(yè)或盈利用途。
  • 5. 眾賞文庫僅提供信息存儲空間,僅對用戶上傳內容的表現方式做保護處理,對用戶上傳分享的文檔內容本身不做任何修改或編輯,并不能對任何下載內容負責。
  • 6. 下載文件中如有侵權或不適當內容,請與我們聯系,我們立即糾正。
  • 7. 本站不保證下載資源的準確性、安全性和完整性, 同時也不承擔用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

評論

0/150

提交評論