Глоссарий — Data Engineering для джунов

Инженер, который проектирует и поддерживает инфраструктуру для сбора, хранения, обработки и доставки данных аналитикам и ML-командам. Отвечает за надёжность пайплайнов, качество данных и SLA. В отличие от аналитика — пишет код продакшен-уровня, в отличие от бэкенд-разработчика — оптимизирует под объёмы и пропускную способность, а не под latency запроса.

Гибридная роль на стыке Data Engineer и Data Analyst. Отвечает за трансформацию сырых данных в моделированные витрины через инструменты вроде dbt. Знает SQL, dimensional modeling и базовый Git/CI, но обычно не строит ingestion-пайплайны от источника.

Extract, Transform, Load — классический подход, при котором данные сначала извлекаются из источника, трансформируются на промежуточном слое (отдельный сервер или Spark-кластер), и только затем загружаются в целевое хранилище. Был стандартом до эпохи дешёвых облачных DWH с гибким scaling.

Extract, Load, Transform — современный подход, при котором сырые данные сначала грузятся в облачное DWH (Snowflake, BigQuery, Redshift), а трансформации выполняются уже внутри хранилища через SQL. Стал доминирующим вместе с modern data stack, потому что разделяет ingestion и transformation и упрощает отладку.

Change Data Capture — техника отслеживания изменений в исходной БД (INSERT/UPDATE/DELETE) и доставки их в DWH или другую систему в почти реальном времени. Реализуется через чтение WAL/binlog (Debezium, Fivetran), триггеры или сравнение снимков. Альтернатива full reload каждую ночь.

Data Warehouse — централизованное хранилище структурированных данных, оптимизированное под аналитические запросы. Содержит исторические снимки бизнес-процессов в виде моделированных витрин (star/snowflake schema). Примеры: Snowflake, BigQuery, Redshift, Teradata, ClickHouse.

Подход, при котором схема валидируется при записи: несоответствие типов или обязательных полей приводит к ошибке загрузки. Стандарт в реляционных DWH. Жёстко, но даёт гарантии целостности данных вниз по pipeline.

Разбиение таблицы на физически отдельные части по значению какого-то поля — обычно по дате (date=2026-05-17). Позволяет читать только релевантные партиции (partition pruning) и быстро удалять старые данные через DROP PARTITION. Критично для производительности на больших таблицах.

Дополнительное к partitioning разбиение данных внутри партиции по hash от ключа на N бакетов. Применяется в Hive/Spark для ускорения joins (bucketed join без shuffle) и для равномерного распределения. Реже встречается в облачных DWH с автоматическим оптимизатором.

Хранилище сырых данных в исходных форматах (CSV, JSON, Parquet, изображения, логи), обычно на объектном хранилище вроде S3 или GCS. Принцип schema-on-read: схема навешивается при чтении, а не при записи. Дёшев, но без дисциплины превращается в data swamp.

Архитектура, объединяющая дешевизну data lake и ACID-гарантии DWH через табличные форматы вроде Iceberg, Delta Lake, Hudi. Позволяет хранить данные на S3 как Parquet-файлы, но работать с ними как с таблицами с транзакциями, time travel и schema enforcement. Продвигается Databricks и open-source комьюнити.

Подход, при котором данные сохраняются в сыром виде (JSON, CSV) без явной схемы, а интерпретация структуры происходит при чтении. Гибко (легко принять новый источник), но рискованно: ошибки схемы вылезают в продакшене у потребителя, а не на ingestion.

Открытый табличный формат для lakehouse, разработанный в Netflix. Добавляет к Parquet-файлам слой метаданных с manifest-файлами и snapshot-историей, что даёт ACID, time travel, schema evolution и hidden partitioning. Поддерживается Snowflake, BigQuery, Databricks, Spark, Trino.

Открытый табличный формат от Databricks для lakehouse, базируется на Parquet и transaction log (_delta_log). Даёт ACID, time travel, schema enforcement, OPTIMIZE/Z-ORDER. Глубоко интегрирован со Spark, поддерживается также в Trino, Athena, Snowflake.

