EMR 的存储解决方案 | 学习笔记

开发者学堂课程【E-MapReduce入门：EMR 的存储解决方案】学习笔记，与课程紧密联系，让用户快速学习知识。

课程地址：https://developer.aliyun.com/learning/course/329/detail/3702

EMR 的存储解决方案

内容介绍：

一、EMR 提供的存储选择概念

二、JindoFS 玩转云原生存储

三、JindoFS 使用实战

四、云上云下互联

从大数据分析的场景来看，主要目的是分析、处理海量的数据，首先要将解决的问题是存储数据。

一、EMR 提供的存储选择概念

1、传统大数据存储解决方案——HDFS

首先 EMR 提供 HDFS 的存储方案， HDFS 是大数据领域最为传统的存储方案，在 EMR 集群创建出来之后，所有 EMR 集群中都会自带 HDFS 的部署配置。集群 A 和集群 B 两个 EMR 集群，各自都会有一个 HDFS ，上层的计算引擎都可以去访问自己集群的 HDFS 或者也可以像图中所示，集群 B 可以跨集群访问集群 A 的 HDFS 。这就是 EMR 提供的 HDFS 的解决方案。

2、云原生存储解决方案

相对于传统的 HDFS 解决方案，最近几年大数据领域的趋势，是从存储上的趋势直线演化成计算、存储分离的架构，原有 HDFS 的存储架构的特点是计算跟着存储走，计算和存储是一体的，在同一个集群中一起维护。现在会通过把计算和存储分离开的做法实现计算存储分离的架构，最常见的是类似于 AWS 利用 S3 做计算层专属分离的架构， EMR 中已经非常好的支持计算、存储分离的架构，把整个方案或者整个产品的代号称作为 JindoFS 。

JindoFS 的本质基于阿里云上 OSS 对象存储的产品，在 EMR 中实现计算存储分离的架构，计算存储的趋势非常明显，非常明显的看到越来越多的用户选择计算存储分离的架构，而不是选择 HDFS ，同时可以看到很多 HDFS 老用户希望做存储架构的升级，把 HDFS 的存储架构调整为计算存储分离的架构。趋势非常的明显，趋势背后的原因有四点，这些原因造成的非常明显的趋势。

首先从容量来看， HDFS 有明显的特点，是它的容量是受集群规模限制的，容量受限在 HDFS 可以由两方面去考虑，一个是数据容量， HDFS 的数据是通过分布式的 DataNode 进行存储管理的，所以存储流量很明显受限于 DateNote 上磁盘的总量，另一个方面 HDFS 的容量也受限于原数据的容量。HDFS 的 NameNode 的实现受制于内存使用，所以它的原数据无法支撑非常大的量级，如果原数据达到了一定程度，不得不采用一些类似于 Federation 的手段，实现更复杂的HDFS 的部署配置。相对于 HDFS 来说，计算存储分离架构就可以提供一个近乎海量的数据。

第二点是运维成本。做过 HDFS 运维的同学应该有一些经验， HDFS的运维是比较复杂的，相对来说基于 JindoFS 来做计算、存储、分离，相当于把整个工作交给更专业的团队，阿里云的 OSS 团队来做，用户层面无需再为运维烦恼， OSS 也能提供一个更为强大，更安全，更可靠的一个运维保证。

第三点关于集群弹性的问题，因为 HDFS 利用三备份的方式来保存数据，所以整个数据集存储在本地的节点上，所以存储节点是比较难做灵活的伸缩，然后数据有多少就需要长期持有这些节点，随着数据量增大，还需要进行相应的扩容，来相对来说 JindoFS 的好处是由于存储不再是由一个计算机循序计算集群去管理，所以它的计算集群的弹性是非常好的，可以根据实际的计算的需求，然后去动态的伸缩集群。

第四点成本上的考量， HDFS 由于通过本地盘的存储，它的存储成本会比计算存储分离架构成本要高。

总的来看，总结了相似点的差异，导致越来越多的客户希望使用计算存储分离的架构。

二、JindoFS 玩转云原生存储

1、什么是 JindoFS

适配对象存储 OSS，提供 Hadoop Compatible FileSystem (HCFS)

提供缓存加速能力 (Cache 模式)

结合对象存储深度定制的高性能 Block 模式

