开源大数据平台资源隔离现状及演进思考

下面文字是来自天源迪科大数据专家一篇纯干货的实战思考。这种经验总结非常值得一看,真正的经验来自不停踩坑之后的灵光一现,然后茅塞顿开。 强烈推荐!!!也希望更多的同学也来一起分享。

引言

走过一些地方,发现各地都在建集中的大数据平台,提供数据、服务、工具,面向各分支部门、各外围合作伙伴,以“租户”的形式接入应用,谓之能力开放,是当下极为流行的做法。讲到开放,就要考虑考虑权限的控制、资源隔离,前者是安全控制,而后者技术性更强。当前常因为投资预算等客观原因,所谓的“大”集群规模其实也是相对的,往往就是百十来台,是否能够在这样一个单一的物理集群下承担复杂多样的应用呢?业界是没有一个标准的计算公式,更多还需要具体情况具体分析。所以我又经常碰到一些“重度使用”的集群环境,这是我们自己的一个说法,就是说集群的规模不是那么大,但上面跑的应用确是足够多。促成这个困局的现实因素是,不单是因为有限的预算,有时是因为过于技术理想主义、过度的资源压榨。讲真,如果集群规模上去了,又没几个应用,好多问题就不是问题。

案例讨论

以下给出一例:

上述集群规模在100台左右,存量数据5PB,增量在10TB/日。机器属于当前主流配置(256G内存,32核CPU)已接入的租户是30个左右,租户基本是按照不同的项目或应用为单元,可能是不同的厂家。这些应用可以分为三类,一类是离线批处理类,主要使用MR,hive,Tez,Spark,Impala长作业之类的应用以及一些即席查询,流计算实时批处理类作业主要是Spark Streaming类的作业,及基于Hbase之上的存储和查询类的业务,品种是非常齐全的。集群绝大部分时候运行良好,偶发性的性能问题有一些,主要是影响在线业务。

主机在某些时段,CPU消耗已出现繁忙

思考

提到资源的隔离,我们第一时间想到的是Yarn,没错,当前集群也使用它来管理很大一部分(Mr on yarn,Spark on Yarn,Tez on Yarn)采用用户级资源池公平调度,由于资源吃紧,最大资源数留多出一部分作为自由抢占。

但细看有一部分的资源是存在管理盲区:

  • Hbase资源隔离:只有一个全局的heapsize内存控制,没有做分用户的资源隔离,尽管当前版本已经具备单用户请求数的隔离,但验证发现对于一些scan操作结果诡异,与预期相去甚远,甚至影响正常使用,姑且认为它还不够健全而弃之。多说几句,Hbase这个组件我向来认为并不是那么好驾驭,属于上手很快、后期又容易出问题的一类东西,要求应用开发层面的考虑太多后台服务优化的点,处处充满了不人性化的设计。你比如说:hbase本来是强项基于键值的小批量查询的,偏偏也能通过hive外部表的方法来遍历查询或统计,完全当做一个关系型数据库来干了,这个动作的影响之大开发人员并没有想到,他们也无辜,问题在于hbase本身并未限制不能做这样的操作,所谓的开发规范也仅仅是一个建议。另外关于分区、键值设计等,搞不好就会影响脆弱的RS,还是要去和开发逐一阐述清楚。所以,我现在比较推举phoenix这种做了一层封装的hbase服务。关于hbase的问题,说是组件不足也好,说是使用不当也罢,反正,问题就摆在这儿。
  • Impala资源的隔离:有针对单个服务实例的内存控制,也能控制到了用户级队列控制,也仅仅有内存的限制,而CPU则是任由抢占,且目前资源并未交给Yarn集中托管。CPU抢占的结果是机器本身24核它可能抢去了20核,其它的服务怎么玩?需要补充说明的是,实际是存在Impala on Yarn技术:Llama,早期由于这个东西的版本一直处于测试阶段,我们认为冒然去使用会增加问题定位的难度,因而生产应用搁浅上。
  • IO的隔离:在用户队列层面,由于Yarn目前只做了CPU和核的控制,并未对IO做出控制,也就是放任抢占;当然,在服务进程层面,是可以通过cgroups做一些组件层面的限制。

重度应用环境下,技术异构体现更明显,有的是CPU密集型,有的是IO密集型,应用间的影响可能性加大,问题的定位变得更困难。例如:下图显示上面集群出现的一个问题,部分主机间歇性卡顿,top显示不是用户CPU消耗过高,而是的Sys消耗高。主机一卡顿,可能各种服务问题都会随之而来。

Sys过高通常有swap使用、线程交换方面的问题,而I/O方面也是潜在的因素。

以上文字说明的是:大量I/O操作也可能触发sys高负载,想想也是,所谓的sys不就是操作系统调用,当然与read,write有关的。通过比对相同时间点上的IO负载,发现确有此类问题。

而下面张图则显示的是在针对hbase做遍历时,hbase集群层面的请求数陡增,由此引发的性能问题。

