关于云计算:拥抱云原生Fluid-结合-JindoFS阿里云-OSS-加速利器

作者 | 王涛（扬礼）、车漾（必嘫）
起源 | 阿里巴巴云原生公众号

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 的命名空间进行资源隔离，实现数据的平安隔离。
将来自不同存储的数据联结起来进行运算，从而有机会突破不同存储的差异性带来的数据孤岛效应。

如果要理解 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 提供对 Aliyun OSS 对象存储服务的拜访和缓存减速能力，并且利用 FUSE 的 POSIX 文件系统接口实现能够像本地磁盘一样轻松应用 OSS 上的海量文件，具备以下特点：

OSS 的读写性能突出：深度联合 OSS 进行读写效率和稳定性的加强，通过 native 层优化对 OSS 拜访接口，优化冷数据拜访性能，特地是小文件读写。
分布式缓存策略丰盛：反对单 TB 级大文件缓存、元数据缓存策略等。在大规模 AI 训练和数据湖场景实测中有突出的性能劣势。

认证平安：反对阿里云上 STS 免密拜访和 K8s 原生的秘钥加密。
数据安全：checksum 校验、客户端数据加密等安全策略，爱护云上数据安全和用户信息等。

反对原生 K8s 环境，利用自定义资源定义，对接数据卷概念。应用部署流程简略，能够开箱即用。

底层基于 c++ 代码，整体构造轻量化，各种 OSS 拜访接口额定开销较小。

咱们应用 ImageNet 数据集基于 Kubernetes 集群并应用 Arena 在此数据集上训练 ResNet-50 模型，基于 JindoFS 的 JindoRuntime 在开启本地缓存的状况下性能大幅度优于开源 OSSFS，训练耗时缩短了 76%，该测试场景会在后续文章中进行具体介绍。

应用 JindoRuntime 流程简略，在筹备好根本 K8s 和 OSS 环境的条件下，您只须要消耗 10 分钟左右工夫即可部署好须要的 JindoRuntime 环境，您能够依照上面的流程进行部署。

创立命名空间

kubectl create ns fluid-system

下载 fluid-0.5.0.tgz

应用 Helm 装置 Fluid

helm install --set runtime.jindo.enabled=true fluid fluid-0.5.0.tgz

查看 Fluid 的运行状态

$ kubectl get pod -n fluid-system
NAME                                         READY   STATUS    RESTARTS   AGE
csi-nodeplugin-fluid-2mfcr                   2/2     Running   0          108s
csi-nodeplugin-fluid-l7lv6                   2/2     Running   0          108s
dataset-controller-5465c4bbf9-5ds5p          1/1     Running   0          108s
jindoruntime-controller-654fb74447-cldsv     1/1     Running   0          108s

其中 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: xxx
  fs.oss.accessKeySecret: xxx

生成 secret：

kubectl create -f mySecret.yaml

创立一个 resource.yaml 文件外面蕴含两局部：

首先蕴含数据集及 ufs 的 dataset 信息，创立一个 Dataset CRD 对象，其中形容了数据集的起源。
接下来须要创立一个 JindoRuntime，相当于启动一个 JindoFS 的集群来提供缓存服务。

apiVersion: data.fluid.io/v1alpha1
kind: Dataset
metadata:
  name: hadoop
spec:
  mounts:
    - mountPoint: oss://<oss_bucket>/<bucket_dir>
      options:
        fs.oss.endpoint: <oss_endpoint>  
      name: hadoop
      encryptOptions:
        - name: fs.oss.accessKeyId
          valueFrom:
            secretKeyRef:
              name: mysecret
              key: fs.oss.accessKeyId
        - name: fs.oss.accessKeySecret
          valueFrom:
            secretKeyRef:
              name: mysecret
              key: fs.oss.accessKeySecret
---
apiVersion: data.fluid.io/v1alpha1
kind: JindoRuntime
metadata:
  name: hadoop
spec:
  replicas: 2
  tieredstore:
    levels:
      - mediumtype: HDD
        path: /mnt/disk1
        quota: 100Gi
        high: "0.99"
        low: "0.8"

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：水位上限大小。

kubectl create -f resource.yaml

查看 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: demo
      image: nginx
      volumeMounts:
        - mountPath: /data
          name: hadoop
  volumes:
    - name: hadoop
      persistentVolumeClaim:
        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/null

real  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/null

real  0m0.048s
user  0m0.001s
sys 0m0.046s

环境清理
- 删除利用和利用容器
- 删除 JindoRuntime

kubectl delete jindoruntime hadoop

删除 dataset

kubectl delete dataset hadoop

以上通过一个简略的例子实现 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-加速利器

什么是 Fluid

什么是 JindoRuntime

JindoRuntime 的劣势

1. 性能卓越

2. 安全可靠

3. 简略易用

4. 轻量级

JindoRuntime 性能怎么样

如何疾速上手应用 JindoRuntime

**

作者简介

Just My Socks（注册教程内含优惠码）

关于云计算:拥抱云原生Fluid-结合-JindoFS阿里云-OSS-加速利器

什么是 Fluid

什么是 JindoRuntime

JindoRuntime 的劣势

1. 性能卓越

2. 安全可靠

3. 简略易用

4. 轻量级

JindoRuntime 性能怎么样

如何疾速上手应用 JindoRuntime

**

作者简介

Just My Socks（注册教程 内含优惠码）

Just My Socks（注册教程内含优惠码）