Cloudera Hadoop-企业级大数据平台设计

　　　　　　　　　　　　Cloudera Hadoop-企业级大数据平台设计

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　作者：尹正杰

版权声明：原创作品，谢绝转载！否则将追究法律责任。

 

 

一.浅谈企业级大数据平台的重要性

1>.缺乏统一大数据平台的问题

大数据思维需要依托大数据技术的支撑才能得以实现，所以隐藏在背后的支撑平台非常重要。正所谓下层基础决策决定上层建筑，没有一个牢固的地基是建不成摩天大楼的。我们不妨设想一下作为一个头上大数据领域的企业，如果没有一个统一的大数据平台会出现什么问题。

（1）资源浪费
　　　　通常在一个企业内部会有多个不同的技术团队和业务团队。如果每个团队都搭建一套自己的大数据集群，那么宝贵的服务器资源就这样随意地分割成若干个小块，没有办法使出合力，服务器资源的整体利用率也无法得到保证。这种做法无疑是对企业资源的一种浪费。
　　　　其次大数据就去那设计的技术繁杂，其搭建和运维也是需要学习和运营成本的。这种重复的建设费时费力且没有意义，只会造成无谓的资源浪费。

（2）数据孤岛
　　　　如果企业内部存在多个分散的小集群，那么首先各种业务数据从物理上便会被孤立存储于各自的小集群之中，我们就没有办法对数据进行全量的整合使用，数据便失去了关联的能力，大数据技术使用全量数据进行分析的优势也丧失了。
　　　　其次，在这种情况下，也难以实现对业务数据进行统一的模型定义与存储，一些相同的数据被不同的部门赋予了不同的含义，同一份数据就这样以不同的模型定义重复地存储到多个集群之中，不仅造成了不必要的存储资源浪费，还造成了不同部门之间的沟通成本的增长。

（3）服务孤岛
　　　　企业内部各自为政的小集群的首要任务是支撑团队或项目组自身的业务场景来满足自身需求，所以在实现功能的时候不会以面向服务的思维来抽闲提炼服务，很可能都没有可以暴露出来龚小集群外部使用的服务。
　　　　退一步将就算这些小集群有提供出来的服务，那么它们也缺乏统一的顶层设计，在做服务设计到时候没有统一的规则，导致提供的服务参差不起，其访问入口也很有可能不统一。同时这些服务被分散在不同的集群中，应用程序不能跨越多个集群使用所有的服务。

（4）安全存疑

　　　　企业内部各项组成团队自身维护的小集群通常都只为支撑自身业务而实现的，不会同时面对多个用户。企业通过一些行政手段可以在一定程度上保障集群的安全。但是当团队人员扩充，集群规模扩大或者是大数据集群的服务同时面向多个技术团队和业务部门的时候，很多问题就会显漏出来。
　　　　首当其冲的便是需要面对多用户的问题，集群不在只有一个用户，而是需要main 对多个不同的用户。这就自然而言地印出了一些列需要切实面对和解决的问题，比如用户的管理，用户的访问控制，服务的安全控制和数据的授权等。小集群通常都处于“裸奔状态”，基本没有什么安全防护的能力。集群安全涉及方方面面，是一个非常复杂的系统工程，不是轻易能够实现的。
（5）缺乏可维护性和可扩展性
　　　　大数据领域的技术发展日新月异，其本身正处于一个高速的发展期，我们的集群服务会不时需要进行更新获得新的能力，或是需要安装补丁以修复Bug。在这种情况下对多个小集群进行维护就会变得非常麻烦。同时当某个小集群性能达到瓶颈的时候也没有办法很容易做到横向扩容。

（6）缺乏可复制性
　　　　各自为政的小集群缺乏统一的技术路线，导致大数据集群的运维工作会缺乏可复制性。因为一个部门或者一个团队与其他部门使用的技术组件可能完全不一样，这样一个集群的安装，维护和调试等经验就没有办法快速复制和推广到其他部门团队或部门。
　　　　同时在大数据应用研发方面也会存在同样的问题，正常来讲我们做过的项目越多，从项目中获得的经验也就越多，我们能从这个过程中提炼，抽象和总结一些经验，规则或是开发框架来帮助我们加速今后的应用研发。但是技术路线的不统一很可能导致这些经验丧失后续的指导意义。