首先要搞清楚的是 JindoFS 是什么，图上为 JindoFS 的架构图。可以看到 JindoFS 处于一个中间层的状态，可以看到整个图的最上层，是计算引擎，它的最底层是对象存储 OSS 是计算存储离里面的存储核心，把所有的数据都存在对象存储上面。当中蓝色的部分是通过网络，蓝色部分以上是 EMR 集群内部，然后 EMR 集群内部需要通过网络来访问远端的 OSS 存储上的数据， JindoFS 处于计算层和 OSS 之间，起到了连接以及加速的作用， JindoFS 定位可以从三个方面来看：

首先第一点是 JindoFS 提供了一个对象，存储 OSS 的一个适配，对象存储的语义是无法直接应用于大数据的生态系统，它更多的是遵循于类似 HDFS 所定义的 Hadoop Compatible FileSystem 的接口， JindoFS 在所做的第一件事情就是如何将 OSS 中对象存储的语义比较高效、比较完善的封装成兼容 Hadoop 的 System的语义。这是 JindoFS 第一个重要作用。

第二个重要作用是 JindoFS 除了做好 Connector 工作以外，还提供非常重要的缓存能力，在存储计算分离的架构中，所有的计算引擎读数据都要通过网络去读远端 OSS 的顺序。可以看到整个读写 IO 肯定是受制于网络的瓶颈。 JindoFS 在中间作为缓存层，利用本地的存储资源，来缓存 OSS 上比较热的数据，缓存到本地节点上，起到缓存加速的能力，这就是 JindoFS 提供的第二个核心能力。

第三个能力是 JindoFS 除了上述所说提供缓存的一个机制之外，还提供了深度整合 OSS 对象存储，深度定制提供的 Block 使用模式，然后提供一个更高性能的存储访问的方案。

（1）基础使用

海量规模优化支持，特别针对大目录操作稳定、高效

文件语义适配完善

高级特性: Job Committer ¹、Flink file sink connector²

从表面上来看提供了一个对于 OSS 对象存储的封装，实现了connector 的作用，但其实在这方面的能力不仅仅是一个 connector。对于适配 OSS 对象存储来说 JindoFS 做了不少的优化。

比如第一点就是如何支持海量规模，特别是针对一些大目录的一些操作，大目录的 Name、List 之类的操作。如何更加的稳定，在性能上更加的高效， JindoFS 在这方面做了不少优化工作。

第二点是 JindoFS 在语义适配上经过了较长时间的演化，不断的改善， JindoFS 语义支配上也是非常的完善。

最后一点 JindoFS 也是针对 OSS 对象存储的特性，支持了一些高级的特性，比如 Job Committer ¹ 实现了无需 Rename 的高效的 Job Committer ¹ 。另外也是利用了 OSS 的一些接口，对于 Flink 的应用场景，实现了 file sink 的 connector，实现 flink 上面的exactly once的语义。在适配 OSS 方面，可以对标 S3 的实现，S3 是比较领先的产品我们知道S3在夜间应该说是比较领先啊，比较领先的这样一个产品，有大量的工作围绕如何在大数据领域像 S3 的一个存储系统。S3 在这方面相对来说算是一个标杆， JindoFS 基础使用上所对标的就是 S3 在大数据上的使用，S3 所能做到的一些功能， JindoFS 也做了非常好的支持，甚至在大规模的情况下，甚至可以做到比对 S3 的支持更好的优化， JindoFS 在 OSS 适配所做的工作。最简单来看，不需要额外功能 JindoFS 就可以交互 OSS 的存储后端，对应作业的读写文件地址相应的就可以去使用 JindoFS 作为 behind 实现非常完善的知识，也是非常高效的知识。这就是关于 JindoFS 的一个最基础使用。

（2）缓存模式使用

打开缓存开关，可利用本地存储资源缓存加速 OSS 上的数据¹

LRU 策略自动清理冷数据块

异步触发清理，不影响读写

