Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 30
×

Як оптимізувати обробку, зберігання та аналіз даних для Data Lake на AWS: сервіси, рішення та інсайти

Усім привіт! Мене звати Ігор Козлов, і я — Python Software Engineer в компанії Levi9. У першій частині статті я розповів про збір вимог і побудову injection pipeline для Data Lake на AWS. У цьому матеріалі я розповім детальніше про обробку, зберігання та аналіз даних, які сервіси ми з командою використовуємо та їхні особливості. Спершу поглянемо на обробку даних.

Event based data processing

Під час обробки даних важливо розуміти, як опрацьовувати датасет. Якщо дані незалежні, то можна розпаралелити обробку по файлах, і навпаки — коли інформація пов’язана, то нам потрібно обробляти весь датасет разом. Ба більше, від розміру даних залежить, який саме сервіс обрати для їхньої обробки. Для себе ми виділили три основні сервіси:

  • AWS Lambda. Використовується для роботи з невеликими файлами (зазвичай до 2-3 гігабайтів) і простими трансформаціями. Основне перетворення в цьому сервісі — це конвертування даних в них у Parquet-формат.
  • AWS Batch. Його ми використовуємо для обробки даних вагою більше, ніж 3 ГБ, та коли необхідно виконати складніші трансформації чи data enrichment — наприклад, додати до кожного рядку дані, отримані з API.
  • AWS Glue. Оптимальний для поєднання великих датасетів, фільтрації, групування тощо. Цей сервіс добре працює з даними, що важать понад 15 ГБ і дозволяє здійснювати навіть просту конвертацію в Parquet набагато швидше внаслідок паралелізації та інших можливостей Apache Spark.

Процес обробки мають запускати певні сигнали — тригери. Ними можуть бути:

  • S3 Event notifications. Як тільки файл завантажено до S3, івент тригериться та активує лямбду, в якій вже прописано логіку обробки датасету.
  • API Gateway. Коли інша команда повністю завантажила дані, вона робить виклик API та повідомляє наші сервіси про це.

Візуальне представлення архітектури

Помітили, що ми розділили логіку обробки івентів і обробки даних? За івенти в нас відповідає Lambda, що парсить event payload і передає всю необхідну інформацію сервісу для обробки. Ним може виступати Glue, Batch або Lambda. Надіславши інформацію на сервіс, lambda більше не залучається в процес — вони вже самі беруть необхідні дані з S3 та обробляють.

Оскільки основний сервіс для обробки великого об’єму даних все-таки AWS Glue, давайте поглянемо детальніше на його можливості та нюанси роботи.

Одні з основних функцій AWS Glue — це Data Catalog і Crawlers.

Crawler-и можуть автоматично інспектувати дані та створювати таблиці в data- каталозі, які описують ваші дані у форматі полів та їхніх типів. Результат дуже схожий на таблиці в базах даних. Crawler-и можуть автоматично обробляти CSV, JSON, Parquet і інші види файлів. Якщо формату, який ви використовуєте, немає, можна написати свою логіку парсингу за допомогою grok-виразів.

Сам же data-каталог додатково зберігає метадані про отриману інформацію як-то версії, шлях до файлів і тощо. Таблиці data-каталогу далі можна використовувати для доступу до даних за допомогою AWS Athena, Redshift та Glue Jobs, використовуючи Glue Context замість стандартного Spark Context.

Проте з таблицями варто бути обережними. Так, навіть якщо ви завантажили дані до S3, таблиця не оновиться поки crawler не обробить дані. Тож важливо коректно налаштувати логіку оновлення — обрати час запуску чи використати івенти.

Розповім на власному досвіді, як ми оптимізували цей процес оновлення та обробки даних.

Спочатку ми використовували для цього S3 notifications та Lambda, яка перевіряла статус crawler-a та запускала його, якщо він ще не був запущений. Але якщо працюєш з великою кількістю файлів, які завантажуються паралельно, це все одно неефективно, — в такому випадку ми маємо запускати crawler багато разів. На щастя, нещодавно AWS запропонувала своє рішення для цього, також використовуючи S3 notifications, але разом з SQS і SNS. Завдяки такому розширенню, файли потрапляють в чергу та вже звідти обробляються crawler-ом. Ми перейшли на це рішення майже одразу після того, як воно стало доступним.