2>.构建统一大数据平台的优势

如果我们能化零为整，在企业内部从宏观，整体的角度设计和实现一个统一的大数据平台，引入单一集群，单一存储，统一服务和统一安全的架构思想就能较好地解决上述的种种问题。

（1）资源共享
　　　　使用单一集群架构，可以实现通过一个大集群整合所有可用的服务器资源，通过一个大集群对外提供所有的能力。这样将所有服务器资源进行统一整合之后，能够更加合理地规划和使用整个集群的资源，并且能够实现细粒度的资源调度机制，从而使其整体的资源利用率更加高效。同时集群的存储能力和计算能力也能够突破小集群的极限。
　　　　不仅如此，因为只使用来一个大集群，所以我们现在只需要部署和维护一个集群，不需要重复投入人力资源进行集群的学习和维护。

（2）数据共享
　　　　使用单一存储架构，可以实现将企业内部的所有数据集中存储在一个集群之内，方便进行各种业务数据的整合使用。这样我们便能够结合业务实际场景对数据进行关联使用，从而充分利用大数据技术全量数据分析的优势。同时，在这种单一存储架构之下，各种业务数据可以进行统一的定义和存储，自然的也就不会存在数据重复存储和沟通成本增长的问题来。　　

（3）服务共享
　　　　通过统一服务架构，我们可以站在宏观服务设计的角度来考虑问题，可将一套统一服务设计规则应用到所有服务实现之上，同时也能够统一服务的访问入口与访问规则。
　　　　除此之外，因为所有的服务是由一个统一的大数据提供的，这便意味着这些服务不存在孤岛问题，可以进行整合使用。

（4）安全保障
　　　　通过统一安全架构，可以从平台层面出发，设计并实现一套整体的安全保证方案。在单一集群架构的基础之上，可以实现细粒度的资源整合；在单一存储架构的基础之上，可以实现细粒度的数据授权；在单一服务架构之上可以实现细粒度的访问控制等等。

（5）统一规则
　　　　由于统一大数据集群实现技术线路的统一，这使得我们在后续开发过程中有很多施展拳脚的空间。如此我们可以通过大数据应用的开发过程中得到的一些经验总结，将这些经验整理为方法论和模型，在基于这些理论和模型实现一套大数据平台开发SDK。最终通过这套SDK，可以很方便地将这些经验快速复制推广到整个企业内部。

（6）易于使用
　　　　在开发一款大数据产品或者业务的时候，我们应当将主要的精力放在业务的梳理和实现之上，而不应该过度关注平台底层细节，如集群的安装，维护和监控等。
　　　　比较理想的方式是直接将应用构建在一个大数据平台之上，通过面向平台服务的方式进行应用开发，或是借助平台工具直接以交互的方式进行数据分析。通过平台服务和工具的形式暴露平台能力，屏蔽平台底层细节。应用开发者直接使用平台服务接口进行应用开发，数据科学家，数据分析人员直接使用平台提供的工具进行交互式数据查询和分析。

3>.企业级大数据平台需要具备的基本能力

为了落实这样一个统一的大数据平台，我们提出一些平台应该具有的最基本的能力需求。

（1）数据接入
　　　　在大数据的应用领域，自始至终都是围绕着数据在做文章。所以首先需要面对的是如何把海量数据接入到平台的问题。结合大数据来源多，类型杂，容量大等特征，可以得知大数据平台需要能够对接各种来源和各种类型的海量数据。

（2）数据存储和查询
　　　　在数据接入进来之后，就需要开始考虑如何将数据持久化存储并提供数据查询能力的问题了。为了应对不同业务场景，平台需要提供多种不同的存储媒介以满足千奇百怪的存储与查询需求，所以平台需要提供者如关系型数据模型，非关系性模型以及文档模型的存储系统。

（3）数据计算
　　　　在数据接入并存储下来之后，还需对数据进行进一步的加工，分析和挖掘，这就是数据计算的范畴了。这里包括离线批处理，实时计算，机器学习，多维分析和全文搜索等场景。

（4）平台管理与安全
　　　　作为一个企业级大数据平台产品，安全问题自然不容小觑。平台需要解决诸如用户管理，数据隔离与访问授权，访问控制和集群服务安全等问题。

