型別：技術專欄 

作者介紹

張凱（Kyle Zhang），SmartX 聯合創始人 & CTO。畢業於清華大學計算機系，研究方向為分散式系統和體系結構。2013 年與徐文豪、王弘毅聯合創立 SmartX，主導自主研發了 SmartX 分散式檔案系統 SmartX ZBS。SmartX 擁有國內最頂尖的分散式儲存和超融合架構研發團隊，是國內超融合領域的技術領導者。

本文轉載自知乎專欄 @SmartX 技術部落格，點選底部“閱讀原文”進入部落格瀏覽更多文章。

過去半年閱讀了 30 多篇論文，堅持每 1~2 周寫一篇 Newsletter，大部分都和儲存相關。今天在這裡進行一個總結，供大家作為了解儲存技術熱點和趨勢的參考。本文包含了全新的技術領域，如 Open-Channel SSD，Machine Learning for Systems；也包含老話題的新進展，如 NVM，LSM-Tree，Crash Consistency；以及工業界的進展。

Open-Channel SSD

Open-Channel SSD 在國內關注的人比較少。和傳統 SSD 相比，Open-Channel SSD 僅提供一個最簡化的 SSD，只包含 NAND 晶片和控制器，並不包含 Flash Translation Layer（FTL）。原有 FTL 中的功能，例如 Logical Address Mapping，Wear Leveling，Garbage Collection 等，需要由上層實現，可能是作業系統，也可能是某個應用程式。也就是說，Open-Channel SSD 提供了一個裸 SSD，使用者可以根據自己的需要設計和實現自己的 FTL，以達到最佳效果。

我們通過一個具體場景來描述 Open-Channel SSD 的價值。RocksDB 作為一個單機儲存引擎，被廣泛應用在很多分散式儲存的場景中。RocksDB 的資料儲存採用 LSM-Tree + WAL 的方式，其中，LSM-Tree 用於儲存資料和索引，WAL 用於保證資料寫入的完整性（Data Integrity）。由於目前在 RocksDB 的實現中，LSM-Tree 中的 SSTable 和 WAL 都是檔案系統上的一個檔案，所以資料寫入 WAL 的過程中，也會觸發檔案系統的資料保護機制，例如 Journaling。而檔案系統在將資料寫入 Journal 時，也會觸發 SSD FTL 層的資料保護機制。所以，一次 RocksDB 的寫請求會經過三個 IO 子系統：RocksDB，File System，FTL。每一層子系統為了保證資料完整性，都會產生寫放大（Write Amplification），使得一次寫入被放大幾十甚至上百倍。這個現象可以被形象的描述為『Log-On-Log』的現象。

而實際上，對於 RocksDB 的 WAL，以及檔案系統的 Journal，實際上都是臨時性的寫入，並不需要底層系統額外的資料保護機制。Open-Channel SSD 的出現提供了打破這個現象的機會，如果在 RocksDB 可以繞過檔案系統層以及 FTL，則可以將三層 Log 合併為一層，避免寫入放大，最大化發揮 SSD 的效能。

除了避免寫放大之外，在 LSM-Tree 資料結中，由於 SSTable 是隻讀不可修改的，而 SSD 的 Block 也是隻讀的（如果要寫入必須先擦寫），那麼 RocksDB 可以利用 SSD 的這個特點，讓 SSTable 與 Block 對齊，將 LSM-Tree 中的刪除 SSTable 操作與 SSD 的 Block 回收操作合併，避免 SSD Block 回收時產生的資料拷貝操作，避免 GC 對效能產生影響。在 『An Efficient Design and Implementation of LSM-Tree based Key-Value Store on Open-Channel SSD』 中，就實現了將 LevelDB 直接執行在 Open-Channel SSD 上。

除了避免寫放大，Open-Channel SSD 還提供了實現 IO Isolation 的可能性。由於 SSD 的物理特性，SSD 的效能和資料的物理佈局緊密相關。SSD 的效能來自於每一個 NAND 晶片的效能的總和。每一個 NAND 晶片提供的 IO 效能很低，但由於 NAND 晶片之間可以進行並行化，這使得 SSD 的整體效能非常高。換句話說，資料的佈局決定了 IO 效能。然而由於傳統的 SSD 上運行了 FTL，FTL 不僅會對資料的佈局進行重對映，同時在後臺還會執行 GC 任務，這使得 SSD 的效能是無法預測的，也無法進行隔離。Open-Channel SSD 將底層資訊暴露給上層應用，通過將資料放置在不同的 NAND 晶片上，可以在物理層面達到資料分佈隔離，同時也就打到了效能的隔離的效果。

為了方便的管理和操作 Open-Channel SSD，LightNVM 應運而生。LightNVM 是在 Linux Kernel 中一個針對 Open-Channel SSD 的 Subsystem。LightNVM 提供了一套新的介面，用於管理 Open-Channel SSD，以及執行 IO 操作。為了和 Kernel 中現有的 IO 子系統協同工作，還存在 pblk（Physical Block Device）層。他在 LightNVM 的基礎上實現了 FTL 的功能，同時對上層暴露傳統的 Block 層介面，使得現有的檔案系統可以通過 pblk 直接執行在 Open-Channel SSD 上。2017 年 FAST 上的一篇 paper：『LightNVM: The Linux Open-Channel SSD Subsystem』專門介紹了 LightNVM。

目前 LightNVM 已經被合併入 Kernel 的主線。而對於使用者態的程式來說，可以通過 liblightnvm 操作 Open-Channel SSD。

2018 年 1 月，Open-Channel SSD 釋出了 2.0 版本的標準。但無論是 Open-Channel SSD，還是 LightNVM 都還處於非常早期的階段，目前在市面上很難見到 Open-Channel SSD，不適合直接投入到生產中。儘管如此，Open-Channel SSD 和 Host based FTL 帶來的好處是非常巨大的。對於追求極致儲存效能的場景，在未來很可能會採用 Open-Channel SSD + LightNVM 的實現方式。

Non-volative Memory（NVM）

NVM，或者 PM（persistent memory），SCM（storage class memory），實際上都是一個意思，指的都是非易失性記憶體。NVM 在學術界火了很多年了， 相關的研究在不斷向前推進。

一直以來，由於 2：8 定律的特性，計算機系統的儲存一直是採用分層的結構，從上到下依次是 CPU Cache，DRAM，SSD，HDD。 其中，CPU Cache 和 DRAM 是易失性的（volatile），SSD 和 HDD 是非易失性的（non-volatile）。儘管 SSD 的速度遠高於 HDD，但和 DDR 相比，還是有一定的差距。SSD 提供 10us 級別的響應時間，而 DRAM 只有 ns 級別，這中間有一萬倍的差距。由於 DRAM 和 SSD 之間巨大的效能差距，使得應用程式需要非常仔細的設計 IO 相關的操作，避免 IO 成為系統的效能瓶頸。

而 NVM 的出現彌補了這個差距。NVM 在保持非易失性的前提下，將響應時間降低到 10ns 級別，同時單位容量價格低於 DRAM。此外，NVM 是按位元組訪問（byte-addressable），而不像磁碟按照塊（Block）訪問。NVM 的出現打破了傳統的儲存層次，將對軟體架構設計產生巨大的影響。

NVM 看上去很美好，但目前並不能像記憶體或磁碟一樣，做到即插即用。在傳統的作業系統中，Virtual Memory Manager（VMM）負責管理易失性記憶體，檔案系統負責管理儲存。而 NVM 既像記憶體一樣可以通過位元組訪問，又像磁碟一樣具有非易失性的特點。使用 NVM 的方式主要有兩種：

1.將 NVM 當做事務性記憶體（Persistant Transactional Memory）使用，包括採用 Redo Logging，Undo Logging，以及 Log-Structured 等管理方式。

2.將 NVM 當做磁碟使用，提供塊以及檔案的介面。例如在 Linux 中引入的 Direct Access（DAX），可以將對現有的檔案系統進行擴充套件，使得其可以執行在 NVM 上，例如 Ext4-DAX。也有類似於 PMFS，NOVA 等專門為 NVM 定製的檔案系統。

面向 NVM 進行程式設計和麵向傳統的記憶體或磁碟程式設計是非常不同，這裡我們舉一個非常簡單的例子。例如，有一個函式用於執行雙鏈表插入操作：

然而對於 NVM 來說，由於是非易失性的，假設在執行到函式的第一行後發生了斷電，當系統恢復後，連結串列處於一個異常且無法恢復的狀態。同時，由於 CPU 和 NVM 之間還有 CPU Cache 作為快取，以及 CPU 執行具有亂序執行的特性，所以 NVM 需要使用特殊的程式設計模型，也就是 NVM Programming Model。通過顯示的指定 Transaction，達到原子性操作的語義，保證當系統恢復時，不會產生中間狀態。

