Data Engineering, ETL и DWH простыми словами

По данным IDC Global DataSphere, к 2028 году объём мировых данных превысит 394 зеттабайта — рост в 10 раз за десять лет. При этом, по оценке Gartner, плохое качество данных обходится организациям в среднем в $12,9 млн убытков ежегодно, а McKinsey фиксирует: data-driven компании получают выручку на 20% выше среднего по рынку. Иными словами, data engineering, etl dwh — это уже не только про IT-отдел, это про деньги. В этой статье разберём, что происходит с данными от источника до дашборда и во сколько это обходится.

Материал для тех, кто «утонул» в разрозненных данных — 1С, CRM, сайт, рекламные кабинеты, таблицы в Excel — и хочет единую аналитику, но не понимает, что для этого нужно инженерно. Никаких академических абстракций: только практика подрядчика, который проектирует и внедряет дата-платформы.

Что такое Data Engineering простыми словами

Data Engineering (инженерия данных) — это дисциплина, которая отвечает за то, чтобы данные из разных источников надёжно и в нужном виде попадали туда, где с ними работают аналитики, менеджеры и BI-системы. Дата-инженер строит «трубы» (пайплайны данных), по которым информация течёт от источника к хранилищу и дальше к витринам и дашбордам.

Главный результат работы дата-инженера — единый источник правды: одно место, где все цифры согласованы, актуальны и проверены. Вместо ситуации, когда у маркетолога одни данные по продажам, у финансиста другие, а у CEO третьи.

Инженер данных vs аналитик vs data scientist — кто за что отвечает

Роль	Что делает	Что использует
Дата-инженер	Строит пайплайны, хранилища, следит за качеством данных	Airflow, dbt, Kafka, ClickHouse, Python
Аналитик данных	Отвечает на бизнес-вопросы, строит отчёты и дашборды	SQL, DataLens, Superset, Excel
Data Scientist	Строит предиктивные модели, ML	Python, scikit-learn, TensorFlow, Spark

Без дата-инженера аналитик и data scientist тратят 80% времени на «сантехнику» — сбор и очистку данных — вместо анализа. Инженер данных убирает эту боль.

Зачем это бизнесу: единый источник правды вместо десятка таблиц

Типичная ситуация среднего бизнеса: отдел продаж работает в amoCRM, склад — в 1С, маркетинг — в Google Sheets, финансы — в своих таблицах, сайт — в GA4. Раз в месяц аналитик тратит неделю на сведение всего этого в одну цифру для CEO. При этом данные расходятся, потому что у каждого своё определение «выручки» и «лида».

Дата-платформа решает эту проблему: данные из всех систем автоматически собираются, нормализуются и попадают в единое хранилище. Отчёт, который раньше занимал неделю, строится за минуты — и у всех одинаковые цифры.

ETL и ELT: как данные попадают в хранилище

ETL и ELT — это паттерны интеграции данных. Они описывают порядок трёх операций: извлечение (Extract), трансформация (Transform) и загрузка (Load).

Extract — Transform — Load по шагам

Extract (извлечение). Данные вытягиваются из источников: REST API CRM, файловый выгруз из 1С, таблица из PostgreSQL боевой базы, лог из Kafka. Важно: забираем данные без изменений — как есть.
Transform (трансформация). Сырые данные очищаются, унифицируются, обогащаются. Приводим форматы дат, убираем дубли, объединяем сущности из разных систем по ключу, считаем производные метрики.
Load (загрузка). Готовые данные попадают в целевое хранилище DWH или витрины данных, откуда их читают BI-инструменты и аналитики.

ETL vs ELT — в чём разница и что выбирать в 2026

Разница одна — где происходит трансформация:

ETL: данные трансформируются на промежуточном сервере (ETL-движке) до загрузки в хранилище. Классический подход, хорош, когда данных немного или хранилище слабое.
ELT: сначала загружаем сырые данные в хранилище (Raw-слой), а трансформации выполняет сама СУБД хранилища. Современный стандарт для облачных колоночных хранилищ (ClickHouse, BigQuery, Snowflake, Greenplum).

