大数据集群规划的一点建议

1：分别对增量数据、全量数据进行规模测算。在实际业务中，对于任何一个企业其业务条线都会有其自己的业务增长趋势，这样随着业务规模的增长企业数据量也会不断增长，所以我们在规划集群时可以按照短期业务（1～2年）、中长期（3～5年）业务增长进行规划，而不是在集群初始化时一次性导入的初始数据量。
比如：我们假设企业的客户量x，所有客户产生的所有业务数据量为y，在构建集群时的初始数据量为c，那么可能的一种企业数据量增长模型为
y = a*f(x) + b*g(x) + c
其中，在大部分企业中如果客户量增加一个量级dx，那么其所对应的日志和订单业务数据量可能是客户量的线性模型f(x)，而对于交易类业务的数据量可能是客户量的非线性增长模型g(x)，比如笛卡尔积模型。
所以不能通过简单的节点动态增加来调整集群规模和存储计算能力，最好还是通过构建短期业务和中长期业务增长趋势模型来规划集群。
2：针对离线和实时场景，需要做好压测(QPS(每秒查询率)=并发数/平均响应时间)，评估任务量、任务数以及各个组件在不同配置下的处理性能。
3：集群高可用保证，针对关键性管理节点，尽可能散落在不同的机器节点上，避免集中在某一两台机器上。
4：对于管理节点与NameNode,ResourceManager,Master,JobManager...等，存储和内存，尽量分配小一点。
5：对于存储 如HDFS DataNode尽量磁盘分配比较大的机器，选择合适的文件格式，并且进行数据压缩。而对于计算节点，如spark 、flink、doris等尽量分配比较高CPU和内存的机器。
6.任务提交参数合理优化：消耗内存的分批次提交。堆内存进行估算，设置合理并行度。
对于计算资源内存的估算没有绝对的标准，需要根据公司使用的计算系统来区分，需根据实际使用的组件(MR\Flink\Spark\)，执行了多少任务，实时任务数量，离线任务数量、算法模型等进行实际估算。
一般实时任务占用的资源都是固定的，可以根据业务个数估算。离线任务可以根据 ETL 任 务数和任务资源配置情况估算，计算资源离线和实时同时启用的时候不能超过资源 90%。实时任务资源占用需要小于 50%，如果数据增量为 570G，实时任务 7407/s 的 QPS，一分 钟窗口，如全量计算 444420*（2/1024/1024）=0.85G,有的设置 5 分钟窗口，如全量计算大概是 4.25G。 
如果离线任务，可以把 1/4 的数据放到内存，那就就需要 47.5G 的内存。如果二者同时运行，按照不超过 90%来计算，需要 57.5G。上面只是单纯的从实时和离线单任务来计算，可以选择 64G 内存（一般机器比较新的情况下）。
7.kafka、ZK、Flume传输数据比较紧密的放在一起。
8.客户端尽量放在1到2台服务器上，一是风险隔离，导致集群内部受到不必要的干扰。二是作为跳板机，方便工程师外部访问。
9.有依赖关系的尽量放到同一台服务器(例如:HIVE和DS)
10.CPU和内存的比例一般为1:2,1:3或者1:4三种，具体分配要重点看有多少线程。CDH集群中的MR任务一般采用1:3，实时接收数据的kafka端一般配比高一些，对于spark、kudu这类需要先缓存到内存再保存到磁盘的组件，一般内存需要设置大一些。
11. 对于集群中产生的数据可以按照业务中间数据、临时数据、集群的系统日志、集群的预留空间安全系数等来进行规划。业务中间数据和临时数据会分配一定的空间比例，对于集群的预留空间安全系数可以按照当集群的总体规模使用达到80%就需要进行横向扩容，等等。
笔者曾经在实践中遇到过如下情形，原始的业务数据大概有15T左右，通过多副本存储策略、数据处理过程中产生的大量中间和临时数据、再加上集群需要有预留空间的安全系数等，当时整个集群120T的总空间尽然都不够用，也就是说现实中的业务数据在使用中总体上可能会膨胀好多倍。

zookeeper :(100台服务器下)3台； （>=100）5台
kafka:根据数据量的io需求实际测试
  点数计算方式：
   按照吞吐量计算：X（总吞吐量，MB/秒） / 100（单节点最大Producer吞吐量，MB/秒） / 0.85（预留比例）
   按照存储量计算：X（总吞吐量，MB/秒） * 3600 * 24 * D（天数，默认7）* 2（副本数） / 1024 / 1024 / (25 * 0.96) / 0.85（预留比例）
   二者取大值，最少配置2台。
hbase:hbase数据写入快，节点数计算公式：
  节点数 = 规划数据量 * 1.5 （数据膨胀率） * 1（数据压缩率） * 3（3副本）/ 0.8（磁盘利用率） / 0.9 （磁盘进制转换）/ （12 （磁盘个数） * 4T （磁盘容量））
es:写入慢读取快，同样数据写入es和hbase，一般服务器数量多于hbase
  节点数 = 规划数据量 * 1.5 （数据膨胀率） * 1（数据压缩率） * 2（2副本）/ 0.8（磁盘利用率） / 0.9 （磁盘进制转换）/ （24 （磁盘个数） * 0.96T （磁盘容量）* 5 / 6 （RAID系数））
hdfs:数据的总计算资源存储资源。