Щодо процесингу даних, то за них відповідають Glue Jobs. Вони можуть бути як чисто Python, так і з Apache Spark. По суті сервіс — це обгортка над spark-ом, яка полегшує інтегрування з сервісами AWS та позбавляє нас необхідності розгортати інфраструктуру самостійно. Але під час роботи з Glue Jobs ми виявили для себе суттєві недоліки:

  • Оновлення Spark-у може зайняти довгий час. У випадку з релізом 3.0, ми чекали пів року, щоб оновитися. Весь цей час ми не могли використовувати нові фічі, виконання скриптів через це було довшим. Відповідно, ми витрачали більше грошей.
  • Обмежена можливість конфігурування кластеру. Деякі параметри можливо передавати через конфігурацію скрипту, але це не ідеальне рішення — ми мали підвищувати обсяг пам’яті (memory limit) для уникнення помилки Out of Memory. Також неможливо ввімкнути, наприклад, Adaptive Query Executor, а, отже, треба чекати нового релізу Spark-у, коли він буде активний за замовчуванням.
  • Для того, щоб бути cloud agnostic, тобто не залежати від хмарного провайдера, необхідно не використовувати GlueContext та інші фічі. Тобто з переваг залишається відсутність менеджменту інфраструктури

Альтернативою Spark-у в Glue може бути використання Kubernetes, але додаються витрати на адміністрування кластеру.

Методом проб і помилок ми знайшли рішення, яке нас задовольнило, та сформували деякі рекомендації по роботі зі Spark-ом, які зможуть вам допомогти зберегти час, гроші та сили:

  • Максимально уникати використання UDF-функцій і, де можливо, застосовувати Spark SQL. Це значно економить час і ресурси, оскільки Spark не оптимізує UDF і не використовує такі методи як проштовхування предикатів (predicate pushdown) і згортка констант (constant folding).
  • Знаходити оптимальну кількість DPU/воркерів для кожної задачі. Це значно оптимізує витрати. Ми використовували розмір датасету як один із параметрів для визначення потрібної кількості. Нещодавно представили AWS Glue Auto Scaling, яке автоматично додає/забирає воркери залежно від запиту. Дуже рекомендую протестувати та використовувати, як тільки фіча вийде з прев’ю.
  • Використовувати Spark UI для аналізу перфомансу скриптів і можливої оптимізації. В AWS можна ввімкнути його для окремої задачі, після чого завантажити файли з S3 і проаналізувати інформацію локально.
  • Пам’ятати про різницю між actions та transformations, та які операції до якої категорії належать. Трансформації виконуються не одразу, а під час виконання action або матеріалізації запиту.

Ми витратили досить багато часу, борючись з недоліками AWS адміністрованого Spark-у, але на початковому етапі він значно прискорив нашу розробку.

Особливості роботи з S3

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

  • Формат зберігання.
  • Life-cycle rules.
  • Метадані.
  • Надання даних.

Формат зберігання важливий не тільки з точки зору оптимізації витрат, але й гнучкості використання. Parquet, про який я згадував у попередній статті, оптимальний завдяки стовпчастому зберіганню даних і можливості застосування різних алгоритмів стиснення/кодування для стовпців. Але це не означає, що потрібно використовувати тільки його. Наприклад, коли ми не зберігали дані довго, а опрацьовували їх і передавали іншим командам, то часто використовували той формат, в якому дані отримали — зазвичай, JSON або CSV. Це пов’язано з тим, що не всі сервіси можуть працювати з parquet-форматом. Як приклад, його складно прочитати за допомогою PHP, тому варто враховувати, в якому вигляді кінцеві споживачі можуть отримати дані та яких витрат зазнає бізнес через подвійне конвертування датасетів.

Загалом, використовуючи Data Lake, отриману інформацію можна розділити на декілька основних типів, орієнтуючись на вимоги до швидкості отримання даних та їхній об’єм — це гарячі, теплі та холодні дані. Об’єм даних збільшується від гарячих до холодних, тоді як необхідна швидкість отримання збільшується від холодних до гарячих даних.

