История профессии Data Engineer

Чтобы понимать почему мы сейчас работаем с dbt и Snowflake, а не с Informatica и Oracle, полезно знать как мы сюда пришли. История DE — это история того, как объёмы и требования к данным росли, а инфраструктура догоняла.

Прочитав этот урок, ты поймёшь, откуда взялись слова, которые до сих пор крутятся в индустрии: ETL, OLAP, Inmon vs Kimball, Hadoop, Lakehouse.

Карта эволюции

1980-1990: эра DBA

В 1980-х данные жили в одной реляционной базе — Oracle, DB2, Sybase. Эта же база обслуживала и транзакции (заказы, банковские операции), и аналитику (отчёты, дашборды).

Кто занимался данными: DBA (Database Administrator). Его задачи:

• бекапы и восстановление;
• индексы и тюнинг запросов;
• права доступа;
• репликация на standby-сервер.

Не было «пайплайнов» — данные не нужно было «куда-то перемещать». Был один сервер, на нём всё.

Проблема: аналитические запросы (большие агрегации, JOIN на годовых данных) убивали production OLTP-нагрузку. Решение появилось в 1990-х: отдельный сервер для аналитики.

1990-2000: DWH и битва Inmon vs Kimball

В 1992 году Билл Инмон выпустил книгу «Building the Data Warehouse». В 1996 году Ральф Кимбалл — «The Data Warehouse Toolkit». Два подхода к тому, как строить аналитический сервер.

Inmon: Corporate Information Factory (top-down)

Идея: Большой централизованный DWH с нормализованной моделью (3NF). Из него уже строятся data marts под отдельные подразделения.

Плюсы: Единая «правда» в компании. Нет дублирования.

Минусы: Долго, дорого, инфраструктурно. Хорошо для банков, плохо для стартапов.

Kimball: Dimensional Modeling (bottom-up)

Идея: Сразу строим data marts в виде star schema: fact tables (числа, события) + dimension tables (атрибуты).

Плюсы: Быстро, прагматично. Аналитики любят — JOIN’ы просты.

Минусы: Дублирование, нет единой истины (в каждой марте свои справочники).

В реальной жизни выиграл Kimball: star schema — это то, что сейчас строят в Snowflake/BigQuery через dbt. Но Inmon оставил наследство: концепция «единой правды», корпоративный data governance.

Появился ETL

Раз есть DWH отдельно от OLTP-БД, надо туда что-то грузить. Так появились ETL-инструменты:

• Informatica PowerCenter (1993)
• IBM DataStage
• Microsoft SSIS

Они были тяжёлые, дорогие, с графическим UI. Один DE-инженер (тогда его называли «ETL Developer») рисовал пайплайн мышкой.

2005-2015: Big Data и Hadoop

В 2003 году Google опубликовал статью «MapReduce: Simplified Data Processing on Large Clusters». В 2004 году — про GFS (Google File System). Это переопределило индустрию.

В 2006 году Yahoo сделало open-source реализацию: Apache Hadoop (HDFS + MapReduce). Можно стало хранить петабайты на дешёвых серверах и обрабатывать параллельно.

Почему Hadoop взлетел

В 2005-2010 веб-компании (Yahoo, Facebook, Twitter, LinkedIn) уперлись в стену: данных стало слишком много для классических DWH. Один сервер Teradata стоил миллионы и не масштабировался горизонтально. Hadoop разрешил:

• хранить сырые (неструктурированные) данные — логи, JSON, изображения;
• горизонтально масштабироваться добавлением дешёвых серверов;
• использовать дешёвое железо вместо премиум-Oracle.

Hadoop-экосистема

Вокруг HDFS+MapReduce построилась куча инструментов:

• Hive (2010) — SQL поверх MapReduce. Аналитики могли писать запросы.
• HBase — NoSQL поверх HDFS.
• Pig — скриптовый язык для пайплайнов.
• Oozie — оркестратор.
• Sqoop — экспорт из реляционных БД в HDFS.

В этот момент появилась роль Data Engineer в современном понимании. ETL Developer был узким специалистом, DE — широкий: HDFS + Hive + Sqoop + scripting.

Кризис Hadoop (2015-2020)

К 2015 году стало ясно: Hadoop сложный. Кластеры из сотен серверов требовали команды Hadoop-админов. MapReduce — медленный и многословный (написать join — это 200 строк Java). Cloudera, Hortonworks, MapR (большая тройка Hadoop-вендоров) начали умирать.

Спаситель — Apache Spark (2014). Тот же распределённый compute, но в 10-100 раз быстрее, плюс удобный API (Python, Scala). Spark съел MapReduce, и Hadoop-стек сократился до «HDFS + Spark».

2013-2020: Cloud DWH

Параллельно с Hadoop случилось другое: облачные DWH.

• Amazon Redshift (2013) — первый mass-market cloud DWH.
• Google BigQuery (2010 для своих, 2012 для всех) — serverless, петабайтные сканы.
• Snowflake (2014, IPO в 2020) — separation of storage and compute, мульти-облако.

Эти системы заменили и Hadoop, и классические DWH. Они дают:

• бесконечное хранилище (S3-под-капотом);
• compute по требованию (поднимаешь warehouse, считаешь, гасишь);
• SQL-интерфейс;
• работают с петабайтами.

Большинство компаний к 2020 перешло с Hadoop сразу на cloud DWH, минуя Spark. Hadoop остался в банках и телекоме, где on-premise.

2018-now: Modern Data Stack

Когда появились cloud DWH, изменилось всё.

Раньше ETL: трансформируешь данные до загрузки в DWH (потому что DWH дорогой и слабый). Сейчас ELT: грузишь сырые в DWH (storage дешёвый), трансформируешь внутри (compute эластичный).

И появился Modern Data Stack — набор cloud-native инструментов:

Ключевая идея MDS: best-of-breed SaaS-инструменты, склеенные через DWH в центре. Каждый инструмент — лучший в своей категории, но не пытается быть всем.

2022-now: Lakehouse

Последняя глава: попытка объединить гибкость Data Lake (хранение сырых файлов в S3) с производительностью DWH (transactions, schema, fast queries).

Это сделали table formats:

• Apache Iceberg (Netflix, 2018)
• Delta Lake (Databricks, 2019)
• Apache Hudi (Uber, 2017)

Lakehouse хранит данные в Parquet-файлах в S3, но поверх — слой метаданных, который даёт ACID-транзакции, schema evolution, time travel.

В 2024-2026 крупные игроки (Snowflake, Databricks, Google) объявили поддержку Iceberg как «открытого формата». Это намёк, что lakehouse — будущее.

Что будет дальше (прогнозы 2026+)

• Streaming-first архитектуры: Kafka и Flink становятся стандартом, batch отходит.
• LLM в DE: автогенерация SQL, документация моделей, анализ ошибок.
• Data Mesh / Data Products: децентрализация — каждая команда владеет своими данными как продуктом.
• DuckDB-like локальная аналитика: «small data» снова в моде, не всё нужно гнать в Snowflake.

Это уже происходит. Через 5 лет инструменты будут другими, но концепции (ingestion, storage, transform, serving) останутся.

Попробуй сам

1. Найди в Wikipedia статью про «Modern Data Stack» или прочти любую статью на сайте dbt Labs про MDS. Сравни архитектуру MDS со схемой Hadoop из этого урока. Что общее, что разное?
2. Если бы ты сейчас работал DE в банке, который последние 15 лет на Hadoop, — какие технологические выборы у тебя есть? Записать 3 варианта (мигрировать, не мигрировать, гибрид) и плюсы/минусы каждого.