Manhattan，Twitter規模的實時、多租戶分布式數據庫

【編者按】構建一個完全面向服務的系統一直是Twitter追求的目標，而從 之前的文章中，我們分享過Twitter從容應對14.3萬TPS峰值的整個系統概覽，不過各個服務組件的細節卻并未涉及。有幸的是，該公司近日披露了其自主研發的數據庫系統Manhattan，在提供高可靠、高可用等特性的同時，Twitter仍然灌輸了其面向服務的特性。

以下為譯文：

隨著Twitter成長為全球化的用戶交流、表達平臺，它的存儲需求也在一直增大。在過去的幾年中，我們發現我們急需一個可以進行每秒數百萬次查詢，在實時環境中延遲低的存儲系統?？捎眯院退俣瘸蔀橹陵P重要的因素。理想的系統不僅需要速度快，還需要可擴展到全球多個地區。

在過去的幾年中，我們為許多開源數據庫做出了重要的貢獻。但是我們，Twitter的實時特性導致當下任何開源系統都無法滿足其低延遲的需求。我們花費了大量時間來滿足不同產品的需求，提供新的存儲容量，耗費人力、流程以滿足使用需求。但是依照我們在Twitter規模下的開發運行生產存儲經驗，這種狀態是不可持續的。所有我們試圖構建下一代Twitter分布式系統――我們稱之為Manhattan 。Manhattan 不但需要滿足現有需求，還需要迎合未來潛在的需求。

Twitter存儲系統全覽

如今眾多數據庫有著眾多特性，不過根據我們的經驗我們可以明確幾個需求，這些需求符合我們的未來預期，足以應對我們將面對的大部分情況并解決實時使用中可能遇到的問題――如正確性、可操作性、可見性、性能和客戶支持等。我們的要求如下：

1. 可靠性：Twitter服務需要一個耐用的數據存儲，這個數據存儲的性能必須是可估的。我們要求在各種失敗、減速、擴張、熱點或者在其他我們遇到情況下，這個數據存儲都是可信任的。

2. 可用性：我們大多數用例都推崇可用一致性，因此我們需要一個不間斷的最終實現一致性的數據庫。

3. 可擴展性：我們要求應用可以應對今后的變化需求，因此我們需要一個可靠的、模塊化的基礎，并在這個基礎上構建從新存儲引擎到強一致性的所有部件。此外，無結構鍵值數據模型最適合客戶的需求，這個模型還給了客戶今后添加結構空間。

4. 可操作性：隨著集群從幾百個節點變成幾千個節點，即使是最簡單的操作也會是對操作者耗時、痛苦的折磨。為了有效的使用人力資源，我們從一開始就優化操作。針對每個新特征，我們都要考慮操作便捷性，并對問題進行診斷。

5. 低延遲：作為實時服務，Twitter的產品需要一致的低延遲，所以我們需要作出一些權衡。

6. 生產環境的可擴展性：在分布式系統中，擴展性挑戰無處不在。Twitter需要一個可擴展的數據庫，而且這個數據庫的每個指標今后都可以繼續發展到新的高度――集群大小，每秒查詢次數，數據大小，地理特性以及租戶數量――在不犧牲成本效率、易于操作的前提下。

7. 開發人員生產率：公司的開發者應當可以存儲任何用來構建服務的內容，存儲過程基于自助服務平臺，不需要來自存儲工程師的干涉，存儲基于一個“能工作”的系統。

8. 開發者應當可以將任何所需內容存儲到一個可用的系統。

Twitter規模下的可靠性

當我們開始構建Manhattan 時，我們已經有許多Twitter的大存儲集群，因此我們充分了解規模運行系統所帶來的挑戰，這些經驗告訴我們新系統中該爭取和避免哪些特性。

一個可靠的系統是一款在任何操作下都可信任的、運行良好的系統，這種可估性能是非常難實現的。可估系統的關鍵是對最糟狀態的判斷；而平均表現情況就沒有那么重要了。在一個正確配置、良好實現的系統中，平均表現很少導致問題。當我們看公司指標時我們會看如p999和p9999延遲之類的指標，我們關心最慢的0.01%的請求到底有多慢。我們需要為最差的情況做好打算。例如，如果有一個周期性的批量工作每天都會有一個小時降低性能，那么可接受的穩定表現也就無從談起了。

