JindoFS: 云上大数据的高性能数据湖存储方案

本场视频链接：

https://developer.aliyun.com/live/1546?spm=a2c6h.12873639.0.0.7dcd359fhRnsQ8&groupCode=apachespark

ppt观看：

https://www.slidestalk.com/AliSpark/0761944

点击文末‘阅读原文’可直达链接

---

EMR JindoFS背景

计算存储分离已经成为云计算的一种发展趋势。在计算存储分离之前，普遍采用的是传统的计算存储相互融合的架构（下图左侧），但是这种架构存在一定的问题，比如在集群扩容的时候会面临计算能力和存储能力相互不匹配的问题。用户在某些情况下只需要扩容计算能力或者存储能力，而传统的融合架构不能满足用户的这种需求，进行单独的扩充计算或者存储能力；其次在缩容的时候可能会遇到人工干预，人工干预完后需要保证数据在多个节点中同步，而当有多个副本需要同步时候，可能会造成的数据丢失。而计算存储分离架构（下图右侧）则可以很好的解决这些问题，使得用户只需要关心整个集群的计算能力。

EMR现有的计算存储分离方案是基于OSS开发的提供兼容Hadoop文件系统的OssFS。其具备海量存储的能力，用户无需担心存储容量无法满足业务需求；另外由于OssFS可以访问OSS上的数据，因此也保留了OSS的一些优势，比如成本低、高可靠等。但是OssFS也存在一些缺点，比如任务结束后可能会将数据移动到最终的目录，该过程中文件移动以及重命名操作慢，这主要是由于在OSS系统上模拟了文件系统的语义，文件系统对象存储不支持重命名或移动的原子操作；OSS是一个公有云服务，其带宽会受到限制；高频访问的数据消耗过多的OSS带宽。相比之下，JindoFS在保留OssFS的优势的基础上，克服了前面提到的这些问题。

EMR JindoFS介绍

1) 架构简介

EMR JindoFS的整体架构如下图所示，主要包含部分：Namespace服务和Storage服务。Namespace服务主要负责JindoFS 元数据管理以及 Storage服务的管理，而Storage服务主要负责用户数据的管理（本地数据和远程OSS数据）。EMR JindoFS是一个云原生的文件系统，它可以提供本地存储的性能以及OSS的超大容量。

• Namespace服务
Namespace服务是JindoFS的中心服务，主要负责管理用户的元数据，包括JindoFS 本身文件系统的元数据、切分的Block的元数据以及 Storage服务的元数据。JindoFS Namespace服务可以支持多个Namespace，用户可以根据不同的业务划分不同的Namespace，不同的Namespace存放不同业务数据，不相互干扰。Namespace不设置全局大锁，可以基于目录级别实现并发控制，进行并发创建和并发删除。此外Namespace可以设置不同后端存储，现阶段主要支持RocksDB和阿里云OTS，OTS支持预计在下个版本发布，其好处是如果在EMR中创建自己的集群，采用OTS作为数据后端，本地EMR集群可以随时销毁，集群在创建的时候，JindoFS的数据仍然可以访问，这增加了用户使用的灵活性。

• Storage 服务
Storage 服务主要用来管理集群本地磁盘的数据，本地缓存的数据以及OSS数据。其目前可以支持不同的存储后端以及存储介质，存储后端现阶段主要支持本地文件系统以及OSS， 本地存储系统可以支持HDD/SSD/DCPM等存储介质，用以提供缓存加速，另外Storage 服务针对用户的小文件较多的场景进行优化，避免过多的小文件给本地文件系统带来过大的压力造成整体性能的下降。

在整个生态方面，JindoFS 目前支持所有大数据组件，包括Hadoop、Hive、Spark、Flink、Impala、Presto和HBase等， 用户访问EMR JindoFS时，只要替换文件访问路径的模式为jfs即可。另外在机器学习方面下个版本JindoFS将会推出Python SDK，方便机器学习用户可以高效率的访问JindoFS上的数据。EMR JindoFS还与EMR Spark实现了高度集成优化，比如集成Relational Cache、基于Spark的物化视图以及Cube的优化等。

EMR Jindo使用模式

EMR-Jindo使用模式主要有两种：Block模式和Cache模式。
• Block模式
Block模式将JindoFS的文件切分的Block的形式存放本地磁盘以及OSS上，用户通过OSS 只能看到Block的数据，该模式非常依赖于本地的Namespace的文件系统，本地的Namespace服务负责管理元数据，通过本地元数据以及Block数据构建出文件数据。相对于后一种模式来讲，该模式下JindoFS的性能是最佳的，Block模式适用于用户对数据以及元数据有一定性能要求的场景，Block模式需要用户将数据迁移到JindoFS。

Block模式支持不同的存储策略，适配用户不同的应用场景。默认的是WARM的策略，
a) WARM:此为默认策略，数据在OSS和本地分别有一个备份，本地备份能够有效的提供后续的读取加速，OSS备份起到高可用的作用；
b) COLD:数据仅有一个备份存在 OSS 上，没有本地备份，适用于冷数据存储；
c) HOT:数据在 OSS 上一个备份，本地多个备份，针对一些最热的数据提供更进一步的加速效果；
d) TEMP:数据仅有一个本地备份，针对一些临时性数据，提供高性能的读写，但牺牲了数据的高可靠性，适用于一些临时数据的存取。