Image source

Гарячі дані повинні надходити якнайшвидше — це, наприклад, отримані в реальному часі дані для побудови прогнозів (real-time prediction) або аналітики. Отримання теплих даних може зайняти трохи більше часу, зазвичай до години. Прикладом можуть бути дані, що необхідні для квартального або річного репорту. Холодні дані — це вже архівна інформація, яку можуть запитати один раз у декілька років — наприклад, інформація, яку необхідно зберігати відповідно до регуляторних вимог.

В архітектурі AWS ці різні типи даних та переміщення між ними можна реалізувати за допомогою S3 Storage Tiers і S3 Life-cycle rules.

Storage tiers дозволяють економити кошти внаслідок більшого часу отримання даних і, подекуди, зберігання даних тільки в одній зоні доступності. Основні класи, які наша команда використовує, — це Standard для гарячих даних із найвищою швидкістю отримання, Infrequent Access для теплих даних і Glacier для архіву холодних даних. Правила переміщення даних із одного класу в інший, зазвичай, залежать від датасету та як він використовується в компанії.

Основне, на що потрібно звернути увагу, це:

  • Life-cycle rules можна використовувати для видалення файлів.
  • Дані, які знаходяться в Glacier/Glacier Deep Archive, не можна зчитувати за допомогою Redshift Spectrum або Athena.
  • Файли, що важать менше ніж 128 кілобайтів, завжди тарифікуються за ціною S3 Standard.
  • Отримання даних із архіву може зайняти до 12 годин. Існують різні типи отримання такої інформації — від найшвидшого до найдовшого, і відповідно, найдорожчого: expedited, standart, bulk. Якщо ж дані знаходяться в Deep Archive, процес отримання може зайняти до 48 годин.
  • Якщо ви не знаєте, який клас вибрати, — є intelligent tier. У ньому необхідний клас обирається на основі інформації про запити до даних. Тож про таку опцію також потрібно пам’ятати.

Взагалі, щодо зберігання даних, дуже важливо трекати інформацію — наприклад, скільки даних ви маєте, як змінюється їхній обсяг, в яких Storage Tiers вони знаходяться тощо. Ми почали з того, що використовували S3 Inventory для того, щоб збирати метадані про наше сховище та об’єкти в ньому. Сервіс збирав такі дані як розмір, версія, дата створення, storage class і інше в CSV-файл. Але оскільки ці файли треба було додатково обробляти та візуалізувати, ми цим сервісом скористалися тільки декілька разів після налаштування. На щастя, через деякий час з’явився S3 Storage Lens, який ми використовуємо й дотепер для отримання потрібної інформації про наші дані.

Image source

Завдяки Storage Lens можна інтерактивно представити інформацію за розміром, кількістю об’єктів, відстежити динаміку змін і які storage classes використовуються. Крім того, сервіс може рекомендувати, як оптимізувати витрати на основі зібраних характеристик.

Головною перевагою для нас є можливість отримати всі ці метрики не тільки на рівні самого S3 bucket, а й на рівні різних префіксів у ньому — в нашому випадку окремий префікс — це окремий датасет. Сервіс оптимально використовувати для всіх рівнів даних, які ми обговорювали в минулій статті, — bronze, silver і gold. Це дозволяє розуміти динаміку та бути впевненим у тому, що сирі дані або ті, які представлялися для кінцевих споживачів (data consumers) видалені, коли вони стали непотрібними. Інформація про запити до даних може бути корисною для того, щоб налаштувати оптимальні life-cycle rules.

Попри те, що S3 — це досить надійне сховище, я не рекомендую зберігати дані лише в одному місці. Необхідно налаштувати кросрегіональну реплікацію в S3 (cross region replication) для критичних даних, що допоможе зберегти інформацію на випадок надзвичайної ситуації.

Як працювати з персональними даними споживачів

Давайте також поглянемо на роботу з персональними даними (personally identifiable information, PII).

При роботі з великими датасетами дуже складно знайти та видалити інформацію про конкретну людину — це може бути пошук одного рядку інформації серед мільярдів інших. Тож для себе ми обрали такий механізм:

  • при завантаженні датасету в Data Lake ми ідентифікуємо чутливі PII-дані;
  • під час переміщення в silver і gold сховище, ці дані анонімізуються за допомогою хешу;
  • лінк між хешем і початковими даними зберігається в базі даних.

