本文汇总了使用SmartData时的常见问题。

基本概念

开源和生态

升级和迁移

已知版本问题汇总

OSS相关

安全相关

使用问题汇总

JindoFS如何手动下线节点？

什么是JindoFS？

JindoFS是阿里云开源大数据E-MapReduce产品提供的一套Hadoop文件系统，主要对Hadoop和Spark大数据生态系统使用阿里云OSS提供多层次的封装支持和优化。

基础功能提供适配OSS和支持访问，您可以直接使用JindoFS SDK；标准功能针对OSS提供分布式缓存优化，以对应JindoFS缓存模式；高级功能上针对使用OSS一些特殊或重要场景进行了深度定制，例如，JindoFS Block模式。

已经有阿里云OSS，为什么还要使用JindoFS？

阿里云OSS是对象存储系统，提供基于对象语义的REST API和各种语言SDK封装。JindoFS主要是对阿里云OSS提供HCFS（Hadoop Compatible FileSystem）接口封装，并且在此基础上提供缓存加速能力和高级优化定制的功能。因为Hadoop和Spark生态组件依赖HCFS的抽象接口，所以需要使用JindoFS。

JindoFS有哪些使用方式？使用场景是什么？

JindoFS使用方式包括JindoFS SDK（jindo-sdk_xxx.jar）、缓存和Block模式。

针对三种方式，使用场景如下：
  • JindoFS SDK模式：简单情况下，您可以使用此模式，上传JindoFS SDK的JAR包至组件的classpath目录。
  • 缓存模式：当计算性能受限于IO和存储吞吐时，您可以使用此模式，在计算集群的Core节点上增加或扩容磁盘，以开启数据缓存。
  • Block模式：特殊场景，例如对元数据操作性能和一致性要求高时，使用此模式。

JindoFS SDK和缓存模式的区别是什么？

JindoFS SDK和缓存模式完全兼容阿里云OSS，通过这两种方式您可以通过OSS产品提供的API和SDK，直接读取写入OSS的文件。

缓存模式需要部署和配置Jindo分布式缓存服务，打开数据缓存开关，而JindoFS SDK则不需要。如果缓存服务出现故障，系统自动切换至JindoFS SDK方式，直接读写OSS文件。

JindoFS缓存模式和Block模式的区别是怎么？

Block模式可以管理文件的元数据，组织数据的块，把OSS作为磁盘来使用，类似HDFS。读写Block模式的数据需要通过JindoFS SDK 客户端。

缓存模式兼容OSS，可以直接读写数据。例如，您通过缓存模式写一个大文件，可以在OSS控制台对应目录下找到这个大文件。如果是块缓存模式时，您只能找到很多文件块，这些块只能通过JindoFS SDK 客户端拼接成大文件。

如果更新了OSS上的数据，如何保证JindoFS缓存数据的一致性？

如果OSS对象被修改、覆盖或删除，JindoFS在读取OSS对象的时候，首先会检查OSS对象的Meta信息和MD5，然后对比本地缓存的信息，检查是否发生了变化。如果发生了变化，本次读取放弃本地缓存直接读取OSS，并更新缓存。

JindoFS Block模式可以通过OSS API读取数据吗？

不可以。只能通过JindoFS SDK客户端读取数据。

对象存储OSS不支持Rename操作，那JindoFS支持Rename操作吗？

支持。因为JindoFS支持HCFS文件系统接口，所以支持文件和目录的Rename操作。

对象存储OSS因为没有文件和目录的概念，所以不支持文件和目录的Rename操作，需要通过模拟文件系统的方式来实现Rename操作（先拷贝对象至新位置，再删除旧的对象）。

JindoFS的Rename性能如何？

JindoFS的Rename性能优于社区版本。如果是文件，OSS支持大对象 Fast Copy 优化，JindoFS 利用该优化做到比社区版本快很多；如果是目录，涉及到很多文件，JindoFS通过充分并发优化，也比社区版本快多倍。

JindoFS支持类似于Hadoop S3A的Magic Committer吗？

JindoFS支持无需Rename操作的Magic Committer。

JindoFS对百万千万级文件数目录的支持情况如何？

针对百万千万级文件数的大目录，JindoFS支持并发访问和内存优化，不会出现OOM（Out Of Memory）或者挂起。

JindoFS是如何保证数据可靠性的？

因为JindoFS无论使用哪种方式，数据都存放在OSS上，本地磁盘只缓存数据，所以数据可靠性是由OSS来保证的。

JindoFS支持文件和目录操作的一致性吗？

支持。JindoFS Block模式实现HDFS文件系统语义，支持强一致性。

JindoFS支持文件和目录操作的原子性吗？

