Databricks объявил конец эпохи пайплайнов.

На Data + AI Summit 2026 компания представила новую архитектуру LTAP (Lake Transactional/Analytical Processing), которая должна объединить транзакционные системы, аналитику, стриминг и AI на одной копии данных. Идея радикальная: приложения, BI-системы и AI-агенты работают с одним источником данных напрямую, без CDC, ETL и бесконечных репликаций между OLTP и аналитическими хранилищами.

Последние двадцать лет типичная архитектура выглядела примерно так:

PostgreSQL → CDC → Kafka → ETL → Data Warehouse → BI → AI

Каждый новый слой добавлял задержки, повышал стоимость владения и создавал новые точки отказа. Особенно болезненно это стало с появлением AI-агентов, которым нужны актуальные данные в реальном времени, а не копия пятиминутной давности.

Ответ Databricks — хранить операционные и аналитические данные в одном месте. В основе подхода лежит Lakebase, PostgreSQL-совместимая система, работающая поверх объектного хранилища и интегрированная с Lakehouse. Компания называет это первым LTAP-подходом, который должен заменить как традиционные ETL-процессы, так и многочисленные реплики баз данных.

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

Но сам тренд выглядит очень интересным. Если раньше индустрия спорила, что лучше — Data Lake или Data Warehouse, то теперь главный вопрос звучит иначе:

Нужно ли вообще перемещать данные между системами, если все сервисы, аналитика и AI могут работать поверх одной копии данных?

Похоже, именно вокруг этого вопроса и будет строиться следующая большая битва в мире Data Engineering.

@tldr_data

Я наконец нашла время прочитать новую версию законопроекта про ИИ. Его разослали по всем ФОИВам, в ГосДуму, некоторые партии и т.п. Ну, и естественно, как-то документ попал в прессу. Для желающих изучить — прилагаю.

Я споткнулась сразу же на определении большой фундаментальной модели ИИ. Вот оно:

«..большая фундаментальная модель искусственного интеллекта — программа для электронных вычислительных машин (их составных частей), предназначенная для выполнения интеллектуальных задач на уровне, сопоставимом с результатами интеллектуальной деятельности человека или превосходящем их, использующая алгоритмы и обучающаяся (ранее обученная) на наборах данных для выведения (распознавания) закономерностей, предоставления информации, принятия решений или прогнозирования результатов по заданным человеком целям, одновременно являющаяся основой для создания и доработки различных видов программного обеспечения, содержащая не менее 1 миллиарда параметров и применяемая для выполнения большого количества различных задач».

Данное определение прекрасно своей широтой. Например, под него полностью подходит определение программного обеспечения Microsoft Excel.  Это программа для ЭВМ, решает сложные интеллектуальные задачи на уровне человека или круче (например, столбцы чисел любой длины складывает моментально), использует алгоритмы, обучается на наборах данных, которые туда вводит пользователь.

Эта программа, безусловно, используется для выведения закономерностей, принятия решений или прогнозирования результатов по заданным человеком целям. Она является основой для создания и доработки различных видов ПО — куча ПО действительно пишется с использованием Excel. В одном листе таблицы может быть до 17 миллиардов ячеек. Если каждую ячейку взять, как параметр (а определение, что такое параметр, в законопроекте отсутствует), то все — мы получили пример Большой Фундаментальной модели.

Неточность определения термина дает возможности по его широкому трактованию. Что, может быть, и неплохо, так как власти грозятся ввести КПЭ по внедрению ИИ региональным органам исполнительной власти и прочим госучреждениям. Но при таком определении можно взять Excel. или аналог и заявить — вот, мол, внедрили то, что полностью соответствует определению, на все наши компьютеры в организации — КПЭ выполнен на 100%!

ИИшные будни и полный пятничный сумбур

Сегодня подводили итоги квартала и все команды дата офиса сейчас пишут контекст для своих помощников. И вот нонсенс - чем лучше ваша слоенная архитектура и чем больше у нее документации, тем сложнее ее запихать в RAG и тем хуже на ней работают модели. Спасибо умным людям (привет, Венера), которые начали подробно описывать метрики в компании в маркдауне в репке dbt еще в 22 году - это самый простой и потрясающий буст по контексту для простых потребителей. Но вернемся к тому, почему вроде работали,а получилась шляпа. Самый простой способ убедиться в этом без построениях всяких специальных рагов - поставить nao.

