Data Engineering *

Пару дней назад я собрал сводку новостей по lakehouse и закончил её обещанием: разберу каждый громкий анонс по отдельности. Выполняю - и начинаю с самого шумного.

На своём июньском саммите Databricks вышел на сцену с заявлением масштаба смены эпохи: отдельные быстрые базы под витрины больше не нужны, перекачка данных между системами умерла, а всё хозяйство теперь живёт в едином озере, готовом под ИИ-агентов. Звучит так, что хочется встать и поверить.

Я вместо этого полез в их документацию, инженерные блоги и интервью - и ниже по пунктам сверяю, что обещано со сцены, а что написано мелким шрифтом. Сразу скажу: технология местами действительно сильная. Но «конца эпохи» в опубликованных данных я не нашёл - нашёл несколько мест, где громкое слово прикрывает вещь куда более скромную и знакомую.

Я слишком рано понёс первые результаты в наш продукт. Тогда это выглядело логично: мы прикрутили агентный ИИ к анализу логов и поведения пользователей в regulated продукте с реальными денежными операциями, качество обнаружения пошло вверх, аналитики по фроду стали меньше возвращать инженерам мусорные кейсы.

Снаружи это уже выглядело рабочим слоем защиты: аналитики видели меньше мусора, инженеры получали более понятные issues, и продукт наконец увидел практическую пользу вместо очередного демо. Я примерно так и сказал: “смотрите, это уже не игрушка”. Плохая фраза, как оказалось.

Потому что как только защита начинает работать, даже чуть-чуть, вокруг сразу появляются нормальные взрослые вопросы. А давайте это в платежи? А в бонусный абьюз? А в L7? А в социнженерию? А в странные кейсы саппорта, где один тикет внезапно объясняет половину графика? Вопросы честные. Только дорогие.

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

Пишу по собственному инженерному опыту. Детали слегка обобщены и обезличены, потому что в антифроде лишняя конкретика быстро превращается в инструкцию для другой стороны.

Осенью 2024 года я не планировал начинать новый проект. Тем более связанный с медициной.

После тяжёлой пневмонии дочери врач назначил контрольный анализ крови. Среди стандартных показателей оказался анализ на уровень глюкозы. Именно он впервые показал проблему.

Вскоре нас направили в детскую больницу, где после обследования поставили диагноз — сахарный диабет первого типа.

Наверное, многие родители, столкнувшиеся с этим впервые, испытывают похожие ощущения. За несколько дней приходится освоить огромный объём новой информации: научиться измерять уровень глюкозы, рассчитывать углеводы, понимать действие разных типов инсулина, вести дневник питания и принимать десятки небольших решений каждый день.

Параллельно с этим я заканчивал курс Python в Яндекс Практикуме. Днём — работа, вечером — обучение, ночью — медицинские статьи и клинические рекомендации. Не самый простой период, но именно тогда и появилась идея проекта, о котором пойдёт речь дальше.

Apache Paimon: стриминговый lakehouse для дата-инженеров

Сколько систем вы держите ради того, чтобы аналитики видели события через секунды, а годовые отчёты собирались без прогрузки всех данных целиком? Kafka, Flink, S3/HDFS, ClickHouse и бесконечная синхронизация состояния между ними. Apache Paimon стирает границу между стримингом и батчем: одна таблица на LSM-tree отдаёт свежие данные за секунды и одновременно служит источником для тяжёлой аналитики. Разбираем архитектуру, честные бенчмарки против Iceberg, Delta Lake и Hudi - где Paimon выигрывает, а где проигрывает - и проходим путь от первой таблицы до CDC-пайплайна в проде на рабочем коде.

Привет Хабр!

Современное нефтегазовое производство требует всё более совершенных инструментов для прогнозирования состояния оборудования и предотвращения аварийных ситуаций. Особенно это касается газопроводов-шлейфов — критически важных элементов инфраструктуры, обеспечивающих транспортировку газа от скважин до установок комплексной подготовки газа.

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

В этой статье мы подробно разберём, как машинное обучение помогает решать проблему прогнозирования износа газопроводов.

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

Привет! Меня зовут Роман, я инженер данных в компании CDEK и занимаюсь разработкой платформы данных и внедрением self‑service инструментов. В этой статье расскажу, как мы обеспечиваем Event Sourcing подход в платформе больших данных, с какой болью столкнулись при переходе на Kafka 4.0 и как решились отказаться от JSON‑формата.

Это продолжение новых безопасных паттернов по работе с MCP, которые я для себя придумал, которые я описал в статье:

Основная задумка вместо того, чтобы строить очередной Data-lake возможно ли организовать взаимодействие через MCP так с данными, чтобы это было безопасно и эффективно

Небольшой обзор идей согласованности в DWH на основе книг Кимбалла.

В статье - краткий разбор некоторых принципов моделирования данных простыми словами.