对比HDFS， JindoFS的Block 模式具有以下优势：
a) 利用OSS 的廉价和无限容量，具备成本以及容量的优势；
b) 冷热数据自动分离，计算透明，冷热数据自动迁移的时候逻辑位置不变，无须修改表元数据 location 信息；
c) 维护简单，无须decommission，节点坏掉就去掉，数据OSS上有，不会丢失；
d) 系统快速升级/重启/恢复，没有block report；
e) 原生支持小文件，避免小文件过程造成文件系统过大的压力。

• Cache模式
与Block模式不同的是，Cache模式将JindoFS文件以对象的形式存储在OSS上。该模式兼容现有的OSS文件系统，用户可以通过OSS访问原有的目录结构以及文件，同时该模式提供数据以及元数据的缓存，加速用户的读写数据的性能。使用该模式的用户无需迁移数据到OSS，可以无缝对接现有OSS上的数据，但是性能相对Block模式有一定的性能损失。在元数据同步方面用户可以根据不同的需求选择不同的元数据同步策略。

对比OssFS， JindoFS的Cache模式提供以下优势：
a) 由于本地备份存在，读写吞吐与HDFS相当；
b) 能够支持全部 HDFS接口，支持更多的场景，如Delta Lake，支持 HBase on JindoFS；
c) JindoFS作为数据以及元数据的缓存，用户在读写数据以及List/Status操作相对OssFS有性能提升；
d) JindoFS作为数据缓存，可以加速用户的数据读写。

外部客户端提供用户在EMR 集群外访问 JindoFS的一种方式，现阶段该客户端只支持JindoFS的Block模式，客户端的权限与OSS 权限绑定，用户需要有相应OSS的权限才能够通过外部客户端访问JindoFS的数据。

EMR JindoFS + DCPM性能

下面分享一下如何用Intel新的硬件Optane DC persistent memory来加速EMR JindoFS。下图展示了英特尔傲腾数据中心级可持久化内存的典型使用场景，从最底层的存储层开始，在RDMA/Replication的场景下，使用新的存储介质可以达到更高的I/O性能；在基础设施层，密集型应用创建更多实例的需求下，高容量的可持久化内存是一个比较好的解决方案；数据库层特别是IMDB，可以使用SAP HANA和Redis通过高容量的可持久化内存支持更多实例的创建;类似地，在AI和数据分析领域，可以使用低延迟的设备加速实时数据分析，比如SAS，使用Databricks来加速机器学习场景分析；此外在HPC和COMMS领域都可以用到可持久化内存。

使用DCPM加速EMR JindoFS的性能测试环境配置如下图所示。其中，Spark使用的是EMR Spark，其基于开源Spark 2.4.3版本做了很多改造，增加了很多新的特性，包括Relational Cache和JindoFS；可持久化内存使用方式是SoAD,其对于用户来讲是一个快设备；基准测试选用了三个层面，即Micro-benchmark、TPC-DS queries和Star Schema Benchmark。

EMR JindoFS使用DCPM后的性能测试结果显示：DCPM为小文件读带来显著性能提升，特别是在更大文件以及更多读进程场景下，性能提升更为明显；使用决策支持相关查询作为基准测试，2TB数据下，DCPM为99个查询执行带来1.53倍性能提升；同样在2TB数据下，DCPM为 SSB with spark relational cache带来总体2.7倍的性能提升。

下图为Micro-benchmark的性能测试结果，主要测试了不同文件大小（ 512K, 1M, 2M, 4M and 8M ）和不同并行度（1-10）下的100个小文件读操作，从图中可以看出DCPM为小文件读带来了性能的显著提高，文件越大，并行度越高，性能提升的也更明显。

下图是TPC-DS的测试结果，TPC-DS数据量为2TB，测试整个TPC-DS的99个查询。基于归一化时间，DCPM总体上带来了1.53倍的性能提升。具体分析性能提升的根源，如下图右侧两张子图所示，读操作内存带宽峰值是6.23GB/s，而写操作的峰值是2.64GB/s，而Spark中读的场景比较多，这也是性能提升的原因。

下图SSB在Spark Relational Cache + JindoFS 性能测试结果，其中SSB（星型基准测试）是基于TPC-H的针对星型数据库系统性能的测试基准。Relational Cache是EMR Spark支持的一个重要特性，主要通过对数据进行预组织和预计算加速数据分析，提供了类似传统数据仓库物化视图的功能。在SSB测试中，使用1TB数据来单独执行每个查询，并在每个查询之间清除系统cache。基于归一化时间，总体上DCPM 能带来2.7倍的性能提升。对于单个query，性能提升在1.9倍至3.4倍。总结一下就是通过DCPM新硬件，不仅可以解决I/O问题，还为JindoFS带来端到端的性能提升。

---

相关文章推荐：
JindoFS概述：云原生的大数据计算存储分离方案

JindoFS解析 - 云上大数据高性能数据湖存储方案

---

后续我们也会在云栖社区和钉钉群分享更多的 Jindo 技术干货，欢迎有兴趣的同学加入 【Apache Spark技术交流社区】进行交流和技术分享。