Snowflake, Airflow, Kafka: до якого мейнстриму придивитися початківцю в дата-інженерії

Привіт, я Володимир Роман, Lead Data Engineer у львівському офісі DataArt. У дата-інженерію мене занесло сім років тому, коли я, початківець у Java-розробці, несподівано отримав пропозицію зайнятися хайповою тоді Big Data і Hadoop.

Сім років я спостерігав, як змінюються підходи і принципи побудови Data-платформ, як Data Warehouse і Big Data об’єднуються в одну екосистему та переходять у хмари. Зміни супроводжувалися появою нових технологій та зміною лідерів серед них.

На основі особистого досвіду й досвіду колег я постарався зібрати необхідний мінімум мейнстримних технологій, що зарекомендували себе та, найімовірніше, залишаться такими і в 2023 році. Цього набору вистачить, щоб претендувати на посаду Middle Data Engineer.

Стаття розрахована на IT-фахівців рівня middle і вище, що мають загальне уявлення про технології, про які я розповім. Щоб це з’ясувати, раджу спочатку пробігтися назвами розділів.

Кому та коли потрібні дані

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

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

Щоб зрозуміти, скільки чайників закупити, можна подивитися на продаж у такий самий місяць рік тому — можливо, вони продаватимуться приблизно так само. З іншого боку, бізнес зріс, кількість відвідувачів сайту збільшилась, відповідно, покупок теж має бути більше. А якщо ці чайники вийшли з моди і їх не купуватимуть? Зорієнтуватись у тренді допоможе простий графік продажу за останній рік, на кшталт такого:

Далі магазин звертається до даних, пов’язаних з окремими юзерами: аналізує покупки, перегляди товарів та пропонує персональні пропозиції, які їх зацікавлять. Вдалий досвід можна масштабувати — запустити маркетингові кампанії на великі групи клієнтів. В ідеалі магазин знає, кому, коли, на який товар та яку знижку дати, щоб максимізувати прибуток і не займати склад залишками.

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

Поки магазин невеликий, продається 1000 чайників на місяць, менеджер заганяє дані в Excel і добре справляється. Коли організація розростається до мережі магазинів зі складами у різних містах, а крім таблиць із продажами з’являється ще десяток таблиць, які в різних комбінаціях доведеться джойнити для відповіді на бізнес-питання, Excel вже не здається зручною штукою.

Тобто зі зростанням компанії зростають і обсяги даних, плюс з’являються нові типи даних, що допомагають відповісти на дедалі складніші запитання менеджменту. І тоді виникає потреба у розробці дата-платформи.

Що робить дата-інженер і хто може ним стати

Data Platform збирає з різних джерел великі обсяги даних, зазвичай в один централізований Data Store, обробляє їх та надає зручний доступ дата-аналітикам і бізнес-користувачам: C-level або експертам з відділів маркетингу, комерції, фінансів.

За створення дата-платформи та її основних компонентів відповідає дата-інженер. Ключове завдання дата-інженера — надати зручний доступ до даних.

Спрощена структура Data Platform з основними компонентами: Data Store, Data Ingestion і Data Transformations

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

Думаю, на дата-інженера найлегше перекваліфікуватися з Python-розробника рівня middle+, який володіє SQL на хорошому рівні. Розібратися в наведених мною дата-технологіях можна за 3–6 місяців без відриву від фултайму.

Якщо інженер рівня middle+ не володіє Python, але володіє Java, JS, C# тощо, потрібно додатково закласти місяць або трохи більше.

Data Store: Snowflake

Серце дата-платформи — Data Store, місце, де ми зберігаємо дані. Це загальне поняття, під яким маються на увазі:

  • реляційні DBs: PostgreSQL, Oracle, MS SQL;
  • NoSQL DBs: MongoDB, Cassandra, HBase, DynamoDB;
  • розподілені файлові системи (DFS): Hadoop HDFS, Databricks File System тощо;
  • Blob-сховища: S3, GCS, Azure Blob, що використовуються замість DFS у клаудах;
  • Modern Data Warehouse (DWH) DBs: Snowflake, GCP BigQuery, AWS RedShift. Цей клас баз даних призначений для аналітики, що використовується на дата-платформах, які підтримують SQL і розподілені обчислення;
  • формати файлів таблиць: Apache Hudi, Apache Iceberg, Delta Lake.

Найбільш популярними можна назвати два рішення:

1. Blob Store + Snowflake / GCP BigQuery / AWS RedShift.

