【51CTO獨家專訪】目前，Facebook在全球已經有5億用戶。用戶們更新狀態、發站內信、聊天、玩遊戲，積累了巨量的數據。單單用戶的基數
就是Facebook的工程師們面臨的大挑戰。這樣一個數據庫應該怎樣設計、部署和維護？Facebook放棄MySQL和Cassandra而採用了
HBase是爲了什麼？在2011年QCon大會北京會場上，51CTO編輯對Facebook信息服務團隊存儲工程師Nicolas
Spiegelberg進行了專訪，就Facebook的業務需求、數據庫遷移的實現和難點、大規模集羣的監控、以及產品的技術選型方面進行了探討。
左爲Facebook信息服務團隊存儲工程師Nicolas Spiegelberg，右爲51CTO編輯
51CTO：首先，能否談談你加入Facebook之前的工作？
Nicolas：我在2009年下半年的時候加入的Facebook，到現在也一年半多了。那個時候我加入了HBase項目——這個項目當時剛剛開始。我們做了很多早期的工作，包括編寫啓動腳本。
在這之前，我是一位嵌入式C++開發者，針對ADTRAN設備寫代碼（ADTRAN算是思科的一個競爭者）。嵌入式開發我做了5年，主要是網絡層的技術：TCP/IP，PPP，SPF等等。有一點很有趣的是，我們HBase開發者當中，可能有一半都是以前做過嵌入式開發的。
51CTO：是因爲嵌入式開發和HBase有什麼相通的地方嗎？
Nicolas：兩者之間的共同之處在於有大量的通信層下的傳輸，有分佈式環境，做協議，減少網絡延時等。那時候做很多這方面的工作，只是不太需要優化自己的代碼。
51CTO：那麼在Facebook中，你負責了HBase的設計和部署，從MySQL的遷移。這之前是怎樣一個情況？是你們預見到未來的變化，還是因爲一些已經存在的問題需要解決才做出了這個決定？
Nicolas：事實上，我到Facebook的時候，他們已經做好了決定。我於是成爲了HBase項目最初的開發者之一。當時我自己迫切需要理解的問題之一就是爲什麼我們要做出這樣的選擇，比如爲什麼我們不用Cassandra等等。
我們的用戶基數一直在增長，所以當時的首要問題在於分片（sharding）。好比我們的信息系統，用戶們越來越多的使用聊天功能。用戶需要保留他
們的聊天記錄，隨時回去查閱它們，而不會容忍幾年前的聊天記錄被丟掉。種種此類需求都造成我們的數據量極快的上升，那麼分片就成爲很痛苦的事情，尤其是如
果你要手動做分片的情況。而且我們需要讓分片變得自動化，這樣萬一我們遭遇了一些運維事故，即時有十分之一的服務器都宕機了，也能夠應付的過來。
所以我們需要這樣一個數據庫系統儘快上線，能夠完成我們需要的功能，而且不會丟失數據。這就牽扯到一個時間預算的問題。
MySQL，Cassandra和HBase都是設計優良的數據庫，但問題是我們是要在現有的系統上自己打一些簡陋的補丁將就着用一陣子，還是遷移到一個
已經具備了此種功能的系統之上來滿足長期的需求。在權衡之後，我們決定從MySQL轉移出來。
51CTO：數據庫遷移一般都是挺煩人的事情吧。你們在遷移的時候有沒有什麼有趣的事情？
Nicolas：在Facebook這樣規模的企業工作的樂趣之一就在於，有些工作在中小企業裏只有痛苦，但是在Facebook當中則是一種挑
戰。比如這個數據遷移，在Facebook裏就有非常多的挑戰。一個是性能優化。對於一般規模的遷移，優化並不在考慮當中；但是我們現在有5億用戶，做數
據遷移的話，如果我們一週做1千萬個，做完5億則需要一年！這個速度是不可以接受的，是非常慢的。所以就需要做大量的優化。
那麼這其中一個有趣的事情就是，你做優化，首先要檢查一下，別人是不是已經做過相應的功能，你是不是已經進行了最合適的配置。不要花半天功夫寫了個
2000行代碼的功能，結果卻發現前人已經做過相關的工作。很多時候，我們的問題並非是沒有某個功能，而是你不知道已經有了哪些功能！
51CTO：然後他們就不知道可以用現成的功能。
Nicolas：所以我們說，做任何事情之前，應該先多花一些功夫來真正瞭解這個系統。
51CTO：很有意思。那麼接下來我們聊一些有關優化之前的一些工作。一個網站遇到性能問題，原因可能有無數種——我這麼說沒問題吧？
Nicolas：當然！那是一定的。
51CTO：那麼在Facebook，我們是如何快速定位性能問題的根源呢？
Nicolas：首先，我們會用Ganglia等
軟件做度量計算——整個Facebook其實用到很多度量。那麼我們有40個左右的圖表來監控集羣的健康狀況。當我們監測到PUT
Latency的值變得很高的時候，我們首先去檢查所有牽涉到PUT的主要進程，分析這些進程的度量，深入進去。我們進行日誌分析，用正則表達式來挖掘數
據日誌。對於大部分數據，其實我們並不需要一個調試器，你需要的是和一些非常熟悉這個系統的人坐在一起，反覆探討可能出現的問題。
所以，我們在Facebook遇到的問題，一般都是這樣解決的：先去看圖表，再看日誌，嘗試去理解發生了什麼事，嘗試在理論上找出系統的修復方法。接下來就是在後端的集羣中用不同的流量去測試它，從而驗證我們是不是真的修復了這個問題。
51CTO：所以相當於是在一個測試環境中調試？
Nicolas：是的，但不是那種單元測試環境，而是一個真實的測試環境。由用戶產生的流量永遠比那種基準測試要好得多，因爲用戶的流量和用戶的性能體現纔是你所關注的。
51CTO：好的，十分感謝。這些就是Facebook一般進行系統檢查的流程了吧。
Nicolas：是的。話說我想有一點我想要強調一下，就是作爲HBase的工程師，你看到我們有那麼多度量，有那麼多圖表。這些其實是因爲在我們
爲HBase設計任何新功能之前，我們會先考慮清楚需要爲日後的分析工作放入哪些度量進去。我認爲這是非常重要的。有很多開發者總是先加了功能上去，然後
回頭發現要修改這個、添加那個，最後就會很煩。所以最好一開始就把它們設計進去。
51CTO：所以說，就是要從一開始就把事情做對嘍。那麼最後談談一個比較開放的問題吧。對於創業者，你會建議他們使用NoSQL嗎？
Nicolas：我覺得毋庸置疑的一點是，你必須要從你的系統本身入手。NoSQL對於很多Web創業網站是非常合適的，尤其是當你的用戶數量面臨
快速增長的情況。而對於小量數據而言——當然這個小量是相對的，好比GB級的數據量在我們這個TB級的世界裏就是小量的——則無所謂用不用NoSQL了。
那麼有關NoSQL最好的一點就是高可擴展性，動態可擴展性。無需爲分片發愁，無需頻繁的替換查詢表（Query Tables）。
51CTO：我聽說NoSQL在做實時遷移方面也相對簡單一些，是這樣麼？
Nicolas：我們用HBase做實時遷移，那麼就如同之前所說，它能夠處理大量的負載。假如說我們有個集羣爲2000萬用戶提供服務，然後我們
要再遷1000萬進來，那麼它是可以處理這個擴展的。但是就算它擴展性再好，也不是說你能盲目的去做這個事兒，搞個不好，你遷移1000萬進來，結果所有
的用戶都崩潰了。除非你事先做好分析，做好配置文件的修正，在後端做好大量的測試，這樣在上線的時候才能按照預期的狀態進展。