2034人阅读
Hive（31）
&& & & 前面学习了Hive中的数据定义语言，也学习了如何加载或者插入数据，在一些示例中或多或少的使用了SELECT语句，但还没有全面系统地学习，现在就开始学习Hive的SELECT语句。Hive的SELECT语句与传统的SQL中的SELECT还是有些区别的。具体的语法如下：
[WITH CommonTableExpression(, CommonTableExpression)*]
SELECT [ALL | DISTINCT]select_expr, select_expr, ...
FROM table_reference
[WHERE where_condition]
[GROUP BYcol_list]
[HAVING where_condition]
[ORDER BYcol_list]
[CLUSTER BYcol_list
| [DISTRIBUTE BY col_list] [SORT BY col_list]
[LIMIT number]
&& & &SELECT语句可以作为union查询的一个部分或者另一个查询的子查询，table_reference既可以是表、视图，也可以是联合查询或者子查询。ALL和DISTINCT指定是否返回重复行，在不指定任何关键字的情况下，默认值为ALL，DISTINCT指定删除结果集中的重复记录。HAVING必须出现在GROUP BY之后。下面具体看看SELECT语句的各个部分。
Common Table Expression(CTE)
&& & &Common Table Expression (CTE)是由WITH子句指定的简单查询得到的临时结果集，CTE仅在一条语句的执行范围内定义。在Hive的SELECT,&INSERT,&CREATE TABLE AS SELECT, 或者CREATE VIEW AS SELECT语句中可以使用一个或者多个CTE，但在子查询中不支持WITH子句。CTE的语法如下：
withClause:cteClause (, cteClause)*
cteClause:cte_name AS (select statment)
&& & &CTE在SELECT语句的示例如下：
with q as(select time_taken from idp where time_taken=15) select *
-- chaining CTEs
with q1 as (select key from q2 where key = '5'),
q2 as ( selectkey from src where key = '5')
select * from(select key from q1)
-- union example
with q1 as(select * from src where key= '5'),
q2 as (select *from src s2 where key = '4')
select * from q1union all select * from q2;
&& & &CTE在视图，CTAS，插入语句中的使用如下：
-- insert example
with q1 as (select key, value from src where key = '5')
insert overwritetable s1
-- ctas example
create table s2as
with q1 as (select key from src where key = '4')
select * from q1;
-- view example
create view v1as
with q1 as (select key from src where key = '5')
select * from q1;
&& & &Where从句是布尔表达式，只有满足此表达式的记录才会返回。从Hive-0.13版本开始，一些子查询可以出现在Where从句中，这些子查询的结果被作为IN和NOT IN语句中的常量，EXISTS和NOT EXISTS也是被支持的子查询，示例如下：
IN (SELECT
EXISTS (SELECT
WHERET1.X = T2.Y)
基于分区的查询
&& & &一般情况下，SELECT查询扫描整个表，但是如果使用PARTITIONED BY从句创建表，那么查询可以进行分区修剪并且只扫描查询中与指定分区相关的部分。如果在WHERE从句或者JOIN的ON从句中指定分区，Hive就会执行分区修剪。例如，表page_view在列date上分区，下面的查询仅取回在和之间的数据：
SELECT page_views.*
FROM page_views
WHERE page_views.date &= '' AND page_views.date &= ''
&& & &如果表page_view与表dim_users进行连接（join），可以在ON从句中指定分区范围，如下：
SELECT page_views.*
FROM page_views JOIN dim_users
ON(page_views.user_id = dim_users.id AND page_views.date &= '' AND page_views.date &= '')
&& & &Limit从句限制了返回记录的数量，返回的记录是被随机选取的，如果想返回头几条记录，可以先对结果排序然后再使用LIMIT从句，如下：
SELECT * FROM sales SORT BY amount DESC LIMIT 5
GROUP BY从句
&& & &当使用GROUP BY从句时，select语句只能包含那些包含在GROUP BY从句中的列，或者在select语句中使用聚类函数，如count，sum等。聚类函数或者简单查询的输出可以被存入多个表或者HDFS中，如下：
FROM pv_users
INSERT OVERWRITE TABLE pv_gender_sum
SELECT pv_users.gender, count(DISTINCTpv_users.userid)
GROUP BY pv_users.gender
INSERT OVERWRITE DIRECTORY '/user/hadoop/tmp/pv_age_sum'
SELECT pv_users.age, count(DISTINCTpv_users.userid)
GROUP BY pv_users.
&& & &hive.map.aggr参数控制着如何进行聚类操作，默认值为true，这时Hive会在Map任务中直接执行第一层级的聚类操作，这会提供更高的效率，但却要求更多的内存。
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：403884次
积分：5240
积分：5240
排名：第3673名
原创：81篇
评论：121条
文章：33篇
阅读：110660
文章：10篇
阅读：68978
文章：49篇
阅读：122131
(1)(1)(1)(1)(2)(1)(6)(9)(12)(11)(11)(8)(7)(8)(6)(12)(5)(4)(10)(7)(1)(1)当前位置：
Hive已为Hadoop带来实时查询机制
　　Apache Hive是一款以Hadoop为基础打造而成的工具，其专长在于利用类SQL语法对大规模非结构化数据集进行分析，从而帮助现有商务智能及企业分析研究人员对Hadoop内容进行访问。作为由Facebook工程师们开发、受到Apache基金会认可并贡献的开源项目，Hive目前已经在商用环境下的大数据分析领域取得了领先地位。
　　与Hadoop生态系统中的其它组成部分一样，Hive的发展速度同样非常迅猛。在今天的评测文章中，我们将以0.13为目标――该版本解决了其它前续版本中的一些缺陷。0.13版本还显着提升了类SQL查询在多个大规模Hadoop集群之间的处理速度，并针对前续版本中的交互查询机制添加了多项全新功能。 从本质上讲，Hive其实是一套事务型数据存储体系，同时也适用于规模巨大、对查询速度要求不高的相对静态数据集进行分析Hive对现有数据仓库方案作出了很好的补充，但并不属于完整的替代性机制。相反，利用Hive辅助数据仓库能够充分发挥现有投资成果的实际效能，同时又不会对数据容纳能力造成影响。 典型的数据仓库方案包含有众多昂贵的硬件与软件组件，例如RAID或者SAN存储、用于简化及插入数据的优化型ETL（即提取、转换与加载）规程、面向ERP或者其它后端系统的特定连接机制外加面向地理位置、产品或者销售渠道等企业常见销售事务所设计的规划方案。这类仓库体系通过优化为CPU带来丰富的数据内容，从而为规划方案中预设的各类运营问题找到答案。
　　相比之下，Hive数据存储机制将大量非结构化数据整合到了一起――其中包括日志文件、客户推文、电子邮件信息、地理数据以及CRM交互等――并将它们以非结构化格式保存在成本低廉的商用硬件之上。Hive允许分析师们以这些数据为基础构建类似于数据库的项目结构，引入与传统表、列以及行相仿的机制并针对其编写类SQL查询。这意味着用户完全可以根据查询特性在同一套数据集之上采用不同类型的处理规划，从而透过收集到的数据找出关键性运营问题的确切答案。
　　过去，Hive查询一直存在比较严重的延迟状况，即使是涉及数据量不大的小型查询也需要耗费相当长的一段时间――这是因为查询需要首先被转化为映射-归约作业，而后才能提交给集群并以批量方式得到执行。这种延迟一般不至于造成什么问题，因为早在查询规划与映射-归约机制起效之前、查询本身就会对整个处理周期的时耗作出预判――至少在运行Hive设计思路所指向的大规模数据集时是如此。
　　不过用户们很快发现，这类运行周期过长的查询流程在多用户环境下会造成严重的不便甚至麻烦，因为在这种状况下单一作业有可能成为整体集群的首要完成目标。 为了解决这一难题，Hive社区组织起新一轮努力（也被称为‘毒刺’项目）以改善查询处理速度，其目标是让Hive有能力适应实时、交互式查询与探索性操作的需求。这部分改进成效在Hive 0.11、0.12以及0.13三个版本中开始陆续出现。
　　最后，尽管HiveQL查询语言以SQL-92为基础，但它仍然与SQL之间存在一系列重大差别――原因很简单，前者运行在Hadoop基础之上。举例来说，DDL（即数据定义语言）命令需要考虑到表中现有多用户文件系统能够支持多种存储格式这一客观现实。不过总体而言，SQL用户在使用HiveQL语言时能够获得理想的熟悉之感，而且在适应过程中应该不会遇到任何障碍。 Hive平台架构 从上到下，Hive的平台架构看起来与任何其它关系型数据库并没有什么不同。用户编写SQL查询并将其提交至处理流程，且可以使用与数据库引擎直接交互的命令行工具或者通过JDBC或ODBC与数据库进行通信的第三方工具。Hive的具体架构如下图所示：
　　Hive平台架构示意图。
　　通过Mac及Windows系统下的JDBC以及ODBC驱动程序，数据工作人员们可以将自己喜爱的SQL客户端与Hive相对接，从而对表进行浏览、查询以及创建。对于资深用户而言，Hive也提供原始的胖客户端CLI、能够与Hive驱动程序直接交互。这套客户端最为强大且要求与Hadoop直接对接，因此特别适合处理本地网络执行事务――防火墙、DNS以及网络拓朴结构都将不是问题。
　　Hive元存储机制HCatalog原本曾经作为独立的Hadoop项目存在，如今则成为Hive发行版当中的组成部分。在其自有关系型数据库的支持之下，HCatalog能够免去在Hive当中定义规划的步骤、简化新查询同时使此类规划能够为Hadoop工具链中的其它工具――例如Pig――所用。
　　Hive上手指南
　　正如前面所提到，Hive使用的是名为HiveQL的简化版类SQL语言，其支持数据定义与操作语句。任何一位SQL用户都能在使用Hive时拥有熟悉的使用体验。HiveQL在设计思路上尽量简化了由SQL向其过渡的过程，并能够直接让数据分析机制建立并运行在Hadoop之上。
　　大多数商务智能与SQL开发者工具都能轻松与Hive对接，正如与其它任何数据库相对接一样。在ODBC连接机制的辅助下，用户可以将导入数据并利用PowerPivot for Excel等工具探索并分析数据，进而帮助企业了解到蕴藏在大数据当中的宝贵价值。
　　HiveQL与标准SQL之间也存在着多项显着区别。Hive 0.13在设计思路上需要利用YARN以及Tez架构对PB级别的数据集进行全表扫描，因此关系型数据库当中的一部分常见功能在Hive当中已经不复存在。缺乏的特性包括事务处理、光标、编报表、行级更新与删除以及对运行中的查询加以撤销等等。
　　虽然这些功能的缺失不会对数据分析产生影响，但却有可能影响到我们在Hive集群上对现有SQL查询加以使用的能力。查询命令的编写方式可能与其它支持完整SQL语言的引擎有所区别，但经验丰富的传统数据库用户应该不至于在编写Hive查询时遇到阻碍。很多传统SQL编辑环境现在已经可以通过连接机制支持Hive，而Hive表也能够利用多数SQL编辑器实现访问，其中包括甲骨文及微软推出的相关工具。
　　数据库用户在使用Hive时面临的主要差异在于对存储细节的识别层面。在传统数据库环境当中，数据库引擎控制着指向数据库的全部读取与写入操作。但在Hive方面，数据库表以文件形式被保存在Hadoop分布式文件系统（简称HDFS）当中，而其它应用程序也可以对其加以修改。不过这在某种意义上也算是好事，这意味着Hive会强制要求数据与现有规划的读取机制相匹配，也就是说Hive会针对读取操作对规划加以修改。如果底层数据格式发生变化，Hive将尽力弥合这种差异，但用户也可能因此面对意料之外的调整结果。
　　Hive用户必须了解数据存储的两大要素：文件格式与压缩机制。经过调整的Hive查询能够对数据库表中的数字、类以及文件作出优化，从而让底层映射-归约作业以更富效率的方式执行。Hive以文本作为默认存储格式，其优势在于能够更轻松地为其它工具所使用。不过作为弊端，我们很难在查询中对于原始文本文件作出优化。
　　Hive能够读取并写入多种文件格式，并在运行过程中对相关内容进行压缩。不同的文件格式可能给存储要求与查询效率带来巨大影响，大家可以通过以下图表进一步加以了解（由Hortonworks提供）。文件格式属于Hadoop社区的一大研究重点。高效的文件格式既能够降低存储成本，也可以提高查询效率。
　　HDFS上的文件格式与文件大小。（图表由Hortonworks提供）
　　大规模数据集的处理流程往往需要分为几步进行，而HiveQL当中包含多种语言结构、用于指定ETL流程。通常情况下，根据具体问题的实际要求，一项作业通常需要保存临时表，而将TB级别的数据移动至HDFS当中显然不切实际。Hive提供三种UDF（即用户定义函数），能够在查询当中被用于完成处理流程定制。由于它们作为Hive查询的组成部分运行而且能够与数据直接对接，因此其执行效率更高且能够消除流程内的中间步骤。UDF必须利用Java语言来编写，因此SQL程序员们可能会面临一些难题――不过Hive工具包的出现在一定程度上消除了此类障碍。如果没有这三种UDF，特定类型的问题将变得更难于解决。
　　Hive查询性能
　　Hive 0.13属于毒刺项目（即技术社区为改进Hive性能所构建的项目）的最后一部分，而且很明显相关努力收到了不错的成效。我在0.11到0.13版本当中对多项速度参数进行了测试，并实际感受到了版本提升给处理效率带来的改善。其中最引人注目的特性是0.13版本在全新Tez执行框架上运行查询的能力。
　　在我的测试当中，我发现在引入Tez之后、查询次数与原先相比缩减了一半，而且查询时耗在缓存机制的辅助下也降低了30%。在大规模数据集方面，其速度提升效果变得更为显着。使用在0.11版本中引入的ORC（即优化行列）文件格式时，查询次数降低了约15%。微软专为Hive 0.13打造的Vectorization则进一步将速度提高约10%。0.13版本中的另一项新功能――基于成本的查询优化机制――也能够实现20%效率改进。
　　需要指出的是，这些测试全部运行在我自己的笔记本设备上、处理对象为小型数据集、使用临时性查询，因此其结果可能无法准确反映Hive 0.13在真实使用环境下的性能水平。很明显，性能调整工具包中的每一项功能特性都具备显着的价值，其在大规模查询作业中将发挥重要的实际作用。
　　未来几年中，需要收集并加以分析的数据总量当然不可能有所减少。而企业级数据仓库业务中最常用的度量单位――每TB成本――也只会变得更加重要。虽然这种衡量指标易于计算也方便理解，但与大多数简便指标一样、它也会让买家对整体架构的复杂性缺乏足够的理解。无论如何，几乎所有从业人士都认为Hive的数据存储成本要远低于传统数据仓库方案――只相当于后者的1%甚至更低。
　　传统数据仓库方案的用户们应该认真评估利用Hadoop进行非结构化分析数据存储的可能性，并考虑能否将其引入数据仓库体系。在Hive的帮助下，我们有能力执行PB级别查询，从而定义并简化数据内容并为日后引入数据仓库分析作好准备。Hadoop与Hive也可以在逆向场景中发挥作用：将原本需要保存在数据仓库中的汇总数据分离出来，从而显着降低存储成本。最后，Hive能够对非结构化数据进行实验性分析，并在确认其实际价值后再将内容保存在数据仓库当中。
　　尚未部署数据仓库方案的企业或者技术部门也可以将Hive作为起点，从而在感受数据分析价值的同时将前期投入成本控制在最低程度。虽然Hive并不能提供一套完整的数据仓库解决方案，但它确实带来一套具备多种分析工具的优秀、低成本、大规模、可操作型数据存储机制。如果分析师们对于Hive的表现感到满意，那么众多传统数据仓库供应商也将提供相关连接机制与工具、保证用户可以将数据引入数据仓库当中以保护原有资产投入。
　　在实际运营层面，以数据与分析为基础制定出准确决策的企业将拥有显着的竞争优势。Hive在查询流程方面提供近线性可扩展能力，且拥有比传统企业级数据仓库高出一个量级的卓越性能与性价比，此外其入门门槛也比后者低得多。目前10TB级别的企业数据仓库解决方案大约需要100万美元启动费用，相比之下善于管理大规模非结构化数据集的Hive可谓潜力无限。
&&&&&&& 本文来源：51CTO 核子可乐译
　　原文链接：
　　/d/big-data/review-apache-hive-brings-real-time-queries-hadoop-246607
阅读：2519次
推荐阅读：
联系我们：
电话：400-
邮编：210014 & & & &官方微博：/njcstor & & &&微信公众号：cStor_cn
地址：南京市白下高新技术产业园中国云计算创新基地A栋9层
（在地图软件上搜“”即可）
版权所有 &
南京云创大数据科技股份有限公司(股票代码：835305)， 保留一切权利。&&
云创大数据-、大数据、云计算产品供应商MapReduce和Hive支持递归子目录作为输入 - 推酷
MapReduce和Hive支持递归子目录作为输入
关键字：MapReduce、Hive、子目录、递归、输入、Input、mapreduce.input.fileinputformat.input.dir.recursive、hive.mapred.supports.subdirectories
一般情况下，传递给MapReduce和Hive的input文件夹中不能包含子目录，否则就会报错。但后来增加了递归遍历Input目录的功能，这个貌似是从0.23开始的，具体不清楚，反正在0.20中是不支持的。
我使用的Hadoop版本为：hadoop-2.3.0-cdh5.0.0
Hive版本为：apache-hive-0.13.1-bin
具体使用示例如下：
hadoop fs -mkdir /tmp/lxw1234/
hadoop fs -mkdir /tmp/lxw1234/subdir/
hadoop fs -put 1.txt /tmp/lxw1234/
hadoop fs -put 2.txt /tmp/lxw1234/subdir/
hadoop fs -ls -R /tmp/lxw1234/
-rw-r--r-- 2 lxw1234 supergroup 6
13:56 /tmp/lxw1234/1.txt
drwxr-xr-x - lxw1234 supergroup 0
13:56 /tmp/lxw1234/subdir
-rw-r--r-- 2 lxw1234 supergroup 4
13:56 /tmp/lxw1234/subdir/2.txt
1.txt在/tmp/lxw1234/下，2.txt在/tmp/lxw1234/subdir/目录下。
默认情况下，mapreduce.input.fileinputformat.input.dir.recursive为flase.
运行wordcount：
hadoop& jar& hadoop-mapreduce-examples-2.3.0-cdh5.0.0.jar& wordcount& /tmp/lxw1234/& /tmp/output/
报错 “Error: java.io.FileNotFoundException: Path is not a file: /tmp/lxw1234/subdir”，原因是MapReduce获取/tmp/lxw1234下的列表，把/tmp/lxw1234/subdir 也作为一个input file来处理。
设置mapreduce.input.fileinputformat.input.dir.recursive=true，这个参数是客户端参数，可以在MapReduce中设置，也可以在mapred-site.xml中设置，无所谓。
再运行上面的wordcount命令：
hadoop& jar& hadoop-mapreduce-examples-2.3.0-cdh5.0.0.jar& wordcount& /tmp/lxw1234/& /tmp/output/
Job成功执行，查看结果：
hadoop fs -cat /tmp/output/*
仍然使用上面的HDFS路径/tmp/lxw1234/建表：
CREATE EXTERNAL TABLE lxw1234 (d string) stored AS textfile location '/tmp/lxw1234/';
查询：select * from lxw1234;
同样报错 “Not a file: hdfs://cdh5/tmp/lxw1234/subdir” 。
在hive-cli中设置参数：
set hive.mapred.supports.subdirectories=set mapreduce.input.fileinputformat.input.dir.recursive=
结果正确。
mapreduce.input.fileinputformat.input.dir.recursive
表示是否在MapReduce中递归遍历Input目录，
Hadoop1.0中该参数为： mapred.input.dir.recursive
Hive中设置
hive.mapred.supports.subdirectories
=true之后，即可将包含子目录的文件夹作为表或分区的数据目录，
查询的时候会递归遍历查询，但需要Hadoop的版本支持该功能才可以。
比如：hive0.13+hadoop0.20就不起作用。
已发表评论数()
请填写推刊名
描述不能大于100个字符!
权限设置： 公开
仅自己可见
正文不准确
标题不准确
排版有问题
主题不准确
没有分页内容
图片无法显示
视频无法显示
与原文不一致将很多段逻辑sql放在一个hive文件执行 停止提交的任务做法 - SQL当前位置:& &&&将很多段逻辑sql放在一个hive文件执行 停止提交的任将很多段逻辑sql放在一个hive文件执行 停止提交的任务做法&&网友分享于：&&浏览：0次将很多段逻辑sql放在一个hive文件执行 终止提交的任务做法
背景： hive工作中，将很多etl 脚本写在一起，然后整体提交，提交后突然后悔想取消
qyjssum.sh:
sudo -u hdfs hive -e "
清洗逻辑1.....
清洗逻辑2....
清洗逻辑3......
调用写法：
nohup /cloud/qyjs_sum_generate.sh & /cloud/qyjs_sum_generate.log
/cloud/qyjs_sum_generate.log
一般想杀死用：
-ef | grep qyjs_sum_generate.sh
此时会出现三个进程描述信息和ID，
第一个是 grep这条语句的进程
第二个是上面 nohup调用grep qyjs_sum_generate.sh 的进程
第三个是这个任务提交成mr任务的进程
一般直 kill -9 第二个 第三个进程即可，
但是昨天我用这种方式杀不死，现象是：
清洗逻辑1.....
清洗逻辑2....
清洗逻辑3......
杀死了这个进程后，
清洗逻辑2的进程提交上去，然后杀死清洗逻辑2的 清洗逻辑3的有提交上去，
具体原因我不知道，但是最后的做法就是：
hadoop job -list 查看产生的 hadoop job
然后用 hadoop job -kill jobid方式 出现一个杀死一个 这种方式实现完全杀死整个sh里面的任务。
12345678910
12345678910
12345678910 上一篇：没有了下一篇：文章评论相关解决方案 1234567891011 Copyright & &&版权所有