进阶使用是 JindoFS 提供额外的缓存加速的能力。基础使用相对来说对于比较小的用户或者整个数据规模不是那么大的，就简单的使用一基础的一个配置就可以非常好的去适配 OSS 上的存储数据。在很多情况下基础的使用方式可能会面临一些瓶颈，最常见受制于网络的带宽，当集群规模变得比较大或者整个集群数量非常多的时候，可以想到由于所有数据存储在 OSS 远端存储上，整个网络冲突，随着集群规模的增长，网络端口它对于 IO 的吞吐需求也是会水涨船高的，总会有一个界限导致，当作业规模达到一定程度之后，网络的带宽成为了整个作业的瓶颈因素，在这种情况下，会推荐大家使用 JindoFS 的缓存方式，去减缓网络带宽带来的瓶颈，通过本地已有的存储资源，通过本地磁盘或者本地内存所提供的带宽，来弥补网络带宽的不足。在 JindoFS 提供的进阶缓存使用模式，也是提供了一个缓存开关，在后面的一个演示流程中，也会为大家演示如何去打开缓存开关。然后这样就可以利用本地的存储资源去加速 OSS 上的热数据。

关于缓存使用上，知道本地集群或者计算集群所拥有的存储资源，比如本地磁盘相比于 OSS 后端来说它的资源和容量是非常的有限的，所以缓存模式是利用有限的本地磁盘去缓存最热的一个 OSS 后端上的数据，从而达到较优的缓存加速作用，关于缓存的管理 JindoFS 相对的缓存服务会根据 LRU 的策略去自动清理，自动管理清理集群上的冷热数据，然后空间留给热数据，这一块是 JindoFS 自动做掉的，也不需要用户去操心，整个过程也是一步出发的过程，不会影响读写流程。打开缓存开关，利用缓存模式来使用 JindoFS 之后，对于作业来说也是没有任何感知的，用户所需要做的是只要打开页面上的缓存开关，它所带来的好处是可以利用本地的磁盘带宽来加速数据的读取，从而缓解网络带宽所带来的 IO 读取的瓶颈，整个过程也是透明的。这就是 JindoFS 所提供的第二个核心能力，关于缓存模式的阐述。

（3）块存储模式使用

块存储模式 (Block) 适用于高性能数据处理场景¹

元数据由 NamespaceService 管理，文件数据以数据块形式存储

在OSS 上，本地对数据块进行缓存

性能和体验上对标 HDFS

关于 JindoFS 的高级使用，提供了块存储的使用方式。关于块存储的使用方式，可以看一下图，这种使用模式相对于之前纯粹的缓存方式来说，它是结合了 OSS 做深度定制的，文件不再是存放在 OSS 上的一个对象，而是使用 JindoFS 自己 Namespace 服务，自己去管理数据的元信息。 OSS 只是作为一个存储介质，只是把数据分块，然后放在对应的 OSS 的目录底下。

整个元数据通过自己的元数据服务进行管理。有了缓存模式之后又引入块存储的模式的原因主要可以从两个点上进行考虑，第一个点是第一个相比于 Cache 模式的重要区别点是它的原数据不再是 OSS 上的对象，而是自己维护的元信息，比较类似于 HDFS 、 NameNode  的实现，这样的好处是对于对象存储的元数据访问是要通过网络，然后去 OSS 后端上去查的，某些某些 Hadoop 文件系统的元数据操作的语义，往往还涉及到多次的 rest API 的调用，导致了在元数据访问上，纯粹的 Cache 模式有可能会带来的新的问题，通过 Block 模式，提供了自己管理的元数据，提供了非常高效的元数据访问的实现。

在 Block 模式方面可以对标 HDFS 。之前做过一些测试，在原数据访问性能上在很多场景下甚至是超过 HDFS 的。另外一个方面 Block 模式所具有的是对于语义的支持。 OSS 这种对象存储是很难去完全支持 HDFS 的所有语义的，比如说像 Append、Think 语义单纯的通过 Cache 模式是比较难实现的，对于这些的支持通过 Block 模式的使用方式，提供了更加完善的文件系统语义支持，可以使用 Block 模式完全替代掉 HDFS 的任何使用场景，利用 Block 模式来进行架构升级。虽然它是 Block 模式，但是它的存储架构其实还是存储计算分离的架构，它多模式的数据，还是由 OSS 后端去存储的，本地只是缓存加速的性质。

元数据服务虽然需要依赖于本地的 NameSpace 的服务，但是它的元数据信息，也同步在 OTS 也是阿里云表格存储的云产品，也是把数据放在 OTS 上面，同样也做到了元数据的存储计算分离，所以整个 Block 模式的架构是可以完全替代 HDFS ，二是它比 HDFS 的性能更优，第三点就是它比 HDFS 的灵活性更强，是真正做到存储计算分离的架构。