（5）平台辅助工具
　　　　大数据领域相比传统的企业及应用，在平台运维和程序研发等方向都显得复杂和困难。所以为了提高平台的易用性并降低平台的使用门槛，这里还需要提供一些平台的辅助工具，诸如程序开发套件，任务管理与调度系统，自助式数据探索分析系统等。

 

二.RAID技术及JBOD技术概述

1>.什么是磁盘阵列

磁盘阵列（Redundant Arrays of Independent Drives，RAID），有“独立磁盘构成的具有冗余能力的阵列”之意。

　　磁盘阵列是由很多块独立的磁盘，组合成一个容量巨大的磁盘组，利用个别磁盘提供数据所产生加成效果提升整个磁盘系统效能。利用这项技术，将数据切割成许多区段，分别存放在各个硬盘上。
　　
　　磁盘阵列还能利用同位检查（Parity Check）的观念，在数组中任意一个硬盘故障时，仍可读出数据，在数据重构时，将数据经计算后重新置入新硬盘中。

　　RAID技术是由加利福尼亚大学伯克利分校（University of California-Berkeley）在1988年，发表的文章：“A Case for Redundant Arrays of Inexpensive Disks”中提出的，最初是为了组合多个小的廉价磁盘来代替昂贵磁盘，同时希望磁盘损坏时不会使数据的访问受损而开发的一种数据保护技术。

　　RAID可以提升硬盘速度和增大硬盘容量，并且提供容错功能以确保数据安全性。它易于管理的优点使得在任何一块磁盘出现问题的情况下都可以继续工作，应用程序不易受到损坏硬盘的影响。

2>.磁盘阵列分类

磁盘阵列其样式有三种，一是外接式磁盘阵列柜、二是内接式磁盘阵列卡，三是利用软件来仿真。

　　外接式磁盘阵列柜最常被使用大型服务器上，具可热交换（Hot Swap）的特性，不过这类产品的价格都很贵。

　　内接式磁盘阵列卡，因为价格便宜，但需要较高的安装技术，适合技术人员使用操作。硬件阵列能够提供在线扩容、动态修改阵列级别、自动数据恢复、驱动器漫游、超高速缓冲等功能。它能提供性能、数据保护、可靠性、可用性和可管理性的解决方案。阵列卡专用的处理单元来进行操作。

　　利用软件仿真的方式，是指通过网络操作系统自身提供的磁盘管理功能将连接的普通SCSI卡上的多块硬盘配置成逻辑盘，组成阵列。软件阵列可以提供数据冗余功能，但是磁盘子系统的性能会有所降低，有的降低幅度还比较大，达30%左右。因此会拖累机器的速度，不适合大数据流量的服务器。

3>.RAID常见级别简介

一.Raid0：
　　工作原理：
　　　　Raid0是所有raid中存储性能最强的阵列形式。其工作原理就是在多个磁盘上分散存取连续的数据,这样,当需要存取数据是多个磁盘可以并排执行,每个磁盘执行属于它自己的那部分数据请求,显著提高磁盘整体存取性能。
　　适用场景：
　　　　至少需要两块磁盘，没有容错能力，读写性能都提示， 磁盘空间利用率提升了100%，两块磁盘型号最好要一样，一般存放swap，或者/tmp目录的，适用于低成本、低可靠性的台式系统。

二.Raid1：
　　工作原理：
　　　　又称镜像盘,把一个磁盘的数据镜像到另一个磁盘上,采用镜像容错来提高可靠性,具有raid中最高的数据冗余能力。存数据时会将数据同时写入镜像盘内,读取数据则只从工作盘读出。发生故障时,系统将从镜像盘读取数据,然后再恢复工作盘正确数据。这种阵列方式可靠性极高,但是其容量会减去一半。
　　适用场景：
　　　　至少需要两块磁盘，镜像，具有硬件容错能力，读性能提升，写性能下降，磁盘空间利用率只有50%。广泛用于数据要求极严的应用场合,如商业金融、档案管理等领域。只允许一颗硬盘出故障。
　　需要注意的是，具有硬件容错能力 != 你可以对数据不进行备份。因此对重要数据的备份一定要做好。

