?????????假如业务系统数据量每天增量 50T,保留周期30天,那么HDFS存储容量为 50T * 30天 * 3副本 * 2倍(数据源 + 清洗加工) = 9000T = 8.79P
? ? ? ? 假如每个机器的磁盘是4T * 10 = 40T,每台机器的可用存储容量为 40T * 0.75 = 30T,节点预估数量 = 9000T/30 = 300 节点,所以datanode的节点最小数量为300个。
????????根据任务量和性能评估YARN的节点数是很难的,难以评估,所以NodeManager节点数可以和datanode节点数据保持一致,如果算力负载过高,根据实际情况再扩容即可。
????????HBase节点规划,一般开始搭建是根据HDFS存储公式计算即可,如果从增加并发的考虑,一般一个RegionServer并发为5000 ~ 2万(优化后并发更高),可以根据业务实际并发估计节点数量。
????????Kafka节点规划,一般开始搭建时根据类似HDFS存储公式计算,一般1个broker并发为5万(优化后并发更高),可以根据业务实际并发估计节点数量。
????????Zookeeper节点规划,集群开始搭建时3节点就够用了,如果发现zookeeper负载过高或有超时时现象可以考虑扩展到5节点
????????集群中的每个组件都要做高可用,一般国企会用CDH,互联网公司会用开源社区版演化自己平台。
????????如何计算数据量的大小,这个其实很多企业已有相关的系统,只不过数据的处理更换为大数据系统。数据的增量, 对于不同的公司是不一样的,有的公司数据增量也就是几个G,而有的公司数据增量 1T 以上,比如物联网大数据行业数据。
假设每天3亿请求,每个约2KB,数据增量为570G。
计算过程:2KB转换为 G = 2/1024/1024
再乘以请求数:(2/1024/1024) * 3 * 100000000 ~ 570GB
????????在计算整体QPS之前,我们先需要压测一台物理机的最大QPS。这方面可以参考下面的文章https://segmentfault.com/a/1190000018075241
????????假设有 80%的数据( 0.8 亿)会在高峰期涌入,20%的数据在低谷时涌入: QPS= 80 000 000/ (10800)约等于 7407 条。即预估结果集群需要在业务最高峰期抗住 7407/s 的 QPS。上面是我们评估在高峰期 QPS。如果资源充足,让高峰期 QPS 控制在集群能承载的总 QPS 的 30%左右是比较安全的策略,即应设计集群承载 QPS 上限为 2 万~3 万/s 才是安全的。对于物理机,我们可以进行测试,一般来说一台物理机可稳定支持 4 万 QPS。
????????存储的预估,这里其实还是涉及到我们是如何对待这些数据的,比如有些数据有效期是一年, 有的则是长期存储等。这里我们就以长期存储保留。对于时间上来说,一般原则是三年内不需要增加磁盘。?
????????我们以刚才的日增量570G来预估三年的存储。对于大数据集群存储来说,hdfs一般会默认3副本存储机制,那么一天的增量也就是 570G * 3 = 1710G ,大概一天1.7T左右。
????????1.7*3*365 = 1861.5TB 是三年的数据存储大小,存储一般不会超过集群整体存储的80%,所以需要用 1861.5/0.8 = 2325.875TB,假设每快盘需要预留10%的存储空间,则总的存储空间还需要根据盘数预留一定大小,最后得出总存储资源在2.5PB左右。如果一台机器90T左右,则需要30台机器。当然这里没有考虑存储到hdfs中的数据有没有被压缩,如果压缩效果比较好的话可以节省不少成本。
????????对于计算资源内存的估算没有绝对的标准,需要根据公司使用的计算系统来区分,需根据实际使用的组件(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 内存(一般机器比较新的情况下)。?
????????CPU和内存的比例一般为1:2,1:3或者1:4三种,具体分配要重点看有多少线程。CDH集群中的MR任务一般采用1:3,实时接收数据的kafka端一般配比高一些,对于spark、kudu这类需要先缓存到内存再保存到磁盘的组件,一般内存需要设置大一些。