Data Engineering *

Всем привет!

Меня зовут Никита, я 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-контексте, и это поведение - сквозная нить обеих частей.

JOIN - крайне популярная операция в SQL, о которой еще и спрашивают на 99% собеседований на программиста. Но когда начинаешь впервые разбираться с ней, то постоянно путаешься, какие таблицы соединять и когда именно.

В этой статье простыми словами и с великолепной графикой расскажу, что такое JOIN в SQL, что такое Foreign Key, какой тип JOIN когда использовать - INNER или OUTER - и зачем вообще.

Привет, Хабр! В прошлых статьях я описала, как через нововведенный параметр TSI теоретически можно определить грейд разработчика.

Привет, Хабр! Я Миша Онянов, Python-разработчик и платформенный инженер в крупнейшем проекте MAGNIT TECH – F&R. Из статьи вы узнаете, как с помощью механизма Cluster Policies в Apache Airflow вынести требования к DAG’ам в исполняемый код:

- Поговорим о том, когда и зачем нужен отдельный слой Policies.

- Посмотрим на примеры требований в больших data-инженерных проектах и способ их реализации с помощью политик.

- Покажу нашу архитектуру, примеры кода и способы внедрения.

- Сделаем выводы из моих ошибок, допущенных при разработке и внедрении.

- В конце посмотрим, в каких ещё системах используется аналогичный механизм.

Материал будет полезен всем, кто собирается внедрять или уже работает с Apache Airflow ✌️🥸

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

Задача сводилась к автоматическому выявлению таких инцидентов на десятках тысяч объектов сети, используя только исторические временные ряды в ClickHouse, без вынесения вычислений во внешние системы.

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

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

Показана реализация на SQL в ClickHouse с применением паттерна Islands & Gaps для выделения инцидентов во временных рядах.

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

Построили двухконтурную систему: офлайн-обучение на XGBoost и CatBoost — и лeгкий онлайн-инференс через Flask.

Вместо одного .fit() с дефолтным лоссом внедрили K‑method — асимметричную функцию потерь. Теперь модель «боится» недолить жидкость сильнее, чем перелить, потому что в реальности эти ошибки стоят по-разному.

CatBoost лучше по удобству работы с «сырыми» категориями, XGBoost потребовал кастомного кодирования, но дал сравнимые метрики.

На малых данных (~350 строк) случайное разбиение творит хаос: метрики скачут от сида к сиду. Поэтому отбираем топ‑20 лучших random_state, а гиперпараметры усредняем частотным методом.

Весь пайплайн — от подбора параметров до прогона K‑сетки — завернули в Airflow ради повторяемости, а все эксперименты и логи складываем в MLflow.

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

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

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

На заметку всем, кто интересуется, как меняется современная разработка ПО.

Недавно Anthropic выпустил отличную статью о том, как меняется современная разработка ПО на примере трансформации подходов внутри собственной компании.

В продуктах, построенных поверх моделей распознавания речи (Automatic Speech Recognition models, ASR), качество распознавания речи напрямую влияет на пользовательский опыт.

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

Привет, Хабр! Я Дмитрий Клепиков из команды Modus. 

После прошлой статьи захотелось взять тот же стек — ИИ-агента и пару MCP-серверов — и собрать через него в нашем BI-портале DQ-шаблон. DQ здесь — это Data Quality, то есть проверка качества данных: полнота, корректность, уникальность, согласованность, актуальность и всё то, из чего потом складывается доверие к данным.

Шаблон получился не универсальным в духе «подставь любую таблицу, и всё само поймётся». Скорее универсальным оказался каркас: одни и те же этапы, одна таблица результатов, один набор отчётов, история запусков и каталог правил. А вот сами правила остаются доменными. В адресном реестре это КЛАДР, ФИАС, ГКН, кадастровые номера и нюансы вроде «ё» в названиях улиц. Для контрагентов будут ИНН, КПП и ОГРН, для продаж — совсем другой набор проверок.

В качестве тестового датасета я взял открытый Реестр адресов Москвы. Задача была такая: агент через postgres-mcp смотрит схему, выбирает проверки из каталога правил, запускает SQL, пишет результаты в dq_snapshots, а потом через modusbi-mcp собирает отчёты в портале. Ниже расскажу, как именно он шёл, что получилось на выходе и почему после такого эксперимента агенту всё равно нельзя просто верить на слово.

Сбор первичных документов из 1С, SAP и ERP из разных юридических лиц традиционно является серьезной головной болью бухгалтерии. В этой статье мы поговорим о том, как с помощью low-code платформ можно автоматизировать данный процесс и сформируем гайд по построению такого пайплайна.

Когда пайплайн отработал без ошибок, тесты зелёные, а в дашборде внезапно нули, проблема может быть не в инфраструктуре, а в отсутствии договорённостей между командами.

В статье разбираем, как data contracts помогают фиксировать структуру, правила и ответственность за данные — и почему это спасает витрины, отчёты и нервы дата-инженеров.

Привет, Хабр! Пишет команда Business Intelligence GlowByte. Каждый год мы проводим Fine Day Online – конференцию про бизнес-аналитику, где практики из разных компаний делятся честным опытом. 22 апреля собрались спикеры из сети “Галамарт”, банков Уралсиб и ОТП, а также FanRuan, и все пять докладов оказались про одно и то же: данные есть, деньги в инструменты вложены, а бизнес по-прежнему принимает решения на ощущениях.

В этом материале хотим поделиться: что обсуждали спикеры, какие цифры называли, что пошло не так и чем закончилось.

Меня зовут Андрей Рыжик, я Product Owner BI-направления в компании «Белый код». Эта статья – обзор платформы rapeed: in-memory OLAP-движка с собственным форматом хранения, нестандартной алгеброй связей между источниками и несколькими клиентами поверх единого ядра. 

Справочники МТР на крупных предприятиях ‒ это десятки тысяч строк вида «Кабель ВВГнг 3х2.5 кв.мм, серая изоляция, 100м», которые нужно разложить по атрибутам (тип, сечение, длина, цвет изоляции). Дубли, ошибки, разнородные форматы от разных поставщиков, почему это больная тема, а также подходы и методы решения, подробно разобраны в этой статье.

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