目前,Hive底层使用MapReduce作为实际计算框架,SQL的交互方式隐藏了大部分MapReduce的细节。这种细节的隐藏在带来便利性的同时,也对计算作业的调优带来了一定的难度。未经优化的SQL语句转化后的MapReduce作业,它的运行效率可能大大低于用户的预期。本文我们就来分析一个简单语句的优化过程。
https://github.com/lihuigang/hive-bitmap-udf
Failded with exception:unable to move source hdfs://…
相信使用Hive的人平时会经常用到去重统计之类的吧,但是好像平时很少关注这个去重的性能问题,但是当一个表的数据量非常大的时候,会发现一个简单的count(distinct order_no)这种语句跑的特别慢,和直接运行count(order_no)的时间差了很多,于是研究了一下。 先说结论:能使用group by代替distinc就不要使用distinct,例子:
本文参考官方介绍,原文地址如下: https://cwiki.apache.org/confluence/display/Hive/LanguageManual+Union
HQL是数据分析过程中的必备技能,随着数据量增加,这一技能越来越重要,熟练应用的同时会带来效率的问题,动辄十几亿的数据量如果处理不完善的话有可能导致一个作业运行几个小时,更严重的还有可能因占用过多资源而引发生产问题,所以HQL优化就变得非常重要,本文我们就深入HQL的原理中,探索HQL优化的方法和逻辑。
以下面的 SQL 为例,我们来介绍下其在离线中和在实时中执行的区别,对比学习一下,大家就比较清楚了
在阐述Hive Join具体的优化方法之前,首先看一下Hive Join的几个重要特点,在实际使用时也可以利用下列特点做相应优化:
Hive作为大数据平台举足轻重的框架,以其稳定性和简单易用性也成为当前构建企业级数据仓库时使用最多的框架之一。
原文地址:https://kylin.apache.org/docs16/howto/howto_optimize_build.html
1 将排序结果插入到新文件中 hive> insert overwrite table re_table1 select * from table1 cluster by id; 2 在shell中使用hive $HIVE_HOME/bin/hive -S -e "select * from table1 cluster by id" > /home/hadoop/hadoop/hadoop-1.2.1/test/re_s.txt 3 hive中操作hadoop命令 hive> dfs -ls /dat
在讲解中我们需要贯串一个例子,所以需要设计一个情景,对应还要有一个表结构和填充数据。如下:有 3 个字段,分别为 personId 标识某一个人,company 标识一家公司名称,money 标识该公司每年盈利收入(单位:万元人民币)
滴滴集团作为生活服务领域的头部企业,正在全面测试和上线StarRocks,其中橙心优选经过一年多的数据体系建设,我们逐渐将一部分需要实时交互查询、即席查询的多维数据分析需求由ClickHouse迁移到了StarRocks中,StarRocks在稳定性、实时性方面也给了我们良好的体验,接下来以StarRocks实现的漏斗分析为例介绍StarRocks在橙心优选运营数据分析应用中的实践。
在离线数据研发中,随着业务的快速发展以及业务复杂度的不断提高,数据量的不断增长,尤其得物这种业务的高速增长,必然带来数据逻辑复杂度的提升,数据量越大,复杂度越高,对任务的性能的要求就越高,因此,任务性能的优化就成了大家必然的话题,在离线数仓招聘中,这几乎成了必考题目。
Hive 支持索引,但是 Hive 的索引与关系型数据库中的索引并不相同,比如,Hive 不支持主键或者外键。 Hive 索引可以建立在表中的某些列上,以提升一些操作的效率,例如减少 MapReduce 任务中需要读取的数据块的数量。 在可以预见到分区数据非常庞大的情况下,索引常常是优于分区的。 虽然 Hive 并不像事物数据库那样针对个别的行来执行查询、更新、删除等操作。它更多的用在多任务节点的场景下,快速地全表扫描大规模数据。但是在某些场景下,建立索引还是可以提高 Hive 表指定列的查询速度。(虽然效果差强人意) 索引适用的场景 适用于不更新的静态字段。以免总是重建索引数据。每次建立、更新数据后,都要重建索引以构建索引表。 Hive 索引的机制如下: hive 在指定列上建立索引,会产生一张索引表(Hive 的一张物理表),里面的字段包括,索引列的值、该值对应的 HDFS 文件路径、该值在文件中的偏移量; v0.8 后引入 bitmap 索引处理器,这个处理器适用于排重后,值较少的列(例如, 某字段的取值只可能是几个枚举值) 因为索引是用空间换时间,索引列的取值过多会导致建立 bitmap 索引表过大。但是,很少遇到 hive 用索引的。说明还是有缺陷 or 不合适的地方的。
某些 SELECT 查询可以转换为一个 FETCH 任务,从而最大限度地可以减少交互的延迟。在目前情况下,查询只能是单一数据源,不能有任何的子查询,不能有任何的聚合,去重(导致RS - ReduceSinkOperator,会产生 MapReduce 任务),Lateral views 以及 Join。Fetch 任务是 Hive 中执行效率比较高的任务之一。直接遍历文件并输出结果,而不是启动 MapReduce 作业进行查询。对于简单的查询,如带有 LIMIT 语句的 SELECT * 查询,这会非常快(单位数秒级)。在这种情况下,Hive 可以通过执行 HDFS 操作来返回结果。
Hadoop离线数据分析平台实战——410事件分析 项目进度 模块名称 完成情况 用户基本信息分析(MR)� 完成 浏览器信息分析(MR) 完成 地域信息分析(MR) 完成 外链信息分析(MR) 完成 用户浏览深度分析(Hive) 完成 订单分析(Hive) 未完成 事件分析(Hive) 未完成 模块介绍 事件分析我们主要只是分析事件的触发次数, 通过查看事件的触发次数我们可以得到事件转换率或者用户会此类事件的兴趣所在之处以及不喜之处。 计算规则 计算event
Hadoop离线数据分析平台实战——400用户浏览深度分析 项目进度 模块名称 完成情况 用户基本信息分析(MR)� 完成 浏览器信息分析(MR) 完成 地域信息分析(MR) 完成 外链信息分析(MR) 完成 用户浏览深度分析(Hive) 未完成 订单分析(Hive) 未完成 事件分析(Hive) 未完成 模块介绍 用户浏览深度分析中,通过pv值来表示用户的浏览深度, 分别从两个不同的角度来展示浏览深度,分别为会话和用户。 会话是指,每个pv阶段对应的会话个数
分析用户特征和留存的关系时,使用了 dtale 这个包来手动分析,这个包可视化还挺好的,但是我面对的是很多种组合分析,手动点鼠标要累死我啊
老工在职场多年,从事过海量(PB级)数据的关系型数据库数据处理工作,后由于数据平台升级的要求,将数据迁移到Hadoop集群,做了多年的数据研发和数据产品的研发工作,从业务理解、数据模型构建、数据采集、数据清洗,到数据产品前端/服务端的研发都做过,基本涵盖了数据的生命周期。对于Hive调优,老工自有一番理解。下面将从一个过度优化的案例说起。
mysql和hive版本: mysql版本:5.6.17 hive版本:2.1.1
我是小蕉。 上一篇大家说没有干货,妈蛋回南天哪来的干货你告诉我!!!还好这几天天气还不错,干货来了。 首先祭上今天关键代码,要做的事情就是从Hive表中取得年龄数据,然后去重,统计每个年龄的人数。如果你能看到这里,我当你知道RDD,HDFS,还有scala是什么东东,不知道的看我上一篇或者上某搜索引擎去,我不管。 case class PERSON( val name:String, val age:String ); object Some{ def main(args: Arr
SQL 中的 TRIM 函数是用来移除掉一个字串中的字头或字尾。最常见的用途是移除字首或字尾的空白。
根据常理判断,简单的 select * limit 不会造成内存溢出的。因此,我们用hive原生sql查询,发现不存在这个问题。
4.groupByKey、reduceByKey、aggregateByKey、combineByKey区别
在使用SQL提数的时候,常会遇到表内有重复值的时候,比如我们想得到 uv (独立访客),就需要做去重。
0x00 前言 往往那些不起眼的功能,最能毁掉你的工作成果。 本篇分享一些和数据质量监控相关的内容。数据质量监控是一个在快速发展的业务中最容易被牺牲和忽略的功能,但是它确实至关重要的。 文章结构 数据质量监控的意义和价值就不再谈了,本文主要讨论下面三个主题: 数据质量监控要做哪些监控内容 该怎么做 数据校验 文中会涉及到数据仓库其它的一些知识点,请参考之前的文章。 0x01 什么值得你监控 我把数据质量分成三部分来理解: 监控 告警 多数据源 重点在监控,这点会展开来讲,多数据源这一块是因为在大数据场
Hadoop离线数据分析平台实战——300活跃会员分析 项目进度 模块名称 完成情况 用户基本信息分析(MR)� 未完成 浏览器信息分析(MR) 未完成 地域信息分析(MR) 未完成 外链信息分析(MR) 未完成 用户浏览深度分析(Hive) 未完成 订单分析(Hive) 未完成 事件分析(Hive) 未完成 模块介绍 活跃会员的统计和活跃用户统计类似, 区别只是在于从不同的角度来进行分析访问网站的用户数量。 活跃用户统计是根据我们在cookie中保存的uui
0、背景 最近两天数据仓库中一张核心表遭遇了锁的问题,导致数据插入失败,影响挺大,之前一直没注意到这个问题,借此总结一下这块的知识和遇到的坑。 hive 在 0.7 版本之后开始支持并发,线上的环境默
hive sql求差集的方法 1、什么是差集 set1 - set2,即去掉set1中存在于set2中的数据。 2、hive中计算差集的方法,基本是使用左外链接。 直接上代码 select * from table1 t1 left outer join table2 t2 on t1.id = t2.id where t2.id = null; 3、一般来说我们要先去重,使得两个表都变成集合,元素唯一。 先对table2(右表)去重然后再计算差集。 select * from ( selec
Hadoop离线数据分析平台实战——420订单分析 项目进度 模块名称 完成情况 用户基本信息分析(MR)� 完成 浏览器信息分析(MR) 完成 地域信息分析(MR) 完成 外链信息分析(MR) 完成 用户浏览深度分析(Hive) 完成 订单分析(Hive) 未完成 事件分析(Hive) 完成 模块介绍 订单分析分别分析订单的数量和订单的金额, 以及将订单分为总订单、 支付成功订单以及退款订单三种类型的数据, 通过这六个分析指标的数据我们可以指定网站的订单情
Hadoop离线数据分析平台实战——340浏览器PV分析 项目进度 模块名称 完成情况 用户基本信息分析(MR)� 完成 浏览器信息分析(MR) 未完成 地域信息分析(MR) 未完成 外链信息分析(MR) 未完成 用户浏览深度分析(Hive) 未完成 订单分析(Hive) 未完成 事件分析(Hive) 未完成 模块介绍 在浏览器信息分析模块中除了用户、会员和会话的分析外, 还有pv的分析,pv的计算可以代表网站的流量值, 也能够表示网站对用户的吸引程度,如果用
Hadoop离线数据分析平台实战——360地域信息分析 项目进度 模块名称 完成情况 用户基本信息分析(MR)� 完成 浏览器信息分析(MR) 完成 地域信息分析(MR) 未完成 外链信息分析(MR) 未完成 用户浏览深度分析(Hive) 未完成 订单分析(Hive) 未完成 事件分析(Hive) 未完成 地域信息分析规则 在地域信息分析模块中, 我们只统计活跃用户、总会话数以及跳出会话个数这三个指标的信息, 那么我看将代码写出之前的模式,一个分析指标写一个m
来自:blog.csdn.net/xienan_ds_zj/article/details/103869048
搞大数据的都知道 Spark,照例,我不会讲怎么用,也不打算讲怎么优化,而是想从 Spark 的核心数据结构的演进,来看看其中的一些设计和考虑,有什么是值得我们借鉴的。我想这些思想和理念才是更持久和通用的东西。
将key相对分散,并且数据量小的表放在join的左边,这样可以有效减少内存溢出错误发生的几率;再进一步,可以使用map join让小的维度表(1000条以下的记录条数)先进内存。在map端完成reduce。 实际测试发现:新版的hive已经对小表JOIN大表和大表JOIN小表进行了优化。小表放在左边和右边已经没有明显区别。
上文提到了使用画像宽表可以便捷的创建人群,本文介绍人群创建所依赖的另外一种数据组织形式:标签BitMap。
我们知道ChatGPT通过谷歌面试,年薪突破18.3万美元。阿里面试你觉得会怎么样?
Map在读取数据时,先将数据拆分成若干数据,并读取到Map方法中被处理。数据在输出的时候,被分成若干分区并写入内存缓存(buffer)中,内存缓存被数据填充到一定程度会溢出到磁盘并排序,当Map执行完后会将一个机器上输出的临时文件进行归并存入到HDFS中。
Presto设计精巧,可以处理海量数据,最大化地利用硬件性能,计算全部在内存中完成,很好的利用高速网络来进行数据调度。性能基本上是Hive的10倍。
本文通过介绍数据倾斜以及数据倾斜解决方法,总结归纳了Hive、Spark、HBase等大数据处理框架在实际应用中出现的各种数据倾斜问题及其解决方法,为大数据处理框架的优化提供了方向。
点击关注公众号,Java干货及时送达 在使用SQL提数的时候,常会遇到表内有重复值的时候,比如我们想得到 uv (独立访客),就需要做去重。 在 MySQL 中通常是使用 distinct 或 group by子句,但在支持窗口函数的 sql(如Hive SQL、Oracle等等) 中还可以使用 row_number 窗口函数进行去重。 举个栗子,现有这样一张表 task: 备注: task_id: 任务id; order_id: 订单id; start_time: 开始时间 注意:一个任务对应多条订单
数据量大尽量避免使用 count(distinct) ,这会导致所有数据在一个 reduce 内去重,导致运行缓慢,使用 group by 来代替
0x00 前言 往往那些不起眼的功能,最能毁掉你的工作成果。 本篇分享一些和数据质量监控相关的内容。数据质量监控是一个在快速发展的业务中最容易被牺牲和忽略的功能,但是它确实至关重要的。 假设你做了100个业务,一旦有其中一个业务在某个时间段出现了数据异常,这个异常还是由业务方发现的而不是你,根据我的经验是,它带来的负面影响会超过你之前做的100个业务带来的正面影响。 文章结构 数据质量监控的意义和价值就不再谈了,本文主要讨论下面两个主题: 数据质量监控要做哪些监控内容 该怎么做 文中会涉及到数据仓库其它的一
Hadoop离线数据分析平台实战——290活跃用户分析 项目进度 模块名称 完成情况 用户基本信息分析(MR)� 未完成 浏览器信息分析(MR) 未完成 地域信息分析(MR) 未完成 外链信息分析(MR) 未完成 用户浏览深度分析(Hive) 未完成 订单分析(Hive) 未完成 事件分析(Hive) 未完成 模块介绍 和分析新增用户一样,活跃用户也需要在用户基本信息分析模块和浏览器分析模块中展示,因此也可以将其写成一个mapreduce任务。 计算规则 acti
守护撤回了一条消息 【潜水】 A 2019/1/15 8:50:46 之前的做法是先卸数到数据文件,如果调度出问题,第二天还可以从数据文件再重新把数据加载上去,还有什么其他的方法吗 【话唠】B 2019/1/15 8:53:04 增量数据,还是全量 【话唠】B 2019/1/15 8:54:27 源库数据归档备份几天呢,这方法可行? 【潜水】A 2019/1/15 9:08:21 有的增量有的全量,考虑在不动源库的情况下,源库可能已经有备份机制,在仓库也考虑一下这个情况的处理~ 【活跃】C 2019/1/15 9:26:16 ETL不应该都支持重跑历史么? 前一天挂了,第二天重跑一下就好了,只要调度工具支持重跑,ETL的代码也要写成支持重跑的。 【冒泡】D 2019/1/15 9:51:28 Indeed 贴源缓冲+作业重跑机制,一般是调度要支持N次自动失败重跑。 【话唠】B 2019/1/15 9:54:37 @C 它这是从源库抽取到ods,正常业务系统源库不保存历史,只保留最新的,如果是ods到dwd,在仓库里,当然可以重跑。 【话唠】B 2019/1/15 9:56:31 n次自动失败重跑,作业预警,发短信,邮件? 【潜水】A 2019/1/15 10:04:03 @ 是的,只能支持库内重跑,源库只有最新 【潜水】A 2019/1/15 10:05:36 @ @ 现在确实没有失败自动重跑的机制,考虑加一下,请问下你们做etl一般会做卸数到数据文件,备份数据文件的操作吗 【潜水】A 2019/1/15 10:08:05 其实可以直接不用卸数可以直接从源库加载带仓库,但是考虑一个异常情况和数据的备份,为了更安全,加上卸数到数据文件的操作,一般有没有必要呢想了解一下 【冒泡】E 2019/1/15 10:11:48 @A 一般都是要卸载为文件,源库是不断变化的,你的度量会丢失 【群主】北京-胖子哥(1106110976) 2019/1/15 10:12:21 这个里面就可以看到ODS的价值了。 ODS存储短周期,贴源数据 【话唠】B 2019/1/15 10:20:15 @A 你们的源业务系统库,都是啥数据库啊,mysql还是oracle或者其它mongodb,redis,hbase啥的 【冒泡】K 2019/1/15 10:23:30 混杂,Ora、GP、TD都有 【活跃】G 2019/1/15 10:24:32 你讲的是源库到ods当天任务没成功,第二天跑就丢掉了历史变更? 【冒泡】K 2019/1/15 10:27:23 对 【潜水】A 2019/1/15 10:28:02 源是oracle @ 对,第二天源业务库数据就变了,已经无法从源库取到前一天的数据了 【活跃】C 2019/1/15 10:42:11 你举个场景,看看大家有什么想法,我们很多时候中间状态可以不要 【潜水】A 10:55:19 比如由于源库的表结构变了,没有同步修改仓库;源库有异常的数据加载到仓库出错了;或者源库数据量太大数据加载时候出错了。就是一些比较异常的情况,可能有的也不会发生,就是怕一旦发生什么想象不到的情况,导致某些表的数据没有加载过来,还没有在当天及时处理。 【话唠】B 10:58:53 你们数仓也是基于hive的吗 【话唠】B 11:00:55 我们这边权限控制严格,普通用户没有删表,删字段权限。如果源库做变更了增加字段了,必须发邮件,看看上下游是否有影响,再做同步变更。 【话唠】B 11:02:42 etl报错是难免的,及时的预警,处理,因为各种问题,可以维护个问题集,后边的人报错了,也可以查看。 【潜水】J 11:04:05 源系统变更一般都会做影响分析的吧 【潜水】A 11:18:22 对 是基于hive的 源库的变化都会做影响分析 主要是考虑一些预想外的情况或者疏漏之类的 【潜水】A 11:23:10 非常感谢上面几位的分享建议,我都参考一下想一想
领取专属 10元无门槛券
手把手带您无忧上云