所以 Block 模式的定位主要是替代 HDFS 实现比 HDFS 更优的解决方案。

2、高级特性

FUSE支持

权限控制

分层存储 ( coming soon )

主要有三大特性， JindoFS 提供的一些额外的高级特性支持。

首先 JindoFS 现在也支持 FUSE 文件系统的接口， FUSE 的使用场景是机器学习场景，传统的机器学习可能就直接读取本地的文件系统。 FUSE 的好处是把分布式的文件系统挂载到 FUSE 的目录下，类似于像读取本地文件系统一样的去操作，对于机器学习的场景，经常会使用 FUSE 的接口实现非常易用的存储解决方案。

第二点 JindoFS 支持权限控制。在即将到来的新版本中，也会对 Block 模式和 Cache 模式都会支持权限控制实现用户对权限安全方面的需求的满足。

第三部分，在新版本中也即将会推出一个大的特性，就是分层存储。 像 OSS 这样的对象存储，除了提供海量的存储容量之外，也提供了一些存储介质的选择，比如类似于标准的存储或者 Archive 性质的存储。

Archive 性质的存储可以去存储一些冷数据，对于 Archive 的冷数据的读取是比较费时比较费力的，但是费用相对来说是很低的，所以说利用 OSS 提供的特性， JindoFS 在 Hadoop 的文件系统层也提供文件分层的功能，对一个文件或者目录甚至对于一个表级别，提出能够透出存储策略的自端，或者也提供了存储策略转换的工具，用户可以根据实际情况把一些冷的数据 Archive 掉，把热数据从 OSS 后段中预加载到本地的缓存中实现比较 hot 的 policy，通过分层存储策略，可以提供更好的文件冷热的管理，对于热数据可以进行预加载更好的去加速后续的计算。

对于冷数据来说可以通过类似于 Archive 这样的方式，通过更低成本的建设去存储从而很好的去降低用户整体的存储成本，然后达到较优的存储方案。

三、JindoFS 使用实践

存量数据迁移，Jindo DistCp¹

简单使用示例

缓存相关配置示例

Block 模式使用演示

演示一下如何在 EMR 中使用 JindoFS 的方案。主要会分为四部分来做演示。针对前三部分，其实也是非常直观的用户创建使用 EMR 、 JindoFS 的实际流程。

第一步是数据迁移让用户使用 EMR ，使用JindoFS 在很多情况下并不是数据从零开始的，往往用户是从线下的或者从自建的一个集群迁移到 EMR 上面，那这就涉及到所要做的第一步，是怎么样把存量的数据从原有的集群上搬到 EMR 、JindoFS 的存储系统中，第一步提供 Jindo DistCp¹ 工具是基于 Hadoop DistCp¹进行深度定制改造，针对 JindoFS 做了一些定制优化，一个非常高性能的 DistCp¹ 的数据迁移工具。这个工具可以在 EMR 中使用也可以提供相应的 GitHub 地址，也可以从 GitHub 上去下载编译项目，然后在自己自建的集群中去运行 Jindo DistCp¹ ，可以实现非常高效的数据迁移。

完成数据迁移之后，第二步非常直观的是需要利用 JindoFS 这个存储后端进行数据作业的运行、后数据的分析、统计，也会简单的演示一下如何使用 JindoFS 来考作业。

第三块是关于 JindoFS 的缓存相关，也会演示一下缓存相关的配置方式。

最后一块会针对 JindoFS 的 Block 模式来演示一下如何使用 Block模式。

EMR 集群建出来的情况以及 JindoFS 集群的情况。这是建的一个测试集群，对于建出来的 EMR 集群来说都是默认自带 JindoFS 系统。对于 JindoFS 就是这些组件的状态，可以看到 SmartData点进去。

可以看到 Storage Service、Namespace Service 这些负责数据缓存、管理据、信息管理等服务。对应的配置也是在这个下面的。

针对刚才场景做演示。

1、存量数据迁移， Jindo DistCp¹ 

TimdeMacBook-Pro:~tim$  ssh root@101.132.97.103

root@101.132.97.103's password:

Last login: Sat Sep 12 17:51:23 2020

Welcome to Alibaba Cloud Elastic Compute Service !

-bash: warning: setlocale: LC_CTYPE: cannot change locale (UTF-8): No such file or directory