- Кто такой Кимбалл и каков его подход
- Факты и измерения
- Согласованные факты
- Согласованные измерения
- SVOT, или single version of truth

Я сделал ContentCombine — мультинишевый контент-комбайн, который собирает материалы из RSS, Telegram, сайтов и других источников, нормализует их, считает скор, склеивает повторы в сюжеты, отделяет кейсы от шума и готовит ежедневный дайджест. Сначала движок работал на игровых новостях, потом я перенёс его на SEO и AI — без переписывания ядра, но с кучей неожиданных граблей: entity blobs, старые статьи под видом свежих, молчащие фиды, ложные тренды и LLM-недетерминизм в проде.

Практический эффект TAPe+ML v2 сейчас лучше всего видно в object detection. Так, TAPe+ML v2 на конкретной практической задаче рудозасорения (см главу про промышленный пилот), без COCO-головы, на новом backbone, основанном на данных клиента, дает точность детекции 96%, по mAP50 – точность  90% и по mAP50–95 – 85%. То есть TAPe‑детекция выходит на уровень RF‑DETR по mAP50 при числе параметров меньше 100 тысяч против порядка 127 миллионов у RF‑DETR 2XL.

Мы применили последовательность улучшений, которые не раскрываем публично как ноу‑хау, но их итоговые эффекты можно зафиксировать на COCO. На разных этапах получались следующие значения:

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

Тогда возникает идея разработать некий механизм, который обладает всеми приватными знаниями организации. Это может быть Confluence, дата хаб, трекер задач и так далее. В этой статье будем разбираться именно на примере кода.

GenAI-ассистент может довольно быстро начать отвечать "по теме": находить релевантные фрагменты, собирать уверенный текст и создавать ощущение, что система уже работает.

Если подключить LLM к корпоративным документам через RAG, подобрать параметры поиска, немного почистить контекст и добавить хороший prompt, первые результаты часто выглядят обнадеживающе. Пользователи начинают пробовать систему, появляются первые метрики использования, а сама идея быстро кажется готовой к расширению.

Но для продуктового контура этого недостаточно.

Проблема не только в том, может ли модель сформировать релевантный ответ. Проблема в том, является ли поведение системы ожидаемым, проверяемым и управляемым.

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

В этой статье я разбираю не готовый "рецепт правильного GenAI-ассистента", а результаты и выводы из проверки на малом контролируемом прототипе: какие решения появляются вокруг GenAI-системы, когда она должна не просто отвечать, а вести себя управляемо.

Фокус будет не на том, как "улучшить prompt" или выбрать модель побольше, а на том, как система управляет ответом после retrieval:

Как устроен Data Mesh, какие требования подход предъявляет к бизнесу и почему большинству российских компаний сегодня зачастую важнее построить зрелое DWH, чем пытаться перейти к распределенной архитектуре данных

Есть привычная ошибка в техническом аудите больших сайтов: открыть краулер, поставить лимит побольше и просканировать всё.

На сайте в пару тысяч страниц это работает. На сайте с семизначным инвентарём URL — нет. Полный краул упирается в память, диск, сетевые таймауты, rate limit, JavaScript-рендеринг, дубли, параметры, бесконечные фасеты и в то, что через двое суток вы получаете таблицу на миллионы строк, которую всё равно придётся сегментировать с нуля.

Поэтому я начинаю не с краулера. Я начинаю с sitemap.

В статье показываю sitemap-first подход: как скачать sitemap graph, превратить URL в датасет, разобрать слаги на смысловые группы, сматчить паттерны со спросом, найти пустые посадочные, проверить рендеринг и потом подтвердить гипотезы через GSC, Яндекс.Вебмастер, Метрику и серверные логи.

write‑tools, безопасность, метаданные

Это вторая часть статьи по Sping AI в Джеймикс. Короткая аннотация первой — на случай, если прошло время или вы её не читали: мы собрали read‑only агент внутри Джеймикс‑приложения. Пользователь задаёт вопрос на естественном языке; ChatClient из Spring AI крутит agent loop — дёргает @Tool‑методы, пока не наберёт достаточно данных для ответа. Каждый tool данные читает через DataManager с явным fetch plan‑ом, поэтому почти полностью остаётся внутри рамок системы безопасности Джеймикс и возвращает только нужные модели поля. UI — обычный Джеймикс‑вью, без REST‑прослойки. Также, в первой части мы убедились, что выбор модели — не деталь: модель без надёжного native tool calling ломает всю схему. Если первую часть не читали — начните с неё, код ниже строится как продолжение.

В этой части мы дадим агенту право менять данные. И вот здесь, в отличие от первой половины, начинают всплывать вопросы, которые ни Spring AI, ни большинство туториалов по агентам обычно не поднимают: под каким пользователем выполняется tool, что делать с транзакциями, как аудировать действия, инициированные моделью, и как заставить агента работать с вашей доменной моделью без ручного перечисления сущностей в промпте.