不可否认,当前技术发展的趋势总体上朝着融合的方向走,通过多租户隔离实现资源最大化的共享,大家在一个集中的平台上转。现实问题在于当前开源技术还不那么成熟,更不要说生产版本还有一定滞后,直接导致资源的隔离不彻底,应用之间相互依旧有干扰。运营过程痛苦。

方案讨论

鉴于上述情况,本人斗胆建议:针对小规模的集群(<200台),现阶段还是老老实实做一定的集群拆分,特别是生产级要求高的在线业务,通过简单的分拆规避干扰。我下图给出的是一个基于技术维度上的切分,也仅供参考。细分这些应用发现,还是有那么一些应用是死不了人的,大不了可以重启解决掉(开源的东西大家都能理解),有些则是真的有所要求的。这么说可能不太严谨,但在当前过渡阶段确是有效的办法。

至于在技术演进方面,我们也不是无动于衷,以下是可以去做的:

  • Impala:如上文提到的,引入Llama组件,将Impala服务的资源交给Yarn集中管理。现阶段看Yarn作为一个统一的资源管理入口,就比较可控了。而关于Impala的执行容错性已经被一些案例中提及,我们也有有同类经历,这会引起我们在选型中的严重关注
  • Hbase:针对资源的隔离方案也是有的,我们探究了三种:

方案1:逻辑隔离:HDFS共享一套,基于之上搭建多个Hbase集群(分在不同主机上),不需要额外迁移数据

方案2:物理隔离:完全独立,包括HDFS也是分离的,隔离效果最优,但涉及数据在不同HDFS之间交互,很多人很忌讳做这个

方案3:Hbase on yarn:在Hbase2.0中得以支持。类似逻辑隔离,基于Yarn面向各个用户提供单独的Hbase集群实例,regionServer运行在YARN上

本文主要是结合实际经历遇到的问题进行了一下思路总结,限于自己的眼界下给出的观点,定有不妥之处,期待与你探讨。

原文发布于微信公众号 - 大数据和云计算技术(jiezhu2007)

原文发表时间:2017-09-02

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏织云平台团队的专栏

腾讯最完整的监控体系介绍,看这篇就够了!

腾讯业务监控体系的层级构成,用代表性的监控系统阐述每个监控层次的实现方法,以及与监控体系配合,业务做了哪些容灾和调度的方案。从而和大家分享腾讯最完整的关于做监控...

2.3K6
来自专栏北京马哥教育

面向容器技术资源调度关键技术对比

摘要:本文以资源分配理念:拍卖、预算、抢占出发,引出Borg、Omega、Mesos、Kubernetes架构、数据、API的特点比较。然后梳理资源共享各种不同...

2847
来自专栏云计算D1net

云数据恢复:文档是成功的关键

创建云上的数据恢复计划,很重要的一点是持续跟踪基础架构,DR需求和可能的故障转移持续时间。 公有云给IT部门提供了绝佳的机会来实现业务的持续性/灾难恢复计划,而...

2677
来自专栏华章科技

经典收藏丨数据科学家&大数据技术人员工具包

本文简介:数据科学家的常用工具与基本思路,数据分析师和数据科学家使用的工具综合概述,包括开源的技术平台相关工具、挖掘分析处理工具、其它常见工具等几百种,几十个大...

682
来自专栏钱塘大数据

大数据技术人员必备工具包,为工作提质增效

本文作者:秦陇纪 ? 本文简介:数据科学家的常用工具与基本思路,数据分析师和数据科学家使用的工具综合概述,包括开源的技术平台相关工具、挖掘分析处理工具、其它常见...

3665
来自专栏廖念波的专栏

谈谈 KV 存储集群的设计要点

不同于无数据的逻辑层框架,KV 存储系统的架构设计会更复杂、运维工作更繁琐、运营过程中可能出现的状况更多、bug 收敛时间会更长。一句话:团队自己做一个 KV ...

2K0
来自专栏流柯技术学院

性能测试之吞吐量

我们每天的生活中都在用水用电,我只会关心自己的水管是否有水,水压是否稳定,如果我们把水龙头拧到最大,还是一滴一滴的流水。那我们就要愤怒了,直接找房东问明情况。我...

1264
来自专栏张善友的专栏

MongoDB新版本特性

MongoDB 2.4已经发布,该版本增加了一些新特性,如文本搜索、基于哈希的分片、更好的地理空间功能、支持GeoJSON以及一些性能和工具方面的提升。我们还和...

1805
来自专栏小狼的世界

Google SRE 读书笔记 扒一扒SRE用的那些工具

最近花了一点时间阅读了《SRE Goolge运维解密》这本书,对于书的内容大家可以看看豆瓣上的介绍。总体而言,这本书是首次比较系统的披露Google内部SRE运...

892
来自专栏BeJavaGod

分布式系统的那些事儿(一)

巨石应用在如今互联网+时代逐渐淘汰,而分布式系统,集群,微服务可谓现在的流行趋势。那么近期花点时间来讲讲分布式系统吧。 什么是分布式系统,很多人一直不理解,只知...

3336

扫码关注云+社区