三.Raid4：
　　工作原理：
　　　　至少需要三块磁盘，两块盘存数据，一块盘单独用来存另外两块磁盘的校验值。读写性能有所提升，读写性能（n-1）/n。而Raid5是缺吧数据和校验值打乱，分别存到3快磁盘上去。详情可以参考Raid5介绍。Raid生产环境很少人用。

四.Raid5:
　　工作原理：
　　　　Raid5可以看成是Raid0+1的低成本方案。采用循环偶校验独立存取的阵列方式。将数据和相对应的奇偶校验信息分布存储到组成RAID5的各个磁盘上。当其中一个磁盘数据发生损坏后,利用剩下的磁盘和相应的奇偶校验信息 重新恢复/生成丢失的数据而不影响数据的可用性。
　　适用场景：
　　　　至少需要3个或以上的硬盘。适用于大数据量的操作。成本稍高、储存新强、可靠性强的阵列方式。适合用来安装操作系统。

五.Raid6:
　　工作原理：
　　　　其实他就是在Raid5上做的一个优化，存储机制和Raid5类似，只不过多了一块磁盘做热备，当其中一块磁盘坏掉时，另外一块磁盘立即补位，完成存储功能。
　　适用场景：
　　　　至少需要四块磁盘，允许两块盘出错，读写性能提升，磁盘利用率（n-2）/n

六.Raid10:
　　工作原理：
　　　　其实就是Raid1+Raid0的组合，至少需要四块磁盘，允许不同组内各坏一块磁盘，读写性能提升，磁盘使用率50%。
　　使用场景：
　　　　如果有重要数据的话，建议用这种模式，该模式是就有冗余能力的。不建议用Raid5或者Raid01来存取重要的数据，因为Raid5不靠谱，当一块磁盘坏掉的话，工作性能变得特别差！如果在坏一块的话就彻底不能工作了。

七.Raid01：
　工作原理：　
　　将Raid0和Raid1技术结合在一起,兼顾两者的优势。在数据得到保障的同时,还能提供较强的存储性能。不过至少要求4个或以上的硬盘,也只运行一个磁盘出错。是一种高成本、高可靠性、高存储性能的三高阵列技术。


关于软RAID配置，博主推荐阅读：https://www.cnblogs.com/yinzhengjie/p/6858302.html

4>.RAID优缺点 

优点
　　提高传输速率。RAID通过在多个磁盘上同时存储和读取数据来大幅提高存储系统的数据吞吐量（Throughput）。在RAID中，可以让很多磁盘驱动器同时传输数据，而这些磁盘驱动器在逻辑上又是一个磁盘驱动器，所以使用RAID可以达到单个磁盘驱动器几倍、几十倍甚至上百倍的速率。这也是RAID最初想要解决的问题。因为当时CPU的速度增长很快，而磁盘驱动器的数据传输速率无法大幅提高，所以需要有一种方案解决二者之间的矛盾。RAID最后成功了。
　　通过数据校验提供容错功能。普通磁盘驱动器无法提供容错功能，如果不包括写在磁盘上的CRC（循环冗余校验）码的话。RAID容错是建立在每个磁盘驱动器的硬件容错功能之上的，所以它提供更高的安全性。在很多RAID模式中都有较为完备的相互校验/恢复的措施，甚至是直接相互的镜像备份，从而大大提高了RAID系统的容错度，提高了系统的稳定冗余性。

缺点
　　RAID0没有冗余功能，如果一个磁盘（物理）损坏，则所有的数据都无法使用。
　　RAID1磁盘的利用率最高只能达到50%(使用两块盘的情况下)，是所有RAID级别中最低的。
　　RAID0+1以理解为是RAID 0和RAID 1的折中方案。RAID 0+1可以为系统提供数据安全保障，但保障程度要比 Mirror低而磁盘空间利用率要比Mirror高。

5>.JBOD简介 

