拥抱云原生,Fluid 结合 JindoFS:阿里云 OSS 加速利器
作者|?王濤(揚禮)、車漾(必嘫)
來源|阿里巴巴云原生公眾號
什么是?Fluid
Fluid?是一個開源的 Kubernetes 原生的分布式數據集編排和加速引擎,主要服務于云原生場景下的數據密集型應用,例如大數據應用、AI 應用等。通過 Kubernetes 服務提供的數據層抽象,可以讓數據像流體一樣在諸如 HDFS、OSS、Ceph 等存儲源和 Kubernetes 上層云原生應用計算之間靈活高效地移動、復制、驅逐、轉換和管理。而具體數據操作對用戶透明,用戶不必再擔心訪問遠端數據的效率、管理數據源的便捷性,以及如何幫助 Kuberntes 做出運維調度決策等問題。用戶只需以最自然的 Kubernetes 原生數據卷方式直接訪問抽象出來的數據,剩余任務和底層細節全部交給 Fluid 處理。
Fluid 項目當前主要關注數據集編排和應用編排這兩個重要場景。數據集編排可以將指定數據集的數據緩存到指定特性的 Kubernetes 節點,而應用編排將指定該應用調度到可以或已經存儲了指定數據集的節點上。這兩者還可以組合形成協同編排場景,即協同考慮數據集和應用需求進行節點資源調度。
然后介紹 Fluid 中 Dataset 的概念,數據集是邏輯上相關的一組數據的集合,會被運算引擎使用,比如大數據的 Spark,AI 場景的 TensorFlow,而關于數據集智能的應用和調度會創造工業界的核心價值。Dataset 的管理實際上也有多個維度,比如安全性,版本管理和數據加速。
我們希望從數據加速出發,對于數據集的管理提供支持。在 Dataset 上面,我們通過定義 Runtime 這樣一個執行引擎來實現數據集安全性,版本管理和數據加速等能力,Runtime 定義了一系列生命周期的接口,可以通過實現這些接口來支持數據集的管理和加速,目前 Fluid 中支持的 Runtime 有 AlluxioRuntime 和 JindoRuntime 兩種。Fluid 的目標是為 AI 與大數據云原生應用提供一層高效便捷的數據抽象,將數據從存儲抽象出來從而達到如下功能:
-
通過數據親和性調度和分布式緩存引擎加速,實現數據和計算之間的融合,從而加速計算對數據的訪問。
-
將數據獨立于存儲進行管理,并且通過 Kubernetes 的命名空間進行資源隔離,實現數據的安全隔離。
-
將來自不同存儲的數據聯合起來進行運算,從而有機會打破不同存儲的差異性帶來的數據孤島效應。
什么是 JindoRuntime
如果要了解 Fluid 的 JindoRuntime,先要介紹 JindoFS。它是 JindoRuntime 的引擎層。
JindoFS 是阿里云針對 OSS 開發的自研大數據存儲優化引擎,完全兼容 Hadoop 文件系統接口,給客戶帶來更加靈活、高效的計算存儲方案,目前已驗證支持阿里云 EMR 中所有的計算服務和引擎:Spark、Flink、Hive、MapReduce、Presto、Impala 等。JindoFS 有兩種使用模式,塊存儲(Block)模式和緩存(Cache)模式。Block 模式將文件內容以數據塊的形式存放在 OSS 上并在本地可選擇使用數據備份來進行緩存加速,使用本地的 namespace 服務管理元數據,從而通過本地元數據以及塊數據構建出文件數據。Cache 模式將文件存儲在 OSS 上,該模式兼容現有的 OSS 文件系統,用戶可以通過 OSS 訪問原有的目錄結構以及文件,同時該模式提供數據以及元數據的緩存,加速用戶讀寫數據的性能。使用該模式的用戶無需遷移數據到 OSS,可以無縫對接現有 OSS 上的數據,在元數據同步方面用戶可以根據不同的需求選擇不同的元數據同步策略。
在 Fluid 中,JindoRuntime 也是使用 JindoFS 的 Cache 模式進行遠端文件的訪問和緩存,如您需要在其他環境單獨使用 JindoFS 獲得訪問 OSS 的能力,您也可以下載我們的 JindoFS SDK?按照使用文檔進行部署使用。JindoRuntime 來源于阿里云 EMR 團隊自研 JindoFS 分布式系統,是支撐 Dataset 數據管理和緩存的執行引擎實現。Fluid 通過管理和調度 Jindo Runtime 實現數據集的可見性、彈性伸縮、數據遷移、計算加速等。在 Fluid 上使用和部署 JindoRuntime 流程簡單、兼容原生 K8s 環境、可以開箱即用。深度結合對象存儲特性,使用 Navite 框架優化性能,并支持免密、checksum 校驗等云上數據安全功能。
JindoRuntime 的優勢
JindoRuntime 提供對 Aliyun OSS 對象存儲服務的訪問和緩存加速能力,并且利用 FUSE 的 POSIX 文件系統接口實現可以像本地磁盤一樣輕松使用 OSS 上的海量文件,具有以下特點:
1. 性能卓越
-
OSS 的讀寫性能突出:深度結合 OSS 進行讀寫效率和穩定性的增強,通過 native 層優化對 OSS 訪問接口,優化冷數據訪問性能,特別是小文件讀寫。
-
分布式緩存策略豐富:支持單 TB 級大文件緩存、元數據緩存策略等。在大規模 AI 訓練和數據湖場景實測中有突出的性能優勢。
2. 安全可靠
-
認證安全:支持阿里云上 STS 免密訪問和 K8s 原生的秘鑰加密。
-
數據安全:checksum 校驗、客戶端數據加密等安全策略,保護云上數據安全和用戶信息等。
3. 簡單易用
支持原生 K8s 環境,利用自定義資源定義,對接數據卷概念。使用部署流程簡單,可以開箱即用。
4. 輕量級
底層基于 c++ 代碼,整體結構輕量化,各種 OSS 訪問接口額外開銷較小。
JindoRuntime 性能怎么樣
我們使用 ImageNet 數據集基于 Kubernetes 集群并使用 Arena 在此數據集上訓練 ResNet-50 模型,基于 JindoFS 的 JindoRuntime 在開啟本地緩存的情況下性能大幅度優于開源 OSSFS,訓練耗時縮短了 76%,該測試場景會在后續文章中進行詳細介紹。
如何快速上手使用 JindoRuntime
使用 JindoRuntime 流程簡單,在準備好基本 K8s 和 OSS 環境的條件下,您只需要耗費 10 分鐘左右時間即可部署好需要的 JindoRuntime 環境,您可以按照下面的流程進行部署。
- 創建命名空間
- **下載 **fluid-0.5.0.tgz
**
- 使用 Helm 安裝 Fluid
- 查看 Fluid 的運行狀態
其中 csi-nodeplugin-fluid-xx 的數量應該與 K8s 集群中節點 node 的數量相同。
- 創建 dataset 和 JindoRuntime
在創建 dataset 之前,我們可以創建一個 secret 來保存 OSS 的 fs.oss.accessKeyId 和 fs.oss.accessKeySecret 信息,避免明文暴露出來,K8s 會對已創建的 secret 使用加密編碼,將 key 和 secret 信息填入 mySecret.yaml 文件中。
apiVersion: v1 kind: Secret metadata:name: mysecret stringData:fs.oss.accessKeyId: xxxfs.oss.accessKeySecret: xxx生成 secret:
kubectl create -f mySecret.yaml創建一個 resource.yaml 文件里面包含兩部分:
首先包含數據集及 ufs 的 dataset 信息,創建一個 Dataset CRD 對象,其中描述了數據集的來源。
接下來需要創建一個 JindoRuntime,相當于啟動一個 JindoFS 的集群來提供緩存服務。
mountPoint:oss://<oss_bucket>/<bucket_dir> 表示掛載 UFS 的路徑,路徑中不需要包含 endpoint 信息。
fs.oss.endpoint:oss bucket 的 endpoint 信息,公網或內網地址皆可。
replicas:表示創建 JindoFS 集群的 worker 的數量。
mediumtype:JindoFS 暫只支持 HDD/SSD/MEM 中的一種。
path:存儲路徑,暫只支持一塊盤,當選擇 MEM 做緩存也需要一塊盤來存儲 log 等文件。
quota:緩存最大容量,單位 Gi。
high:水位上限大小 / low:水位下限大小。
查看 dataset 的情況:
$ kubectl get dataset hadoop NAME UFS TOTAL SIZE CACHED CACHE CAPACITY CACHED PERCENTAGE PHASE AGE hadoop 210MiB 0.00B 180.00GiB 0.0% Bound 1h- 創建應用容器體驗加速效果
您可以通過創建應用容器來使用 JindoFS 加速服務,或者進行提交機器學習作業來進行體驗相關功能。
接下來,我們創建一個應用容器 app.yaml 來使用該數據集,我們將多次訪問同一數據,并比較訪問時間來展示 JindoRuntime 的加速效果。
apiVersion: v1 kind: Pod metadata:name: demo-app spec:containers:- name: demoimage: nginxvolumeMounts:- mountPath: /dataname: hadoopvolumes:- name: hadooppersistentVolumeClaim:claimName: hadoop使用 kubectl 完成創建:
kubectl create -f app.yaml查看文件大小:
$ kubectl exec -it demo-app -- bash $ du -sh /data/hadoop/spark-3.0.1-bin-hadoop2.7.tgz 210M /data/hadoop/spark-3.0.1-bin-hadoop2.7.tgz進行文件的 cp 觀察時間消耗了 18s:
$ time cp /data/hadoop/spark-3.0.1-bin-hadoop2.7.tgz /dev/nullreal 0m18.386s user 0m0.002s sys 0m0.105s查看此時 dataset 的緩存情況,發現 210MB 的數據已經都緩存到了本地。
$ kubectl get dataset hadoop NAME UFS TOTAL SIZE CACHED CACHE CAPACITY CACHED PERCENTAGE PHASE AGE hadoop 210.00MiB 210.00MiB 180.00GiB 100.0% Bound 1h為了避免其他因素(比如 page cache)對結果造成影響,我們將刪除之前的容器,新建相同的應用,嘗試訪問同樣的文件。由于此時文件已經被 JindoFS 緩存,可以看到第二次訪問所需時間遠小于第一次。
kubectl delete -f app.yaml && kubectl create -f app.yaml進行文件的拷貝觀察時間,發現消耗 48ms,整個拷貝的時間縮短了 300 倍。
$ time cp /data/hadoop/spark-3.0.1-bin-hadoop2.7.tgz /dev/nullreal 0m0.048s user 0m0.001s sys 0m0.046s-
環境清理
-
刪除應用和應用容器
-
刪除 JindoRuntime
-
- 刪除 dataset
以上通過一個簡單的例子完成 JindoFS on Fluid 的入門體驗和理解,并最后進行環境的清理,更多 Fluid JindoRuntime 的功能使用后續文章會進行詳細介紹。
-
Fluid 項目 GitHub 地址:
https://github.com/fluid-cloudnative/fluid -
Fluid 項目主頁:
http://pasa-bigdata.nju.edu.cn/fluid/index.html -
社區交流釘群:
作者簡介
王濤,花名揚禮,阿里巴巴計算平臺事業部 EMR 開發工程師,目前從事開源大數據存儲計算方面的開發和優化工作。
**
車漾,花名必嘫,阿里巴巴云原生應用平臺高級技術專家,從事 Kubernetes 和容器相關產品的開發。尤其關注利用云原生技術構建機器學習平臺系統,是 GPU 共享調度的主要作者和維護者。
點擊訪問“Kubernetes與云原生應用更多開源實踐”大講堂,4 次開源技術直播, 60+ 節 Kubernetes 經典課程,3 本云原生電子書,將前沿的容器技術和開源實踐一網打盡!
總結
以上是生活随笔為你收集整理的拥抱云原生,Fluid 结合 JindoFS:阿里云 OSS 加速利器的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: seata-golang 接入指南
- 下一篇: Serverless 躁动背后的 5 大