Как стать автором
Обновить

Комментарии 7

Я вот знаете чего не понял… а почему более простое решение не годится? Ну вот скажем, такое — хадуп же для каждого файла хранит такую штуку как Summary, а именно, число файлов и папок внутри. занятое место (в блоках и гигабайтах). И запрос этой информации — он дешевый, т.е. он не вызывает самого подсчета, все что нужно — уже подсчитано, и возвращается за константное время.

Организуем рекурсивный спуск по дереву папок, или вложенные циклы по схемам, таблицам и партициям Hive, параллелим это любым доступным нам удобным способом — и вроде бы мы должны собрать подобную статистику за приемлемое время? Ну т.е. если у вас в наличии только команда hdfs dfs -count — она может и не очень, а вот Java API HDFS вполне себе гибкий для таких задач. Я бы тупо начал бы с того, что запустил спарк шелл, да распараллелил бы это все на несколько потоков.

У меня стояла задача найти брошенные таблицы, для этого надо было считать MAX(modificationtime), MAX(accesstime) GROUP BY folder. Если делать это через API, для modificationtime придётся перебрать все папки (modification time у папок равно самому последнему для файлов непосредственно внутри них), для accesstime - все файлы (у папок access time всегда 0). Шерстить 70 млн файлов накладно

Если такой задачи не стоит, то да, отличный вариант. Гораздо лучше hdfs dfs -count

А, да, логично. У меня немного другая но похожая задача стояла, мне хватило. Но ваша идея интересная, да.

И еще мне кажется, что партиций в Hive все-таки минимум на порядок меньше, чем файлов — так что можно попробовать пробежаться по ним. У них есть даты модификации, во всяком случае у новых версий (в старом Cloudera 5.16 еще не было).

А что за сборка у вас?

HDP 2.6.5

Самосбор или вендорская?

вендорская hortonworks

Зарегистрируйтесь на Хабре , чтобы оставить комментарий