ozone的出現的初衷就是要解決hdfs namespace的擴充套件性問題，那麼現在問題了，未來如何將這兩大從設計上上來已經完全大改變的系統整合起來呢？這個聽起來非常有意思，本文筆者結合最近社群的一些討論，來簡單聊聊這個話題。
社群在設計ozone的時候，提出了乙個具有關鍵性意義的概念：storage container。而不是hdfs中的塊（block）概念。二者的關係是：storage container對外提供塊服務。而storage container由底層儲存向外提供服務，它可以支援不同的上層系統。所以ozone的結構是這樣的：
而在ozone中，scm只負責維護這些container資訊。原先的block report就會變成container report。此時的關係變為：
ksm: object —> block
scm: block —> container
在上圖中，我們看到的是1對1的關係，在未來ozone會支援到多對多的關係，類似與目前hdfs的federation。
ozone既然已經出現了，現在我們如何把現有hdfs移植到ozone之上。比如達到下面的架構，這樣就充分利用了新設計的架構體系。
在這裡，我們需要乙個關鍵的實現：ozone fs，ozone內部提供的檔案系統介面。以此將新的資料寫出到ozone filesystem，ozfs完全相容現有的hdfs路徑格式和讀取方式，可以給spark、hive程式使用。通過現有檔案操作相容api，可以將資料從老的hdfs轉移到ozone中。這步操作實質做的改動：將全存入記憶體的namespace資料移到了k-v儲存的namespace中。相比於之前記憶體式的查詢讀取，k-v儲存下查詢的操作就變為了io scan的方式了，效率上還是會有所影響。可能在未來，再進一步優化，只保留工作集的資料在記憶體中，達到新hdfs的狀態結果。
當然，要想讓現有hdfs更加平滑地構建於ozone之上，還需要很多的工作需要去做。
1.
業務和技術的融合
我記得三年前去一家軟體公司應聘的時候，面試我的是乙個做市場方面的領導，當時他問了我乙個問題 你認為技術是最重要的嗎，業務一點都不重要嗎？聽他這麼問，我當時就說不是，業務也很重要，技術要依託於業務才能產生價值。來到現在幹的這家公司後，前些天又聽到我公司的技術總監說 其實單純做技術是走不遠的，技術要和業...
HDFS的特性和缺點
1 海量資料儲存 hdfs可橫向擴充套件，其儲存的檔案可以支援pb級別或更高階別的資料儲存。2 高容錯性 資料儲存多個副本，副本丟失後自動恢復。可構建在廉價的機器上，實現線性擴充套件。當集群增加新節點之後，namenode也可以感知，進行負載均衡，將資料分發和備份資料均衡到新的節點上。3 商用硬體 ...
HDFS的特性和缺點
海量資料儲存 hdfs 可橫向擴充套件，其儲存檔案可以支援pb級別資料 高容錯性 節點丟失，系統依然可用，資料儲存多個副本，副本丟失後自動恢復。可建構在廉價 與小型機大型機比 的機器上，實現線性擴充套件 隨著節點數量的增加，集群的儲存能力增加 大檔案儲存 dfs採用資料塊的方式儲存資料，將乙個大檔案...