文档介绍：第一部分:Hadoop计算框架的特性什么是数据倾斜由于数据的不均衡原因,导致数据分布不均匀,造成数据大量的集中到一点,造成数据热点。Hadoop框架的特性1)不怕数据大,怕数据倾斜2)jobs数比较多的作业运行效率相对比较低,比如即使有几百行的表,如果多次关联多次汇总,产生十几个jobs,耗时很长。原因是mapreduce作业初始化的时间是比较长的3)sum,count,max,min等UDAF,不怕数据倾斜问题,hadoop在map端的汇总合并优化,使数据倾斜不成问题4)count(distinct),在数据量大的情况下,效率较低,因为count(distinct)是按groupby字段分组,按distinct字段排序,一般这种分布方式是很倾斜的。第二部分:优化的常用手段优化的常用手段1)解决数据倾斜问题减少job数2)设置合理的mapreduce的3)task数,能有效提升性能。了解数据分布,自己动手解决数据倾斜问题是个不错的选择4)数据量较大的情况下,慎用count(distinct)5)。对小文件进行合并,是行至有效的提高调度效率的方法。6)优化时把握整体,单个作业最优不如整体最优。7)第三部分:Hive的数据类型方面的优化优化原则按照一定规则分区(例如根据日期)。通过分区,查询的时候指定分区,会大大减少在无用数据上的扫描,同时也非常方便数据清理。合理的设置Buckets。在一些大数据join的情况下,mapjoin有时候会内存不够。如果使用BucketMapJoin的话,可以只把其中的一个bucket放到内存中,内存中原来放不下的内存表就变得可以放下。这需要使用buckets的键进行join的条件连结,=true第四部分:Hive的操作方面的优化全排序Hive的排序关键字是SORTBY,它有意区别于传统数据库的ORDERBY也是为了强调两者的区别–SORTBY只能在单机范围内排序。怎样做笛卡尔积当Hive设定为严格模式(=strict)时,不允许在HQL语句中出现笛卡尔积,MapJoin是的解决办法。MapJoin,顾名思义,会在Map端完成Join操作。这需要将Join操作的一个或多个表完全读入内存MapJoin的用法是在查询/子查询的SELECT关键字后面添加/*+MAPJOIN(tablelist)*/提示优化器转化为MapJoin(目前Hive的优化器不能自动优化MapJoin)其中tablelist可以是一个表,或以逗号连接的表的列表。tablelist中的表将会读入内存,应该将小表写在这里在大表和小表做笛卡尔积时,规避笛卡尔积的方法是,给Join添加一个Joinkey,原理很简单:将小表扩充一列joinkey,并将小表的条目复制数倍,joinkey各不相同;将大表扩充一列joinkey为随机数。控制Hive的Map数通常情况下,作业会通过input的目录产生一个或者多个map任务。主要的决定因素有:input的文件总个数,input的文件大小,集群设置的文件块大小(目前为128M,;命令查看到,该参数不能自定义修改)。是不是map数越多越好?答案是否定的。如果一个任务有很多小文件(远远小于块大小128m),则每个小文件也会被当做一个块,用一个map任务来完成,而一个map任务启动和初始化的时间远远大于逻辑处理的时间,就会造成很大的资源浪费。而且,同时可执行的map数是受限的是不是保证每个map处理接近128m的文件块,就高枕无忧了?答案也是不一定。比如有一个127m的文件,正常会用一个map去完成,但这个文件只有一个或者两个小字段,却有几千万的记录,如果map处理的逻辑比较复杂,用一个map任务去做,肯定也比较耗时。针对上面的问题3和4,我们需要采取两种方式来解决:即减少map数和增加map数;是不是保证每个map处理接近128m的文件块,就高枕无忧了?答案也是不一定。比如有一个127m的文件,正常会用一个map去完成,但这个文件只有一个或者两个小字段,却有几千万的记录,如果map处理的逻辑比较复杂,用一个map任务去做,肯定也比较耗时。针对上面的问题3和4,我们需要采取两种方式来解决:即减少map数和增加map数;举例:a)假设input目录下有1个文件a,大小为780M,那么hadoop会将该文件a分隔成7个块(6个128m的块和1个12m的块),从而产生7个map数。b)假设input目录下有3个文件a,b,c,大小分别为10m,20m,130m,那么hadoop会分隔成4个块(10m,20m,128m,2m),从而产生4个map数。即,如果