Apache Hudi — табличный формат для lakehouse с фокусом на upserts и CDC-нагрузки. Поддерживает два режима хранения: Copy-on-Write (для read-heavy) и Merge-on-Read (для write-heavy). Активно используется в Uber, изначально оптимизирован под streaming-ingestion.

Техника физической перестановки данных в Delta Lake и Iceberg по нескольким колонкам сразу, чтобы запросы с фильтром по любой из них пропускали много файлов. Использует Z-order curve (space-filling curve) для сохранения локальности по нескольким измерениям. Запускается командой OPTIMIZE.

Объединение множества мелких файлов в один большой в data lake / lakehouse. Решает small files problem: каждый файл — это отдельный seek и метаданные, тысячи мелких файлов убивают производительность чтения. Запускается командой OPTIMIZE в Delta или rewrite_data_files в Iceberg.

Возможность запросить таблицу в её состоянии на момент в прошлом: «SELECT * FROM orders AS OF '2026-05-01'». Поддерживается в Snowflake, BigQuery, Iceberg, Delta Lake, Hudi через хранение snapshot-метаданных. Полезно для отладки, аудита, восстановления после ошибочных UPDATE.

Online Transaction Processing — системы для оперативной обработки транзакций: банковские переводы, заказы в интернет-магазине, регистрация пользователей. Оптимизированы под короткие записи и точечные чтения по primary key. Типичные представители: PostgreSQL, MySQL, Oracle, MS SQL Server.

Online Analytical Processing — системы для аналитических запросов с агрегациями по большим объёмам данных: SUM продаж за квартал, AVG чека по сегментам. Оптимизированы под колоночное хранение и сканирование, а не точечные чтения. Snowflake, BigQuery, ClickHouse, Vertica — типичные OLAP.

Atomicity, Consistency, Isolation, Durability — четыре свойства транзакций в БД. Гарантируют, что транзакция либо целиком применилась, либо целиком откатилась, изолирована от других, и после commit пережила сбой. В DWH-мире классически были в OLTP, теперь приходят в lakehouse через Iceberg/Delta/Hudi.

Сборная архитектура data engineering, доминирующая с ~2020 года: облачное DWH (Snowflake/BigQuery), managed ingestion (Fivetran/Airbyte), трансформации в dbt, оркестрация в Airflow/Dagster, BI поверх (Looker/Tableau/Metabase). Принцип — ELT, SQL-first, managed services вместо self-hosted.

Колоночный бинарный формат хранения данных от Apache, де-факто стандарт в data lakes. Хранит данные по столбцам, что даёт высокий compression ratio и быстрое сканирование при запросе нескольких колонок из таблицы с сотнями полей. Содержит метаданные (min/max, null counts) для predicate pushdown.

Строчный бинарный формат с явной схемой, разработанный Apache. Хранит schema в самом файле, что упрощает schema evolution: добавление новых полей не ломает старых читателей. Часто используется для streaming (Kafka) и хранения сырых событий, где важна целостность одной записи.

Optimized Row Columnar — колоночный формат от Hortonworks, исторически связанный с Hive-экосистемой. По свойствам похож на Parquet: колоночное хранение, статистики, сжатие. Лучше работает в Hadoop-стеке, в облачных DWH чаще встречается Parquet.

Способ хранения, при котором значения одного столбца лежат вместе на диске. Даёт высокое сжатие (одинаковые типы рядом) и быстрое сканирование агрегаций (читаем только нужные столбцы). Используется в Parquet, ORC, Snowflake, BigQuery, ClickHouse. Неэффективно для OLTP-нагрузок с записями по одной строке.

Способ хранения, при котором все поля одной строки лежат рядом на диске. Оптимально для OLTP-нагрузок: вставка одной транзакции — одна запись подряд, чтение по ID — один seek. Используется в PostgreSQL, MySQL и других реляционных OLTP-системах.

Способ моделирования DWH, при котором в центре стоит fact-таблица (события: продажи, клики), а вокруг — dimension-таблицы (продукт, клиент, дата). Все dimensions соединяются напрямую с fact через foreign key. Простая, быстрая, понятная аналитикам — стандарт для BI-витрин.