JindoFS Cache模式不支持原子性。JindoFS Cache模式因为要兼容OSS，受限于OSS对象存储限制，不支持跨对象操作的原子性。例如Rename操作，至少涉及到源和目标两个对象，如果是目录的Rename，涉及的对象更多。

JindoFS Block模式严格实现HDFS文件系统语义，支持原子性，包括Rename操作。

JindoFS Block模式如何保证HA？

JindoFS Block模式基于Raft分布式一致性协议可以部署多个Jindo NamespaceService节点，并且元数据的更新支持异步备份至阿里云Tablestore数据库上。

JindoFS Block模式在集群上保存文件元数据，重建集群时数据怎么处理？

JindoFS Block模式的元数据的更新支持异步备份至阿里云Tablestore数据库上，在确保生产集群停止更新，所有修改同步至Tablestore后，可以停掉JindoFS集群，此时，所有数据在OSS和Tablestore上。重建集群时，恢复OSS和Tablestore上数据至重建集群。
说明 重建集群时，需要考虑版本的兼容性。例如，EMR-2.7.x版本之间都是兼容的，但EMR-2.7.x和EMR-2.6.x之间则不一定。如果是升级到不兼容的大版本时，建议通过Jindo DistCp同步Block模式数据至OSS。

EMR已经支持HDFS，为什么还要有JindoFS Block模式？

JindoFS Block模式从技术架构和功能上确实和HDFS相似，都是自定义管理文件元数据并组织数据，具有强一致性。

JindoFS Block模式的优势在于，数据备份至OSS上，支持弹性扩展、低成本且无需维护磁盘。

JindoFS和Alluxio相比有什么技术差异和优势？

对比项 JindoFS Alluxio
相同点 JindoFS缓存模式在技术架构上与Alluxio类似，都提供对OSS的缓存加速能力，支持Master + Workers形式，Master维护缓存块的位置信息，Workers提供缓存块的管理和读写能力。
不同点 JindoFS不需要挂载，可以直接访问oss://路径，只需打开数据缓存开关即可。 Alluxio需要先挂载OSS Bucket位置至名字空间，再使用alluxio://访问
JindoFS核心支持的是OSS，性能优化。 Alluxio支持数据源很多，可以同时挂载到统一的名字空间。
JindoFS提供基础的SDK模式支持访问适配 OSS，全面对接各种开源引擎。 无

跟HDFS相比，使用JindoFS和OSS能节省成本吗？

HDFS存储时，不能弹性伸缩，预算不足就会面临存储空间不足，或者存在空间浪费的情况。

阿里云OSS是海量对象存储，支持弹性伸缩，具有归档存储功能，可以备份冷数据。JindoFS基于OSS，支持数据冷热分层和数据归档存储策略，使用得当，整体上可以降低成本。

Hadoop社区版本也提供OSS支持，JindoFS有什么优势？

Hadoop社区版本支持的OSS，受到社区整体约束，只具备OSS基本适配功能。

JindoFS对OSS的支持优势如下：
  • 更全面：对接各种开源引擎。
  • 更活跃：对OSS的新功能提供同步更新和升级。
  • 更高级：具有高阶缓存加速能力和高级定制功能Block模式。
  • 更快：性能更优。JindoFS核心代码采用C++ native代码开发，各种基本操作性能优于社区版本。

JindoFS提供Fuse支持吗？和OSS自带的Fuse有什么优势？

提供。JindoFS提供的Fuse优势在于能够利用JindoFS分布式缓存和Block模式功能。

JindoFS支持哪些开源组件？

支持按照HCFS接口读写数据的组件，例如，Hadoop、Hive、Spark、Flink、Presto、HBase、Impala、Druid、Kafka和Flume。

JindoFS吞吐如何？会不会影响Spark或Hive大规模分析计算？

JindoFS在适配上充分发挥OSS并发吞吐能力，实现异步并发读取，利用Concurrent Multipart Upload特性进行并发分块写入，在读写吞吐上面比社区版本具有较大优势。

JindoFS缓存模式和Block模式可以利用集群本地磁盘或内存来缓存数据，对于新写入的数据和重复读取的数据具有显著加速效果。在同样集群条件下，对于Spark或Hive分析计算，跟HDFS相比集群吞吐是相当的，甚至优于HDFS。

JindoFS写性能如何？

因为HDFS需要写三备份才算写入成功，JindoFS只需写入OSS一备份就算写入成功，所以通常情况下，JindoFS写性能优于HDFS。

JindoFS支持Flink实时计算场景吗？

支持。JindoFS支持Flink读OSS source，checkpoint和sink到OSS以及Exactly-Once语义。

JindoFS和OSS场景下，可以使用Presto做交互式分析吗？

可以。JindoFS缓存模式和Block模式都支持Presto交互式分析，且性能稳定。

使用Impala时，可以通过JindoFS查询OSS上的数据吗？