2. Blob Store / Databricks File System + Apache Hudi / Apache Iceberg / Delta Lake.

Про друге рішення ми ще поговоримо, поки сфокусуємося на першому.

Переваги й популярність modern DWH-рішень пов’язані з такими факторами:

  1. Більшість дата-аналітиків володіють SQL, тому вибір часто падає на бази даних, що максимально нагадують класичні реляційні та на додачу вміють працювати з напівструктурованими (semi-structured) даними. Вони повноцінно підтримують SQL, мають функціонал для роботи з напівструктурованими даними та схожі на класичні реляційні бази даних.
  2. Проблема класичних реляційних баз даних — у складності масштабування. Вони легко масштабуються вертикально (scale-up) — ви просто переносите базу на новий сервер, що має більше дисків, пам’яті та ядер процесора, але з терабайт це дуже дорого. Альтернативний варіант — горизонтальне масштабування (scale-out), коли ми створюємо кластери машин. Modern DWH працюють саме на кластерах і, теоретично, можуть масштабуватися до нескінченності щодо зберігання даних і обчислювальних потужностей. Легко уявити кластер із сотні машин з CPU та RAM для виконання одного SQL-запиту, що обробляє петабайти даних.

З відомого тріо — Snowflake, GCP BigQuery та AWS RedShift — найбільш популярною є Snowflake. До цього, безперечно, доклали руку маркетологи Snowflake, але є й інші причини. Наприклад, Snowflake дуже проста: інтерфейс і підхід до роботи максимально нагадують PostgreSQL, достатньо запустити й відразу почати писати SQL. До того ж Snowflake, порівняно з іншими кластерними рішеннями, дуже швидка шляхом внутрішніх механізмів оптимізації; зазвичай не потрібно власноруч щось конфігурувати для оптимізації SQL-запитів.

Початківцю в дата-інженерії варто розібратися з кількома фічами. Загугліть разом зі словом «Snowflake» наступні терміни: MPP, Columnar Storage, Virtual Warehouse, Micro-partitions, Time Travel, Fail-safe, Clustering, Search Optimization, Pricing Model, кешування, Data Ingestion (Batch і Continuous load) та Stage, Semi-structured Data Load, Table Types, Data Marketplace, Streams і Tasks.

Окремо зазначу вивчення ієрархії ролей у Snowflake, створення користувачів і ролей, надання їм прав. Потім варто розібратися в Object-level, Column-level і Row-level access policies. Data access політики в інших базах даних і сховищах працюють схожим чином.

Хостіть Snowflake на клауді, якому віддаєте перевагу (AWS, GCS, S3). Якщо уподобань немає, можете вибрати AWS, він найпопулярніший із цієї трійки.

У наступному блоці описаний SQL, його можна практикувати у Snowflake. Деякі з описаних там речей недоступні у Snowflake та більше стосуються інших реляційних баз даних, проте є важливими для вивчення.

SQL

Дві найпопулярніші мови в data-світі зараз — Python та SQL. Хоча SQL старий як світ і навколо з’явилися нові підходи до обробки даних, як-от MapReduce і Dataframe, у більшості ситуацій з SQL, як і раніше, зручно працювати.

Рекомендую розібратися з основними фічами: JOINS, UDFs і Procedures, Aggregation і Grouping, Window/analytical functions, DML, DDL, Transactions, View (lateral and materialized), CTE, Triggers, MERGE operator і EXPLAIN operator, Subqueries, Cursor, Changing Data Capture.

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

Раджу ознайомитися з розширеними функціями SQL у Snowflake, зокрема розібратись, як працювати з напівструктурованими даними. Уточню, що напівструктурованими ми називаємо дані без фіксованої структури, де різні записи можуть мати різні набори стовпців. Яскравим прикладом є JSON messages, де набори полів відрізняються. Snowflake має засоби для роботи з JSON messages, вміє обробляти їхні масиви і словники.

Python та бібліотеки

Знати Python потрібно не менше, ніж SQL.

Раджу ознайомитися на базовому рівні з бібліотекою Pandas та її концепцією DataFrames, тому що це одна з альтернатив SQL для обробки даних. Такий самий підхід існує у Spark, але Pandas працює в одному треді, а Spark — на кластері.

Плюсом буде базове знайомство з пакетами Jupiter notebook, Numpy, Matplotlib, Seaborn. Вони допоможуть швидко проаналізувати дані, щоб краще зрозуміти їх.