Ми маємо окремі таблиці з хешами — це адреси, телефони тощо. При запиті на видалення інформації ми маємо лише видалити цей лінк із потрібної таблиці, без необхідності обробляти великий обсяг даних.

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

Пошук чутливих PII-даних можна автоматизувати за допомогою AWS Macie — сервісу, який буде автоматично сканувати S3 та надсилати алерти в CloudWatch у випадку знаходження таких даних. Сервіс може шукати дані за допомогою машинного навчання, вбудованих правил pattern matching. Крім того, можна створити свій особистий патерн. Якщо ви маєте багато джерел даних, то я рекомендую використовувати Macie.

Для передачі інформації партнерам можна використовувати read-only доступ до золотих даних. Але частіше партнерам потрібен не весь датасет, а поєднання або агрегація датасетів. У своїй практиці ми переважно брали дані з «золотого» сховища, робили необхідні трансформації та завантажували в окремий S3-бакет, звідки партнери їх вивантажували. Доступ потрібно надавати на рівні конкретного префіксу, де префікс — це, наприклад, назва команди чи компанії, яка потребує дані. Загалом, варто дуже добре розмежувати доступ до даних, щоб уникнути випадкового видалення.

Інструменти аналітики

Для аналітики, в основному, ми використовуємо два сервіси: Redshift Spectrum і Athena. Вони обидва можуть зчитувати дані напряму з S3, використовуючи Glue Data Catalog, особливості якого ми вже обговорювали в цьому матеріалі. Всім, хто так чи інакше робив запити до баз даних, буде зручно використовувати ці сервіси, адже синтаксис схожий. Наприклад, Athena використовує Presto SQL. Для цих сервісів також є спеціальні інструменти — коннектори — з таких популярних застосунків для аналітики, як Tableau та Incorta.

В Athena можна розділити права, витрати та налаштування для юзерів за допомогою Workgroups. Для кожної робочої групи можна визначити, які датасети будуть доступні в data-каталозі, скільки даних можна сканувати, обмеження в мегабайтах і витратах на місяць тощо. Якщо ліміти вичерпано, нові запити не будуть виконуватися. Крім того, кожна група ізольована від інших. Так, користувачі бачать тільки ті запити, які збережені чи виконувалися в рамках певної групи. Ми користувалися Workgroups для розділення доступів і витрат між внутрішніми департаментами.

Для себе ми вирішили дати доступ аналітикам до всіх даних у Data Lake, а не тільки до «золотих». Це спрощує процес встановлення вимог для отримання якісніших даних, адже аналітики завжди можуть переглянути початкові дані та надати інформацію про трансформації та поєднання даних, які їм потрібні.

Загалом, це основні сервіси, які ми використовували для побудови Data Lake на AWS. Приблизно через рік після завершення імплементації з’явився AWS Lake Formation — сервіс, який допомагає розгорнути Data Lake швидше та простіше. На практиці він використовує більшість сервісів, які я описав в обох частинах статті. Якщо ви готові миритися з недоліками сервісів, адміністрованих AWS, вам потрібно зробити proof of concept — Lake Formation може бути ідеальним варіантом.

В цій статті є деякі моменти, де я не вдавався дуже в деталі (наприклад, використання Spark UI та оптимізація Spark Jobs), інакше це могло відволікти від загальної архітектури імплементації Data Lake. Якщо вам цікаво дізнатися деталі — пишіть в коментарях і я обов’язково відповім.

P. S. Я дуже рекомендую підписатися на розсилку новин від AWS — так ви не пропустите вихід важливого оновлення або сервісу, який значно полегшить розробку. Також корисними будуть AWS Re:Invent key notes, де зібрана основна інформація з AWS конференцій.

Дякую за увагу!

👍ПодобаєтьсяСподобалось19
До обраногоВ обраному4
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Дякую! Розкажіть будь ласка про ваш досвід оптимізації Spark Jobs

Дякую! Гарна стаття та цікавий досвід.

Підписатись на коментарі