У меня есть журналы доступа S3, помещенные в корзину в недружественной структуре Hive (Glue Data Catalog). По сути, им присваивается префикс, оканчивающийся на sla sh, затем каждое имя файла начинается со строки даты, но ниже они не разделяются на «подкаталоги» (я знаю, что S3 не делает каталоги, но многие вещи любят притворяться, что это делает - например, Hive & веб-консоль S3). В итоге файлы выглядят так:
s3://logs-bucket/some-prefix/2020-01-01-00-18-09-0D4ABDAC9C0DA971
s3://logs-bucket/some-prefix/2020-02-02-00-18-32-F4326DB4C0F61E87
s3://logs-bucket/some-prefix/2020-02-02-00-27-32-75841FC1705062CA
...
, и их миллионы вот так.
Я пытаюсь выяснить, как определить таблицу Hive или схему секционирования, которая разделяет эти файлы на основе даты. Без этого мне придется сканировать весь префикс, даже если я знаю, что искомые данные находятся в файлах с именами, начинающимися с данной даты.
Я попытался определить таблицу с именем 's3_logs_2020-02 'на месте 's3://logs-bucket/some-prefix/2020-02'. Я также попробовал секционированную таблицу с корнем в префиксе и с тем же расположением для раздела «2020-02». В обоих случаях данные не найдены, потому что Hive (Glue?), По-видимому, неявно добавляет '/' в конец строки местоположения.
Таким образом, вопрос заключается в том, есть ли способ сказать Hive не неявно добавить этот конечный sla sh в местоположения S3?
РЕДАКТИРОВАТЬ: Альтернатива, на которую я смотрел, - это добавить предложение where в мои запросы, используя псевдостолбец "$ path". Это работает, чтобы уменьшить фактические возвращаемые результаты, но мне не ясно, уменьшает ли это фактические сканированные пути S3. Кто-нибудь знает, если это так?