Data Engineering *

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

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

Я разобрал свежие кейсы OpenAI, Anthropic и Hex: что действительно улучшает ответы, какие очевидные подходы уже провалились, из чего складывается реальная стоимость и как за шесть шагов проверить

209 тысяч наименований товаров в 150 представительствах записаны по-разному, а обычный join сопоставляет от силы 1% из них. Дата-инженер Дмитрий Дунаев на Вечерней школе Слёрма показал, как эту путаницу разгребли с помощью LLM, эмбеддингов и fuzzy-поиска, а заодно избавили менеджеров от звонков по 5 минут за штуку из бесконечного списка на обзвон.

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

Четвёртая часть цикла про TDCV2 — открытый конструктор тестовых данных, который я пишу сам.

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

А можно нарисовать. Генератор берёт SVG или скриншот графика, читает контур и раскладывает по нему значения. Нарисуете две линии вместо одной — получите коридор, и разброс тоже станет нарисованным. А поменяете смысл горизонтальной оси — та же картинка превратится в закон распределения. Формулу это не отменяет, просто для некоторых форм выходит заметно короче.

Сегодня у айтишников появилось новое хобби - делать свой SaaS или писать торговых ботов с помощью LLM.

Порог входа резко снизился: достаточно хорошей идеи, немного свободного времени и подписки на одну из современных LLM.

Модель, которая набирает 90%+ в бенчмарке, совсем не обязательно поможет вам заработать деньги.
Потому что между «написать хороший код» и создать работающий продукт есть огромная разница.

Я дал шести LLM одну задачу - написать торгового бота и проверил, что из этого можно использовать на практике.

GPT, Claude Opus, DeepSeek, Qwen, GigaChat, YandexGPT Pro.

В статье разбираем реальное тестовое задание на позицию аналитика DWH: четыре коротких SQL-запроса. Все синтаксически корректны, все дают верный результат на контрольных данных. И в каждом спрятана предпосылка, при нарушении которой цифры в витрине становятся неверными — без ошибок, без предупреждений, просто другие числа в отчёте

У банков и ритейлеров, с которыми я работала, почти всегда одна и та же боль: данные о клиенте размазаны по CRM, core-banking и платёжным системам, и никто не может ответить на простой вопрос — а что мы вообще знаем об этом клиенте прямо сейчас. Чтобы попрактиковаться в решении этой задачи и показать подход публично, я собрала pet-проект: end-to-end пайплайн, который строит единую витрину Customer 360 из синтетических данных.

Сразу оговорюсь: все данные генерируются локально скриптом и полностью синтетические. Кода или данных работодателя в проекте нет — это самостоятельная реализация архитектуры, которую я использую в повседневной работе DWH/data-аналитика.

Обычный MCP-инструмент возвращает агенту текст или структурированные данные. Агент анализирует результат и пишет тебе что-то вроде:

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

Для проверки я использую четыре типа контролеров: от полностью автоматических O3, где результат можно проверить механически, до O0, где остается человеческое решение. При этом наличие проверки само по себе ничего не гарантирует - важна ее реальная сила: охват, надежность, устойчивость и независимость. Эту модель я называю градиентом автономности.

Теперь попробуем применить ее к данным и аналитике

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

Где заканчивается прототип и начинается инженерия, почему «работает у меня» не равно «готово для бизнеса» и за что на самом деле платят опытной команде.

TL;DR: мы сделали llm_markup — Spark-приложение для массовой обработки данных через LLM API в существующем Airflow-контуре. Источник данных, промпт, формат ответа, лимиты и целевая таблица задаются конфигурацией. Инструмент берет на себя батчинг, распределение запросов, контроль нагрузки на API, валидацию ответов и сопоставление результата с исходными строками.

Меня зовут Дима Иванов, я дата-инженер в Lamoda Tech. Я работал над llm_markup и в этой статье расскажу, как мы пришли к его архитектуре и какие задачи пришлось решить, чтобы инструмент стабильно работал в продакшене. Разберем это на двух примерах: оценке качества поиска и классификации негативных отзывов.

Четыре фамилии, четыре специальности, четыре кабинета. Сколько разных врачей окажется в журнале на две тысячи строк? Шестьдесят четыре.

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

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

Представьте: вы разрабатываете антифрод-систему для банка. Пользователь совершает пять покупок подряд за пару минут. Все транзакции успешно попадают в Kafka, никаких ошибок, consumer lag почти нулевой, Flink работает стабильно.

Но модель выдачи решений получает на вход признак: transactions_in_10_minute_window = 3 Хотя по факту их было пять, а вместо вероятности мошенничества 0.91 она выдаёт 0.42.

