hive 的分隔符、orderby sort by distribute by的优化 / 憋错料

一、Hive 分号字符

分号是SQL语句结束标记，在HiveQL中也是，但是在HiveQL中，对分号的识别没有那么智慧，例如：

select concat(cookie_id,concat(‘;‘,’zoo’)) fromc02_clickstat_fatdt1 limit 2;

FAILED: Parse Error: line 0:-1 cannot recognize input‘<EOF>‘ in function specification

可以推断，Hive解析语句的时候，只要遇到分号就认为语句结束，而无论是否用引号包含起来。

解决的办法是，使用分号的八进制的ASCII码进行转义，那么上述语句应写成：

select concat(cookie_id,concat(‘\073‘,‘zoo‘)) fromc02_clickstat_fatdt1 limit 2;

为什么是八进制ASCII码？

我尝试用十六进制的ASCII码，但Hive会将其视为字符串处理并未转义，好像仅支持八进制，原因不详。这个规则也适用于其他非SELECT语句，如CREATE TABLE中需要定义分隔符，那么对不可见字符做分隔符就需要用八进制的ASCII码来转义。

二、insert 新增数据

根据语法Insert必须加“OVERWRITE”关键字，也就是说每一次插入都是一次重写。那如何实现表中新增数据呢？

假设Hive中有表manbu,

hive> DESCRIBE manbu;

id int

value int

hive> SELECT * FROM manbu;

3 4

1 2

2 3

现增加一条记录:

hive> INSERT OVERWRITE TABLE manbu

SELECT id, value FROM (

SELECT id, value FROM manbu

UNION ALL

SELECT 4 AS id, 5 AS value FROM manbu limit 1

) u;

结果是:

hive>SELECT * FROM p1;

3 4

4 5

2 3

1 2

其中的关键在于, 关键字UNION ALL的应用, 即将原有数据集和新增数据集进行结合, 然后重写表.

三、初始值

INSERT OVERWRITE TABLE在插入数据时, 后面的字段的初始值应注意与表定义中的一致性. 例如, 当为一个STRING类型字段初始为NULL时:

NULL AS field_name // 这可能会被提示定义类型为STRING, 但这里是void

CAST(NULL AS STRING) AS field_name // 这样是正确的

又如, 为一个BIGINT类型的字段初始为0时:

CAST(0 AS BIGINT) AS field_name

四、orderby sort by distribute by的优化

Hive的排序关键字是SORT BY，它有意区别于传统数据库的ORDER BY也是为了强调两者的区别–SORT BY只能在单机范围内排序。

例如:

set mapred.reduce.tasks=2;(设置reduce的数量为2 )

原值:

1.selectcookie_id,page_id,id from c02_clickstat_fatdt1

where cookie_idIN(‘1.193.131.218.1288611279693.0‘,‘1.193.148.164.1288609861509.2‘)

1.193.148.164.1288609861509.2 113181412886099008861288609901078194082403 684000005

1.193.148.164.1288609861509.2 127001128860563972141288609859828580660473 684000015

1.193.148.164.1288609861509.2 113181412886099165721288609915890452725326 684000018

1.193.131.218.1288611279693.0 01c183da6e4bc50712881288611540109914561053 684000114

1.193.131.218.1288611279693.0 01c183da6e4bc22412881288611414343558274174 684000118

1.193.131.218.1288611279693.0 01c183da6e4bc50712881288611511781996667988 684000121

1.193.131.218.1288611279693.0 01c183da6e4bc22412881288611523640691739999 684000126

1.193.131.218.1288611279693.0 01c183da6e4bc50712881288611540109914561053 684000128

2. selectcookie_id,page_id,id from c02_clickstat_fatdt1 where

cookie_idIN(‘1.193.131.218.1288611279693.0‘,‘1.193.148.164.1288609861509.2‘)

SORT BYCOOKIE_ID,PAGE_ID;

SORT排序后的值

1.193.131.218.1288611279693.0 684000118 01c183da6e4bc22412881288611414343558274174 684000118

1.193.131.218.1288611279693.0 684000114 01c183da6e4bc50712881288611540109914561053 684000114

1.193.131.218.1288611279693.0 684000128 01c183da6e4bc50712881288611540109914561053 684000128

1.193.148.164.1288609861509.2 684000005 113181412886099008861288609901078194082403 684000005

1.193.148.164.1288609861509.2 684000018 113181412886099165721288609915890452725326 684000018

1.193.131.218.1288611279693.0 684000126 01c183da6e4bc22412881288611523640691739999 684000126

1.193.131.218.1288611279693.0 684000121 01c183da6e4bc50712881288611511781996667988 684000121

1.193.148.164.1288609861509.2 684000015 127001128860563972141288609859828580660473 684000015

selectcookie_id,page_id,id from c02_clickstat_fatdt1

where cookie_idIN(‘1.193.131.218.1288611279693.0‘,‘1.193.148.164.1288609861509.2‘)

ORDER BYPAGE_ID,COOKIE_ID;