你好,游客 登录 注册 搜索
背景:
阅读新闻

10大类E-MapReduce(Hadoop)用户问题-集群规划

[日期:2016-08-12] 来源:云栖博客   作者:封神 [字体: ]

  前言

  目前E-MapReduce已经服务了很多客户,大部分的客户都有着相同类似的问题,本系列会总结这些问题,分为10篇文章,每隔一段时间会更新一大类的问题,欢迎大家交流学习。我们交流群为 开源大数据技术社区召集令 ,欢迎大家关注。另外,也顺便推荐下E-MapReduce产品,如果有大数据的需求,欢迎大家尝试使用,本系列所有的问题都是基于E-MapReduce平台的。

Hadoop

  集群规划类问题

  所有的使用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 350*1 高效云盘

  2台slave 4cpu16g 100*4 高效云盘 后续可以按照实际情况扩展节点。

  存储服务Hbase

  此块磁盘最好使用SSD云盘,考虑到iops

  流式计算cpu与memory按照1:4的比例,slave规格可以大一些

  开始可以按照:

  2台master 4cpu8g 250*1 SSD云盘

  2台slave 16cpu64g 250g*4 SSD云盘 后续可以按照实际情况扩展节点。

  离线计算 存储与计算分离

  离线计算其实可以做到离线在线分离的,比如把数据全部放在OSS中,再通过无状态的E-MapReduce分析。那E-MapReduce就纯粹的计算,不存在存储跟计算搭配来适应业务了,这样最为灵活。

  后记

 

  集群的规格最终还是需要用户按照自身的业务特点来最终评估,以上只是一些大体的原则。欢迎各位E-MapReduce及Hadoop用户给出自己的建议。





收藏 推荐 打印 | 录入:elainebo | 阅读:
本文评论   查看全部评论 (0)
表情: 表情 姓名: 字数
点评:
       
评论声明
  • 尊重网上道德,遵守中华人民共和国的各项有关法律法规
  • 承担一切因您的行为而直接或间接导致的民事或刑事法律责任
  • 本站管理人员有权保留或删除其管辖留言中的任意内容
  • 本站有权在网站内转载或引用您的评论
  • 参与本评论即表明您已经阅读并接受上述条款