Jupiter notebook — досить зручна платформа, свого роду альтернатива IDE, використовується у зв’язці з іншими бібліотеками. Numpy — більш низькорівневий і оптимізований варіант Pandas. Matplotlib і Seaborn — основні бібліотеки для малювання графіків у Python.

Blobs і Lambda / Cloud Functions

У дата-платформах зазвичай комбінуються два сховища: Blob Storage (AWS S3, GCP GCS, Azure Blob) і Modern DWH. Можете вибрати для ознайомлення AWS S3 та дослідити його фічі, особливо такі: Storage Classe, Access Policies, CLI Commands, Python API.

Раджу написати просту програму на Python, яка вичитує файл з S3, обробляє його та зберігає в S3. Ще краще створити AWS Lambda Function, яка читає, обробляє і зберігає файл, та викликати її через S3 Trigger, тобто коли в S3 з’явиться файл, запуститься функція для його обробки.

Наступним кроком буде створення SQL-запиту у Snowflake, яка завантажить файл з S3 у Snowflake-таблицю.

Ваш пайплайн виглядатиме так:

Apache Spark

Це основний фреймворк для обробки великих масивів даних у кластерному режимі та одна з найпопулярніших технологій у data-світі. Теоретично здатний обробляти безмежні обсяги даних. Аналогічні технології — Apache Flink та Apache Beam.

Spark може використовуватися для Data Ingestion, а також для Data Transformation, якщо як Data Store виступає Blob Storage, а не modern DWH. Точніше, він може обробляти дані з nodern DWH і записувати в нього назад, але в більшості випадків це не має сенсу.

Spark написаний на Scala, працює на JVM, але має Python API (PySpark), яку я раджу використовувати.

Spark має кілька модулів, раджу почати зі Spark SQL, який оперує з DataFrames. Під капотом Spark — MapReduce-алгоритм для розподілених обчислень.

Список основних фіч, з якими раджу розібратися: Actions і Transformations, Lazy Evaluation, DAG (tasks, stages), RDD Partitioning, Broadcast Variables, Accumulators, Persistence і Caching, Checkpoints, Dataframe vs Dataset vs RDD, Dataframe Operations і Join types, UDF.

Spark RDD API — стара, досить низькорівнева API, яку в нових проектах сенсу використовувати зазвичай немає, але я рекомендую спробувати попрацювати з RDD методами flatMap, reduce, reduceByKey, filter. Вони дають найбільш низькорівневу API для алгоритму MapReduce, якщо не брати до уваги Hadoop MapReduce, та дозволяють на практиці спробувати реалізувати MapReduce-алгоритм.

Спробуйте написати Spark-джоби, які читають дані з різних Data Sources, обробляють їх, об’єднують, фільтрують і зберігають у S3 або інше сховище.

Формати файлів: Parquet, Avro, Delta Lake

Дані з різних джерел часто бувають у форматах JSON і CSV, але зберігати їх на дата-платформах у цих форматах не варто. Якщо ви плануєте запускати обчислення на основі ваших даних (за допомогою Spark SQL або Dataframe), краще вибрати Parquet — колонковий формат, оптимізований під такі навантаження. Якщо S3 використовується як проміжне сховище, можна вибрати Avro, що найкраще підтримує зміну схеми даних.

Раджу познайомитися з цими двома форматами, їхньою внутрішньою структурою, типами стовпців, metadata в Parquet, тим, як вони підтримують зміну схеми і стиснення даних. Спробуйте попрацювати з ними через Spark — завантажити з S3, перетворити та зберегти на S3.

Останнім часом на сцену виходять нові гравці, які розв’язують проблеми, що з’являються при роботі з Parquet: відсутність ACID, time-travel, підтримки DELETE та UPDATE операцій, concurrent read/write. Їх можна назвати Modern Table File Formats (Apache Hudi, Apache Iceberg та Delta Lake). Зазвичай вони базуються на тих самих принципах, що й Parquet, чи безпосередньо використовують його під капотом.

Delta Lake опенсорсний, але розвивається та підтримується комерційною компанією Databricks, яка також розвиває опенсорсний Spark, тому має гарну документацію. Його основний конкурент Iceberg підтримується виключно опенсорсним ком’юніті. Hudi наразі трохи від них відстає.

Отже, крім Parquet і Avro, рекомендую розібратися у внутрішній структурі Delta Lake і попрацювати з ним через Spark.

Оркестратор: Apache Airflow

