问题标签 [hadoop3]

我已经Hadoop 3.0.0安装了。我现在应该从此页面安装Apache Spark的with-hadoop或without-hadoop版本吗？

我正在按照本指南开始使用 Apache Spark。
它说

从此链接下载最新版本的 Apache Spark（根据您的 Hadoop 版本预构建）：...

但我很困惑。如果我已经在我的机器上运行了一个 Hadoop 实例，然后我下载、安装并运行 Apache-Spark-WITH-Hadoop，它不会启动另一个额外的 Hadoop 实例吗？

我已经用我的从节点的主机名更新了 Hadoop 主节点上的 /conf/slaves 文件，但是我无法从主节点启动从节点。我必须单独启动从属服务器，然后我的 5 节点集群启动并运行。如何使用来自主节点的单个命令启动整个集群？

此外，SecondaryNameNode 正在所有从属服务器上运行。那是问题吗？如果是这样，我怎样才能将它们从奴隶中移除？我认为集群中应该只有一个 SecondaryNameNode 和一个 NameNode，对吗？

谢谢！

我创建了如下表：

然后启用分区我设置了以下属性：

我创建的分区表如下：

创建表后，我发出插入查询为

但它不起作用..

同样在 Hive 1.x 上成功运行

根据 Hadoop 3.x 发行说明，他们引入了擦除编码来克服存储问题。

纠删码是一种持久存储数据的方法，与复制相比可节省大量空间。与标准 HDFS 复制的 3 倍开销相比，像 Reed-Solomon (10,4) 这样的标准编码有 1.4 倍的空间开销。

由于纠删码在重建过程中会产生额外的开销并且主要执行远程读取，因此它传统上用于存储较冷、访问频率较低的数据。用户在部署此功能时应考虑纠删码的网络和 CPU 开销。

我正在寻找相同的示例配置文件。

此外，即使在设置了 ec 策略并使用 启用它之后hdfs ec-enablePolicy，该策略是否仅适用于冷文件，还是默认实现以存储整个 hdfs 文件？

我正在尝试在使用此页面配置的 docker 容器中以伪模式运行 HDFS：https ://hadoop.apache.org/docs/current/hadoop-project-dist/hadoop-common/SingleCluster.html#Pseudo -Distributed_Operation，但我没有使用start-all.sh脚本，因为它不应该能够做 ssh，所以我手动运行命令bin/hdfs --daemon start namenode|datanode来一一启动它们。问题是我可以看到 namenode 成功启动，但是 datanode 没有任何错误消息。来自datanode的最后一条日志是：

core-site.xml文件：

并且hdfs-site.xml是

我错过了那里的任何东西吗？

我想使用 Spark 2.2 版和 Hadoop 最新版 3.1。我可以手动集成 Spark 和 Hadoop 吗？

我已经使用 Hadoop 2.6 或更高版本安装了 Spark 2.2，但我想更新 Hadoop。是否可以在带有 Hadoop 文件夹的 Spark 中找到 Hadoop 目录？

我已经下载了没有 hadoop 的 Spark 2.2 和 hadoop 3.1.0。两者都在运行，但是当我使用 hadoop_home 配置 spark.env.sh.template 文件时，它不起作用。任何人都可以分享正确的配置吗？

谢谢

HDFS 2.7 是 HBase 2.0.0 的默认版本。对于 HBase 稳定版，它是 2.5。我刚刚使用 3.1.0 版本启动了 HDFS 集群。如何让 HBase 使用它？我收到 hsync 错误消息。

编辑

我知道我必须替换所有这些 jar 文件？hadoop-*-2.7.4.jar 在此处输入图片描述

在 hadoop 2.0 中，默认的复制因子是 3。可接受的节点故障数是 3-1=2。
因此，在 100 个节点的集群上，如果一个文件被分成 10 个部分（块），复制因子为 3，则所需的总存储块为 30。如果包含块 X 及其副本的任何 3 个节点失败，则文件为不可恢复。即使集群有 1000 个节点或文件被分成 20 个部分，集群上 3 个节点的故障仍然可能对文件造成灾难性影响。

