Датаклассы

Наконец-то спустя год дошли руки написать про датаклассы 🌷 Меня спросили на собесе в ламоду, и тогда я про них либо краем уха слышала, либо вообще не слышала. Но точно не использовала. Посмотрим, что с ними можно делать

Зачем?

Датакласс описывает данные, но без кучи лишних методов. Он сам вместо нас добавит __init__, __repr__, __eq__ по дефолту. Набор методов можем сами менять с помощью флагов

Как создать?

Чтобы датаклассы заработали, нужно их импорнуть и добавить в виде аннотации:

from dataclasses import dataclass

@dataclass
class SparkParams:
  """Dataclass для параметров spark-submit команды."""

  name: str
  deploy_mode: str
  driver_cores: int
  driver_memory: str
  executor_cores: int
  executor_memory: str
  num_executors: int

Готово! Никакие методы добавлять не нужно

Как использовать?

spark_params = SparkParams("test_app", "cluster", 2, "4g", 4, "32g", 8)

Другие фишки

Запрещаем менять поля:

@dataclass(frozen=True)

Задаем дефолтные значения:

@dataclass
class Team:
  description: str | None = None
  emails: list[str] = field(default_factory=list)  # для list/dict/set

Чуть подробнее можно прочитать в короткой статье

@data_engineerette

В прошлом году Databricks купил Neon.

Основатели Neon:
• Никита Шамгунов - CEO и идейный вдохновитель Россиянин, PhD по Computer Science из Санкт-Петербурга
• Хейкки Линнакангас - Co-founder, Postgres-хакер
Финн, один из самых известных core committer'ов PostgreSQL с 20+ летним стажем.
• Стас Кельвич - Co-founder, инженер. Изучал физику, затем пришёл в разработку — работал в Яндексе в команде баз данных.

Команда собралась вокруг одной идеи: "что если сделать для Postgres то же, что Amazon Aurora сделала для MySQL/Postgres, но open-source и по-настоящему serverless?"

Amazon Aurora это serverless Postgres, но это как бы vendor lock.

У Neon было три основных этапа/фичи:

1️⃣Разделение слоев давало serverless-поведение: scale-to-zero, оплата только за реальное использование, "бездонное" хранилище.

2️⃣Разделение compute и storage открыло неожиданную суперспособность - branching базы данных через copy-on-write. Создать полную копию базы с данными и схемой стало бесплатным по времени и почти бесплатным по стоимости.

Кстати Snowflake zero-copy cloning имеет похожую идею copy-on-write - клон/ветка не копирует данные физически, а создаёт метаданные-указатели на те же блоки хранилища. Новые данные записываются только при изменениях. Оба мгновенные и почти бесплатные по хранилищу. Только у Neon каждая ветка это свой изолированный Postgres. Благодаря этому у каждой ветки свой compute и не влияет на продакшн базу данных.

3️⃣Neon обнаружил, что 80% баз на их платформе создаются кодом, а не людьми. AI-агенты и платформы вроде Replit Agent стали создавать тысячи эфемерных баз на лету - под каждого пользователя, под каждый эксперимент. Один инженер в Retool управлял через Neon API 300,000 Postgres-инстансов.

Для Databricks это решение понравилось, ведь они уже работаю с AI агентами, каждый агент получает свою изолированную базу данных, и сама идея Zero ETL не нова, и Neon позволяет использовать OLTP workloads и хранить данные сразу в Databricks, ведь Neon хранит данные в облачном object storage (S3/ADLS/GCS), то есть буквально в том же хранилище, что и lakehouse.

И вот Databricks закончил интеграцию и назвал продукт/фичу - Lakebase. Это Postgres версии 16/17. Так же Databricks приобрел Mooncake для лучшей интеграции Postgres с Lakehouse.

Mooncake Labs - это маленький стартап (основан в 2024 году), который сделал одну очень конкретную вещь: ⁠pg_mooncake — Postgres-расширение, которое добавляет колоночное хранилище прямо внутрь Postgres, сохраняя данные в формате Apache Iceberg/Delta Lake в object storage.

Под капотом происходит следующее:
• Данные хранятся не в Postgres heap (row-формат), а в Parquet-файлах в S3 в формате Iceberg
• Аналитические запросы выполняются через DuckDB (встроен в расширение) - векторизованный движок, заточенный под колоночное чтение

Neon дал serverless Postgres compute, но данные в нём хранились в Postgres-формате — отдельно от lakehouse.

Чтобы аналитические движки (Spark, Databricks SQL) могли их читать, нужно было либо копировать данные через ETL, либо держать два источника правды.

Mooncake закрыл этот gap: вместо того чтобы копировать данные из Postgres в lakehouse, он делает Iceberg основным хранилищем. Postgres пишет сразу в Iceberg/Parquet в S3 - и тот же файл без какого-либо ETL читают и приложения через Postgres, и аналитика через Spark.

Есть еще Synced Tables - это отдельный, более старый механизм для обратного направления: когда нужно "опустить" уже готовые аналитические данные из Unity Catalog в Lakebase, чтобы приложение могло читать их с низкой латентностью (< 10 мс) (Reverse ETL). Здесь дублирование данных неизбежно — потому что аналитический Parquet нужно переложить в row-формат Postgres для быстрых point-lookup запросов.


PS Работаю часто с Databricks, пока реальных кейсов на Lakebase Postgres не видел =/

В прошлом году мы добавили в каталог «Если быть точным» новый формат данных — parquet. Подробно рассказываем, как с ним работать

