hadoop调整vcore_调整Hadoop和Cassandra：提防vNode，拆分和页面

hadoop调整vcore

当针对Cassandra运行Hadoop作业时，您将需要注意一些参数。

具体来说，请特别注意vNode，拆分和页面大小。

vNode是在Cassandra 1.2中引入的 。 vNode允许主机拥有令牌范围的多个部分。 这允许更均匀地分布数据，这意味着节点可以分担节点重建的负担（并且它不会全部落在一个节点上）。 而是将重建分布在多个节点上。 （很酷的功能）

但是，vNode使Hadoop的工作变得有些棘手……

第一次去使用CQL运行Hadoop作业时，我是在具有大量vNode（〜250）的Cassandra上运行本地Hadoop群集（仅一个容器）。 我已经完成了几千条记录的简单工作（可能是字数统计）。 我希望这项工作能在几秒钟内完成。 令我感到沮丧的是，这是永远的。

运行Hadoop作业时，拆分的最小数量是vNode的数量。

在Hadoop中，每个拆分都由一个容器使用，并且一个容器一次只能针对一个拆分运行。 实际上，Hadoop容器是一个JVM，它被启动以处理特定的数据拆分。

在任何Hadoop集群中，都有最大数量的可用容器。 就我而言，我有一个可用的容器，这意味着必须按顺序处理拆分，每个拆分的旋转和拆解开销都很大。 嘘...

因此，在执行任何操作之前，请检查您正在运行的vNode数。 这由您的Cassandra yaml文件控制。 有一个num_tokens参数。 以下是cassandra.yaml的节选。

# This defines the number of tokens randomly assigned to this node on the ring
# The more tokens, relative to other nodes, the larger the proportion of data
# that this node will store. You probably want all nodes to have the same number
# of tokens assuming they have equal hardware capability.
...
# If you already have a cluster with 1 token per node, and wish to migrate to
# multiple tokens per node, see http://wiki.apache.org/cassandra/Operations
num_tokens: 25

要查看现有集群上有多少个vNode，可以使用nodetool：

➜  cassandra  bin/nodetool ring
Datacenter: datacenter1
==========
Address    Rack        Status State   Load            Owns                Token
                                                                          8743874685407455894
127.0.0.1  rack1       Up     Normal  41.27 KB        100.00%             -8851282698028303387
127.0.0.1  rack1       Up     Normal  41.27 KB        100.00%             -8032384077572986919
127.0.0.1  rack1       Up     Normal  41.27 KB        100.00%             -7279609033604637725
...
127.0.0.1  rack1       Up     Normal  41.27 KB        100.00%             8107926707118065773
127.0.0.1  rack1       Up     Normal  41.27 KB        100.00%             8743874685407455894

您会注意到令牌范围的数量等于您在配置文件中设置的数量：

➜  cassandra  bin/nodetool ring | grep rack1 | wc -l
      25

有关vNode和配置的更多信息，请参见Patrick最出色的资料：

• http://www.slideshare.net/patrickmcfadin/cassandra-virtual-node-talk

旁白：由于拆分的最小数量是vNode的数量，因此您可能希望运行一个单独的Cassandra环，使用较少的vNode进行分析。

好的，这意味着什么，以及如何解决？

好吧，如果您的容器数量少且vNode数量多，则拆分开销可能会成为问题（就像在我的本地Hadoop集群中一样）。 但是，也许更重要的是，如果您要处理大量记录并使用默认的拆分大小，那么最终将导致疯狂的拆分。 例如，我们最近遇到了一个有50亿条记录的表。 默认拆分大小为64K。

[1]做数学：

# of rows / split size = # of splits
5B / 64K = 78,125 splits!

这是一个非常糟糕的拆分，您将为每个拆分承担开销的向上旋转/撕下代价。 即使假设每次拆分仅花费5秒钟的时间，那也需要大量时间：

78125 * 10 seconds  / 60  / 60  = ~100 hours of overhead (NOT GOOD!)

最佳地，拆分的数量将等于可用容器的数量。 通常这是不可能的，但是我们可以通过以下行在Hadoop作业上设置拆分大小来尽可能接近：

org.apache.cassandra.hadoop.ConfigHelper.setInputSplitSize(job.getConfiguration(), 10000000); // splitSize = 10M

让我们使用该值重做数学：

5B / 10M = 500 splits (MUCH BETTER!)

如果我们在具有250个可用容器的Hadoop集群上运行，则将在拆分上进行两次传递，每个容器将处理两个拆分。

计算出拆分大小后，您将需要注意页面大小参数。 页面大小参数告诉CQL驱动程序一次要返回多少行。 它等效于CQL语句上的LIMIT子句。 对于这一点，您将希望在不消耗内存的情况下尽可能多地向后拉。 （我已经完成了；）页面大小的默认值为1000。要配置页面大小，请使用以下行：

CqlConfigHelper.setInputCQLPageRowSize(job.getConfiguration(), Integer.toString(100));

希望这可以节省一些时间。 调整愉快。 （向gnana大喊；）

翻译自: https://www.javacodegeeks.com/2015/04/tuning-hadoop-cassandra-beware-of-vnodes-splits-and-pages.html

hadoop调整vcore