Amazon Athena є інтерактивною службою запитів, яка дозволяє легко аналізувати дані, збережені в Amazon Simple Storage Service (Amazon S3), за допомогою стандартного SQL. Athena є безсерверною, тому немає інфраструктури для управління, і ви платите лише за запити, які ви виконуєте. Athena легка у використанні. Просто вкажіть ваші дані в Amazon S3, визначте схему і почніть виконувати запити за допомогою стандартного SQL.
У цьому пості ми розглянемо десять найкращих порад, які можуть покращити продуктивність запитів. Ми акцентуємо увагу на аспектах, пов’язаних із зберіганням даних в Amazon S3, а також настроюванням, специфічним для запитів.
Цей пост передбачає, що у вас є знання різних форматів файлів, таких як Parquet, ORC, TEXTFILE, AVRO, CSV, TSV та JSON.
Зберігання (Storage)
Цей розділ розглядає, як організувати ваші дані, щоб ви могли отримати максимальний ефект від використання Athena. Ви можете застосовувати ті ж практики до обробки даних в Amazon EMR, таких як Spark, Presto та Hive, коли ваші дані зберігаються в Amazon S3. Ми обговорюємо наступні найкращі практики:
- Розділяйте ваші дані на розділи.
- Групуйте ваші дані в бакети.
- Використовуйте стиснення.
- Оптимізуйте розмір файлів.
- Оптимізуйте генерацію сnовпчикового сховища даних.
1. Розділяйте ваші дані на розділи (Partition)
Athena підтримує партиціювання Hive, яке використовує один із двох конвенцій найменування. Перший метод полягає в тому, щоб партиціювати назву стовпця з наступним знаком рівності (=), а потім значення. Наприклад:
s3://yourBucket/pathToTable/<PARTITION_COLUMN_NAME>=<VALUE>/<PARTITION_COLUMN_NAME>=<VALUE>/Якщо ваш набір даних партиційованно у цьому форматі, то ви можете виконати команду MSCK REPAIR table, щоб автоматично додати партицію до вашої таблиці.
Якщо шлях до ваших даних не відповідає вищезазначеному формату, ви можете вручну додавати партиції, використовуючи команду ALTER TABLE ADD PARTITION для кожного розділу. Наприклад:
ALTER TABLE <tablename> ADD PARTITION (PARTITION_COLUMN_NAME = <VALUE>, PARTITION_COLUMN2_NAME = <VALUE>) LOCATION ‘s3://yourBucket/pathToTable/YYYY/MM/DD/’;За допомогою цієї методології ви можете зв’язати будь-яке розташування з тими значеннями, на які ви хочете посилатися.
Наступний приклад показує, як дані партиційовані за стовпцем “year” у таблиці “польотів”, збереженій у віджеті S3:
$ aws s3 ls s3://athena-examples/flight/parquet/
PRE year=1987/
PRE year=1988/
PRE year=1989/
PRE year=1990/
PRE year=1991/
PRE year=1992/
PRE year=1993/Ви можете обмежити партиції, які скануються в запиті, використовуючи стовпець у партиції ‘WHERE’.
SELECT dest, origin FROM flights WHERE year = 1991Ви також можете використовувати декілька стовпців як ключі партицій. Ви можете сканувати дані для конкретних значень та інше.
s3://athena-examples/flight/parquet/year=1991/month=1/day=1/
s3://athena-examples/flight/parquet/year=1991/month=1/day=2/При виборі стовпців для партицій враховуйте наступне:
Стовпці, які використовуються як фільтри, є хорошими кандидатами для партицій. Партиціювання має свою вартість. Зі збільшенням кількості партицій у вашій таблиці зростає накладна вартість на отримання та обробку метаданих партицій, а також зменшується розмір файлів. Занадто дрібне партиціювання може анулювати початкову вигоду. Якщо ваші дані сильно перекошені на одне значення партиції і більшість запитів використовують це значення, то накладні витрати можуть анулювати початкову вигоду. Наприклад, у наступній таблиці порівнюються час виконання запитів між розділеною і нерозділеною таблицею. Обидві таблиці містять дані об’ємом 74 ГБ, нестиснуті та збережені у текстовому форматі. Партиційована таблиця розділена за стовпцем l_shipdate і має 2,526 партицій.
Виконання EXPLAIN ANALYZE для запиту допомагає визначити, чи є таблиця партиційна і, якщо так, то чи використовується партиційний стовпець як фільтр. Розгляньте наступний запит, який виконується на партиційній таблиці:
EXPLAIN ANALYZE SELECT count(*) FROM lineitem WHERE l_shipdate = '1996-09-01'У наступному виводі для оператора TableScan показано, що був використаний фільтр ключа партиції, що призвело до зменшення обсягу сканованих даних:
…
…
Fragment 2
CPU: 851.65ms, Input: 249684 rows (0B), Data Scanned: 29.96MB; per task: std.dev.: 284.00, Output: 30 rows (270B)
Output layout: [count_3]
- Aggregate(PARTIAL) => [[count_3]]
CPU: 46.00ms (5.39%), Output: 30 rows (270B)
Input avg.: 8322.80 rows, Input std.dev.: 1.17%
count_3 := "count"(*)
- TableScan[awsdatacatalog:HiveTableHandle{schemaName=tpch100, tableName=lineitem, analyzePartitionValues=Optional.empty}, grouped = false] => [[]]
CPU: 805.00ms (94.37%), Output: 249684 rows (0B)
Input avg.: 8322.80 rows, Input std.dev.: 1.17%
LAYOUT: tpch100.lineitem
l_shipdate:string:-1:PARTITION_KEY :: [[1996-09-01]]Партіціювання також має негативний вплив, якщо фільтр партиції не використовується в запиті, як показано у наступній таблиці. Впевніться, що ви не партицюєте дані занадто дрібно. Занадто велика кількість партицій призводить до утворення більшої кількості менших файлів, що негативно впливає на продуктивність, як показано пізніше в цьому пості.
Якщо ваша таблиця, збережена в AWS Glue Data Catalog, має десятки, сотні тисяч або мільйони партицій, ви можете включити індекси партицій на таблицю. За допомогою індексів партицій вибирається лише метадані для значення партицій у фільтрі запиту з каталогу, замість вибору всіх метаданих партиції. Результатом є швидші запити для таких високороздільних таблиць. Наступна таблиця порівнює час виконання запитів між партиційною таблицею без індексів партицій та з індексами партицій. Таблиця містить приблизно 100 000 партицій та дані у некомпресованому текстовому форматі. Таблиця замовлень партійована за стовпцем o_custkey.
Щоб дізнатися більше про переваги індексування розділів AWS Glue Data Catalog у Amazon Athena, дивіться статтю “Покращення продуктивності запитів Amazon Athena за допомогою індексів розділів AWS Glue Data Catalog”
2. Bucket your data (Групування/бакетування ваших даних)
Ще один спосіб розділення ваших даних – це групува даних в межах одного розділу. За допомогою групування ви можете вказати один або декілька стовпців, що містять рядки, які ви хочете об’єднати, і розмістити ці рядки у декількох “ковшах” (buckets). Це дозволяє вам запитувати лише той “ковш”, який вам потрібен для читання, коли значення стовпця “ковша” вказано. Це може значно зменшити кількість рядків даних для читання і, відповідно, вартість виконання запиту.
При виборі стовпця для групування ми рекомендуємо вибирати той, який має високу кардинальність (тобто велику кількість унікальних значень) та часто використовується для фільтрації даних під час виконання запиту. Прикладом гарного стовпця для групування може бути основний ключ, такий як ідентифікатор користувача для систем.
У межах Athena ви можете вказати стовпець групування у вашому операторі CREATE TABLE, вказавши CLUSTERED BY (<стовпці групування>) INTO <кількість ковшів> BUCKETS. Кількість “ковшів” повинна бути такою, щоб файли були оптимального розміру. Докладніше дивіться розділ Оптимізація розмірів файлів.
Для використання таблиць з бакетами в межах Athena вам потрібно використовувати Apache Hive для створення файлів даних, оскільки Athena не підтримує формат бакетів Apache Spark. Для отримання інформації про створення таблиць з бакетами дивіться документацію Apache Hive, розділ LanguageManual DDL BucketedTables.
Також зверніть увагу, що Athena не підтримує таблиці та розділи, в яких кількість файлів не відповідає кількості бакетів, наприклад, коли виконано кілька запитів INSERT INTO.
Наступна таблиця показує різницю в таблиці клієнтів, де стовпець c_custkey використовується для створення 32 бакетів. Розмір таблиці клієнтів становить 2,29 ГБ.
Виконання EXPLAIN ANALYZE для попереднього запиту показує, як групування (бакетування) допомогло зчитувати менше даних з Amazon S3 для таблиці клієнтів. Наступні фрагменти виводу EXPLAIN ANALYZE для запиту до негрупованої (небакетованої) і групованої (бакетованої) таблиці виділяють вхідні рядки та розмір даних для розуміння різниці.
Ось вивід для негрупованої таблиці:
…
…
- ScanFilterProject[table = awsdatacatalog:HiveTableHandle{schemaName=tpch100, tableName=customer, analyzePartitionValues=Optional.empty}, grouped = false, filterPredicate = ("c_custkey" = 12677856)] => [[]]
CPU: 30.35s (99.95%), Output: 1 row (0B)
Input avg.: 202702.70 rows, Input std.dev.: 4.83%
LAYOUT: tpch100.customer
c_custkey := c_custkey:int:0:REGULAR
Input: 15000000 rows (2.29GB), Filtered: 100.00%Ось вивід для таблиці з бакетуванням:
…
…
- ScanFilterProject[table = awsdatacatalog:HiveTableHandle{schemaName=tpch100, tableName=customer, analyzePartitionValues=Optional.empty}, grouped = false, filterPredicate = ("c_custkey" = 12677856)] => [[]]
CPU: 858.00ms (100.00%), Output: 1 row (0B)
Input avg.: 156250.00 rows, Input std.dev.: 22.44%
LAYOUT: tpch100.customer bucket=32
c_custkey := c_custkey:int:0:REGULAR
Input: 468750 rows (72.94MB), Filtered: 100.00%3. Use Compression (Використовуйте стиснення)
Стиснення ваших даних може значно прискорити виконання запитів, якщо файли мають оптимальний розмір (див. наступний розділ) або файли можна розділити. Зменшені розміри даних зменшують обсяг сканування даних з Amazon S3, що призводить до зменшення витрат на виконання запитів. Вони також зменшують мережевий трафік з Amazon S3 до Athena.
У наступній таблиці наведено підсумок підтримки форматів стиснення в Athena для кожного формату файлів зберігання. Формат TEXTFILE включає TSV, CSV, JSON та користувацькі серіалізатори для тексту.
Файл, який можна розділити (splittable), може бути прочитаний паралельно виконавчим двигуном в Athena, у той час як нерозділений файл не може бути прочитаний паралельно. Це означає, що час на читання роздільного файлу менший порівняно з нероздільним файлом. Формати AVRO, Parquet та Orc є роздільними, незалежно від використаного кодеку стиснення. Для текстових файлів роздільними є лише файли, стиснуті кодеками BZIP2 та LZO. Якщо використовуються інші кодеки для текстових файлів, уникайте маємо один великий стиснутий файл. Замість цього, розділіть його на кілька стиснутих файлів оптимального розміру, як це обговорено в наступному розділі.
Для Athena ми рекомендуємо використовувати Apache Parquet або Apache ORC, які за замовчуванням стискають дані та є роздільними.
Ви можете стиснути ваш набір даних за допомогою AWS Glue ETL jobs, Spark або Hive на Amazon EMR, або використовуючи оператори CTAS, INSERT INTO і UNLOAD в Athena. Ось приклад скрипта для стиснення за допомогою AWS Glue:
from awsglue.job import Job
from awsglue.transforms import *
from awsglue.context import GlueContext
from awsglue.utils import getResolvedOptions
from pyspark.context import SparkContext
args = getResolvedOptions(sys.argv, ['JOB_NAME'])
sc = SparkContext()
glueContext = GlueContext(sc)
spark = glueContext.spark_session
job = Job(glueContext)
job.init(args['JOB_NAME'], args)
## Read TABLE_NAME from DB_NAME out of the AWS Glue Data Catalog
dataset = glueContext.create_dynamic_frame.from_catalog(database = DB_NAME, table_name = TABLE_NAME, transformation_ctx = "dataset")
## Write data in JSON format to S3, compressed with GZip
outputdf = glueContext.write_dynamic_frame.from_options( \
frame = dataset,
connection_type = "s3",
connection_options = {"path":"s3://bucket/prefix/"},
format = "json",
compression = "gzip",
transformation_ctx = "outputdf")
job.commit()4. Оптимізація розмірів файлів
Запити працюють більш ефективно, коли сканування даних може бути паралелізовано і коли блоки даних можуть бути читані послідовно. Переконайтеся, що ваші формати файлів є роздільними, що допомагає з паралелізмом, незалежно від того, наскільки великі ваші файли.
Однак, якщо ваші файли занадто малі (зазвичай менше 128 МБ), виконавчий двигун може витрачати додатковий час на накладні витрати з відкриття файлів S3, переліку каталогів, отриманні метаданих об’єкта, налаштуванні передачі даних, читанні заголовків файлів, читанні словників стиснення тощо. З іншого боку, якщо ваш файл не є роздільним, і файли занадто великі, обробка запиту чекає, доки один читач завершить читання всього файлу. Це може зменшити паралелізм.
Одним із засобів вирішення проблеми з невеликими файлами є використання утиліти S3DistCP на Amazon EMR. Ви можете використовувати її для об’єднання менших файлів в більші об’єкти. Також S3DistCP можна використовувати для переміщення великих обсягів даних оптимізованим способом з HDFS в Amazon S3, з Amazon S3 в Amazon S3 і з Amazon S3 до HDFS.
Деякі переваги використання більших файлів включають швидше перелікування, менше запитів до Amazon S3 та менше метаданих для управління.
Наприклад, наступна таблиця порівнює час виконання запитів між двома таблицями, одна з яких базується на одному великому файлі, а інша на 100 000 малих файлів. Обидві таблиці містять приблизно 8 ГБ даних, збережених у текстовому форматі.
Ви також можете використовувати AWS Glue для розділення ваших даних, як показано в наступному прикладі скрипта.
from awsglue.job import Job
from awsglue.transforms import *
from awsglue.context import GlueContext
from awsglue.utils import getResolvedOptions
from pyspark.context import SparkContext
args = getResolvedOptions(sys.argv, ['JOB_NAME'])
sc = SparkContext()
glueContext = GlueContext(sc)
spark = glueContext.spark_session
job = Job(glueContext)
job.init(args['JOB_NAME'], args)
## Read TABLE_NAME from DB_NAME out of the AWS Glue Data Catalog
dataset = glueContext.create_dynamic_frame.from_catalog(database = DB_NAME, table_name = TABLE_NAME, transformation_ctx = "dataset")
## Write data in JSON format to S3, compressed with GZip
outputdf = glueContext.write_dynamic_frame.from_options( \
frame = dataset,
connection_type = "s3",
connection_options = {"path":"s3://bucket/prefix/", compression = "gzip"},
format = "json",
transformation_ctx = "outputdf")
job.commit()5. Оптимізація генерації сховища даних у стовпчиковому форматі
Apache Parquet та Apache ORC є популярними сховищами даних у стовпчиковому форматі. Вони надають можливості для ефективного зберігання даних за допомогою стовпцевого стиснення, різних методів кодування, стиснення на основі типу даних та підтримку відсічення. Крім того, вони підтримують розділення даних на блоки. Зазвичай, кращі коефіцієнти стиснення або пропуск блоків даних означають зчитування меншої кількості байтів з Amazon S3, що призводить до покращення продуктивності запитів і зменшення витрат на їх виконання. У Parquet і ORC є кілька параметрів, які можна налаштувати для досягнення оптимальної продуктивності.
Один із параметрів, який можна налаштувати, – це розмір блоку (або розмір смуги) у Parquet (або розмір смуги у ORC). Розмір блоку в Parquet визначає максимальну кількість рядків, які можуть поміститися в один блок у байтах. Чим більший розмір блоку або смуги, тим більше рядків можна зберегти в кожному блоку. За замовчуванням розмір блоку в Parquet становить 128 МБ, а розмір смуги в ORC – 64 МБ. Ми рекомендуємо встановлювати більший розмір блоку, якщо у вас є таблиці з багатьма стовпцями, щоб забезпечити ефективне послідовне введення/виведення даних.
Іншим параметром, який можна налаштувати, є алгоритм стиснення для блоків даних. Parquet підтримує стиснення GZIP, Snappy (за замовчуванням), ZSTD та LZO. ORC підтримує стиснення ZLIB (за замовчуванням), LZ4, ZSTD та Snappy. Ми рекомендуємо почати з алгоритму стиснення за замовчуванням і тестувати інші алгоритми стиснення, якщо у вас є більше 10 ГБ даних.
Формати файлів Parquet і ORC обидва підтримують відсічення на основі предикату (також називається фільтрація за предикатом). Обидва формати мають блоки даних, що представляють значення стовпця. Кожен блок містить статистику для блоку, таку як максимальні/мінімальні значення. Під час виконання запиту ця статистика визначає, чи повинен бути блок прочитаний або пропущений в залежності від значення фільтра, яке використовується в запиті. Це допомагає зменшити кількість сканованих даних і покращує продуктивність запиту. Для використання цієї можливості додайте більше фільтрів у запит (наприклад, за допомогою класу WHERE).
Один із способів оптимізації кількості блоків для пропуску полягає у визначенні та сортуванні за загальним стовпцем, який часто фільтрується, перед записом файлів ORC або Parquet. Це забезпечує те, що діапазон між мінімальним та максимальним значеннями в межах кожного блоку є якомога меншим, що покращує можливість відсічення та додатково зменшує кількість сканованих даних.
У таблиці нижче порівнюються часи виконання та обсяги сканованих даних для одного й того ж набору даних у текстовому форматі GZIP, форматі Parquet GZIP без сортування та форматі Parquet GZIP з сортуванням за l_partkey.
Ви можете конвертувати ваші існуючі дані в формат Parquet або ORC, використовуючи Spark або Hive на Amazon EMR, завдання ETL AWS Glue, або команди CTAS (Create Table As Select) або INSERT INTO та UNLOAD в Athena.
Кастомізація запитів
Двигун Athena побудований на основі Presto. Розуміння його принципів роботи дозволяє зрозуміти, як можна оптимізувати запити при їх виконанні. Цей розділ надає наступні рекомендації щодо найкращих практик:
6. Оптимізація підсортування (ORDER BY).
7. Оптимізація об’єднань (joins).
8. Оптимізація групування (GROUP BY).
9. Використання наближених функцій (approximate functions).
10. Включайте лише ті колонки, які вам потрібні.
6. Оптимізація підсортування (ORDER BY).
ORDER BY повертає результати запиту в впорядкованому вигляді. Athena використовує розподілене сортування для виконання операції сортування паралельно на кількох вузлах. Якщо ви використовуєте ORDER BY для отримання верхніх або нижніх N значень, використовуйте LIMIT для зменшення витрат на сортування, що призводить до швидшого часу виконання запиту.
Наприклад, наведена нижче таблиця узагальнює час виконання для набору даних з таблицею розміром 7,25 ГБ, не стиснутою в текстовому форматі, з приблизно 60 мільйонами рядків.
7. Оптимізація об’єднань (joins).
Вибір правильного порядку з’єднання є критичним для поліпшення продуктивності запиту. При з’єднанні двох таблиць вказуйте більшу таблицю на лівому боці з’єднання і меншу таблицю на правому боці з’єднання. Athena розподіляє таблицю праворуч на робочі вузли, а потім передає таблицю ліворуч для виконання з’єднання. Якщо таблиця справа менша, то використовується менше пам’яті, і запит виконується швидше.
У наведеній нижче таблиці показані часи виконання для набору даних з загальним обсягом 74 ГБ, не стиснутого у текстовому форматі, з приблизно 602 мільйонами рядків.
При з’єднанні трьох і більше таблиць, ви можете розглянути можливість спочатку з’єднати велику таблицю з найменшою, щоб зменшити проміжний результат і потім з’єднати з іншими таблицями.
SELECT count(*)
FROM Table_A
JOIN Table_B ON Table_A.date = Table_B.date
WHERE Table_B.column_A = "value"Athena також підтримує динамічну фільтрацію та динамічне відкидання партіцій, що покращує продуктивність запиту та зменшує обсяг сканованих даних для запитів з об’єднаннями і дуже вибірковим фільтром для таблиці справа від об’єднання, як показано в наступному прикладі. У наступному запиті Table_B – це мала таблиця з дуже вибірковим фільтром (column_A = “value”). Після застосування вибіркового фільтру до Table_B, спершу виділяється список значень для об’єднаного стовпця Table_B.date, і він передається вниз до об’єднаної таблиці Table_A як фільтр. Це використовується для відсіювання зайвих рядків та партіцій Table_A. Це призводить до зменшення читання рядків та партіцій з джерела для Table_A та допомагає скоротити час виконання запиту та розмір скану даних, що, в свою чергу, допомагає зменшити витрати на виконання запиту в Athena.
8. Оптимізація групування (GROUP BY).
Оператор GROUP BY розподіляє рядки на робочі вузли відповідно до стовпців GROUP BY, які зберігають значення GROUP BY в пам’яті. По мірі надходження рядків стовпці GROUP BY перевіряються в пам’яті, і значення порівнюються. Якщо стовпці GROUP BY збігаються, значення агрегуються разом.
При використанні GROUP BY в вашому запиті впорядкуйте стовпці від найвищої кількості унікальних значень (рівномірно розподілених) до найнижчої.
SELECT state, gender, count(*)
FROM census
GROUP BY state, gender;Ще однією оптимізацією є обмеження кількості стовпців у SELECT та GROUP BY, щоб зменшити обсяг пам’яті, необхідний для зберігання, оскільки рядки зберігаються в пам’яті та агрегуються для GROUP BY. У наступному прикладі показане прискорення запитів при скороченні кількості стовпців у SELECT.
9. Використання наближених функцій (approximate functions).
Для дослідження великих наборів даних загальним випадком є знаходження кількості унікальних значень для певного стовпця за допомогою COUNT(DISTINCT column). Наприклад, це може бути корисним для визначення кількості унікальних користувачів, які заходили на веб-сторінку.
Якщо точне число не є обов’язковим (наприклад, якщо ви шукаєте сторінки для докладного аналізу), розгляньте можливість використання функції approx_distinct(). Ця функція намагається мінімізувати використання пам’яті, рахуючи унікальні хеші значень замість цілих рядків. Однак недолік полягає в тому, що є стандартна похибка в розмірі 2,3%.
У таблиці нижче наведено підсумок прискорення на наборі даних з таблицею об’ємом 74 ГБ, некомпресованою в текстовому форматі та приблизно 600 мільйонами рядків.
10. Включайте лише ті колонки, які вам потрібні.
При виконанні запитів обмежуйте кінцевий оператор SELECT лише тими стовпцями, які вам потрібні, замість вибору всіх стовпців. Зменшення кількості стовпців зменшує обсяг даних, який потрібно обробляти через усю конвеєр виконання запиту. Це особливо корисно, коли ви виконуєте запити до таблиць, в яких є велика кількість стовпців на основі рядків, і коли ви виконуєте кілька об’єднань або агрегацій. У випадку стовпчастих форматів це зменшує обсяг даних, які скануються з Amazon S3, оскільки читається лише дані конкретних стовпців.
У таблиці нижче наведено підсумок прискорення на наборі даних з таблицею об’ємом 7,25 ГБ, некомпресованою в текстовому форматі та приблизно 60 мільйонами рядків.
Додаткові поради
У цьому розділі ми надаємо додаткові поради з налаштування продуктивності.
Оптимізація обробки розділів за допомогою проекції розділів Обробка інформації про розділи може стати гальмом для запитів Athena, коли у вас є дуже велика кількість розділів і ви не використовуєте індексацію розділів AWS Glue. Ви можете використовувати проекцію розділів в Athena, щоб прискорити обробку запитів для сильно розділених таблиць і автоматизувати управління розділами. Проекція розділів допомагає мінімізувати цей накладний розхід, дозволяючи вам запитувати розділи, розраховуючи інформацію про розділи, а не отримуючи її з метасховища. Вона позбавляє вас необхідності додавати метадані розділів до таблиці AWS Glue.
У проекції розділів значення і розташування розділів розраховуються з конфігурації, а не зчитуються з репозиторію, такого як Каталог даних AWS Glue. Оскільки операції в пам’яті зазвичай є швидшими за віддалені операції, проекція розділів може скоротити час виконання запитів для сильно розділених таблиць. Залежно від конкретних характеристик запиту та базових даних, проекція розділів може значно зменшити час виконання запитів, які обмежені на отримання метаданих розділів.
Використання проекції розділів є ідеальним, коли схеми розділів ваших розділів співпадають або коли схема таблиць завжди точно описує схеми розділів. Це можна використовувати для розділення стовпців дуже великої кількості, таких як ідентифікатори або діапазони дат з дуже дрібною грануляцією.
Прискорення запитів, що виробляють великі результати, за допомогою UNLOAD
Виконання запиту SELECT в Athena призводить до створення одного файлу результату в Amazon S3 у стиснутому форматі CSV. Якщо очікується, що ваш запит виведе великий результатний набір (наприклад, 13 ГБ, як показано в наступному прикладі), значний час витрачається на запис результатів в один файл в Amazon S3. За допомогою UNLOAD ви можете розділити результати на кілька файлів в Amazon S3, що зменшує час, витрачений на фазу запису. Ви також можете вказати формат результату (ORC, Parquet, AVRO, JSON або TEXTFILE) та тип стиснення (за замовчуванням GZIP для Parquet, JSON та TEXTFILE; та ZLIB для ORC) для набору результатів.
У таблиці нижче показане порівняння між операторами SELECT та UNLOAD. Очікується, що запит виведе приблизно 13 ГБ некомпресованих даних.
Висновок
У цій публікації було розглянуто наші десять основних порад для оптимізації вашого інтерактивного аналізу на Athena з двигуном Presto. Ви можете використовувати ці ж самі практики при використанні Presto на Amazon EMR.
Оригінал статі:Top 10 Performance Tuning Tips for Amazon AthenaАвтори статі:
Mert Hocanin is a Principal Big Data Architect with AWS Lake Formation
Pathik Shah is a Sr. Big Data Architect on Amazon Athena. He joined AWS in 2015 and has been focusing in the big data analytics space since then, helping customers build scalable and robust solutions using AWS analytics services.
🚀Долучайтесь до нашої спільноти Telegram:
🚀Долучайтесь до нашої спільноти FaceBook:
