Коли витрати на AWS Athena різко зростають: основні уроки та як цього уникнути-serverless-архітектурі

Posted on by data-life-ua

У сфері інженерії даних вибір правильних інструментів і технологій є критично важливим для ефективного керування та аналізу даних. AWS Athena стала популярним вибором серед інженерів даних завдяки своїй serverless-архітектурі та можливості виконувати запити безпосередньо до даних у Amazon S3, використовуючи стандартний SQL.

Однак, як і будь-яка технологія, вона має власні переваги та обмеження. У цьому дописі я розповім, чому мені подобається працювати з Athena, з якими прихованими проблемами я зіткнувся, та як уникнути їх у майбутньому.

Чому я люблю і водночас ненавиджу працювати з Athena

Як інженер даних, я маю глибоку повагу до AWS Athena. Вона пропонує багато переваг, які роблять зберігання даних та виконання запитів дуже простими. Ось кілька причин, чому мені подобається працювати з Athena:

  • Простота використання з S3: зберігати дані в S3 і читати їх за допомогою Athena просто та ефективно.
  • Федеративні запити: за допомогою простого налаштування конектора користувачі можуть об’єднувати дані з S3 із даними з різних баз даних.
  • Підтримка таблиць Apache Iceberg: ця функція розширює можливості Athena для виконання запитів
  • Serverless-архітектура: serverless-природа Athena означає, що вам не потрібно турбуватися про керування інфраструктурою, масштабування або виділення ресурсів.
  • Оплата за запит (Pay-Per-Query): ви платите лише за ті запити, які виконуєте, що може бути дуже економічно вигідно для нерегулярних потреб у виконанні запитів.
  • Інтеграція з екосистемою AWS: Athena легко інтегрується з іншими сервісами AWS, такими як AWS Glue, Amazon QuickSight і AWS Lambda, що розширює її функціональність і спрощує використання.
  • Стандартний інтерфейс SQL: Athena підтримує стандартний SQL, що робить її доступною для користувачів, які вже знають SQL, без потреби додаткового навчання.
  • Висока масштабованість: Athena може ефективно працювати з великими наборами даних і складними запитами, масштабуючись за потреби для задоволення попиту.
  • Легкість налаштування: почати працювати з Athena можна дуже швидко, оскільки вона потребує мінімального налаштування, що дозволяє швидко розгорнути її та почати використовувати.
  • Аналітика Data Lake: Athena чудово підходить для виконання ad-hoc запитів до даних, що зберігаються в озері даних (data lake), надаючи швидкі інсайти без потреби у використанні сховища даних (data warehouse).

Однак, як і будь-яка технологія, Athena не позбавлена недоліків. Хоча ми часто обговорюємо переваги й недоліки різних фреймворків, баз даних, форматів, архітектур або підходів, визначити мінуси Athena іноді буває складно. Деякі очевидні обмеження:

  • Не традиційна база даних: Athena — це сервіс для виконання запитів, а не база даних. Це означає, що вона не підтримує типові операції баз даних, такі як оновлення (update) та видалення (delete) у звичному вигляді. Також є обмеження щодо ACID-транзакцій при використанні формату таблиць Hive.
  • Обмеження партицій: існує обмеження на додавання більше ніж 100 партицій за один раз, що може бути незручним під час роботи з великими обсягами даних.
  • Керування схемою (Schema Management): обробка змін у схемі може бути складною, оскільки еволюція схеми (schema evolution) не така безперервна та зручна, як у деяких інших системах. Знову ж таки, це стосується лише формату таблиць Hive.
  • Нестабільність продуктивності: продуктивність запитів може значно змінюватися залежно від структури та організації даних, що зберігаються в S3.

Реальний сценарій: прихована пастка Athena

Уявімо ситуацію, коли ми використовуємо Athena для зберігання трансформованих даних, до яких виконуються запити приблизно раз на місяць. У такому випадку близько 80% даних є «холодними» (Cold Data), а запити складаються з простих SELECT із кількома JOIN.Таке рішення є економічно вигідним, оскільки не має фіксованих витрат на CPU або RAM, на відміну від Redshift.

Протягом двох років така конфігурація працювала успішно: зберігалися терабайти даних, оброблялися тисячі щомісячних запитів із хорошою швидкістю виконання, а пов’язані витрати становили приблизно $4 на день. Порівняно з іншими рішеннями, це дуже вражаючий результат.

Потім виникла неочікувана проблема.

Аналіз структури таблиць і запиту

Щоб проілюструвати проблему, давайте проаналізуємо дві таблиці:

  1. stratum: розділена на партиції за account_id, wave_id та country_id.
  2. kpis: також розділена на партиції за account_id, wave_id та country_id.

Таблиці зберігають дані про різні KPI та групи (stratum) для різних акаунтів, хвиль і країн. Таблиця stratum містить метадані про ці групи для кожного акаунта та хвилі, тоді як таблиця kpis зберігає дані KPI.

Ось приклад запиту:

WITH strata AS (
  SELECT 
    2041 AS wave_id,
    "meta.country",
    stratum_index 
  FROM strata_account_2442_wave_2041
  WHERE "meta.country" IN ('DE') 
    AND ("dem.location" = 'berlin')
)
SELECT
    kpis.kpi_id,
    kpis.wave_id,
    kpis."meta.country" country,
    SUM(kpis.statistic_value * kpis.weight) / SUM(kpis.weight) AS weighted_value
FROM kpis_samples_account_2442 kpis
INNER JOIN strata 
    ON strata.wave_id = kpis.wave_id
    AND strata."meta.country" = kpis."meta.country"
    AND strata.stratum_index = kpis.stratum_index
WHERE
    kpis.wave_id IN (2041) AND
    kpis."meta.country" IN ('DE')
GROUP BY
    kpi_id,
    kpis."meta.country",
    kpis.wave_id

У цьому запиті:

  • Підзапит strata вибирає дані з таблиці stratum, де wave_id = 2041, country = ‘DE‘, а location = ‘berlin‘.
  • Основний запит об’єднує результат підзапиту strata з таблицею kpis за полями wave_id, country та stratum_index, після чого виконує агрегацію, щоб обчислити зважене значення KPI.

Проблема

Під час міграції одному з наших користувачів потрібно було виконати всі існуючі запити. Однак він не міг визначити реальну країну та місцезнаходження для конкретної хвилі, через що довелося виконувати запити по всіх країнах із неіснуючими локаціями, наприклад:

"meta.country" IN ('DE') AND ("dem.location" = 'london')

Це призвело до тисяч запитів із суперечливими фільтрами. Оскільки в таблиці stratum не було даних для цих фільтрів, підзапит strata не повернув жодних результатів. Попри це, було виконано об’єднання (join) з таблицею kpis (яка містить понад терабайт даних), через що Athena просканувала весь розділ (partition) таблиці kpis, щоб повернути 0 результатів. Таке неефективне сканування призвело до значних витрат.

На жаль, механізм повторних спроб (retry) визначив відсутність результатів як проблему та запустив повторні запити. У результаті за один день було виконано сотні сканувань таблиці, що коштувало компанії понад $1000. Це занадто багато, щоб залишити без уваги, тож я вирішив написати цей пост.

Аналіз плану виконання запиту

Ось де проблема стає очевидною. В ідеалі план виконання запиту мав би показати, що оскільки підзапит strata порожній, у таблиці kpis не повинно скануватися жодних даних. Однак план виконання показує зовсім іншу картину.

Fragment 0: Final Aggregation and Projection
  Output: kpi_id, wave_id, country, weighted_value
  Process: Final aggregation and projection of results.
  Steps:
    Project weighted value (expr_8 = sum / sum_7).
      Aggregate keys (kpi_id, meta.country, wave_id) to get sum_7 and sum.
        Use LocalExchange to partition the data by hash.
Fragment 1: Partial Aggregation
  Output: kpi_id, meta.country, wave_id, sum_10, sum_9
  Process: Partial aggregation before final merge.
  Steps:
    Calculate sum_10 (sum of weights) and sum_9 (sum of weighted values).
    Join data based on stratum_index.
Fragment 2: Source Scan for KPI Data
  Output: stratum_index, statistic_value, weight, wave_id, meta.country, kpi_id
  Process: Scan and filter KPI sample data.
  Steps:
    Filter data based on partition keys (kpi_id, wave_id, meta.country).
    Calculate hash values for partitioning.
Fragment 3: Source Scan for Strata Data
  Output: stratum_index_0
  Process: Scan and filter strata data.
    Steps:
    Filter based on location (dem.location = 'london').
    Calculate hash values for partitioning.

З плану виконання видно, що підзапит strata не повертає жодних результатів, оскільки немає записів, які відповідають заданим умовам. Однак замість того, щоб пропустити операцію JOIN, план виконання показує, що вся таблиця kpis_samples_account_2442 сканується для країни ‘DE’, що призводить до непотрібної та дорогої операції.

Детальний розбір проблеми

Основна проблема полягає в тому, що коли підзапит strata не повертає жодного рядка, ми очікуємо, що JOIN також не поверне результатів без сканування таблиці kpis.Однак планувальник запитів Athena не оптимізує цей сценарій. Динамічні фільтри, які застосовуються під час процесу JOIN, не можуть ефективно запобігти повному скануванню таблиці kpis, що призводить до таких проблем:

  • Неефективне використання ресурсів: сканування всієї таблиці kpis для ‘DE‘, навіть попри те, що підзапит strata не повертає результатів, призводить до марного використання обчислювальних ресурсів.
  • Збільшення витрат: кожне повне сканування таблиці спричиняє витрати, які, помножені на кількість таких непотрібних сканувань, призводять до суттєвих фінансових витрат.
  • Ризики масштабування: хоча Athena добре масштабується для обробки великих запитів, це також може призводити до надмірних витрат, якщо її використовувати без належного контролю.

Як уникнути цієї проблеми в майбутньому

Щоб запобігти подібним дорогим сценаріям у майбутньому, варто розглянути впровадження таких стратегій:

  1. Створення різних Workgroups: налаштуйте різні workgroups для різних користувачів і встановіть обмеження на максимальний обсяг даних, який запит може просканувати. Це допоможе ефективно контролювати та розподіляти ресурси, гарантуючи, що жоден окремий запит не зможе використати надмірну кількість ресурсів.
  2. Створення сповіщень CloudWatch: налаштуйте сповіщення в CloudWatch для відстеження незвично великого обсягу даних, просканованих за день або годину. Це допоможе рано виявляти аномальні патерни запитів і реагувати на них, запобігаючи неочікуваним витратам.
  3. Оптимізація партиціювання даних: переконайтеся, що ваші дані правильно розбиті на партиції, щоб мінімізувати обсяг даних, який сканується під час типових запитів. Правильне партиціювання на основі полів, за якими найчастіше виконуються запити, може значно покращити продуктивність запитів і зменшити витрати.
  4. Використовуйте інструменти моніторингу запитів: скористайтеся вбудованими інструментами моніторингу запитів AWS Athena, щоб відстежувати продуктивність запитів і використання ресурсів. Регулярно переглядайте логи запитів, щоб знаходити та оптимізувати неефективні запити.
  5. Використовуйте кешування запитів: де це можливо, застосовуйте механізми кешування запитів, щоб уникати повторного сканування тих самих даних. Це особливо ефективно для часто виконуваних запитів.
  6. Застосовуйте детальний контроль доступу: обмежуйте доступ до чутливих або великих наборів даних лише тим користувачам, яким це справді необхідно. Це зменшує ризик випадкового запуску важких запитів користувачами, які можуть не усвідомлювати розмір даних.
  7. Навчайте користувачів кращим практикам: навчайте користувачів писати ефективні запити та розуміти фінансові наслідки їх виконання. Надання рекомендацій і кращих практик допоможе уникнути поширених помилок.

Запровадивши ці стратегії, ви зможете зменшити ризики, пов’язані з масштабованістю Athena, і забезпечити більш передбачувані та керовані витрати на виконання запитів.

Висновок

AWS Athena має багато сильних сторін, особливо простоту використання, підтримку федеративних запитів та гнучкість у роботі з форматами, такими як Apache Iceberg. Однак вона також має певні недоліки, які можуть призвести до значних витрат, якщо не керувати ними належним чином. Наш досвід роботи з Athena підкреслює важливість розуміння її обмежень, зокрема неефективності планування запитів та ризику непотрібних сканувань даних.

Щоб повністю використати потенціал Athena і водночас уникнути її недоліків, важливо впроваджувати кращі практики, такі як створення workgroups, налаштування сповіщень, оптимізація партиціювання даних та навчання користувачів. Це дозволяє використовувати потужні можливості Athena, зберігаючи контроль над витратами та продуктивністю. Такий збалансований підхід гарантує, що Athena залишатиметься цінним інструментом у нашому наборі інструментів для інженерії даних, дозволяючи використовувати її переваги та водночас зменшувати потенційні ризики. Зрештою, навчання на власному досвіді та проактивне вирішення цих викликів допоможе зробити керування даними більш ефективним і економічно вигідним.

І наостанок варто пам’ятати головне застереження щодо використання Athena:

Фінансові витрати: хоча Athena є недорогою для рідкісних запитів, більш часті та складні запити можуть призвести до високих витрат, особливо при роботі з великими наборами даних.

Простими словами 🚀

Переклад:
Дякуємо, що були частиною спільноти In Plain English Перш ніж ви підете:

  • Обов’язково поставте оплески 👏 та підпишіться на автора.
  •  Підпишіться на нас: X | LinkedIn | YouTube | Discord | Newsletter
  • Відвідайте наші інші платформи: CoFeed | Differ
  • Більше контенту на: PlainEnglish.io

ОРИГІНАЛ СТАТТІ:When AWS Athena costs skyrocket: Key lessons and how to avoid them

АВТОР СТАТІ:José David Arévalo

🚀Долучайтесь до нашої спільноти Telegram:

🚀Долучайтесь до нашої спільноти FaceBook:

🚀Долучайтесь до нашої спільноти Twiter X:

Leave a Reply

Related Posts