在分散式場景下，如果要充分發揮 NVM 的效能，就必須和 RDMA 結合。由於 NVM 的超高的效能，Byte Addressable 的訪問特性，以及 RDMA 的訪問方式，使得分散式的 NVM + RDMA 需要全新的架構設計，包括單機資料結構，分散式資料結構，分散式一致性演算法等等。在這方面，清華計算機系高效能所去年發表的 Octopus 提供了一個思路，通過 NVM + RDMA 實現了分散式檔案系統，同時在自己實現一套基於 RDMA 的 RPC 用於進行節點間的通訊。

然而尷尬的是，儘管學術界在 NVM 上已經研究了數十年，但在工業界目前還沒有可以大規模商用的 NVM 產品，大家還只能基於模擬器進行研究。Intel 和 Micro 在 2012 年合作一起研發 3D XPoint 技術，被認為是最接近能商用的 NVM 產品。Intel 在 2017 年釋出了基於 3D XPoint 技術的磁碟產品 Optane，而 NVM 產品（代號 Apache Pass）還沒有明確的釋出時間。

然而即使 NVM 產品面世，由於 NVM 的價格和容量的限制，以及複雜的程式設計模式，在實際生產中很少會出現純 NVM 的場景，更多的還是 tiering 的形式，也就是 NVM + SSD + HDD 的組合。在這個方面，2017 SOSP 上的一篇論文 Strata 也提供了一個不錯的思路。

Machine Learning for Systems

去年 Jeff Dean 所在的 Google Brain 團隊發表了一篇非常重要的論文『The Case for Learned Index Structures』。可以說從這篇文章開始，系統領域展開了一個新的方向，Machine Learning 與系統相結合。不得不讚嘆 Jeff Dean 對電腦科學的影響力。

這篇文章，以及 Jeff Dean 在 NIPS17 ML Systems Workshop 上的 talk，都釋放出了一個很強的訊號，計算機系統中包含了大量的 Heuristics 演算法，用於做各種各樣的決策，例如 TCP 視窗應該設定為多大，是否應該對資料進行快取，應該排程哪一個任務等等。而每一種演算法都存在效能，資源消耗，錯誤率，以及其他方面的 Tradeoff，需要大量的人工成本進行選擇和調優。而這些正是Machine Learning 可以發揮的地方。

在 『The Case for Learned Index Structures』 文章中，作者提到了一個典型的場景，資料庫的索引。傳統的索引通常採用 B 樹，或 B 樹的變種。然而這些資料結構通常是為了一個通用的場景，以及最差的資料分佈而進行設計的，並沒有考慮到實際應用中資料分佈情況。對於很多特殊的資料分佈場景，B 樹並不能夠達到最優的時間和空間複雜度。為了達到最佳效果，需要投入大量的人力進行資料結構的優化。同時，由於資料的分佈在不斷的變化，調優的工作也是持續不斷的。作者提出的的 Learned Index，則是通過與 Machine Learning 技術結合，避免人工調優的開銷。

在這篇文章中，作者把索引資料結構當做一個 Model，這個 Model 的輸入是一個 Key，輸出是這個 Key 對應的 Value 在磁碟中的位置。而 B 樹或其他的資料結構只是實現這個 Model 的一種方式，而這個 Model 也可以存在其他的實現形式，例如神經網路。

和 B 樹相比，神經網路具有很大的優勢：

1.由於不需要在記憶體中儲存 key，所以佔用記憶體空間極小。尤其當索引量巨大時，避免產生磁碟訪問。

2.由於避免了樹遍歷引入的條件判斷，查詢速度更快。

通過進行離線的模型訓練，犧牲一定的計算資源，可以達到節省記憶體資源，以及提高效能的效果。

當然，這種方法也存在一定的侷限性。其中最重要的一點，就是 Learned Index 只能索引固定資料分佈的資料。當有資料插入時導致資料分佈發生了變更，原有的模型就會失效。解決的方案是對於新增的資料，依然採用傳統的資料結構進行索引，Learned Index 只負責索引原有資料。當新增資料積累到一定程度時，將新資料與原有資料進行合併，並根據新的資料分佈訓練出新的模型。這種方法是很可行的，畢竟和新增資料量相比，全量資料是非常大的。如果能對全量資料的索引進行優化，那應用價值也是巨大的。