因為可估的優先級，我們需要在任何潛在問題、失敗模式下都保持良好的表現?？蛻魧ξ覀兊膶嵤┘毠澓透鞣N借口并不感興趣；我們的服務對他們、對Twitter要么是可用的，要么是不可用的。即使有些時候我們需要做出一些權衡以應對一些不太可能發生的狀況，我們也需要這么做，我們必須要銘記――有些時候，罕見的事情也會發生。

如今規模不僅來自機器數量、請求數量、大規模數據，還來自人員規模――使用、支持系統的人數的增長。我們通過關注以下幾個問題進行管理：

• 如果某個用戶制造了問題，那么這個問題應該僅存在于這個用戶，不會擴散。
  
• 我們和用戶都應當可以很容易的分辨出問題是源于存儲系統還是用戶。
  
• 對于潛在的問題，一旦發現、診斷，我們就要最小化恢復系統所需的時間。
  
• 我們必須了解各種失敗模式將如何呈現給用戶。
  
• 完成常規的操作、診斷修復大部分問題，都不應該要求一個操作員有深入、全面的操作系統知識。
  

最終，我們依據規模操作的經驗構建了Manhattan ，復雜性是我們最大的敵人。最終，簡單、可行戰勝了浮華。我們提倡簡單，可靠工作的，具有良好的一致性，提供良好的能見性的系統；我們不提倡理論上完美，實際工作時不能正常運行或者可見度低、可操作性差、與其它核心需求不兼容的系統。

構建一個存儲系統

在構建新一代存儲系統時，我們決定對系統分層，以得到模塊化、穩定的底層作為構建基礎，之后在此之上更新功能將不需要做大調整。

以下是設計目標：

• 保持核心精益和簡單
  
• 越早實現價值越高（專注于增量）
  
• 第一要義：多租戶，QoS，自助服務
  
• 關注可估性
  
• 存儲不只是一項技術，更是一個服務
  

層

我們將Manhattan 分為四層：接口，存儲服務，存儲引擎和內核

內核

內核是存儲系統的關鍵部分：內核具有高穩定性、魯棒性。內核負責處理失敗，最終一致性，路由，拓撲管理，數據中心內復制，數據中心間復制和解決沖突。通過系統內核，關鍵部分結構實現完全可插拔，因此我們可以進行設計和改進的快速迭代，進行有效的單元測試。

操作者可以在任何時間改變拓撲以添加或刪除容量，我們的可見性和強大拓撲管理是至關重要的。我們將拓撲結構信息存儲到Zookeeper，盡管Zoopkeeper不是讀寫的關鍵路徑，但是它有強大的協調能力，也是Twitter基礎建設中的一個管理組件。我們也付出了大量的努力確保對內核最佳可見性，我們通過一組Ostrich指標來了解所有主機的正確性和表現。

一致性模型

很多Twitter應用都很好的兼容于最終一致模型。我們推崇覆蓋幾乎所有用例的一致性，因此我們要在內核中把Manhattan 建設為一個最終一致模型。然而，總會有應用程序需要強烈的自身數據一致性，建立這樣一個系統高優先級是吸引更多的顧客。強一致性是可選的模型，開發者要做好權衡。在強一致性系統中，使用者將對于一部分分區擁有主控權。Twitter上的很多用例是不能忍受幾秒鐘的延遲的（因為失敗后會被淘汰）。我們為開發人員提供良好的默認設置，并幫助他們理解兩個模型之間的權衡。

實現一致性

為了在最終一致系統中實現一致性，開發者需要一個稱之為副本和解的機制。這是一個增量機制，它一直運行可以和解副本數據的進程。它解決位衰減、系統bug、寫丟失（節點宕機很長一段時間）和數據處理中心間的網絡分區帶來的問題。除了副本和解外，我們還可以使用；另外兩個機制進行優化，以實現更快的收斂性：讀修復（read-repair），這個機制基于讀數據的速率，使得常被訪問的數據更快收斂；暗示移交（hinted-handoff），基于節點不穩定或離線一段時間，是二次傳遞機制。

