Google Mesa論文筆記
原文 http://www.bitstech.net/2015/05/26/google-mesa/
Mesa是Google用于廣告的數據倉庫系統， 擁有準實時的數據更新能力， 和低延遲的數據查詢性能。 系統高可用性、可靠性、擴展性都非常優秀， 數據規模可達PB級別， 支持每秒數百萬行寫入。 每天數十億查詢請求 。
Mesa的設計目標：
Mesa的數據模型是數據立方體， 表包含多個維度屬性（keys）， 和多個度量屬性（values）。 表上可定義物化視圖， 譬如表C是定義在表B上的物化視圖， 其定義查詢為SELECT SUM(Clicks), SUM(Cost) GROUP BY AdvertiserId, Country。 物化視圖可以提高查詢效率， 當然也放大了數據更新量， 因為系統必須維護父表和物化視圖的數據一致性 。
多版本機制
更新采用批量方式。 一段時間內（通常是幾分鐘）的更新操作累積在一起， 批量更新入庫。 與關系數據庫MVCC機制類似， 一批更新操作產生一個新版本(版本號從0開始連續編號)， 查詢都是針對一個特定版本的數據快照， 所以更新操作不會影響到查詢一致性。
物理存儲和索引結構
Mesa底層是一個KV存儲結構， 所有維度屬性作為key， 度量屬性作為Value。 如下圖所示， Mesa使用與Leveldb類似的兩層delta結構存儲KV。 singleton代表一次update操作產生的delta， cumulatives代表多個版本的累計delta， base是所有歷史更新積累而成的基礎數據。多個singleton定期合并形成cumulatives， cumulatives定期合并到base。 通過這種方式， mesa支持到分鐘級（5分鐘）的數據更新延遲，且保證了查詢性能。
Mesa表和索引采用相同的存儲方式， 各自有各自的兩層delta結構。 base/cumulative/singleton按照索引key順序組織成多個數據文件， 存儲于Colossus。 每個索引都會存儲完整的記錄， 所以查詢時不存在回表操作。數據文件分為多個大小相近的row blocks， row block內部按照列存來組織并壓縮， 以獲得較高的壓縮比。 提取row block首key的固定長度前綴構成數據文件摘要索引。查找記錄時先從摘要索引定位row block， 解壓縮row block相關列，進一步在row block中定位記錄。
查詢
Mesa查詢通過查詢服務器來實現， 沒有實現類似Google兄弟產品powerdrill或者dremel類似的多層樹狀查詢執行模型， 如果查詢涉及的數據量較大時，性能會有瓶頸。 Mesa提供的查詢能力也比較有限， 只是一些簡單的條件過濾和group by， 高層數據庫引擎比如MySQL，F1，Dremel可基于mesa的查詢能力提供更強大的SQL能力，比如join query。 Mesa通過查詢的標簽區分在線查詢和離線批量查詢， 避免這兩者相互干擾，能同時滿足兩種類型查詢需求。
Mesa實現了一些基本的查詢優化措施： 1） delta pruning。 根據delta的key范圍跳過一些不命中的delta。理論上mesa也可以利用row block的統計調過一些不滿足的block， 但是文章沒有提到這種優化措施。 2） scan-to-seek優化， (A,B)兩列索引，如果查詢只指定了B上條件， 也盡量利用索引調過不必要的數據訪問。（ 這種優化常見于MySQL等關系數據庫）。
除了基本查詢之外， 針對一些離線分析業務， Mesa也支持Map Reduce框架。
總體看來Mesa支持的SQL能力比較有限， 查詢的效率比較依賴于索引或者物化視圖定義。
異地復制
全局唯一的無狀態committer賦予更新唯一版本號， 并提交到異地高可用（paxo協議實現）的Global update storage中。 各數據中心的mesa實例從Global Update storage拉取更新，應用到本地， 等到所有數據中心都應用 成功時候， committer才增加commit version， 此時更新才對查詢可見。 committer本身是無狀態的， 所以自身高可用不成問題。
總結
Mesa是能同時滿足準實時數據更新， 低延遲查詢， 且可用性、擴展性都表現不錯的數據庫倉庫系統。 Google內部類似的系統有PowerDrill，Dremel， 雖然有些不同的地方， 但是應用場景上也略有重疊， 很好奇Google內部是如何定位這些系統的。
文獻
Mesa: GeoReplicated, Near RealTime, Scalable Data Warehousing