Это не косметические изменения, а ровно те решения, что отделяют демо от приложения, которое можно показывать заказчику.

Полный исходник всего, что мы здесь обсуждаем, лежит здесь: https://github.com/jmix‑edu/ai‑warehouse — можно клонировать и сразу запустить.

Что добавляем

Всем привет!

Меня зовут Никита, я CEO компании VSL BI. Мы занимаемся внедрением BI-аналитики и автоматизацией отчетности для бизнеса.

Недавно к нам обратилась спортивная школа для детей.

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

Поэтому основной целью проекта стало создание единой системы аналитики, в которой данные из Alfa CRM автоматически собираются, обрабатываются и отображаются в виде дашбордов для руководства.

Сейчас я учусь на 2 курсе магистратуры МИФИ по ML ( это моё второе высшее образование, по 1 специальности я психолог и TechHR с опытом 17+ лет), и пишу диплом о GENAI аватарах, в рамках диплома я создала прототип коммуникативной системы для HR и кандидатов на основе GENAI аватаров и LLM (подготовка для кандидатов к интервью, первичная оценка кандидатов + доп.сервисы - аналитика по ML-вакансиям в Real-Time). Мой диплом - это полноценный прототип системы с бэкэндом и UI, LLM, Gen-AI аватарами.

Этот небольшой обзор - для моих локальных студенческих задач. Cейчас для меня важна невысокая стоимость GPU сервисов - для демо-версии на защите диплома в МИФИ, в связи с этим я сделала обзор GPU решений в России, которые подходят для студента, будут не слишком дорогими, и на перспективу - могут быть подходящими и для небольших Production решений.

Всем привет. На связи Дмитрий Немчин из Т-Банка. Снова буду говорить про Greenplum, но в необычном контексте.

С 2015 года занимаюсь Greenplum: развитием, эксплуатацией, автоматизацией и всем, что обычно появляется вокруг большой аналитической платформы. Когда я пришел, у нас было два production-кластера Greenplum и десятки терабайтов данных. Сейчас production-кластеров около 20 и объемы данных измеряются петабайтами. За это время Greenplum прошел путь от небольшого DWH до центра крупной Дата Платформы. И сейчас это система, которая все еще держит большую часть нагрузки, но постепенно перестает быть точкой будущих инвестиций. 

Переход к такому состоянию системы часто воспринимается болезненно. Особенно если технология долго была центральной для команды и бизнеса. Но сам факт перехода в legacy не означает, что система была плохой или что работа команды обесценилась. Чаще наоборот: legacy становятся решения, которые долго работали, выдержали рост и успели стать частью критичной инфраструктуры. 

В статье хочу разобрать переход на примере Greenplum: что я называю legacy, почему технология начала ограничивать следующий этап роста, какие варианты были у команды и что происходит с людьми, когда привычная система постепенно уходит из фокуса развития. 

Меня зовут Андрей, я работаю с данными. И так получается, что на реальных проектах у меня никогда не было возможности собрать идеальный, на мой взгляд стек. Поэтому я собрал его в идеальном пет проекте.

Это первая из двух статей про построение AI-агента внутри Джеймикс-приложения. Джеймикс (или Jmix, ex. CUBA) - высокоуровневый фреймворк для разработки корпоративных приложений на Java, автор не будет слишком сильно в него погружаться, в наше время любой запрос к AI даст Вам всю нужную информацию. В этой части мы соберем минимальный, но рабочий пример: пользователь задает вопрос на естественном языке, агент решает, какие операции вызвать на бэкенде, дергает их и возвращает осмысленный ответ. В качестве предметной области возьмем склад - сценарий, узнаваемый для большинства бизнес-приложений и достаточно широкий, чтобы во второй части обсудить уже не только чтение, но и запись данных, безопасность, fetch plans и метаданные.

Зачем это вообще нужно? Данные корпоративного приложения живут за списками и формами с фильтрами. Это отлично работает, когда пользователь знает, по каким полям фильтровать - и плохо для размытых, многокритериальных вопросов вроде "где у нас заканчивается кофе тёмной обжарки по северным складам?". Когда иначе пришлось бы открыть несколько экранов и руками свести результаты, AI-агент даёт возможность просто спросить - и собирает ответ из бэкенд-операций, которые у вас уже есть.

Почему строить это внутри Джеймикс-приложения, а не отдельным сервисом? В случае Джеймикса агент едет на том же доступе к данным и той же безопасности, что уже есть во фреймворке, его tools идут через DataManager, поэтому он видит ровно то, что разрешено текущему пользователю - никакого параллельного пути к данным, никакого обхода прав. Именно это свойство делает агента приемлемым в enterprise-контексте, и это поведение - сквозная нить обеих частей.