本文汇总了使用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.enablefalse,Cache模式配置jfs.cache.data-cache.enablefalse

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

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

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

        添加参数的详情,请参见添加组件参数

      4. 重启Jindo Storage Service服务。

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

JindoFS如何手动下线节点?

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