Развитие star schema, в котором dimension-таблицы нормализованы: например, dim_product ссылается на dim_category. Экономит место, но усложняет запросы (больше joins) и хуже работает на BI-инструментах. Применяется редко, чаще выбирают денормализованную звезду.

Таблица в DWH, хранящая количественные измерения бизнес-событий: продажи, заказы, клики. Содержит foreign keys на dimensions и meassures (numeric поля для агрегаций). Обычно большая (миллионы-миллиарды строк), грузится append-only по batch или streaming.

Таблица в DWH, описывающая сущности, по которым происходит срез фактов: клиент, продукт, регион, дата. Сравнительно небольшая (тысячи-миллионы строк), содержит описательные атрибуты. Изменяется реже, чем fact, но требует продуманной стратегии обновлений (SCD).

Slowly Changing Dimension Type 1 — стратегия обновления dimension, при которой старое значение перезаписывается новым без сохранения истории. Подходит для исправлений опечаток, но теряет информацию о том, что было раньше. Простой UPDATE.

Slowly Changing Dimension Type 2 — стратегия, сохраняющая полную историю изменений через добавление новой строки на каждое изменение с полями valid_from, valid_to и is_current. Позволяет видеть состояние клиента или продукта на момент любой исторической транзакции. Стандарт в DWH.

Slowly Changing Dimension Type 3 — компромисс, при котором в dimension добавляются колонки previous_value и current_value. Хранит только последнее изменение, не полную историю. Применяется редко, когда нужно сравнить «было/стало», но не вся хронология.

Уровень детализации одной строки в fact-таблице: что именно описывает одна запись — одна продажа, один день, одна позиция в чеке. Определение grain — первый и важнейший шаг dimensional modeling. Смешение grain в одной таблице ведёт к двойному счёту в агрегациях.

Искусственный ключ dimension-таблицы, не связанный с бизнес-смыслом — обычно auto-increment или UUID. Используется в SCD2, где natural key (customer_id из источника) перестаёт быть уникальным после исторических снимков. Позволяет fact ссылаться именно на ту версию dimension, которая действовала на момент события.

Естественный ключ сущности из исходной системы: customer_id из CRM, product_sku из товарного каталога. Уникален в источнике, но в DWH с SCD2 одного natural key соответствует несколько строк (история). Поэтому в DWH используется как business key, но не primary key.

Свойство операции, при котором её повторный запуск даёт тот же результат, что и одиночный. Критично для пайплайнов: retry после сбоя не должен задублировать данные. Достигается через MERGE/UPSERT, использование детерминированных ключей, разметку обработанных событий.

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

Обработка данных порциями по расписанию: «раз в час», «раз в сутки», «раз в неделю». Высокий throughput, простая семантика, легко отлаживается и перезапускается. Стандарт для DWH-пайплайнов и аналитических витрин, где latency в часы приемлема.

Метка в streaming-системе, означающая «до этого момента все события уже пришли, можно закрывать window». Нужен для агрегаций по времени, когда события могут опоздать из-за сетевых задержек. Слишком ранний watermark теряет late events, слишком поздний — задерживает результат.

События, пришедшие в систему после ожидаемого окна обработки: продажа из оффлайн-магазина с задержкой синхронизации, мобильный клиент без сети сутки. В streaming требуют политики обработки (drop, update window, side output), в batch — пересчёта затронутых партиций.

Архитектурный паттерн с двумя слоями: batch (полная пересчётка истории) и speed/streaming (быстрые приблизительные результаты), которые объединяются в serving layer. Даёт надёжность batch и low-latency stream, но требует поддерживать две кодовые базы. Сейчас вытесняется Kappa.

Упрощение Lambda, в котором есть только один streaming-слой, а batch — это replay стрима с самого начала. Одна кодовая база, но требует надёжного хранения событий (Kafka с большим retention или event lake). Популярна в командах с сильным streaming-стеком.

