㈠ Hive sql语句执行顺序
Hive 中 sql 语句的执行顺序如下：
from .. where .. join .. on .. select .. group by .. select .. having .. distinct .. order by .. limit .. union/union all
下面我们通过一个 sql 语句分析下：
上面这条 sql 语句是可以成功执行的，我们看下它在 MR 中的执行顺序：
Map 阶段 ：
Rece 阶段 ：
上面这个执行顺序到底对不对呢，我们可以通过 explain 执行计划来看下，内容过多，我们分阶段来看。
我们看到 Stage-5 是根，也就是最先执行 Stage-5，Stage-2 依赖 Stage-5，Stage-0 依赖 Stage-2。
图中标 ① 处是表扫描操作，注意先扫描的 b 表，也就是 left join 后面的表，然后进行过滤操作（图中标 ② 处），我们 sql 语句中是对 a 表进行的过滤，但是 Hive 也会自动对 b 表进行相同的过滤操作，这样可以减少关联的数据量。
先扫描 a 表（图中标 ① 处）；接下来进行过滤操作 idno > �'（图中标 ② 处）；然后进行 left join，关联的 key 是 idno（图中标 ③ 处）；执行完关联操作之后会进行输出操作，输出的是三个字段，包括 select 的两个字段加 group by 的一个字段（图中标 ④ 处）；然后进行 group by 操作，分组方式是 hash（图中标 ⑤ 处）；然后进行排序操作，按照 idno 进行正向排序（图中标 ⑥ 处）。
首先进行 group by 操作，注意此时的分组方式是 mergepartial 合并分组（图中标 ① 处）；然后进行 select 操作，此时输出的字段只有两个了，输出的行数是 30304 行（图中标 ② 处）；接下来执行 having 的过滤操作，过滤出 count_user>1 的字段，输出的行数是 10101 行（图中标 ③ 处）；然后进行 limit 限制输出的行数（图中标 ④ 处）；图中标 ⑤ 处表示是否对文件压缩，false 不压缩。
限制最终输出的行数为 10 行。
通过上面对 SQL 执行计划的分析，总结以下几点：
㈡ Hive简易教程 - 数据分析
Hive是一个HDFS上的sql执行引擎，它将sql语句转化为Hadoop上的map-rece任务来执行。由于是写sql，所以使用Hive进行数据分析的好处是没有什么额外的学习成本，但是它是批量式处理的，可能会比较慢。本文将通过几个案例来简单介绍如何使用Hive。
** 随机生成一批订单数据(order_id, price, tag, order_date) **
** 存储数据到Hive **
** 统计出近一周每天成功支付的订单总数，gmv，客单价 **
** 统计出近一周每天成功支付 及支付失败 各自的订单总数，gmv，客单价 **
count函数和if条件组合，而不是两个sql join
** 挑选出近一周gmv>1000并且订单量>2单的卖家ID及其订单 **
在使用group by之后只能select出group key以及相关的统计数字，但也可以以集合的形式select出任何其他的非group key，比如按卖家ID聚合之后又想查看在这个卖家下单的买家ID：sellect collect_set(buyer_id) from t group by seller_id。
与collect_set类似，元素可重复
explode函数可以把一个array类型的数据扁平化。比如，现在每行是一个seller_id集合，使用explode可以扁平化为每行一个seller_id。但explode不可以直接与group by一起使用，比如我想按某些条件筛选一些卖家然后在查看该店铺的买家的情况：select explode(b.buyer_ids) from (select collect_set(buyer_id) as buyer_ids from t group by seller_id) b;
当前时间
将系统时间戳转化为人可读的数据格式 如：select from_unixtime(unix_timestamp(), 'yyyy-MM-dd');
求几天前的日期
nvl函数用于处理null值，当一个字段是null时，这个字段和其它字段进行算术运算时的结果依然为null。这时可以使用这个函数为值可能为null的字段赋予一个默认值，即v2.
判断字符串'xxx'是否出现在str1中，如果str1是null或者不存在xxx返回值都是0
返回数组a1的大小
合并两个查询结果，但结果的列数需要一致！！！
㈢ 【数据分析】Excel数据分析全流程
作为数据分析师， 清晰了解数据分析的步骤是非常重要的，有助于清楚把控整个数据分析的流程。
作为想要学习数据分析的人员，了解整个数据分析的流程， 这样在面对一个数据分析问题的时候，知道如何去开展。
那么数据分析流程包含哪些环节呢？
我将一次完整的数据分析流程主要分为六个环节，包括明确 分析目的、数据获取、数据处理、数据分析、数据可视化、总结与建议 。
做任何事情都有其对应的目的，数据分析也是如此。每一次分析前，都必须要先明确做这次分析的目的是什么，只有先明确了目的，后面的分析才能围绕其展开, 常见的数据分析目标包括以下三种类型：
指标波动型 : 主要是针对某个指标下降了，上涨或者异常所做的分析， 比如DAU(日活跃用户数)降低了， 留存率降低了， 电商平台的订单数量减少了， 收入降低了，质量指标如卡顿率上涨的，分析的主要目的是挖掘指标波动的原因， 及时发现业务的问题。
评估决策型 ：主要是针对某个活动上线， 某个功能上线， 某个策略上线的效果评估以及下一步迭代方向的建议，这些建议是指导产品经理或者其他业务方决策的依据。
专题探索型 : 主要是针对业务发起的一些专题的分析， 比如增长类的专题分析， 怎么提高用户新增，活跃，留存，付费， 比如体验类的专题分析， 如何提高用户查找表情的效率， 比如方向性的探索， 微信引入视频号的功能的用户需求分析以及潜在机会分析。
明确了数据分析目的之后， 第二步就是根据我们的分析目的，提取相对应的数据，通常这一个环节是利用 hive sql 从数据仓库中提取数据。
提取的数据通常要注意提取的维度和对应的指标个数，以电商app 的付费流失严重分析案例,我们需要提取的维度和指标可以根据具体的业务流程来(如图):
首先从维度上，我们需要确定好，比如时间维度我们提取的时间跨度是多长，比如今天的数据和昨天的对比，那就是取2天的数据，如果是这周和上周那就是十四天的数据。
设备维度的值是否需要提取ios和安卓的用户进行不同的平台的对比，分析付费流失严重是否主要发生在某个平台。
年龄、性别、地域维度，就是提取用户这些维度的信息， 主要是为了在哪一个年龄层， 哪一个性别，哪一个地域流失最严重。
新老用户的维度， 主要是从新旧维度上分析流失严重是否是集中在新用户还是老用户(如图所示)
确定好了维度以后， 接下来就是指标信息， 维度+ 指标才是一个完整的数据 。
因为需要分析每一个环节的流失情况，所以需要提取下单的每一个环节对应的指标的人数和次数。
基于这些人数和次数，我们可以计算每一个环节之间的转化率。
活跃浏览比 = 浏览的人数/活跃的人数
浏览添加比 = 添加的人数/浏览的人数
添加下单比 = 点击下单人数/添加购物车人数
成功下单率 = 成功下单的人数/点击下单的人数
当我们知道我们应该从哪里获取数据， 以及获取哪些指标数据后，为了保证我们提取的数据的质量，我们通常要对数据进行处理。
常见的数据处理有异常值处理，空值处理。举个例子， 比如我们在提取用户的年龄数据之前，我们需要去除掉年龄中的空的数据以及异常的数据， 异常的数据指得是比如年龄超过120岁这种。
数据处理好了之后，就可以开始分析，根据我们的分析目标，我们要选择合适的分析方法和分析思路去做拆解和挖掘。
常见的分析方法包括：漏斗分析， 相关性分析， 5w2h 分析， aha 时刻分析， 麦肯锡逻辑树分析法，用户画像分析，RFM用户分群，对比分析等方法，这些方法详细的介绍会在第三章展开， 在这里不做赘述
针对我们的订单流失的问题，典型的分析思路和方法是利用漏斗分析和用户画像分析。
漏斗分析主要是可以挖掘付费流失严重的主要流失环节是在哪里。我们发现付费流失严重主要是因为用户活跃到浏览商品的转化率从50%跌倒30%， 减少了20%，那就可以把问题定位到为什么用户浏览变少的问题上。
用户画像分析，可以帮助我们分析流失严重的用户是什么特征，比如什么样的年龄， 性别， 地域等， 那就可以知道这种流失是集中在哪一个年龄群体，哪一个地域群体以及其他的行为特征。
通过数据分析得出结论后，还需要用图表展示出来，俗话说得好，“文不如表，表不如图"，用图表可以更清晰展现你的结论，通常的可视化我们可以利用excel 自带的可视化的功能， 也可以通过python或者R脚本进行可视化。
常见的图表有: 柱形图，折线图，饼图，条形图，面积图， 散点图，组合图，箱线图
当我们利用图表把我们的数据分析结论展示出来以后，最后就是数据分析的总结的部分，主要分成我们得出了什么具体的结论以及给业务具体的建议，告诉他们改进的方向。
这就是一次完整的数据分析的流程，从分析目的到提取数据，到分析数据给出结论的完整的过程。
㈣ hive什么进行sql处理
是指在（getdate()-7）的那天注册并登录的用户数sumUser和在getdate()里有登录的用户数userNum（getdate()-7注册并登陆的），这两个数的比例？
select cast(case when sumUser=0 then 0 else userNum/sumUser*100 end as varchar(2))+'%' as 留存率 from
(select
count(nowlogin.openid) as userNum,
count(newlogin.openid)as sumUser
from
(select aa.openid,aa.ftime from t_login_all as aa right join t_login_new as bb on aa.openid=bb.openid and bb.ftime=getdate()-7) as nowlogin,
(select openid from t_login_new where ftime=getdate()-7) as newlogin
where nowlogin.ftime=getdate() and nowlogin.openid=newlogin.openid
) as a
㈤ 大数据开发工程师Hive(Hive Sql的执行顺序)
Hive中SQL的执行顺序：
（1） from ：对from左边的表和右边的表计算笛卡尔积，产生虚表VT1；
（2） on : 对虚表VT1进行on过滤，只有那些符合 的行才会被记录在虚表VT2中；
（3） join ：如果指定了outer join（比如left join、 right join），那么保留表中未匹配的行就会作为外部行添加到虚拟表VT2中，产生虚拟表VT3；
（4） where ：对虚拟表VT3进行where条件过滤。只有符合 的记录才会被插入到虚拟表VT4中；
（5） group by ：根据group by子句中的列，对VT4中的记录进行分组操作，产生VT5；
（6） having ： 对虚拟表VT5应用having过滤，只有符合 的记录才会被 插入到虚拟表VT6中；
（7） select ：执行select操作，选择指定的列，插入到虚拟表VT7中；
（8） distinct ：对VT7中的记录进行去重。产生虚拟表VT8；
（9） order ：将虚拟表VT8中的记录按照 进行排序操作，产生虚拟表VT9；
（10） limit ：取出指定行的记录，产生虚拟表VT10, 并将结果返回；
partition by 通常会用于和开窗及分析函数一起使用，partition by是在select执行完 后 的结果集上进行的；
(每日1小题，进步1点点)
㈥ 数据分析课程笔记 - 19 - HiveSQL 常用优化技巧
大家好呀，这节课学习 HiveSQL 的常用优化技巧。由于 Hive 主要用来处理非常大的数据，运行过程由于通常要经过 MapRece 的过程，因此不像 MySQL 一样很快出结果。而使用不同方法写出来的 HiveSQL 语句执行效率也是不一样的，因此为了减少等待的时间，提高服务器的运行效率，我们需要在 HiveSQL 的语句上进行一些优化。
本节课的主要内容 ：
引言
1、技巧一：列裁剪和分区裁剪
（1）列裁剪
（2）分区裁剪
2、技巧二：排序技巧——sort by代替order by
3、技巧三：去重技巧——用group by来替换distinct
4、技巧四：聚合技巧——grouping sets、cube、rollup
（1）grouping sets
（2）cube
（3）rollup
5、技巧五：换个思路解题
6、技巧六：union all时可以开启并发执行
7、技巧七：表连接优化
8、技巧八：遵循严格模式
Hive 作为大数据领域常用的数据仓库组件，在平时设计和查询时要特别注意效率。影响Hive效率的几乎从不是数据量过大，而是数据倾斜、数据冗余、job 或 I/O 过多、MapRece 分配不合理等等。对 Hive 的调优既包含对HiveSQL 语句本身的优化，也包含 Hive 配置项和 MR 方面的调整。
列裁剪就是在查询时只读取需要的列。当列很多或者数据量很大时，如果select 所有的列或者不指定分区，导致的全表扫描和全分区扫描效率都很低。Hive中与列裁剪优化相关的配置项是 hive.optimize.cp ，默认是 true 。
分区裁剪就是在查询时只读需要的分区。Hive中与分区裁剪优化相关的则是 hive.optimize.pruner ，默认是 true 。
HiveSQL中的 order by 与其他 SQL 语言中的功能一样，就是将结果按某个字段全局排序，这会导致所有map端数据都进入一个 rece 中，在数据量大时可能会长时间计算不完。
如果使用 sort by ，那么就会视情况启动多个 recer 进行排序，并且保证每个 recer 内局部有序。为了控制 map 端数据分配到 rece 的 key，往往还要配合 distribute by 一同使用。如果不加 distribute by 的话，map 端数据就会随机分配给 recer。
这里需要解释一下， distribute by 和 sort by 结合使用是如何相较于 order by 提升运行效率的。
假如我们要对一张很大的用户信息表按照年龄进行分组，优化前的写法是直接 order by age 。使用 distribute by 和 sort by 结合进行优化的时候， sort by 后面还是 age 这个排序字段， distribute by 后面选择一个没有重复值的均匀字段，比如 user_id 。
这样做的原因是，通常用户的年龄分布是不均匀的，比如20岁以下和50岁以上的人非常少，中间几个年龄段的人又非常多，在 Map 阶段就会造成有些任务很大，有些任务很小。那通过 distribute by 一个均匀字段，就可以让系统均匀地进行“分桶”，对每个桶进行排序，最后再组合，这样就能从整体上提升 MapRece 的效率。
取出 user_trade 表中全部支付用户：
原有写法的执行时长：
优化写法的执行时长：
考虑对之前的案例进行优化：
注意： 在极大的数据量（且很多重复值）时，可以先 group by 去重，再 count() 计数，效率高于直接 count(distinct **) 。
如果我们想知道用户的性别分布、城市分布、等级分布，你会怎么写？
通常写法：
缺点 ：要分别写三次SQL，需要执行三次，重复工作，且费时。
那该怎么优化呢？
注意 ：这个聚合结果相当于纵向地堆在一起了（Union all），分类字段用不同列来进行区分，也就是每一行数据都包含 4 列，前三列是分类字段，最后一列是聚合计算的结果。
GROUPING SETS() ：在 group by 查询中，根据不同的维度组合进行聚合，等价于将不同维度的 group by 结果集进行 union all。聚合规则在括号中进行指定。
如果我们想知道用户的性别分布以及每个性别的城市分布，你会怎么写？
那该怎么优化呢？
注意： 第二列为NULL的，就是性别的用户分布，其余有城市的均为每个性别的城市分布。
cube：根据 group by 维度的所有组合进行聚合
注意 ：跑完数据后，整理很关键！！！
rollup：以最左侧的维度为主，进行层级聚合，是cube的子集。
如果我想同时计算出，每个月的支付金额，以及每年的总支付金额，该怎么办？
那应该如何优化呢？
条条大路通罗马，写SQL亦是如此，能达到同样效果的SQL有很多种，要学会思路转换，灵活应用。
来看一个我们之前做过的案例：
有没有别的写法呢？
Hive 中互相没有依赖关系的 job 间是可以并行执行的，最典型的就是
多个子查询union all。在集群资源相对充足的情况下，可以开启并
行执行。参数设置： set hive.exec.parallel=true;
时间对比：
所谓严格模式，就是强制不允许用户执行3种有风险的 HiveSQL 语句，一旦执行会直接报错。
要开启严格模式，需要将参数 hive.mapred.mode 设为 strict 。
好啦，这节课的内容就是这些。以上优化技巧需要大家在平时的练习和使用中有意识地去注意自己的语句，不断改进，就能掌握最优的写法。
㈦ 如何查看hive的sql解析过程
hivesql sql — 获取指定hive表或指定文件中所有hive表的DDL，如果有按天的分区则默认执行最近7天的分区DDL。同时，table支持符合sql语法的正则表达式，如果有多个表匹配，则提示用户选择(使用file则自动关闭该交互功能)。
㈧ Hive Sql优化集(on where过滤)
分析：这三个sql区别就在于log表和a表的过滤条件是在where字句上还是on字句上。
sql1的结果：
a表和log表的所有数据做连接，只是在a表的dt!=-09-17'记录上a表上所有字段都为空
sql2的结果：
a表和log表的所有数据先做连接，然后过滤出两个表只在-09-17'分区上的数据
sql3的结果：
a表和log表分别查询出-09-17'分区上数据，两个小数据集做关联，结果和sql2的相同
sql3的执行效率最高，推荐使用；sql2的效率较低，因为需要全表关联；sql1有bug，不建议直接在on中使用过滤条件
但是注意不要将where过滤条件放到on中，除非你很了解SQL执行后的结果；另外不要将on连接条件放到where中，hive并不会像mysq那样做连接优化，这样会导致不可控的情况
㈨ Hive SQL执行计划深度解析
Hive SQL执行计划深度解析 - An342647823的专栏 - 博客频道 - CSDN.NET
http://blog.csdn.net/an342647823/article/details/36385479
美团网技术陈纯大作，值得拥有。
Hive是基于Hadoop的一个数据仓库系统，在各大公司都有广泛的应用。美团数据仓库也是基于Hive搭建，每天执行近万次的Hive ETL计算流程，负责每天数百GB的数据存储和分析。Hive的稳定性和性能对我们的数据分析非常关键。
在几次升级Hive的过程中，我们遇到了一些大大小小的问题。通过向社区的咨询和自己的努力，在解决这些问题的同时我们对Hive将SQL编译为MapRece的过程有了比较深入的理解。对这一过程的理解不仅帮助我们解决了一些Hive的bug，也有利于我们优化Hive SQL，提升我们对Hive的掌控力，同时有能力去定制一些需要的功能。
㈩ hive sql 优化的常用手段有哪些
1、join连接时的优化：当三个或多个以上的表进行join操作时，如果每个on使用相同的字段连接时只会产生一个maprece。
2、join连接时的优化：当多个表进行查询时，从左到右表的大小顺序应该是从小到大。原因：hive在对每行记录操作时会把其他表先缓存起来，直到扫描最后的表进行计算
3、在where字句中增加分区过滤器。
4、当可以使用left semi join 语法时不要使用inner join，前者效率更高。原因：对于左表中指定的一条记录，一旦在右表中找到立即停止扫描。