使用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

這是小時場的一個案例問題！