可以。Impala 3.4及后续版本支持JindoFS，可以读写OSS。

JindoFS支持使用Delta Lake，或者Hudi和IceBerg时，存放数据在OSS上吗？

支持。

数据存放在OSS上，JindoFS支持机器学习训练吗？

支持。您可以使用JindoFS缓存模式，通过预加载将OSS数据提前写入内存或者SSD做缓存，然后训练引擎可以通过JindoFuse支持直接读取。

基于MaxCompute数仓上的数据，JindoFS如何帮助机器学习训练？

有如下两种方式：
  • MaxCompute数仓作业将数据通过MaxCompute外表方式写入至OSS，然后在训练集群通过JindoFS缓存模式和JindoFuse来加载训练。
  • 通过JindoTable从MaxCompute拉取数据写入至JindoFS缓存模式，然后使用JindoFuse来加载训练。

基于Hive数仓上的数据，JindoFS如何帮助机器学习训练？

类似于MaxCompute数仓上的数据处理方式，方式详情请参见基于MaxCompute数仓上的数据，JindoFS如何帮助机器学习训练？。

如果使用JindoFS，如何迁移HDFS上的数据？

您可以使用Jindo DistCp同步HDFS数据至JindoFS或OSS。Jindo DistCp比Hadoop DistCp性能高，且支持OSS归档。

JindoFS在新版本才有，如果需要在EMR集群上使用JindoFS，该如何处理？

如果集群规模不大，建议重建集群来使用JindoFS和EMR新版本。

JindoFS支持哪些Hadoop版本和发行厂商？

JindoFS SDK提供OSS适配功能，明确支持Hadoop 2.7后续版本和Hadoop 3.x版本。

Hortonworks版本（Hortonworks Data Platform，简称HDP）和Cloudera版本（Cloudera’s Distribution Including Apache Hadoop，简称CDH）都可以使用，但可能会存在冲突，需要修改配置fs.oss.impl = JindoOssFileSystem。

JindoFS可以在ECS自建集群上使用吗？

可以。需要您下载JindoFS SDK手工部署即可。如果您需要使用JindoFS缓存模式和Block模式功能，建议您登录阿里云E-MapReduce控制台，直接使用E-MapReduce产品。

JindoFS可以在阿里云ACK环境上使用吗？

可以。

使用JindoFS会被阿里云E-MapReduce绑定吗？

不会。JindoFS遵循标准HCFS接口，兼容和支持全面开源生态，不会绑定。

JindoFS可以在IDC机房的Hadoop集群使用吗？

可以。您可以直接下载开源JindoFS SDK按照文档部署使用即可。

如何查看JindoFS上的数据量？

您可以直接使用如下命令查看统计情况。
hadoop dfs -du/count

什么情况下建议打开OSS Bucket的多版本控制？

对于重要的数据建议打开OSS Bucket多版本，防止误删时数据不丢失。

打开OSS Bucket多版本控制对EMR和JindoFS的影响是什么？

对于Hive或Spark中间结果存放的数据以及频繁修改的数据，不建议使用多版本Bucket，会影响计算性能。

OSS归档存储可以大量节省存储成本，JindoFS提供相应的支持吗？

JindoFS支持相应的OSS归档存储。Block模式上，提供专门的存储策略与OSS归档匹配。

使用JindoFS，会泄露AccessKey吗？

JindoFS支持在集群上配置使用AccessKey，但存在泄漏AccessKey的风险。在EMR集群里或者在ECS环境，如果节点绑定了ECS role，您可以使用权限管理，不使用AccessKey。

什么是AccessKey免密？

EMR集群提供AccessKey免密，该功能通过EMR管控得到用户授权，方便用户拿到具有权限的阿里云STS (Security Token Service) ，然后使用该 Token访问阿里云资源，例如OSS。

如果支持AccessKey免密，那如何区分不同的用户和权限限制？

AccessKey免密不是适用于所有的场景。

如果有多个用户需要区分权限，有如下两种方式：
  • 您可以通过RAM用户权限控制，每个用户使用RAM用户来访问OSS。
  • 您可以使用JindoFS权限控制，通过Ranger来授权。
    重要 JindoFS仅能在Namespace上设定权限控制。

如何使用不同的AccessKey，通过JindoFS访问不同的OSS Bucket？

您可以使用JindoFS multi namespace，每个Namespace配置不同的OSS bucket和对应的AccessKey信息。

在无EMR管控支持情况下，想使用自建的IDC集群，又不想在集群节点上配置AccessKey，该如何处理？

您可以使用Hadoop Crendential Provider机制，详情请参见Credential Provider使用说明。

JindoFS支持Auditlog吗？

支持。JindoFS支持Multi Namespaces，每个Namespace上可以设定Auditlog，默认不打开。

JindoFS支持Ranger集成吗？

