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

💡 Усі статті, обговорення, новини для початківців — в одному місці. Приєднуйтесь до Junior спільноти!

Привіт, я Володимир Роман, 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.