Кто не слышал про эту штуку (как я, например, и спасибо большое просвещающим коллегам) - это по сути самая простая обертка для агента, нацеленная на работу с dwh. С одной стороны вы подключаете любую модель (Claude, ChatGPT, локальные модели), с другой стороны у вас веб чат с аутентификацией и авторизацией, а посередине репа с текстовыми файлами контекста. На первом запуске, когда мы подключили локальную модельку я был в диком восторге - ответ получил за секунды и вроде похож на верный. Правда на следующий день мы выяснили, что он был полностью выдуманным и ни один запрос в бд не был сделан :) Но в общем и целом после тюнинга получается достаточно удобно.

Так вот, в эту репку можно прямо ссылкой отгрузить dbt проект. Плюс еще сам nao собирает мету со всех подключенных бд на этапе init. И потом с этой горой информационного мусоры мы пытаемся взлететь, а размер контекста у локальных моделей сильно отстает от лидеров рынка - будет сплошной мусор.

Решить этой штукой мне хотелось вечную боль команд данных - выгрузки. И все бы ничего, но в коробке такого функционала нет :) Отвечать на вопросы с цифрами может, графики рисовать умеет, но csv выплюнуть - не сделали. У нас в планах на следующий квартал реализовать и пушнуть в апстрим. Еще коллега впрягся и добавил туда поддержку StarRocks :)

А что по остальным командам? BI и их ужасные системы из большой тройки. Самая большая проблема там - найти интересующую тебя информацию. Даже если приложение имеет описание, надо его еще найти, посмотреть есть ли там нужные разрезы и метрики. Решение - RAG. Чуете чем пахнет? Дата говернансом, дада, тем самым. Когда-то внедряли каталоги данных за миллион денег, которые сами по себе не могут решить никаких проблем. Так вот описание нужно, а каталоги - нет. И сам по себе офис данных сейчас по сути становится держателем контекста информации всей компании, мне так кажется.

Доли LLM, свежий график

Рекрутеры много говорят о том, что соискатели должны быть честными. Но честны ли при этом сами рекрутеры?
🧨кандидаты должны строго откликаться на вакансии точечно, только на то, что соответствует их профилю, пока HR пишут непонятные описания вакансий с непрозрачными целями и задачами
🧨вы должны выкладывать честное резюме, пока нанимающие могут указывать описание и требования, которые не соответствуют реальной работе
🧨соискатель должен внимательно изучать вакансию и выяснить, действительно ли требуется именно он, хотя его резюме с большой долей вероятности отбракует автофильтр. По причинам, которые неизвестны даже рекрутерам
🧨резюме соискателя должно отражать след его личности, которую рекрутер оценит за 30 секунд, а то и за 7. Вместе с сопроводительным
🧨соискателям нельзя использовать ИИ, чтобы адаптировать резюме, написать сопроводительное или откликнуться на сотню вакансий одним кликом, хотя поиск работы не является работой. В то же время HR пишет описание, отсеивает и сортирует резюме с помощью нейросетей. Ведь это его работа, ему можно, не перепутайте
🧨у соискателя не должно быть перерывов в опыте, но искать работу, когда вы уже трудитесь в компании с HR - тоже харам и табу, фу такими быть
🧨и одновременно рекрутеры ищут в первую очередь тех, кто уже работает, дискриминируя тех, кто честно ушёл "в никуда"
🧨при этом соискателям нельзя быть меркантильными, менять работу просто ради прибавки в зарплате. Пока компании с лёгкостью будут увольнять сотни и тысячи сотрудников просто потому, что бизнес вдруг начал получать меньше, чем раньше
🧨нанимают за вайбик, хотя требуют харды с софтами
🧨вам будут говорить качать навыки, но лучше всего работают self-sell навыки
🧨зарплатную вилку кандидату никто не озвучит, но от соискателя требуется назвать точные зарплатные ожидания. Чаще всего даже без чёткого описания вакансии и задач
🧨соискателям лучше ни за что и никогда не опаздывать на собеседования даже на 3 минуты. Рекрутерам же заставлять своего собеседника сидеть в ожидании "а чё такого?"
🧨кандидатам строго запрещается сливать информацию о вопросах, заданиях и последовательности собеседований наружу. Хотя считается совершенно нормальным для компании собирать информацию, рекомендации и прочие личные данные, в том числе - в неофициальных чятиках или общении с прочими рекрутерами
🧨кандидат не должен игнорировать запросы HR или пропадать на долгий срок, особенно на поздних этапах. И "Мы вам перезвоним"
🧨на своих курсах они по поиску работы в итоге они предлагают примерно то же, что и "волки": подкручивать резюме, закрывать паузы между работами, пририсовывать опыт. Да, официально это всё нельзя и фу-фу-фу
🧨в итоге вот уже 50 лет рекрутеры нанимают с уровнем ошибок в 40-60%, но проблемы именно у тех людей, кто пытается быть честным во всём этом бардаке
🧨а ещё враг - любой человек, кто посмел с аргументами выступить, что систему найма надо менять. А не те, кто консервирует эти порочные и вредные практики.