儘管存在一定的侷限性，Learned Index 還是有很多適用的場景，例如 Google 已經將其應用在了 BigTable 中。相信 Learned Index 只是一個開端，未來會有越來越多的 System 和 Machine Learning 結合的工作出現。

LSM-Tree 優化

LSM-Tree 是 LevelDB，以及 LevelDB 的變種，RocksDB，HyperDB 等單機儲存引擎的核心資料結構。

LSM-Tree 本身的原理我們不過多介紹。目前 LSM-Tree 最大的痛點是讀寫放大，這使得效能往往只能提供裸硬體的不到 10%。所以關於解決 LSM-Tree 讀寫放大問題成為近些年研究的熱點。

在 2016 年 FAST 會議上發表的論文 WiscKey 提出了將 Key 與 Value 分開存放的方法。傳統 LSM-Tree 將 Key 和 Value 相鄰存放，保證 Key 和 Value 在磁碟上都是有序的。這提高了 Range Query 的效率。然而，當進行 Compaction 時，由於需要同時操作 Key 和 Value，所以造成了較大讀寫比例放大。而在 WiscKey 中，通過將 Key 和 Value 分開存放，Key 保持 LSM-Tree 結構，保證 Key 在磁碟上的有序性，而 Value 使用所謂 『Value Log』 結構，很像 Log-Structured File System 中的一個 Segment。通過在 Key 中儲存 Value 在磁碟上的位置，使得可以通過 Key 讀取到 Value。由於 LSM-Tree 中只儲存 Key，不儲存 Value，且 Key 的大小通常遠小於 Value 的大小，所以 WiscKey 中的 LSM-Tree 的大小遠小於傳統  LSM-Tree 的大小，因此 Compaction 引入的讀寫放大可以控制在非常小的比例。WiscKey 的缺點是犧牲了 Range Query 的效能。由於相鄰 Key 的 Value 在磁碟上並沒有存在相鄰的位置，WiscKey 中對連續的 Key 讀取被轉化成隨機磁碟讀取操作。而作者通過將預讀（Prefetching）IO 並行化的方式，儘可能降低對順序讀效能的影響。

而在 2017 年 SOSP 上發表的論文 PebblesDB 提出了另外一種思路。在傳統 LSM-Tree 中，每一層由多個 SSTable 組成，每一個 SSTable 中儲存了一組排好序 Key-Value，相同層的 SSTable 之間的 Key 沒有重疊。當進行 Compaction 時，上層的 SSTable 需要與下層的 SSTable 進行合併，也就是將上層的 SSTable 和下層的 SSTable 讀取到記憶體中，進行合併排序後，組成新的 SSTable，並寫回到磁碟中。由於 Compaction 的過程中需要讀取和寫入下層的 SSTable，所以造成了讀寫放大，影響應能。

PebblesDB 將 LSM-Tree 和 Skip-List 資料結構進行結合。在 LSM-Tree 中每一層引入 Guard 概念。 每一層中包含多個 Guard，Guard 和 Guard 之間的 Key 的範圍是有序的，且沒有重疊，但 Guard 內部包含多個 SSTable，這些 SSTable 的 Key 的範圍允許重疊。

當需要進行 Compaction 時，只需要將上層的 SSTable 讀入記憶體，並按照下層的 Guard 將 SSTable 切分成多個新的 SSTable，並存放到下層對應的 Guard 中。在這個過程中不需要讀取下層的 SSTable，也就在一定程度上避免了讀寫放大。作者將這種資料結構命名為 Fragemented Log-Structured Tree（FLSM）。PebblesDB 最多可以減低 6.7 倍的寫放大，寫入效能最多提升 105%。

和 WiscKey 類似，PebblesDB 也會多 Range Query 的效能造成影響。這是由於 Guard 內部的 SSTable 的 Key 存在重疊，所以在讀取連續的 Key 時，需要同時讀取 Guard 中所有的 SSTable，才能夠獲得正確的結果。

WiscKey 和 PebblesDB 都已經開源，但在目前最主流的單機儲存引擎 LevelDB 和 RocksDB 中，相關優化還並沒有得到體現。我們也期待未來能有更多的關於 LSM-Tree 相關的優化演算法出現。

Crash Consistency

