背景
HDFS 是 Hadoop 生態的預設儲存系統，很多資料分析和管理工具都是基於它的 API 設計和實現的。但 HDFS 是為傳統機房設計的，在雲上維護 HDFS 一點也不輕鬆，需要投入不少人力進行監控、調優、擴容、故障恢復等一系列事情，而且還費用高昂，成本可能是物件儲存是十倍以上。
在儲存與計算分離大趨勢下，很多人嘗試用物件儲存來構建資料湖方案，物件儲存也提供了用於 Hadoop 生態的 connector，但因為物件儲存自身的侷限性，功能和效能都非常有限，在資料增長到一定規模後這些問題更加突出。
JuiceFS 正是為了解決這些問題而設計的，在保留物件儲存的雲原生特點的同時，更好地相容 HDFS 的語義和功能，顯著提升整體效能。本文以阿里雲 OSS 為例，給大家介紹一下 JuiceFS 是如何全面提升物件儲存在雲上大資料場景中的表現的。
後設資料效能
為了完整相容 HDFS 並提供極致的後設資料效能，JuiceFS 使用全記憶體的方式來管理後設資料，將 OSS 作為資料儲存使用，所有的後設資料操作都不需要訪問 OSS 以保證極致的效能和一致性。絕大部分後設資料操作的響應時間都在 1ms 以內，而 OSS 通常要幾十到一百毫秒以上。下面是使用 NNBench 進行後設資料壓測的結果：
上圖中的 rename 操作還只是針對單個檔案的，因為它要拷貝資料所以很慢。在大資料實際的任務中通常是對目錄做重新命名，OSS 是 O(N) 複雜度，會隨著目錄裡檔案數量的增多顯著變慢，而 JuiceFS 的 rename 的複雜度是 O(1) 的, 只是伺服器端的一個原子操作，不管目錄多大都可以一直這麼快。
類似的還有 du 操作，它是要看一個目錄裡所有檔案的總大小，在管理容量或者瞭解資料規模時非常有用。 下圖是對一個 100GB 資料（包含3949個子目錄和檔案）的目錄做 du 的時間對比，JuiceFS 比 OSS 快 76倍！這是因為 JuiceFS 的 du 是基於伺服器端記憶體中實時統計好的大小即時返回的，而 OSS 需要通過客戶端遍歷目錄下的所有檔案再累加求和，如果目錄下的檔案更多的話，效能差距會更大。
順序讀寫效能
大資料場景有很多原始資料是以文字格式儲存的，資料以追加方式寫入，讀取以順序讀為主（或者是順序讀其中一個分塊）。在訪問這類檔案時，吞吐能力是一個關鍵指標。為了能夠更好地支援這樣的場景，JuiceFS 會先將它們切割成 64MB 的邏輯 Chunk，再分割成 4MB（可配置）的資料塊寫入物件儲存，這樣可以併發讀寫多個資料塊以提升吞吐量。OSS 也支援分塊上傳，但有分塊大小和分塊數量的限制，而 JuiceFS 沒有這些限制，單個檔案可達 256PB。
同時，這類文字格式的檔案還非常容易被壓縮，JuiceFS 內建的 LZ4 或者 ZStandard 壓縮演算法可以在並行讀寫的同時進行壓縮/解壓縮，不但可以降低儲存成本，還能減少網路流量，進一步提升順序讀寫的效能。對於已經被壓縮過的資料，這兩個演算法也能自動識別，避免重複的壓縮。
再結合 JuiceFS 的智慧預讀和回寫演算法，很容易充分利用網路頻寬和多核 CPU 的能力，將文字檔案的處理效能推向極致。下圖是單執行緒順序 I/O 效能測試結果，顯示了 JuiceFS 對大檔案（使用不能被壓縮的隨機資料）的讀寫提速是非常顯著的。
隨機讀效能
對於分析型數倉，通常會將原始資料經過清洗後使用更為高效的列存格式（Parquet 或者 ORC）來儲存，一方面大幅節省儲存空間，還能顯著提升分析的速度。這些列存格式的資料，在訪問模式上跟文字格式很不一樣，以隨機讀居多，對儲存系統的綜合效能有更高的要求。
JuiceFS 針對這些列存格式檔案的訪問特點做了很多優化，將資料分塊快取到計算節點的 SSD 盤上是其中最核心的一點。為了保證快取資料的正確性，JuiceFS 對所有寫入的資料都使用唯一的 ID 來標識 OSS 中的資料塊，並且永不修改，這樣快取的資料就不需要失效，只在空間不足時按照 LRU 演算法清理即可。Parquet 和 ORC 檔案通常只有區域性列是熱點，快取整個檔案或者一個 64MB 的 Chunk 會浪費空間，JuiceFS 採取的是以 1MB 分塊（可配置）為單位的快取機制。
計算叢集中通常只會有一個快取副本，通過一致性雜湊演算法來決定快取的位置，並利用排程框架的本地優化機制來將計算任務排程到有資料快取的節點，達到跟 HDFS 的資料本地化一樣甚至更好的效果，因為 HDFS 的三個副本通常是隨機排程的，作業系統頁快取的利用率會比較低，JuiceFS 的資料快取會盡量排程到同一個節點，系統頁快取的利用率會更高。
當排程系統不能做本地化排程時，比如 SparkSQL 在讀小檔案時，會隨機地把多個小檔案合併到同一個任務中，就喪失了本地化特性，即使使用 HDFS 也是如此。JuiceFS 的分散式快取很好地解決了這個問題，當計算任務未能排程到快取所在節點時，JuiceFS 客戶端會通過內部的 P2P 機制來訪問快取的資料，大幅提高快取命中率和效能。
我們選取查詢時間比較有代表性的 q2 來測試不同分塊大小和快取設定情況的加速效果：
當沒有啟用快取時，使用 1MB 的分塊比 4MB 的分塊效能更好，因為 4MB 的分塊會產生更多的讀放大，導致隨機讀變慢，也會浪費很多網路頻寬導致網路擁堵。
啟用快取後，Spark 可以直接從快取的資料塊上做隨機讀，大大的提高了隨機讀效能。因為 SparkSQL 會將小檔案隨機合併到一個任務中，導致大部分檔案沒辦法排程到有快取的那個節點，快取命中率很低，部分未命中快取的讀請求只能讀物件儲存，嚴重拖慢了整個任務。
在啟用了分散式快取後，不管計算任務排程到哪，JuiceFS 客戶端都能夠通過固定的節點讀到快取的速度，快取命中率非常高，速度也非常快（通常第二次查詢就能獲得顯著加速效果）。
JuiceFS 還支援隨機寫，但大資料場景不需要這個能力，OSS 也不支援，就不做對比了。
綜合效能
TPC-DS 是大資料分析場景的典型測試集，我們用它來測試一下 JuiceFS 對 OSS 的效能提升效果，包括不同資料格式和不同分析引擎。
測試環境
我們在阿里雲上使用 CDH 5.16 （估計是使用最為廣泛的版本）搭建了一個叢集，詳細配置和軟體版本如下：
Apache Spark 2.4.0.cloudera2
Apache Impala 2.12
Presto 0.234
OSS-Java-SDK 3.4.1
JuiceFS Hadoop SDK 0.6-beta
Master: 4 CPU 32G 記憶體，1臺
Slave: 4 CPU 16G 記憶體，200G 高效雲盤 x 2，3臺
Spark 引數：
master yarn
driver-memory 3g
executor-memory 9g
executor-cores 3
num-executors 3
spark.locality.wait 100
spark.dynamicAllocation.enabled false
測試資料集使用 100GB 的 TPC-DS 資料集，多種儲存格式和引數。完整跑完 99 條測試語句需要太多時間，我們選取了前面 10 條語句作為代表，已經包括各種型別的查詢。
寫入效能
通過讀寫同一張表來測試寫入效能，使用的 SQL 語句是：
INSERT OVERWRITE store_sales SELECT * FROM store_sales;
我們對比了未分割槽的文字格式和按日期分割槽的 Parquet 格式，JuiceFS 都有顯著效能提升，尤其是分割槽的 Parquet 格式。通過分析發現，OSS 花了很多時間在 Rename 上，它需要拷貝資料，還不能併發，而 Rename 在 JuiceFS 裡是一個原子操作，瞬間完成。
SparkSQL 查詢效能
Apache Spark 的使用非常廣泛，我們使用 SparkSQL 來測試文字、Parquet 和 ORC 這 3 種檔案格式下 JuiceFS 的提速效果，其中文字格式是未分割槽的，Parquet 和 ORC 格式是按照日期分割槽的。
對於未分割槽的文字格式，需要掃描全部文字資料，主要瓶頸在 CPU，JuiceFS 的提速效果有限，最高能提升 3 倍。需要注意的是，如果使用 HTTPS 訪問 OSS，Java 的 TLS 庫比 JuiceFS 使用的 Go 的 TLS 庫慢很多，同時 JuiceFS 對資料做了壓縮，網路流量也會小很多，因此在兩者都啟用 HTTPS 來訪問 OSS 時，JuiceFS 效果更好。
上圖說明了在使用 HTTPS 的情況下，JuiceFS 的效能幾乎沒有變化，而 OSS 卻下降很多。
對於互動式查詢，經常要對熱點資料做反覆查詢的，上圖是同一個查詢重複 3 次後的結果，JuiceFS 依靠快取的熱點資料大幅提升效能，10 個查詢中的 8 個有幾倍的效能提升，提升幅度最少的 q4 也提升了 30%。
對 ORC 格式的資料集的提速效果跟 Parquet 格式類似，最高提速 11 倍，最少提速 40%。
對所有的資料格式，JuiceFS 都能顯著提升 OSS 的查詢效能，最高超過 10 倍。
Impala 查詢效能
Impala 是效能非常好的互動分析引擎，對 I/O 本地化和 I/O 排程有非常好的優化，不需要使用 JuiceFS 的分散式快取就能夠獲得很好的效果：為 OSS 提速 42倍！
Presto 是與 Impala 類似的查詢引擎，但因為測試環境下配置的 OSS 不能跟 Presto 工作（原因未知），JuiceFS 沒辦法與 OSS 做比較。
總結
彙總上面的測試結果，JuiceFS 在所有場景中都能為 OSS 顯著提速，當儲存格式為 Parquet 和 ORC 這類列存格式時提速尤為明顯，寫入提升 8 倍，查詢提升可達 10 倍以上。這顯著的效能提升，不但節省了資料分析人員的寶貴時間，還能大幅減少計算資源的使用，降低成本。
以上只是以阿里雲的 OSS 為例項做了效能對比，JuiceFS 的提速能力適用於所有云的物件儲存，包括亞馬遜的 S3、谷歌雲的 GCS、騰訊雲的 COS 等，也包括各種私有云或者自研的物件儲存，JuiceFS 能顯著提升它們在資料湖場景下的效能。此外，JuiceFS 還提供了更好的 Hadoop 相容性（比如許可權控制、快照等）和完整的 POSIX 訪問能力，是雲上資料湖的理想選擇。
如有幫助的話歡迎關注我們專案 Juicedata/JuiceFS 喲！ (0ᴗ0✿)