Обработка данных по мере их поступления, событие за событием или в микро-батчах. Low latency (секунды-миллисекунды), но сложнее в отладке и backfill. Инструменты: Kafka Streams, Flink, Spark Structured Streaming. Применяется для real-time дашбордов, фрод-детекта, IoT.

Режим Kafka-продюсера, в котором даже при retry сообщение не дублируется: брокер отслеживает sequence numbers от producer-а и отбрасывает дубли. Включается через enable.idempotence=true. Основа для exactly-once semantics в Kafka.

Гарантия доставки в streaming: каждое событие обрабатывается ровно один раз, без потерь и дублей. Дороже at-least-once и at-most-once, требует поддержки на producer, broker и consumer. Достижима в Kafka через idempotent producer и transactional consumer, в Flink через checkpoints.

Распределённый фреймворк для обработки больших объёмов данных в памяти. Поддерживает batch (DataFrame API), streaming (Structured Streaming), SQL, ML. Используется как движок для трансформаций над петабайтными датасетами. Альтернатива Hadoop MapReduce с многократно лучшей производительностью.

Распределённая платформа для потоковой передачи событий, по сути — большой append-only лог с подписчиками. Брокер хранит сообщения по топикам и партициям, продюсеры пишут, консьюмеры читают. Стандарт для event-driven архитектур и streaming pipelines.

data build tool — фреймворк трансформаций для ELT, в котором SQL-модели версионируются в Git и компилируются в DDL/DML для целевого DWH. Поддерживает Jinja-шаблоны, инкрементальные модели, тесты, документацию, lineage. Стандарт modern data stack для Analytics Engineer.

Managed-сервис для ingestion данных из сотен SaaS-источников (Stripe, Salesforce, Postgres CDC) в DWH. Берёт на себя коннекторы, schema evolution, retries, мониторинг. Платный, но снимает необходимость писать свои Python-скрипты на ingestion. Конкурент — Airbyte (open-source).

Open-source альтернатива Fivetran для ingestion из источников в DWH. Поддерживает 300+ коннекторов, можно self-host или использовать managed cloud. Менее зрелый, чем Fivetran, на сложных источниках, но бесплатен и расширяем.

Открытый стандарт описания lineage (происхождения) данных: какая таблица из какой получена, через какой job. Интегрируется с Airflow, dbt, Spark, выгружает события lineage в централизованный backend (Marquez, DataHub, OpenMetadata).

Граф зависимостей данных: откуда взялась каждая колонка, через какие трансформации прошла. Нужен для impact analysis (что сломаем, если изменим источник), отладки, compliance. Строится автоматически в dbt (через ref()) или через OpenLineage / DataHub.

Каталог данных — централизованный реестр всех таблиц, датасетов, dashboards с описанием, owner-ом, tags, lineage. Помогает аналитикам найти нужный датасет и понять, можно ли ему доверять. Примеры: DataHub, OpenMetadata, Amundsen, Alation, Collibra.

Процесс на worker-узле Spark-кластера, выполняющий tasks и хранящий данные в памяти. Каждый executor имеет фиксированное количество CPU cores и memory. Тюнинг количества executors и их размера — типичная задача оптимизации Spark-jobs.

Перераспределение данных между executors в Spark при операциях, требующих сведения данных по ключу: groupBy, join, distinct. Дорогостоящая операция: данные сериализуются, пишутся на диск, передаются по сети. Минимизация shuffle — главная техника оптимизации Spark.

Оптимизация в Spark, при которой маленькая таблица копируется (broadcast) на все executors, и join выполняется локально без shuffle. Применима, когда одна из сторон join умещается в память executor-а (по умолчанию <10MB). Резко ускоряет joins fact с маленькими dimensions.

Оркестратор пайплайнов на Python, в котором workflow описывается как DAG из задач. Запускает задачи по расписанию или триггеру, отслеживает зависимости, делает retry, показывает UI с историей запусков. Стандарт de-facto в data engineering, конкуренты — Dagster, Prefect, Mage.

Directed Acyclic Graph — ориентированный граф без циклов, в Airflow и других оркестраторах описывает зависимости между задачами. Узлы — задачи, рёбра — «выполнить после». Гарантирует, что нет циклов (A зависит от B, B от A), и можно построить детерминированный порядок выполнения.

