Databricks Lakebase переосмысляет базы данных OLTP
Пять лет назад компания Databricks ввела термин «озерохранилище данных» (data lakehouse) для описания нового типа архитектуры данных, объединяющей озеро данных (data lake) и хранилище данных (data warehouse). Сегодня этот термин и архитектура данных стали привычными для всей индустрии работы с данными при решении аналитических задач.
Теперь Databricks снова стремится создать новую категорию с помощью своего сервиса Lakebase, который сегодня становится общедоступным. Если концепция lakehouse имеет дело с базами данных OLAP (онлайн-обработка аналитических запросов), то Lakebase полностью ориентирована на OLTP (онлайн-обработка транзакций) и операционные базы данных. Сервис Lakebase находился в разработке с июня 2025 года и основан на технологиях, которые Databricks получила в результате приобретения провайдера базы данных PostgreSQL — компании Neon. В октябре 2025 года он был дополнительно усовершенствован благодаря приобретению Mooncake, что позволило интегрировать PostgreSQL с форматами данных lakehouse.
Lakebase — это бессерверная операционная база данных, представляющая собой принципиальный пересмотр принципов работы баз данных в эпоху автономных ИИ-агентов. Как сообщает Databricks, ранние пользователи, включая easyJet, Hafnia и Warner Music Group, сокращают время поставки приложений на 75–95%, однако более глубокая архитектурная инновация позиционирует базы данных как эфемерную инфраструктуру самообслуживания, которую ИИ-агенты могут развертывать и настраивать без вмешательства человека.
Это не просто еще один управляемый сервис Postgres. Lakebase рассматривает операционные базы данных как легкие, одноразовые вычислительные мощности, работающие поверх хранилища озера данных, а не как монолитные системы, требующие тщательного планирования емкости и контроля со стороны администраторов баз данных (DBA).
«По сути, чтобы тренд на «вайб-кодинг» прижился, нужно, чтобы разработчики верили в возможность очень быстро создавать новые приложения, но также необходимо, чтобы центральная ИТ-команда или администраторы баз данных не боялись цунами приложений и баз данных», — рассказал соучредитель Databricks Рейнольд Син (Reynold Xin) в интервью VentureBeat. — «Классические базы данных просто не масштабируются до такого уровня, поскольку они не могут позволить себе выделить по администратору на каждую базу данных и каждое приложение».
Ускорение поставки на 92%: с двух месяцев до пяти дней
Производственные показатели демонстрируют немедленный эффект, выходящий за рамки концепции автоматизированного развертывания с помощью агентов. По данным Databricks, компания Hafnia сократила время поставки готовых к работе приложений с двух месяцев до пяти дней (на 92%), используя Lakebase в качестве транзакционного движка для своего внутреннего операционного портала. Судоходная компания отказалась от статических BI-отчетов в пользу бизнес-приложений реального времени для работы с флотом, коммерческих и финансовых процессов.
Еще одним примером успеха клиентов, о котором сообщила Databricks, стала компания EasyJet. Она объединила более 100 репозиториев Git всего в два и сократила циклы разработки с девяти месяцев до четырех (на 56%), создав веб-центр управления доходами на базе Lakebase, который пришел на смену устаревшему за десятилетие десктопному приложению и одной из крупнейших в Европе устаревших сред SQL Server.
В Databricks также отметили, что Warner Music Group переносит аналитические инсайты непосредственно в производственные системы с помощью единой платформы, в то время как Quantum Capital Group использует ее для поддержания согласованных, управляемых данных при поиске и оценке инвестиций в нефтегазовую отрасль, исключая дублирование данных, из-за которого командам ранее приходилось хранить несколько копий в разных форматах.
Такое ускорение стало возможным благодаря устранению двух основных «узких мест»: клонирования баз данных для тестовых сред и обслуживания ETL-пайплайнов для синхронизации операционных и аналитических данных.
Техническая архитектура: почему это не просто управляемый Postgres
Традиционные базы данных объединяют хранение и вычисления: организации развертывают экземпляр базы данных с подключенным хранилищем и масштабируют его, добавляя новые экземпляры или дисковое пространство. AWS Aurora внедрила инновацию, разделив эти уровни с помощью проприетарного хранилища, однако оно оставалось запертым внутри экосистемы AWS и не было независимо доступно для аналитики.
Lakebase доводит разделение хранения и вычислений до логического завершения, помещая хранилище непосредственно в озеро данных (lakehouse). Уровень вычислений работает на базе практически стандартной СУБД PostgreSQL, сохраняя полную совместимость с экосистемой Postgres, но каждая операция записи направляется в хранилище lakehouse в форматах, которые Spark, Databricks SQL и другие аналитические движки могут сразу же запрашивать без использования ETL.
«Уникальное техническое понимание заключалось в том, что озера данных отделяют хранение от вычислений, и это было здорово, но нам нужно внедрить в озеро данных возможности управления данными, такие как администрирование и управление транзакциями», — пояснил Син. — «На самом деле мы не сильно отличаемся от концепции lakehouse, но мы строим поверх нее легкие, эфемерные вычисления для OLTP-баз данных».
Databricks создала Lakebase на основе технологий, полученных в результате приобретения Neon. При этом Син подчеркнул, что Databricks существенно расширила первоначальные возможности Neon для создания принципиально нового продукта.
«У них не было корпоративного опыта и масштабов облака», — отметил Син. — «Мы объединили новые архитектурные идеи команды Neon с надежностью инфраструктуры Databricks. В результате мы создали супермасштабируемую платформу».
От сотен баз данных к миллионам, созданным для агентного ИИ
Син обрисовал видение, напрямую связанное с экономикой инструментов ИИ-программирования, которое объясняет, почему концепция Lakebase важна и за пределами текущих сценариев использования. По мере падения затрат на разработку предприятия перейдут от покупки сотен SaaS-приложений к созданию миллионов специализированных внутренних приложений.
«По мере снижения стоимости разработки программного обеспечения, которое мы наблюдаем сегодня благодаря инструментам ИИ-кодинга, фокус сместится с распространения SaaS за последние 10–15 лет на распространение разработки приложений силами самих компаний», — сказал Син. — «Вместо создания сотен приложений со временем они будут строить миллионы специализированных программ».
При традиционных подходах это создает неразрешимую проблему управления парком систем. Невозможно нанять столько администраторов баз данных, чтобы вручную развертывать, отслеживать и устранять неполадки в тысячах баз. Решение Сина: относиться к управлению базами данных как к задаче обработки данных, а не к операционной задаче.
Lakebase хранит всю телеметрию и метаданные — производительность запросов, использование ресурсов, шаблоны подключений, частоту ошибок — непосредственно в lakehouse, где их можно анализировать с помощью стандартных инструментов дата-инженерии и науки о данных. Вместо настройки дашбордов в специализированных инструментах мониторинга баз данных команды дата-специалистов запрашивают данные телеметрии с помощью SQL или анализируют их с помощью моделей машинного обучения для выявления аномалий и прогнозирования проблем.
«Вместо того чтобы создавать дашборд для каждых 50 или 100 баз данных, вы можете просто посмотреть на график, чтобы понять, ведет ли себя какая-то система некорректно», — пояснил Син. — «Управление базами данных будет очень похоже на решение аналитической задачи. Вы ищете отклонения, следите за трендами, пытаетесь понять причины происходящего. Именно так осуществляется управление в масштабе, когда агенты программным путем создают и уничтожают базы данных».
Последствия этого распространяются и на самих автономных агентов. ИИ-агент, столкнувшийся с проблемами производительности, сможет запросить данные телеметрии для диагностики неполадок, рассматривая операции с базами данных как еще одну аналитическую задачу, не требуя при этом специализированных знаний администратора БД. Управление базами данных становится тем, что агенты могут делать самостоятельно, используя те же возможности анализа данных, которыми они уже обладают.
Что это значит для корпоративных команд по работе с данными
Концепция Lakebase сигнализирует о кардинальном изменении того, как предприятия должны воспринимать операционные базы данных — не как хрупкую, тщательно обслуживаемую инфраструктуру, требующую специализированных администраторов, а как эфемерные ресурсы самообслуживания, которые масштабируются программным образом подобно облачным вычислениям.
Это имеет значение независимо от того, материализуются ли автономные агенты так быстро, как прогнозирует Databricks, поскольку лежащий в основе архитектурный принцип — рассмотрение управления базами данных как аналитической, а не операционной задачи — меняет требования к навыкам и структуре корпоративных команд.
Лидерам в сфере данных следует обратить внимание на сближение операционных и аналитических данных, происходящее по всей индустрии. Когда операции записи в операционной базе данных могут немедленно запрашиваться аналитическими движками без ETL, традиционные границы между транзакционными системами и хранилищами данных стираются. Такая унифицированная архитектура снижает операционные издержки на поддержание раздельных систем, но также требует переосмысления структур команд, выстроенных вокруг этих границ.
Когда появилось озерохранилище данных, конкуренты отвергли эту концепцию, но в итоге сами приняли ее. Син ожидает аналогичной траектории и для Lakebase.
«Разделение хранения и вычислений и перенос всего хранения в озеро просто логичны — это открывает столько возможностей и перспектив», — резюмировал он.
