Что такое data lake

Раньше, в эру до 2010 года, мир данных был прост: всё лежало в DWH (data warehouse) — реляционной БД с предопределённой схемой, дорогим железом и строгим ETL. Это работало для финансовых отчётов, но не подходило для логов веб-серверов, IoT-сенсоров, JSON-сообщений из API и тысяч CSV от партнёров.

Появилось концептуальное решение — data lake: огромное хранилище сырых данных любых форматов на дешёвом железе. Туда можно лить всё подряд, не думая о схеме, типах и нормализации. Сначала загружай, потом разбирайся — это и есть schema-on-read в отличие от schema-on-write в DWH.

К 2026 году data lakes — это обязательный компонент в большинстве компаний. Но за дешевизной кроются ловушки: без дисциплины data lake превращается в data swamp — болото, в котором никто не разбирается.

Простое определение

Data lake — это object storage (S3, GCS, Azure Blob) с произвольной структурой папок и файлами в разных форматах. Никаких таблиц, никаких индексов — просто файлы.

Пример структуры:

s3://my-company-lake/
  raw/
    crm/
      customers/
        year=2026/month=05/day=17/customers_2026-05-17.parquet
    web-logs/
      year=2026/month=05/day=17/hour=14/logs.gz
    events/
      year=2026/month=05/day=17/events_batch_001.json
  processed/
    customers_normalized/year=2026/month=05/...
    daily_revenue/year=2026/month=05/...
  ml/
    features/...
    models/...

Никаких баз данных. Просто файлы в “папках” (хотя в object storage папок физически нет — это префиксы).

История: откуда взялся концепт

Концепт data lake популяризировал в 2010 году James Dixon (Pentaho). Он противопоставил его DWH:

Если data mart — это бутылка воды (очищенная, упакованная, готовая к питью), то data lake — это огромное озеро в естественном состоянии: пей сколько хочешь, бери для разных целей, занимайся плаванием.

Технологически data lakes стали возможны благодаря двум вещам:

1. Hadoop / HDFS (2006-2014). Apache Hadoop с распределённой файловой системой HDFS на дешёвых серверах. Можно было хранить петабайты данных не покупая дорогих СХД от EMC и NetApp. Hadoop был первым массовым data lake.

2. Cloud object storage (2006-настоящее). Amazon S3 запустился в 2006 году и предложил безграничное хранение по 2-3 цента за GB в месяц. Постепенно S3 стал главным сabal data lake — дешевле и проще, чем Hadoop в собственном датацентре.

Hadoop на собственном железе — почти legacy в 2026. Облако (S3/GCS/Azure) забрало рынок.

Чем data lake отличается от DWH

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

Главные различия:

• Формат данных: lake принимает всё, DWH — только структурированные таблицы.
• Когда задаётся схема: lake — при чтении (schema-on-read), DWH — при записи (schema-on-write).
• Цена: lake дешевле в 10-20 раз по storage.
• Скорость: DWH быстрее для аналитических запросов (индексы, оптимизация); чтение из lake требует full scan.

Преимущества data lake

1. Дёшево. Хранить сырые логи и события за 10 лет в S3 — реалистично. В Snowflake — разорение.

2. Гибкость форматов. Завтра придёт новый источник в JSON с динамической схемой — никаких миграций, просто загружаешь.

3. Source of truth. Сырые данные в lake — единственный гарантированный источник. Любые processed-таблицы можно пересоздать из raw.

4. ML и аналитика на одних данных. Data Science работают с теми же сырыми файлами, что и DE. Не нужны параллельные пайплайны.

5. Открытые форматы. Parquet, JSON — все могут читать. Нет vendor lock-in: уйти со Snowflake на BigQuery — проблема, поменять движок поверх S3 — обычное дело.

Недостатки и риски

1. Schema-on-read = боль аналитика. В DWH ты получаешь готовую таблицу. В lake ты должен сам определить, что значат поля в JSON, и каждый аналитик может определить по-разному.

2. Производительность чтения. Без индексов запрос “найди продажи в Германии за вчера” сканирует тонну файлов. Партиционирование и колоночные форматы спасают, но всё равно медленнее DWH.

3. Качество данных. В lake падает всё подряд, включая мусор. Без дисциплины это превращается в data swamp — болото, где никто не понимает, что лежит и что чему верить.

4. Метаданные. В DWH есть INFORMATION_SCHEMA, в lake — нет. Нужны отдельные метастораджи (AWS Glue, Hive Metastore) или каталоги (Apache Atlas, DataHub, Amundsen).

Типичная архитектура lake

В корпоративных компаниях data lake обычно делят на три зоны:

• Bronze (raw): сырые файлы в исходном формате. Только append, никогда не удаляем. Это source of truth.
• Silver (cleaned): очищенные, дедуплицированные, в едином формате (Parquet). Обычно колоночные таблицы.
• Gold (curated): агрегаты и витрины для BI и ML.

Эта структура — medallion architecture, популяризованная Databricks. Её адаптируют практически все.

Кто использует data lakes

Практически все крупные компании в 2026 году имеют data lake:

• Netflix — кликстрим, рекомендательные данные в S3.
• Uber — события поездок, телеметрия GPS, ML фичи.
• Airbnb — кликстрим, бронирования, медиа листингов.
• Facebook/Meta — события социальной сети, ML training data.
• Spotify — поведение прослушивания, рекомендации.

Везде паттерн один: сырые данные в lake (S3/GCS), потом ETL/ELT в lakehouse-форматы (Iceberg, Delta) или в DWH (Snowflake, BigQuery) для бизнес-аналитики.

Когда выбирать lake vs DWH

В реальности у большинства компаний есть и то, и другое: lake для сырых данных и ML, DWH для BI. А с появлением lakehouse (см. следующие уроки) граница размывается.

Попробуй сам

Создай бесплатный AWS-аккаунт (или GCP, или Azure). Создай S3 bucket. Загрузи несколько файлов: CSV с заказами, JSON-лог, Parquet-файл. Поэкспериментируй со структурой папок: попробуй партицирование year=2026/month=05/day=17/. Открой AWS CLI и попробуй команды aws s3 ls, aws s3 cp, aws s3 sync. Это даст ощущение, как выглядит data lake изнутри. Через бесплатный Athena ты сможешь делать SQL-запросы прямо к этим файлам — почувствуешь schema-on-read.