　　JBOD（just a bunch of disks，简单磁盘捆绑，或有时称简单驱动捆绑）是一个不太正规的术语，官方术语称作“Spanning”，它用来指还没有根据RAID（独立磁盘冗余阵列）系统配置以增加容错率和改进数据访问性能的电脑硬盘。
　　
　　RAID系统在多个磁盘上冗余地存储了同样的数据，而这多个磁盘在操作系统看来就像一个磁盘。虽然JBOD也让多个磁盘看来似乎只有一个，但它是通过把多个驱动器合并成一个大的逻辑磁盘来做到这一点的。JBOD使用独立的磁盘并没有带来任何好处，也不能提供任何RAID所能带来的容错或是更好的性能等好处。 
　　
　　更多关于JBOD信息，详情请参考：https://baike.baidu.com/item/JBOD/3624200?fr=aladdin。

6>.JBOD工作方式

　以三个硬盘组成的Spans数据存储方式为例：Span是在逻辑上把几个物理磁盘一个接一个串联到一起，从而提供一个大的逻辑磁盘。Span上的数据简单的从第一个磁盘开始存储， 当第一个磁盘的存储空间用完后， 再依次从后面的磁盘开始存储数据。Span存取性能完全等同于对单一磁盘的存取操作。Span也不提供数据安全保障。它只是简单的提供一种利用磁盘空间的方法，Span的存储容量等于组成Span的所有磁盘的容量的总和。
　　
　　我们知道RAID 0 是在读写文件的时候采用异步并行的方式同时操作多快数据盘，而JBOD在读写文件时，它只是操作一块磁盘，读写效率想必大家也心知肚明了。

7>.JBOD与RAID比较 

 8>.没有阵列卡的服务器是否能识别磁盘？

　　答案是肯定的，没配置阵列卡的服务器一定可以识别到硬盘。

　　相反，独立的阵列卡的服务器正常情况下不用做阵列都能识别到硬盘的。
　　
　　配置了阵列卡的服务器，无论是独立的还是主板自带的都有可能不做阵列识别不了硬盘，而主板自带阵列卡的服务器很多时候都要做阵列才可以识别硬盘的，因为服务器是这样设计的，硬盘接阵列卡再进主板，所以必须做阵列。

 

三.企业应用磁盘阵列设计方案

　　机器层面来说，我们要保证系统盘正常运行和数据盘的高效实用。

1>.系统盘

　　推荐磁盘阵列类型为：RAID1，相当于HA，当一块系统盘挂掉后，操作系统仍然可以正常使用。操作系统如果损坏，那么在这台操作系统上的所有软件都变得不可用！

2>.数据盘

　　官方推荐是将多个硬盘合并为一个磁盘的操作，即JBOD。我们之前对RAID和JBOD有相应了解，但在实际生产环境中我们推荐使用RAID 0，不推荐使用JBOD。

 

四.节点服务器数据存储方式的推荐

　　我们如果给“dfs.datanode.data.dir”指定了多个目录，那么在存储数据时，会并行去存储，配置多目录可以提升读写速度。注意这里的多目录是咱们在安装操作系统时指定的。（此处各有利弊，涉及到分区知识和DataNode存储数据的方式，因为HDFS使用balance负载均衡可以保证各节点存储数据的总量保持均衡，但不能保证各个分区数据存储均衡哟～因此我们建议把系统盘和数据盘分开后即可，不要再对数据盘进行分区啦，我在生产环境中并没有对其进行分区，也没有配置多目录。） 

 

 

五.企业集群规划与资源配置方案

1>.操作系统选择 

[root@node101.yinzhengjie.org.cn ~]# cat /etc/redhat-release 
CentOS Linux release 7.6.1810 (Core) 
[root@node101.yinzhengjie.org.cn ~]# 
[root@node101.yinzhengjie.org.cn ~]# uname -r
3.10.0-957.el7.x86_64
[root@node101.yinzhengjie.org.cn ~]# 
[root@node101.yinzhengjie.org.cn ~]# uname -m
x86_64
[root@node101.yinzhengjie.org.cn ~]#

2>.集群主机名命名规范（尽量每个节点的后缀都相同，显得比较专业）

[root@node101.yinzhengjie.org.cn ~]# cat /etc/hosts
172.30.1.101 node101.yinzhengjie.org.cn 　　　　　
172.30.1.102 node102.yinzhengjie.org.cn
172.30.1.103 node103.yinzhengjie.org.cn
172.30.1.104 node104.yinzhengjie.org.cn
172.30.1.105 node105.yinzhengjie.org.cn
172.30.1.106 node106.yinzhengjie.org.cn　　　　　　#Mysql master节点，Kerberos master节点
172.30.1.107 node107.yinzhengjie.org.cn　　　　　　#Mysql Slave节点，Kerberos slave节点
172.30.1.108 node108.yinzhengjie.org.cn　　　　　　#备用服务器，用作节点的扩容时使用，暂不开机
[root@node101.yinzhengjie.org.cn ~]#

