作为大数据工程师,你必须熟练运用的性能优化技术

最近几年一直参与大数据产品的研发,同时大数据产品在海量数据场景下其处理性能又是其主要卖点和突破,所以个人在这几年经常忙于如何对大数据产品进行性能上面的优化,并且想通过本文和大家聊聊具体的几种比较常见大数据性能优化技术。

常见的大数据性能优化技术一般分为两部分,其一是硬件和系统层面的观测,从而来发现具体的瓶颈,并进行硬件或者系统级的调整;其二是主要通过对软件具体使用方法的调整来实现优化。

硬件方面的监测

  图1. Windows7性能指数

关于硬件性能本身,个人觉得最好对性能的诠释就像图1大家比较熟悉的Windows7操作系统性能指数所展示的一样,性能本身并在于其所长,而是在于其所短,就像图1里面那个5.4分主硬盘托了整体的后腿一样,只要有短板存在,其他地方再强也可能收效甚微,所以需要硬件的性能检测就是找出短板在那里,并且尽可能地找到应对的方法。

在硬件观测角度方面,主要通过以下四个维度来判断到底哪里是瓶颈,它们分别是CPU、内存、硬盘还有网络。

CPU利用率

首先,在讲检测CPU性能之前,我们可以通过这个“cat /proc/cpuinfo |grep “processor”|wc -l”命令来获取本机的核数(如果开了超线程,一个核可以被看作两个核),这样可以知道CPU利用率的上限是多少。

最常用CPU监测工具是TOP,当然TOP输出是一个瞬间值,如果想获取精确的数据,需要持续关注一段时间。

  图2 TOP示例

TOP的使用主要看两个值,其一是总体使用值,其最大值是100%,就是图2第三行Cpu(s),前面两个0.2%分别是用户态和内核态的利用率 而99.7%是CPU空闲率,从这个可以看出,本机的CPU部分基本是空闲的;其二可以看相关进程,看它的“%CPU”使用率,比如,Xorg这个GUI进程的占用率是0.3%,但是这里面的100%不是本机所有CPU的100%,而是单个核的100%。所以它的上限会是本机核数*100%。

  图3 uptime示例

因为TOP主要关注的是瞬时的值,如果要看一段时间的均值,这个时候可以用uptime这个命令,见图3,它除了可以显示当前总运行时,当前在线用户,更重要的是可以显示1分钟、5分钟、15分钟的整机CPU的平均负载情况。

假设在平时监测的时候,如果经常碰到用满80%以上CPU资源的话,可以理解为CPU利用率高,在这种场景下大多数只能靠优化执行逻辑,才能提升效率。

内存的监测

  图4 free -m的示例

关于内存的监测,常用的命令是free -m,通过这个命令可以查看系统内存的具体使用情况。其中total,used和free都很好理解,通过这三列可以看出此时系统总内存,已经使用内存和没有被使用的内存,而cached这列则表示有多少内存已经被Page Cache占用,但当系统内存吃紧的时候,Page Cache会立即被回收并分配给请求内存的应用程序,所以Page Cache也可以被视为处于free状态的内存。

还有下面的Swap分区,如果used数值比较高,说明内存非常紧张,系统已经动用交换区,同时IO开销也会增长非常明显。当发现内存不够用的情况,可以考虑重启或者关闭那些占用很多内存的进程。

在这里稍微扩展一下Page Cache这个内存机制,因为这个机制对大数据挺重要的。一般在Linux系统上,利用默认系统I/O接口写入的文件块,会先在Page Cache上面有一个缓存,之后再写入到I/O设备上面,那么假设系统内存没有被占有满的话,在这种情况下,这个缓存会长时间保留,并不会被洗出内存,这样等下次程序访问到这些文件块的时候,肯定会访问Page Cache上面的那个版本,也就是直接访问内存,所以性能方面是内存级别的。

I/O性能的监测

  图5 iostat –xz 1示例

