Hive日志分析的大数据存储优化探讨
摘要信息化发展水平的提升，使数据成为现代生产生活中不可或缺的关键要素，但社会中很多生产领域产生的数据量都较大，如何实现可用信息转化是当前数据利用与研究的关键问题。文章基于Hive日志分析，对优化大数据的存储进行了探究，希望能够提高Hive日志信息查询效率，优化其整体功能，从而在实际应用中发挥更大的作用。
关键词Hive日志；大数据存储；存储优化
信息数据是当前社会发展领域的重要基础，一切生产与发展活动都要将信息数据作为依据与支持，而信息中数据内含量大，还存在隐含信息数据，对信息数据的充分挖掘与利用，能够有开发出信息数据的更多价值。当前信息技术对数据的开发与利用水平有了提升，但对于很多大数据的存储仍是难题，为此，对Hive 日志分析的大数据存储优化探讨对我国调整存储结构，提高大数据读写效率有着重要意义。
1 基于Hive优化大数据存储策略简述
Hive是隶属于Hadoop的数据仓库工具，其主要发挥的作用是利用HFDS进行大数据存储，然后根据用户的实际要求映射数据，成为数据表；另外，利用其自带的数据查询功能能够快速的为用户提供数据信息，并通过查询内容提交到计算程序中完成用户布置的任务，这项功能也是Hive日志的优势体现，利用这项功能能够快速进行数据信息查询、信息数据分析。所以，在Hive日志的基础特性上展开数据存储优化探究，应重视对日志分析方法的利用，具体的优化可以并从以下几个方面着手：一是，对日志中常用的功能以及查询服务进行全面的分析，也就是通过对用户使用习惯的数据统计，明确用户常用的功能，然后合理分化数据结构，为用户提供更为便利的服务[1]。二是，优化数据导入格式，使用每种数据的专用存储结构。三是，对数据字段进行压缩，但不能改变其数据表的顺序以及字段的物理意义。四是，将数据表作为字段取值的参照标准，然后深入优化存储类型。五是，编写UDF，在不对用户的日常使用习惯造成任何影响的基础上，优化存储数据，从而能够有效提升日志查询功能的效率，并且能够优化数据占据的空间面积。
2 科学分化日志查询区域，优化查询效率
Hive日志本身具备记录功能，也就是在通常情况下，Hive日志能够自动对自身的运行进行记录，这样操作人员减少了很多复杂的操作步骤，能够有效提高操作效率，操作人员可以利用对Hive的标写来具体分析日志，然后根据其具备的EXPLAIN特性，得到抽象与简化后的查询语句语法树，从而提高查询的效率，完善了查询服务功能。利用正则表达式进行特征数据获取，能够获得准确的语法结构或语句结构，从而详细的进行了shell脚本编写，这时工具可以同时或批量执行使用者通过EXPLAIN传递的指令，然后日志在快速时间内利用对用户使用
Hive日志分析的大数据存储优化探讨 摘要信息化发展水平的提升，使数据成为现代生产生活中不可或缺的关键要素，但社会中很多生产领域产生的数据量都较大，如何实现可用信息转化是当前数据利用与研究的关键问题。文章基于Hive日志分析，对优化大数据的存储进行了探究，希望能够提高Hive日志信息查询效率，优化其整体功能，从而在实际应用中发挥更大的作用。 关键词Hive日志；大数据存储；存储优化 信息数据是当前社会发展领域的重要基础，一切生产与发展活动都要将信息数据作为依据与支持，而信息中数据内含量大，还存在隐含信息数据，对信息数据的充分挖掘与利用，能够有开发出信息数据的更多价值。当前信息技术对数据的开发与利用水平有了提升，但对于很多大数据的存储仍是难题，为此，对Hive 日志分析的大数据存储优化探讨对我国调整存储结构，提高大数据读写效率有着重要意义。 1 基于Hive优化大数据存储策略简述 Hive是隶属于Hadoop的数据仓库工具，其主要发挥的作用是利用HFDS进行大数据存储，然后根据用户的实际要求映射数据，成为数据表；另外，利用其自带的数据查询功能能够快速的为用户提供数据信息，并通过查询内容提交到计算程序中完成用户布置的任务，这项功能也是Hive日志的优势体现，利用这项功能能够快速进行数据信息查询、信息数据分析。所以，在Hive日志的基础特性上展开数据存储优化探究，应重视对日志分析方法的利用，具体的优化可以并从以下几个方面着手：一是，对日志中常用的功能以及查询服务进行全面的分析，也就是通过对用户使用习惯的数据统计，明确用户常用的功能，然后合理分化数据结构，为用户提供更为便利的服务[1]。二是，优化数据导入格式，使用每种数据的专用存储结构。三是，对数据字段进行压缩，但不能改变其数据表的顺序以及字段的物理意义。四是，将数据表作为字段取值的参照标准，然后深入优化存储类型。五是，编写UDF，在不对用户的日常使用习惯造成任何影响的基础上，优化存储数据，从而能够有效提升日志查询功能的效率，并且能够优化数据占据的空间面积。 2 科学分化日志查询区域，优化查询效率 Hive日志本身具备记录功能，也就是在通常情况下，Hive日志能够自动对自身的运行进行记录，这样操作人员减少了很多复杂的操作步骤，能够有效提高操作效率，操作人员可以利用对Hive的标写来具体分析日志，然后根据其具备的EXPLAIN特性，得到抽象与简化后的查询语句语法树，从而提高查询的效率，完善了查询服务功能。利用正则表达式进行特征数据获取，能够获得准确的语法结构或语句结构，从而详细的进行了shell脚本编写，这时工具可以同时或批量执行使用者通过EXPLAIN传递的指令，然后日志在快速时间内利用对用户使用
优化时，把hive sql当做map reduce程序来读，会有意想不到的惊喜。 理解hadoop的核心能力，是hive优化的根本。这是这一年来，项目组所有成员宝贵的经验总结。 长期观察hadoop处理数据的过程，有几个显著的特征: 1.不怕数据多，就怕数据倾斜。 2．对jobs数比较多的作业运行效率相对比较低，比如即使有几百行的表，如果多次关联多次汇总，产生十几个jobs，没半小时是跑不完的。map reduce作业初始化的时间是比较长的。 3.对sum，count来说，不存在数据倾斜问题。 4.对count(distinct ),效率较低，数据量一多，准出问题，如果是多count(distinct )效率更低。 优化可以从几个方面着手： 1. 好的模型设计事半功倍。 2. 解决数据倾斜问题。 3. 减少job数。 4. 设置合理的map reduce的task数，能有效提升性能。(比如，10w+级别的计算，用160个reduce，那是相当的浪费，1个足够)。 5. 自己动手写sql解决数据倾斜问题是个不错的选择。set hive.groupby.skewindata=true;这是通用的算法优化，但算法优化总是漠视业务，习惯性提供通用的解决方法。 Etl开发人员更了解业务，更了解数据，所以通过业务逻辑解决倾斜的方法往往更精确，更有效。 6. 对count(distinct)采取漠视的方法，尤其数据大的时候很容易产生倾斜问题，不抱侥幸心理。自己动手，丰衣足食。
7. 对小文件进行合并，是行至有效的提高调度效率的方法，假如我们的作业设置合理的文件数，对云梯的整体调度效率也会产生积极的影响。 8. 优化时把握整体，单个作业最优不如整体最优。 迁移和优化过程中的案例： 问题1：如日志中，常会有信息丢失的问题，比如全网日志中的user_id，如果取其中的user_id和bmw_users关联，就会碰到数据倾斜的问题。 方法：解决数据倾斜问题 解决方法1. User_id为空的不参与关联，例如： Select * From log a Join bmw_users b On https://www.doczj.com/doc/0414061499.html,er_id is not null And https://www.doczj.com/doc/0414061499.html,er_id = https://www.doczj.com/doc/0414061499.html,er_id Union all Select * from log a where https://www.doczj.com/doc/0414061499.html,er_id is null. 解决方法2 ： Select * from log a
Hive性能优化 1.概述 本人在工作中总结Hive的常用优化手段和在工作中使用Hive出现的问题。下面开始本篇文章的优化介绍。 2.介绍 首先，我们来看看hadoop的计算框架特性，在此特性下会衍生哪些问题？ ?数据量大不是问题，数据倾斜是个问题。 ? jobs数比较多的作业运行效率相对比较低，比如即使有几百行的表，如果多次关联多次汇总，产生十几个jobs，耗时很长。原因是map reduce作业初始化的时间是比较长的。 ? sum,count,max,min等UDAF，不怕数据倾斜问题,hadoop在map 端的汇总合并优化，使数据倾斜不成问题。 ? count(distinct ),在数据量大的情况下，效率较低，如果是多count(distinct )效率更低，因为count(distinct)是按group by 字段分组，按distinct字段排序，一般这种分布方式是很倾斜的。举个例子：比如男uv,女uv，像淘宝一天30亿的pv，如果按性别分组，分配2个reduce,每个reduce处理15亿数据。
面对这些问题，我们能有哪些有效的优化手段呢？下面列出一些在工作有效可行的优化手段： ?好的模型设计事半功倍。 ?解决数据倾斜问题。 ?减少job数。 ?设置合理的map reduce的task数，能有效提升性能。(比如，10w+级别的计算，用160个reduce，那是相当的浪费，1个足够)。 ?了解数据分布，自己动手解决数据倾斜问题是个不错的选择。 set hive.groupby.skewindata=true;这是通用的算法优化，但算法优化有时不能适应特定业务背景，开发人员了解业务，了解数据，可以通过业务逻辑精确有效的解决数据倾斜问题。 ?数据量较大的情况下，慎用count(distinct)，count(distinct)容易产生倾斜问题。 ?对小文件进行合并，是行至有效的提高调度效率的方法，假如所有的作业设置合理的文件数，对云梯的整体调度效率也会产生积极的正向影响。 ?优化时把握整体，单个作业最优不如整体最优。 而接下来，我们心中应该会有一些疑问，影响性能的根源是什么？ 3.性能低下的根源
Hive性能优化总结 介绍 首先，我们来看看Hadoop的计算框架特性，在此特性下会衍生哪 些问题？ ?数据量大不是问题，数据倾斜是个问题。 ?jobs数比较多的作业运行效率相对比较低，比如即使有几百行的表，如果多次关联 多次汇总，产生十几个jobs，耗时很长。原因是map reduce作业初始化的时间是 比较长的。 ?sum,count,max,min等UDAF，不怕数据倾斜问题,hadoop在map端的汇总合并优化， 使数据倾斜不成问题。 count(distinct ),在数据量大的情况下，效率较低，如果是多count(distinct )效率更低，因为count(distinct)是按group by 字段分组，按distinct字段排序，一般这种分布方式是很倾斜的。举个例子：比如男uv,女uv，像淘宝一天30亿的pv，如果按性别分组，分配2个reduce,每个reduce处理15亿数据。 面对这些问题，我们能有哪些有效的优化手段呢？下面列出一些在工作有效可行的优化手段： 好的模型设计事半功倍。 ?解决数据倾斜问题。 ?减少job数。 ?设置合理的map reduce的task数，能有效提升性能。(比如，10w+级别的计算，用 160个reduce，那是相当的浪费，1个足够)。 ?了解数据分布，自己动手解决数据倾斜问题是个不错的选择。set hive.groupby.skewindata=true;这是通用的算法优化，但算法优化有时不能适应特定 业务背景，开发人员了解业务，了解数据，可以通过业务逻辑精确有效的解决数据 倾斜问题。 ?数据量较大的情况下，慎用count(distinct)，count(distinct)容易产生倾斜问题。 ?对小文件进行合并，是行至有效的提高调度效率的方法，假如所有的作业设置合理 的文件数，对云梯的整体调度效率也会产生积极的正向影响。 优化时把握整体，单个作业最优不如整体最优。 而接下来，我们心中应该会有一些疑问，影响性能的根源是什么？
Hive规则及常用语法 一.hive介绍 hive是基于Hadoop的一个数据仓库工具，可以将结构化的数据文件映射为一张数据库表，并提供简单的sql查询功能，可以将sql语句转换为MapReduce任务进行运行。其优点是学习成本低，可以通过类SQL语句快速实现简单的MapReduce统计，不必开发专门的MapReduce应用，十分适合数据仓库的统计分析。 二.Hive规则 1.建表规则 表名使用小写英文以字符串模块名称，项目以BI开头(数据集市以DM)以’_’分割主业务功能块名,然后详细业务名,最后以数据表类别结尾,数据表存放在相应的表空间 例如: 数据仓库层_业务大类_业务小类-*** 示例 dw_mobile_start_week dw_mobile_start_mon dw_mobile_start_day 1）在建立长期使用的表时，需要给每个字段Column填写Comment栏，加上中文注释方便查看。对于临时表在表名后加上temp; 2）对运算过程中临时使用的表，用完后即使删除，以便及时的回收空间。临时表如果只用来处理一天数据并且每天都要使用不要按时间建分区。避免造成临时表数据越来越大。 3）字段名应使用英文创建，字段类型尽量使用string.避免多表关联时关联字段类型不一致。 4）多表中存在关联关系的字段，名称，字段类型保持一致。方便直观看出关联关系及连接查询。 5）建表时能够划分分区的表尽量划分分区。 6）建表时为表指定表所在数据库中。 2.查询规则 1.多表执行join操作时，用户需保证连续查询中的表的大小从左到右是依次增加的。也 可以使用/*+STREAMTABLES(表别名)*/来标记大表。
Hive update实现方案 1.问题 由于hive数仓的特性，不容许数据进行修改，造成hive中的数据更新活着删除很困难的问题，自hive 0.11版本之后，hive也尝试在测试环境允许进行update和delte操作，但这些操作还不成熟，不敢在生产环境放心使用，其中也有一样不足。所以就需要找一种可靠的方案实现hive的数据更新或者删除。 2.方案 2.1.创建数据表 创建两张数据结构一模一样的hive数据表TEST、TEST_TEMP，其中TEST表的存储格式为“ORCFILE”（性能高），TEST_TEMP 表的存储格式为“TEXTFILE”（方便数据加载）。 ID NAME AGE 主键姓名年龄 create table TEST_TEMP ( id string, name string, age string ) comment '临时表' partitioned by (y string,m string,d string) row format delimited fields terminated by',' stored as textfile create table TEST (
id string, name string, age string ) comment '最终表' row format delimited fields terminated by',' stored as orcfile 2.2.初始化 1.通过hive数据load的方式先把数据加载到TEST_TEMP表中 （此处也可以通过sqoop进行数据抽取，不再详述）。 load data local inpath '/home/hadoop/a.txt' overwrite intotable TEST_TEMP 2.通过hive insert overwrite的方式把临时表的数据加载到最终 表TEST中。 insertintotable TEST select id,name,age from TEST_TEMP 2.3.日常 1.通过hive数据load的方式先把数据加载到TEST_TEM表中 （此处也可以通过sqoop进行数据抽取，不再详述）。 load data local inpath '/home/hadoop/b.txt' overwrite intotable TEST_TEMP 2.通过数据比对方式，找出非更新和非增量的数据，人后把这 部分数据覆盖到TEST表中，即保证TEST中的数据和 TEST_TEMP中的没有重复(前提是表中必须有主键)。 INSERT OVERWRITE TABLE TEST SELECT id,name,age FROM TEST a LEFT JOIN TEST_TEMP b on a.id=b.id WHERE b.id is null; 注：上述语句其实就是not in的逻辑，如果日常数据上包含增、 删、改标识，则只需在关联时在TEST_TEMP表上加条件判
一、join优化 Join查找操作的基本原则：应该将条目少的表/子查询放在Join 操作符的左边。原因是在Join 操作的Reduce 阶段，位于Join 操作符左边的表的内容会被加载进内存，将条目少的表放在左边，可以有效减少发生内存溢出错误的几率。 Join查找操作中如果存在多个join，且所有参与join的表中其参与join的key都相同，则会将所有的join合并到一个mapred程序中。 案例： SELECT a.val, b.val, c.val FROM a JOIN b ON (a.key = b.key1) JOIN c ON (c.key = b.key1) 在一个mapre程序中执行join SELECT a.val, b.val, c.val FROM a JOIN b ON (a.key = b.key1) JOIN c ON (c.key = b.key2) 在两个mapred程序中执行join Map join的关键在于join操作中的某个表的数据量很小，案例： SELECT /*+ MAPJOIN(b) */ a.key, a.value FROM a join b on a.key = b.key Mapjoin 的限制是无法执行a FULL/RIGHT OUTER JOIN b，和map join相关的hive参数：hive.join.emit.interval hive.mapjoin.size.key hive.mapjoin.cache.numrows 由于join操作是在where操作之前执行，所以当你在执行join时，where条件并不能起到减少join数据的作用；案例： SELECT a.val, b.val FROM a LEFT OUTER JOIN b ON (a.key=b.key) WHERE a.ds='2009-07-07' AND b.ds='2009-07-07' 最好修改为： SELECT a.val, b.val FROM a LEFT OUTER JOIN b ON (a.key=b.key AND b.ds='2009-07-07' AND a.ds='2009-07-07') 在join操作的每一个mapred程序中，hive都会把出现在join语句中相对靠后的表的数据stream化，相对靠前的变的数据缓存在内存中。当然，也可以手动指定stream化的表：SELECT /*+ STREAMTABLE(a) */ a.val, b.val, c.val FROM a JOIN b ON (a.key = b.key1) JOIN c ON (c.key = b.key1) 二、group by 优化 Map端聚合，首先在map端进行初步聚合，最后在reduce端得出最终结果，相关参数：? hive.map.aggr = true是否在Map 端进行聚合，默认为True ? hive.groupby.mapaggr.checkinterval = 100000在Map 端进行聚合操作的条目数目 数据倾斜聚合优化，设置参数hive.groupby.skewindata = true，当选项设定为true，生成的查询计划会有两个MR Job。第一个MR Job 中，Map 的输出结果集合会随机分布到Reduce 中，每个Reduce 做部分聚合操作，并输出结果，这样处理的结果是相同的Group By Key 有可能被分发到不同的Reduce 中，从而达到负载均衡的目的；第二个MR Job 再
hive常用优化方法大全 hive是基于Hadoop的一个数据仓库工具，可以将结构化的数据文件映射为一张数据库表，并提供简单的sql查询功能，可以通过类SQL语句快速实现简单的MapReduce统计，十分适合数据仓库的统计分析。 在使用hive的过程中，可以进行hive优化，以下是常用的hive优化方法： 1. join连接时的优化：当三个或多个以上的表进行join操作时，如果每个on使用相同的字段连接时只会产生一个mapreduce； 2. join连接时的优化：当多个表进行查询时，从左到右表的大小顺序应该是从小到大，原因是hive在对每行记录操作时会把其他表先缓存起来，直到扫描最后的表进行计算； 3. 在where字句中增加分区过滤器； 4. 当可以使用left semi join 语法时不要使用inner join，前者效率更高，原因是对于左表中指定的一条记录，一旦在右表中找到立即停止扫描； 5. 如果所有表中有一张表足够小，则可置于内存中，这样在和其他表进行连接的时候就能完成匹配，省略掉reduce过程，设置属性即可实现，set hive.auto.covert.join=true; 用户可以配置希望被优化的小表的大小 set hive.mapjoin.smalltable.size=2500000; 如果需要使用这两个配置可置入$HOME/.hiverc文件中； 6. 同一种数据的多种处理：从一个数据源产生的多个数据聚合，无需每次聚合都需要重新扫描一次； 7. limit调优：limit语句通常是执行整个语句后返回部分结果，set
hive.limit.optimize.enable=true； 8. 开启并发执行：某个job任务中可能包含众多的阶段，其中某些阶段没有依赖关系可以并发执行，开启并发执行后job任务可以更快的完成，设置属性：set hive.exec.parallel=true； 9. hive提供的严格模式，禁止3种情况下的查询模式： a：当表为分区表时，where字句后没有分区字段和限制时，不允许执行； b：当使用order by语句时，必须使用limit字段，因为order by 只会产生一个reduce任务。 c：限制笛卡尔积的查询； 10. 合理的设置map和reduce数量； 11. jvm重用。可在hadoop的mapred-site.xml中设置jvm被重用的次数。 除此之外，还有很多其他的优化方式，感兴趣的可以深入学习一下，相信不断的学习和积累，必定能熟练掌握大数据知识，成为高级大数据工程师！
第一部分：Hadoop 计算框架的特性 什么是数据倾斜 由于数据的不均衡原因，导致数据分布不均匀，造成数据大量的集中到一点，造成数据热点。 Hadoop框架的特性 1)不怕数据大，怕数据倾斜 2)jobs数比较多的作业运行效率相对比较低，比如即使有几百行的表，如果多次关联多次 汇总，产生十几个jobs，耗时很长。原因是map reduce作业初始化的时间是比较长的3)sum,count,max,min等UDAF，不怕数据倾斜问题,hadoop在map端的汇总合并优化，使 数据倾斜不成问题 4)count(distinct ),在数据量大的情况下，效率较低，因为count(distinct)是按group by 字段 分组，按distinct字段排序，一般这种分布方式是很倾斜的。 第二部分：优化的常用手段 优化的常用手段 1)解决数据倾斜问题 2)减少job数 3)设置合理的map reduce的task数，能有效提升性能。 4)了解数据分布，自己动手解决数据倾斜问题是个不错的选择 5)数据量较大的情况下，慎用count(distinct)。 6)对小文件进行合并，是行至有效的提高调度效率的方法。 7)优化时把握整体，单个作业最优不如整体最优。 第三部分：Hive的数据类型方面的优化 优化原则 按照一定规则分区（例如根据日期）。通过分区，查询的时候指定分区，会大大减少在无用数据上的扫描, 同时也非常方便数据清理。 合理的设置Buckets。在一些大数据join的情况下，map join有时候会内存不够。如果使用Bucket Map Join的话，可以只把其中的一个bucket放到内存中，内存中原来放不下的内存表就变得可以放下。这需要使用buckets的键进行join的条件连结，并且需要如下设置set hive.optimize.bucketmapjoin = true
Hive的作用与特征 1.Hadoop家族产品 Apache Hadoop：是Apache开源组织的一个分布式计算开源框架，提供了一个分布式文件系统子项目(HDFS)和支持MapReduce分布式计算的软件架构。 截止到2013年，根据统计，Hadoop家族产品已经达到20个。 2.Hive的定义 Apache Hive：是基于Hadoop的一个数据仓库工具，它提供了一系列的工具，可以将结构化的数据文件映射为一张数据库表，可以用来进行数据提取转化加载（ETL），这是一种可以存储、查询和分析存储在Hadoop 中的大规模数据的机制。 Hive 定义了简单的类SQL 查询语言，称为HQL，它允许熟悉SQL 的用户查询数据。通过类SQL语句快速实现简单的MapReduce统计，不必开发专门的MapReduce应用，十分适合数据仓库的统计分析。同时，这个语言也允许熟悉MapReduce 开发者的开发自定义的mapper 和reducer 来处理内建的mapper 和reducer 无法完成的复杂的分析工作。 Hive最大的特点就是提供了类SQL的语法，封装了底层的MapReduce过程，让有SQL基础的业务人员，也可以直接利用Hadoop进行大数据的操作，就是这一特点，解决了原数据分析人员对于大数据分析的瓶颈。 3.设计特征 Hive 是一种底层封装了Hadoop 的数据仓库处理工具，使用类SQL 的HiveQL 语言实现数据查询，所有Hive 的数据都存储在Hadoop 兼容的文件系统（例如，Amazon S3、HDFS）中。Hive 在加载数据过程中不会对数据进行
任何的修改，只是将数据移动到HDFS 中Hive 设定的目录下，因此，Hive 不支持对数据的改写和添加，所有的数据都是在加载的时候确定的。Hive 的设计特点如下。 ● 支持索引，加快数据查询。 ● 不同的存储类型，例如，纯文本文件、HBase 中的文件。 ● 将元数据保存在关系数据库中，大大减少了在查询过程中执行语义检查的时间。 ● 可以直接使用存储在Hadoop 文件系统中的数据。 ● 内置大量用户函数UDF 来操作时间、字符串和其他的数据挖掘工具，支持用户扩展UDF 函数来完成内置函数无法实现的操作。 ● 类SQL 的查询方式，将SQL 查询转换为MapReduce 的job 在Hadoop 集群上执行。 4.Hive的体系结构 主要分为以下几个部分： 用户接口 用户接口主要有三个：CLI，Client 和WUI。其中最常用的是CLI，Cli 启动的时候，会同时启动一个Hive 副本。Client 是Hive 的客户端，用户连接至Hive Server。在启动Client 模式的时候，需要指出Hive Server 所在节点，并且在该节点启动Hive Server。WUI 是通过浏览器访问Hive。 元数据存储 Hive 将元数据存储在数据库中，如mysql、derby。Hive 中的元数据包括表的名字，表的列和分区及其属性，表的属性（是否为外部表等），表的数据所在目录等。 解释器、编译器、优化器、执行器 解释器、编译器、优化器完成HQL 查询语句从词法分析、语法分析、编译、优化以及查询计划的生成。生成的查询计划存储在HDFS 中，并在随后由MapReduce 调用执行。 下图列出了Hive的知识点。
一、控制hive任务中的map数: 1. 通常情况下，作业会通过input的目录产生一个或者多个map任务。 主要的决定因素有：input的文件总个数，input的文件大小，集群设置的文件块大小(目前为128M, 可在hive中通过set dfs.block.size;命令查看到，该参数不能自定义修改)； 2. 举例： 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数 即，如果文件大于块大小(128m),那么会拆分，如果小于块大小，则把该文件当成一个块。 3. 是不是map数越多越好？ 答案是否定的。如果一个任务有很多小文件（远远小于块大小128m）,则每个小文件也会被当做一个块，用一个map任务来完成， 而一个map任务启动和初始化的时间远远大于逻辑处理的时间，就会造成很大的资源浪费。 而且，同时可执行的map数是受限的。 4. 是不是保证每个map处理接近128m的文件块，就高枕无忧了？ 答案也是不一定。比如有一个127m的文件，正常会用一个map去完成，但这个文件只有一个或者两个小字段，却有几千万的记录， 如果map处理的逻辑比较复杂，用一个map任务去做，肯定也比较耗时。 针对上面的问题3和4，我们需要采取两种方式来解决：即减少map数和增加map数； 如何合并小文件，减少map数？ 假设一个SQL任务： Select count(1) from popt_tbaccountcopy_mes where pt = ‘2012-07-04’; 该任务的 inputdir /group/p_sdo_data/p_sdo_data_etl/pt/popt_tbaccountcopy_mes/pt=2012-07 -04 共有194个文件，其中很多是远远小于128m的小文件，总大小9G，正常执行会用194个map任务。
Hive常见优化 一、数据倾斜 1、什么是数据倾斜？Hadoop框架的特性决定最怕数据倾斜 ?由于数据分布不均匀，造成数据大量的集中到一点，造成数据热点。 节点间数据分布不均衡，会造成map端每个map任务的工作量不同，即map端数据倾斜。Map-reduce，把相同key提交给同一个reduce，如果key不均衡就会造成不同的reduce的工作量不同。 以京东首页活动为例，曝光率大的是大活动，曝光率小的是小活动： 假如reduce1处理的是小活动，reduce2处理大活动，reduce2干的活比其他reduce多很多，会出现其他reduce执行完毕了，reduce2还在缓慢执行。 症状：map阶段快，reduce阶段非常慢； 某些map很快，某些map很慢； 某些reduce很快，某些reduce奇慢。 如下情况： A、数据在节点上分布不均匀 B、join时on关键词中个别值量很大（如null值） C、count(distinct),在数据量大的情况下，容易数据倾斜，因为count(distinct)是按group by字段分组，按distinct字段排序。 其中A无法避免。B见后边的Join章节。C语法上有时无法避免 如何解决数据倾斜？实际上是没办法避免的，这里的解决只是个别情况起效：有数据倾斜的时候进行负载均衡 set hive.groupby.skewindata=false; 当选项设定为true，生成的查询计划会有两个MR Job。第一个MR Job中，Map 的输出结果会随机分布到Reduce中，每个Reduce做部分聚合操作，并输出结果，这样处理的结果是相同的Group By Key有可能被分发到不同的Reduce中，从而达到负载均衡的目的；第二个MR Job再根据预处理的数据结果按照Group By Key分布到Reduce中（这个过程可以保证相同的Group By Key被分布到同一个Reduce中），最后完成最终的聚合操作。
hive数据倾斜原因分析及解决方案 1.hive数据倾斜有哪些原因造成的？化过程中，遇到了数 2.数据倾斜可以修改哪些参数？ 3.有数据倾斜的时候进行负载均衡，可以通过哪个参数来设置？ 在做Shuffle阶段的优化过程中，遇到了数据倾斜的问题，造成了对一些情况下优化效果不明显。主要是因为在Job完成后的所得到的Counters是整个Job的总和，优化是基于这些Counters得出的平均值，而由于数据倾斜的原因造成map处理数据量的差异过大，使得这些平均值能代表的价值降低。Hive的执行是分阶段的，map处理数据量的差异取决于上一个stage的reduce输出，所以如何将数据均匀的分配到各个reduce中，就是解决数据倾斜的根本所在。规避错误来更好的运行比解决错误更高效。在查看了一些资料后，总结如下。 1数据倾斜的原因
2数据倾斜的解决方案 2.1参数调节： hive.map.aggr = true Map 端部分聚合，相当于Combiner hive.groupby.skewindata=true 有数据倾斜的时候进行负载均衡，当选项设定为true，生成的查询计划会有两个MR Job。第一个MR Job 中，Map 的输出结果集合会随机分布到Reduce 中，每个Reduce 做部分聚合操作，并输出结果，这样处理的结果是相同的Group By Key 有可能被分发到不同的Reduce 中，从而达到负载均衡的目的；第二个MR Job 再根据预处理的数据结果按照Group By Key 分布到Reduce 中（这个过程可以保证相同的Group By Key 被分布到同一个Reduce 中），最后完成最终的聚合操作。 2.2 SQL语句调节： 如何Join： 关于驱动表的选取，选用join key分布最均匀的表作为驱动表 做好列裁剪和filter操作，以达到两表做join的时候，数据量相对变小的效果。 大小表Join： 使用map join让小的维度表（1000条以下的记录条数）先进内存。在map端完成reduce. 大表Join大表： 把空值的key变成一个字符串加上随机数，把倾斜的数据分到不同的reduce上，由于null 值关联不上，处理后并不影响最终结果。 count distinct大量相同特殊值 count distinct时，将值为空的情况单独处理，如果是计算count distinct，可以不用处理，直接过滤，在最后结果中加1。如果还有其他计算，需要进行group by，可以先将值为空的记录单独处理，再和其他计算结果进行union。 group by维度过小： 采用sum() group by的方式来替换count(distinct)完成计算。 特殊情况特殊处理：
Hive优化 要点：优化时，把hive sql当做map reduce程序来读，会有意想不到的惊喜。 理解hadoop的核心能力，是hive优化的根本。 长期观察hadoop处理数据的过程，有几个显著的特征: 1.不怕数据多，就怕数据倾斜。 2．对jobs数比较多的作业运行效率相对比较低，比如即使有几百行的表，如果多次关联多次汇总，产生十几个jobs，没半小时是跑不完的。map reduce作业初始化的时间是比较长的。 3.对sum，count来说，不存在数据倾斜问题。 4.对count(distinct ),效率较低，数据量一多，准出问题，如果是多count(distinct )效率更低。 优化可以从几个方面着手： 1. 好的模型设计事半功倍。 2. 解决数据倾斜问题。 3. 减少job数。 4. 设置合理的map reduce的task数，能有效提升性能。(比如，10w+级别的计算，用160个reduce，那是相当的浪费，1个足够)。 5. 自己动手写sql解决数据倾斜问题是个不错的选择。set hive.groupby.skewindata=true;这是通用的算法优化，但算法优化总是漠视业务，习惯性提供通用的解决方法。 Etl开发人员更了解业务，更了解数据，所以通过业务逻辑解决倾斜的方法往往更精确，更有效。 6. 对count(distinct)采取漠视的方法，尤其数据大的时候很容易产生倾斜问题，不抱侥幸心理。自己动手，丰衣足食。
7. 对小文件进行合并，是行至有效的提高调度效率的方法，假如我们的作业设置合理的文件数，对云梯的整体调度效率也会产生积极的影响。 8. 优化时把握整体，单个作业最优不如整体最优。 优化案例： 问题1：如日志中，常会有信息丢失的问题，比如全网日志中的user_id，如果取其中的user_id和bmw_users关联，就会碰到数据倾斜的问题。 方法：解决数据倾斜问题 解决方法1. User_id为空的不参与关联，例如： Select * From log a Join bmw_users b On https://www.doczj.com/doc/0414061499.html,er_id is not null And https://www.doczj.com/doc/0414061499.html,er_id = https://www.doczj.com/doc/0414061499.html,er_id Union all Select * from log a where https://www.doczj.com/doc/0414061499.html,er_id is null. 解决方法2 ： Select * from log a
https://www.doczj.com/doc/0414061499.html,/joe_007/article/details/8987422 hive的查询注意事项以及优化总结 Hive是将符合SQL语法的字符串解析生成可以在Hadoop上执行的MapReduce的工具。使用Hive尽量按照分布式计算的一些特点来设计sql，和传统关系型数据库有区别， 所以需要去掉原有关系型数据库下开发的一些固有思维。 基本原则： 1：尽量尽早地过滤数据，减少每个阶段的数据量,对于分区表要加分区，同时只选择需要使用到的字段 select ... from A join B on A.key = B.key where https://www.doczj.com/doc/0414061499.html,erid>10 and https://www.doczj.com/doc/0414061499.html,erid<10 and A.dt='20120417' and B.dt='20120417'; 应该改写为： select .... from (select .... from A where dt='201200417' and userid>10 ) a join ( select .... from B where dt='201200417' and userid < 10
) b on a.key = b.key; 2、对历史库的计算经验(这项是说根据不同的使用目的优化使用方法) 历史库计算和使用，分区 3：尽量原子化操作，尽量避免一个SQL包含复杂逻辑 可以使用中间表来完成复杂的逻辑 4 jion操作小表要注意放在join的左边（目前TCL里面很多都小表放在join 的右边）。 否则会引起磁盘和内存的大量消耗 5：如果union all的部分个数大于2，或者每个union部分数据量大，应该拆成多个insert into 语句，实际测试过程中，执行时间能提升50% insert overwite table tablename partition (dt= ....) select ..... from ( select ... from A union all select ... from B union all select ... from C ) R where ...; 可以改写为： insert into table tablename partition (dt= ....) select .... from A WHERE ...; insert into table tablename partition (dt= ....)
深入浅出数据仓库中SQL性能优化之Hive篇 忽略元数据末尾 ? ?添加者：邓昌甫/GFZQ, 最后更新者：邓昌甫/GFZQ于九月24, 2015 回到原数据开始处 摘要：Hive查询生成多个map reduce job，一个map reduce job又有map，reduce，spill，shuffle，sort等多个阶段，所以针对hive查询的优化可以大致分为针对MR中单个步骤的优化，针对MR 全局的优化以及针对整个查询的优化。 一个Hive查询生成多个Map Reduce Job，一个Map Reduce Job又有Map，Reduce，Spill，Shuffle，Sort等多个阶段，所以针对Hive查询的优化可以大致分为针对MR中单个步骤的优化（其中又会有细分），针对MR全局的优化，和针对整个查询（多MR Job）的优化，下文会分别阐述。 在开始之前，先把MR的流程图帖出来（摘自Hadoop权威指南），方便后面对照。另外要说明的是，这个优化只是针对Hive 0.9版本，而不是后来Hortonwork发起Stinger项目之后的版本。相对应的Hadoop版本是1.x而非2.x。 Map阶段的优化(Map phase) Map阶段的优化，主要是确定合适的Map数。那么首先要了解Map数的计算公式： [js]view plaincopy 1. num_Map_tasks = max[${Mapred.min.split.size}， 2. min(${dfs.block.size}， ${Mapred.max.split.size})] ?Mapred.min.split.size指的是数据的最小分割单元大小。 ?Mapred.max.split.size指的是数据的最大分割单元大小。 ?dfs.block.size指的是HDFS设置的数据块大小。