[root@emr-header-1 ~]# hadoop fs -ls hdfs:///data-dir/

Found 17 items

-rw-r-----   2 root hadoop 0 2020-09-12 15:39

hdfs:///data-dir/_SUCCESS

-rw-r-----   2 root hadoop 62500000 2020-09-12 15:39

hdfs:///data-dir/part-m-00000

-rW-r-----   2 root hadoop 62500000 2020-09-12 15:39

hdfs:///data-dir/part-m-00001

-rw-r-----   2 root hadoop 62500000 2020-09-12 15:39

hdfs:///data-dir/part-m-00002

-rw-r-----   2 root hadoop 62500000 2020-09-12 15:39

hdfs:///data-dir/part-m-00003

-rw-r-----   2 root hadoop 62500000 2020-09-12 15:39

hdfs:///data-dir/part-m-00004

-rw-r-----   2 root hadoop 62500000 2020-09-12 15:39

hdfs:///data-dir/part-m-00005

-rw-r-----   2 root hadoop 62500000 2020-09-12 15:39

hdfs:///data-dir/part-m-00006

-rw-r-----   2 root hadoop 62500000 2020-09-12 15:39

hdfs:///data-dir/part-m-00007

-rw-r-----   2 root hadoop 62500000 2020-09-12 15:39

hdfs:///data-dir/part-m-00008

-rW-r-----   2 root hadoop 62500000 2020-09-12 15:39

hdfs:///data-dir/part-m-00009

-rW-r-----   2 root hadoop 62500000 2020-09-12 15:39

hdfs:///data-dir/part-m-00010

-rW-r-----   2 root hadoop 62500000 2020-09-12 15:39

hdfs:///data-dir/part-m-00011

-rW-r-----   2 root hadoop 62500000 2020-09-12 15:39

hdfs:///data-dir/part-m-00012

-rw-r----- 2 root hadoop 625000002 2020-09-12 15:39 hdfs:///data-dir/part-m-00013

-rW-r-----   2 root hadoop 62500000 2020-09-12 15:39

hdfs:///data-dir/part-m-00014

-rW-r-----   2 root hadoop 62500000 2020-09-12 15:39

hdfs:///data-dir/part-m-00015

(reverse-i-search)'jin':jindo distcp --src=hdfs:///data-dir --des=oss：//chenshan-sh-test/date-dir

[root@emr-header-1～]# jindo distcp --help

登陆集群，用 EMR 集群做一个模拟，假设在本地的 HDFS 集群上有一些存量数据， data-dir 下面有存量数据，第一步是利用 Jindo DistCp¹ 工具，把模拟存量集群上的数据传到 JindoFS 上面。

r!/org/slf4j/impl/StaticLoggerBinder.class]

SLF4J:Found binding in[jar;file:/opt/apps/ecm/service/b2jindosdk/

2.7.301/package/b2jindosdk-2.7.301/Lib/jindo-distcp-2.7.301.j ar!/org/slf4j/impl/StaticLoggerBinder.class]

SLF4J: See http://www.slf4i.org/codes.html#multiple_bindings for an explanation.

SLF4J; Actual binding is of type[org.slf4j.impl.Log4jLoggerFactory]

20/09/12 17:52:07 INFO distcp.JindoDistCp:JindoDistCp args:--help

20/09/12 17:52:07 INFO distcp.JindoDistCp$JindoDistCpOptions:Options

--help- Print help text

--SrC-VALUE Directory to copy files from

--dest-VALUE Directory to copy files to

--parallelism-VALUE Copy task parallelism

--outputManifest=VALUE The name of the manifest file

--previousManifest=VALUE -The path to an existing manifest file

--requirePreviousManifest-VALUE Require that a previous manifest is present if specified

--copyFromManifest Copy from a manifest instead of listing a directory

--srcPrefixesFile-VALUE File containing a list of source URI prefixes

--srcPattern-VALUE Include only source files matching this pattern

--deleteOnSuccess Delete input files after a successful copy

--outputCodec=VALUE Compression codec for output files

--groupBy-VALUE Pattern to group input files by

--targetSize-VALUE Target size for output files

--enableBalancePlan Enable plan copy task to make balance

-enableDynamicPlan Enable plan copy task dynamically

--enableTransaction Enable transation on Jobexplicitly

