计算存储分离已经成为云计算的一种发展趋势。在计算存储分离之前，普遍采用的是传统的计算存储相互融合的架构，但是这种架构存在一定的问题，比如在集群扩容的时候会面临计算能力和存储能力相互不匹配的问题。用户在某些情况下只需要扩容计算能力或者存储能力，而传统的融合架构不能满足用户的这种需求，进行单独的扩充计算或者存储能力；其次在缩容的时候可能会遇到人工干预，人工干预完后需要保证数据在多个节点中同步，而当有多个副本需要同步时候，可能会造成的数据丢失。而计算存储分离架构则可以很好的解决这些问题，使得用户只需要关心整个集群的计算能力。
阿里云作为一家全球领先的云计算及人工智能科技公司，其产品EMR提供了相对方便可控的企业级大数据服务，作为EMR的核心，在底层存储也有突出的设计和优化，本文主要调研和阿里云EMR的存储核心产品能力。
阿里云EMR在存储领域的核心组件涉及SmartData、JindoData、JindoFS、jindoFSx、OSS-HDFS、JindoCache等概念。本文不讨论阿里云盘古等底层存储系统的设计。
| 序号 | 版本号 | 修改内容 | 作者 | 修改时间 |
| 1 | V1.0 | 创建文档 | 作者 | 20240228 |
1 SmartData
资料来源：SmartData组件介绍_开源大数据平台 E-MapReduce(EMR)-阿里云帮助中心
SmartData是E-MapReduce（简称EMR）产品的核心自研组件，为EMR各个计算引擎提供统一的存储优化、缓存优化、计算加速优化和多个存储功能扩展，涵盖数据访问、数据治理和数据安全。
1.1 EMR各模块关系
SmartData组件在EMR产品中的位置如下所示。
1.2 主要组件
SmartData组件包括：
- JindoFS核心子系统：为各种远端存储系统提供缓存和缓存加速，详情请参见JindoFS介绍和使用
- JindoTable核心子系统：为表格数据源（例如Hive数仓）提供表和分区级别的优化和治理，详情请参见JindoTable使用说明
- JindoManager：提供JindoFS&JindoTable相关服务和功能的管理页面，例如，查看文件和表在缓存上的各种统计指标。
- JindoSDK：为EMR各种开源计算引擎提供统一的SDK，支持Java、C、C++和Python语言，提供多种访问和API接口，包括HCFS文件系统接口、POSIX接口和Table表格接口。
- 工具集： 提供相关的工具集，例如Jindo tool和迁移工具Jindo DistCp。
- 各种Connectors：包括Hadoop connector、Flink connector和TensorFlow connector，支持Kite SDK、Apache Beams、Flume、Sqoop和Kafka。
1.3 分析结论
SmartData作为阿里云EMR核心产品或模块，是EMR Jindo引擎的存储部分，包括统一的存储优化、缓存优化、计算加速优化和多个存储功能扩展，支持EMR各个计算引擎所需的各种存储服务。
SmartData的最高版本SmartData 3.8.x，文档发布于2023-03-07； JindoData是原阿里云EMR SmartData组件的升级版本。
2 JindoData
JindoData 是阿里云开源大数据团队自研的数据湖存储加速套件，面向大数据和 AI 生态，为阿里云和业界主要数据湖存储系统提供全方位访问加速解决方案。JindoData 套件基于统一架构和内核实现，主要包括 JindoFS 存储系统（原 JindoFS Block 模式），JindoFSx 存储加速系统（原 JindoFS Cache 模式），JindoSDK 大数据万能 SDK 和全面兼容的生态工具（JindoFuse、JindoDistCp）、插件支持。
2.1 架构
JindoData主要组件如下：
- JindoFS存储系统
- JindoFSx存储加速系统
- 生态支持和工具
2.2 主要组件
2.2.1 JindoFS 存储系统
基于阿里云 OSS 的云原生存储系统，二进制兼容 Apache HDFS，并且基本功能对齐，提供优化的 HDFS 使用和平迁体验。是原 JindoFS Block 模式的全新升级版本。 阿里云 OSS-HDFS 服务（JindoFS 服务) 是 JindoFS 存储系统在阿里云上的服务化部署形态，和阿里云 OSS 深度融合，开箱即用，无须在自建集群部署维护 JindoFS，免运维。
OSS-HDFS 服务具体介绍请参考 OSS-HDFS服务概述 。
2.2.2 JindoFSx 存储加速系统
JindoFSx（JindoData服务）是原JindoFS Cache模式的全新升级版本，是面向大数据和AI生态的云原生数据湖存储加速系统，为大数据和AI应用访问各种云存储提供访问加速，支持数据缓存、元数据缓存和P2P加速等功能。JindoFSx支持管理多个后端存储系统，可以通过统一命名空间进行管理，也可以兼容各系统原生的访问协议，也支持为这些系统提供统一的权限管理。原生优化支持阿里云OSS和阿里云OSS-HDFS服务，同时也支持业界多云对象存储（例如，Amazon S3）、 Apache HDFS和NAS。
2.2.3 生态支持和工具
- JindoSDK 支持。面向云时代的大数据 Hadoop SDK 和 HDFS 接口支持，内置优化访问阿里云 OSS，较 Hadoop 社区版本性能大幅提升；同时对接支持 JindoFS 存储系统包括服务、JindoFSx 存储加速系统；支持多云对象存储。
- JindoShell CLI 支持。JindoData 除了对接支持 Hadoop/HDFS shell 命令，同时提供一套 JindoShell CLI 命令，从功能、性能上大幅扩展和优化一些数据访问操作。
- JindoFuse POSIX 支持。JindoData 为阿里云 OSS、JindoFS 存储系统和服务、JindoFSx 存储加速系统提供的 POSIX 支持。
- JindoDistCp 数据迁移支持。IDC 机房数据（HDFS）上云迁移和多云迁移利器，支持多种存储数据迁移到阿里云 OSS 和 JindoFS 服务，使用上类似Hadoop DistCp。
- JindoTable 支持。结合计算引擎的使用推出的一套解决方案，支持 Spark、Hive、Presto 等引擎，以及表格式数据的管理功能。
- 生态插件。除了默认提供 JindoSDK 支持 Hadoop，另外还支持 Flink Connector 等插件。
2.3 应用场景
阿里云OSS/OSS-HDFS服务透明缓存加速
JindoFSx存储加速系统提供了透明缓存的使用方式，兼容原生OSS/OSS-HDFS存储方式，文件以对象的形式存储在OSS/OSS-HDFS上，每个文件根据实际访问情况会在本地进行缓存，提升访问OSS/OSS-HDFS的效率，同时兼容了原有OSS/OSS-HDFS文件形式，数据访问上能够与其他OSS/OSS-HDFS客户端完全兼容，作业访问OSS/OSS-HDFS的方式无需做任何修改。
Apache HDFS透明缓存加速
Apache HDFS透明缓存加速可以利用计算集群的闲置存储资源对远端HDFS集群进行数据缓存，避免了计算集群或服务占用核心集群过多带宽。当HDFS集群和计算集群分离，HDFS集群访问性能不及预期时，您可以通过在计算集群或靠近计算集群的地方缓存数据来进行加速。
统一命名空间缓存加速
JindoFSx存储加速系统提供统一命名空间挂载的功能，可以为应用程序提供统一的命名空间（jindo://）。应用程序可以通过统一命名空间和接口来访问多个独立的存储系统，从而实现只连接JindoFSx就可与不同的底层存储系统进行通信。
2.3 分析结论
JindoData是原阿里云EMR SmartData组件的升级版本，JindoData 4.0.0是原阿里云EMR，SmartData自研组件（大版本到3.8.0）架构升级之后的首次版本发布，重点对接和支持了阿里云OSS存储产品和阿里云OSS-HDFS服务（JindoFS服务）。
从SmartData到JindoData，定位发生变化，JindoData的定位是"数据湖存储加速套件"，与其他主流云服务运行商在此方便有异曲同工之处；
JindoData基于统一架构和内核实现包括——统一的存储优化、缓存优化、计算加速优化和多个存储扩展功能；
2.4 参考资料
https://github.com/aliyun/alibabacloud-jindodata
JindoData概述 - 开源大数据平台E-MapReduce - 阿里云
JindoData版本说明 - 开源大数据平台E-MapReduce - 阿里云
3 JindoFS存储系统
JindoFS是基于阿里云对象存储OSS，为开源大数据生态构建的Hadoop兼容文件系统（Hadoop Compatible File System，HCFS）。JindoFS提供兼容对象存储的纯客户端模式（SDK）和缓存模式（Cache），以支持与优化Hadoop和Spark生态大数据计算对OSS的访问；提供块存储模式（Block），以充分利用OSS的海量存储能力和优化文件系统元数据的操作。
3.1 架构
JindoFS 主要包含两个服务组件： 元数据服务(NamespaceService) 和存储服务(StorageService)：
- NamespaceService 主要负责元数据管理以及管理 StorageService。
- StorageService 主要负责管理节点的本地数据和 OSS 上的缓存数据。
下图是 JindoFS 架构图：
3.1.1 Namespace服务
Namespace服务是JindoFS的中心服务，主要负责管理用户的元数据，包括JindoFS 本身文件系统的元数据、切分的Block的元数据以及 Storage服务的元数据。JindoFS Namespace服务可以支持多个Namespace，用户可以根据不同的业务划分不同的Namespace，不同的Namespace存放不同业务数据，不相互干扰。Namespace不设置全局大锁，可以基于目录级别实现并发控制，进行并发创建和并发删除。此外Namespace可以设置不同后端存储，现阶段主要支持RocksDB和阿里云OTS，OTS支持预计在下个版本发布，其好处是如果在EMR中创建自己的集群，采用OTS作为数据后端，本地EMR集群可以随时销毁，集群在创建的时候，JindoFS的数据仍然可以访问，这增加了用户使用的灵活性。
3.1.2 Storage 服务
Storage 服务主要用来管理集群本地磁盘的数据，本地缓存的数据以及OSS数据。其目前可以支持不同的存储后端以及存储介质，存储后端现阶段主要支持本地文件系统以及OSS， 本地存储系统可以支持HDD/SSD/DCPM等存储介质，用以提供缓存加速，另外Storage 服务针对用户的小文件较多的场景进行优化，避免过多的小文件给本地文件系统带来过大的压力造成整体性能的下降。
3.2 使用方式
如前所述，JindoFS提供兼容对象存储的纯客户端模式（SDK）和缓存模式（Cache），以支持与优化Hadoop和Spark生态大数据计算对OSS的访问；提供块存储模式（Block），以充分利用OSS的海量存储能力和优化文件系统元数据的操作。
3.2.1 纯客户端模式（SDK）
JindoFS纯客户端模式为Hive和Spark等计算框架提供了访问阿里云OSS及其各种操作的优化，类似Hadoop社区的OSS FileSystem或S3A FileSystem。此模式不改变文件或对象在OSS上的组织方式，文件还是保存在OSS上，JindoFS只是提供面向Hadoop生态的客户端连接、扩展、适配和优化访问。您可以使用此模式，上传JindoFS SDK的JAR包至组件的classpath目录，简单易用，无需部署分布式服务。
3.2.2 JindoFS缓存模式（Cache）
JindoFS缓存模式（Cache）兼容JindoFS纯客户端模式（SDK），同时利用Jindo分布式缓存能力在计算侧为OSS提供缓存加速，以满足大规模的分析和训练吞吐需求。在纯客户端模式（SDK）基础上，Cache模式支持可选的元数据缓存和数据分布式缓存，同时保持数据跟OSS兼容和同步。数据缓存可以基于内存、SSD和普通磁盘，以适用不同的计算场景。
与Block模式不同的是，Cache模式将JindoFS文件以对象的形式存储在OSS上。该模式兼容现有的OSS文件系统，用户可以通过OSS访问原有的目录结构以及文件，同时该模式提供数据以及元数据的缓存，加速用户的读写数据的性能。使用该模式的用户无需迁移数据到OSS，可以无缝对接现有OSS上的数据，但是性能相对Block模式有一定的性能损失。在元数据同步方面用户可以根据不同的需求选择不同的元数据同步策略。
对比Oss FS， JindoFS的Cache模式提供以下优势：
a) 由于本地备份存在，读写吞吐与HDFS相当；
b) 能够支持全部 HDFS接口，支持更多的场景，如Delta Lake，支持 HBase on JindoFS；
c) JindoFS作为数据以及元数据的缓存，用户在读写数据以及List/Status操作相对OssFS有性能提升；
d) JindoFS作为数据缓存，可以加速用户的数据读写。
3.2.3 块存储模式（Block）
JindoFS存储模式（Block），不仅提供缓存加速能力，还可以组织、存储数据和管理文件元数据，类似Apache Hadoop HDFS。在此模式下JindoFS是个独立的存储系统，只是文件块数据存储在OSS上。
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）原生支持小文件，避免小文件过程造成文件系统过大的压力。
f）接口包括但不限于Rename的原子性和事务性能力、高性能本地写入、透明压缩、truncate、append、flush、sync和snapshot等。这些高阶存储接口对实现完整的POSIX和对接更多的大数据引擎到OSS是不可或缺的，例如，Flink、HBase、Kafka和Kudu。其他两种方式使用OSS也可以对接部分接口，但是能力和优势会有所不足。
3.2.4 Cache模式和Block模式对比
（1）共同点
两种模式都把数据存储在OSS上，同时根据本地缓存空间剩余情况确定是否在本地也放置一份以用于缓存加速。
（2）区别
两种模式的本质区别在于，块存储模式可以管理目录和文件元数据，文件是分成多个块存储在OSS上，所以写到OSS上的是一个一个的文件块，而缓存模式存储的是整个文件对象。
3.3 外部客户端
JindoFS外部客户端，主要是为E-MapReduce集群外部访问JindoFS集群提供一种可行的方法。现在JindoFS外部客户端只能访问块存储模式下的JindoFS，不支持访问缓存模式下的JindoFS。实际上，缓存模式兼容OSS原始语义，因此外部访问仅需用普通OSS客户端即可。
JindoFS外部客户端实现了Hadoop文件系统的接口，在用户程序跟E-MapReduce JindoFS Namespace服务网络相通的情况下， 用户可以通过JindoFS外部客户端去访问JindoFS上存储的数据， 但外部客户端不能利用E-MapReduce JindoFS的数据缓存能力，相比E-MapReduce集群内部访问JindoFS集群，性能有所损失。
3.4 分析结论
JindoFS提供兼容对象存储的纯客户端模式（SDK）和缓存模式（Cache），以支持与优化Hadoop和Spark生态大数据计算对OSS的访问；Cache模式将JindoFS文件以对象的形式存储在OSS上。该模式兼容现有的OSS文件系统，用户可以通过OSS访问原有的目录结构以及文件，同时该模式提供数据以及元数据的缓存，加速用户的读写数据的性能。
JindoFS提供块存储模式（Block），以充分利用OSS的海量存储能力和优化文件系统元数据的操作。 Block模式将JindoFS的文件切分的Block的形式存放本地磁盘以及OSS上，用户通过OSS只能看到Block的数据，该模式非常依赖于本地的Namespace的文件系统。
3.5 参考资料
[01] 什么是JindoFS,支持哪些模式_开源大数据平台 E-MapReduce(EMR)-阿里云帮助中心
[02] JindoFS外部客户端 - 开源大数据平台E-MapReduce - 阿里云
[03] JindoFS: 云上大数据的高性能数据湖存储方案-阿里云开发者社区
[04] 《阿里云云原生数据湖体系全解读》
4 OSS-HDFS 服务
阿里云 OSS-HDFS 服务（JindoFS 服务) 是 JindoFS 存储系统在阿里云上的服务化部署形态，和阿里云 OSS 深度融合，开箱即用，无须在自建集群部署维护 JindoFS，免运维。
OSS-HDFS服务（JindoFS服务）是一个云原生数据湖存储功能。基于统一的元数据管理能力，完全兼容HDFS文件系统接口，满足大数据和AI等领域的数据湖计算场景。
4.1 功能优势
通过OSS-HDFS服务，无需对现有的Hadoop、Spark大数据分析应用做任何修改。通过简单的配置即可像在原生HDFS中那样管理和访问数据，同时获得OSS无限容量、弹性扩展、更高的安全性、可靠性和可用性支撑。
作为云原生数据湖基础，OSS-HDFS在满足EB级数据分析、亿级文件管理服务、TB级吞吐量的同时，全面融合大数据存储生态，除提供对象存储扁平命名空间之外，还提供了分层命名空间服务。分层命名空间支持将对象组织到一个目录层次结构中进行管理，并能通过统一元数据管理能力进行内部自动转换。对Hadoop用户而言，无需做数据复制或转换就可以实现像访问本地HDFS一样高效的数据访问，极大提升整体作业性能，降低了维护成本。
4.2 主要功能
（1）回收站
当您从OSS-HDFS服务误删除文件时，文件不会立即被彻底删除，而是转至回收站。回收站中的数据保存时间默认是3天，支持自定义数据保存时间为1~14天。在回收站数据保存时间到期前，您可以从回收站恢复已删除的文件。
（2）导出清单
使用清单导出功能，您可以将某个Bucket下的OSS-HDFS服务的文件清单导出到某个特定路径，格式为JSON文件，方便您对元数据进行统计分析。
示例：
{"id":163**,"path":"/","type":"directory","size":0,"user":"admin","group":"supergroup","atime":0,"mtime":1666581702933,"permission":511} {"id":624668410678950****,"path":"/dls-1000326249","type":"directory","size":0,"user":"hadoop","group":"supergroup","atime":0,"mtime":1660889124590,"permission":511} {"id":624668410678950****,"path":"/dls-1000326249/benchmark","type":"directory","size":0,"user":"hadoop","group":"supergroup","atime":0,"mtime":1660889124590,"permission":511} {"id":624668410678950****,"path":"/dls-1000326249/benchmark/n1","type":"directory","size":0,"user":"hadoop","group":"supergroup","atime":0,"mtime":1660889124590,"permission":511} {"id":624668410678950****,"path":"/dls-1000326249/benchmark/n1/490747449","type":"directory","size":0,"user":"hadoop","group":"supergroup","atime":0,"mtime":1660895613953,"permission":511}清单导出结果文件的各字段含义说明如下：
| 字段 | 含义 |
| id | 文件或目录ID。 |
| path | 文件或目录路径。 |
| type | 元数据类型。
|
| size | 数据大小，单位为字节。
|
| user | 文件或目录所属的owner。 |
| group | 文件或目录所属的用户组。 |
| atime | 文件或目录的访问时间，取值固定为0，暂不支持统计。 |
| mtime | 文件或目录的修改时间，格式为时间戳。 |
| permission | 文件或者目录的权限。 |
（3）导出审计日志
OSS-HDFS服务端记录了客户端请求的查询、修改、删除文件元数据的操作审计日志。 您可以通过审计日志，了解OSS-HDFS服务操作审计、访问统计以及异常请求等情况。
示例：
2023-07-07 12:32:45.557 allowed=true ugi=root (auth:SIMPLE) ip=192.168.2.22 cmd=mkdirs src=/tmp/presto-root/e94dd606-ba21-4675-9b88-c82f66483628/b1=68/c1=68 dst=<null> perm=root:hadoop:rw-r----- proto=PROTOCOL_UNKNOWN 2023-07-07 12:32:46.39 allowed=true ugi=root (auth:SIMPLE) ip=192.168.2.22 cmd=getfileinfo src=/xxx/nnbench/user/hive/warehouse/mydb_18520/root/t1/b1=2/c1=2/20230707_043031_00022_xxx_80561c14-4d19-494e-8337-0e9b7b0d6663 dst=<null> perm=<null> proto=PROTOCOL_UNKNOWN 2023-07-07 12:33:02.169 allowed=true ugi=root (auth:SIMPLE) ip=192.168.2.22 cmd=rename src=/tmp/presto-root/e94dd606-ba21-4675-9b88-c82f66483628/b1=60/c1=60/20230707_043220_00030_xxx_03832297-7e89-4b0f-a3a2-88b1c4cec6da dst=/xxx/nnbench/user/hive/warehouse/mydb_18520/root/t1/b1=60/c1=60/20230707_043220_00030_xxx_03832297-7e89-4b0f-a3a2-88b1c4cec6da perm=presto:hadoop:rw-r----- proto=PROTOCOL_UNKNOWN 2023-07-07 12:33:05.430 allowed=true ugi=root (auth:SIMPLE) ip=192.168.2.22 cmd=delete src=/tmp/presto-root/e94dd606-ba21-4675-9b88-c82f66483628/b1=62 dst=<null> perm=<null> proto=PROTOCOL_UNKNOWN审计日志文件的各字段含义说明如下：
| 字段 | 含义 |
| （首字段） | 请求时间。 |
| allowed | 表示是否允许该操作。
|
| ugi | 用户名。 |
| ip | 发起请求的客户端IP地址。 |
| cmd | 操作类型，主要包含create、delete、mkdirs、rename、getfileinfo、listStatus、contentSummary、setStoragePolicy、unsetStoragePolicy等操作。 |
| src | 文件路径。 |
| dst | 仅当请求的操作类型为rename时，存在dst路径。 |
| perm | 创建文件、目录使用的默认权限。 |
| proto | 请求的协议，目前仅支持REST协议。 |
（4）冷热分层存储
并不是所有OSS-HDFS中存储的数据都需要频繁访问，但基于数据合规或者存档等原因，部分数据仍然需要继续保存。针对以上问题，OSS-HDFS服务支持数据的冷热分层存储，对于经常需要访问的数据以标准类型进行存储，对于较少访问的数据以低频、归档以及冷归档类型进行存储，从而降低总存储成本。
指定为写入OSS-HDFS服务的数据设置存储策略：
| 场景 | 执行命令 | 执行结果 |
| 为写入OSS-HDFS服务的数据设置存储策略为低频访问存储 | ./jindo fs -setStoragePolicy -path oss://examplebucket/dir1 -policy CLOUD_IA | dir1/目录下的文件对应的数据块会携带Key为transition-storage-class、Value为IA的标签信息。 |
| 为写入OSS-HDFS服务的数据设置存储策略为归档存储 | ./jindo fs -setStoragePolicy -path oss://examplebucket/dir2 -policy CLOUD_AR | dir2/目录下的文件对应的数据块会携带Key为transition-storage-class、Value为Archive的标签信息。 |
| 为写入OSS-HDFS服务的数据设置存储策略为冷归档存储 | ./jindo fs -setStoragePolicy -path oss://examplebucket/dir3 -policy CLOUD_COLD_AR | dir3/目录下的文件对应的数据块会携带Key为transition-storage-class、Value为ColdArchive的标签信息。 |
（5）元数据转换
OSS-HDFS服务支持在未部署任何导入和导出工具的情况下，直接将OSS元数据转换为OSS-HDFS元数据。
（6）Snapshot（试用）
您可以通过Snapshot进行数据备份和恢复。Snapshot在使用方式上与HDFS的快照功能完全兼容，同时支持目录层级的操作。
（7）RootPolicy
您可以通过RootPolicy为OSS-HDFS服务设置自定义前缀，在无需修改原有访问hdfs://前缀作业的基础上，将作业直接运行在OSS-HDFS服务上。
（8）ProxyUser
ProxyUser命令用于授权一个用户代表其他用户进行文件系统操作。例如，某些敏感数据只允许授权的特定用户代表其他用户进行访问和操作。
（9）UserGroupsMapping
UserGroupsMapping用于配置用户和用户组之间的映射关系。
5 JindoCache概述
参考资料：JindoCache概述_开源大数据平台 E-MapReduce(EMR)-阿里云帮助中心
JindoCache（原JindoFSx）是阿里云EMR提供的用于加速云原生数据湖的一个服务。他提供了数据缓存和元数据缓存等加速功能，并根据不同的CacheSet提供不同的读写策略，以满足数据湖在不同使用场景下对访问加速的需求。
CacheSet是JindoCache的缓存抽象。在实际使用中，并非所有的数据都需要缓存加速。考虑到数据湖的多样化计算需求和场景，JindoCache提供了细粒度的访问策略选择，您可以根据需要进行精确的配置。您可以根据具体情况选择激进的元数据缓存策略或完全不缓存某些数据，以实现最佳的性能和资源利用效率。
5.1 使用场景
JindoCache可以用于如下场景：
- OLAP（Presto查询）：提高查询性能，缩短查询时间。
- DataServing（HBase）：显著降低P99延迟，减少请求费用。
- 大数据分析（Hive/Spark 报表）：减少报表生成时间，优化计算集群成本。
- 湖仓一体：减少请求费用，优化数据目录（catalog）的响应延迟。
- AI：加速训练等场景，降低AI集群使用成本，提供更全面的能力支持。
5.2 缓存策略
JindoCache支持数据缓存（包括分布式数据缓存、一致性哈希数据缓存和本地缓存）和元数据缓存功能。
5.3 应用案例
JindoCache加速OSS-HDFS透明缓存
OSS-HDFS服务（JindoFS服务）是一款云原生数据湖存储产品。基于统一的元数据管理能力，在完全兼容HDFS文件系统接口的同时，提供充分的POSIX能力支持，能更好地满足大数据和AI等领域的数据湖计算场景。
以JindoCache支持阿里云OSS-HDFS透明缓存加速的使用方式为例，利用集群本身的存储资源缓存OSS-HDFS文件，以加速作业对OSS-HDFS的访问。
JindoCache加速OSS透明缓存
本文以JindoCache支持阿里云OSS透明缓存加速的使用方式为例，利用集群本身的存储资源缓存OSS文件，以加速作业对OSS的访问。
文件以对象的形式存储在OSS上。
JindoCache使用CacheSet来管理不同的缓存策略，您可以根据实际需求为不同的路径选择不同的缓存策略。JindoCache支持一个或多个CacheSet。
JindoCache统一命名空间缓存加速
JindoCache存储加速系统不仅提供了对多种数据源的缓存加速功能，还能将不同数据源统一管理，并将它们置于同一个命名空间下，从而实现统一访问。
可以将OSS Bucket的指定目录挂载到Jindo文件系统中的/oss目录下，使得您可以通过Jindo文件系统访问和操作OSS上的文件。您也可以将多个OSS Bucket挂载到不同的路径下面。
6 参考资料
[01] GitHub - aliyun/alibabacloud-jindodata: alibabacloud-jindodata
[02] 什么是JindoData（新）_开源大数据平台 E-MapReduce(EMR)-阿里云帮助中心
[03] 什么是OSS-HDFS服务_对象存储(OSS)-阿里云帮助中心
[04] 《阿里云云原生数据湖体系全解读》
标签：HDFS,存储,缓存,JindoFS,套件,OSS,JindoData,数据 From： https://blog.csdn.net/iamonlyme/article/details/136626617