Допустим, вы хотите обрабатывать 4-месячные данные с помощью запросов CTAS, но вам нужно разделить их по дням. Если вы сделаете это в одном запросе CTAS, вы получите примерно 4 x 30 = 120 разделов, таким образом, запрос не будет выполнен, как вы упомянули, из-за ограничений AWS .
Вместо этого выможет обрабатывать ваши данные за каждый месяц за раз, так что вам гарантированно будет иметь менее 31 раздела за раз. Однако результат каждого запроса CTAS должен иметь уникальное внешнее расположение на S3, т. Е. Если вы хотите сохранить результаты нескольких запросов CTAS в s3://bukcet-name/data-root, вам потребуется расширить этот путь для каждого запроса в external_location в WITH. пункт. Очевидным выбором для вашего случая будет полная дата, например:
s3://bukcet-name/data-root
├──2019-01 <-- external_location='s3://bukcet-name/data-root/2019-01'
| └── month=01
| ├── day=01
| | ...
| └── day=31
├──2019-02 <-- external_location='s3://bukcet-name/data-root/2019-02'
| └── month=02
| ├── day=01
| | ...
| └── day=28
...
Однако теперь вы получили 4 разных таблицы. Так что вам нужно либо запросить разные таблицы, либо выполнить некоторую постобработку. По сути, у вас есть две опции:
Переместить все новые файлы в общее место с помощью высокоуровневых команд AWS CLI , за которыми следует MSCK REPAIR TABLE, так как выходная структура «каталогов» соответствует соглашению об именовании разделов HIVE. Например, из
s3://bukcet-name/data-staging-area
├──2019-01 <-- external_location='s3://bukcet-name/data-staging-area/2019-01'
| └── month=01
| ├── day=01
| | ...
вы бы скопировали в
s3://bukcet-name/data-root
├── month=01
| ├── day=01
| | ...
| └── day=31
├── month=02
| ├── day=01
| | ...
| └── day=28
Манипулировать с помощью каталога данных клея AWS. Это немного сложнее, но основная идея заключается в том, что вы определяете корневую таблицу , местоположение которой указывает на s3://bukcet-name/data-root. Затем после выполнения запроса CTAS вам потребуется скопировать метаинформацию о разделах из созданной промежуточной таблицы в корневую таблицу. Этот шаг будет основан на AWS Glue API через, например, библиотеку boto3 для Python. В частности, вы будете использовать методы get_partitions() и batch_create_partition().
Независимо от того, какой подход вы выберете, вам нужно будет использовать какое-то программное обеспечение для планирования заданий, особенно если ваши данные не являютсяпросто исторический. Для этого я бы предложил использовать Apache Airflow . Это можно рассматривать как альтернативу комбинации функций лямбда и шаг, это совершенно бесплатно. Есть много сообщений в блоге и документации, которые могут помочь вам начать. Например:
- Средний пост : автоматизировать выполнение запросов AWS Athena и перемещение результатов по S3 с помощью воздушного потока.
- Полное руководство по установке воздушного потока, ссылка 1 и ссылка 2
Вы можете даже настроить интеграцию со Slack для отправки уведомлений, когда ваши запросы завершаются либо в состоянии успеха, либо в состоянии сбоя.
Что нужно иметь в виду:
Как правило, у вас нет явного контроля над тем, сколько файлов будет создано в результате запроса CTAS, поскольку Athena является распределенной системой. С другой стороны, вы не хотите иметь много маленьких файлов. Так что можете попробовать это использовать «этот обходной путь» , который использует bucketed_by и bucket_count поля в пределах WITH предложение
CREATE TABLE new_table
WITH (
...
bucketed_by=ARRAY['some_column_from_select'],
bucket_count=1
) AS (
-- Here goes your normal query
SELECT
*
FROM
old_table;
)
В качестве альтернативы, уменьшить количество разделов, то есть остановиться намесячный уровень.