為媒體資產構建一個雲原生的檔案系統

Netflix Drive: 為媒體資產構建一個雲原生的檔案系統

Netflix Drive是一個多介面、多OS的雲檔案系統，旨在為設計師的工作站提供典型的POSIX檔案系統和操作方式。

它還可以作為一個具有REST後端的微服務，內含很多工作流所使用的後端操作，以及無需使用者和應用與檔案和資料夾直接互動的自動化場景。REST後端和POSIX介面可以共存於任何Netflix Drive範例中，無需手動排除。

Netflix Drive框架中採用了事件告警後端。事件和告警是Netflix Drive的一等公民。

我們將Netflix Drive定義為通用框架，支援使用者選擇不同型別的資料和後設資料儲存。例如，可以使用DynamoD作為Netflix Drive的後設資料儲存，也可以使用MongoDB和Ceph Storage作為後端資料儲存和後設資料儲存。更多參見完整的視訊演示

譯自：Netflix Drive: Building a Cloud-Native Filesystem for Media Assets

為什麼構造Netflix Drive

總的來說，Netflix開創了雲娛樂工作室的概念，它允許全球的設計師共同共同作業。為此，Netflix需要提供一個分散式、可延伸的高效能基礎設施平臺。

在Netflix，資產指由不同的系統和服務儲存和管理的、包含資料和後設資料的一系列檔案和目錄。

從資料採集開始，即當攝像機記錄視訊(產生資料)，到資料變為電影和電視節目，這些資產會基於創作流程，被不同的系統打上各種後設資料標籤。

在邊緣(即使用資產的設計師)，設計師和他們的應用會希望使用一個介面來無縫存取這些檔案和目錄。當然，該工作流並不僅適用於設計師，也適用於工作室。一個最好的例子是，在使用Netflix Drive進行內容渲染的過程中會發生資產轉換。

工作室流程中需要在不同的創作迭代階段中轉移資產，每個階段都會給資產打上新的後設資料標籤。我們需要一個能夠在資料中新增不同形式的後設資料的系統。

我們還需要在每個階段中支援多種級別的動態存取控制，這樣就可以在平臺專案中限制特定應用、使用者或流程可以存取的資產子集。我們調研了AWS Storage Gateway，但其效能和安全性無法滿足我們的需求。

最後訴求於設計Netflix Drive來滿足多種場景的需求。該平臺可以作為一個簡單的POSIX檔案系統，將資料儲存到雲端或從雲端檢索資料，同時也可以包含豐富控制介面。它將成為支援大量Netflix工作室和平臺的基礎儲存設施的一部分。

Netflix Drive的架構

圖1展示了Netflix Drive的介面：

圖11：動態設定Netflix Drive名稱空間

更新內容

Netflix Drive上的POSIX介面可以支援open/close、move、read/write等檔案操作。

部分REST API可以修改檔案--例如，某個API可以暫存檔案，從雲端拉取檔案；某個API可以檢查檔案；某個API可以儲存檔案，顯示地將檔案上傳到雲端儲存。

圖12是展示瞭如何使用Publish API將檔案上傳到雲端。我們可以自動儲存檔案，定期檢查上傳到雲端的檔案，並進行顯示儲存(上傳到雲端)。顯式儲存可以是不同工作流釋出時呼叫的API。

圖12：Netflix Drive釋出API

使用不同APIs的一個典型例子是：當設計師大量使用臨時資料時。由於這類資料僅僅用於過程處理，而不是最終產品，因此大部分不需要上傳到雲端。對於這類工作流，應該使用顯示儲存，而非自動儲存，Google Drive就是這種模式。一旦設計師確定可以將資產共用給其他設計師或工作流，此時可以呼叫API將其上傳到雲端。API會在設計師的Netflix Drive掛載點對所選的檔案進行快照，將其上傳到雲端，並儲存到特定的名稱空間中。

經驗

在支援不同工作流中的多個角色使用Netflix Drive過程中，我們吸取了很多經驗。

檔案、工作流、設計師工作站的效能/延遲，以及我們希望為使用Netflix Drive的設計師提供的體驗，決定了架構的方方面面。我們使用C++實現了大部分程式碼。我們對比了程式語言，發現C++的效能最佳。沒有考慮使用Rust的原因是此時Rust在FUSE檔案系統的支援度還不夠成熟。