В Airflow — шаблон для одного типа задачи: PythonOperator выполняет функцию, BashOperator запускает shell-команду, SnowflakeOperator выполняет SQL. Создавая task, ты инстанцируешь оператор с конкретными параметрами. Также есть community-провайдеры с операторами для всех популярных систем.

Особый тип Airflow-оператора, который ждёт наступления события: появление файла в S3, готовности upstream-таблицы, ответа от внешнего API. Может работать в режиме poke (опрос с задержкой) или reschedule (освобождать слот между проверками). Чрезмерное использование poke-сенсоров забивает пул задач.

Минимальная единица работы в Airflow-DAG — инстанс оператора с конкретными параметрами. Каждый запуск DAG создаёт task instances, у каждой есть статус (queued, running, success, failed, retry). Из tasks через `>>` или `set_downstream` строится зависимостный граф.

Облачная DWH-платформа с разделением storage и compute, что позволяет масштабировать их независимо. Поддерживает semi-structured данные (VARIANT), time travel, zero-copy cloning, Snowpark. Биллинг — за секунды работы compute. Один из лидеров modern data stack.

Облачное DWH от Google Cloud, полностью serverless: не управляешь кластерами, платишь либо за просканированные байты, либо за зарезервированные слоты. Хорошо интегрирован с GCS, Looker, Dataflow. Использует колоночное хранение Capacitor и Dremel-движок.

Облачное DWH от AWS, исторически основан на форке PostgreSQL и архитектуре MPP. Имеет варианты Provisioned (фиксированные кластеры) и Serverless. Сильно интегрирован с экосистемой AWS (S3, Glue, IAM). Уступает Snowflake и BigQuery по UX, но привычен AWS-командам.

Платформа на базе Apache Spark и Delta Lake, продвигающая концепцию lakehouse. Объединяет ETL, ML, BI в одной среде на основе ноутбуков и Unity Catalog. Сильна в ML-workloads и обработке неструктурированных данных. Альтернатива Snowflake для команд с тяжёлыми ML и Spark-нагрузками.

Simple Storage Service — объектное хранилище от AWS, де-факто стандарт для data lake. Хранит файлы как объекты в bucket, с дешёвой ценой за гигабайт и бесконечной масштабируемостью. Поддерживает разные классы хранения (Standard, IA, Glacier) для оптимизации стоимости.

Класс систем хранения, в котором данные представлены как объекты в плоском пространстве (bucket), без иерархии файлов. Доступ по HTTP, обычно eventually consistent, дёшев и масштабируем. Примеры: AWS S3, GCS, Azure Blob, MinIO. Основа всех современных data lakes.

Единица вычислительных ресурсов BigQuery, примерно эквивалентна виртуальному CPU. В on-demand модели слоты выделяются автоматически, в reserved — резервируются на месяц/год за фиксированную цену. Тюнинг количества слотов — рычаг оптимизации стоимости.

Compute-кластер в Snowflake, исполняющий запросы. Имеет размер (X-Small, Small, ... 6X-Large), стоит фиксированных credits за час работы, может авто-стопаться и масштабироваться. Не путать с DWH как концепцией — в Snowflake это конкретный compute-кластер.

Open-source фреймворк для тестов качества данных. Позволяет описывать expectations (ожидания) к датасету: «колонка не null», «значение в диапазоне», «уникальность» — и запускать их как unit-тесты в пайплайне. Альтернативы: Soda, dbt tests, Deequ.

Шесть классических измерений качества данных: completeness (нет пропусков), accuracy (соответствие реальности), consistency (согласованность между источниками), timeliness (свежесть), uniqueness (нет дубликатов), validity (соответствие формату/типу). Тестирование DQ обычно покрывает эти оси.

Платформа data observability — мониторинг качества данных в проде: автоматическое обнаружение аномалий (drop in row counts, schema changes), data lineage, оповещения. Категория продуктов называется data observability, конкуренты — Soda, Bigeye, Anomalo, Acceldata.