Manhattan，Twitter規(guī)模的實(shí)時(shí)、多租戶分布式數(shù)據(jù)庫

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

以下為譯文：

隨著Twitter成長為全球化的用戶交流、表達(dá)平臺，它的存儲需求也在一直增大。在過去的幾年中，我們發(fā)現(xiàn)我們急需一個(gè)可以進(jìn)行每秒數(shù)百萬次查詢，在實(shí)時(shí)環(huán)境中延遲低的存儲系統(tǒng)。可用性和速度成為至關(guān)重要的因素。理想的系統(tǒng)不僅需要速度快，還需要可擴(kuò)展到全球多個(gè)地區(qū)。

在過去的幾年中，我們?yōu)樵S多開源數(shù)據(jù)庫做出了重要的貢獻(xiàn)。但是我們，Twitter的實(shí)時(shí)特性導(dǎo)致當(dāng)下任何開源系統(tǒng)都無法滿足其低延遲的需求。我們花費(fèi)了大量時(shí)間來滿足不同產(chǎn)品的需求，提供新的存儲容量，耗費(fèi)人力、流程以滿足使用需求。但是依照我們在Twitter規(guī)模下的開發(fā)運(yùn)行生產(chǎn)存儲經(jīng)驗(yàn)，這種狀態(tài)是不可持續(xù)的。所有我們試圖構(gòu)建下一代Twitter分布式系統(tǒng)――我們稱之為Manhattan 。Manhattan 不但需要滿足現(xiàn)有需求，還需要迎合未來潛在的需求。

Twitter存儲系統(tǒng)全覽

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

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

2. 可用性：我們大多數(shù)用例都推崇可用一致性，因此我們需要一個(gè)不間斷的最終實(shí)現(xiàn)一致性的數(shù)據(jù)庫。

3. 可擴(kuò)展性：我們要求應(yīng)用可以應(yīng)對今后的變化需求，因此我們需要一個(gè)可靠的、模塊化的基礎(chǔ)，并在這個(gè)基礎(chǔ)上構(gòu)建從新存儲引擎到強(qiáng)一致性的所有部件。此外，無結(jié)構(gòu)鍵值數(shù)據(jù)模型最適合客戶的需求，這個(gè)模型還給了客戶今后添加結(jié)構(gòu)空間。

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

5. 低延遲：作為實(shí)時(shí)服務(wù)，Twitter的產(chǎn)品需要一致的低延遲，所以我們需要作出一些權(quán)衡。

6. 生產(chǎn)環(huán)境的可擴(kuò)展性：在分布式系統(tǒng)中，擴(kuò)展性挑戰(zhàn)無處不在。Twitter需要一個(gè)可擴(kuò)展的數(shù)據(jù)庫，而且這個(gè)數(shù)據(jù)庫的每個(gè)指標(biāo)今后都可以繼續(xù)發(fā)展到新的高度――集群大小，每秒查詢次數(shù)，數(shù)據(jù)大小，地理特性以及租戶數(shù)量――在不犧牲成本效率、易于操作的前提下。

7. 開發(fā)人員生產(chǎn)率：公司的開發(fā)者應(yīng)當(dāng)可以存儲任何用來構(gòu)建服務(wù)的內(nèi)容，存儲過程基于自助服務(wù)平臺，不需要來自存儲工程師的干涉，存儲基于一個(gè)“能工作”的系統(tǒng)。

8. 開發(fā)者應(yīng)當(dāng)可以將任何所需內(nèi)容存儲到一個(gè)可用的系統(tǒng)。

Twitter規(guī)模下的可靠性

當(dāng)我們開始構(gòu)建Manhattan 時(shí)，我們已經(jīng)有許多Twitter的大存儲集群，因此我們充分了解規(guī)模運(yùn)行系統(tǒng)所帶來的挑戰(zhàn)，這些經(jīng)驗(yàn)告訴我們新系統(tǒng)中該爭取和避免哪些特性。

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

