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

Возьмите, например, корзину 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 и создать дополнительную разделенную таблицу кустов, которая вставляется из исходной таблицы.

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

Всего 2 ответа


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

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

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

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

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


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

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

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

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


Есть идеи?

10000