【51CTO獨家專訪】目前，F(xiàn)acebook在全球已經(jīng)有5億用戶。用戶們更新狀態(tài)、發(fā)站內(nèi)信、聊天、玩游戲，積累了巨量的數(shù)據(jù)。單單用戶的基數(shù)就是Facebook的工程師們面臨的大挑戰(zhàn)。這樣一個數(shù)據(jù)庫應(yīng)該怎樣設(shè)計、部署和維護(hù)？Facebook放棄MySQL和Cassandra而采用了HBase是為了什么？在2011年QCon大會北京會場上，51CTO編輯對Facebook信息服務(wù)團(tuán)隊存儲工程師Nicolas Spiegelberg進(jìn)行了專訪，就Facebook的業(yè)務(wù)需求、數(shù)據(jù)庫遷移的實現(xiàn)和難點、大規(guī)模集群的監(jiān)控、以及產(chǎn)品的技術(shù)選型方面進(jìn)行了探討。

[[21403]]
左為Facebook信息服務(wù)團(tuán)隊存儲工程師Nicolas Spiegelberg，右為51CTO編輯

51CTO：首先，能否談?wù)勀慵尤隖acebook之前的工作？

Nicolas：我在2009年下半年的時候加入的Facebook，到現(xiàn)在也一年半多了。那個時候我加入了HBase項目——這個項目當(dāng)時剛剛開始。我們做了很多早期的工作，包括編寫啟動腳本。

在這之前，我是一位嵌入式C++開發(fā)者，針對ADTRAN設(shè)備寫代碼（ADTRAN算是思科的一個競爭者）。嵌入式開發(fā)我做了5年，主要是網(wǎng)絡(luò)層的技術(shù)：TCP/IP，PPP，SPF等等。有一點很有趣的是，我們HBase開發(fā)者當(dāng)中，可能有一半都是以前做過嵌入式開發(fā)的。

51CTO：是因為嵌入式開發(fā)和HBase有什么相通的地方嗎？

Nicolas：兩者之間的共同之處在于有大量的通信層下的傳輸，有分布式環(huán)境，做協(xié)議，減少網(wǎng)絡(luò)延時等。那時候做很多這方面的工作，只是不太需要優(yōu)化自己的代碼。

51CTO：那么在Facebook中，你負(fù)責(zé)了HBase的設(shè)計和部署，從MySQL的遷移。這之前是怎樣一個情況？是你們預(yù)見到未來的變化，還是因為一些已經(jīng)存在的問題需要解決才做出了這個決定？

Nicolas：事實上，我到Facebook的時候，他們已經(jīng)做好了決定。我于是成為了HBase項目最初的開發(fā)者之一。當(dāng)時我自己迫切需要理解的問題之一就是為什么我們要做出這樣的選擇，比如為什么我們不用Cassandra等等。

我們的用戶基數(shù)一直在增長，所以當(dāng)時的首要問題在于分片（sharding）。好比我們的信息系統(tǒng)，用戶們越來越多的使用聊天功能。用戶需要保留他們的聊天記錄，隨時回去查閱它們，而不會容忍幾年前的聊天記錄被丟掉。種種此類需求都造成我們的數(shù)據(jù)量極快的上升，那么分片就成為很痛苦的事情，尤其是如果你要手動做分片的情況。而且我們需要讓分片變得自動化，這樣萬一我們遭遇了一些運維事故，即時有十分之一的服務(wù)器都宕機了，也能夠應(yīng)付的過來。

所以我們需要這樣一個數(shù)據(jù)庫系統(tǒng)盡快上線，能夠完成我們需要的功能，而且不會丟失數(shù)據(jù)。這就牽扯到一個時間預(yù)算的問題。MySQL，Cassandra和HBase都是設(shè)計優(yōu)良的數(shù)據(jù)庫，但問題是我們是要在現(xiàn)有的系統(tǒng)上自己打一些簡陋的補丁將就著用一陣子，還是遷移到一個已經(jīng)具備了此種功能的系統(tǒng)之上來滿足長期的需求。在權(quán)衡之后，我們決定從MySQL轉(zhuǎn)移出來。

51CTO：數(shù)據(jù)庫遷移一般都是挺煩人的事情吧。你們在遷移的時候有沒有什么有趣的事情？

Nicolas：在Facebook這樣規(guī)模的企業(yè)工作的樂趣之一就在于，有些工作在中小企業(yè)里只有痛苦，但是在Facebook當(dāng)中則是一種挑戰(zhàn)。比如這個數(shù)據(jù)遷移，在Facebook里就有非常多的挑戰(zhàn)。一個是性能優(yōu)化。對于一般規(guī)模的遷移，優(yōu)化并不在考慮當(dāng)中；但是我們現(xiàn)在有5億用戶，做數(shù)據(jù)遷移的話，如果我們一周做1千萬個，做完5億則需要一年！這個速度是不可以接受的，是非常慢的。所以就需要做大量的優(yōu)化。