Рынок ИТ нестабилен, и люди могут менять работодателей. Ваша предыдущая компания была партнером Databricks, и у вас был аккаунт в Databricks Partner Academy с сертификатами, значками и информацией о пройденных курсах. В новой компании у вас новый аккаунт, а ваши предыдущие достижения и сертификаты остаются в предыдущей компании. Оказывается, вам не нужно проходить все заново. Вы можете перенести всю свою историю.

При LoRA‑дообучении адаптеры обычно применяются ко всем слоям модели, хотя активность разных слоев во время обработки промпта заметно различается. Возникает вопрос: можно ли выбрать более «умные», активные слои для конкретной темы и получить прирост качества?

Проверил гипотезу на Qwen3-1.7B: воспроизвёл метод из статьи Act‑LoRA, добавил свою метрику по градиентам, статистически проверил устойчивость сигнала и получил результат, который многое объясняет о том, как на самом деле работает LoRA‑дообучение.

Привет, Хабр!

Собрать Lakehouse на слайде несложно. Берём S3-совместимое хранилище, добавляем Iceberg, Spark, Trino, Kafka, Airflow и каталог данных. Получается современно, масштабируемо и архитектурно красиво. Гораздо сложнее сделать так, чтобы эта конструкция работала в определенных корпоративных сценариях. В статье попробуем отделить архитектурную концепцию от маркетинга и разобраться, как на самом деле идут проекты внедрения Data Lakehouse в России: какие решения доступны на рынке, какие проблемы платформа не решает, когда её внедрение имеет смысл и как выбрать подход к миграции.

Привет, Хаброжители! Совсем недавно мы открыли предзаказ на книгу:«Data integration. Объединение данных для улучшения процесса принятия решений». Мы хотим немного больше вам о ней рассказать.

Джей Бортен дает подробное практическое руководство по интеграции данных — от базовых понятий и терминологии до реального сквозного примера, который шаг за шагом превращает разрозненные источники в работающий конвейер на AWS, Qlik, Databricks и Confl uent. Независимо от того, разбираетесь ли вы в теме, впервые приступили к этой задаче или хотите систематизировать уже накопленный опыт, идеи и практические примеры Бортена помогут вам выстроить эффективную работу с данными в компании.

Разбор всех видов SCD (slowly changing dimensions) по Кимбаллу:
— от простого к сложному
— на примерах
— с цитатами Кимбалла

В конце обзора — заполненная шкала со всеми типами и подсказками

В любой записи в базу зашито допущение: у факта одно значение. Два несовпадающих наблюдения об одном объекте — конфликт, который положено разрешить до коммита, и разрешается он UPDATE. Пока данные генерирует ваш же код, допущение верное.

Ломается оно на наблюдениях. Сенсоры расходятся в показаниях, и оба показания настоящие. Агент пишет о состоянии файла, который человек уже поправил руками. Два источника сообщают разное, и разрешить противоречие в момент записи нечем — контекст, в котором одно из них весит больше, появляется только в момент вопроса.

INDB стоит на этом: смысл производится при чтении, а не фиксируется при записи. Вместо CRUD три фазы — вдох (Inhale, принять сырое наблюдение), выдох (Exhale, сжать повторы и отфильтровать шум репутацией), аксиома (Axiom, подписать то, что выжило).

Если мысленно вернуться в 1980-е, аналитика во многом находилась буквально над production

Данные появлялись в операционных системах, затем из них строились отчёты, выгрузки и аналитические витрины. Постепенно мы начали выносить аналитику подальше от production: появились отдельные хранилища, ETL, data warehouse, затем data lake, lakehouse и, наконец, огромный набор специализированных систем для streaming, batch, realtime и research

Каждый раз мы решали вполне реальные проблемы своего времени. Но вместе с этим постепенно привыкли к довольно странной модели:

production хранит настоящее, data lake - прошлое, Kafka - поток, а research живёт где-то ещё

И вот здесь мне стало интересно немного заглянуть вперед...

А что, если в 2052 году мы перестанем воспринимать всё это как разные сущности?

Опираясь не на фантазии, а на то, что смог найти в технических блогах - не концепты, а реальные прототипы

Если не хотите много читать, в конце статьи вся суть одной картинкой

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

Сложности начинаются, когда такого агента нужно запустить в проде.

Кто будет хранить состояние между запросами? Как пережить перезапуск? Где выполнять сгенерированный код? Как не передать ему секреты? Когда запрашивать подтверждение пользователя? Что делать, когда контекст разрастается до сотен тысяч токенов?