Написані вами джоби для обробки даних необхідно запускати з певною періодичністю (наприклад, раз на годину) та у певній послідовності. Допустимо, спочатку Spark job завантажує дані з джерела в S3, потім SQL-запит завантажує у Snowflake, далі інші SQL-запити обробляють нові дані та зберігають інші таблиці, з якими працюють дата-аналітики.

Завданням періодичного й послідовного запуску джобів займаються оркестратори — невід’ємна частина Data ingestion і Data Transformation.

Airflow, як і раніше, є одним з найпопулярніших оркестраторів, незважаючи на те, що в нього з’явилися сильні конкуренти, як-от Perfect, або більш спеціалізовані тулзи, що включають оркестрацію, як-от DBT (Data Build Tool). Тому я рекомендую його вивчити.

Як мінімум досліджуйте такі фічі Airflow: DAG, оператори (BashOperator, PythonOperator, Snowflake і Spark related operators), статуси задач, ланцюжок задач із різними умовами, залежності DAGs, Jinja-шаблони для SQL-скриптів, Sensors.

Спробуйте запустити SQLі Spark джоби через Airflow.

Spark Streaming і Kafka

Крім джобів, що запускаються через якийсь період часу (batch jobs), є тип джобів, що працюють безперервно з живим потоком даних (streaming jobs). Потокова обробка дозволяє мінімізувати Latency — час між появою даних у джерелі та доступністю для кінцевих користувачів.

Зазвичай у потокових архітектурах центральним є message broker. Найчастіше це Kafka або аналог, наданий клаудом: AWS Kinesis, GCP PubSub.

Згадані Apache Spark, Apache Flink і Apache Beam підтримують і batch, і streaming режими.

Рекомендую спробувати зв’язку: Kafka як сорс даних + Spark Streaming як консумер (Data Consumer), що обробляє і зберігає дані у S3.

Особливості Spark Streaming, на які варто звернути увагу: Late Arrival Data та Watermarks, Micro-batch vs Real-time streaming, Stateful operations, Windowing і Sliding windows.

Трохи теорії, яку варто знати дата-інженеру

  • Data vs information vs knowledge vs wisdom;
  • Structured, un-structured, semi-structured data;
  • MapReduce algorithm (map and reduce stages, shaffling);
  • ETL vs ELT;
  • OLAP vs OLTP;
  • DWH vs Data Lake;
  • Sensitive data.

Більше теорії для рівня Advanced

  • Data Warehousing concepts and multi-dimensional modeling (Facts and dimensions, Slowly Changed Dimension types, Fact types etc.);
  • DBT (Data Build Tool);
  • Data Management та Governance:
    • Data Governance, Data Management та зв’язок між ними;
    • Data Catalogs (будь-який з: Amundsen, Atlas, DataHub);
    • Data Quality;
    • Data Security;
  • NoSQL (types, CAP, data modeling);
  • Databricks або Dremio Platform;
  • BI Tools: Power BI, Tableau, Superset тощо;
  • Data Mesh.

Сподобалась стаття? Натискай «Подобається» внизу. Це допоможе автору виграти подарунок у програмі #ПишуНаDOU

👍ПодобаєтьсяСподобалось14
До обраногоВ обраному12
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
Наприклад, Snowflake дуже проста

так це ж взагалі S3 bucket SQL надбудова
Клік хаус ще

Багато сучасних рішень для роботи з даними, які орієнтовані на scale-out, є надбудовами над блоб стореджами. І це не дивно, оскільки вони дешеві та надійні. Фактично блоби це клаудна альтернатива HDFS.

Наприклад, Snowflake дуже проста: інтерфейс і підхід до роботи максимально нагадують PostgreSQL, достатньо запустити й відразу почати писати SQL. До того ж Snowflake, порівняно з іншими кластерними рішеннями, дуже швидка шляхом внутрішніх механізмів оптимізації; зазвичай не потрібно власноруч щось конфігурувати для оптимізації SQL-запитів.

А що складного в BigQuery та що там конфiгурувати?

максимально нагадують PostgreSQL

автор не чув про ANSI SQL 92
синтаксис звідки

Власне ви праві, BigQuery та Snowflake концептуально дуже схожі. Тому більшість переваг описаних для Snowflake будуть актуальними і для BigQuery.
Але тут я акцентую саме на Snowflake і його характеристиках, оскільки це рішення більш популярне ніж BigQuery в плані вакансій.
А популярніше скоріше всього через дві причини: агресивний маркетинг Snowflake та те що його можна підняти не тільки на GCP, а на AWS та Azure