Crash Consistency 的意思是，儲存系統可以在故障發生後，保證系統資料的正確性以及資料，元資料的一致性。可以說 Crash Consistency 是儲存領域永恆不變的話題。

早些年大家熱衷於通過各種方法在已實現的檔案系統中尋找 Bug，而這兩年構造一個新的 Bug Free 的檔案系統成為熱門的方向。在這方面最早做出突破的是 MIT 的團隊的 FSCQ。FSCQ 通過 Coq 作為輔助的形式化驗證工具，在 Crash Hoare Logic 的基礎上，實現了一個被證明過 Crash Safty 的檔案系統。

然而使用 Coq 的代價是需要人工手動完成證明過程，這使得完成一個檔案系統的工作量被放大了幾倍，例如 FSCQ 的證明過程花費了 1.5 年。

而 Washington 大學提出的 Yggdrasil 則基於 Z3，將檔案系統證明過程自動化，也就是最近非常流行的『Push-Button Verification』 的方法。

值得注意的是，無論是 FSCQ 還是 Yggdrasil 都存在著巨大的侷限性，例如不支援多執行緒訪問，檔案系統功能並不完備，效能較弱，以及程式碼生成過程中依賴一些沒有被驗證過的工具等等。我們距離構建一個在通用場景下可以完全替代已有檔案系統（如 ext4）還有很長的路要走。這也依賴於形式化驗證方面的技術突破。

工業界進展

隨著虛擬化技術的成熟和普及，儲存的接入端逐漸從 HBA 卡或傳統作業系統，轉變為 Hypervisor。在 Linux KVM 方面，隨著儲存效能逐漸提高，原有的 virtio 架構逐漸成為了效能瓶頸，vhost 逐漸開始普及。所謂 vhost 就是把原有 Qemu 對於 IO 裝置模擬的程式碼放到了 Kernel 中，包含了 vhost-blk，以及 vhost-net。由 Kernel 直接將 IO 請求發給裝置。通過減少上下文的切換，避免額外的效能開銷。

在容器方面，隨著 K8S 的應用和成熟，在 K8S 的儲存方面也誕生了一些新的專案。比如 rook.io 是基於 K8S 的編排工具。而 K8S 本身也釋出了 Container Storage Interface（CSI），用於第三方儲存廠商更好的開發 K8S 的儲存外掛。未來也會看到越來越多的儲存廠商對 K8S 進行支援。

2017 年 Linux Kernel 共釋出了 5 個版本，從 4.10 到 4.14，目前最新的版本是 4.15。其中儲存相關比較值得注意的變化包括：AIO 改進，Block Layer 錯誤處理改進，基於 MQ 的排程器 Kyber 等等。然而比較悲傷的訊息是，為了修復 Meltdown 和 Spectrue 漏洞，Kernel 引入了 Kernel Page Table Isolation（KPTI）技術，這導致系統呼叫和上下文切換的開銷變得更大。Brendan Gregg 在他的部落格中詳細分析了 KPTI 對效能產生的影響。對於系統呼叫與上下文切換越頻繁的應用，對效能的影響越大。也就是說，IO 密集型的應用將受到比較大的影響，而計算密集型的應用則影響不大。

在企業級儲存方面，去年有很多儲存廠商都開始向純軟體廠商進行轉型，包括 Nutanix，Kaminario 以及 E8 等等。向軟體化轉型並不是處於技術的原因，而是商業的考慮。考慮到 Dell 和 EMC 的合併，儲存硬體的利潤率必定會不斷下降。軟體化最大的好處，就是可以提升財務報表中的利潤率，使得公司的財務狀況更加健康，也避免了和 Dell EMC 的儲存硬體發生競爭。

在資本市場方面，2017 年可以說是波瀾不驚。上圖是 2017 年儲存行業發生的併購案。其中 Toshiba Memory 被收購的案件是儲存行業歷史上第三大收購案（第一名是 Dell 收購 EMC）。

總結

以上是作者對當前儲存熱點和趨勢的不完整的總結。希望幫助讀者對儲存領域增加一點點了解，或者是對儲存技術產生一點點的興趣。也歡迎大家把自己感興趣的話題寫在評論裡，我們將在後面儘可能的為大家進行介紹。

順便廣告一下，SmartX 是全球技術領先的分散式儲存廠商，如果想在儲存領域做出一番事業的話，歡迎加入 SmartX。

-END-

↓戳原文，進入 SmartX 知乎技術專欄。