存儲引擎

存儲系統的最底層是數據如何存儲在硬盤上，數據結構如何存儲在內存中的。為了降低管理多個存儲引擎的多個數據處理中心所帶來的復雜性和風險，我們決定將最初的存儲引擎設計在內部，如果有額外需求可以靈活的插入外部存儲引擎。這使得我們關注最必要的部分，審核改動是否應當進行。我們現在有三個存儲引擎：

• seadb是只讀文件格式，讀來自Hadoop的批量處理數據。
  
• sstable是基于重寫工作負載格式的日志結構合并樹。
  
• btree，基于重讀，輕量級寫負載的格式。
  
• 所有存儲引擎都支持基于塊的壓縮。

存儲服務

我們在Manhattan 內核頂層創建了額外的服務，這些服務使得Manhattan 擁有更強的魯棒性，這種特性也是開發者一直以來期待的。一些例子如下：

Hadoop批導入：Manhattan 的最初用例位于Hadoop生成的數據之上，作為其高效服務層。我們設計了一個進口管道，這個管道允許客戶在HDFS的數據集生成為簡單的格式，并通過自助服務接口指定文件位置。我們的觀測者自動選擇了一個新數據集，在HDFS中將其轉為seadb文件，這樣他們就可以將這些將數據導入集群中以獲取來自SSD卡或內存的快速服務。我們致力于將這個管道流線化，使其簡單、便捷，幫助開發者快速進行進化數據集的迭代。我們從用戶了解到的一點是他們希望生成大的，大概幾千兆的數據集，通常后續版本的數據變化小于10%～20%。為了減少網絡帶寬，我們采取優化措施――產生我們在下載數據到副本時可使用的二進制差別，進而大幅度減小數據中心的導入時間。

強一致性服務：強一致性服務保障用戶在進行系列操作時擁有強一致性。我們使用一個一致算法搭配了一個復制日志來保證順序事件順利到達所有副本。這使得我們可以進行諸如檢查設置（CAS）、強讀、強寫的操作。現在我們支持兩種模式：LOCAL_CAS和GLOBAL_CAS。Globall CAS使得開發者在法定數據控制中心間獲得強一致性，Local CAS使開發者在指定數據控制中心內獲得強一致性?？紤]到應用的延遲性和數據模型，兩種操作各有利弊。

時間序列計數器服務：我們開發了一個特定的服務來處理Manhattan 中的大量時間序列計數器。推動這項需求的“客戶”是我們的可觀察的基礎設施，它需要一個每秒可以處理成千上萬個增量的系統。在這種規模下，我們的工程師通過種種實踐，權衡諸如耐久性、增量對報警系統可見前的延遲、用戶可以接受的次秒級交通模式等方面，最終得出解決方案。最終方案是在一個優化的Manhattan 集群上添加一個輕量的、高效的計算層，這大大滿足了我們的要求、提高系統可靠性。

接口

接口層描述了用戶如何與我們的存儲系統交互?，F在我們已經向用戶開放一個鍵/值接口，我們也正在實現其它接口――如進行邊緣交互的圖接口。

工具

為了滿足集群簡易性的需求，我們需要花大功夫研究如何設計最好的日常操作的工具。我們希望系統處理盡可能復雜的操作，并希望通過高層語義的命令對操作者屏蔽這些復雜的實施細節。我們先實現的工具包括可以僅通過編輯宿主組織和權重文件就可以實現修改整個系統的拓撲結構的工具，可以通過單個命令行就可以重啟所有節點的工具。當早期的工具變得太復雜時，我們建立一個自動化的代理，這個代理接受簡單的命令作為集群的狀態的目標，并且可以堆棧、結合，在沒有操作者的關注下安全執行指令。

存儲服務

