Hive QL详解.doc

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