3>.生产环境软硬件选择

一.硬件部分
　　Hadoop集群根据不同的计算需求，通常可分为IO密集型和CPU密集型两类。IO密集姓的计算任务有数据的导入导出，ETL，索引，分组等。CPU密集型的计算任务有数据挖掘，机器学习等。不同计算需求适合于不配置不同的硬件，每个企业的预算，集群规模，现有硬件（如果搭建Hadoop需要利用现有硬件）也不尽相同。

　　以目前的生产环境为例，如果使用自建机房搭建集群，一般会采购PC服务器作为集群节点（通常大小为2U），安装在机架上（标准机架为42U，一般不会安装超过20台服务器），机架于机架之间至少要保证万兆以太网连接（由于目前服务器的网卡传输效率都在万兆级别，因此核心交换机应该支持至少万兆级别传输）。

　　Hadoop集群也可安装在虚拟机或公有云上，CDH对此有良好的支持，选择硬件时，可参照物理机搭建集群的配置，并适当地考虑数据交换成本等额外因素。（搭建在虚拟环境中运行效率可能会低，我来到公司不到一个月时间将2PB的数据从某云上全量迁移自建的大数据集群中，根据大数据开发人员反馈，之前在某云上运行40分钟的任务，在新集群不到5分钟就可以运行完毕，因此我并不建议大家将生产的集群部署在虚拟环境之上）。

二.软件部分
　　(1)CDH and Cloudera Manager 5.16.x Supported Operating Systems:
　　　　　　https://www.cloudera.com/documentation/enterprise/release-notes/topics/rn_consolidated_pcm.html#c516_supported_os

　　(2)CDH and Cloudera Manager Supported JDK Versions:
　　　　　　https://www.cloudera.com/documentation/enterprise/release-notes/topics/rn_consolidated_pcm.html#pcm_jdk

　　(3)CDH and Cloudera Manager Supported Databases:
　　　　　　https://www.cloudera.com/documentation/enterprise/release-notes/topics/rn_consolidated_pcm.html#cdh_cm_supported_db

　　(4)CDH 5 and Cloudera Manager 5 Requirements and Supported Versions:
　　　　　　https://www.cloudera.com/documentation/enterprise/release-notes/topics/rn_consolidated_pcm.html

4>.角色划分

按照节点在集群中角色的不同，我们一般会分为四类节点：
　　　　管理节点:
　　　　　　主要用于运行重要的管理进程，如NameNode， ResourceManager等。
　　　　工具节点:
　　　　　　主要用于非Hadoop管理进程的其他进程，如ClouderaManager，Hue等。
　　　　边缘节点:
　　　　　　用于运行集群的客户端、Flume等数据采集进程、FTP服务等。
　　　　工作节点:
　　　　　　主要用于运行各种分布式计算进程，如nodemanager，impala等。 

　　对于前三类节点，推荐配置:
　　　　（1）2个6核以上的CPU，主频至少2GHz;    
　　　　（2）64-512GB内存，具体取决于负载多重，如NamaNode可以多配一些;
　　　　（3）4-8个1TB以上的SAS或SATA硬盘，一般OS、ZooKeeper存储目录等可以用裸盘，NameNode的fsimage、数据库数据文件等盘建议用RAID 1或 RAID10。

　　对于工作节点，推荐配置:
　　　　（1）2个6核以上的CPU，主频至少2GHz，如果为CPU密集型集群，可选择2路12核及以上CPU;
　　　　（2）64-512GB内存，具体取决于集群部署的角色，如果只运行Hadoop核心组件，则64或128GB一般够用，如果混合部署Impala、Spark等内存计算组件，则至少配置256或512GB(也可如下估算，CPU密集型CPU:内存为1:4， IO密集型或内存计算CPU:内存为1:8或1:16);
　　　　（3）4-24个2TB以上的SAS或SATA硬盘，一般2U服务器内插硬盘个数不超过8 个，可以通过背板扩展卡扩展到16甚至24个。虽然Hadoop也支持异构存 储，但一般不需要使用SSD硬盘，除非对IO有特别高的需求;
　　　　（4）柜顶交换机使用万兆的，机架上层的核心交换机至少也要是万兆的，使得异机架节点的带宽至少为千兆。