因?yàn)榭晒赖膬?yōu)先級，我們需要在任何潛在問題、失敗模式下都保持良好的表現(xiàn)。客戶對我們的實(shí)施細(xì)節(jié)和各種借口并不感興趣；我們的服務(wù)對他們、對Twitter要么是可用的，要么是不可用的。即使有些時(shí)候我們需要做出一些權(quán)衡以應(yīng)對一些不太可能發(fā)生的狀況，我們也需要這么做，我們必須要銘記――有些時(shí)候，罕見的事情也會(huì)發(fā)生。

如今規(guī)模不僅來自機(jī)器數(shù)量、請求數(shù)量、大規(guī)模數(shù)據(jù)，還來自人員規(guī)模――使用、支持系統(tǒng)的人數(shù)的增長。我們通過關(guān)注以下幾個(gè)問題進(jìn)行管理：

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

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

構(gòu)建一個(gè)存儲系統(tǒng)

在構(gòu)建新一代存儲系統(tǒng)時(shí)，我們決定對系統(tǒng)分層，以得到模塊化、穩(wěn)定的底層作為構(gòu)建基礎(chǔ)，之后在此之上更新功能將不需要做大調(diào)整。

以下是設(shè)計(jì)目標(biāo)：

• 保持核心精益和簡單
  
• 越早實(shí)現(xiàn)價(jià)值越高（專注于增量）
  
• 第一要義：多租戶，QoS，自助服務(wù)
  
• 關(guān)注可估性
  
• 存儲不只是一項(xiàng)技術(shù)，更是一個(gè)服務(wù)
  

層

我們將Manhattan 分為四層：接口，存儲服務(wù)，存儲引擎和內(nèi)核

內(nèi)核

內(nèi)核是存儲系統(tǒng)的關(guān)鍵部分：內(nèi)核具有高穩(wěn)定性、魯棒性。內(nèi)核負(fù)責(zé)處理失敗，最終一致性，路由，拓?fù)涔芾恚瑪?shù)據(jù)中心內(nèi)復(fù)制，數(shù)據(jù)中心間復(fù)制和解決沖突。通過系統(tǒng)內(nèi)核，關(guān)鍵部分結(jié)構(gòu)實(shí)現(xiàn)完全可插拔，因此我們可以進(jìn)行設(shè)計(jì)和改進(jìn)的快速迭代，進(jìn)行有效的單元測試。

操作者可以在任何時(shí)間改變拓?fù)湟蕴砑踊騽h除容量，我們的可見性和強(qiáng)大拓?fù)涔芾硎侵陵P(guān)重要的。我們將拓?fù)浣Y(jié)構(gòu)信息存儲到Zookeeper，盡管Zoopkeeper不是讀寫的關(guān)鍵路徑，但是它有強(qiáng)大的協(xié)調(diào)能力，也是Twitter基礎(chǔ)建設(shè)中的一個(gè)管理組件。我們也付出了大量的努力確保對內(nèi)核最佳可見性，我們通過一組Ostrich指標(biāo)來了解所有主機(jī)的正確性和表現(xiàn)。

一致性模型

很多Twitter應(yīng)用都很好的兼容于最終一致模型。我們推崇覆蓋幾乎所有用例的一致性，因此我們要在內(nèi)核中把Manhattan 建設(shè)為一個(gè)最終一致模型。然而，總會(huì)有應(yīng)用程序需要強(qiáng)烈的自身數(shù)據(jù)一致性，建立這樣一個(gè)系統(tǒng)高優(yōu)先級是吸引更多的顧客。強(qiáng)一致性是可選的模型，開發(fā)者要做好權(quán)衡。在強(qiáng)一致性系統(tǒng)中，使用者將對于一部分分區(qū)擁有主控權(quán)。Twitter上的很多用例是不能忍受幾秒鐘的延遲的（因?yàn)槭『髸?huì)被淘汰）。我們?yōu)殚_發(fā)人員提供良好的默認(rèn)設(shè)置，并幫助他們理解兩個(gè)模型之間的權(quán)衡。