Parquet в 2013 году придумали инженеры Twitter и Cloudera. Теперь им пользуются в Google, Amazon и Netflix. С апреля, кроме привычных csv и xlsx, мы публикуем все наборы данных в этом формате.

Главное преимущество parquet — компактность. Например, датасет по онкологии в csv весит 576 мегабайт. Файл excel c теми же данными — 140 мегабайт, а parquet занимает всего 4 мегабайта.

Формат позволяет не загружать весь файл в память — можно читать только нужные столбцы и строки, в том числе напрямую из облачного хранилища, не скачивая сам файл.

Как работать с parquet — читайте на сайте «Если быть точным» или в нашем новом блоге на Хабре.

◾️ Этот гайд впервые вышел в рассылке «Это не показатель» — присоединяйтесь через Tribute или Boosty.

Российские вендоры данных переходят на Lakehouse. Все. Сразу.

За последний год практически каждый крупный российский вендор аналитических данных либо выпустил, либо анонсировал собственное Lakehouse-решение. И все они сошлись на одном: Apache Iceberg + Parquet + S3-совместимое хранилище.

Если ты до сих пор думаешь, что Lakehouse — это что-то из мира Databricks и Snowflake, не имеющее отношения к российской реальности, — пора обновить картину.

Вот что происходит прямо сейчас:

🤩 Arenadata (ADB + ADH) — крупнейший российский игрок в Hadoop-экосистеме — уже не просто поддерживает Iceberg в ADH, а выстраивает полноценную lakehouse-платформу поверх него. В документации прямо написано: «Lakehouse — универсальная платформа данных, объединяющая мощь DWH и гибкость Data Lake». В составе — Spark, Trino, Impala, Iceberg, Kafka с Iceberg Sink Connector для CDC-пайплайнов. Greenplum (ADB) при этом остаётся как движок для классического DWH-слоя.
🤩 DIS Group / Селена — пожалуй, самый агрессивный новичок. Платформа на базе StarRocks Enterprise (партнёрство с китайским вендором), позиционируется как российское Data Lakehouse-решение нового поколения. Поддержка Parquet, ORC, Iceberg, Paimon. ETL через Trino. Хранение на S3 (MinIO, Ceph). Буквально вчера вышла новость о переходе на коммерческое ядро StarRocks Enterprise.
🤩 Postgres Professional / Tengri Data — концептуально смелый ход. Бизнес вокруг PostgreSQL, запускают аналитическую платформу в парадигме Open Lakehouse. Разделение compute и storage, данные на S3, работа с Iceberg и Parquet. Прямо позиционируют себя как альтернативу Greenplum-решениям, которые «больше не развиваются в рамках open source». DuckLake (новый lakehouse-формат от DuckDB) с Iceberg-совместимостью тоже на радаре — его v1.0 вышла буквально на днях, и он использует PostgreSQL как каталог.
🤩 VK Tech / CedrusData — lakehouse-платформа на базе Trino, Iceberg, Spark, Flink. Собственный каталог метаданных CedrusData Catalog с поддержкой Iceberg REST API. Уже используется в продакшене — например, в S7 Airlines. Развивают крупнейшие русскоязычные комьюнити по Trino и Apache Iceberg. Недавно переписали часть ядра Trino на Rust для производительности.
🤩 Yandex Cloud — собирает lakehouse из управляемых сервисов: Object Storage + Iceberg + Managed Spark + Managed Trino + Airflow + ClickHouse для витрин. Уже рассказывают про это на конференциях как про «инженерный стандарт, обеспечивающий предсказуемость витрин и ML-моделей». Совсем недавно проводили митап по Lakehouse.
🤩 CloudRu (бывший SberCloud) — в платформе Evolution есть Managed Trino, Managed Spark, Managed Metastore и Object Storage. Полный набор для сборки lakehouse-архитектуры в облаке.

Что общего у всех этих решений?

🤩 Данные хранятся в открытом формате — Parquet (реже ORC) в объектном S3-хранилище
🤩 Табличный формат — Apache Iceberg — ACID-транзакции, schema evolution, time travel, партиционирование
🤩 Compute отделён от Storage — можно масштабировать независимо
🤩 Несколько движков на одних данных — Spark для ETL, Trino/StarRocks для интерактивных запросов, DuckDB для локальной аналитики

Это и есть Lakehouse — архитектура, на которую переходят вообще все. Свой лейкхаус строят бигтехи: Авито, Т-Банк, Х5, Тинек, Лемана-Леруа.

Greenplum перестал развиваться в open source. Hadoop в чистом виде уходит. Вендоры перестраиваются — и перестраивают требования к специалистам. Parquet, Iceberg, принципы lakehouse-архитектуры — это уже не опционально. Это базовая грамотность data-инженера в 2026 году. Поэтому выходит что:
🤩 Если ты в облаке - будет менеджед Лейкхаус
🤩 Если ты в онпреме/энтерпрайзе - будет вендорский от одного из рос провайдеров
🤩 Если ты сам по себе крутой бигтех - тоже будет Лейкхаус! свой, родной

Хотите поработать с Trino + Iceberg + S3? Есть курс Алексея Белозерского из VK Tech 🔥«Lakehouse для аналитиков и инженеров данных» — живые онлайн-сессии, Iceberg, Trino, PyIceberg, dbt, Airflow, пайплайны на SQL и Python, практика на реальном стеке. Старт 16 апреля. Подробности → devhands.ru/lakehouse