【平台建设-01】Hadoop平台规划--软硬件选择篇

之前有很多朋友问我，你们的集群存储是怎么规划的，硬件配置如何选择，大致成本是多少？现在越来越多的企业都在规划搭建Hadoop平台。Hadoop测试集群搭建可以不需要考虑太多。但是线上环境，特别是一定规模的集群、涉及到硬件资源、.......





之前有很多朋友问我，你们的集群存储是怎么规划的，硬件配置如何选择，大致成本是多少？现在越来越多的企业都在规划搭建Hadoop平台。Hadoop测试集群搭建可以不需要考虑太多。但是线上环境，特别是一定规模的集群、涉及到硬件资源、网络规划，操作系统版本、软件版本等一系列问题，若没有相关经验看起来是比较复杂的。那么今天我就把这些问题简单梳理一下，希望对初建Hadoop集群的同学有一些帮助。

我们的集群规模应该多大？

Hadoop资源包含：存储和计算。前期你对计算资源其实很难评估，建议初期可以忽略计算资源的评估，单纯从存储这个指标来规划。那么我们的存储应该是多大？你需要去各个团队调研沟通，汇总一下现在每天产生的日志量大概有多少，确认一下我们的规划是1年还是半年。前期不建议规划太长时间，因为你现在能够了解到的信息量是比较少，很难做比较长期的规划。另外Hadoop集群后期水平扩展很容易，所以刚开始可以进行短周期的规划。我个人也比较推崇快速上线，逐步迭代，目的就是让我们快速增量的获取有价值的信息，快速做一些调整，能跑得更快更稳。

假设每天增长的数据为500G、我们3备份存储，以半年规划为例,大概存储为500G*3*180天=265T, 在这个基础上你还需要乘一个系数。 因为你要考虑给计算留一部分存储，给用户留一部分存储，考虑未来数据增长的趋势。此外还要考虑企业对这方面的投入意愿和财力现状。所以这个系数可根据企业现状进行灵活把握。当然你还要配合我们昨天的那篇文章：，要不然你的规划很合理，但是被用户不合理的资源利用了，那合理的规划就变得不合理了。

硬件配置如何选择？

硬件的选择实际上是需要我们回答以下两个问题：

1. 要高配还是低配？确定节点规模。
2. 单节点 cpu、内存、磁盘配比应当如何？

关于节点规模

节点多的话：要求的机柜就会多，这是一个成本，而且要考虑未来节点继续增长可能需要进行机房扩容，长远还要考虑到扩容成本和跨机房迁移的复杂度。

节点少的话：单个节点故障，不work的资源相对变多，100台机器挂掉一台，失去1%的计算能力；如果只有10台，那失去是10%的计算能力。

这和团队管理有点类似，你招的都是精兵，走掉一个，就得哇哇叫。不一样的是，管理的人越多成本越高，而Hadoop集群100台的规模和1000台规模管理成本差异不大。

在我们内部，目前基本还是控制节点数量，短期内有更重要的事情要去做，暂时绕开跨机房的问题，所以集群扩容是以提高单节点的配置方案为主。

关于单节点cpu 、内存、磁盘配比

我们Hadoop集群的硬件配置包含以下几种：



以上配置仅供参考！

初建集群还是建议使用主流硬件配置，Hadoop本身可以通过调整配置平衡资源的消耗。比如当存储不够了则就可以把压缩算法调整为高压缩比，拿cpu换存储；当cpu不足了可以将shuffle的压缩算法调整，以网络带宽来换cpu。根据我们运营Hadoop1.0的经验是:按照上图配置，内存是有富足。不过Hadoop2.0 的yarn框架可以接入各种计算资源，解决完一些技术问题，后续我们就可以引入一些内存计算框架如Spark，将多余的内存资源消耗掉，这也是我们为何后面配置升级继续将内存调大到64G。集群在进行扩容时可以根据具体的资源情况，再做一些配置调整。

另外关于机架感应,配置机架感应的目的是防止一个机架故障(掉电，掉网），导致一大片的节点不work。如果是小公司不会有太多机架，基本可以忽略不计。如果是大公司则需要考虑把Hadoop机器的节点与其他业务的机器混合部署在一些机架上。

操作系统该如何选择？

我们namenode是centos5.8，datanode前期上线都是5.8，后期有部分机器是6.2，但是这里面存在一些兼容性问题，你想了解是什么问题，可以回复Q5。如果从长远考虑未来在yarn上想使用docker资源，则可以上centos6.x系列；短期内追求稳定，可以使用centos5.8，我们集群使用centos5.8 稳定运营了2年多，集群规模支持到400个节点。

jdk 版本选择：jdk1.7稳定运行2年多没问题，我们使用的小版本为：1.7.0_07,供大家参考。关于升不升1.8，还是一个稳定性和新特性的权衡，大家有兴趣自己去实验，欢迎交流。

Hadoop版本该如何选择？

现在Hadoop的发行版包括：apache hadoop、Cloudera cdh，Hortonworks HDP 。后两者是商业团队在原生apache hadoop之上做一些优化和调整，关于这几个发行版之前的差异，大家可以参考其他文章。我们这边使用的是apache Hadoop，主要有以下两个原因:1.起步的早，最初这两个发行版本还不是很流行。2.我们有二次研发能力，可以紧跟社区脚步。

Hadoop最新release版本是2.6.0，新增了一些特性，但是都是beta，大家根据集群的用途看是否选择最新版本。现在初建的生产环境建议使用release 2.5.2 版本，2.5.0的版本新增的一些特性都是很不错，刚发布时官方就建议用户往这个版本升级。2.5.2则是一个专门fix bug的版本，应该比较稳定，并没有亲测。(笔者目前使用的版本是2.3.0，因Hadoop集群升级缺乏对社区发展动态的深入了解，所以上线当时最新的2.3.0，存在一些bug，上线没1周以后，社区就发布了2.4.0版本，后面只能自行修复bug，算是一个经验积累。)

具体的节点该如何分配？

Namenode： 内存要大，我们最早上线的是32G，导致文件数到6000W就扛不住了。建议初建集群直接上大内存，我们后面直接升级128G，cpu资源主要用于gc，磁盘空间不需要大，可做raid。 机器数量 2台，如果不上HA，1台就用来上SecondNamenode，初建集群根据团队的人力投入情况灵活把握是否上HA 。根据yahoo之前的数据统计，NameNode故障率比较低（当然运维支撑基础设置也要强大），多个集群3年出现过一次namenode宕机。

Resource Manager 1~2台 ：1台备用。RM架构把task的调度下放到AM，所以主要的服务就是进行job的调度，对机器资源要求不高。我们线上配置为32G内存，24核cpu，磁盘不需要大，可做raid。

客户端机器 1~N台 ，用于给用户提交作业，进行日常操作，根据团队的数量，资源使用情况可以灵活调配，我们的客户端都是由平台管理员统一管理，建议磁盘做raid，数据定期备份。

slaves 节点： 根据规划的资源，单节点配置情况，购置相应数量的机器。磁盘不做raid。

后续我们会专门从安全角度来聊聊各节点的拓扑分布。

麻雀虽小五脏俱全，不管你建多大的集群，基本的思路都是这么来的，只是集群规模不一样，企业现状不一样，投入的资源不一样，我们在一些细微的选择上会有一些差别。当你实战规划过一个20台集群的Hadoop之后，我想1000台集群你差不多也可以做了。

    关注 大数据梅峰谷