Espresso：來自LinkedIn的分布式NoSQL數據庫

原文  http://www.infoq.com/cn/news/2015/02/espresso-linkin-nosql

Espresso 是一個來自LinkedIn的分布式NoSQL數據庫，其具有高性能、高擴展性、支持事務、容錯能力等重要特征。在LinkedIn，Espresso有著強大的應用規模，它運行在十幾個集群中，并且已有將近30個應用在使用Espresso，如 Member Profile 、 InMail 、 LinkedIn的手機客戶端 等。在高峰期，它能夠每秒處理數百萬的訪問記錄。Espresso由LinkedIn的分布式數據系統團隊基于高性能的數據抓取系統 Databus 、 R2D2 、通用的集群管理框架 Apache Helix 等開源技術開發，用來解決關系型數據庫（如MySQL、Oracle等）不能滿足當前線上并發業務的性能要求的問題以及關系型數據庫固有的一些局限性，如擴展性差、容錯處理能力差、成本高等。

Espresso具有一個分層的數據模型，其結構為數據庫（Database）->表（Table）>集合 （Collection）->文檔（Document）。Espresso使用JSON數據格式定義數據庫Schema和表Schema，使用數據 序列化的系統 Apache Avro 定義文檔Schema。Espresso的表是同一類型文檔的容器，使用指定Key所確定的文檔就是一個集合，一個指定的Key唯一確定一個文檔，一個文 檔Schema對應一個Avro的Schema。Espresso提供了簡單、易用的讀/寫操作的REST風格API和基于Last-Modified 和 ETag的條件操作API，其中的寫操作API還具有事務性。

Espresso的整個架構如下圖所示：

• 路由器（Router）

  路由器是一個無狀態的HTTP代理，它是客戶端訪問Espresso的入口。路由器首先檢查請求的URL以確定需要訪問的數據庫（除了內部的Schema 注冊數據庫，該數據庫能夠映射到任何節點），并根據分區Key以確定請求對應的分區，并將請求轉發到對應的存儲節點。路由器還有一個本地的緩存路由表，該 路由表映射分區的分布情況。當集群的狀態發生變化時，路由表通過分布式應用程序協調服務應用 Apache ZooKeeper 實現路由器的更新，并以并行的方式實現跨分區的批量請求。

• 存儲節點（Storage Node）

  存儲節點是集群擴展和數據存儲的基本單元，每個存儲節點都包括一套分區。路由器能夠將發送請求轉發到存儲節點，存儲節點的功能包括查詢處理、作為存儲引擎、實現二級索引、處理節點狀態的轉換、支持本地事務、提交復制日志、定時備份以及一致性檢查和數據驗證等工具類功能。

• 集群管理框架Helix

  Espresso使用 Helix 進行集群管理。Espresso的狀態模型具有OFFLINE、SLAVE和MASTER狀態。Espresso的狀態模型約束包括每個分區必須至少有一 個Master節點和n個可配置的Slave節點、分區分布在所有的存儲節點上、在同一個基點上不存在同一分區的副本、當Master節點出現故障 時，Slave節點要能夠升級成為Master節點。

• 低延遲數據抓取系統Databus

  Espresso 使用Databus實現變化捕獲機制，Databus能夠處理Espresso事務日志，Databus的重要特征包括來源獨立、可擴展、高度可用、低延 遲、支持多種訂閱機制和無限回溯等。Espresso使用Databus目的包括：（1）將事件傳遞給下游消費者，如搜索的索引和緩存等；（2）實現 Espresso的多數據中心的復制。Databus的結構如下圖所示：

  

• 數據復制服務（Data Replicator）

  數據復制是一 個在跨地域復制的Espresso集群間轉發提交請求的服務，該服務由Helix管理的無狀態集群實例構成，并具有容錯處理能力和線上/線下的Helix 狀態模型。數據復制服務是Databus的一個Consumer，用來處理集群中的數據庫分區事件，它還能夠在數據中心之間批量處理事件以提升高延遲的鏈 接線路的吞吐量。該服務定期檢查ZooKeeper的復制進度以及節點故障、服務重啟等，每個節點負責一定數量分區的復制，具體負責哪些分區由Helix 指定。一旦節點發生故障，屬于故障節點負責的分區會被重新分配給正常的節點。當一個節點開始處理新指派的分區時，它會從保存在Zookeeper中的最近 檢查點重新執行相關處理/操作。

• 快照服務（Snapshot Service）

  快照服務能夠自 動、定期地備份數據中心的所有Espresso節點的數據，且對正在運行的集群影響非常小。快照服務本身也是一個分布式系統，并與數據復制服務一樣具有相 同的線上/下狀態模型。最近備份的元數據信息也將寫入到ZooKeeper，叫做“znode”的節點是存儲元數據的地方。

Espresso的關鍵特征和實現細節內容如下：

• 序列號-- Espresso時鐘

  Espresso使用一個內置的時鐘以確定事件的全序關系，時序對集群間的復制和Databus都是非常重要的。每個成功的操作（如插入、更新、刪除）都分配了一個64位的系統改變碼（SCN），SCN由MySQL在事務提交時生成，其是單調遞增且由每個分區獨立維護。

• Schema的管理

  Espresso的Schema存儲在ZooKeeper中，該組件在所有服務中可共享。

• Schema的演變

  Espresso的文檔Schema根據Avro的Schema演化規則的改變而改變，且還有一些的規范限制。

• 容錯處理

  Espresso的集群管理使用Helix來實現，存 儲節點是真是數據的來源，所以容錯功能是至關重要的。在Espresso中，每個節點既有Slave分區，也有Master分區。容錯處理的情況包括 （1）當一個存儲節點連接到Helix時，該節點會在Zookeeper中創建一個臨時節點，該節點由Helix監視；（2）當一個節點出現故障時，如管 理了Socket連接或者沒有響應心跳檢測，Zookeeper移除該臨時節點；（3）在刪除一個節點出現故障時，Helix會更新外部試圖來排除出現故 障的節點；（4）一旦生成“ideal state”，Helix就會根據定義好的狀態模型進行狀態轉換 。在Espresso中，每個受到影響的分區的Slave節點將會收到SLAVE->MASTER的轉換信息。

• 備份恢復服務（Backup Restore ）

  Espresso的存儲節點能夠定期備份所有分區，壓縮后的存儲節點數據流備份鏡像會存儲到一個分布式文件系統里，在每個分區生成的備份能夠在擴展時跨遷移。備份數據能夠用來恢復故障節點、啟動新的集群、擴展已存在的集群等。

• 其它 Espresso 還有其他一些有趣的特性，如 集群擴展、每個數據庫的定額管理、批量加載HDFS中的數據、自動實化集群、組提交、沖突解決等。

更多關于Espresso的相關信息，請讀者閱讀2013年ACM SIGMOD數據管理國際會議上 關于Espresso的論文 和Swaroop Jagadish 關于Espresso的演示稿 。