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

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

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

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

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

51CTO：是因?yàn)榍度胧介_發(fā)和HBase有什么相通的地方嗎？

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

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

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

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

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

51CTO：數(shù)據(jù)庫(kù)遷移一般都是挺煩人的事情吧。你們?cè)谶w移的時(shí)候有沒(méi)有什么有趣的事情？

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

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

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

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

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

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

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

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

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

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

Nicolas：是的，但不是那種單元測(cè)試環(huán)境，而是一個(gè)真實(shí)的測(cè)試環(huán)境。由用戶產(chǎn)生的流量永遠(yuǎn)比那種基準(zhǔn)測(cè)試要好得多，因?yàn)橛脩舻牧髁亢陀脩舻男阅荏w現(xiàn)才是你所關(guān)注的。

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

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

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

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

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

51CTO：我聽說(shuō)NoSQL在做實(shí)時(shí)遷移方面也相對(duì)簡(jiǎn)單一些，是這樣么？

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

音頻播放：

【編輯推薦】

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