【藏经阁一起读（9）】读《阿里云 JindoFS+OSS 数据上云实战》，你有哪些心得？

好书要赞！

很棒的内容！

1

学习

JindoFS 作为阿里云基于 OSS 的一揽子数据湖存储优化方案，完全兼容Hadoop/Spark 生态，并针对Spark、Hive、 Flink、 Presto 等大数据组件和Al 生态实现了大量扩展和优化。

《阿里云 JindoFS+OSS 数据上云实战》这本书，云原生的大数据计算存储分离方案。我充分的理解了以前OSS/S3 作为云上对象存储的代表， 也在大数据生态进行了适配，但是由于对象存储设计上的特点，元数据相关操作无法达到 HDFS 一样的效率；对象存储给客户的带宽不断增加， 但是也是有限的，一些时候较难完全满足用户大数据使用上的需求。JindoFS 是阿里云针对云上存储定制的自研大数据存储服务， 完全兼容 Hadoop 文件系统接口，给客户带来更加灵活、高效的计算存储方案，目前已验证支持阿里云 EMR 中所有的计算服务和引擎： Spark、Flink、Hive、MapReduce、Presto、Impala 等。它使用 RocksDB 存储元数据，相比于 NameNode 可以存储更大规模的文件数， 不受限于内存。另外不需要Worker节点上报块信息，没有性能抖动的问题。工作中最明显的益处就是： 我们可以利用 JindoFS 作为存储引擎，将底层数据存放在对象存储（比如OSS）上，并且利用 JindoFS 的本地缓存加速能力， 组成一个云上稳定、可靠、高性能的大数据存储方案，给上层计算分析引擎提供强大有力的支撑。

拜读了读《阿里云 JindoFS+OSS 数据上云实战》这本书，让我学习到了如何进行数据迁移，包括迁移HDFS海量文件迁移到OSS、 如何将Hive数据按分区归档到OSS等。如何使用JindoFS缓存加速，用Fluid+JindoFS对OSS、HDFS上的数据以及海量小文件的训练加速， 以及JindoTable计算加速。这本书非常的有实践参考意义，JindoFS是基于阿里云对象存储OSS，为开源大数据生态构建的Hadoop兼容文件系统 。JindoFS提供兼容对象存储的纯客户端模式（SDK）和缓存模式（Cache），以支持与优化Hadoop和Spark生态大数据计算对OSS的访问； 提供块存储模式（Block），以充分利用OSS的海量存储能力和优化文件系统元数据的操作。这一些特性非常的针对典型的数据湖场景， 推荐使用SDK或者Cache模式以支持大数据分析和AI训练加速。这里面的很多实践我们之间就可以拿来使用，是非常好的方法论。 感谢专家们提供的《阿里云 JindoFS+OSS 数据上云实战》这本书。

学习

学习

学习

学习

学习

JindoFS SDK是一个简单易用的 JindoFS 客户端，目前主要用在E-Mapreduce集群内，提供JindoFS集群访问能力和操作OSS文件的能力。相比于Hadoop-OSS-SDK做了很多的性能优化。现在，JindoFS SDK对外开放使用，我们可以使用该SDK来获得访问OSS的能力，并获得更好的性能。

JindoFS SDK的作用等价于Hadoop-OSS-SDK，可以直接替代Hadoop-OSS-SDK。与Hadoop-OSS-SDK不同的是，JindoFS SDK直接基于OSS Restful API进行实现，而不是基于Java版SDK进行封装。JindoFS SDK也同样提供了Hadoop FileSystem接口，并且JindoFS SDK对文件管理、文件上传下载进行了一系列的性能优化。

麻烦给我点一个免费的赞

感谢你哦，祝你做啥都顺利

那我们开始吧，你可能有疑问这是什么东东？我的理解是 JindoFS它是种基于OSS的数据湖存储优化一种方案，能兼容市面上你能想到大数据生态与AI组件，并进行了扩展与优化，目的就是提高存储效率的。那咱怎么具体开发呢？是用“插件式”的SDK，可以在各种Hadoop/Spark 环境上用它。第一点就是针对大规模数据迁移，那肯定需要一种分布式的拷贝工具的对不对？DistCp就能完成，现在你退一步想下为啥要用它呢？那说明HDFS文件同步到对象存储是有问题的啊，比如超时啊，不能保证数据拷贝的一致性啊不能进行归档啊，而现在DistCp基本都能解决掉。 第二就是完成对象存储访问加速，我深有体会自从用了它当图床写文章的时候那上传速度那是嗖嗖的啊，并且用DistCp能够保证安全性，这是为啥呢？因为咱们知道对象存储如果进行AK方式进行安全授权可能就会泄露，那你说咋办？JindoFS SDK对免密验证的支持丰富，也还有Kerberos以及Ranger这类安全组件所以你怕个毛线，还有如何在各个组件如何取用这个SDK来提高OOS写入能力你自己看书。 第三是它有缓存加速能力。那最后效果是啥？启用缓存带来了将近50%的性能提升你就是牛不牛，怎么做到的呢，首先指定表和分区来预先缓存，这样查询缓存效率会提高不少，实操怎么做的自己看书。另外云上访问云下HDFS是存在问题的，说白了原因是网络时延本地带宽的限制导致。如果用了DisTCp的缓存加速可以完美解决这个问题啦。的流程是计算服务通过 Jindo SDK 访问数据，Jindo SDK 从 Namespace 中 查询缓存信息，然后向集群中的 Storage 服务读取缓存数据，如果命中缓存则直接返回，如果 没有命中缓存则从 OSS 读取数据，并将缓存写入 Storage 服务以便下次使用。 第四它能对AI进行训练加速哦。如果能提前把数据进行预热，将远端文件的原数据和数据都缓存到本地，那么训练的时候，所有的文件读取都是从本地，极大的缓解了 带宽和底层存储的压力。JindoRuntime 支持多种原数据和数据缓存策略。另外还支持原子性 cache 来保证本地文件的唯一性和可见性。我们也对小文件的缓存进行了比 较大的优化。比如图片、小文本训练场景，结合小文件的特点进行了缓存加速的优化。 第五是对Parquet数据进行查询加速。痛点是相对于本地存储，其性能受到网络带宽和机 械负载的影响，存在性能波动和瓶颈,同时因为远端读取 OSS 单次的 IO 是比较慢的，在列存等 一些随机读比较多的场景，性能的差距比较明显。所以在此背景下，稳定且高性能的数据读取 方案已经迫在眉睫，达到的效果是至少能把查询时间缩短了一倍多。其次是对HIve数仓表进行高效小文件合并，是这样完成的，JindoTable 是由 EMR 团队提供的表级别或分区级别的热度统计，具有存储分层以及表文件优 化的功能。如上图所示，-accessStat/-leastUseStat 类似于表的热度统计；-cache/-uncache 等 是表的分层存储；-showTable/-listTables 是查看表状态；-moveTo 是 JindoTable 提供的表级 别的数据迁移工具。optimize 可以实现小文件合并。 小文件合并的流程主要有两步。第一，查看表或分区有没有小文件。判断文件是否需要合并？ 这个时候，我们会用到-showTable/-showPartition 的命令。第二，如果确认表或分区需要进行 小文件合并，对表或者分区做 optimize。

码字不易，请给我一个免费的赞吧

你必升职加薪

11

1

学习学习

不错不粗，学习一波

学习

学习