Avro та Protobuf у Data Engineering: схеми для якісних даних

Що відрізняє джуніора від сеньйора? Сеньйор точно знає, скільки компанії коштував його останній факап. Починаємо другий сезон з найболючішого — реальних, дорогих і дуже життєвих помилок в Data Engineering.У цьому випуску ми не шукаємо винних, ми шукаємо дірки в архітектурі. Розбираємо історії, від яких по спині тече холодний піт, і вчимося будувати системи, стійкі до людського фактора.

У цьому випуску ми говоримо про тестування в дата-інжинірингу. Які види тестів варто застосовувати — від unit- і інтеграційних до end-to-end і контрактних. Розбираємо, що саме тестують у світі даних: схеми баз, трансформації, пайплайни, бізнес-правила та якість результатів. Окремо зупиняємось на ролі dbt у тестуванні: вбудовані тести, кастомні перевірки й те, як dbt допомагає зробити контроль якості даних частиною щоденного робочого процесу. Це практичний огляд для інженерів даних, які хочуть будувати більш надійні пайплайни.

Щоб дані залишались узгодженими і зрозумілими, інженери даних використовують спеціальні формати опису схем. У цьому випуску ми розглянемо два найпопулярніших варіанти — Apache Avro та Google Protobuf. Ми пояснимо, як вони працюють, чим відрізняються, які переваги та обмеження мають. Ви дізнаєтесь, чому Avro зручний для schema evolution, а Protobuf — для високошвидкісних систем, і як обрати правильний інструмент для своїх data pipelines.Також не забувайте підписуватись на каналта писати коменти під відео :)

Пояснюємо, що таке Data Quality (якість даних) і як її вимірювати без «води». Розберемо «погані дані» та бізнес-виміри (Descriptive, User-driven), технічні метрики (Availability, Freshness, Uniqueness, Completeness, Schema validity + Consistency), і як оформити це у scorecard з чіткими SLA/SLI/SLO. Покажемо, як вшити тести якості у пайплайни/DAG (дедуп, non-NULL, обсяги, аномалії), налаштувати алерти й observability (метрики, логи, lineage) та використовувати data contracts для стабільних схем. Завершимо практикою: старт з 3 ключових датасетів і 3–5 базових тестів. Підписуйтесь — випуск максимально практичний.

Ми вже говорили про Airflow як приклад оркестратора. У цьому епізоді йдемо ширше й глибше: пояснюємо, що таке data orchestration, навіщо вона потрібна та як виглядає зріла оркестрація поза межами одного інструмента. Розберемо історичні болі cron (залежності, продуктивність, «клейовий» код, data silos), три основні кроки collection → unification → activation, типи платформ (інженерні Airflow/Dagster, модельні dbt, low/no-code), роль DAG (upstream/downstream, без циклів, паралельність). Поговоримо про тригери (time/event/manual), SLA, алерти, retries, idempotency, чеки якості, а також observability (метрики, логи, lineage), вартість і RBAC. Наприкінці — як почати перехід від cron до керованих DAG і вибрати стек під вашу команду.

У цьому епізоді просто й по суті: пояснюємо, що таке query (запит) у СУБД, чітко розводимо DDL vs DML(структура проти даних) і проходимо Query Life Cycle від парсера та оптимізатора до виконання плану зі стадіями wait → read → compute → write. Розберемо ключові команди без коду:— DDL: CREATE, ALTER, DROP, TRUNCATE, RENAME, INDEX;— DML: SELECT, INSERT, UPDATE, DELETE, MERGE.Пояснимо, як думати про партиціювання (PARTITION BY), кластеризацію (CLUSTER BY) і фільтри до JOIN, щоб запити працювали швидше й дешевше. Підписуйтесь, буде практично й без «води».

У 21-му випуску ми покроково проведемо вас крізь процес Dimensional Modeling за методологією Кімбалла. На прикладі компанії з оренди електросамокатів ви дізнаєтеся:Select the business process – чому grain = одна завершена поїздка.Declare the grain – як вибір атомарного рівня деталізації дає гнучкість у запитах.Identify the dimensions – створюємо таблиці Rider (SCD1), City (SCD2) і Vehicle + mini-dimension (SCD4).Identify the facts – які метрики (duration, distance, price, pauses, rating) варто зберігати в fact table.Наприкінці епізоду словесно опишемо, як у BigQuery побудувати датасет, налаштувати партиціювання за датою та кластеризацію за ключами вимірювань для максимальної продуктивності ваших аналітичних запитів.Підпишіться, щоб не пропустити детальні гайди з практичною реалізацією!

У цьому випуску ми просто й зрозуміло розкажемо:OLTP vs OLAP: навіщо потрібні окремі оперативні й аналітичні бази даних.Star Schema by Kimball: як факти (fact table) у центрі та виміри (dimension tables) навколо допомагають робити запити швидко й зрозуміло.Snowflake Schema: коли варто нормалізувати виміри, щоб зекономити місце.Slowly Changing Dimension (SCD): п’ять способів (Type 0–4) зберегти історію змін атрибутів.Після цього епізоду ви знатимете, як правильно спроєктувати модель даних для свого data warehouse. Підпишіться, щоб не пропустити інші корисні випуски!

У цьому випуску — introduction to data modeling для data engineers. Розбираємо три рівні моделювання: conceptual, logical та physical. Пояснюємо, що таке granularity, normalization, primary keys, foreign keys та як усе це допомагає побудувати зрозумілу, масштабовану аналітичну систему.📦 На прикладі продуктової мережі моделюємо процес продажів: від бізнес-процесу до BigQuery-таблиць.Це — основи, без яких неможливо побудувати якісний data warehouse чи data product.👉 У наступному випуску поговоримо про Kimball’s Dimensional ModelingПідпишись, щоб не пропустити продовження!

Цей випуск завершує серію про ingestion-методи. Говоримо про два популярних інструменти з Python-екосистеми — pandas та PySpark.Коли варто використовувати кожен? Як зчитувати, обробляти і завантажувати дані з CSV, BigQuery або DataFrame-структури? Чим відрізняються RDD, DataFrame і Dataset у Spark?Щоб не пропустити нові епізоди — підпишіться на подкаст ✨