首先申明，裏面對技術背景和後續技術發展方向的內容，來自於個人技術上的思考和判斷，並非引經據典，僅供參考。
3 Dremel
3.1背景
大規模交互性數據分析處理在整個行業中應用越來越廣泛，對於交互型分析對於數據處理的響應時間要求比較高，而原有Bigtable數據庫設計上並沒有考慮對於交互式場景要求，對於大大規模交互數據分析處理響應性不夠，因此Dremel就應運而生，Dremel解決大規模交互數據分析的實時性問題，可以做到秒級的數據響應，GOOGLE在測試中宣稱，可以在3秒鐘的時間處理1PB數據。
在大規模交互數據分析中，會有這樣一種場景，需要參加數據分析的原始數據量非常大，但是最終結果集數據量會很小，往往是一個分析結果或者是彙總型的數據，這種場景就是大型交互時數據分析的典型場景。從GOOGLE分佈式數據庫產品的戰略定位看，Dremel和Bigtable的定位有所不同，Dremel更適合對於交互式場景，而Bigtable通常會跟MapReduce配置，做爲大數據處理搭配處理，當然Dremel同樣可以與MAPReduce結合使用。因此Dremel並不是取代Bigtable的一種分佈式數據庫，而是一種補充，從技術演進角度看，由於Dremel數據庫公開時間晚於Bigtable，因此做爲Google第二代分佈式數據庫代表之一。
3.2Dremel的數據模型
3.2.1Dremel嵌套列數據模型
Dremel採用是嵌套列數據模型，該數據模型把嵌套數據拆分爲列結構加以存儲，在查詢時把數據重建爲嵌套數據，原有列存儲數據庫通常屬於關係型數據庫，在嵌套類型的數據處理還未採用這種結構，GOOGLE創造性的把嵌套數據處理爲列數據庫，並且技術指標還能大幅提升，滿足大型數據的交互式查詢要求，不得不說這個GOOGLE的一個新創造，但爲什麼是這樣的列嵌套結構，而不是其他數據結構，這點GOOGLE並沒有進行介紹說明，因此這一點理解上面有一定困難，不過在後續介紹中，會發現這種結構在數據查詢處理時的優勢和特點。
一提起數學模型，很多程序員就會暈，不過仔細看看，稍微有一點數據知識的人，應該就能夠看明白，Dremel的數學模型如下：
π = dom | <A1 : π[*|?],…,An :π[*|?]>
π是數據庫中的一條記錄類型，Ai是數據庫記錄的一個字段，*爲一個重複字段，?爲可選字段，這個數據模型說明該一條記錄是由多個字段構成，字段類型由可選字段、必選字段、重複字段組成，可選字段可以出現，也可以不出現；必選字段必須會出現，重複字段則會出現多次。在GOOGLE公開的資料中，在圖3-1給出嵌套記錄樣例和數據模式定義，Document是一個網頁類型的數據模式，該網頁有整形的DocId和可選的Link分組屬性，Link分組屬性包含了多個Backword和Forward可
圖3-1 嵌套式記錄樣例和數據模式定義
重複的整型屬性構成列表，一個網頁包括了多個可以重複的名字分組，每個名字分組，可以包括多個語言分組和可選的URL地址，語言分組包括必選的CODE字段，可選的Country屬性。整個Document嵌套層次關係如圖3-2：
圖3-2 嵌套層次關係圖
3.2.2Dremel的重複深度和定義深度
在Dremel中如何對於嵌套式數據結構，在列存儲後進行重建，依賴於二個重要參數，一個是RepetitionLevel重複深度，一個是Definition Level定義深度.重複深度和定義深度僅針對重複字段來計算層次，用於描述這個值什麼重複字段的此值重複了，以此確定重複的位置；定義深度描述多個嵌套層次的路徑上，有多少個字段是有值的，通過這二個參數可以完成嵌套數據的列式化存儲。
3.2.3Dremel的存儲和重構
Dremel存儲是採用列式模型，按照列進行嵌套式數據的存儲，讀取數據時，根據定義在列式模型中的數據，按照順序，把列式存儲數據還原到原有的嵌套式數據結構。
3.3Dremel的系統架構和查詢
Dremel採用的是多層次服務樹架構，最上層Dremel的根服務器，根服務器接收所有的查詢請求，讀取數據庫相關的元數據，並把相關請求下發到下一級查詢服務器查詢。中間層查詢服務器負責根服務器請求的派發和葉子服務器的查詢結果的處理。葉子服務器與具體存儲層直接通訊，完成存儲系統上相關數據的讀取和查詢動作，整個系統架構圖如下圖所示。
圖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和整個對比總結，任務很重，要完成有點懸。