我們傾向於將Netflix Drive作為一個通用的框架，支援任何資料儲存和後設資料儲存。為某些作業系統設計通用框架是比較困難的。在調研過可替代方案後，我們決定讓Netflix Drive支援CentOS、macOS和Windows上的FUSE檔案系統。這增加了我們的測試矩陣和保障矩陣。

我們使用不同的後端，有不同的快取層和儲存層，並依賴快取的後設資料操作。Netflix Drive支援EB級別的資料以及十億級別的資產。可延伸性是架構的另一個考量點。我們通常認為，雲上的擴充套件解決方案的瓶頸是資料儲存，但最後發現後設資料儲存才是瓶頸。擴充套件的關鍵是處理後設資料。我們重點關注後設資料處理，並減少後設資料儲存的呼叫量。通過在本地快取大量資料可以提高工作室應用和工作流的效能，這些應用和工作流通常需要大量後設資料。

我們調研了雲檔案系統，如EFS，但使用檔案系統無法擴充套件掛載點，且會影響到效能。為了服務十億級別的資產，我們需要使用某種形式的物件儲存，而非檔案儲存。這意味著設計師的檔案將會被轉換為物件(檔案和物件作一對一對映)--這種方式過於簡單，但檔案大小可能超過支援的最大物件大小。我們希望將一個檔案對映成多個物件。如果設計師修改了檔案的某個畫素，Netflix Drive能夠只修改包含相關檔案塊的物件。構建轉換層是權衡之下的選擇，同時這種方式也提升了擴充套件性。

使用物件帶來的問題是去重和分塊。物件儲存使用版本控制：每次變更物件時，無論變更大小，都會建立一個新版本物件。因此，修改檔案的一個畫素會導致傳送整個檔案，並覆蓋原有物件。無法傳送並在雲端儲存中使用增量資料。通過將一個檔案分為多個物件，可以降低傳送到雲端的物件大小。選擇合適的塊大小與其說是一門科學，不如說是一門藝術，因為更小的塊意味著需要更多的資料以及轉換邏輯，並增加了後設資料量。另一個需要考慮的是加密。我們需要對每個塊進行加密，因此更小的塊會導致使用更多的加密金鑰以及後設資料加密。Netflix Drive的塊大小是可設定的。

多儲存層可以提升效能。當我們設計Netflix Drive時，並沒有限制僅使用本地儲存還是雲端儲存。我們希望將其構建為：可以方便地在框架中新增儲存層。該觀念貫穿整個設計、架構和程式碼。例如，我們的媒體快取僅僅是一個靠近使用者和應用的快取層。Netflix Drive在本地檔案儲存中快取了大量資料(Google Drive則不會這麼做)，因此可以較Google Drive可以更好的利用到本地檔案系統的效能。

還有一個不使用AWS Storage Gateway的原因。如果多個設計師共同操作一個資產，並將每次迭代的資產都儲存到雲端，這樣我們的雲開銷會爆炸。我們希望將這些資產儲存到靠近使用者的媒體快取中，並控制何時將最終拷貝傳送到雲端。我們可以利用這種混合基礎設施，以及AWS Storage Gateway提供的引數。

軟體架構採用堆疊式方法至關重要。一個很好的例子是使用共用名稱空間。我們目前正在開發支援不同工作站或名稱空間的檔案共用。我們將此構建在事件框架之上，並將其設計為Netflix Drive架構的一部分。當一個Netflix Drive範例上的使用者向一個名稱空間新增檔案時，它可以生成多個雲服務可能消費的事件。然後Netflix Drive使用REST介面將檔案注入存取該名稱空間的其他Netflix Drive範例中。

更多參見技術部落格.

總結

本文介紹了Netflix自研的檔案系統Netflix Drive。自研檔案系統的一個原因是現有云服務無法滿足業務場景，如多掛載點、使用本地快取、檔案切分等。

Netflix Drive通過使用本地快取，減少了雲端儲存的開銷(如通過快取減少了物件儲存API的呼叫次數)。