我們對現有數據庫的一個通常認識是這些數據庫為了特定的用例所設置、構建、管理。隨著Twitter內部服務的成長，我們認識到先前的認識無法滿足商業需求。我們的解決方案是存儲是一項服務。通過構建一個工程師完全可控的自服務存儲系統，我們大大提高了工程團隊和運營團隊生產力。工程師可以提供他們的應用程序所需要的（存儲大小、每秒查詢等）和開始在幾秒鐘內準備存儲，無需安裝硬件或模式的設置。公司內部客戶運行在多租戶環境下，運營團隊管理這個環境。集群管理自助服務和多租戶帶來了一定的挑戰，所以我們把這個服務層作為一個頭等特征：我們為客戶提供客戶數據和工作量的能見度；我們有內置的配額執行和限速，當工程師越過閾值時它們會提醒工程師；我們的信息由我們的容量和敏捷管理團隊進行管理分析和匯報。通過方便工程師運行新功能，我們看到了新用例實驗和增值的增長。為了更好的處理這些，我們開發了內部API來公布這些成本分析數據，這些分析幫助我們可以確定哪些用例需要花費的多，哪些不經常使用。

關注客戶

盡管我們的客戶都是Twitter的雇員，我們始終要提供優質服務，因為他們是我們的客戶。我們需要做到隨叫隨到，進行應用程序間行為的隔離，在一切工作中都考慮用戶體驗。大部分開發人員都了解需要閱讀服務的詳細文檔，但是對存儲系統的功能增加或調整需要慎重考慮，而將特性無縫的集成到自服務中更需要處理多種不同的需求。當一個用戶有問題時，我們需要設計服務，這樣我們可以快速準確的定位根本原因，這包括當工程師訪問數據庫時來自不同客戶和應用程序的問題和突發問題。我們已經很成功的將Manhattan 構建為一種服務，而不是只一項技術。

多租戶和QoS

支持多租戶――允許多個不同應用程序共享同一資源――這從一開始就是一個關鍵需求。Twitter先前使用的系統中，我們為每個特征構建外部集群。這增加了操作負擔，浪費資源，并且阻礙了客戶推出新功能的速度。如上文所說，允許多個用戶使用同一組群將增強運行系統的競爭力。我們現在必須要考慮隔離性，資源管理，多個用戶能力模型，速率限制，QoS以及配額等等。為了給客戶提供所需的可視性，我們設計了自己的速率限制服務來增強用戶對資源和配額的使用。如果需要，我們可以通過觀測指標是否越過閾值來確保應用程序沒有影響系統中的其它程序。

速率限制不是在粗粒度下進行，它被實現到亞秒級，并容忍現實世界中峰值。我們不僅要考慮自動執行，還要關注應該給操作者提供哪些手動控制操作符來解決問題，關注如何減輕對所有用戶的負面影響。我們構建為每個客戶提取數據、將數據發送給容量團隊的API，容量團隊要確保當客戶有任何大小需求時（Twitter標準的），我們的資源都是可用的，這樣那些工程師可以在不需要我們的額外的幫助的情況下開始工作。將這些所有內容都直接整合到子服務系統使得客戶可以在大多租戶集群中更快的啟用新特性，并允許我們更容易的吸收峰值流量，因為大多數客戶不使用他們所有的資源。

著眼未來

我們要做的還有很多。挑戰在不斷的增加，Manhattan 內置的特性也在迅速增加。促使自己做的更好、更聰明是我們內核存儲團隊的動力。我們以我們的價值為豪：我們所做的一切會讓Twitter變得更好，那么我們如何才能讓我們的客戶更成功？我們打算發布一個涉及Manhattan 更多技術細節和運行Manhattan 兩年經驗的白文件，敬請期待！

原文連接： Manhattan, our real-time, multi-tenant distributed database for Twitter scale（翻譯/蔡仁君 責編/仲浩）

以“  云計算大數據 推動智慧中國 ”為主題的  第六屆中國云計算大會 將于5月20-23日在北京國家會議中心隆重舉辦。產業觀察、技術培訓、主題論壇、行業研討，內容豐富，干貨十足。票價優惠，馬上  報名 ！ 

生活不易，碼農辛苦
如果您覺得本網站對您的學習有所幫助,可以手機掃描二維碼進行捐贈