我们在实际工作，或者面试中，经常会遇到这么一个问题，集群该如何规划，一台机器多少磁盘，多少内存，多少core等。

关于公司集群规模，有的几台，有的几百或有的则几千台，那么这几百几千台机器他们的配置是怎么样的？

这里先说下大概，对于大多数公司来说，集群有的10来台，而对于电信行业，一个地方的可能有几百台，对于一线互联网集群规模就比较大一些，上千台是比较常见的。    

那么如果我们要搭建大数据平台，集群该如何规划？这是我们初步搭建集群的时候，首次遇到的问题。

对于需要多少台机器，其实这个问题，不能一刀切的回答，具体情况具体分析。虽然一开始我们不知道多少台机器，但是我们可以知道影响的关键因素？

那就是数据的增量是多少？

数据的增量，这里我们来说下数据增量：

其实数据的增量不同的公司，也是不一样的，有的公司数据增量也就是几个G，而有的公司数据增量1T以上，比如物联网大数据。除了数据增量，还有其它影响因素，比如使用的计算组件，使用MapReduce和Spark,Flink在内存的使用上，肯定是有区别的。再比如QPS也影响着系统的资源分配。

除了影响因素，那么我们预估集群包含哪些步骤？

1.判断计算数据增量大小

如何计算数据量得大小，这个其实很多企业已有相关得系统，只不过数据得处理更换为大数据。所以数据增量已经非常明确。如果我们不知道增量是多少，那么我们就需要计算下。

如每天1亿的请求，每个大概2KB，则增量为190G。

计算过程：

2KB转换为G=2/1024/1024

（2/1024/1024）*100000000约等于190G

2.QPS计算与评测

QPS这里我们首先需要计算大概是多少，同时我们需要评测一台物理机大概能支撑多少QPS。

QPS或许我们有些成员比较陌生，可以参考

记一次性能优化，单台4核8G机器支撑5万QPS

https://www.aboutyun.com/blog-61-4365.html

我们或许听说过，如果新浪微博明星发微博，比如结婚，离婚等事件，那么新浪就要顶不住了，就需要临时增加服务器，所以导致新浪程序员假期加班。其中原因之一就是QPS过多，导致服务器压力增大。

假如集群1亿的请求，对于一些网站而言，比如About云社区，电商社区等，一般0点到上午8点请求量很小。一般高峰期为上午10点，下午4，5点请求量比较大，当然每个社区或者电商时间点，有所区别。

也就是80%的数据( 0.8亿)会在其余16个小时（8点-24点）涌入，20%时间( 3小时内)涌入:

QPS= 80 000 000/ (10800)约等于7407条。

即预估结果集群需要在业务最高峰期抗住 7407/s的QPS。

上面是我们评估在高峰期QPS。如果资源充足，让高峰期QPS控制在集群能承载的总QPS的30%左右是比较安全的策略，即应设计集群承载QPS上限为2万~3万/s 才是安全的。

对于物理机，我们可以进行测试，一般来说一台物理机可稳定支持4万QPS。关于QPS测试方法很多种，比如WRK

QPS性能测试工具WRK的简明教程

https://www.aboutyun.com/blog-61-4366.html
更多我们可以自己搜索。

3.存储预估

存储的预估，这里其实还是涉及到我们是如何对待这些数据的，比如有些数据有效期是一年，有的则是长期存储等。这里我们就以长期存储保留。对于时间上来说，一般是三年内不需要增加磁盘。

我们就以数据增量为190G来计算，对于大数据存储，比如hdfs存储副本默认为3，那么190G*3=570G，也就是说一天大概存储570G。

570G*3*365=624150G大概为609T。也就是就存储来说大概需要609T的磁盘。但是一般集群存储不超过80%，609T/0.8大概需要760T。

如果一台机器是20T，那么我们需要38台机器。

4.内存估算

内存估算，内存的估算其实这个是没有绝对标准，有的公司使用Flink处理物联网数据，只用了几台不到10G的机器就可以处理。所以内存的估算其实不同的组件，执行多少任务，多少实时任务，离线任务、算法模型等，区别比较大。

一般实时任务占用的资源都是固定的，可以根据业务个数估算。离线任务可以根据ETL任务数和任务资源配置情况估算，计算资源离线和实时同时启用的时候不能超过资源90%。实时任务资源占用需要小于50%，如果数据增量为190G，实时任务7407/s的QPS，一分钟窗口444420*（2/1024/1024）=0.85G,有的设置5分钟窗口，那么大概是4.25G。如果离线任务，可以把1/4的数据放到内存，那就就需要47.5G的内存。如果二者同时运行，按照不超过90%来计算，需要57.5G。

上面只是单纯的从实时和离线单任务来计算，可以选择64G内存。

5.CPU估算

CPU和内存比例，一般为1：2或者1：4，当然具体需要看有多少线程。

我们以Kafka为例：

Kafka进程里面大概有多少线程：

1个Accept线程

• 默认的3个Process线程（一般会设置为9个）
  
• 默认的8个RequestHandler工作线程（可以设置为32个）
  
• 清理日志的线程
  
• 感知Controller状态的线程
  
• 副本同步的线程
  

估算下来Kafka内部有100多个线程

实际计算

4个cpu core，一般来说几十个线程，在高峰期CPU几乎都快打满了。

8个cpu core，也就能够比较宽裕的支撑几十个线程繁忙的工作。所以Kafka的服务器一般是建议16核，基本上可以hold住一两百线程的工作。当然如果可以给到32 cpu core那就最好不过了！【参考】

总结

上面其实结果并不重要，重要的是我们是如何计算的，大家可以根据自己的环境和需求来估算大概需要的配置和机器数目。