Как переместить объекты Amazon S3 в разделенные каталоги

Question

Возьмем, например, ведро s3 со следующей структурой с файлами вида francescototti_yyyy_mm_dd_hh.csv.gz:

Например:

francescototti_2019_05_01_00.csv.gz,
francescototti_2019_05_01_01.csv.gz,
francescototti_2019_05_01_02.csv.gz,
.....
francescototti_2019_05_01_23.csv.gz,
francescototti_2019_05_02_00.csv.gz

Каждый почасовой файл составляет около 30 МБ. Я бы хотел, чтобы окончательная таблица улья была разбита по дням в виде файлов орков.

Каков наилучший способ сделать это? Я представляю несколько способов, потенциально один из следующих.

1. автоматизированный скрипт, который берет дневные файлы за день и перемещает их в соответствующую папку дня в корзине s3. Создайте секционированную внешнюю таблицу поверх этой новой структурированной корзины s3.

2. создайте внешнюю таблицу кустов поверх необработанного местоположения s3 и создайте дополнительную разделенную таблицу кустов, которая вставляется из исходной таблицы.

Каковы плюсы / минусы каждого? Любые другие рекомендации?

Answer 1

Вы можете настроить Amazon S3 Events на , чтобы автоматически запускать функцию AWS Lambda при создании объекта в корзине Amazon S3.

Эта лямбда-функция может считывать имя файла (Key) и перемещать объект в другой каталог (фактически, он будет копировать + удалять объект).

Таким образом, объекты перемещаются в нужное место сразу после их создания. Пакетные задания не требуются.

Однако это не изменит формат файлов. Содержимое можно преобразовать с помощью Amazon Athena в Преобразование в форматы столбцов . Это немного сложнее, так как вам нужно будет указать источник и пункт назначения.

Answer 2

Первый вариант: (автоматический скрипт, который берет дневные файлы за час и перемещает их в соответствующую дневную папку в корзине s3. Создайте секционированную внешнюю таблицу поверх этой новой структурированной корзины s3) выглядит лучше чем построение файлов поверх необработанного местоположения s3 , потому что необработанное расположение содержит слишком много файлов , и запрос будет работать медленно, потому что он перечислит их все, даже если вы фильтруете по виртуальному столбцу INPUT__FILE__NAME и если вы получая свежие файлы в нем, тогда это станет еще хуже.

Если файлов не слишком много, скажем, сотни в папке raw, и они не растут, я бы выбрал option2.

Возможным недостатком первого варианта является возможная проблема согласованности после удаления файлов и многократного чтения / перечисления папки. После удаления большого количества файлов (скажем, тысяч за раз) вы непременно столкнетесь с проблемой возможной согласованности (фантомные файлы) в течение следующего часа или около того. Если вы не собираетесь удалять слишком много файлов одновременно. И похоже, что нет, вы будете перемещать 24 файла за раз, тогда с очень высокой вероятностью вы не столкнетесь с возможной проблемой согласованности в s3. Другим недостатком является то, что перемещение файлов стоит. Но в любом случае это лучше, чем читать / перечислять слишком много файлов в одной папке.

Итак, первый вариант выглядит лучше.

Другие рекомендации: Перепишите вышестоящий процесс, чтобы он записывал файлы в ежедневные папки. Это лучший вариант. В этом случае вы можете построить таблицу поверх местоположения верхнего уровня s3 и каждый день добавлять только ежедневный раздел Сокращение разделов будет работать нормально, и вам не нужно перемещать файлы и нет проблем с несогласованностью в s3.