关于I/O性能,可以通过iostat这个命令来观察I/O的性能,具体见图5(sda是主硬盘),虽然参数比较多,但可以主要关注这两个参数:

其一是await,它代表了IO操作的平均等待时间,单位是毫秒,这也是应用和磁盘之间操作所要消耗的时间,包括等待和实际的操作,如果这个数值大,说明I/O资源非常忙或者有故障;

其二是%util,也就是设备利用率,数值如果超过60,所以利用率很高,并会影响I/O平均等待时间,如果到100,那就说明设备已饱和了,只能添加更多I/O资源。

网络方面的监测

  图6 sar –n DEV 1示例

在网络方面,使用的比较多的sar(System Activity Reporter)命令,如图6。这个命令可以查看网络设备的吞吐率,并在这个基础上,将吞吐量和硬件上限做对比,来判断网络设备是否已经饱和,假设以单张千兆网卡为例,如果“rxkB/s”和“txkB/s”两种相加超过100MB的话,说明网络已经接近饱和了。还有除了这个通过命令行来获取网络数据之外,还可以通过开源的nload的工具来进行监测,具体见下图:

  图7:nload示例

VMSTAT

  图8 vmstat 1示例

其实除了上面这些工具外,还有一个vmstat这个全能的命令,能监控硬件的方方面面,比如,如图8所示,Procs的“r”列,这个列显示正在等待CPU资源的进程数,这个数据比之前看的top和uptime更加能够体现CPU负载情况,并且这个数据不包含等待IO的进程。如果这个数值大于机器CPU核数,那么机器的CPU资源已经饱和。

Memory部分的“free”,“buff”和“cache”列的作用和上面free作用类似,而“si”和“so”说明使用Swap的次数,如果这个数据不为0,说明Swap交换区已经在使用,也意味着物理内存已经不足。

Cpu部分也大体和TOP上面显示类似,但可以关注“wa”这列,其代表的是IO等待时间,如果数值大于0的话,可以判断I/O资源有争抢。

如果通过上面硬件方面的监测,发现了瓶颈,或者发现了有很多余量,可以通过下半部分的软件方面的优化来进行调整,如果软件方面也无能为力的话,那么只能通过购买和安装更多的硬件。

软件方面的优化

这个方面因为各个大数据产品的实现方式不同,并且需要优化点也不同,操作方式更是不同,所以在这里,主要提供一些方针供大家参考。

写入优化

因为常见大数据产品的写入和传统关系型数据库是不同,传统关系数据库的写入是一行一行的写入,而常见大数据产品的写入是批量的写入,并且每次批量写入之后,都会生成新的数据文件,并且这个数据文件是不会被修改的。所以导入数据粒度小的话会导致很多细小文件产生,这样会导致更多的I/O操作,所以在使用大数据产品的时候,导入数据规模是越大越好,常见的规模在100MB以上为佳。

尽可能地并行

假设通过前面的硬件方面的测试方面,发现无论是CPU,内存,I/O还是网络,都没有遇到瓶颈,并且至少有20%潜力可挖,这个时候可以考虑尽可能地通过并行来提升性能,主要有两个方式:其一是每台机器上面部署更多的进程来压榨硬件资源;其二是提升单个进程的多线程数,这种方式比第一种更简单,风险也更低。总体而言,尽量使每台机器所使用到的线程数可以达到系统自身线程数的80%。

尽可能使用压缩和列存

对于一些新入门的工程师,也包括那些有很多传统关系数据库使用经验的专业DBA数据管理员而言,大家都对列存比较一知半解,从而不敢使用。

列存和传统行存相比,主要有两个比较大的区别:

其一是数据不是按照行来存储,而且是将很多行的数据按列归属在一起,并存储 ,具体可以看图9;

