如何规划大数据集群
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
#### 前情回顾
还记得笔者在上一篇文章《如何精通一种大数据技术?》中提到如何精通一种大数据技术的六个层次吗?首先我们对上篇中所列六个层次进行简单前情回顾,如果想精通一种大数据技术可以按照如下进行层层深入递进:
1. 掌握其环境依赖和安装原理;
2. 掌握其基本原理和接口使用方法;
3. 精研其底层源码的实现原理;
4. 掌握其深度性能优化和故障解决的能力;
5. 掌握对其进行二次开发和发布自己版本的能力;
6. 终极境界成为开源社区的代码贡献者甚至PMC;
后续笔者会对上述六个层次按照企业实践中每个层次的实际应用分主题分关键点进行深入展开。从本篇文章开始,笔者首先对第一个层次的关键点系列进行展开。
学习和应用大数据技术,第一步首先面对的就是如何安装大数据集群,包括本地模式、伪分布式集群模式、企业实际应用的分布式集群模式。对于前两种本地模式和伪分布式模式,比较简单,是在单机实现,在实际应用中企业也不会使用这两种模式,所以我们按照企业实际应用的分布式模式进行分析。在企业实际使用安装大数据集群之前,首先需要对集群进行规划,所以今天我们对企业如何做大数据集群的规划设计进行分析。如有错误,敬请指正。
#### 如何做大数据集群规划设计?
通常,对于给定业务的大数据集群来说,应该如何规划集群才能使硬件资源不浪费?由于成本考量只有少量节点的情况下如何规划集群的主节点和从节点才合理?对于集群的副本数如何设置才比较合适?给定容量的集群到底能存储多少数据?等等,想必这些问题也应该曾经或者目前正在困惑着很多的大数据技术人员或者运维人员,本文将结合笔者在实际工作中的经验简单的对这些问题解析和分享,希望对读者能够有一定的帮助。下面笔者以构建Hadoop和HBase分布式文件系统来说明如何规划集群。
##### 1. 从集群性能和运维角度考虑
**单机配置性能**
在进行集群规划时,对于单机机器资源配置主要是从内存、CPU、硬盘、网络等方面进行考虑。通常情况下大数据集群中分为两类节点:主节点和从节点,比如Hadoop中的NameNode就是主节点,而DataNode就是从节点。下面具体说明各种资源在选择时应该考虑哪些关键因素。
对于内存的考量,通常选择比较大的内存节点。如果是主节点通常情况下对内存的要求更高,需要配置更大的内存,而从节点就没必要像主节点那么大,可能更关注的是磁盘和CPU指标了。对于小微集群,通常所有的节点可能配置都是一样的,所以可根据实际情形进行选择。
对于CPU的考量,不同的节点可以根据要求而不同的,比如对于主节点可以选择2路32核或者更高性能的CPU,而从节点可以适当降低一些要求,选择2路16核的CPU。如果集群规模比较小,所有的节点配置完全相同。
对于磁盘的考量,通常情况下会按照集群的总体规模进行规划。对于从节点来说,安装的都是数据存储节点或者计算节点,往往都选择比较大的磁盘,比如由多块2T或者4T组成的20T或40T的磁盘。而对于主节点来说,通常安装的都是主节点需要的是内存,对磁盘的要求比较低,不过如果同时也安装了从节点磁盘也需要配置比较大的磁盘。但有一点,为了保证负载均衡和集群性能,所有从节点的磁盘空间配置要尽量保持一致。
对于网络的考量,通常对于大数据平台往往数据量都是非常巨大的,网络的吞吐率要求也比较高,所以在条件允许的情况下都选择万兆网。
**应用分布规划**
从集群的系统性能方面考虑,希望集群的整体性能尽可能比较高,资源使用率尽可能大,而从运营维护角度考虑,当集群某个节点出现故障时希望对集群的可用
性、稳定性等方面的影响尽可能小,下面我们以通常情况下按照如下分配所有的应用程序。
对于小微集群来说,集群节点个数往往比较少(有时可能只有几台服务器),这样多个节点需要进行共享。如果集群的节点个数少于5个,我们以4个节点的集群、HA模式为例,可以按照如下进行应用分布设计:
Node01: NN、RM、HM
Node02: NN、RM、HM、JN、ZK
Node03: DN、NM、RS、JN、ZK
Node04: DN、NM、RS、JN、ZK
对于如上的集群配置,这样的集群抗风险和容错能力比较差,集群的扩展能力也方便,当有节点发生故障需要机器下线操作起来也不方便,所以仅适合于做开发环境或者实时性要求比较低的批处理集群。
对于节点数大于等于5个节点时,集群就可以按照如下进行分布设计:
Node01: NN、RM、HM
Node02: NN、RM、HM
Node03: JN、ZK、DN、NM、RS
Node04: JN、ZK、DN、NM、RS
Node05: JN、ZK、DN、NM、RS
Node06: DN、NM、RS
Node07: DN、NM、RS
......
NodeNN: DN、NM、RS
对于这样的集群随着业务规模的扩展,我们随时可以很方便的将Node03、Node04、Node05上的DN、NM、RS都下线,使集群的分布变更为:
Node01: NN、RM、HM
Node02: NN、RM、HM
Node03: JN、ZK
Node04: JN、ZK
Node05: JN、ZK
Node06: DN、NM、RS
Node07: DN、NM、RS
......
NodeNN: DN、NM、RS
上述中的简写名称分别代表:NN代表NameNode,RM代表ResourceManager,HM代表HMaster,DN代表DataNode,JN代表JournalNode,ZK代表Zookeeper,NM代表NodeManager,RS代表RegionServer。
##### 2. 从存储容量角度规划考虑
在进行集群规划时同时还需要从存储容量角度考虑,可以按照如下四个方面进行规划:
**数据范围**
在实际业务中,对于任何一个企业其业务条线都会有其自己的业务增长趋势,这样随着业务规模的增长企业数据量也会不断增长,所以我们在规划集群时可以按照短期业务(1~2年)、中长期(3~5年)业务增长进行规划,而不是在集群初始化时一次性导入的初始数据量。
比如:我们假设企业的客户量x,所有客户产生的所有业务数据量为y,在构建集群时的初始数据量为c,那么可能的一种企业数据量增长模型为
y = a*f(x) + b*g(x) + c
其中,在大部分企业中如果客户量增加一个量级dx,那么其所对应的日志和订单业务数据量可能是客户量的线性模型f(x),而对于交易类业务的数据量可能是客户量的非线性增长模型g(x),比如笛卡尔积模型。