Hive架构、倾斜优化、sql及常见问题

Hive架构


hive架构如图所示,client跟driver交互,通过parser、planner、optimizer,最后转为mapreduce运行,具体步骤如下

  1. driver输入一条sql,会由parser转为抽象语法树AST,这个是没有任务元数据信息的语法树;
  2. 语法分析器再把AST转为一个一个的QueryBlock,一个QueryBlock包含输入、输出、计算逻辑,也就是说一个子程序就是QueryBlock
  3. planner遍历所有的QueryBlock,转为一个个的Operator(算子,比如tablescanOperator),最后形成OperatorTree;
  4. 优化器对OperatorTree进行优化,包含谓词下推、剪枝等;
  5. 然后遍历OperatorTree,分割成多个mapreduce作业,形成物理计划
  6. 之后进行物理优化,比如是否进行map join等

Hive 数据倾斜优化

  1. 对于group by可以有两个优化点
    map聚合:set hive.map.aggr=true,会在map端对相同key先聚合一下;
    分发为两道作业:set hive.groupby.skewindata=true,会对原来的一道作业分为两道作业,第一道随机分配key,第二道再按key分配
    注意:对于部分聚合函数有用,比如sum和count,但是完全聚合函数无用,比如avg
  2. 对于join也有两个优化点
    map join:新版hive中默认开启set hive.auto.convert.join=true ,join的左表如果足够小,会直接把左表内容加载到内存中
    两道作业:set hive.optimize.skewjoin = true;set hive.skewjoin.key = skew_key_threshold (default = 100000)这个两道作业跟groupby不一样,这个是说把超过10万行的数据单独启一道map join,最后再把结果聚合

hive常见问题

  1. hive不支持非等值join
    错误:select from a inner join b on a.id<>b.id
    替代方法:select
    from a inner join b on a.id=b.id and a.id is null;
  2. hive不支持非join连接
    错误:select from dual a,dual b where a.key = b.key;
    正确:select
    from dual a join dual b on a.key = b.key;
  3. hive不支持or
    错误:select from a inner join b on a.id=b.id or a.name=b.name
    替代方法:select
    from a inner join b on a.id=b.id union all select * from a inner join b on a.name=b.name
  4. hive内部表和外部表的区别
    创建表时:创建内部表时,会将数据移动到数据仓库指向的路径;若创建外部表,仅记录数据所在的路径, 不对数据的位置做任何改变。
    删除表时:在删除表的时候,内部表的元数据和数据会被一起删除, 而外部表只删除元数据,不删除数据。这样外部表相对来说更加安全些,数据组织也更加灵活,方便共享源数据
  5. sortby、orderby、distributeby
    order by会引发全局排序;会导致所有的数据集中在一台reducer节点上,然后进行排序,这样很可能会超过单个节点的磁盘和内存存储能力导致任务失败。
    distribute by + sort by就是该替代方案,被distribute by设定的字段为KEY,数据会被HASH分发到不同的reducer机器上,然后sort by会对同一个reducer机器上的每组数据进行局部排序。

原文地址:https://blog.51cto.com/4876017/2395861

时间: 2024-08-07 02:22:11

Hive架构、倾斜优化、sql及常见问题的相关文章

Hive架构层面优化之四 常用复杂/低效的统计从源上给出,以避免上层作业过多计算

案例一:trackinfo,基础表处理常用的低性能UDF 背景描述:日志信息10分钟加载一次到实时日志表trackreal中(按小时分区),为了保证实时性,在加载的过程中并没有做任何的过滤处理,加载到trackreal表后再过滤非法数据.爬虫数据等,生成按天增量日志表trackinfo,然后根据不同的page_type来统计流量. 解决方案如下: select '首页', count(*) pv, #每条记录就是一条pv count(distinct session_id) uv #根据sess

Hive架构层面优化之二合理利用中间结果集(单Job)

是针对单个作业,针对本job再怎么优化也不会影响到其他job: Hadoop的负载主要有两部分:CPU负载和IO负载: 问题:机器io开销很大,但是机器的cpu开销较小,另外map输出文件也较大,怎么办? 解决办法:通过设置map的中间输出进行压缩就可以了,这个不会影响最终reduce的输出. 集群中的机器一旦选定了,那么CPU就没的改变了,所以集群的最主要的负载还是IO负载: 压缩技术虽然可以降低IO负载,但是同时也加重了CPU负载,治标不治本,CPU加重了,整体性能还是上不去:如果当前CPU

