作者：诚历，阿里巴巴计算平台事业部 EMR 技术专家，Apache Sentry PMC，Apache Commons Committer，目前从事开源大数据存储和优化方面的工作。
JindoFS概述：云原生的大数据计算存储分离方案
JindoFS 之前
在 JindoFS 之前，云上客户主要使用 HDFS 和 OSS/S3 作为大数据存储。HDFS 是 Hadoop 原生的存储系统，10 年来，HDFS 已经成为大数据生态的存储标准，但是我们也可以看到 HDFS 虽然不断优化，但是 JVM 的瓶颈也始终无法突破，社区后来重新设计了 OZone。OSS/S3 作为云上对象存储的代表，也在大数据生态进行了适配，但是由于对象存储设计上的特点，元数据相关操作无法达到 HDFS 一样的效率；对象存储给客户的带宽不断增加，但是也是有限的，一些时候较难完全满足用户大数据使用上的需求。
Jindo 的由来
EMR Jindo 是阿里云基于 Apache Spark / Apache Hadoop 在云上定制的分布式计算和存储引擎。Jindo 原是内部的研发代号，取自筋斗(云)的谐音，EMR Jindo 在开源基础上做了大量优化和扩展，深度集成和连接了众多阿里云基础服务。阿里云 EMR (E-MapReduce) 在 TPC 官方提交的 TPCDS 成绩，也是使用 Jindo 提交的。
http://www.tpc.org/tpcds/results/tpcds_perf_results.asp?resulttype=all
JindoFS
EMR Jindo 有计算和存储两大部分，存储的部分叫 JindoFS。JindoFS 是阿里云针对云上存储定制的自研大数据存储服务，完全兼容 Hadoop 文件系统接口，给客户带来更加灵活、高效的计算存储方案，目前已验证支持阿里云 EMR 中所有的计算服务和引擎：Spark、Flink、Hive、MapReduce、Presto、Impala 等。Jindo FS 有两种使用模式，块存储模式和缓存模式。下面我们来分析下，JindoFS 是如何来解决大数据上的存储问题的。
块存储模式
计算和存储分离是业界的趋势，OSS 这样的云上存储能力是无限大的，成本上非常有优势，如何利用 OSS 提供的无限存储能力，同时又高效地操作文件系统的元数据。JindoFS 块存储模式提供了一套完整的云原生解决方案。
JindoFS 的块存储模式，在元数据上使用 JindoNameService 服务管理 Jindo 文件系统元数据，元数据操作的性能和体验上可以对标 HDFS NameNode。同时，JindoStorageService 保障了数据可以始终有一份存在 OSS 上，即使数据节点被释放，数据也可以随时从 OSS 上拉取，成本上也可以做到更加灵活。
JindoFS 的块存储模式，也支持多种存储策略，比如，本地存两份，OSS上存一份；本地存两份，OSS上不存储；本地不存，OSS上存一份等等。用户可以充分利用不同的存储策略根据业务或者数据冷热进行使用。
块存储使用了全新的 jfs:// 格式，原始 HDFS/OSS 数据通过 distcp 方式即可完成数据导入，同时，JindoFS 提供了 SDK，在 EMR 集群外部，用户也可以读写 Jindo FS。
缓存模式
缓存模式，正如“缓存”本身的含义，通过缓存的方式，在本地集群基于 JindoFS 的存储能力构建了一个分布式缓存服务，远端的数据可以保存在本地集群，使远端数据变成“本地化”。简单地描述 JindoFS 缓存模式解决的问题
就是“OSS / 远端HDFS 已经有了大量数据，每次读数据的时候网络带宽经常被打满，Jindo FS 就可以通过缓存模式优化网络带宽的限制。”
“原来的文件路径是 oss://bucket1/file1 或 hdfs://namenode/file2，不想改作业的路径可以吗？”。是的，不需要修改。EMR 对 OSS 进行了适配（后续会支持远端 HDFS 的场景），可以通过配置的方式使用缓存模式。缓存对于上层的作业做到了完全无感。
但是缓存模式也不是万能的，为了保证多端数据一致性，rename 这种操作一定要同步刷新到远端的 OSS / HDFS，特别是 OSS 的Rename 操作比较耗时，缓存模式对 rename这种文件元数据操作暂时不能优化。
总结
在 2019 年的云栖大会上，EMR Jindo 的技术存储分离方案得到很大的关注，视频直达链接【云上大数据的一种高性能数据湖存储方案】
【EMR打造高效云原生数据分析引擎】后续我们也会在云栖社区和钉钉群分享更多的 Jindo 技术干货，欢迎有兴趣的同学加入 《Apache Spark技术交流社区》进行交流和技术分享。
