Data Engineering *

Часть 2 из 2. В первой части серии мы предсказали отказ насоса за 60 дней и выяснили, что годами чинили не то. Увидели, что материал встретил вашу живую реакцию, поэтому возвращаемся по горячим следам со второй частью. В этом материале, как и обещали, погружаемся в технику. Расскажем, что было под капотом, как решалась судьба насоса и с какими сложностями мы столкнулись.

Начну со сцены, которую видел каждый, кто эксплуатировал платёжный сервис хотя бы год.

Клиент нажимает «Оплатить». Приложение отправляет POST /payments. Проходит пять секунд, и HTTP-клиент падает по таймауту. Ретрай-политика, которую кто-то настроил год назад по гайду, ждёт двести миллисекунд и отправляет запрос ещё раз. Через минуту клиент видит в выписке два списания.

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

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

Второй вывод: надо добавить заголовок Idempotency-Key. Добавили. Дедупликацию сделали в middleware поверх Redis. Через полгода двойное списание случается снова. Потому что Redis пережил failover и потерял ключи. Или потому что повтор пришёл через сутки из файла клиринга, а в файле никакого HTTP-заголовка нет.

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

Retry сам по себе всего лишь тактика. Он работает там, где контракт уже есть. Без контракта retry не делает систему устойчивее. Он делает её быстрее ломающейся.

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

На практике до дашборда было ещё далеко.

Между записью в рабочей системе и цифрой на экране находится целая цепочка решений. Какую дату считать отчётной? Что делать с изменившимся статусом? Какая запись является основной, если один объект встречается несколько раз? Как связать справочники, которые в разных системах ведутся по-разному? И главное - как потом объяснить конкретную цифру, если она не совпала с привычным отчётом?

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

Всех приветствую! Меня зовут Андрей, я студент 4 курса факультета математики и компьютерных наук, автор телеграм-канала Andre | Data Science. Все мы знаем, что направление машинного обучения сейчас на огромном хайпе - практически из-под каждого камня говорят о разных методах и о том, что они способны решить практически любую задачу. Но гайдов, которые бы подробно разбирали работу конкретного метода - от обычной загрузки данных до математического обоснования принципа его работы и визуализации каждого шага, - катастрофически мало.

В этой статье я хочу закрыть этот пробел и разобрать один конкретный метод - RBF SVM. Мы посмотрим, как он устроен с математической точки зрения, как появился на свет, какие у него есть сильные и слабые стороны и с чем они связаны. Также протестируем его на реальных датасетах. Так как аудитория IT-сообщества довольно широкая, я постараюсь очень подробно расписывать каждое определение и каждую часть своего повествования, чтобы по ходу чтения у вас возникало как можно меньше вопросов и нить понимания не обрывалась.

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

Все мы знаем о понятиях ETL/ELT, оно же ETLT. В добавок к этим паттернам иногда на проектах применяются необязательные проверки качества данных, создают возможность аудита загрузок и данных, управления, а так же систематизируют дальнейшую поддержку. Но перечисленные стадии не являются обязательными, поэтому и появляется следующее поколение процесов ETL/ELT с суффиксом “++”, то есть ETLT++.

У мессенджера MAX нет публичного API со статистикой каналов. Числа есть у каталогов-агрегаторов, но они чужие и заморожены с 10 июля. Нам нужен был свой ряд подписчиков — и мы полгода снимаем его каждую ночь с публичного data-эндпоинта max.ru.

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

В марте я уже выкладывал материал про свой ранний проект - AAF (Autonomous Agent Framework). Это был базовый эксперимент, на котором я обкатывал концепции локального контекста и вызова инструментов. За прошедшие месяцы я переписал архитектуру с нуля, учтя накопленный опыт, и сформировал новый фреймворк - JAWL (Just A While Loop).

Если посмотреть на актуальный ландшафт опенсорсных автономных агентов, выделяются два интересных проекта: OpenClaw (созданный Питером Штайнбергером) и Hermes Agent (от Nous Research).