其二是一般行存的写入是一行行,而且列存是比较批量的,所以写入的数据库块会比较大,一般大于行存常见的8KB。基于我个人这几年的经验,列存在极大多数分析场景下,都能提升3倍以上的性能,除了 些需要遍历一个表半数以上列的场景。因为通过列存不仅能够通过避免那些不要列的导入,这样能减少硬盘的I/O总量。并且由于列存本身数据是一个大块一个大块的存在,所以是硬盘I/O读取操作的次数也会减伤,这个对于硬盘I/O非常有利,因为本身硬盘I/O单次随机读取操作的成本非常高,和SSD相比。但是批量连续成本却非常优秀,当然如果使用SSD的话,性能会更优。

在这个基础上,由于连续数据都归属于一列都比较类似,比如,性别,所以对其压缩的效果非常不错,一般在1比5左右,并且通过压缩节省的I/O远大于压缩和解压缩所带来CPU的损耗。这也导致就算所有数据全都在硬盘上,其性能的损失和所有数据在内存上面缓存相比,一般慢4到5倍左右,其他也不会特别亏。

  图9 列存和行存的对比

善加利用Page Cache

在上半部分已经提到了, 利用好Page Cache可以达到最基础级别的内存计算的效果,当然和真正意义上的内存计算还是很大的距离。在性能测试的时候,这个优化是比较常见的。一般作法是,先通过命令“sync; echo 3 > /proc/sys/vm/drop_caches”来清空page cache,之后跑一下比较简单,但又能加载所有相关数据的语句,比如,对每一列进行求总,这种做法的坏处是没有机会应对真实可能存在性能瓶颈,这对今后的实际运行会产生很多不可控的因素,因为真实业务场景肯定会比所预想到的场景更复杂。

利用好分区特性

众所周知,最快SQL就是什么都不做的SQL,比如,“select 1”;当然在实际的操作过程中,肯定不会有类似“select 1”这样没有意义的操作。所以对于传统关系数据库而言,为了减少读取不必要的数据,一般会使用索引。但是对于大数据这样分析操作而言,索引这种机制太昂贵,而且收效甚微。

分析大数据应用常用的过滤数据的方式是分区,特别是按照时间来分区,因为一般时间是最合适分割大数据的维度,比如,数据按照月分区,这样如果查询只需要涉及到某月数据,那么其余十一个月数据可以立刻忽略,当然如果按日来分区的,效果可能会更好,但尽量避免因为粒度太小,导致写入文件过于碎片化的情况。

Join的优化

对于大数据的分析应用而言,Join操作是非常常见的,并且Join操作本身对硬件的短板也更敏感,特别是网络,因为大多数的分布式操作,每个数据节点可以独立地完成,但 Join经常需要来自其他节点数据才能完成本节点的执行,并且这个量可能很大,有的时候,一个节点执行所需要的数据远超本节点自带的数据,类似场景还有unique这样的去重操作,所以在调优方面消耗的功夫也最多。

常见Join方式,主要有三种:

其一是Broadcast广播,常用于大小表之间的Join,Join发起方会将小表的相关数据完整地分发到每个数据节点,之后当每个数据节点收到小表之后,会找其本地的大表数据来完成Join的,如图10,pages是小表,visits是大表,发起方将Pages这张小表分发到每个数据节点;

其二是对小表Local化,这个机制本质上非常类似Broadcast,只是分发小表这个操作是做导入数据的时候自动完成,性能肯定比Broadcast更好,因为减少传输小表的网络消耗和等待时间,但是需要在创建表的时候,做一些额外的设置,这个机制在MPP数据是非常常见的,但是在Hadoop平台上面还是比较少见,因为其底层的HDFS分布式文件系统比较强调硬件无关,地址透明,这个和数据尽可能Local化的思路是违背的;