--diff show the difference between sre and destfilelist

--ossKey-VALUE - Specify your oss key if needed

--ossSecret=VALUE Specify your oss secret if needed

--ossEndPoint=VALUE Specify your oss endPoint if needed

--policy-VALUE Specify your oss storage policy

--cleanUpPending clean up the incomplete upload when distcp job finish

--queue-VALUE Specify yarn queuename if needed

--bandwidth-VALUE Specify bandwidth per map/reduce in MB if needed

--s3Key=VALUE Specify your s3 key

--s3Secret=VALUE Specify your s3 Sercet

--s3EndPoint-VALUE Specify your s3 EndPoint

(reverse-i-search)`jindo' : jindo distcp --src=hdfs:///data-din --dest=oss:// chenshan-sh-test/data-dir

[root@emr-header=i～]# jindo distep --sreuhdfs:///dote-dir --dest= oss; //chenshan-sh-test/data-dir

20/09/12 17:52:29 Inf0; Running with args; --sreuhdfs ///data-dir --dest =oss://chenshan-sh-test/data-dir

SlF4J: Class patn contoins multiple SLFaj bindings,

SLF4J:Found binding in [jar:file/opt/apps/ecm/servce/b2jindosdk/

2.7.301/package/b2jindosdk-2.7.301/lib/jboot.jar!/org/slf4j/i

mpl/StaticLoggerBinder.class]

SLF4J:Found binding in [jar:file:/opt/apps/ecm/service/b2jindosdk/

2.7.301/package/b2jindosdk-2.7.301/lib/jindo-auditlog-full.ja r!/org/slf4j/impl/StaticLoggerBinder.class]

SLF4J:Found binding in [jar:file:/opt/apps/ecm/service/b2jindosdk/

2.7.301/package/b2jindosdk-2.7.301/lib/jindo-distcp-2.7.301. ar!/org/slf4j/impl/StaticLoggerBinder.class]

SLF4J:See http://www.slf4j.org/codes.html#multiple_bindings for an explanation.

SLF4J: Actual binding is of type[org.slf4j.impl.Log4jLoggerFactory]

20/09/12 17:52:29 INF0 distcp.JindoDistCp:JindoDistCpargs:--src

=hdfs:///data-dir --dest-oss://chenshan-sh-test/data-din

20/09/12 17:52:29 INFO distcp.JindoDistCp:Using output pathhdfs:/tmp/

6a9b556a-d71d-406a-ad7d-44601ab0eec5/output'

20/09/12 17:52:29 WARN util.NativeCodeLoader:Unable to load native-hadoop library for your platform ... using builtin-java class es where applicable

20/09/12 17:52:30 WARN shortcircuit.DomainSocketFactory: The short-circuit local reads feature cannot be used because libhadoop cannot be loaded.

20/09/12 17:52:30 INFOdistcp.FileInfoListing:Opening newfile:hdfs:/

tmp/6a9b556a-d71d-406a-ad7d-44601ab0eec5/files/1

20/09/12 17:52:30 INFO distcp.JindoDistCp; Created 1files to copy17 files

20/09/12 17:52:30 INFO distcp.JindoDistCp: Found 17 source files cost 114 ms

20/09/12 17:52:30 INFO common.AbstractJindoFileSvstem:Jboot loa name is/var/oa/biaboot/iboot-INF0-1599904350527-

20/09/12 17:52:30 INFO oss.0ssStore:Filesystem support for magic committers is enabled, write buffer size 1048576

20/09/12 17:52:31INF0common.FsStats:cmd-mkdirs.src=oss:// chenshan -sh-test/data-dir.dst=null,size-0.parameter-FsPermission rwxrwxrwx time -in-ms-520，version-2.7.301

20/09/12 17:52:31 INFO distcp.JindoDistCp:use CopyutputFormat with CopyCommitter

20/09/12 17:52:31 INFO client.RMProxy:Connecting to Resource Manager atemr-header-1cluster-188778/192.168.0.12:8032

20/09/12 17:52:31 INFO inputFileInputFormat: Total input files to process:1

20/09/12 17:52:31 INFO mapreduceJobSubmitter: number of splits:1

20/09/12 17:52:31 INFO mapreduceJobSubmitter: Submitting tokens for job:job_1599894798772_0010

20/09/12 17:52:31 INFO impl.YarnClientImpl:Submitted application application_1599894798772_0010

20/09/12 17:52:31 INF0 mapreduce.Job:The url to track the job:http://emr-header-1.cluster-188778:20888/proxy/application_1599894798772_0010/

20/09/12 17:52:31 INFO mapreduce.Job:Running job;job _15998947987 72_0010

20/09/12 17:52:36 INFO mapreduce.Job:Job job_1599894798772_0010 20/09/12 17:52:36 INFO mapreduce.Job: map 0% reduce 0%

20/09/12 17:52:41 INFO mapreduce.Job: map 100% reduce 0%

20/09/12 17:52:47 INFO mapreduce.Job: map 100% reduce 10%

20/09/12 17:52:48 INFO mapreduce.Job: map 100% reduce 40%

20/09/12 17:52:49 INFO mapreduce.Job: map 100% reduce 60%

20/09/12 17:52:51 INFO mapreduce.Job: map 100% reduce 90%

OSS 对应的目录下看到文件

Combine output records=0

Reduce input groups=17

Reduce shuffle bytes-1226

Reduce input records-17

Reduce output records0

Spilled Records-34

Shuffled Maps =10

Failed Shuffles-0

Merged Map outputs-10

GC time elapsed(ms)=658

CPU time spent(ms)=11980

Physical memory(bytes)snapshot=4821950464

Virtual memory(bytes)snapshot=57849716736

Total committed heap usage(bytes5450498048

Distcp Counters

Bytes Destination Copied=1000000000

Bytes Source Read=1000000000

Files Copied=7

Shuffle Errors

BAD_ID=0

CONNECTION-0 IO_ERROR=0

WRONG_LENGTH=0

WRONG_MAP=0

WRONG_REDUCE=0

File Input Format Counters

Bytes Read-2478

File Output Format Counters

Bytes Written=0

20/09/12 17:52:52 INFO distcp.JindoDistCp:Try to recursively delete hdfs

:/tmp/6a9b556a-d71d-406a-ad7d-44601ab0eec5

[root@emr-header-1 ~]#

点进 data.dir 可以看到相应的数据

5：52时数据从 HDFS 集群中导到 OSS 上面，完成了第一步工作。

2、简单使用示例

使用方式非常简单的，根据刚才可以看到， OSS：// 这样一个 scheme的前缀，用到了 FS 的模式。用 HIve 作业来演示一下。

Combine output records=0

Reduce input groups=17

Reduce shuffle bytes-1226

Reduce input records-17

Reduce output records0

Spilled Records-34

Shuffled Maps =10

Failed Shuffles-0

Merged Map outputs-10

GC time elapsed(ms)=658

CPU time spent(ms)=11980

Physical memory(bytes)snapshot=4821950464

Virtual memory(bytes)snapshot=57849716736

Total committed heap usage(bytes5450498048

Distcp Counters

Bytes Destination Copied=1000000000

Bytes Source Read=1000000000

Files Copied=7

Shuffle Errors

BAD_ID=0

CONNECTION-0 IO_ERROR=0

WRONG_LENGTH=0

WRONG_MAP=0

WRONG_REDUCE=0

File Input Format Counters

Bytes Read-2478

tim 1

Time taken: 11.053 secondsFetched:1row(s)

hive>drop database test cascade；

//

//生成表格文件

Time taken: 0.521 seconds

hive>excit；

//对应的路径被删除

[root@emr-header-1～]#

3、缓存相关配置示例

缓存开关都在页面配置上，SmartData 下面缓存开关都是客户端配置

Data cache enabled 配置0代表是关闭，集群创建出来默认就是关闭的，对于一些简单的应用场景不需要缓存，假如在一些实行规模并发度较大或者遇到瓶颈的情况下可以把它打开。

client 开关表示客户端，这种情况下第一次读 OSS 文件的时候，会将 OSS 后端上的数据块下载到本地的缓存中，在第二第三次后续的个读取过程中就可以命中本地缓存块。

缓存还有一些高级的配置， storage 配置页主要涉及到缓存相关的配置就两个，是water mark low和water mark high，water mark high 是所配置的磁盘使用的上水位，后面是一个比例的设置从0到1，默认设置成0.4，最多利用40%的磁盘去做缓存，low ratio对应的是磁盘水位清理的时候会把磁盘上的缓存数据清理到也就是20%的磁盘总容量。用户可以在使用过程中，根据自己的实际情况配相应配额的磁盘的水位，然后来做一个数据的缓存。

4、Block 模式使用演示

Cache 模式的使用，无需做过多的配置，基本上就是开箱即用，通过DCP 完成数据的导入，直接可以通过 OSS 前缀来访问 OSS 上的数据，最多也是配置一个缓冲开关，然后打开或者关闭对应的缓存功能，Block 模式是通过本地的 Namespace 去管理数据，对应的数据是以数据块的形式放在对应的 OSS 后端上面，Block 的使用需要配置一些相关的配置，可以在帮助文档里面详细的看。

有 JindoFS 的使用说明，最好使用较新的版本，有缓存模式、块模式的使用说明，具体可以参照官网上的使用文档。演示如何配置 HDFS 的块存储模式。

关于 Block 模式的使用，在 Namespace 的标签，就是把元数据标签，要注册 Space ，可以看到 jfs.namespaces 的配置。

比如定了叫 test 的 Namespace，另外还要加两个配置，一个是 mode，一个是 oss.uri 。要配置 OSS 的地址作为数据缓存块的放置地址。

由于是 Namespace 配置，所以 Namespace Service 要重启。

test  Namespace 可以使用了。

对应后面的一个使用方式也类似于 Hive 的示例，比如把 location 设成 jfs：//test 后某个目录这样的形式，location 在 jfs 的目录下。

Block 模式存储给大家一个直观的印象。

刚才上传 hello 文件，在 OSS 上面并不是一个 hello 的对象， OSS只是作为存储后端来放置数据块的，所有的元数据信息都是通过 Namespace 服务进行管理的。

四、云上云下互联

JindoFS 加速云下存储

前面三部分主要内容是如何在EMR集群上面利用计算存储分离的架构，使用 JindoFS 存储方案来实现数据上云，实现在 EMR 上的存储解决方案。

关于这一部分是针对另外一种很常见的场景来进行一些阐述，这是一种类似于云上云下打通的一个场景，经常存在的一个场景比如，用户原有、自建的或者线下的一些存储集群，多数来说都是使用 HDFS 来做大数据存储。随着业务的扩展，对用户来说计算资源可能是不够的，在这种情况下，线下的集群去扩容是很复杂的，需要去采购相应的机器，在线下机房里面去扩容来增加它的计算能力。

随着云上大数据的发展，线下客户的一个非常常见的思维是，对于多出来的计算资源可以选择上云利用云上的弹性可以很好的对于这些动态的计算资源进行相应的扩容、缩容，满足不同时间段的一个业务需求。存在的情况是计算机群是在云上的 EMR 集群。

实际的数据可能在云下的机房或者是在用户自建集群上的一个 HDFS 集群中。这时候假如需要在云上 EMR 集群需要分析云下的 HDFS 存储上面的数据，传统的做法是直接通过拿专线或者通过网络的方式去访问 HDFS。

这个带来的问题是由于 HDFS 并不是一个本集群的一个 HDFS，它可能是跨远端网络甚至是线下集群通过专线跨了专线的一个远端集群。核心HDFS 集群和计算集群其实也是一个分离的状态，在这种情况下比较新的 JindoFS 版本也提供可以对远端的一个 HDFS 集群进行加速的能力。

同样也是可以利用计算集群内的一些存储资源，包括本地的磁盘、本地的 memory 甚至还可以利用云上的一些存储资源，比如 OSS 在这种情况下可以利用 OSS 去缓存线下的 HDFS 集群数据。计算集群可以利用本地资源或者云上的资源去减少通过专线或者通过外部的网络去访问远端的 H的方式集群，减少数据拉取的过程，带来的好处主要是两点，一个是利用本地的存储资源，对远端 HDFS 集群进行缓存加速作用；

第二个通过 JindoFS 的缓存加速也可以进行留空操作，就是在二所示的步骤中可以从计算集群从远端的 HDFS 集群拉取数据，在这个过程中也可以通过 JidoFS 来进行流量控制，避免过多的流量导致把二路径的网络给打满，导致服务不可用或者异常的情况。针对线上线下的场景， JindoFS 也提供了一个 HDFS Cache 模式的方案，可以利用这个配置方式、存储方案，有效地实现云上云下的数据互通，从而实现一个高效的云上云下一体的存储方案。