Нынешний рекрутинг сломан, и починить его "послушным и честным поведением" соискателей невозможно. Систему заставить меняться только массовый саботаж старых догм и максимальная популяризация аргументов, почему прежний порядок настолько порочен.
Честность вернётся только тогда, когда она станет выгодна обеим сторонам. А пока - качайте self-sell навыки.

Ретробес и мракоград

Вся IT-тусовка жужжит на тему увольнений из-за AI. А вы когда-нибудь видели как это реально происходит? Как вы себе это представляете? Типа... компания купила подписку на Claude, он за пару недель решил 100500 задач, лежащих в бэклоге, разрулил техдолг, наколбасил фич и починил застарелые баги, поэтому половина команды оказалась не нужна, да?

Ага, щаз! Несу вам в клювике 2 кейса как людей реально уволили из-за AI. Видел своими глазами, peer review по знакомым подтвердил что такое происходит во многих компаниях. Слушайте внимательно.

Кейс первый: к команде разработки пришёл доморощенный AI-тренер. Начал рассказывать про промпты, агентов, скиллы, APM, MCP и прочую чушь. Естественно, быстро всплыло что Claude работает через grep файлов. Умудрённый опытом senior-разработчик слышит это и задаёт закономерный скептичный вопрос: мол, а как эта штука будет лазить по нашему проекту, в котором 300 тысяч строк кода? Он же все файлы прогрепать и прочесть не может — context window лопнет, миллиарды токенов сгорят. Наверное, это не самый лучший путь? Команда вроде соглашается, принимается решение сделать MCP для кода, гуляющий по AST. Ставится задача в трекер, senior приступает к экспериментам. Через пару дней прибегает AI-тренер, смотрит на промежуточные результаты и нервно выдаёт "ой блин, херня какая, это всё не нужно, Claude умный, сам справится, отменяйте эту задачу на фиг". Senior в лёгком ахуе из-за такого нарушения субординации, о чём вежливо сообщает AI-тренеру. Мол, команда решила сделать так, тимлид подтвердил, стало быть делаем.

А потом senior-разработчика вызывают на ковёр к директору и вежливо сообщают, что своим AI-скептицизмом он что-то дофига личных конфликтов порождает. Демотивирует остальную команду, экзальтированную LLMками. Ретробес и мракоград эдакий. А конфликты — это плохо, поэтому давайте-ка на этом завершим сотрудничество. Senior недоумевает, но подумав соглашается на выходное пособие и в приватном разговоре признаётся что с такими клиническим идиотами, игнорирующими законы физики, сам работать не желает.

Кейс второй: жил-был devops. Заведовал тестовой инфраструктурой для большого продукта: тест-контейнеры, деплой системы через k3s, запуск WebAPI-тестов, сбор логов, подсчёт coverage. В его ведении был Terraform, посыпанный тонной yml-ей и сдобренный Ansible. Он честно строил chain of quality gates, который реально работал.

А тут вдруг начальство посылает к нему разработчика из AI-inspired команды с Claude наперевес. И этот кадр начинает с помощью AI ломать и переколбашивать всю существующую инфраструктуру. У devops-а волосы встают дыбом от такого поворота событий. Пайплайны, и без того иногда падавшие начинают лежать круглыми сутками. Devops такой наглости не выдерживает, идёт к начальству и закономерно вопрошает — а какого, мол, хуя? Начальство же ласково соощает devops-у что он — ретробес и мракоград, не понимает что AI нас всех ведёт в светлое будущее и сейчас все его yaml-и один разработчик с Claude кааак оптимизирует...

Договориться не удаётся, devops-у вручают Contract Termination Letter.

Проникнитесь сюрреализмом: в нормальном бизнесе сначала оптимизируют процесс, а потом перераспределяют освободившиеся кадры. А у нас расстаются с кадрами (которых только недавно собирали по крупицам) под эфемерное ОБЕЩАНИЕ оптимизации.

IT-индустрия вообще только недавно начала более-менее осознавать что такое квалифицированный инженер. Как его собеседовать и как с ним работать. Понимание идёт туго, доходит не до всех. А тут Anthropic всех нас столкнул с новым челленджем: разобраться кто из этих инженеров AI-compatible. Это — задача совершенно иного уровня, в разы сложнее. По моему скромному мнению, AI-compatible инженер должен быть почти архитектором. Он обязан уметь смотреть на системы в целом, разбивать их на части и понимать как они вместе работают. С таким мышлением можно делать точные промпты и добиваться результата. Но эффективный инженер — всегда скептик. А скепсис компании принимают за отрицание прогресса, что ведёт к увольнению.

Такие дела