其三是Shuffle或者Partitioned Join机制,其常用于两张大表之间的Join。因为将大表都分发给每个节点肯定成本太高了,而且数据节点的内存不一定能放的下这么多数据,所以通过Shuffle洗牌机制,也就是将所有参与的Join表的相关部分按照某种机制均匀分发到各个节点,并且每个节点数据都是独立的,如图11所示,pages和visits都是大表,它们按照Join列Hash的值来进行再次分布,节点1有Join列为A-E的数据,之后依次类推,虽然成本很高,但是对于大表之间的Join是最合理和最可行的方法。

  图10 Broadcast Join

  图11 Shuffle Join

介绍完Join机制之后,再深入一下Join的优化,也主要有三个方面:

其一是在大表和小表摆放顺序要符合技术规范,这样能避免优化器将大表作为Broadcast表来进行分发;

其二是开启或者执行预统计,也就是在查询之前,开启表的预统计,虽然预统计会耗费一点时间,但这样能够让优化器知道表的具体情况,从而做出合理的方案,即使之前表的顺序写错了,还有由于预统计会遍历数据,这样可以将数据预先加载到Page Cache上面;

其三是选择合理的Join机制,也就是做好Broadcast和Shuffle之间的抉择,两个大表之间选择Shuffle,如果不是选择Broadcast,当然假如优化器能判断出是更好不过了,但当优化器出现问题的时候,可以通过人工输入一些提示符来帮助优化器来判断;

多看Profile

介绍很多优化技术,但是这样技术都比较笼统,为了更好做优化,做某个产品优化,还是最好能多看看每次执行后的Profile,这样能对产品更深的理解。

因为大数据产品和技术比较多,并且每个产品和特色和设计都不同,所以在细节方面没有特别深入,但是的确有非常多的共性,所以通过硬件的监测,以及软件方面的优化,应该能把常见的大数据产品发挥到八成的功力。

====================================分割线================================

本文转自d1net(转载)

时间: 2017-07-05

作为大数据工程师,你必须熟练运用的性能优化技术的相关文章

大数据工程师练成记之首重:知识体系一览!

我们想要告诉大家的是成为大数据工程师需要掌握的知识体系,而作为初学者,你可以先从简单的入手,慢慢在学更深的知识,拿出高考的恒心和坚持来,肯定能行. 值得一提的是,目前大数据工程师的月薪都是20K起,月收入两万的薪资是不是很诱人?而且大数据工程师是非常容易找到工作的,所以--Why not 不扯犊子了,由于篇幅所限,这一部分内容主要包括数据可视化.机器学习和算法三个分支. 数据可视化 R R不仅是编程语言,同时也R具有强大的统计计算功能和便捷的数据可视化系统.在此,推荐大家看一本书,这本书叫做<R

2017年,大数据工程师应该如何充实自己的专业工具箱

随着互联网应用的普及.智能硬件的发展,数据产生的速度呈现了持续爆炸式的增长,数据产生的价值也已不仅取决于空间维度,同时开始在时间维度进行延展,因此提高计算的时效性,更快的从数据中挖掘出信息和知识就意味着能够获取更大的价值.这在阿里双十一大促这样的场景中表现的尤为明显,用户行为和商品变化信息带来的价值都是短暂有效的,因此大数据后台系统需要在线收集用户行为和商品变化等信息,实时调整搜索和推荐策略,为用户和商家提供更精准的服务. 在实时计算领域,Apache Storm.Samza.Spark Str

如何成为一名大数据工程师?

导 读 大数据是眼下非常时髦的技术名词,与此同时自然也催生出了一些与大数据处理相关的职业,通过对数据的挖掘分析来影响企业的商业决策. 这群人在国外被叫做数据科学家(Data Scientist),这个头衔最早由D.J.Pati和Jeff Hammerbacher于2008年提出,他们后来分别成为了领英(LinkedIn)和Facebook数据科学团队的负责人.而数据科学家这个职位目前也已经在美国传统的电信.零售.金融.制造.物流.医疗.教育等行业里开始创造价值. 不过在国内,大数据的应用才刚刚萌

如何成为一名优秀的大数据工程师

