Facebook 在今年六月 SIGMOD 2011 上發表了一篇名爲“Apache Hadoop Goes Realtime at Facebook”的會議論文 (pdf)，介紹了 Facebook 爲了打造一個實時的 HBase 系統使用到的獨門祕技。由於該論文提到的應用場景與小弟負責的系統要解決的問題域有相似之處，因而抽時間仔細閱讀了這篇論文。下面便是結合論文的內容，談一談我的一些看法和感想，如有謬誤，敬請指正。
這篇 10 頁的長文主要的內容是 Facebook 在 Hadoop 系統上的工程實踐，這些工程實踐的目標則是題目所點出的——實時。雖然缺乏 Hadoop 系統的開發或使用經驗，但是我覺得並沒有妨礙我對這篇論文的理解。在我的腦子裏，HDFS 就是 GFS，HBase 就是 BigTable。它們實現上可能有差異之處，但主要的思想應該是相通的。如果熟悉 GFS 和 BigTable 那兩篇文章，這篇文章就可以視爲 GFS 和 BigTable “進階”。
1. 應用場景和需求
文章的最初是一些背景介紹，主要給出了三類應用場景：Facebook Messaging、Facebook Insight 和 Facebook Metrics System(ODS)。Messaging 就是 Facebook 的新型消息服務，Insight 是提供給開發者和網站主的數據分析工具，ODS 則是 Facebook 內部的軟硬件狀態統計系統。這三個應用場景都有各自的特色，但簡單地來說，面臨的問題是同樣的：單機或者拆分的關係型數據庫無法滿足需求。
基於應用場景的數據特徵，Facebook 抽象出了幾個對存儲系統的需求。由於描述起來有些複雜，例如 Efficient and low-latency strong consistency semantics within a data center，這些需求就不一一列舉了。相比需求，更讓人感興趣的是它的那些“非需求”，總共有三條：
容忍單數據中心內部的網絡分化，Facebook 認爲這個問題應該從網絡硬件層面（做冗餘設計）而不是軟件層面去解決；
單個數據中心宕機不影響服務，Facebook 認爲這種災難很難發生，因而願意接受這種風險；
跨數據中心的數據熱備服務能力，Facebook 假設用戶數據是分配到固定的數據中心的，可能帶來的響應延遲問題應該通過緩存來解決。
從這些“非需求”上可以看出，Facebook 考慮的是更實際的情況，而不是一個理想中的分佈式系統，在這點上有一定的借鑑意義。
根據以上的需求和非需求，Facebook 自然而然地給出選擇 Apache Hadoop 這套系統的理由，其中有社區的成熟度、Hadoop 在一致性、擴展性、可用性、故障容忍、讀寫效率等等的各項優點，這些方面的優點也是有目共睹的。
2. 打造實時的 HDFS
HDFS 本身設計來支持離線 MapReduce 計算的分佈式文件系統，雖然在擴展性和吞吐上有很好的表現，但在實時性方面表現並不好。如果想讓基於 HDFS 的 HBase 有更好的性能，HDFS 層的優化是不可避免的。爲了把 HDFS 打造成一個通用的低時延文件系統，Facebook 主要做了以下一些優化。
2.1 實現 NameNode 的高可用——AvatarNode
HDFS 的 NameNode 是系統單點，就意味着 NameNode 掛掉會導致系統的不可用。NameNode 重啓時加載內存快照、應用log和收集 DataNode 的數據塊信息報告大概需要 45 分鐘。即便使用了 BackupNode，仍然需要收集數據塊信息報告，切換的時間仍然可能大於 20 分鐘。但有實時性需求的系統一般都會要求系統 24x7 的可用性，因而 Facebook 對單點的 NameNode 進行了改進，實現了 NameNode 的雙節點熱備，稱爲 AvatarNode，如下圖所示：
AvatarNode
簡單地來說，備份 AvatarNode 通過 NFS 讀取並回放主 AvatarNode 的事務日誌來保持數據的同步，並同時接收 DataNode 的數據塊信息報告，這保證了主備 AvatarNode 的數據差距儘可能地小，使得備份 AvatarNode 能夠很快地切換爲主節點的角色。主備 AvatarNode 的角色是註冊到 ZooKeeper 中的，DataNode 可以根據 ZooKeeper 中信息判斷需要服從哪個 AvatarNode 節點的指令。
爲了實現熱備 AvatarNode 的數據同步和易用性，Facebook 還改進了 NameNode 事務日誌，並部署了 DAFS (Distributed Avatar File System) 屏蔽了 AvatarNode 的故障切換，使得這些改變對客戶端透明。文中並沒有提到 AvatarNode 的切換是手工還是自動進行的，但是考慮到 ZooKeeper 的 lease 機制，自動切換應該不難實現。
2.2 Hadoop RPC 兼容性和數據塊可用性
在之前的系統需求中，有提到一點是 Fault Isolation，並且 Facebook 的 Hadoop 系統是在單機房部署的，因而同一個服務必然會使用多套 Hadoop 系統。爲了系統升級獨立方便，使客戶端兼容不同版本的 Hadoop RPC 是自然而然的事情。
HDFS 在分配副本數據塊位置時，雖然會考慮到機架位，但整體來說仍然是相當隨機的。其實我以前也曾經與同事討論過類似的問題，到底是選擇隨機分配副本位置，還是使用一定的組策略去分配。隨機分配的好處是簡單均衡，壞處是一旦發生多臺宕機，由於副本隨機分佈，導致某塊數據副本全部丟失概率很大；用一定的組策略去分配的好處是多臺宕機如果不發生在同一組裏，不會丟數據，但是一旦多臺宕機發生在同一組，會丟很多數據。看來 Facebook 是選用了組策略分配的方法，認爲多臺宕機發生在同一組的概率不大。
但這樣做是否正確，我是有疑問的。同一個機架或相鄰機架上的服務器一般上架時間、硬件型號等都相同，那麼同時發生故障的事件不是完全獨立的，其概率是要大於理想故障分佈情況下概率的。我想這也是爲什麼 Facebook 最終方案中一組機器是 (2, 5)，2 個機架，5 臺服務器。這兩個機架的選擇，如果很謹慎的話，能夠儘量避免我說的這種情況。不過，凡事還得看執行力，如果不瞭解部署情況去選擇機架的話，不一定能夠達到預期效果。
2.3 實時負載的性能優化
除了上面的改動之外，Facebook 還對客戶端的 RPC 過程進行了優化。爲 RPC 添加超時機制，加快文件 lease 的撤銷速度（由於對 HDFS 文件操作不瞭解，我沒明白爲什麼要加快 lease 撤銷）。
此外，還提到了最重要的一點：局部性！Facebook 增加了一個檢查文件塊是否在本機的功能，如果在本機就直接讀取。不知道它具體實現方式是怎樣的，但我覺得這個做法其實是“很黃很暴力”的，不知道會不會破壞數據一致性。
2.4 HDFS sync 優化和併發讀
爲了提高寫性能，Facebook 允許不等待 sync 結束就繼續寫，這一點看起來也很暴力，不知道會不會影響數據正確性。
爲了能夠讀到最新數據，Facebook 允許客戶端讀一個還未寫完的數據文件。如果讀到正在寫入的最後一個塊，就重新計算 checksum。
3. 打造實時生產壞境的 HBase
3.1 行級別原子性和一致性
雖然 HBase 已經保證了行級別的原子性，但節點宕機可能導致最後一條更新日誌不完整。Facebook 不夠滿意，引入了 WALEdit，一個日誌事務概念來保證每條更新日誌的完整性。
一致性方面，看來 HBase 能夠滿足需求。不過對於 3 個副本同時校驗失敗導致數據塊不可用的情況，Facebook 增加了事後分析的機制，而不是簡單丟棄。
3.2 可用性
爲了提高 HBase 的可用性，Facebook 對其進行了完善的測試，並解決了以下幾個問題：
重寫 HBase Master，將 ragion 分配信息存儲到 ZooKeeper 中以保證宕機切換正確完成。
使得 compaction 可以中斷以加速 RegionServer 的正常退出速度，並實現 rolling restarts（就是逐臺升級），降低程序升級對服務的影響。
將宕機 RegionServer 的日誌拆分功能從 Master 中拆離，由多個 RegionServer 進行拆分，以提高 RegionServer 故障恢復效率。
這幾個問題的解決倒是有通用的用途，我想不久以後很有可能會合併到 Hadoop 的代碼中。
3.3 性能優化
性能優化主要從兩點進行，一個是 compaction 性能，另一個是讀性能。
讀過 BigTable 論文的應該對其 memtable 和 compaction 的特性比較熟悉。這裏主要討論了讓 minor compaction 也刪除數據的好處，以及如何做 major compaction 能夠提高合併的性能。
在數據讀性能方面，文章裏主要討論了減少 IO 操作的方法，其中包括 bloom filter 和特定類型 meta 信息（時間戳）的使用。還有很重要的一點，在部署上保持 RegionServer 和物理文件的局部性！
文章後面還給出了 Facebook 在部署和運維方面的一些經驗，其中有一些有趣的點，我後續可能會寫篇文章專門討論，這裏就不詳細說明了。
4. 總結
以前我們也曾經討論過如何在分佈式文件系統的基礎上搭建一套實時數據分析系統，當時認爲如果有成熟的 GFS 可用的話，這個工作會比較簡單。現在讀到 Facebook 的這篇文章，才發現當初想法的幼稚。僅僅從這篇文章中的技術點體現出的工作量來看，文中說這個系統是多年持續工作的結晶是令人信服的。當然，這也意味着想複製一套這樣的系統並不是件輕鬆容易的事。
從系統設計的成果來看，這個系統應該能達到文章開頭制定的需求目標，並也能夠滿足大部分應用場景的需要。不過有一點，我存在疑問，即是爲 Insights 提供的 Realtime Analytics 功能。Realtime 沒問題，但使用 HBase， Analytics 究竟能支持多好呢？可能還需要再去了解 HBase 的功能纔能有答案。
從這個系統的很多細節可以發現，有不少折中和 trick。我想這就是現實世界，凡事很難做到盡善盡美，工程也一樣。在設計系統時追求完美沒有錯，但是需要考慮代價和可行性，不要忘記滿足需求才是最重要的目標。除此之外，也不妨再列出一些“非需求”，排除這些限制可能會降低不少的系統複雜度。
轉載自：http://blog.solrex.org/articles/facebook-realtime-hadoop-system.html