Датаклассы

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

Зачем?

Датакласс описывает данные, но без кучи лишних методов. Он сам вместо нас добавит __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 не видел =/