大数据是眼下非常时髦的技术名词,与此同时自然也催生出了一些与大数据处理相关的职业,通过对数据的挖掘分析来影响企业的商业决策. 这群人在国外被叫做数据科学家(Data Scientist),这个头衔最早由D.J.Pati和Jeff Hammerbacher于2008年提出,他们后来分别成为了领英(LinkedIn)和Facebook数据科学团队的负责人.而数据科学家这个职位目前也已经在美国传统的电信.零售.金融.制造.物流.医疗.教育等行业里开始创造价值. 不过在国内,大数据的应用才刚刚萌芽,人才

谁能做大数据工程师?

大数据是眼下非常时髦的技术名词,与此同时自然也催生出了一些与大数据处理相关的职业,通过对数据的挖掘分析来影响企业的商业决策.这群人在国外被叫做数据科学家(Data Scientist),这个头衔最早由D.J.Pati和Jeff Hammerbacher于2008年提出,他们后来分别成为了领英(LinkedIn)和Facebook数据科学团队的负责人.而数据科学家这个职位目前也已经在美国传统的电信.零售.金融.制造.物流.医疗.教育等行业里开始创造价值. 不过在国内,大数据的应用才刚刚萌芽,人才市

你们是不是真的很缺大数据工程师?

00 缘起 之所以有这个话题,是因为周末加班中午吃饭与一个同行朋友聊起了这个话题,之后再细细地结合一些其他接触的东西,确实是有些感触的. 并且对于行业的一些现状,也的确有些自己的看法,对不对先不论,这玩意儿也没有对错之分,每个人都有自己想法,当然也包括我博客虫了. 所以,有些东西.有些想法我还是愿意分享出来的,畅所欲言吧~~ 01 我眼中的大数据现状! 其实个人在大数据在大数据这个坑中,细细算来,时间也有3+年了,从一开始做大数据中心平台开发构建,到现在关注的数据上层应用挖掘.所以,基本上从数据

你们是不是很缺大数据工程师?

缘起 之所以有这个话题,是因为周末加班中午吃饭与一个同行朋友聊起了这个话题,之后再细细地结合一些其他接触的东西,确实是有些感触的. 并且对于行业的一些现状,也的确有些自己的看法,对不对先不论,这玩意儿也没有对错之分,每个人都有自己想法,当然也包括我啦. 所以,有些东西.有些想法我还是愿意分享出来的,畅所欲言吧~~ 1.我眼中的大数据现状 其实个人在大数据在大数据这个坑中,细细算来时间也有3+年了,从一开始做大数据中心平台开发构建,到现在关注的数据上层应用挖掘.所以,基本上从数据收集->数据处理(

身为DATASHUO大数据工程师,我亲手制作的2016年第一期数据报告

2016年,身为DATASHUO大数据工程师,这是我利用DATASHUO我亲手制作的第一期数据报告.主要也是因为最近快过年了,近期爆出了BA巨头的年终奖撕逼大战,不觉让本博主内心心动了一下.大家是不是都在准备跳槽了? 别慌,我们还是关注一下自己手头上的那点媳妇本吧!! [声明]以下数据全部来自于"DATASHUO",未经许可不得用于商业用途:如需转载,请联系本博主,或者注明出处

大数据工程师成稀缺资源 拥有怎样的学识才能胜任

大数据发展如火如荼势不可挡,IT公司们也是不管怎么样都要和大数据扯上关系,才显得自己有水平,但大数据并不是谁都可以做的,想做好大数据,就要有个优秀的大数据工程师,通过对数据的挖掘分析来影响企业的商业决策. 这群人在国外被叫做数据科学家(Data Scientist),这个头衔最早由D.J.Pati和Jeff Hammerbacher于2008年提出,他们后来分别成为了领英(LinkedIn)和Facebook数据科学团队的负责人.而数据科学家这个职位目前也已经在美国传统的电信.零售.金融.制造.