Hadoop當中負責分布式存儲的HDFS，被定義為分布式文件系統，對于進入到平臺當中的數據，提供高效的、可容錯、可擴展的數據存儲，這得益于分布式文件系統的一個重要特性——伸縮性。今天的大數據開發分享，我們就來講講分布式文件系統的伸縮性設計。分布式文件系統當中，主從式的架構設計，使得伸縮性也基于存儲節點和中心節點兩個層面去實現。

1、存儲節點的伸縮

當在集群中加入一臺新的存儲節點，則它主動向中心節點注冊，提供自己的信息，當后續有創建文件或者給已有文件增加數據塊的時候，中心節點就可以分配到這臺新節點了，比較簡單。但同時也需要解決一些相應產生的問題。

1）如何盡量使各存儲節點的負載相對均衡？

首先要有評價存儲節點負載的指標。可以從磁盤空間使用率考慮，也可以從磁盤使用率+CPU使用情況+網絡流量情況等做綜合判斷。一般來說，磁盤使用率是核心指標。其次在分配新空間的時候，優先選擇資源使用率小的存儲節點；而對已存在的存儲節點，如果負載已經過載、或者資源使用情況不均衡，則需要做數據遷移。

2）怎樣保證新加入的節點，不會因短期負載壓力過大而崩塌？

當系統發現當前新加入了一臺存儲節點，顯然它的資源使用率是最低的，那么所有的寫流量都路由到這臺存儲節點來，那就可能造成這臺新節點短期負載過大。因此，在資源分配的時候，需要有預熱時間，在一個時間段內，緩慢地將寫壓力路由過來，直到達成新的均衡。

3）如果需要數據遷移，那如何使其對業務層透明？

在有中心節點的情況下，這個工作比較好做，中心節點就包辦了——判斷哪臺存儲節點壓力較大，判斷把哪些文件遷移到何處，更新自己的meta信息，遷移過程中的寫入怎么辦，發生重命名怎么辦，無需上層應用來處理。如果沒有中心節點，那代價比較大，在系統的整體設計上，也是要考慮到這種情況，比如ceph，它要采取邏輯位置和物理位置兩層結構，對Client暴露的是邏輯層（pool和placegroup），這個在遷移過程中是不變的，而下層物理層數據塊的移動，只是邏輯層所引用的物理塊的地址發生了變化，在Client看來，邏輯塊的位置并不會發生改變。

2、中心節點的伸縮

如果有中心節點，還要考慮它的伸縮性。由于中心節點作為控制中心，是主從模式，那么在伸縮性上就受到比較大的限制，是有上限的，不能超過單臺物理機的規模。我們可以考慮各種手段，盡量地抬高這個上限。有幾種方式可以考慮：以大數據塊的形式來存儲文件——比如HDFS的數據塊的大小是64M，ceph的的數據塊的大小是4M，都遠遠超過單機文件系統的4k。它的意義在于大幅減少metadata的數量，使中心節點的單機內存就能夠支持足夠多的磁盤空間meta信息。

中心節點采取多級的方式——頂級中心節點只存儲目錄的metadata，其指定某目錄的文件去哪臺次級總控節點去找，然后再通過該次級總控節點找到文件真正的存儲節點；中心節點共享存儲設備——部署多臺中心節點，但它們共享同一個存儲外設/數據庫，meta信息都放在這里，中心節點自身是無狀態的。這種模式下，中心節點的請求處理能力大為增強，但性能會受一定影響。關于大數據開發，分布式文件系統的伸縮性設計，以上就為大家做了簡單的介紹了。關于伸縮性，這是影響分布式文件系統性能的重要指標之一，在架構層面就需要先做好構想。
責任編輯人：CC