📰 Databricks says it solved the decades-old data pipeline problem that's been slowing AI agents
Десятилетиями дата-инженеры возводили цивилизацию из костылей. Отдельная база для операционных записей (OLTP), отдельное облачное хранилище для аналитики (OLAP), отдельный real-time serving слой, чтобы BI-дашборды не тупили. Между всем этим — ETL-пайплайны, скрипты на Python, горы логов и вечная головная боль со свежестью данных. Архитектура, рождённая в эпоху, когда данные переваривались со скоростью человека.
Затем пришли AI-агенты. Системы, которые не ждут отчёта к пятнице. Им нужна живая, консистентная информация прямо сейчас и возможность писать обратно, не теряя контекст. И тут оказалось, что «десятилетняя проверенная архитектура» — это не надёжность, а хрупкий карточный домик. Потому что агент, который анализирует данные в одной системе, а пишет результат в другую — гарантированно сломается о рассинхронизацию.
И вот на конференции Data + AI Summit компания Databricks делает то, что у неё получается лучше всего — объявляет, что старые правила больше не работают, и предлагает свой молоток. Два анонса под кодовыми именами LTAP и Lakehouse//RT. Звучит как названия космических кораблей. Но на деле — это попытка одним махом разрубить гордиев узел дата-инфраструктуры.
LTAP: Когда HTAP не взлетел
Ещё в 2014 году Gartner придумала аббревиатуру HTAP (Hybrid Transactional/Analytical Processing). Идея была красивой: сделать один движок, который одинаково шустро и записывает транзакции (как база данных магазина), и выполняет сложные аналитические запросы (как Snowflake). Но на практике вышло как с универсальными солдатами — пытались всё, но не преуспели ни в чём. MemSQL (ныне SingleStore), SAP HANA, Oracle HeatWave — все они так или иначе жертвовали производительностью в угоду универсальности.
Databricks идёт с другой стороны и называет подход HTAP «неудачей индустрии». Их ответ — LTAP (Lake Transactional/Analytical Processing). Акцент смещается с универсального движка на унификацию слоя хранения. Раньше Postgres-данные в сервисе Lakebase хранились в родном формате Postgres на объектном хранилище. Когда аналитике надо было их читать — требовалась конвертация. Больно, медленно, дорого.
С LTAP транзакционные данные пишутся сразу в открытый формат — Delta Lake или Apache Iceberg. Физически это одна копия на том же S3-совместимом хранилище. Postgres остаётся движком для операционных запросов (вставка, обновление строк). Spark и Lakehouse — для аналитических (агрегации, JOIN’ы, ML-модели). Но под капотом они работают с одними и теми же файлами. Без ETL-прокладки. Без двойных копий. Без грязных данных, которые разъехались по разным системам.
Главная техническая проблема, которую пришлось решать — латентность. Объектное хранилище (S3, MinIO) выдаёт ответ за секунды. Для OLTP-запросов нужны миллисекунды. Инженеры Databricks добавили кэширующий слой между Postgres-вычислителями и хранилищем. И ключевая фишка: в этом кэше, пока CPU простаивает, строки конвертируются в колоночный формат. Сжатие даёт выигрыш в 10+ раз. Меньше данных — меньше сетевых затрат — быстрее чтение.
Lakehouse//RT: Убить dedicated serving tier
Вторая часть анонса — Lakehouse//RT. Это ответ на вопрос: «Зачем держать отдельную базу данных вроде Redis или ClickHouse, чтобы отдавать данные с низкой задержкой?». Databricks говорит: давайте сделаем так, чтобы живой Lakehouse сам отвечал за 10 миллисекунд.
Для этого они представили новый движок — Reyden....
🔗 Полный текст статьи читайте у нас на сайте: Читать на TechLoot
📢 ТехноЛут
