天天看點

GOOGLE分布式資料庫技術演進研究--從Bigtable、Dremel到Spanner(二)

首先申明,裡面對技術背景和後續技術發展方向的内容,來自于個人技術上的思考和判斷,并非引經據典,僅供參考。

3  Dremel

3.1背景

       大規模互動性資料分析處理在整個行業中應用越來越廣泛,對于互動型分析對于資料處理的響應時間要求比較高,而原有Bigtable資料庫設計上并沒有考慮對于互動式場景要求,對于大大規模互動資料分析處理響應性不夠,是以Dremel就應運而生,Dremel解決大規模互動資料分析的實時性問題,可以做到秒級的資料響應,GOOGLE在測試中宣稱,可以在3秒鐘的時間處理1PB資料。

    在大規模互動資料分析中,會有這樣一種場景,需要參加資料分析的原始資料量非常大,但是最終結果集資料量會很小,往往是一個分析結果或者是彙總型的資料,這種場景就是大型互動時資料分析的典型場景。從GOOGLE分布式資料庫産品的戰略定位看,Dremel和Bigtable的定位有所不同,Dremel更适合對于互動式場景,而Bigtable通常會跟MapReduce配置,做為大資料處理搭配處理,當然Dremel同樣可以與MAPReduce結合使用。是以Dremel并不是取代Bigtable的一種分布式資料庫,而是一種補充,從技術演進角度看,由于Dremel資料庫公開時間晚于Bigtable,是以做為Google第二代分布式資料庫代表之一。

3.2 Dremel的資料模型

3.2.1 Dremel嵌套列資料模型

Dremel采用是嵌套列資料模型,該資料模型把嵌套資料拆分為列結構加以存儲,在查詢時把資料重建為嵌套資料,原有列存儲資料庫通常屬于關系型資料庫,在嵌套類型的資料處理還未采用這種結構,GOOGLE創造性的把嵌套資料處理為列資料庫,并且技術名額還能大幅提升,滿足大型資料的互動式查詢要求,不得不說這個GOOGLE的一個新創造,但為什麼是這樣的列嵌套結構,而不是其他資料結構,這點GOOGLE并沒有進行介紹說明,是以這一點了解上面有一定困難,不過在後續介紹中,會發現這種結構在資料查詢處理時的優勢和特點。

  一提起數學模型,很多程式員就會暈,不過仔細看看,稍微有一點資料知識的人,應該就能夠看明白,Dremel的數學模型如下:

π = dom | <A1 : π[*|?],…,An :π[*|?]>

π是資料庫中的一條記錄類型,Ai是資料庫記錄的一個字段,*為一個重複字段,?為可選字段,這個資料模型說明該一條記錄是由多個字段構成,字段類型由可選字段、必選字段、重複字段組成,可選字段可以出現,也可以不出現;必選字段必須會出現,重複字段則會出現多次。在GOOGLE公開的資料中,在圖3-1給出嵌套記錄樣例和資料模式定義,Document是一個網頁類型的資料模式,該網頁有整形的DocId和可選的Link分組屬性,Link分組屬性包含了多個Backword和Forward可

GOOGLE分布式資料庫技術演進研究--從Bigtable、Dremel到Spanner(二)

圖3-1  嵌套式記錄樣例和資料模式定義

重複的整型屬性構成清單,一個網頁包括了多個可以重複的名字分組,每個名字分組,可以包括多個語言分組和可選的URL位址,語言分組包括必選的CODE字段,可選的Country屬性。整個Document嵌套層次關系如圖3-2:

GOOGLE分布式資料庫技術演進研究--從Bigtable、Dremel到Spanner(二)

圖3-2 嵌套層次關系圖

3.2.2 Dremel的重複深度和定義深度

在Dremel中如何對于嵌套式資料結構,在列存儲後進行重建,依賴于二個重要參數,一個是RepetitionLevel重複深度,一個是Definition Level定義深度.重複深度和定義深度僅針對重複字段來計算層次,用于描述這個值什麼重複字段的此值重複了,以此确定重複的位置;定義深度描述多個嵌套層次的路徑上,有多少個字段是有值的,通過這二個參數可以完成嵌套資料的列式化存儲。  

3.2.3 Dremel的存儲和重構

Dremel存儲是采用列式模型,按照列進行嵌套式資料的存儲,讀取資料時,根據定義在列式模型中的資料,按照順序,把列式存儲資料還原到原有的嵌套式資料結構。

3.3 Dremel的系統架構和查詢

Dremel采用的是多層次服務樹架構,最上層Dremel的根伺服器,根伺服器接收所有的查詢請求,讀取資料庫相關的中繼資料,并把相關請求下發到下一級查詢伺服器查詢。中間層查詢伺服器負責根伺服器請求的派發和葉子伺服器的查詢結果的處理。葉子伺服器與具體存儲層直接通訊,完成存儲系統上相關資料的讀取和查詢動作,整個系統架構圖如下圖所示。

GOOGLE分布式資料庫技術演進研究--從Bigtable、Dremel到Spanner(二)

圖3-3 Dremel多層次查詢樹架構

Dremel查詢語句基于SQL文法,并根據自身列存儲模型進行了定制,構成在Dremel的存儲結構上面高效的執行,對于Dremel查詢樹結構,會對于根查詢伺服器收到查詢請求進行層層拆分,最終傳遞到葉節點的查詢伺服器,葉節點查詢伺服器擷取的資料結果後,進行過濾和彙總這樣的計算,然後在上傳到上級查詢伺服器,層層彙總結果後,最終傳回結果資料。

Dremel支援多用戶端并發查詢,通常情況下查詢請求會被同時運作,查詢派發器,會根據系統的負載情況和查詢優先級進行一定的查詢排程操作,并提供容錯性,對于查詢節點響應緩慢和通路資料不達的情況進行調整。

3.4 應用場景和關鍵技術

3.4.1 應用場景

Dremel定位為互動系統大型資料處理的資料庫系統,适合資料讀取資料量大,但是傳回資料量小的場景,對于傳回資料量大的場景,采用Dremel就不太合适。

3.4.2關鍵技術

Dremel采用的嵌套式列存儲結構+多層次查詢查詢樹,大型資料處理快速響應的關鍵,列存儲結構可以隻對查詢關心的列資料讀取,多層次查詢樹結構對于資料查詢的拆分和聚合的方式有效的比對,這是Dremel在該場景速度快于Bigtable的關鍵技術;

Dremel号稱可以在秒級進行1PB級的資料運作,沒有看到公開的驗證資料,該這種1PB級的資料,從個人推斷應該是所有列存儲資料占用空間的總大小,而不是僅僅該字段占用空間的大小。

Dremel結構解決了傳統的多表資料通過外鍵關聯效率緩慢的問題,通過存儲列資料的順序結構解決了多表資料的關聯問題,思路非常巧妙。

3.4.2技術展望

Dremel對于标準的SQL文法是不支援的,為了滿足高效率查詢,設計了與自身結構相比對的查詢語句,是以Dremel對于資料庫一些通用SQL查詢支援是不夠的,更像是一種處理互動式資料查詢的分支資料庫,與通常意義上面講的BIGTABLE資料庫使用場景有很大的差別,是以應該屬于分布式資料庫發展的分支技術方向,而不是主流發展方向。

後續Dremel是否能夠對于嵌套式資料庫模型進一步的優化,提供部分SQL标準接口,這些都是Dremel後續可能的發展方向。

--剩下的第三個部分是spanner和整個對比總結,任務很重,要完成有點懸。

繼續閱讀