Как собрать свой Snowflake на S3 и забыть про медленный Postgres

Представьте ситуацию: ваш проект растет, данных становится всё больше, и привычный Postgres начинает «задыхаться» на аналитических запросах. Вы пытаетесь строить индексы, оптимизировать запросы, но отчеты всё равно грузятся мучительно долго. Обычно в этот момент приходят мысли о переезде на Snowflake или BigQuery, но пугают ценники и сложность миграции. А что, если я скажу, что можно получить мощь аналитического движка, не выходя из экосистемы Postgres и используя обычное S3-хранилище?

Сегодня разберем BemiDB — амбициозный open-source проект, который объединяет в себе возможности ETL-инструментов (вроде Fivetran) и облачных хранилищ данных.

Что это такое и зачем оно разработчику?

Если говорить просто, BemiDB — это аналитическая надстройка, которая умеет забирать данные из разных источников (Postgres, Amplitude, CRM) и складывать их в S3 в сжатом колоночном формате. Но самое интересное не в этом. Снаружи BemiDB выглядит как обычный Postgres. Вы подключаетесь к нему привычным psql, Metabase или любимой ORM, но под капотом работает зверски быстрый движок DuckDB.

Кому это пригодится?

Тем, кто хочет централизовать данные без настройки сложных пайплайнов.
Командам, которым нужно разгрузить основную базу от тяжелых аналитических запросов.
Разработчикам, которые хотят дешево хранить и быстро анализировать исторические данные.

BemiDB

Три кита BemiDB: почему это работает быстро

Разработчики проекта пошли по пути «сборки лучшего из доступного». Архитектура проекта напоминает конструктор из проверенных временем технологий:

DuckDB в качестве Query Engine: Это, пожалуй, лучший встраиваемый движок для OLAP-запросов на сегодня. В тестах TPC-H BemiDB показывает ускорение до 2000 раз по сравнению с обычным Postgres на неиндексированных данных.
Apache Iceberg для хранения: Вместо того чтобы изобретать свой формат файлов, проект использует Iceberg. Это открытый формат таблиц, который позволяет работать с огромными объемами данных в объектных хранилищах (S3, MinIO) так же удобно, как с обычными таблицами.
Колоночное сжатие: Данные хранятся в Parquet. Это дает примерно 4-кратное сжатие по сравнению с сырыми данными, что экономит место и ускоряет чтение.

Architecture

Практика: от слов к делу

Одна из крутых фишек BemiDB — это «Zero-ETL». Вам не нужно писать скрипты на Python или настраивать Airflow, чтобы перелить данные. Всё упаковано в один Docker-образ.

Синхронизация из Postgres

Допустим, у вас есть рабочая база, и вы хотите выгрузить из неё таблицы для аналитики. Достаточно запустить контейнер с нужными переменными окружения:

docker run \
  -e SOURCE_POSTGRES_DATABASE_URL=postgres://user:password@db_host:5432/prod_db \
  -e DESTINATION_SCHEMA_NAME=analytics \
  -e AWS_S3_BUCKET=my-data-lake \
  -e CATALOG_DATABASE_URL=postgres://catalog_user:pass@host:5432/catalog \
  ghcr.io/bemihq/bemidb:latest syncer-postgres

BemiDB сам подтянет схему, создаст файлы в S3 и обновит каталог. Кстати, в качестве S3 можно использовать локальный MinIO, что очень удобно для разработки и тестов.

Запросы через привычный интерфейс

После того как данные синхронизированы, вы запускаете сервер BemiDB:

docker run -p 54321:54321 [env_vars] ghcr.io/bemihq/bemidb:latest server

Теперь можно просто зайти через psql и выполнить тяжелый JOIN по миллионам строк. Для вас это будет выглядеть как обычный SQL, но выполняться он будет со скоростью DuckDB, читая данные напрямую из S3.

Что еще умеет BemiDB?

Проект активно развивается, и список коннекторов постоянно пополняется:

Amplitude: Можно выгружать события инкрементально.
Attio CRM: Полная синхронизация данных о клиентах.
Dialpad: Поддержка real-time событий через NATS JetStream.

Интересно, что разработчики позаботились о совместимости. Проект «из коробки» дружит с Metabase, Grafana, DBeaver и даже dbt. Это значит, что вы можете встроить BemiDB в уже существующий стек визуализации данных без боли.

Личные наблюдения и выводы

BemiDB — это отличный пример того, как современные технологии хранения данных (Iceberg + Parquet) становятся доступными для обычных разработчиков. Вам больше не нужно быть Data-инженером 80-го уровня, чтобы построить эффективное хранилище данных.

Стоит ли пробовать? Если вы устали от того, что аналитика «кладет» вашу основную базу, или если счета за облачные хранилища данных стали неприличными — однозначно да. Проект подкупает своей простотой: один Docker-образ, S3 и знакомый синтаксис Postgres.

Конечно, проект еще молодой (лицензия AGPL-3.0), и в дорожной карте еще много амбициозных задач вроде партиционирования таблиц. Но уже сейчас это крепкое решение для тех, кто хочет получить преимущества Lakehouse-архитектуры без лишней головной боли.

А как вы решаете проблему медленных аналитических запросов? Поделитесь в комментариях!