使用Hive,S3,EMR和Recover Partitions加载数据

Question

已解决:请参阅下面的更新#2以了解此问题的"解决方案".

~~~~~~~

在s3中,我有一些log*.gz文件存储在嵌套目录结构中,如:

s3://($BUCKET)/y=2012/m=11/d=09/H=10/

我正在尝试使用多级分区规范将这些加载到Hlastic on Elastic Map Reduce(EMR)上,例如:

create external table logs (content string)
partitioned by (y string, m string, d string, h string)
location 's3://($BUCKET)';

创建表工作.然后我尝试恢复所有现有分区:

alter table logs recover partitions;

这似乎工作,它确实钻取我的s3结构并添加所有不同级别的目录:

hive> show partitions logs;
OK
y=2012/m=11/d=06/h=08
y=2012/m=11/d=06/h=09
y=2012/m=11/d=06/h=10
y=2012/m=11/d=06/h=11
y=2012/m=11/d=06/h=12
y=2012/m=11/d=06/h=13
y=2012/m=11/d=06/h=14
y=2012/m=11/d=06/h=15
y=2012/m=11/d=06/h=16
...

因此,Hive似乎可以成功查看和解释我的文件布局.但是,没有实际数据被加载.如果我尝试做一个简单的计数或选择*,我什么都得不到:

hive> select count(*) from logs;
...
OK
0

hive> select * from logs limit 10;
OK

hive> select * from logs where y = '2012' and m = '11' and d = '06' and h='16' limit 10;
OK

思考？我是否缺少一些额外的命令来加载数据而不是恢复分区？

如果我手动添加具有显式位置的分区,那么它的工作原理如下:

alter table logs2 add partition (y='2012', m='11', d='09', h='10') location 's3://($BUCKET)/y=2012/m=11/d=09/H=10/'

我可以写一个脚本来做这个,但感觉我错过了一些基本的'恢复分区'.

更新#1

感谢Joe K在下面的评论中的精彩和敏锐的观察,我认为这里可能涉及区分大小写问题.

这些文件肯定是按照以下路径规范组织的,带有大写的H(我想这可能是对iso8601格式的一些点头):

s3://($BUCKET)/y=2012/m=11/d=09/H=10/

我使用分区规范创建我的外部表,该规范执行正确的大小写:

partitioned by (y string, m string, d string, H string)

(注意'H').我做了一个恢复分区,它似乎通过目录递归并适当地找到分区,但不知何故(尽管到目前为止在所有指导性地方都使用'H'),Hive似乎确实将它保存为小写'h' :

hive> show partitions logs;
OK
y=2012/m=11/d=06/h=08

(注意'h').所以看起来Hive能够发现分区,然后以小写形式存储它们......后来当它去查找数据时,这些路径(当然)是空的,因为S3区分大小写.

我将把我的数据移动到一个全小写的目录结构,看看是否有效......

更新#2

实际上,我已经确认大写的'H'作为分区名称(在s3文件布局中)是这里的问题.据我所知,这就是发生的事情:

• 我在S3上的布局有一个区分大小写的分区名称(H =)
• 正确运行RECOVER PARTITIONS会发现这些分区......
• 但是它们在内部存储为小写(h)

'recover partitions'命令是Amazon创建的Hive的扩展.我强烈怀疑这个bug是在这个组件中.据我所知,本地Hive没有探索分区发现的文件根的概念......

Answer 1

这是小时场的一个案例问题!