Радив би вчити scala замість python. Все-таки більшість серйозних складних дата-інженерних систем пишуть на scala, а не на python. Та і згадані тут фреймворки(спарк, флінк) написані на scala.

Доволі дискусивне питання. Якщо у інженера бекграунд scala чи java, то впринципі можна. Або якщо інженер дуже хоче саме на скалі писати, функціональщина це штука цікава:)
Але у інших випадках, якщо питання стоїть просто стати Дата Інженером, то python все ж кращий варіант, оскільки проектів на ньому значно більше ніж на скалі чи джаві

Проектів дійсно більше на пайтоні, але вони, якщо грубо говорити, — примітивні. Дійсно складні і цікаві речі в дата інженерії пишуть на scala. Та і ЗП scala девів на порядок більша. Ну і знання scala — це ознака високого рівня інтелекту розробника(далеко не кожен зможе опанувати ФП).

scala варто вчити замість java.
python і scala мають різні ніші і не взаємовиключають один одного.

Працював зі Snowflake декілька років. Цікаво, як автор собі уявляє можливість «придивитися». Якщо в AWS можна конкурента сніжинки Redshift спробувати безкоштовно поки діють безкоштовні години або ж принаймні за невеликі гроші (якщо вимикати інстанс коли не потрібен), то не уявляю як з ціллю ознайомлення можна отримати інстанс Snowflake. Можливо, я чогось не знаю.

Snowflake має безкоштовний тріал на місяць

Чудово, ви вмовили цим не займатися)

Щоб свічнутись в дата-інженери перш за все треба навчитись працювати з клаудами хоча б на рівні джуніор девопса та computer science хоча б трохи, бо без даних знань рости далі впринципі тяжко. Потім можна вивчити основи роботи з даними, наприклад глибоко покопатись в спарку, але для цього скалу бажано знати. Я б радив почати з Designing Data-Intensive Applications by Kleppmann та кожен розділ закріплювати практичним вивченням даних техноголій. Решту всього можна підівчити при потребі, дата інженеру не повинно бути різниці на чому писати орекстрації (прагматично їх можна одразу в клаудах писати кількома конфіг файлами і не збільшувати кодбейз в рази, але тут вже залежить від проекту), чи сильно копати в напрямку

DWH vs Data Lake;

якщо вже придумали Lakehouse та за кілька років придумають ще якусь нову архітектуру, підходи і так залишаться старі.

Погоджуюсь що необхідні базові знання клаудів, власне деякі згадані у статті, але все дуже залежить від проекту, композиції команди та стеку який там використовується, на деяких проектах знання клауду взагалі не потрібне. А ось Spark або SQL використовуються майже на всіх проектах.
На рахунок Спарку на скалі — для глибшого розуміння Спарку однозначно круто розібратись, але для початківця який хоче у Дата Інженерію може бути і занадто складно і не дуже практично, бо більшість проектів зараз на PySpark, ну і Python сама ходова мова у Даті, тому практичніше почати з цього.
На рахунок оркестратора — погоджуюсь, що потрібно вміти писати на будь якому, але спочатку потрібно розібратися хоча б що це таке та попрактикуватись хоча б в одному з них.

на деяких проектах знання клауду взагалі не потрібне

такі проекти треба скіпати, ви швидше тоді бекенд-девелопер, що просто пише етл або BI Analyst, а не дата-інженер, не зважаючи на тайтл.

для початківця який хоче у Дата Інженерію

треба попрацювати хоч трохи звичайним девом, в іншому випадку з вас і дата-інженер буде такий собі, і девелопер теж не дуже

Python сама ходова мова у Даті

зате скала більш оплачувана :D

на деяких проектах знання клауду взагалі не потрібне
такі проекти треба скіпати, ви швидше тоді бекенд-девелопер, що просто пише етл або BI Analyst, а не дата-інженер, не зважаючи на тайтл.

Тобто, якщо ваши ЕТЛ деплояться в клауд, то ви дата інженер, а якщо ті ж самі скріпти задеплоять на он-прем, то вже просто бекендер? :)
В чому принципова різниця умовних паркет файлів в он-прем хадуп кластері + стрімінг через кафку, проти тих самих файлів на С3 + стрімінг в кінезіс?

Python сама ходова мова у Даті
зате скала більш оплачувана :D

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

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