现在步入hadoop 3.0。
使用纠删码，正如 Hadoop 所说，它提供了相同的持久性和 50% 的存储效率。并且基于 Reed-Solomon 方法的工作原理（即对于 k 个数据块和 n 个奇偶校验块，至少应可访问 (k+n) 个块中的 k 个，以使文件可恢复/可读）
所以对于上面的同一个文件——有10个数据块，为了将数据效率保持在50%，可以添加5个奇偶校验块。因此，从 10+5 个块中，至少有 10 个块应该可供文件访问。而在 100 个节点的集群上，如果 15 个块中的每一个都存储在一个单独的节点上，那么如您所见，总共 5 个节点故障是可以接受的。现在在 1000 个节点的集群上存储相同的文件（即 15 个块）不会对可接受的节点故障的数量产生任何影响 - 它仍然是 5。
但这里有趣的部分是 - 如果相同的文件（或另一个文件）被分割分成 20 个块，然后添加 10 个奇偶校验块，然后在 100 个节点的集群上总共保存 30 个块，可接受的节点故障数为 10。

我想在这里说明的一点是 -
在 hadoop 2 中，可接受的节点故障数是 ReplicationFactor-1，并且显然基于复制因子。这是一个集群范围的属性。

但是在 hadoop 3 中，假设存储效率固定为 50%，那么对于不同的文件来说，可接受的节点故障数似乎是不同的，具体取决于它被分成的块数。

那么，如果上述推论正确，任何人都可以发表评论吗？以及如何确定任何集群可接受的节点故障？

（而且我不想让它在上面变得复杂，所以没有讨论只有一个块的文件的边缘情况。但我猜该算法将足够聪明，可以按原样复制它或使用奇偶校验数据复制它，以便数据持久性设置得到保证。）

编辑： 这个问题是我对 EC 提出的一系列问题的一部分 - 其他问题如下 -
Hadoop 3.0 擦除编码：对 MR 作业性能的影响？

我试图了解擦除编码可能对文件的读取性能产生的影响。

在此之前，简要总结了使用 Reed-Solomon 方法的 Hadoop 3.0 擦除编码。如果将分割成 k 个块的文件编码为 p 个奇偶校验块，则在 k+p 个块中，至少任何 k 个块必须可用于重新创建文件。在 Hadoop 2.0 中，默认复制是 3，因此 10 个块的文件需要集群上 30 个块的空间。Hadoop 3.0 声明它提供了 50% 的空间减少，因此存储在 3.0 上的相同 10 个块应该只需要 15 个块，即额外的 5 个块可以用作奇偶校验块。

在 Hadoop 3.0中 - 具有 10 个块的文件 (file1) 将导致 5 个奇偶校验块（将 3.0 中的 EC 数据改进为 50%）。假设原始的 10 个数据块存储在从 n0 到 n9 的节点上，而 5 个奇偶校验块存储在节点 n10 到 n14 上。现在对该文件的读取操作肯定应该从前 10 个节点（即 n0 到 n9）获取数据，因为从具有奇偶校验块的节点获取数据可能需要更多时间，因为它涉及解码（对吗？？）。

接下来，此文件可接受的节点故障数为 5。

如果节点 n10 - n14 失败（这些是具有奇偶校验块的节点）。读取操作的性能（由于节点故障）不会受到影响，性能与上述场景相同。

但是如果节点 n5 到 n9 发生故障，那么我会猜测这种情况下的读取性能会低于上述情况下的性能。

但是在 2.0 中，只要节点故障的数量小于 ReplicationFactor-1，无论哪个节点发生故障，您都可以获得相同的性能。

问题是：是否应该将上述因素（擦除编码）也添加到可能影响 3.0 中读取性能的因素集中

我正在尝试在 Ubuntu 18 机器上创建 hadoop 3.1 集群。我正在按照这里给出的步骤 Hadoop 集群步骤，目前我只设置了一台机器，但是当我尝试运行像“hadoop version”或“hdfs namenode -format”这样的命令时，我收到以下错误：

*无法识别的选项：-

错误：无法创建 Java 虚拟机。

错误：发生了致命异常。程序将会退出。*