Раздел S3 (размер файла) для эффективного запроса Athena - PullRequest
Новая
       5

Раздел S3 (размер файла) для эффективного запроса Athena

0 голосов
/ 16 января 2019

У меня есть конвейер, который загружает ежедневные записи в S3. Затем я использую AWS Glue Crawler для создания раздела для облегчения запроса AWS Athena. Тем не менее, есть много разделенных данных, по сравнению с другими.

Папки / файлы S3 отображаются следующим образом: 

s3.ObjectSummary(bucket_name='bucket', key='database/table/2019/00/00/2019-00-00.parquet.gzip')   7.8 MB

s3.ObjectSummary(bucket_name='bucket', key='database/table/2019/01/11/2019-01-11.parquet.gzip')  29.8 KB
s3.ObjectSummary(bucket_name='bucket', key='database/table/2019/01/12/2019-01-12.parquet.gzip')  28.5 KB
s3.ObjectSummary(bucket_name='bucket', key='database/table/2019/01/13/2019-01-13.parquet.gzip')  29.0 KB
s3.ObjectSummary(bucket_name='bucket', key='database/table/2019/01/14/2019-01-14.parquet.gzip')  43.3 KB
s3.ObjectSummary(bucket_name='bucket', key='database/table/2019/01/15/2019-01-15.parquet.gzip') 139.9 KB

с размером файла, отображаемым в конце каждой строки. Обратите внимание, что 2019-00-00.parquet.gzip содержит все записи до 2019-01-11 и, следовательно, его размер большой. Я прочитал this и там написано "Если ваши данные сильно искажены до одного значения раздела, и большинство запросов используют это значение, то издержки могут уничтожить первоначальное преимущество."

Итак, мне интересно, стоит ли разбивать 2019-00-00.parquet.gzip на более мелкие паркетные файлы с разными разделами. Например, 

key='database/table/2019/00/00/2019-00-01.parquet.gzip',
key='database/table/2019/00/00/2019-00-02.parquet.gzip',
key='database/table/2019/00/00/2019-00-03.parquet.gzip', ......

Однако я полагаю, что это разбиение не так полезно, так как оно не отражает, когда хранились старые записи. Я открыт для всех обходных путей. Спасибо.

1 Ответ

0 голосов
/ 06 февраля 2019

Если полный размер ваших данных составляет менее пары гигабайт, вам вообще не нужно разбивать таблицу. Секционирование небольших наборов данных вредит производительности гораздо больше, чем помогает. Храните все файлы в одном каталоге, глубокие структуры каталогов в нераспределенных таблицах также снижают производительность.

Для небольших наборов данных вам будет лучше без разбиения на разделы, если файлов не слишком много (старайтесь, чтобы оно было меньше ста). Если по какой-то причине у вас должно быть много небольших файлов, вы можете получить выгоду от разбиения, но в этом случае сравните его с оценкой.

Когда размер данных небольшой, как в вашем случае, затраты на поиск файлов на S3, их открытие и чтение будут выше, чем на самом деле их обработка.

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

...