Параметр	ETL	ELT
Место трансформации	Отдельный ETL-сервер	Внутри DWH
Скорость при больших объёмах	Узкое место — ETL-сервер	Масштабируется с хранилищем
Стоимость хранилища	Меньше (нет сырых данных)	Больше (хранится Raw)
Прозрачность и аудит	Ниже	Выше (всегда есть сырой слой)
Инструменты	Informatica, SSIS, Airbyte+custom	dbt + Airflow + ClickHouse

В 2026 году ELT — стандарт де-факто для новых проектов. dbt (data build tool) стал инструментом #1 для трансформаций внутри хранилища — он версионирует SQL-трансформации, строит граф зависимостей и документирует модели.

Batch против стриминга (реальное время)

Batch-обработка — данные собираются порциями по расписанию: раз в час, раз в день. Проще, дешевле, подходит для большинства аналитических задач. Инструмент — Apache Airflow (оркестратор DAG-пайплайнов).

Стриминг — данные обрабатываются непрерывно, событие за событием, задержка — секунды или миллисекунды. Нужен для антифрода, real-time дашбордов, реакции на события в момент их возникновения. Инструмент — Apache Kafka + ksqlDB или Flink. Стриминг сложнее и дороже: используйте его только там, где задержка в час критична для бизнеса.

DWH: что такое хранилище данных и зачем оно нужно

DWH (Data Warehouse, хранилище данных) — это специализированная база данных, оптимизированная для аналитических запросов. В отличие от OLTP-базы приложения, которая заточена под быстрые транзакции (добавить заказ, обновить статус), DWH оптимизирован под агрегации по огромным объёмам истории — «продажи по всем регионам за 3 года».

DWH vs обычная база данных приложения

OLTP-база (PostgreSQL в приложении): строчное хранение, оптимизирована под INSERT/UPDATE/SELECT единичных записей. Аналитический запрос на миллионах строк займёт минуты и убьёт производительность для пользователей.
DWH (ClickHouse, Greenplum): колоночное хранение, данные сжаты по столбцам — аналитический запрос на тех же миллионах строк займёт секунды, потому что читается только нужный столбец, а не вся запись целиком.

Именно поэтому нельзя запускать аналитику прямо на боевой базе: вы либо получаете slow query и 504 у пользователей, либо ждёте результат часами. DWH — отдельная система, изолированная от прода.

Data Lake, Data Warehouse, Lakehouse — чем отличаются

Data Lake (озеро данных): хранит всё подряд в сыром виде — структурированные таблицы, JSON, логи, изображения, видео. Дёшево хранить большие объёмы, но без обработки пользы мало — «болото данных».
Data Warehouse (хранилище данных): только очищенные, смоделированные данные, готовые к аналитике. Структура заранее определена схемой. Запросы быстрые, но гибкость ниже.
Lakehouse: гибрид — хранит сырые данные в озере (S3, MinIO), но добавляет транзакционный слой (Apache Iceberg, Delta Lake) и позволяет делать SQL-запросы в стиле DWH прямо по сырым данным. Современный стандарт для крупных платформ.

Для большинства компаний среднего размера достаточно классического DWH — например, ClickHouse или Greenplum. Lakehouse оправдан, когда объём данных исчисляется петабайтами и нужна максимальная гибкость.

Схемы хранения: слои Raw / ODS / DDS / Data Mart (простыми словами)

Современный DWH организован слоями — каждый слой отвечает за свою степень готовности данных:

Raw (сырой слой): данные как есть из источника, без изменений. Архив, который всегда можно перечитать.
ODS (Operational Data Store): данные слегка очищены — убраны технические поля, приведены типы. Строчное представление источников.
DDS (Detail Data Store): нормализованная модель — сущности (клиенты, заказы, продукты) связаны ключами, история изменений хранится по SCD2. Это «единый источник правды».
Data Mart (витрина данных): денормализованные агрегаты под конкретные аналитические задачи — «продажи по менеджерам за месяц». Именно из витрин читают BI-инструменты.

