專訪Facebook工程師：遷移5億用戶數據的挑戰
原創【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萬進來，結果所有的用戶都崩潰了。除非你事先做好分析，做好配置文件的修正，在后端做好大量的測試，這樣在上線的時候才能按照預期的狀態進展。
音頻播放：
【編輯推薦】