實(shí)現(xiàn)一致性

為了在最終一致系統(tǒng)中實(shí)現(xiàn)一致性，開發(fā)者需要一個(gè)稱之為副本和解的機(jī)制。這是一個(gè)增量機(jī)制，它一直運(yùn)行可以和解副本數(shù)據(jù)的進(jìn)程。它解決位衰減、系統(tǒng)bug、寫丟失（節(jié)點(diǎn)宕機(jī)很長一段時(shí)間）和數(shù)據(jù)處理中心間的網(wǎng)絡(luò)分區(qū)帶來的問題。除了副本和解外，我們還可以使用；另外兩個(gè)機(jī)制進(jìn)行優(yōu)化，以實(shí)現(xiàn)更快的收斂性：讀修復(fù)（read-repair），這個(gè)機(jī)制基于讀數(shù)據(jù)的速率，使得常被訪問的數(shù)據(jù)更快收斂；暗示移交（hinted-handoff），基于節(jié)點(diǎn)不穩(wěn)定或離線一段時(shí)間，是二次傳遞機(jī)制。

存儲引擎

存儲系統(tǒng)的最底層是數(shù)據(jù)如何存儲在硬盤上，數(shù)據(jù)結(jié)構(gòu)如何存儲在內(nèi)存中的。為了降低管理多個(gè)存儲引擎的多個(gè)數(shù)據(jù)處理中心所帶來的復(fù)雜性和風(fēng)險(xiǎn)，我們決定將最初的存儲引擎設(shè)計(jì)在內(nèi)部，如果有額外需求可以靈活的插入外部存儲引擎。這使得我們關(guān)注最必要的部分，審核改動(dòng)是否應(yīng)當(dāng)進(jìn)行。我們現(xiàn)在有三個(gè)存儲引擎：

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

存儲服務(wù)

我們在Manhattan 內(nèi)核頂層創(chuàng)建了額外的服務(wù)，這些服務(wù)使得Manhattan 擁有更強(qiáng)的魯棒性，這種特性也是開發(fā)者一直以來期待的。一些例子如下：

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

強(qiáng)一致性服務(wù)：強(qiáng)一致性服務(wù)保障用戶在進(jìn)行系列操作時(shí)擁有強(qiáng)一致性。我們使用一個(gè)一致算法搭配了一個(gè)復(fù)制日志來保證順序事件順利到達(dá)所有副本。這使得我們可以進(jìn)行諸如檢查設(shè)置（CAS）、強(qiáng)讀、強(qiáng)寫的操作。現(xiàn)在我們支持兩種模式：LOCAL_CAS和GLOBAL_CAS。Globall CAS使得開發(fā)者在法定數(shù)據(jù)控制中心間獲得強(qiáng)一致性，Local CAS使開發(fā)者在指定數(shù)據(jù)控制中心內(nèi)獲得強(qiáng)一致性。考慮到應(yīng)用的延遲性和數(shù)據(jù)模型，兩種操作各有利弊。

時(shí)間序列計(jì)數(shù)器服務(wù)：我們開發(fā)了一個(gè)特定的服務(wù)來處理Manhattan 中的大量時(shí)間序列計(jì)數(shù)器。推動(dòng)這項(xiàng)需求的“客戶”是我們的可觀察的基礎(chǔ)設(shè)施，它需要一個(gè)每秒可以處理成千上萬個(gè)增量的系統(tǒng)。在這種規(guī)模下，我們的工程師通過種種實(shí)踐，權(quán)衡諸如耐久性、增量對報(bào)警系統(tǒng)可見前的延遲、用戶可以接受的次秒級交通模式等方面，最終得出解決方案。最終方案是在一個(gè)優(yōu)化的Manhattan 集群上添加一個(gè)輕量的、高效的計(jì)算層，這大大滿足了我們的要求、提高系統(tǒng)可靠性。