Из чего состоит современный стек данных

Источники → интеграция → хранилище → BI-дашборд (сквозной пример)

Современный стек данных: от источников через ETL к хранилищу и BI-дашборду

Представьте розничную сеть с 50 магазинами. Данные о продажах — в 1С, о клиентах — в amoCRM, о рекламе — в Яндекс Директ и ВКонтакте, о посещаемости сайта — в Яндекс Метрике. CEO хочет видеть: выручку по магазинам в реальном времени, ROMI по рекламным каналам и отток клиентов. Вот как это устроено инженерно:

Источники: 1С (REST + выгрузки), amoCRM (API), Яндекс Директ (API), Метрика (Logs API).
Интеграция: Airflow по расписанию (каждый час) вытягивает данные из источников. Kafka принимает события из кассовых систем в реальном времени.
DWH (ClickHouse): Raw → ODS → DDS (модель: Магазин, Товар, Клиент, Заказ, Рекламная кампания) → витрины.
Трансформации: dbt описывает все преобразования SQL-моделями с тестами качества данных.
BI-слой: Yandex DataLens или Apache Superset читает витрины — CEO видит дашборд с нужными метриками, обновляющийся каждый час без участия аналитика.

Всё это — построение ETL-пайплайнов и хранилища данных под ключ, что мы делаем в YuSMP Group: от аудита источников до запуска BI-дашборда.

Типичные ошибки и как понять, что бизнесу пора строить дата-платформу

Признаки, что «Excel уже не тянет»

Отчёт о продажах за прошлый месяц готовится 3–5 дней.
У разных отделов разные цифры выручки — и никто не знает, чьи правильные.
Аналитик тратит 70% времени на выгрузки и склейку таблиц, а не на анализ.
Нельзя ответить на простой вопрос «какой канал привлечения самый прибыльный» без недельного исследования.
Данные из 1С обновляются раз в неделю вручную, а решения нужны ежедневно.
При попытке автоматизировать отчёт выяснилось, что у каждого источника своё определение «клиента».

Если 3 и более пунктов про вас — дата-платформа окупится за 3–6 месяцев только за счёт экономии времени команды.

5 ошибок внедрения

Нет data-governance. Не описаны правила: кто владелец данных, что считается «клиентом», какие правила дедупликации. Без этого DWH превращается в «золотой мусорник» — красивый, но ненадёжный.
«Сначала витрины — потом источники». Начинают строить красивый дашборд до того, как разобрались с качеством данных в источниках. В итоге дашборд показывает красивые, но неверные цифры.
Недооценка качества данных. В 1С дубли контрагентов, в CRM пустые поля, в рекламных кабинетах разные UTM-метки у одной и той же кампании. Чистка данных занимает 40–60% времени проекта — это нормально, закладывайте бюджет.
Всё в реальном времени. Стриминг данных нужен редко. Для 95% аналитических задач достаточно batch-обновления раз в час. Стриминг в 3–5 раз дороже в разработке и эксплуатации.
Игнорирование исторических данных. «Начнём собирать с сегодня» — через год выяснится, что в 1С и CRM лежат данные за 5 лет, которые можно было загрузить за пару дней и получить тренды и сезонность.

Сколько стоит и сколько длится внедрение

Из чего складывается бюджет (объём источников, историчность, реалтайм, команда)

Стоимость дата-платформы определяют четыре фактора:

Число и сложность источников. Каждый источник — это интеграция: REST API с авторизацией, файловые выгрузки с нестандартными форматами, JDBC-подключение к боевой базе. 3 источника и 20 — принципиально разный объём.
Глубина истории. Загрузить данные за 5 лет из 1С — это ETL на сотни миллионов строк с дедупликацией и преобразованиями. Требует времени и вычислительных ресурсов при начальной загрузке.
Требования к задержке. Batch-обновление раз в час — дёшево. Стриминг с задержкой в секунды — значительно дороже в разработке и инфраструктуре.
Состав команды. Дата-инженер, аналитик, DevOps для настройки инфраструктуры. Аутсорсинг дата-инженерии у подрядчика дешевле собственного найма для большинства компаний среднего размера.

