С нуля: что такое дата-инжиниринг на самом деле
Дата-инжиниринг — это дисциплина перемещения и преобразования данных от места их создания к месту их анализа. Это карта «с нуля» и восемь слов, которые остальной трек считает уже знакомыми.
Твоё веб-приложение сохранило новый заказ. Строка попала в таблицу Postgres. Где-то бизнес-аналитик ждёт ответа на вопрос «сколько заказов поступило за прошлую неделю по регионам?» — и твоя таблица Postgres ему не поможет. Запусти этот запрос на живой базе — и все пользователи на кассе будут тормозить. Выгрузи данные в таблицу — завтра они устареют. Отдай аналитику сырые логи — и ты купил неделю SQL-археологии. Кто-то должен построить трубы. Этот кто-то — дата-инженер, и этот урок — карта того, что он строит и зачем.
Единственная проблема, которую решает дата-инжиниринг
Каждое продакшен-приложение записывает данные способом, оптимизированным для одного: быстрых, безопасных, построчных записей. Касса сохраняет заказ. Сервис пользователей обновляет профиль. Каждая запись маленькая, мгновенная и не должна падать. Это операционный мир. Аналитикам нужно обратное: читать миллиарды строк, джойнить десять таблиц, агрегировать за месяцы. Запусти такой запрос на операционной базе — и приложение ляжет. Дата-инжиниринг — это дисциплина разделения двух миров: перемещение данных от места производства к месту анализа без вреда для продакшена, с преобразованием по пути, чтобы они были чистыми, согласованными и готовыми.
Всё остальное — механика на службе этого разделения: производи чисто, перемещай надёжно, храни эффективно, запрашивай свободно. Когда видишь команду, добавляющую «вторую базу только для отчётов», — они решают именно эту проблему, иногда удачно, иногда нет.
Восемь слов, которые остальной трек считает знакомыми
Senior-уроки дальше используют эти термины, не останавливаясь на определениях. Вот они, по одному предложению — что это и зачем оно.
| Слово | Что это | Зачем оно |
|---|---|---|
| OLTP | База данных, оптимизированная для быстрых, небольших, конкурентных записей — живое хранилище приложения. | Чтобы кассы, логины и обновления не ждали друг друга. |
| OLAP | Система, оптимизированная для чтения и агрегации огромных объёмов исторических данных. | Чтобы аналитики сканировали миллиарды строк, не нагружая продакшен. |
| Пайплайн данных | Автоматизированная последовательность шагов, перемещающая и преобразующая данные от источника к назначению. | Чтобы перемещение было надёжным и повторяемым, а не разовым скриптом. |
| Batch vs stream | Batch обрабатывает порцию данных по расписанию; stream обрабатывает каждое событие по мере поступления. | Чтобы выбрать между простотой (batch) и свежестью (stream). |
| ETL / ELT | ETL трансформирует данные перед загрузкой; ELT сначала загружает сырые данные, затем трансформирует внутри хранилища. | Чтобы подход соответствовал тому, где вычисления дешевле. |
| Data warehouse | Структурированное хранилище со строгой схемой, созданное для OLAP-запросов (например, Snowflake, BigQuery). | Чтобы аналитики получали быстрые, согласованные ответы из чистых типизированных столбцов. |
| Data lake | Хранилище сырых файлов (S3, GCS), принимающее данные в любом формате — JSON, CSV, Parquet — без предварительной схемы. | Чтобы дёшево принять данные и решить об их форме позже. |
| Партиционирование | Разбиение большого датасета на части по ключу (дата, регион), чтобы запросы сканировали только нужный кусок. | Чтобы запрос «за прошлую неделю» читал 7 партиций, а не три года данных. |
Как они складываются вместе
Прочитанные по порядку, слова рассказывают одну историю: твоё OLTP-приложение (Postgres, MySQL) пишет строки в реальном времени — это источник правды. Пайплайн — запущенный как ночной batch-джоб или stream с задержкой в секунды — извлекает эти строки, применяет ETL или ELT-трансформации (чистит null-ы, джойнит справочники, переименовывает столбцы) и загружает результат в data warehouse или складывает сырые файлы в data lake. Хранилище применяет схему, чтобы аналитики всегда получали типизированные, чистые столбцы, а данные партиционированы по дате, чтобы запрос «за прошлый месяц» никогда не сканировал лишнего. Аналитики затем запускают OLAP-запросы — тяжёлые агрегации, которые убили бы продакшен-базу, — и живое приложение ничего не чувствует.
▸Почему это работает
Почему просто не дать аналитикам доступ к продакшен-базе? Потому что OLAP-запросы — это дорогие полные сканы: один запрос «заказы по регионам за год» может выполняться минутами и блокировать строки. Один медленный аналитический запрос способен подвесить кассу пользователя. Data warehouse существует, чтобы принять эту нагрузку на отдельной системе, а пайплайн — чтобы держать его актуальным. Это не оверинжиниринг: это граница, позволяющая обоим мирам расти независимо.
Это не нужно зубрить
Две честные ремарки перед восхождением. Первая: ты встретишь каждое слово снова, в глубине, в своём юните, и тогда оно уляжется. Эта страница — вешалка, на которую вешать детали, когда они приходят, а не экзамен. Вторая: не каждому проекту нужна каждая деталь. Маленький аналитический пет-проект может быть ночным CSV-экспортом в таблицу. Senior-трек учит полной картине, потому что этого требуют данные в масштабе, — но «начни с batch-джоба и добавляй сложность только когда заболит» и есть senior-инстинкт.
Почему аналитики не могут просто запускать тяжёлые запросы прямо на продакшен OLTP-базе?
Расставь путь от действия пользователя до результата аналитического запроса:
- 1 Действие пользователя записывает строку в OLTP-базу (источник правды)
- 2 Пайплайн извлекает и трансформирует данные (ETL/ELT, batch или stream)
- 3 Трансформированные данные попадают в data warehouse или lake, партиционированные по дате
- 4 Аналитик запускает OLAP-запрос и получает ответ за секунды
- 01В одном дыхании: какую проблему решает дата-инжиниринг и какое ключевое разделение он обеспечивает?
- 02Проследи путь от действия пользователя до результата аналитического запроса, называя каждый концепт.
Дата-инжиниринг — это одна дисциплина, выстроенная вокруг единственного разделения: мир OLTP быстрых операционных записей и мир OLAP тяжёлых аналитических чтений не должны бороться за одну систему. Пайплайны — ночные batch-джобы или near-real-time стримы — перекидывают мост, извлекая данные из источника правды, трансформируя их (ETL чистит перед загрузкой; ELT загружает сырьё и трансформирует внутри хранилища) и доставляя в data warehouse или data lake. Хранилище применяет схему и партиционирует данные, чтобы аналитики получали быстрые, типизированные ответы. Озеро хранит сырые файлы дёшево, когда форма данных ещё неизвестна. Ни один мир не тормозит другой. Тебе не нужно держать все восемь слов сразу — у каждого впереди свой юнит. Теперь, когда услышишь «почему аналитики не могут просто зайти в продакшен-базу?» — у тебя есть готовый ответ: OLTP против OLAP, и полная ментальная модель за ним.
Что-то непонятно?
Задай вопрос по этому уроку. Вопросы анонимны и попадают напрямую автору — урок станет лучше.