问题标签 [cloudera-cdh]

一段时间以来，我一直在我的 Mac 上使用 Hadoop (CDH 4.5)，并定期运行 map reduce 作业。我最近按照以下说明安装了 oozie（再次是 CDH4.5）：http: //archive.cloudera.com/cdh4/cdh/4/oozie-3.3.2-cdh4.5.0/DG_QuickStart.html，并尝试运行示例提供的程序。但是，它总是失败并出现以下错误。看起来工作流程根本没有运行。作业信息中的控制台 URL 字段也是空的。

有人可以帮忙吗？

Oozie Job 日志的相关片段如下。

Accumulo 实例无法启动并出现以下错误 - 任何帮助将不胜感激

我有一台具有以下配置的服务器机器。1) 双四核至强 2) 24 GB 内存 3) 500 GB Sata 4) 256 * 2 RAID 1

机器刚到，我们想在里面安装 CDH5。我们要创建一个沙盒/开发集群。我正在寻找一些专家的建议

我们对这个过程相当陌生。任何帮助都会非常有帮助。

谢谢，阿米特

yarn.nodemanager.local-dirs 文件夹的文件权限应该是什么？我弄乱了这些文件的权限，无法解决。目前我已将文件夹权限设置为 755 yarn:hadoop。每当我尝试运行节点管理器时，都会遇到 EPERM: Operation not allowed 错误。细节 -

尝试启动失败后，local-dirs 文件夹包含以下文件夹 - filecache、nmPrivate、3 usercache_DEL_timestamp。根据错误的位置（ResourceLocalizationService.java，第 233 行），三个可能的操作可能会引发此错误 -
a) 清理旧文件 - 这有效，如日志输出所示
b) 创建新文件 - 启动尝试失败后，我在local-dirs中看到了三种文件——三个usercache_DEL_*、filecache、nmPrivate文件。
c) 制作日志路径 - 我检查了日志文件夹以获得 yarn:hadoop 的 775 权限。

可能出了什么问题？我正在使用 Cloudera 来管理我的集群。

我将设置一个本地集群，我打算在其中使用 CDH5。有了这个，我将拥有所有内置的 hadoop 生态系统，但是我的集群中也需要 Rscript 来进行一些 hadoop 流和数据分析工作。所以只是想知道是否可以使用 CDH5 并安装 R 脚本。谢谢

这个错误是什么意思？“ 元数据错误：org.apache.thrift.transport.TTransportException？” 在什么情况下会出现这个错误？

在创建表和将数据加载到表中时出现此错误。

我使用 cloudera 的 hadoop 发行版在多 peta 字节集群中运行 map reduce 作业。我看到一些地图卡在 100%。它们显示为 100%，但继续运行。经过大量的延迟，他们终于成功了，但这需要很多时间，比如有时他们从显示为 100% 的时间开始需要几个小时。

我正在使用Hadoop 2.2.0并发现hdfs组权限配置不像 linux 文件系统那样工作

该目录属于用户data和组data。raw然后，当作为 group 成员的另一个 userdata尝试列出目录/user/data时hdfs，会引发以下异常：

知道为什么吗？

在 spagoBI studio 和 hive（CDH5/CDH4）之间创建 JDBC 连接时，这是我的日志：-

一些相关的问题hive methos not supported，“java.sql.SQLException: Method not supported which says

您的原始错误来自使用 Cloudera 的 Hive 驱动程序，该驱动程序未实现 PDI 正常运行所需的许多 JDBC API 方法。这就是为什么我们在 cdh4 文件夹中拥有自己版本的 hive 驱动程序（称为 hive-0.7.0-pentaho-1.0.2 或类似名称）。简而言之，不应该有从集群复制到 PDI 客户端的 JAR，cdh4 文件夹已经包含所有必要 JAR 的正确版本。

但我没有找到任何用于 CDH5/CDH4 的 spagoBI hive 驱动程序。我能够连接到 hive，但是在访问工作室中的表时出现错误，我可以访问 spagoBI 服务器上的表。任何帮助，谢谢。

我们有一个运行 CDH5.0.2 的四数据节点集群，通过 Cloudera Manager 包安装。为了将 13M 用户的行导入 HBase，我们编写了一个简单的 Python 脚本并使用了 hadoop-streaming jar。它可以按预期工作多达 100k 行。然后......然后，一个接一个地，所有数据节点都崩溃并显示相同的消息：

任何按照网络上的建议（例如[1]、[2]、[3]）解决问题的尝试都不会导致任何接近解决方案的地方。用 java 堆大小“玩”是没用的。唯一“解决”这种情况的是将区域服务器的垃圾收集持续时间监控周期从 5' 增加到 50'。可以说是一个肮脏的解决方法。

我们现在没有人力来为我们的 GC 使用情况创建监视器。我们最终会的，但我想知道将 13M 行导入 HBase 怎么可能导致所有区域服务器肯定崩溃。有干净的解决方案吗？

编辑：

Datanodes 上的 JVM 选项有：

-XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:-CMSConcurrentMTEnabled -XX:CMSInitiatingOccupancyFraction=70 -XX:+CMSParallelRemarkEnabled

Datanodes 是运行 CentOS 6.5 的物理机器，每台都有 32Gb 内存和 2GHz 的 1Quadcore 和 30Mb 缓存。

下面是我们运行的 Python 脚本的摘录。我们填充了两个表：一个具有唯一用户 ID 作为行键，一个包含用户信息的列族，另一个具有我们可能希望作为行键访问的所有信息。