　　角色划分总结：
　　　　（1）对于生产集群，还有一个重要的工作是角色划分，即为每个节点设置运行的进程。因为只有工作节点才真正承担分布式计算任务，管理节点、 工具节点、边缘节点完全不承担计算任务或只承担非分布式的任务，因此在100个节点以上的中大规模集群中，我们希望计算节点的占比尽可能高。
　　　　（2）但是三类非计算节点的个数也不是越少越好，尤其是管理节点上的进程都非常重要，通常会将其分散到多个节点上，以防止节点失效产生严重影响。比如，如果一个节点上既有HDFS的NameNode又有HBase的HMaster， 该节点故障的话，即使两者都配置了高可用，也会造成一段时间内两个 角色的元数据服务都不可用，影响比较大，因此像此类重要进程尽量单 独设置节点，或和ZooKeeper这样稍次要的角色合设。
　　　　（3）根据经验，中大型集群一般使用5%-10%的节点作为非工作节点，并依据这些节点上运行进程的CPU、内存、IO使用特性和HA要求，来合理地进行划分。

5>.测试集群环境（可以运行模拟部分线上数据的环境，无法运行全量数据，一般用于修改配置需要现在测试集群修改完毕后然后再动生产环境的配置）

机器数量：5~10台

硬盘大小：4TB 

内存：24GB~32GB 

CPU：6核 

网卡：万兆

6>. 生产集群规模 

小型集群数量：20台以下

中型集群数量：50台以下（一般在30多台左右）

大型集群数量：50台以上

[root@node101.yinzhengjie.org.cn ~]# cat /proc/cpuinfo| grep "physical id"| sort| uniq| wc -l　　　　　　　　　　　　　　　　#查看CPU个数
[root@node101.yinzhengjie.org.cn ~]# 
[root@node101.yinzhengjie.org.cn ~]# cat /proc/cpuinfo| grep "cpu cores"| uniq　　　　　　　　　　　　　　　　　　　　　　　　 #查看每个物理CPU中core的个数（即核数）　　
cpu cores       : 8
[root@node101.yinzhengjie.org.cn ~]# 
[root@node101.yinzhengjie.org.cn ~]# cat /proc/cpuinfo| grep "processor"| wc -l　　　　　　　　　　　　　　　　　　　　　　　　#查看逻辑CPU个数
[root@node101.yinzhengjie.org.cn ~]# 
[root@node101.yinzhengjie.org.cn ~]# cat /proc/cpuinfo | grep name | cut -f2 -d: | uniq -c　　　　　　　　　　　　　　　　　#查看CPU信息（型号）
 Intel(R) Xeon(R) CPU E5-2620 v4 @ 2.10GHz
[root@node101.yinzhengjie.org.cn ~]# 
[root@node101.yinzhengjie.org.cn ~]# 

[root@node101.yinzhengjie.org.cn ~]# free -h
              total        used        free      shared  buff/cache   available
Mem:           125G         19G         77G        4.0G         29G        101G
Swap:          4.0G          0B        4.0G
[root@node101.yinzhengjie.org.cn ~]# 

[root@node101.yinzhengjie.org.cn ~]# df -h
Filesystem                         Size  Used Avail Use% Mounted on
/dev/mapper/centos_localhost-root   50G   15G   36G  29% /
devtmpfs                            63G     0   63G   0% /dev
tmpfs                               63G     0   63G   0% /dev/shm
tmpfs                               63G  4.1G   59G   7% /run
tmpfs                               63G     0   63G   0% /sys/fs/cgroup
/dev/mapper/centos_localhost-home   80T   50T   31T  62% /home
tmpfs                               13G     0   13G   0% /run/user/0
cm_processes                        63G   38M   63G   1% /opt/cloudera-manager/cm-5.15.1/run/cloudera-scm-agent/process
[root@node101.yinzhengjie.org.cn ~]#