Привет, Хабр! Меня зовут Алексей Миронов, я главный разработчик отдела разработки хранилищ данных в «Газпром ЦПС». Сегодня я расскажу о своем опыте внедрения Data Vault в компании.

Методология Data Vault 2.0 на бумаге выглядит безупречно, особенно если ваша команда живёт по Agile. Разделение данных на Хабы, Линки и Сателлиты позволяет расширять хранилище инкрементально. Появился новый источник или изменилась бизнес-логика? Просто достраиваем новые блоки рядом, не ломая старые сущности и не переписывая половину DWH, как это часто бывает в классической архитектуре Кимбалла.

Кроме того, Data Vault даёт чёткие правила игры: стандарты генерации объектов, расчёта хэш-ключей и версионирования истории здесь прописаны до нас. Это полностью убирает «творчество» отдельных инженеров — вся команда пишет код в едином стандарте.

Но когда дело доходит до практики, начинаются сложности. Ручное проектирование однотипных таблиц быстро превращается в ад. В этой статье я расскажу, как мы наступили на все классические грабли ручного Data Vault и как написали собственный гибкий фреймворк автоматизации.

Ожидания vs Реальность: с какими болями мы столкнулись

К проекту мы решили подойти основательно. Подготовку начали с теории: специально купили легендарную книгу Дэна Линстеда «Building a Scalable Data Warehouse with Data Vault 2.0» в оригинале. Честно прочитали (признаюсь, местами сильно по диагонали) и, вооружившись академическими знаниями, бесстрашно ринулись в бой с реальными данными.

На бумаге всё выглядело гладко, но как только книжная теория столкнулась с продакшен-выгрузками, мы моментально упёрлись в классические проблемы роста:

Это не очередной туториал «поставь LangChain и получи RAG за час». Это дневник того, как одна конкретная RAG-система вырастала из «нейросети, которая просто лазит грепом по md-файлам» до многослойного пайплайна с графом знаний, гибридным ретривом и адаптивной схемой рассуждений — и почему мне пришлось писать её с нуля, вместо того чтобы допилить существующую.

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

Разберём практический подход к проверке качества ML‑модели: от временного сплита и настройки Pipeline до подбора порога решения и подготовки артефакта для инференса.

Пока СМИ спорят о лидерстве моделей в бенчмарках, бигтех перенаправляет бюджеты совсем в другую сторону. Бюджеты на обучение LLM худеют, на инфраструктуру поиска, доставки и фильтрации данных — толстеют. Копнём реальную статистику инвестиций гигантов IT за последние годы и посмотрим, как меняются требования к специалистам на рынке труда.

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

И самое интересное: агент не нарушал прямой запрет. Наоборот, в ключевой момент он поступил "безопасно" — отказался запускать неизвестный бинарный файл и написал собственный декодер на Python. Именно это решение и стало частью атаки.

Такую цепочку продемонстрировал исследователь безопасности Иоганн Ребергер на Claude Code с моделью Opus 5 в Auto Mode. В его небольших сериях тестов атака срабатывала в трёх или четырёх запусках из пяти. Это не означает, что "Claude взламывается с вероятностью 80%", но хорошо показывает более важную проблему: безопасный на вид отдельный шаг ничего не гарантирует, если вся цепочка строится в среде, которую контролирует атакующий.

Как организовать регулярную выгрузку данных из 1С, если ручной экспорт уже не справляется с объемом и частотой обновлений? В статье сравниваются два подхода: прямой доступ к базе через SQL и использование готового ETL-инструмента. Разбираем скорость, сложность настройки, требования к специалистам, риски для безопасности и сопровождения системы. Также показываем, в каких случаях оправдан SQL, а когда удобнее использовать готовый инструмент для автоматической выгрузки данных по расписанию без постоянного участия разработчика.

Привет, бойцы, вы готовы победить перенос данных?

Есть задача: перенести данные из 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. В других случаях нужна обновляемая таблица или отчет с отборами и группировками. Разберем три способа, доступных без разработки отдельного решения.