Всем привет, меня зовут Николай Голов. Всю свою профессиональную жизнь я строю аналитические платформы. Возможно, вы видели мои статьи про Vertica и Snowflake.
В последние годы я в качестве консультанта помогал десяткам организаций выстраивать дата-платформы. И почти всегда наша дискуссия с новой командой начиналась с одного и того же «дня сурка»:
— бизнес: «Аналитики работают слишком медленно!»;
— аналитики: «Нам не дают работать с базой напрямую, заставляют ставить задачи дата-инженерам и ждать неделями!»;
— инженеры: «Да как их пустить в центральное DWH? Вы видели их запросы? Один забытый ON в джойне — и база ложится на бок, блокируя и отчеты для CEO, и критические ETL-процессы».
Этот сюжет я наблюдал везде: в классическом on-premise (Greenplum, Vertica), в модных китайских решениях (StarRocks) и даже в open-source Lakehouse-инсталляциях (Spark). Меня окончательно шокировал кейс одной огромной европейской компании по доставке еды: она сидела на Databricks, имела практически неограниченные ресурсы, но всё равно страдала от взаимных блокировок и конкуренции за ресурсы.
Почему в 2026 году мы всё еще не можем изолировать деятельность одного аналитика от всей остальной компании? Почему индивидуальная ошибка должна вредить коллегам?
В чём корень зла?
Проблема в том, что большинство СУБД по историческим причинам ориентированы на обработку запросов по «единому маршруту», что неизбежно порождает bottlenecks (бутылочные горлышки):
Greenplum (архитектура Shared-Nothing). Любой запрос идёт через ноду-координатор. Даже если у вас сотни сегментов, координатор становится единой точкой отказа и узким местом для метаданных и построения планов. Но хуже другое: тяжёлый запрос на чтение «выжирает» ресурсы (CPU/Interconnect) во всех сегментах сразу, заставляя остальные запросы копиться в очередях.
Vertica. Здесь нет единого координатора, но есть «глобальный каталог». Каждый запрос требует синхронизации узлов по этому каталогу. Стоит одному аналитику запустить «тяжёлую» сессию, и механизмы блокировок (GOS/Ros Pushdown) начинают тормозить работу всего кластера.
Spark и StarRocks. Несмотря на всю свою современность, они часто допускают ситуацию «resource exhaustion». Один некорректный запрос занимает все доступные слоты (executor cores) на узлах, и система просто перестаёт принимать новые задачи.
Конечно, у всех этих баз есть «костыли»: ресурсные группы, пулы, квоты. Но их грамотная настройка требует квалификации DBA уровня «бог», которой в обычных компаниях часто нет. А главное — эти инструменты лишь пытаются ограничить ущерб, но не устраняют саму причину конкуренции за ресурсы.
База мечты для аналитики
Как должна выглядеть база, в которой аналитикам действительно можно дать полную свободу? Представьте: каждый аналитик работает в своей персональной базе данных. Он видит актуальные данные в реальном времени, но физически не делит «железо» с соседом.
Фантастика? Нет, Snowflake первым доказал, что это возможно, внедрив архитектуру Multi-cluster Shared Data:
Storage (S3). Данные лежат отдельно, они дешевые и бесконечные.
Metadata Layer. Единая KV-СУБД хранит транзакции и статистики, отвечая на вопрос «где лежат нужные партиции».
Compute (Virtual Warehouses). И вот тут магия. Это независимые вычислительные узлы, которые стартуют мгновенно, подкачивают только нужные данные из S3 в локальный кэш и гаснут после работы.
Я провёл со Snowflake 6 лет и могу подтвердить: когда ты привыкаешь, что твой коллега может запустить тяжелейший ML-процесс на соседнем складе (Warehouse), а твой BI-дашборд при этом даже не «икнет», — возвращаться к старым архитектурам становится физически больно.
Понимая, что путь Snowflake — единственный способ дать аналитикам настоящую изоляцию, мы в Postgres Professional решили построить свою систему с аналогичной архитектурой, но с учётом всех «болей» и ограничений, которые накопились у пользователей Snowflake за эти годы.
Так появилась Tengri (Tengri Data Platform).
Если смотреть на схему, архитектурно мы очень похожи на Snowflake, но дьявол, как всегда, в деталях. Мы решили убрать «проприетарные стены» и построить систему на открытом стеке.
В чём ключевые отличия от Snowflake?
Открытый формат данных (Apache Iceberg vs Proprietary)
Snowflake хранит данные в своём закрытом бинарном формате. Если вы захотите уйти от них, готовьтесь к долгой и дорогой выгрузке (egress).
В Tengri данные лежат в S3 в открытом формате Apache Iceberg (внутри стандартный Parquet). Это значит, что ваши данные принадлежат вам. Вы можете подключить к ним Spark, Trino или любой другой инструмент напрямую через Tengri или минуя саму СУБД. Никакого vendor lock-in.Эмуляция PostgreSQL
Snowflake имеет свой диалект SQL. Мы же пошли по пути максимальной совместимости. Наш SQL Endpoint эмулирует поведение Postgres. Для любого BI-инструмента или драйвера (ODBC/JDBC) Tengri выглядит как обычный Postgres. Это позволяет бесшовно встроить систему в уже существующую инфраструктуру.On-premise и любое облако
Snowflake — это только публичные облака (AWS/Azure/GCP). Tengri же может жить где угодно: в вашем частном облаке или на голом «железе». Для многих крупных компаний в 2026 году это критическое требование.
Почему Python? (И при чем тут LLM?)
Когда мы начали проектировать систему, перед нами встал выбор: взять готовые опенсорсные компоненты (Trino, Presto, Hive Metastore) и попытаться склеить их «синей изолентой». Но этот путь ведёт в ад: у каждого компонента своё legacy, свои нестыковки и тонны лишнего кода, который в нашей архитектуре просто бесполезен.
Мы решили пойти другим путём — реализовать все «кубики» самостоятельно на Python.
Звучит как безумие для СУБД? На самом деле нет. Современный Python — это не только скрипты, это мощнейшая экосистема библиотек для обработки данных (Apache Arrow, Polars, DuckDB-engine и другие), где вся тяжёлая математика и работа с памятью уже написаны на C++ и Rust.
Выбор Python стал для нас осознанным способом избежать «ловушки legacy»: вместо того чтобы годами адаптировать громоздкие опенсорсные движки с их тоннами лишнего кода и архитектурных наслоений, мы реализовали только необходимые нам функции, опираясь на производительность современных библиотек обработки данных. В этой связке наш многолетний опыт в дата-инженерии и в��зможности LLM сработали в идеальной синергии: нейросети взяли на себя рутинную генерацию кода и типичных структур, позволив нам полностью сфокусироваться на высокоуровневой архитектуре и бесшовной стыковке компонентов. Процесс шёл настолько органично и быстро, что возникало ощущение, будто система сама стремится быть написанной, избавляя нас от борьбы с низкоуровневым «шумом» и позволяя сразу перейти к реализации концепции идеальных сессионных вычислителей.
В итоге мы получили легковесные SQL-вычислители (демоны), которые запускаются за доли секунды, подтягивают нужные данные из Iceberg и возвращают результат, не мешая соседям.
Приведённая диаграмма наглядно иллюстрирует, что дают сессионные вычислители на практике. Мы сравнили Tengri с Cloudberry 1.6.0 (современный форк Greenplum 7 на базе Postgres 14) на стандартном бенчмарке TPC-H (sf=100). Чтобы тест был максимально честным, мы выделили системам сопоставимые ресурсы: 100 vCPU для Tengri против 120 vCPU для Cloudberry. Сразу же предупредим, что данные о производительности были получены в строго контролируемой среде Postgres Professional при моделировании предполагаемых аналитических нагрузок и носят справочный характер. Результаты, полученные в других условиях могут отличаться
Что показывают цифры:
Разница между системами составляет примерно 1.6 раза (496 запросов в час у Tengri против 304 у Cloudberry). Это «базовая» разница в производительности движков, когда им не приходится делить ресурсы с коллегами.
При добавлении пользователей Cloudberry начинает предсказуемо «насыщаться». При переходе с 10 на 20 параллельных потоков его общая производительность вырастает всего на 24%. Это и есть то самое «бутылочное горлышко» архитектуры: запросы начинают нещадно конкурировать за общие ресурсы и блокировки.
Наша система демонстрирует практически линейный рост вплоть до 10 потоков и сохраняет высокую эффективность при 20. Там, где Cloudberry выдаёт 1800 запросов в час, Tengri обрабатывает 7311 — это уже четырёхкратный разрыв.
Каждый новый аналитик в Tengri получает свой изолированный вычислитель, поэтому система эффективно утилизирует доступное железо, а не тратит циклы процессора на ожидание в очередях координатора. Конечно, при дальнейшем росте нагрузки мы тоже упрёмся в физический предел ресурсов, но эту точку «насыщения» в нашей архитектуре можно отодвигать практически бесконечно, просто добавляя новые узлы в кластер.
Если хотите убедиться в приведённых цифрах и технологиях, то документация с примерами доступна по ссылке: https://tengri.postgrespro.ru/documentation/ru/stable/scenarios/
А если вам проще смотреть и слушать, чем читать, вот наш плейлист на «Ютубе»:
https://www.youtube.com/watch?v=aJd9-pxAIPM&list=PLaFqU3KCWw6KOUcoe0AMYDQOmQjgc2sjE
PS. Буду рад ответить на возникающие вопросы.
PPS. Мы открыты для пилотирования, в публичных облаках, или на вашем «железе».