Обсуждаем вопросы сбора и подготовки данных
Привет, бойцы, вы готовы победить перенос данных?
Есть задача: перенести данные из PostgreSQL в Kafka. Первая мысль: написать небольшой сервис.
Он будет выполнять SELECT, превращать строки в сообщения и отправлять их через Kafka Producer. На схеме все выглядит почти безобидно:
Инженеры данных построили агрегат — маленькую таблицу «продажи по магазинам по дням». Отчёт из неё собирается за доли секунды. А сводная в Excel всё равно ждёт двадцать секунд и читает миллиард строк.
Разбираемся на живом ClickHouse, почему база не видит предагрегат, который для неё построили, какая форма запроса это лечит (одна и та же для ClickHouse, Snowflake и BigQuery) и почему в итоге вопрос не к базе, а к семантическому слою. Внутри — замер на миллиарде строк: 3 секунды против 37 миллисекунд, сравнение восьми баз и одно правило, которое стоит проверить в своём BI.
Насос на НПЗ ломался каждые три месяца. Ремонтники меняли подшипники, но проблема возвращалась. Мы предложили не просто мониторить вибрацию, а найти скрытую причину в данных. Результат превзошел ожидания: 60 дней упреждения и неожиданный виновник поломки. Рассказываем, как это было и почему модель — это только 20% успеха.
Привет, Хабр! На связи Александр Курносов, руководитель группы платформы данных, и Андрей Двинских, инженер больших данных. В ежедневной работе мы используем несколько инструментов. Чтобы разобраться с очередной задачей, приходится переключаться между ними, искать нужную информацию и собирать общую картину буквально по частям. В какой-то момент мы поняли, что большинство таких действий повторяются каждый день. Поэтому решили собрать самые востребованные сценарии в одном внутреннем инструменте. Так появился ETL log. В статье расскажем, почему решили его создать, какие задачи он помогает решать и как устроена работа с ним.
Уже полтора года я строю себе цифрового двойника: базу знаний, где лежит вся моя жизнь за десять лет, и агента, который этой базой пользуется вместо меня.
Начинал я как все, со связки Obsidian и Claude.
Первые свои выводы начал делать после того, как загружено было 219 353 файла. Я не знаю как для вас, но для меня Obsidian теперь - это просто программа для просмотра, а не то что я раньше про него думал. Вся ценность всего этого массива моих данных - в трёх вещах: обычные текстовые файлы на диске, ссылки, перелинковки между ними и агент, который читает и пишет их напрямую.
Как это у меня устроено сейчас и сколько токенов на это потрачено
Цель у меня была сделать своего цифрового двойника. Систему, которая думает и отвечает как я, помнит всё, что помню я, и то, что я уже забыл. Для этого нужна правильно работающая память. Но не векторная база с блоками текста по пятьсот токенов, а нормальная, со структурой и историей.
Я поставил Obsidian, завёл хранилище, стал туда складывать заметки, документы, истории - да все подряд.
Чего я ждал от Obsidian, когда ставил его: что он станет местом, где живёт вся моя память; что граф будет моим рабочим инструментом, по которому я нахожу забытое, а не только картинкой, что дополнения которые есть в обсидиан, закроют всё, чего мне не хватало: свяжут заметки между собой, соберут из них таблицы и подключат к базе нейросеть; что синхронизация между машинами будет его заботой, а не моей; что агент сможет работать с базой через него.
Из этого сбылось только то, что граф действительно приятно смотреть, и заметки удобно читать глазами. Но Obsidian это не база знаний. Для меня сейчас это программа для просмотра папки с текстовыми файлами. Она красивая, с графом и плагинами.
Пошаговое руководство по развертыванию JupyterLab на GPU-сервере. Рассказываем про настройку JupyterHub, драйверов NVIDIA, безопасности (Nginx/SSL), лимитов ресурсов и мониторинга.
В 1С ежедневно накапливаются данные о контрагентах, номенклатуре, остатках, продажах, договорах и сотрудниках. Они нужны не только для учета: руководители используют их в дашбордах, аналитики — в BI-системах, а смежные сервисы — для обмена справочниками и показателями.
Сложность начинается в момент, когда данные требуется получить за пределами учетной системы. Иногда достаточно один раз сохранить список в Excel. В других случаях нужна обновляемая таблица или отчет с отборами и группировками. Разберем три способа, доступных без разработки отдельного решения.
Даже хороший алгоритм не спасёт модель, если признаки приходят с нарушенной семантикой или содержат информацию из будущего. Одна лишняя колонка может поднять метрику на тестах и полностью исчезнуть в проде.
Разберём рабочий подход к валидации датасета: от контрактов схемы и проверки таргета до point‑in‑time корректности и фиксации артефактов, чтобы результаты обучения можно было воспроизвести и объяснить.
Привет, Хабр!
В этой статье разберём ещё один инструмент ClickHouse, который часто используется при обогащении данных и позволяет значительно ускорить выполнение тяжелых SQL-запросов с джоинами.
Допустим, у тебя есть несколько AI-агентов. Один разбирает тикет, второй меняет код, третий запускает тесты, четвёртый готовит релиз.
Задача закрыта, тесты зелёные, артефакт собран. Метрика success_rate показывает успех.
Можно праздновать?
Не обязательно. Агенты могли несколько раз выполнить одну работу, нарушить порядок операций, одновременно захватить общий ресурс или случайно добиться правильного результата через недопустимую последовательность действий.
Финальное состояние корректное. Процесс — нет.
Именно эту проблему пытается измерить CoCoBench — новый бенчмарк для проверки координации нескольких AI-агентов. Его разработали исследователи из Нанкинского университета, Tsinghua и AgiBot.
Главная идея исследования полезна далеко за пределами робототехники:
BI снова хоронят: подключаем LLM к хранилищу и аналитики больше не нужны, деньги тратить на лицензии не нужно. По крайней мере, так выглядит обещание.
На практике дата-агент может написать корректный SQL, получить верные цифры и всё равно уверенно ответить не на тот бизнес-вопрос. Он путается в определениях метрик, теряет права пользователя, дорого ходит по кругу и иногда рассуждает хуже, когда ему дают больше времени.
Я разобрал свежие кейсы OpenAI, Anthropic и Hex: что действительно улучшает ответы, какие очевидные подходы уже провалились, из чего складывается реальная стоимость и как за шесть шагов проверить
209 тысяч наименований товаров в 150 представительствах записаны по-разному, а обычный join сопоставляет от силы 1% из них. Дата-инженер Дмитрий Дунаев на Вечерней школе Слёрма показал, как эту путаницу разгребли с помощью LLM, эмбеддингов и fuzzy-поиска, а заодно избавили менеджеров от звонков по 5 минут за штуку из бесконечного списка на обзвон.
Из 15 протестированных моделей нужный баланс критериев показала только одна. Какая именно и почему, разбираем в конспекте доклада вместе с чек-листом, когда агента строить стоит, а когда деньги лучше сэкономить.
Четвёртая часть цикла про TDCV2 — открытый конструктор тестовых данных, который я пишу сам.
Обычно форму случайных значений выбирают из списка: нормальное, экспоненциальное, ещё десяток. Нужного в списке может и не оказаться — суточный профиль нагрузки с двумя горбами разной высоты, разгон и торможение, датчик, у которого к вечеру растёт разброс. Собрать такое формулой вполне можно, вопрос только в цене: смесь распределений, подбор весов, десяток коэффициентов, смысл которых через неделю уже не вспомнишь.
А можно нарисовать. Генератор берёт SVG или скриншот графика, читает контур и раскладывает по нему значения. Нарисуете две линии вместо одной — получите коридор, и разброс тоже станет нарисованным. А поменяете смысл горизонтальной оси — та же картинка превратится в закон распределения. Формулу это не отменяет, просто для некоторых форм выходит заметно короче.
В статье разбираем реальное тестовое задание на позицию аналитика 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 — открытый конструктор тестовых данных, который я пишу сам. Про то, что делать, когда несколько колонок описывают один и тот же объект и обязаны меняться только вместе.