接口

接口層描述了用戶如何與我們的存儲系統(tǒng)交互。現(xiàn)在我們已經(jīng)向用戶開放一個(gè)鍵/值接口，我們也正在實(shí)現(xiàn)其它接口――如進(jìn)行邊緣交互的圖接口。

工具

為了滿足集群簡易性的需求，我們需要花大功夫研究如何設(shè)計(jì)最好的日常操作的工具。我們希望系統(tǒng)處理盡可能復(fù)雜的操作，并希望通過高層語義的命令對操作者屏蔽這些復(fù)雜的實(shí)施細(xì)節(jié)。我們先實(shí)現(xiàn)的工具包括可以僅通過編輯宿主組織和權(quán)重文件就可以實(shí)現(xiàn)修改整個(gè)系統(tǒng)的拓?fù)浣Y(jié)構(gòu)的工具，可以通過單個(gè)命令行就可以重啟所有節(jié)點(diǎn)的工具。當(dāng)早期的工具變得太復(fù)雜時(shí)，我們建立一個(gè)自動(dòng)化的代理，這個(gè)代理接受簡單的命令作為集群的狀態(tài)的目標(biāo)，并且可以堆棧、結(jié)合，在沒有操作者的關(guān)注下安全執(zhí)行指令。

存儲服務(wù)

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

關(guān)注客戶

盡管我們的客戶都是Twitter的雇員，我們始終要提供優(yōu)質(zhì)服務(wù)，因?yàn)樗麄兪俏覀兊目蛻簟Ｎ覀冃枰龅诫S叫隨到，進(jìn)行應(yīng)用程序間行為的隔離，在一切工作中都考慮用戶體驗(yàn)。大部分開發(fā)人員都了解需要閱讀服務(wù)的詳細(xì)文檔，但是對存儲系統(tǒng)的功能增加或調(diào)整需要慎重考慮，而將特性無縫的集成到自服務(wù)中更需要處理多種不同的需求。當(dāng)一個(gè)用戶有問題時(shí)，我們需要設(shè)計(jì)服務(wù)，這樣我們可以快速準(zhǔn)確的定位根本原因，這包括當(dāng)工程師訪問數(shù)據(jù)庫時(shí)來自不同客戶和應(yīng)用程序的問題和突發(fā)問題。我們已經(jīng)很成功的將Manhattan 構(gòu)建為一種服務(wù)，而不是只一項(xiàng)技術(shù)。

多租戶和QoS

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

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

著眼未來

我們要做的還有很多。挑戰(zhàn)在不斷的增加，Manhattan 內(nèi)置的特性也在迅速增加。促使自己做的更好、更聰明是我們內(nèi)核存儲團(tuán)隊(duì)的動(dòng)力。我們以我們的價(jià)值為豪：我們所做的一切會(huì)讓Twitter變得更好，那么我們?nèi)绾尾拍茏屛覀兊目蛻舾晒Γ课覀兇蛩惆l(fā)布一個(gè)涉及Manhattan 更多技術(shù)細(xì)節(jié)和運(yùn)行Manhattan 兩年經(jīng)驗(yàn)的白文件，敬請期待！

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

以“  云計(jì)算大數(shù)據(jù) 推動(dòng)智慧中國 ”為主題的  第六屆中國云計(jì)算大會(huì) 將于5月20-23日在北京國家會(huì)議中心隆重舉辦。產(chǎn)業(yè)觀察、技術(shù)培訓(xùn)、主題論壇、行業(yè)研討，內(nèi)容豐富，干貨十足。票價(jià)優(yōu)惠，馬上  報(bào)名 ！ 

生活不易，碼農(nóng)辛苦
如果您覺得本網(wǎng)站對您的學(xué)習(xí)有所幫助,可以手機(jī)掃描二維碼進(jìn)行捐贈(zèng)