Этапы проекта и ориентировочные сроки

Этап	Содержание	Срок
Аудит источников	Инвентаризация данных, оценка качества, согласование модели DWH	1–2 недели
Пилот (1–2 источника)	Разворачиваем хранилище, подключаем приоритетные источники, первый дашборд	3–4 недели
MVP (основной набор источников)	Подключаем остальные источники, строим DDS-модель, витрины	2–3 месяца
Расширение и тюнинг	Добавляем новые источники, ML-фичи, автоматические алерты по аномалиям	Ongoing

Пилот на 1–2 источника за 3–4 недели позволяет проверить гипотезу и получить первые результаты до полного бюджета. Именно с него мы рекомендуем начинать: запустить первый пайплайн данных, увидеть живые данные в хранилище и убедиться в ценности до крупных вложений.

Часто задаваемые вопросы (FAQ)

Чем ETL отличается от ELT?

ETL трансформирует данные до загрузки в хранилище, ELT грузит сырые данные и трансформирует уже внутри DWH. ELT удобнее для облачных и колоночных хранилищ и больших объёмов — трансформации выполняет сама СУБД, экономя на отдельном ETL-сервере.

Чем DWH отличается от обычной базы данных?

OLTP-база приложения оптимизирована под транзакции (INSERT/UPDATE/SELECT единичных записей). DWH оптимизирован под аналитические запросы по большому объёму исторических данных. Совмещать аналитику и OLTP нельзя — тяжёлые запросы к истории положат боевую базу.

Что такое Data Lake и чем он отличается от DWH?

Data Lake хранит сырые данные любой структуры (JSON, CSV, логи, медиа) без предварительной обработки. DWH хранит очищенные и смоделированные данные, готовые к аналитическим запросам. Lakehouse совмещает оба подхода: хранит сырые данные в озере, но добавляет транзакционный слой и возможность SQL-запросов в стиле DWH.

Нужен ли data engineering малому бизнесу?

Когда данные разбросаны по 1С, CRM, рекламным кабинетам и Excel, а отчёт собирается вручную несколько дней — да. Если всё работает в одной системе и отчёт делается за минуты — пока рано. Пороговый признак: вы тратите больше времени на сбор данных, чем на их анализ.

Сколько стоит построить дата-платформу?

Зависит от числа источников, глубины истории, требований к реальному времени и состава команды. Пилот на 1–2 источника — от нескольких сотен тысяч рублей. Полноценный DWH с оркестрацией — от нескольких миллионов. Точная оценка — только после аудита источников и требований.

Можно ли построить всё на российском и open-source стеке?

Да. PostgreSQL и Greenplum закрывают OLAP-задачи, ClickHouse обеспечивает субсекундные запросы на больших объёмах, Apache Airflow оркестрирует пайплайны, dbt трансформирует данные внутри хранилища, Kafka обеспечивает стриминг. Этот стек полностью покрывает корпоративные требования без иностранных облаков — актуально для импортозамещения.

Слой	Open-source / RU	Облако (зарубежное)
Хранилище (OLAP)	ClickHouse, Greenplum, PostgreSQL	Snowflake, BigQuery, Redshift
Оркестрация	Apache Airflow, Prefect	Databricks Workflows, AWS MWAA
Трансформации	dbt Core (open-source)	dbt Cloud
Стриминг	Apache Kafka, Redpanda	Confluent Cloud, AWS Kinesis
Интеграция источников	Airbyte (self-hosted)	Fivetran, Stitch
BI-слой	DataLens, Superset, Metabase	Tableau, Power BI, Looker

Data Engineering, ETL и DWH: простыми словами для бизнеса

Что такое Data Engineering простыми словами

Инженер данных vs аналитик vs data scientist — кто за что отвечает

Зачем это бизнесу: единый источник правды вместо десятка таблиц