Hive架构层面优化之一分表

场景:某个日志表数据量很大,而且访问该表的作业比较多,造成耗时比较长: 解决方案:将用的比较少/不常用的字段剥离出去: 案例: 日志表trackinfo,每天约有2亿数据量,有5000个作业按天访问,每天的日志数据量有可能会继续添加下去,那么很可能就满足不了要求(每添加10%的数据量作业大概要添加20分钟):如何解决数据的增长呢? 方案: 将邮件营销EDM,网盟Union从trackinfo表中剥离出来,trackinfo表大概能降到1.5亿左右,这样作业的执行时间大概可以减少40-50分钟时间

Hive架构层面优化之五合理设计表分区(静态分区和动态分区)

合理建表分区有效提高查询速度. 重要数据采用外部表存储,CREATE EXTERNAL TABLE,数据和表只是一个location的关联,drop表后数据不会丢失: 内部表也叫托管表,drop表后数据丢失:所以重要数据的表不能采用内部表的方式存储. 在全天的数据里查询某个时段的数据,性能很低效------可以通过增加小时级别的分区来改进! Trackreal为例,有三个分区: 日增量: 按日期分区: 小时增量:按日期.小时分区: 10分钟增量:按日期.小时.step分区:每个小时要导6次. 场

Hive架构层面优化之六分布式缓存

案例: Hadoop jar引用:hadoop jar -libjars aa.jar bb.jar …. jar包会被上传到hdfs,然后分发到每个datanode 假设有20个jar文件,每天jar文件被上传上万次,分发达上万次(百G级),造成很严重的IO开销. 如何使这些jar包在HDFS上进行缓存,同一个jar只需上传和分发一次,后续所有的job可以节省此jar的上传和分发的开销,从而减少不必要的上传和分发呢? 解决方案:使用分布式缓存 MapReduce如何使用分布式缓存 Hadoop

Hive架构层面优化之七压缩

常见的压缩有:对中间结果压缩.对输出结果压缩. 压缩对比: 算法 压缩前/压缩后 压缩速度 解压速度 GZIP 13.4% 21MB/s 118 MB/s LZO 20.5% 135 MB/s 410 MB/s Snappy 22.2% 172 MB/s 409 MB/s Snappy介绍: Snappy 网站:http://code.google.com/p/snappy/ Snappy的前身是Zippy.虽然只是一个数据压缩库,它却被Google用于许多内部项目程,其中就包括BigTable

Hive语法层面优化之一数据倾斜介绍

数据倾斜:数据分布不均匀,造成数据大量的集中到一点,造成数据热点: 由于数据并不是平均分配的,会导致各个节点上处理的数据量是不均衡的,所以数据倾斜是无法避免的: 造成数据倾斜的最根本原因:key分发不均匀造成的: 常见的数据倾斜的症状 1)  Map阶段快,reduce阶段非常慢: 2)  某些map很快,某些map很慢: 3)  某些reduce很快,某些reduce很慢: 4)  任务进度长时间维持在99%(或100%),查看任务监控页面,发现只有少量(1个或几个)reduce子任务未完成,

同事总结的hivesql优化Hive是将符合SQL语法的字符串解析生成可以在Hadoop上执行的M

同事总结的hive sql 优化 Hive是将符合SQL语法的字符串解析生成可以在Hadoop上执行的MapReduce的工具. 使用Hive尽量按照分布式计算的一些特点来设计sql,和传统关系型数据库有区别, 所以需要去掉原有关系型数据库下开发的一些固有思维. 基本原则: 1:尽量尽早地过滤数据,减少每个阶段的数据量,对于分区表要加分区,同时只选择需要使用到的字段 select ... from A join B on A.key = B.key where A.userid>10 and B

hive高级操作(优化,数据倾斜优化)

2019/2/21 星期四 hive高级操作(优化,数据倾斜优化) 分区表/桶表应用,skew,map-join //见hive的基本语法行列转换 hive 优化hive 优化思想Explain 的使用经典案例(distinct count) 数据倾斜的原因操作:关键词 情形 后果1.Join 其中一个表较小,但是key 集中分发到某一个或几个Reduce 上的数据远高于平均值 :2.大表与大表,但是分桶的判断字段0 值或空值过多这些空值都由一个reduce 处理,非常慢:3.group by