那么這其中一個有趣的事情就是，你做優(yōu)化，首先要檢查一下，別人是不是已經(jīng)做過相應(yīng)的功能，你是不是已經(jīng)進(jìn)行了最合適的配置。不要花半天功夫?qū)懥藗€2000行代碼的功能，結(jié)果卻發(fā)現(xiàn)前人已經(jīng)做過相關(guān)的工作。很多時候，我們的問題并非是沒有某個功能，而是你不知道已經(jīng)有了哪些功能！

51CTO：然后他們就不知道可以用現(xiàn)成的功能。

Nicolas：所以我們說，做任何事情之前，應(yīng)該先多花一些功夫來真正了解這個系統(tǒng)。

51CTO：很有意思。那么接下來我們聊一些有關(guān)優(yōu)化之前的一些工作。一個網(wǎng)站遇到性能問題，原因可能有無數(shù)種——我這么說沒問題吧？

Nicolas：當(dāng)然！那是一定的。

51CTO：那么在Facebook，我們是如何快速定位性能問題的根源呢？

Nicolas：首先，我們會用Ganglia等軟件做度量計算——整個Facebook其實用到很多度量。那么我們有40個左右的圖表來監(jiān)控集群的健康狀況。當(dāng)我們監(jiān)測到PUT Latency的值變得很高的時候，我們首先去檢查所有牽涉到PUT的主要進(jìn)程，分析這些進(jìn)程的度量，深入進(jìn)去。我們進(jìn)行日志分析，用正則表達(dá)式來挖掘數(shù)據(jù)日志。對于大部分?jǐn)?shù)據(jù)，其實我們并不需要一個調(diào)試器，你需要的是和一些非常熟悉這個系統(tǒng)的人坐在一起，反復(fù)探討可能出現(xiàn)的問題。

所以，我們在Facebook遇到的問題，一般都是這樣解決的：先去看圖表，再看日志，嘗試去理解發(fā)生了什么事，嘗試在理論上找出系統(tǒng)的修復(fù)方法。接下來就是在后端的集群中用不同的流量去測試它，從而驗證我們是不是真的修復(fù)了這個問題。

51CTO：所以相當(dāng)于是在一個測試環(huán)境中調(diào)試？

Nicolas：是的，但不是那種單元測試環(huán)境，而是一個真實的測試環(huán)境。由用戶產(chǎn)生的流量永遠(yuǎn)比那種基準(zhǔn)測試要好得多，因為用戶的流量和用戶的性能體現(xiàn)才是你所關(guān)注的。

51CTO：好的，十分感謝。這些就是Facebook一般進(jìn)行系統(tǒng)檢查的流程了吧。

Nicolas：是的。話說我想有一點我想要強調(diào)一下，就是作為HBase的工程師，你看到我們有那么多度量，有那么多圖表。這些其實是因為在我們?yōu)镠Base設(shè)計任何新功能之前，我們會先考慮清楚需要為日后的分析工作放入哪些度量進(jìn)去。我認(rèn)為這是非常重要的。有很多開發(fā)者總是先加了功能上去，然后回頭發(fā)現(xiàn)要修改這個、添加那個，***就會很煩。所以***一開始就把它們設(shè)計進(jìn)去。

51CTO：所以說，就是要從一開始就把事情做對嘍。那么***談?wù)勔粋€比較開放的問題吧。對于創(chuàng)業(yè)者，你會建議他們使用NoSQL嗎？

Nicolas：我覺得毋庸置疑的一點是，你必須要從你的系統(tǒng)本身入手。NoSQL對于很多Web創(chuàng)業(yè)網(wǎng)站是非常合適的，尤其是當(dāng)你的用戶數(shù)量面臨快速增長的情況。而對于小量數(shù)據(jù)而言——當(dāng)然這個小量是相對的，好比GB級的數(shù)據(jù)量在我們這個TB級的世界里就是小量的——則無所謂用不用NoSQL了。

那么有關(guān)NoSQL***的一點就是高可擴展性，動態(tài)可擴展性。無需為分片發(fā)愁，無需頻繁的替換查詢表（Query Tables）。

51CTO：我聽說NoSQL在做實時遷移方面也相對簡單一些，是這樣么？

Nicolas：我們用HBase做實時遷移，那么就如同之前所說，它能夠處理大量的負(fù)載。假如說我們有個集群為2000萬用戶提供服務(wù)，然后我們要再遷1000萬進(jìn)來，那么它是可以處理這個擴展的。但是就算它擴展性再好，也不是說你能盲目的去做這個事兒，搞個不好，你遷移1000萬進(jìn)來，結(jié)果所有的用戶都崩潰了。除非你事先做好分析，做好配置文件的修正，在后端做好大量的測試，這樣在上線的時候才能按照預(yù)期的狀態(tài)進(jìn)展。

音頻播放：

【編輯推薦】

1. 視機密如糞土 Facebook數(shù)據(jù)中心信息公開
2. 輸入facebook的URL按下回車后究竟發(fā)生了什么
3. 社交網(wǎng)絡(luò) David Recordon談Facebook的開源之路