4 Spanner
4.1背景
在google的BIGTABLE論文中，提到過Bigtable後續計劃支持多Master的方向，由於BIGTABLE的架構中，只有一個Master服務器，因此一個Bigtable分佈式數據庫的擴展能力，始終是由一定的限制，數據量增加後，勢必需要就會出現瓶頸，如何提升數據庫的數據管理能力，解決數據規模不斷增加後帶來的問題。同時Bigtable丟失傳統RDMS系統的一些特點，比如多數據表之間的事務一致性，這些都是數據庫必須也是應該具背的特性。是否能夠滿足分佈式數據庫的數據分佈、負載和吞吐量的同時，還具備關係數據庫特性，這不就是分佈式數據庫的智高無上的理想嗎？但分佈式數據庫CAP理論告訴我們，分佈式數據庫一致性，可用性、分區容忍性此特性必然只能取其二，是不可能同時具備，這個魔咒能夠被打破嗎？
阿迪有一句名言“Nothing is impossible”勢必需要引入一種新的機制,聰明的Google人找到並解決方案，並在技術上得以實現，Spanner就是在這個場景下面誕生。
4.2 Spanner的數據模型
4.2.1 帶獨立時間戳映射結構
Spanner有一種負責專門管理數據的spanserver，spanserver也是基於bigtable的tablet結構，每個spanserver由上百個或者上千個tablet構成，Spanserver類似於Bigtable中tablet服務器，是管理數據的核心組件，spanserver的Tablet存在下面映射(key:string, timestamp:int64) –> string，這種映射與Bigtable採用的Key-Value結構第一眼看去貌似一樣，但仔細看確有很大差別，時間字段不在是Key一個組成部分，而是把時間戳單獨了出來作爲一個獨立項，構成了一個多版本的數據庫，獨立時間戳意味着時間在Spanner中會扮演重要角色。
4.2.2 spanserver的軟件層次
一個tablet由數據和狀態部分構成，存放在一種稱作Colossus的文件系統中，該文件系統爲GFS後繼的文件系統，爲了支持數據同步複製，在spanserver上部署有一個paxos狀態機, paxos狀態機用於實現一系列被一致性複製的映射。一個數據有多個數據副本，多個數據副本所在的paxos狀態機組織成一個paxos 分組，用於控制副本一致性。對於主副本，spanserver會增加鎖表來保證併發性控制，對於在一個跨越多個Paxos分組的事務，需要在Paxos更上層的確定出主副本機制，以保證跨Paxos分組的事務性。整個結構如圖4-1所示，在圖中可以看出，由於涉及同步的複製範圍不同，需要參與協商Leader的範圍就會發生變化，但不管如何變化，始終是可以根據上升的原則，通過協商機制，實現更大範圍的事務控制。
圖4-1Spanserver 軟件層次圖
4.2.3 Spanner的目錄結構
Spanner提供了一種最爲基礎鍵值映射集合的邏輯視圖，這個邏輯視圖實際上是一個桶的作用，用於把提供一系列鍵值映射集合放在一起存儲，只是爲了便於理解，在Spanner中，把這種桶叫做目錄。由於鍵值存放的數據可能存在於不同的Paxos分組，各Paxos所對應物理存儲可能在不同的Spanserver服務器上，這些數據也可能屬於不同zone,因此雖然這些數據都可以被訪問，但訪問讀取時需要通過長距離的網絡傳輸，因此訪問效率可能就不太高。
Spanner中提出了目錄概念，就是要把目錄作爲數據放置的最小單位，目錄可以在Spanner中進行移動，移動原則是相關數據儘量存放在一起，這樣可以提升Spanner的訪問效率，可以看出邏輯桶結構對於Spanner這種巨型的分佈式數據庫效率提升具有十分重要的意義，能夠讓系統在數據分佈的同時，照顧到數據物理位置，儘量以訪問效率的原則進行數據物理位置的調整，以解決效率問題。目前這種調整的依據還是隻能根據訪問頻率的方式來進行調整，當一個目錄所管理的鍵值映射集合太大時，會進行分割操作，分裂爲多個目錄。
4.2.4 Spanner的半關係模型
Spanner的模型屬於半關係型模型，每個表都必須包含一個或者多個主鍵的排序集合，這一點類似於Key-Value的結構，這種結構的好處是可以方便的根據這種主鍵來進行數據存放位置控制，這種位置屬性可以解決分佈式數據的位置聚集要求，提升系統訪問的性能，但是帶來的一個問題，系統需要存放一些冗餘信息，對於沒有主鍵的行，也必須存儲爲NULL值。在圖4-2對於這種半關係模型進行了說明，這個例子中有2個表，用戶和相冊，相冊是依賴於用戶這個表格，在相冊定義是就增加了用戶的信息，這種結構可以根據客戶端分割爲一個表或者多個表的層次結構，以用戶爲主鍵，可以按照用戶來組織目錄，這種方式就可以結合上面目錄結構做到位置集聚，解決由於數據物理分佈引起的效率問題。
圖4-2 Spanner半關係型數據表定義示例
4.3 Spanner的系統架構
Spanner設計爲一個全球型，可擴展的巨型分佈式數據庫，可以把不同的應用放在一個Spanner中，而不像Bigtable需要建立不同的Bigtable集羣。Spanner可以支持這些存放數據的同步和複製，在保證效率的基礎上，進行數據複製，整個Spanner系統架構如圖4-3所示，UniverseMaster爲Spanner的總控制檯，一個Spanner只有一個Universe Master，對於zone進行管理，包括創建、刪除，同時也顯示zone的各鍾狀態信息； Palacement driver爲目錄移動控制器，會週期性的與Spanserver進行通訊，確定需要轉移目錄、滿足系統更新後的副本約束條件，系統負載調整所需目錄中數據轉移，優化數據物理存儲，轉移速度控制在分鐘級別，一個Spanner只有一個Palacement driver；一個Spanner由許多個zone構成，zone類似於Bigtable數據庫的角色。zone是管理部署的基本單元，Spanner中的zone中的數據都可以支持複製，可以在Zone之間進行數據複製，這種特性爲新加入zone和刪除或者替換zone時，提供了良好的擴展性。一個Zone有一個zone Master 和許多Spanserver構成，Zone Master把數據分配給Spanserver，由Spanserver提供給客戶端數據庫服務，客戶端通過Zone上面的Locationproxy來確定爲客戶端提供服務的Spanserver。
圖4-3 Spanner架構圖
4.4 Spanner查詢
4.4.1 Spanner只讀查詢
Spanner收到一個數據讀取操作後， 根據發起查詢請求，計算出整個查詢需要涉及到那些鍵值，涉及到的鍵值有多少Paxos分組，只涉及一個Paxos分組和涉及多個Paxos分組的處理邏輯有所不同。
涉及一個Paxos分組，按照下面步驟來獲取數據：
步驟一客戶端對Paxos組的領導者發起一個只讀事務；
步驟二 Paxos組的領導者分配爲這個讀操作分配一個時間戳，這個分配過程Paxos組領導必須要考慮到現在已經申請處理的事務，確保這個時間戳可以讓該讀取看到最後一次寫之後的數據；
步驟三按照分配的時間戳進行數據讀取。
涉及多個Paxos分組時，步驟會有所不同，按照下面步驟獲取數據：
步驟一客戶端發起一個只讀事務；
步驟二多個Paxos組領導者進行協商後，分配一個時間戳；
步驟三按照分配時間戳進行數據讀取。
4.4.2 Spanner讀寫操作
Spanner對於讀取和寫入操作會進行拆分，發生在一個事務中寫操作會在客戶端進行緩存，先執行讀操作，因此這種事務讀取操作不會看到這個事務寫操作結果。
讀操作在自己數據相關的Paxos組中先獲取到讀鎖，讀鎖作用是明確讀先執行讀操作，避免寫操作申請到寫鎖，申請到讀鎖後，分配給客戶端對應時間戳進行讀操作，但所有讀取操作完成後，釋放掉讀鎖。
讀鎖釋放完成後，客戶端開始處理所有已經緩存的寫操作，也是通過Paxos協商機制進行協商，獲取到寫鎖，分配對應的預備時間戳後，然後根據預備時間戳中的最大時間，確定一個提交時間戳，在提交時間戳同時進行寫操作的事務提交。
4.5 應用場景和關鍵技術
4.5.1 應用場景
Spanner的特點使其具備特定關係型數據庫的特點，其應用的場景可以部分替換原有關係型數據庫的使用場景，原有Bigtable丟失的關係型數據庫的特性，在實際應用中也暴露出了存在缺陷，而Spanner着力於找回這些丟失的特性，提供表數據的外部一致性和讀取的全局一致性、跨中心數據的一致性複製，從Google的應用實際看，GOOGLE可以使用F1+Spanner的方式來完全滿足關係型數據的特性，而Spanner就是這裏組合的基礎，不滿足部分由F1來實現。同時，由於Spanner數據庫的管理能力非常巨大，可以設定多個區域，每個區域的管理能力都與Bigtable相當，因此是一個全球性的巨型數據庫，理論上所有的應用都可以基於一個Spanner數據庫來運行，這種管理能力是非常驚人的，同時採用這種多區域組成Spanner數據庫的結構，多個區域網絡連接速度一定是有限，Spanner由會通過一些目錄調整的技術，來內聚相關數據，做到相關數據的位置聚集，解決了多區域數據庫存在的效率問題，因此從部署上看，spanner可以部署多個數據中心，不僅僅是邏輯數據中心，還是包括物理上不同數據中心，組成一個全球分佈式數據庫。
4.5.2 關鍵技術
4.5.2.1 TrueTime
TrueTime是Spanner中核心技術，掌握TrueTime也就掌握Spanner技術精髓，TrueTime從物理上GPS和原子鐘構成時間發生器，在每個數據中心部署了一組time Master，在每個節點都部署了timeslave daemo,大多數Master都配置爲GPS時鐘，部分Master配置爲原子時鐘，這些Master在物理上面相互隔離，邏輯上會彼此通訊，進行時間校對。Timeslavedaemo會從一組Master中獲取可信時間區間，這種機制會對於Master進行修訂，同時timeslave daemo可以獲取到一個可信時間區間，具體實現細節這裏不做詳細描述。
而Spanner是利用TrueTime提供API方法， TT.now()、TT.after()和TT.before()方法，TT.now()方法可以給出一個可信時間區間，類似於時間的最早和最晚時間構成的可信時間區間，保證時間必然在這一區域內，TT.after()和TT.before()方法是TT.now()方法的擴展。 表示一個事件e的絕對時間，可以利用函數tabs(e)。如果用更加形式化的術語，TrueTime可以保證，對於一個調用tt=TT.now()，有tt.earliest≤tabs(enow)≤tt.latest，其中，是enow是調用事件。
這個可信時間區間太重要了，這裏強調一下Truetime解決二個重要問題，第一，這個可信時間區間是Spanner全系統一直認同、並一致保證、可靠的時間區間值，第二，TrueTime機制使得這個區間值範圍達到毫秒級，時間區間範圍值越小越利於分佈式事務處理，事務處理成功可能性就會越大。這種時間置信區間後，分佈式數據庫節點之間最大問題事務一致性控制，如何控制，如果有絕對準確時間，可以通過判斷事務發生的時間順序來進行事務一致性控制，因爲從時間點角度看，任務一個事務發生時間點必然是唯一的，只是由於系統時間精度和準確時間獲取成本和技術上可行性，導致時間點無法準確區分和排序，TrueTime就退而求其次，給出一個可信時間區間，然後根據各事務提交可信時間區間對事務成功還是失敗進行控制，這種思路的確非常巧妙的解決這一難題。
4.5.2.2 只讀事務和快照讀事務無鎖管理
只讀事務時預先申明快照隔離的事務，這種事務提前申明不包含什麼寫操作，由Spanner系統爲這種事務分配一個時間戳，在這個時間戳後面寫事務都不會被阻塞，一個只讀事務可以去任何足夠新的副本上面去執行，實現無鎖管理。
快照讀事務是對歷史數據的讀取，由客戶端在提交事務處理時給出一個時間戳或者給出一個時間範圍，讓Spanner根據這個時間範圍選擇一個時間戳給該快照讀事務，這二種場景都可以保證快照讀在任何足夠新的副本上面執行，實現無鎖管理。
4.5.2.3 Paxos領導者的續約
事務始終是與Paxos分組相關，由Paxos中的領導者進行事務控制，對於領導者能夠對於事務時間進行控制，可以延長自己的時間，實現更長時間的領導者地位，當然這個時間有一個最大值，不能超出這個值的範圍裏面續約，續約有一套類似投票協商的機制，此處不做詳細介紹，另外爲了保證事務的隔離性，退出以時間區間中最晚時間點滿足條件爲止。
4.5.2.4 讀寫事務的鎖管理
Spanner採用讀和寫採用二階段鎖事務協議。當所有鎖都已經獲得以後，在任何鎖被釋放之前，就可以給事務分配時間戳。事務根據分配時間戳，通過Paxos分組控制機制，把讀或者寫的動作進行時間戳排序拆分，確保該事務能夠被正常的執行。
6 結語
GOOGLE從Bigtable數據庫開始，提供出來一個解決大型數據管理的新視角，Bigtable側重於數據分佈性、擴展性和處理能力提升，丟棄了關係型數據庫特性，是一種NOSQL的技術發展方向，不管是Bigtable在GOOGLE公司內部的成功應用，還是開源社區HBASE大紅大紫，都說明這種技術方向確實有應用場景。但是隨着Bigtable數據庫深入使用，我們發現其丟失的關係型數據庫特性，在有些場景下已經不能滿足需求，對於巨型數據進行分析時Bigtable的速度也不能滿足人們的要求。通過GOOGLE的不斷研究，在實時數據分析上，引入了一種新模型Dremel，該模型使用列式嵌套式的存儲結構和服務樹的方式，提高數據讀取的有效性，對於數據進行快速查詢分解，對於查詢結果進行快速彙集，滿足大型數據的實時處理要求。作爲Bigtable的後續演進上，GOOGLE推出Spanner來找回部分Bigtable丟失關係型數據庫的特性，同時Spanner在管理容量上，比Bigtable有了巨大的提升，如果說Bigtable是一個區域和局部分佈式數據庫集羣，那麼Spanner就是一個全球範圍的巨型數據庫系統，在管理上無理論上限。在Spanner後續技術發展上會進一步的提供更接近與關係數據庫的產品，對於數據庫的效率繼續提升，另外一個比較讓人動心的技術是數據按照負載情況進行感知，自動進行位置搬遷，提升處理效率，同時spanner也在提升不同數據中心數據複製的成本，優化數據一致性帶來的開銷，對於Bigtable、Dremel、Spanner的關係可以如下圖6-1所示。
圖6-1 Bigtable\Dremel\Spanner關係圖
GOOGLE對於分佈式數據庫技術發展方向的共享非常大，可以說引領了整個分佈式數據庫發展的方向，如果說蘋果公司重新定義了手機，那麼也可以說GOOGLE重新定義了分佈式數據庫，差別在於蘋果公司提供是手機這樣的產品，而GOOGLE提供的是一種可以技術上進行實踐的分佈式數據庫理念，期待不久的將來，GOOGLE能夠持續對於分佈式數據庫進行持續改進，能夠使得分佈式數據滿足必要關係型數據庫特性，提供更好的產品理念和技術文檔的同時，而且把代碼級把產品能夠公開出來，滿足大型數據的處理要求，推出對外商用的分佈式數據庫產品。
作者力圖從自身視角對於GOOGLE分佈式數據庫演進技術做爲分析，側重於作者自身的分析和判斷，部分結論可能不一定準確，如有描述不準確的地方，敬請諒解，提出寶貴的改進意見。