支持。JindoFS支持Multi Namespaces，每个Namespace上可以设定支持Ranger，默认不打开。

EMR中的SmartData和JindoFS是什么关系？

SmartData是产品组件，该组件包括JindoFS服务。

EMR中的Bigboot和JindoFS是什么关系？

Bigboot是SmartData组件的基础设施，对该组件所包含服务提供毫秒级进程监测和日志清理等功能。

如何处理Bigboot日志占用过大的问题？

EMR-3.36.1或EMR-5.2.1之前的版本，会出现Bigboot日志占用过大的问题。当您觉得Bigboot占用日志过大时，针对已有的日志文件需要您手动删除，后续您可以参照以下步骤新增配置，将日志级别由INFO修改为WARN，以减少打印过多的日志信息。

  1. 在EMR控制台新增配置。
    1. 在SmartData服务的配置页面，单击namespace页签。
    2. 单击自定义配置。
    3. 在新增配置项对话框中，添加参数名为logger.level，参数值为1的配置项。logger
      说明 此处的日志级别默认为0表示INFO，修改为1表示WARN。
    4. 单击确定。
  2. 保存配置。
    1. 单击保存。
    2. 在确认修改对话框中，输入执行原因，单击确定。
  3. 重启Jindo Namespace Service。
    1. 在右上角选择操作 > 重启Jindo Namespace Service。
    2. 在执行集群操作对话框中，输入执行原因，单击确定。
    3. 在确认对话框中，单击确定。

/opt/bignode目录占用巨大并持续增长，该如何处理？

  • 问题现象：通常情况下，/opt/bignode目录正常大小应该是几个GB，但SmartData 2.x版本，/opt/bignode目录占用巨大，并且出现磁盘占用过大并持续增长的情况。
  • 问题原因：可能是由于监控进程异常退出，导致对Jindo Storage Service进程状态监控异常，从而不断重复拉起进程导致的。
  • 处理方法：您可以通过以下步骤排查并处理。
    在出现问题的节点上，以root用户执行以下命令，查看进程信息。
    ps -aux | grep b2-storageservice | grep -v grep
    通常情况下应该有两个进程，分别是xxxx/services/b2-storageservice.spec和xxxx/bin/b2-storageservice。如果缺少xxxx/services/b2-storageservice.spec进程，则可以确认是监控进程异常退出导致的，需手动终止xxxx/bin/b2-storageservice进程。
    kill -9 <PID of b2-storageservice>
    说明 <PID of b2-storageservice>为您查看进程信息时，查询到的xxxx/bin/b2-storageservice进程的进程ID。

    执行以上命令后，监控进程会自动拉起新的Storage Service服务，目录占用会自动恢复正常。

读缓存时数据出错，该如何处理？

  • 问题现象：SmartData 3.0至SmartData 3.7版本，使用JindoFS Block模式（Block模式默认启用缓存），或者使用Cache模式并打开了缓存的情况下，生成数据时没有问题，但读取数据时出现内容污染的现象，例如，作业对格式源数据（ORC或Parquet）报格式错误、HBase报HFile格式错误等。
  • 问题原因：可能是遇到了缓存数据块读取流程上的程序已知缺陷，误读了错误的缓存数据块导致的。
  • 处理方法：您可以通过以下方式进行快速恢复处理，并联系EMR对历史版本程序进行升级修复。
    请根据实际需求选择以下方式，快速规避该缺陷，避免对业务产生持续影响。
    • 方式一：关闭缓存。

      通常该缺陷是缓存数据导致的，通过关闭缓存可以彻底避免该问题。您可以在SmartData服务的client配置页面通过配置关闭缓存，Block模式配置jfs.data-cache.enable为false，Cache模式配置jfs.cache.data-cache.enable为false。

    • 方式二：对报错文件进行缓存清理。

      如果出于性能等方面考虑，不适合关闭缓存，可以选择此方式。

      1. 执行以下命令，提交缓存清理任务。
        jindo jfs -uncache <报错文件全路径>
      2. 执行以下命令，查看任务状态，并且确定报错文件的缓存已清理完成。
        jindo jfs -status <报错文件全路径>
      3. 在SmartData服务的client配置页面，添加自定义配置项storage.compaction.enable为false。

        添加参数的详情，请参见添加组件参数。

      4. 重启Jindo Storage Service服务。

        重启Jindo Storage Service服务的详情，请参见重启服务。

JindoFS如何手动下线节点？

手动下线节点的命令格式如下。
jindo jfs -decommission <excludeFile>
说明 命令中的<excludeFile>为新建的文件，文件中的内容是待下线节点的主机名称，每行代表一个待下线的节点，节点主机名称您可以通过hostname命令获取。文件内容格式如下。
emr-worker-1.cluster-29****
emr-worker-2.cluster-29****