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服务
• 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模式支持不同的存储策略，适配用户不同的应用场景。默认的是WARM的策略，a) WARM:此为默认策略，数据在OSS和本地分别有一个备份，本地备份能够有效的提供后续的读取加速，OSS备份起到高可用的作用；b) COLD:数据仅有一个备份存在 OSS 上，没有本地备份，适用于冷数据存储；c) HOT:数据在 OSS 上一个备份，本地多个备份，针对一些最热的数据提供更进一步的加速效果；d) TEMP:数据仅有一个本地备份，针对一些临时性数据，提供高性能的读写，但牺牲了数据的高可靠性，适用于一些临时数据的存取。
对比HDFS， JindoFS的Block 模式具有以下优势：
• Cache模式
对比OssFS， JindoFS的Cache模式提供以下优势：
外部客户端提供用户在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带来端到端的性能提升。