[集群规划]E-MapReduce(Hadoop)10大类问题之集群规划

E-MapReduce(Hadoop)10大类问题之集群规划-博客-云栖社区-阿里云 https://yq.aliyun.com/articles/59064

典型的离线场景
用户每天增加100G的数据，1个月3T，压缩后为 1T（假设压缩率为30%） 数据全部存储在HDFS中，1年之前数据分析比较少，但是希望数据存下来。计算主要以离线机器学习及ETL为主，主要使用hive及spark，并发作业5-10个左右。那客户1年大约有12T的数据。存在HDFS中大约需要36T的磁盘。一般来讲，ETL与机器学习是比较耗费CPU的。目前E-MapReduce作业是从master提交，master可以大一点。

典型的离线场景
用户每天增加100G的数据，1个月3T，压缩后为 1T（假设压缩率为30%） 数据全部存储在HDFS中，1年之前数据分析比较少，但是希望数据存下来。计算主要以离线机器学习及ETL为主，主要使用hive及spark，并发作业5-10个左右。那客户1年大约有12T的数据。存在HDFS中大约需要36T的磁盘。一般来讲，ETL与机器学习是比较耗费CPU的。目前E-MapReduce作业是从master提交，master可以大一点。

---

摘要： 所有的使用Hadoop或者打算使用Hadoop的人肯定会遇到集群规划的问题，我到底使用多大的集群规模呢?有没有一个标准呢? 本篇文章就为你介绍集群规划。
前言
目前E-MapReduce已经服务了很多客户，大部分的客户都有着相同类似的问题，本系列会总结这些问题，分为10篇文章，每隔一段时间会更新一大类的问题，欢迎大家交流学习。我们交流群为开源大数据技术社区召集令，欢迎大家关注。特别推荐 E-MapReduce产品，如果有大数据的需求，欢迎大家尝试使用，本系列所有的问题都是基于E-MapReduce平台的。
集群规划类问题
所有的使用Hadoop或者打算使用Hadoop的人肯定会遇到集群规划的问题，我到底使用多大的集群规模呢?有没有一个标准呢? 本篇文章就为你介绍集群规划。
在云环境E-MapReduce中，各种搭配是比较自由的。当前，cpu跟memory的比例有1：2及1：4的。磁盘是单机4快盘，从不同的性能有普通云盘、高校云盘、SSD云盘，价格也分别不同，单盘的容量也从40g到32T。
对于 有钱的公司，本文就不用看了，直接用最贵最多的肯定是满足需求的。对于广大的创业公司或者本着开源节流的思想来用的公司，还是需要研究下的。
基本原则
离线在线分开，主要是把在线的流式计算(SparkStreaming\Storm)、存储服务(Hbase)与离线计算分开。因为两者追求的目标不一样，在线追求qps响应时间，离线追求吞吐。
Hbase需要使用SSD云盘，直接使用EMR提供的HDFS，因为Hbase需要低延迟。
冷数据尽量放在OSS中。
尽量合并小文件，把数据放在OSS中。
对于离线计算，存储计算尽量分离。如果放在OSS中对于的性能较低（小文件特别多），则需要本地磁盘。
在波峰期间，启动EMR按需集群，分析数据，待波峰通过释放集群，以节约成本。
对于spark，尽量配置cpu:memory为1cpu:4g的比例。

用户评估集群的规模的一般步骤：评估数据量 -> 测试一个小规模的集群的量化性能 -> 最终选择集群的规格。
典型的离线场景
用户每天增加100G的数据，1个月3T，压缩后为 1T（假设压缩率为30%） 数据全部存储在HDFS中，1年之前数据分析比较少，但是希望数据存下来。计算主要以离线机器学习及ETL为主，主要使用hive及spark，并发作业5-10个左右。那客户1年大约有12T的数据。存在HDFS中大约需要36T的磁盘。一般来讲，ETL与机器学习是比较耗费CPU的。目前E-MapReduce作业是从master提交，master可以大一点。
用户的存储需求为12T物理数据，放HDFS需要36T的磁盘
计算的需求，这个不好评估，需要看实际的运行情况，一般来讲，是用户根据运行时间、跟规模一起来评估的。可以先跑一个基本的case，评估一个小集群的运行时间。再按照一定的线性比例上调机器规模。 假设用户运行大约需要 20slave 8cpu 32g，则2 master 8cpu32g的机器，磁盘搭配 350G 高校云盘（350G可以保证最大的磁盘IO）
20 slave 8cpu32g 450g*4块的高效云盘
一年之前的数据全部放在OSS中，需要时E-MapReduce直接连接OSS分析

一般来讲，业务的变化，集群就可能不合适了，这个时候需要重新调整集群的规格，最常见的方式就是 增加节点、重新创建一个新的规格的集群（所以最好是包月，当快到期时，需要再创建一个集群）
流式计算
此块比较好规划，基本磁盘可以忽略不计，主要是以 cpu为主。按照先测试，再按照比例增大。流式计算纯粹统计uv等cpu与memory按照1:2的比例，需要在内存暂存数据的按照1:4以saprkstreaming暂存数据为例：
1台master 4cpu8g 3501 高效云盘
2台slave 4cpu16g 1004 高效云盘 后续可以按照实际情况扩展节点。

存储服务Hbase
此块磁盘最好使用SSD云盘，考虑到iops流式计算cpu与memory按照1:4的比例，slave规格可以大一些开始可以按照：
2台master 4cpu8g 2501 SSD云盘
2台slave 16cpu64g 250g4 SSD云盘 后续可以按照实际情况扩展节点。

离线计算 存储与计算分离
离线计算其实可以做到存储与计算分离的，比如把数据全部放在OSS中，再通过无状态的E-MapReduce分析。那E-MapReduce就纯粹的计算，不存在存储跟计算搭配来适应业务了，这样最为灵活。后续会专门有一篇文章讲述存储计算分离的。
后记
集群的规格最终还是需要用户按照自身的业务特点来最终评估，以上只是一些大体的原则。欢迎各位E-MapReduce及Hadoop用户给出自己的建议。