Бенчмарк бенчмарка Lakehouse-движков, в котором побеждает объективная реальность
В блоге Data Sapience, технологического партнера GlowByte, вышла крутая статья технического идеолога Lakehouse-платформы данных Data Ocean Nova Евгения Вилкова.
Недавно на Хабре вышла статья с громким заголовком “Бенчмарк lakehouse-движков, часть 1: StarRocks и Doris падают под нагрузкой, Presto аутсайдер, CedrusData быстрее всех”. В своей статье авторы из Кверифай Лабс выбрали методику TPC-DS, но вместо 99 запросов остановилась на одном, который к тому же запускается на одной машине. Обосновывается это тем, что на одном конкретном запросе нужно разобрать работу оптимизаторов. По результатам исследования делается вывод, что решение, разработанное авторами, является лучшим, в том числе для запуска одного конкретного запроса на одном узле. Давайте попробуем разобраться, действительно ли это так.
В качестве отступления замечу, что данный эксперимент не имеет ничего общего с массивно-параллельными вычислениями и Lakehouse. Архитектура раздельных вычислений предполагает интенсивный сетевой обмен не только между storage и compute, но и между узлами compute-движка. Как заметили в комментариях к оригинальной статье, с тем же успехом можно было включить в тест и MySQL. Складывается впечатление, что методика тестирования была выбрана исключительно из-за заявленных компетенций в области оптимизатора движка, а запрос – исходя из наличия собственных доработок для обработки схожего случая. Главной же целью было на частном выводе убедить аудиторию в общем выводе. Отдадим должное коллегам – они не скрывают субъективность своего отношения к упражнению.
Заинтригованы? Добро пожаловать в статью Евгения! Комментарии приветствуются.
Тестирование движков массивно-параллельных вычислений: StarRocks, Trino, Spark. Spark — с DataFusion Comet и Impala
Друзья, в блоге компании Data Sapience, партнера GlowByte, вышла новая статья, третья в цикле материалов про нагрузочные испытания вычислительных технологий массивных параллельных вычислений.
В этот раз в список решений добавляется Spark, включая работающий с технологией нативных вычислений DataFusion Comet, и набирающий популярность StarRocks.
Обеспечиваем качество данных в компании. Подборка open-source-инструментов для Data Quality
Привет, Хабр! Я Алексей Чумагин, Data Quality Team Lead Островка. В компании мы работаем с десятками источников данных: авиакомпании, отели, агрегаторы, платёжные сервисы. При этом источники постоянно обновляются: добавляются партнёры, меняются API и форматы. В таких условиях Data Quality становится непрерывным процессом, встроенным в ежедневную работу, а вовсе не стереотипным «набором тестов, которые раз в сутки что-то проверяют».
Качественные данные зависят от выстроенных процессов: автоматизации, прозрачности, быстрой реакции на инциденты. Мы смотрим на Data Quality как на живую экосистему, где тесты — лишь одна из составляющих. Исходя из этого строим в компании единую Data Quality Platform.
Архитектура нашей платформы организована вокруг следующих задач:
автоматизация создания и выполнения тестов;
их централизованное хранение;
визуализация результатов;
мгновенное оповещение команд об инцидентах.
Вся эта экосистема работает в едином ритме с основными data-процессами компании.
Ниже — подборка инструментов, из которых состоит наша платформа. Их легко внедрить и в других IT-компаниях: стек масштабируемый, гибкий и не требует больших затрат на лицензии.
Какие инструменты мы используем в Data Quality
1. Ядро и автоматизация
В качестве ядра системы мы выбрали Soda Core — движок, который позволяет формализовать правила качества: целостность, уникальность, диапазоны значений. Тесты описываются декларативно, что упрощает поддержку и масштабирование.
После того как тесты написаны, их запуск и оркестрацию мы доверяем Apache Airflow. Он автоматически запускает проверку после ETL-процессов, управляет зависимостями и расписанием, что критично для стабильной работы пайплайнов.
Чтобы не тратить время на рутинное написание DAG’ов для новых тестов, мы используем DAG Factory — генератор DAG’ов, позволяющий держать код тестов и их запусков в едином месте, легко масштабировать количество проверок.
2. Интеграция и доступ
Важной частью платформы стала интеграция с другими системами. Для этого мы подняли сервисный слой на FastAPI: через API можно запускать тесты, получать результаты, интегрировать платформу с внешними инструментами.
Для визуализации выбрали Streamlit — он позволяет быстро собирать дашборды и интерактивные отчёты, которые особенно удобны инженерам для экспресс-проверок и разбора логов ошибок.
Но не все участники процесса хотят разбираться в технических деталях. Менеджеры и аналитики зачастую предпочитают DataHub — каталог метаданных, где хранятся все проверки, их результаты, а также информация о таблицах, lineage и пайплайнах. Это позволяет сделать качество данных частью общего ландшафта данных компании.
3. Оперативность и реакция
Все алерты и уведомления о результатах тестов автоматически отправляются в корпоративный мессенджер, чтобы команды могли оперативно реагировать на проблемы.
Вся DQP-платформа развернута в Kubernetes, — это обеспечивает масштабируемость, отказоустойчивость и централизованное управление компонентами.
И почётное упоминание ещё одной неизбежно важной технологии: для ручных ad-hoc-проверок мы, конечно же, используем старый добрый SQL. Без него ни одна оперативная сверка или исследование гипотез не обходится.
Итого: наш Data-Quality-стек — это комбинация проверенных open-source-инструментов, которые удобны на практике: легко автоматизируем тесты, быстро видим результаты, интегрируемся с чем угодно и не особо беспокоимся о лицензиях. Всё масштабируется, поддерживается инженерами, а не только админами и даёт нам уверенность в качестве данных, даже когда вокруг всё меняется.
А какие инструменты используете вы для контроля качества данных? Что бы вы добавили или изменили в нашем подходе? Будем рады обсудить в комментах!
OutBoxML: как мы построили свою ML‑платформу от архитектуры до продакшена
Если вы хоть раз выводили ML‑модель в прод, то знаете этот сценарий.
Папки final_final_v2, десятки Python‑скриптов, неотслеженные версии данных, ручной деплой на сервер, и тревожное чувство, что «где‑то что‑то точно отвалится».
Со временем даже хорошо построенный ML‑процесс превращается в хаос — набор несовместимых пайплайнов и моделей, где каждый инженер решает задачу по‑своему.
Мы столкнулись с этим тоже. Но вместо того чтобы латать процессы по частям, мы решили построить собственную ML‑платформу OutBoxML — систему, которая централизует всё: от обучения и управления фичами до продакшн‑деплоя и мониторинга качества моделей.
OutBoxML — это не концепция на слайдах, а реальный проект, который мы внедрили в продакшн, чтобы стабилизировать и масштабировать ML во всём ИТ‑контуре Страхового Дома ВСК.
В серии из трёх статей на Хабре наши инженеры подробно разбирают, как мы прошли путь от архитектуры до продакшена, какие решения приняли — и какие ошибки помогли нам вырасти.
Решение: платформа OutBoxML
Мы не остановились на обёртках вокруг сторонних инструментов — мы создали OutBoxML: платформу, способную управлять жизненным циклом моделей от разработки до стабильного продакшена.
Мы шаг за шагом описываем во всех трёх статьях, как родилась архитектура, как устроен компонент работы с признаками и как устроена надёжность при выводе моделей.
В первой статье мы показываем конструкцию ядра OutBoxML и обоснование архитектурных подходов.
Ключевой технический инсайт: мы ушли от монолитных систем и отдали предпочтение сервисам с чёткими границами ответственности, использованию событийной коммуникации и контейнеризации.
Мы описываем принципы маршрутизации данных, версионирования и взаимодействия между сервисами, а также как обеспечиваем воспроизводимость экспериментов.
Машинное обучение в страховании — это не только про красивые метрики на этапе тестирования. Самая большая проблема приходит позже, когда модель выходит «в прод»: данные начинают меняться, и точность предсказаний падает. Это явление называется Data Drift. В статье мы делимся практическим опытом:
как диагностировать дрифт с помощью PSI‑метрики;
как использовать SHAP‑анализ для переосмысления модели;
чем отличается модель «с дрифтом» от модели «без дрифта» на реальных страховых данных.
Мы показываем не теорию, а эксперимент с открытым кодом и цифрами: какие признаки пришлось исключить, как изменилась логика модели и что это дало бизнесу на практике.
Совсем скоро выйдет заключительная статья нашего первого цикла open source проекта OutBoxML!
Присоединяйтесь к нашему проекту на GitHub и в Telegram. К тому же, библиотека опубликована в pypi и доступна к установке через pip install outboxml
Пишите в комментариях, о каких аспектах автоматизации ML вам хотелось бы узнать подробнее. Удачи в реализации ваших проектов!
Про AI-ускорение рутины разработчиков, которого... НЕТ! ч.3. В предыдущих частях мы смотрели годные исследования от том, как AI влияет на результаты работы, со стороны самого разработчика (раз, два).
А теперь быстро посмотрим на результаты труда разработчиков! Ведь бешеный прирост эффективности (которого нет) должен быть виден невооруженным взглядом.
1️⃣ Если легко завайбкодить простые приложения, то они должны наводнить сторы. Statista говорит нам, что никакого прироста нет ни в App Store, ни в Google Play. Нет всплеска ни количества новых доменных имен, ни количества игр в Стиме.
То есть даже у индихакеров нет никаких «закодил приложение за три дня, люди пользуются». Но наверняка есть «три дня вайбкодил, но давать пользоваться таким нельзя».
2️⃣ Более того, нет даже значимого прироста числа github репозиториев! А ведь с революционной технологией разработчики должны запускать сайд‑проекты намного быстрее.
Данные из innovation graph, по которому можно проанализировать даже пики ru‑релоканотов в эмигрантских лимбах 🙂 (пост).
3️⃣ То есть подавляющее большинство говорящих о 10х эффекте от вайбкодинга и кодинга с AI никогда не пробовали ни вайбкодить, ни писать код. В работе это может выглядеть так: менеджер предлагает внедрять AI кодинг инструменты (все же внедряют!) А на деле это ведет к снижению эффективности труда разрабов в компании.
4️⃣ CEO Notion недавно рассказал The Wall Street Journal, что до AI маржинальность продукта была 90%, а после добавления AI фич упала до 80%. Проще говоря, они как лидеры рынка были обязаны добавить фичи, но в итоге теряют на этом деньги (бурного прироста пользователей из-за AI нет).
5️⃣ В реальном айтишном мире написание кода никогда не было узким местом создания софтверных продуктов. И мы сегодня видим на рынке, что AI инструменты скорее дают ощущение эффективности, а не саму эффективность.
Потому что в измеряемых результатах работыпрограммиста прирост из-за AI довольно спорный.
6️⃣ В посте про AI агентов я предложил на любую реплику AI энтузиаста просить записать скринкаст того, что у него круто работает (кстати в комментах НИКТО из энтузиастов не смог этого сделать).
А на реплики индихакеров про эффективность кодинга с AI можно просить показать, что они накодили.
Привет! Меня зовут Александр Егоров, я MLOps-инженер в Альфа-Банке, куда попал через проект компании KTS. За свою карьеру я построил четыре ML-платформы (одна из которых сейчас в Росреестре) и развиваю с командой пятую. Недавно мы полностью пересобрали пайплайны и мигрировали c Airflow на Argo Workflows + Argo CD. Делимся подробностями!
Airflow отлично подходит для десятков DAG’ов, но на масштабе сотен моделей появляются проблемы: всё усложняется, теряется Kubernetes-нативность, GitOps работает через костыли, а обновления DAG’ов становятся ручным трудом. Версионирование ломается, пайплайны идут десятками минут, и отлаживать их настоящая боль.
Почему Argo Workflows?
Argo — это K8s-native решение, декларативный подход, совместимость с GitOps, простейшее развертывание и минимум лишних компонентов. Для нас это был буквально глоток свежего воздуха. Вместо монолитного Kubeflow — один контроллер, никаких лишних слоёв и масштабируемость из коробки
Строительные автопилоты: почему данные становятся главным активом строительства.
Автоматизация в строительной отрасли становится массовой и доступной, и её ценность всё меньше в самих технологиях, а всё больше — в данных, которыми они управляют.
За последние 30 лет CAD/BIM фактически превратились в инструмент ручной разметки строительной реальности: инженеры и архитекторы создавали базы элементов зданий и сооружений, превращая чертежи и 3D-модели в структурированные датасеты.
То, что Google, Tesla или Waymo делали силами миллионов студенто-часов, размечавших вручную изображения с людьми и объектами, в строительстве десятилетиями заполняли инженеры проектировщики в специальных базах слабоструктурированных данных AutoCAD или структурированной базы данных Revit или ArchiCAD.
Именно эти массивы станут сырьём для «строительных автопилотов» — систем, способных автоматически расставлять элементы в пространстве проекта и рассчитывать стоимость, сроки и ключевые параметры новых проектов. Как LLM обучаются на массиве текстов, чтобы генерировать новые знания и целые приложения, так и в строительстве мы сможем с помощью AI и workflow использовать опыт тысяч реализованных проектов, чтобы проектировать и планировать новые проекты быстрее и точнее. У отрасли есть лишь десятилетие, чтобы превратить накопленный опыт в основу будущих систем. После этого рынок займут те, кто сумел первым построить собственные «автопилоты».
Но сами по себе автопилоты, AI-модели и процессы автоматизации ничего не стоят без качественных данных. Именно уникальные, хорошо структурированные наборы данных станут главным активом компаний. Их невозможно скопировать или купить, в отличие от софта или подрядчиков. Настоящее конкурентное преимущество даёт не программа, а налаженный конвейер по сбору, очистке и обогащению собственных данных.
Но сами по себе автопилоты, AI-модели и процессы автоматизации ничего не стоят без качественных данных. Именно уникальные, хорошо структурированные наборы данных станут главным активом компаний. Их невозможно скопировать или купить, в отличие от софта или подрядчиков. Настоящее конкурентное преимущество даёт не программа, а налаженный конвейер по сбору, очистке и обогащению собственных данных.
В ближайшие годы ключевой задачей строительных компаний станет не создание проектов как таковых, а системная подготовка и капитализация своих или приобретённых массивов данных. Те, кто начнёт этот процесс сейчас, получат собственных «автопилотов»-агентов. Остальным придётся довольствоваться чужими.
Хотите обсудить новые пайплайны автоматизации, поделиться своими кейсами или получить помощь? Больше примеров автоматизации вы можете найти в репозитарии на GitHub или в нашем телеграмм чате "n8n Development | Практика автоматизации и готовые решения" Присоединяйтесь к нашему Telegram-сообществу для живых обсуждений, советов и эксклюзивного контента.
# transform.py
def calculate_age(birth_date, row_data, table):
from datetime import datetime
if not birth_date:
return None
birth = datetime.strptime(birth_date, '%Y-%m-%d')
return (datetime.now() - birth).days // 365
def format_phone(phone, row_data, table):
if not phone:
return None
# 79991234567 -> +7 (999) 123-45-67
return f"+7 ({phone[1:4]}) {phone[4:7]}-{phone[7:9]}-{phone[9:11]}"
Запуск
# Установка с GitHub
pip install git+https://github.com/tumurzakov/myrepetl.git
# Или клонировать и установить локально
git clone https://github.com/tumurzakov/myrepetl.git
cd myrepetl
pip install -e .
# Запуск с конфигом
myrepetl run config.json
# Или через Docker
docker run -v ./config.json:/app/config.json myrepetl:latest
ML Impact — рассказываем, как компании внедряют ML и что из этого получается
Мы запустили ресурс о том, как эффективно использовать искусственный интеллект в рабочих задачах. Уже доступны материалы про настоящую роль ИИ в автоматизации и работу EDGE AI. Скоро появятся новые статьи!
Их можно использовать, чтобы обосновать коллегам или руководству целесообразность запуска ML-проекта. У вас под рукой будет готовый ресурс, которым можно просто поделиться — вместо тысячи слов и долгих объяснений.
Три способа сформировать идентификатор пользователя.
Привет, меня зовут Рамис и я работаю дата-аналитиком в Garage Eight. Так как аналитики довольно часто (почти всегда) используют id пользователя для объединения таблиц, я хочу рассказать о различных способах формирования идентификатора пользователя (user_id, id, account_id и пр.).
Первый способ, который приходит на ум — это инкрементальное увеличение id пользователя, также известный как последовательный или автоинкрементный ID. То есть самый первый пользователь будет иметь id = 1, следующая регистрация 2 и так далее. Вроде бы идеально?
Плюсы:
Уникальность.
Порядок регистрации.
Простота реализации.
Минусы:
Требуют централизованного управления, что может замедлять работу при масштабировании.
Предсказуемы (идут по порядку), что может быть небезопасно, ведь злоумышленники могут угадать ID. Для генерации нового ID часто нужно обращаться к базе данных (БД), что увеличивает нагрузку.
В шардированных или реплицированных БД могут возникать конфликты и задержки в генерации ID. Невозможно встроить дополнительную информацию (например, временные метки или идентификаторы сервисов).
Кстати, проблему шардирования можно частично решить следующим образом: id увеличивается не на 1, а на число k, равное количеству используемых БД.
Второй способ — UUID, или универсально уникальный идентификатор (Universally Unique Identifier), — это 128-битное число.
Плюсы:
Уникальный, почти никогда не повторяется.
Генерится где угодно, не нужна база данных.
Не угадать, особенно, v4 и v7.
Для больших систем, так что хорошо подходит для микросервисов.
Третий способ — Twitter snowflake id (теперь X) — это система генерации уникальных 64-битных идентификаторов для объектов, таких как твиты, личные сообщения, пользователи и списки.
Бит знака — всегда равно 0 и зарезервировано на будущее.
Временная метка — количество миллисекунд, прошедших с начала эпохи UNIX.
ID ЦОД дает нам 2 ^ 5 = 32 центра обработки данных.
ID компьютера дает нам еще 2 ^ 5 = 32 компьютера в каждом ЦОД.
Номер последовательности.
При генерации каждого id на отдельно взятом компьютере или процессе номер последовательности инкрементируется на 1, каждую миллисекунду этот инкремент обнуляется.
Плюсы:
Уникальность.
Распределенная генерация.
Можно сортировать.
Эффективность. 64-битный формат обеспечивает достаточную ёмкость для идентификаторов, а также эффективную обработку данных.
Простота. Логика генерации Snowflake довольно проста для понимания и реализации.
Популярность. Идентификаторы Snowflake широко используются, что облегчает интеграцию с различными системами и библиотеками.
Минусы:
Ограничение по времени. Максимальная точность Snowflake — миллисекунды, что может быть недостаточно для некоторых приложений, требующих большей точности.
Риск переполнения. При очень высокой скорости генерации идентификаторов существует риск переполнения порядкового номера, что может привести к потере уникальности.
Зависимость от синхронизации времени. Точность временной метки зависит от синхронизации времени на серверах.
Сложность в распределенных системах. При неправильной настройке распределенной системы могут возникать проблемы с уникальностью идентификаторов.
Необходимость управления идентификаторами машин. Каждой машине, генерирующей идентификаторы, необходимо присваивать уникальный идентификатор.
На этом все, но это неполный список, есть еще сервер тикетов и прочие.
Информацию взял из книги «System Design. Подготовка к сложному интервью», Алекс Сюй.
Как ИИ повышает эффективность email-маркетинга: цифры и аналитика
Искусственный интеллект трансформирует email-маркетинг, делая письма точнее и эффективнее. ИИ анализирует данные о поведении клиентов - от истории покупок до времени открытия писем - и создаёт персонализированные предложения. Например, система может предложить клиенту товар, который он искал, или отправить письмо в момент, когда он наиболее активен.
Результаты говорят сами за себя: исследования показывают, что персонализация с ИИ повышает открываемость писем до 47%, кликабельность (CTR) - до 27%, а повторные покупки - на 31%. Аналитика ИИ выявляет, какие заголовки работают лучше, и оптимизирует кампании в реальном времени, сокращая затраты на тесты.
Как ИИ мог бы усилить ваши email-кампании? Поделитесь мыслями в комментариях!
Выпущена новая версия СУБД Picodata — Picodata 25.3
Компания Picodata (входит в Группу Arenadata) выпустила новую версию СУБД Picodata — Picodata 25.3. Обновление включает расширенные возможности SQL, механизм автоматического обновления схемы данных, а также повышение стабильности кластера.
Улучшение обратной совместимости
В Picodata 25.3 реализовано автоматическое обновление схемы данных при переходе инстансов на новый релиз Picodata. Этот механизм учитывает сделанные изменения в системных таблицах и сохраняет обратную совместимость при обновлении на следующий релиз СУБД: при переводе кластера на новую версию Picodata необходимые DDL/DML-команды выполнятся без вмешательства администратора, а требуемые в новой схеме внутренние функции также будут созданы автоматически.
Новые возможности SQL
В релиз добавлены новые возможности языка SQL в Picodata, в частности:
поддержка NULLS FIRST/LAST при сортировке результатов запроса (ORDER BY);
обработка конфликтов при вставке данных в глобальные таблицы (INSERT INTO … ON CONFLICT DO FAIL/REPLACE/NOTHING);
оператор % для определения остатка деления по модулю для целых чисел;
возможность определения лидера raft-группы через функции pico_raft_leader_id() и pico_raft_leader_uuid();
возможность определения версии текущего инстанса с помощью функции version();
изменение, связанное с совместимостью: вместо скалярной функции instance_uuid (которая теперь объявлена устаревшей), рекомендуется использовать новую функцию pico_instance_uuid.
Улучшенная совместимость с PostgreSQL
Picodata теперь поддерживает безопасное соединение при обращении к внешнему LDAP-серверу. При подключении через протокол PostgreSQL (например, с помощью клиента psql) с методом аутентификации LDAP можно задействовать TLS-шифрование (при условии, что оно включено на LDAP-сервере). На стороне Picodata для этого потребуется установить значения у трёх переменных окружения. Например:
Добавлен новый параметр instance.pg.advertise — публичный адрес сервера для подключения по протоколу PostgreSQL. По умолчанию, его значение соответствует значению instance.pg.listen. Этот параметр пригодится в ситуации, когда снаружи инстанс доступен по адресу, отличающемуся от адреса во внутренней сети.
Улучшенный веб-интерфейс
Команда Picodata продолжает развивать компонент webui для Picodata. В версии Picodata 25.3 веб-интерфейс не просто выглядит лучше, он также стал удобнее и информативнее:
на панели Cluster ID отображается больше полезной информации, включая список включённых плагинов;
в области просмотра сведений об инстансе теперь присутствует адрес подключения по протоколу PostgreSQL.
Механизм плагинов
При подключении плагина к кластеру Picodata теперь допускается расхождение минорных версий плагина и инстанса (например, плагин, собранный для версии 25.3.1, будет работать в Picodata 25.3.2).
Automate Your Daily Tasks in 10 Minutes: A Practical Guide to n8n for Beginners
Until 2022, I thought automation was only large companies. But in 2022 I discovered n8n, and everything changed. Now, I automate routine work, reports, and even whole business processes—sometimes in under 10 minutes. Here’s how it works, what surprised me, and what you can try today.
In 2022, I deployed n8n on a separate VPS to demonstrate the ability to process design data from Revit and show that it's like working in Dynamo or Grasshopper, but for data managers and automation pipelines outside of Autodesk products.
But it was hard to get experts interested in 2022 - at the time, n8n was still in its early stages: there were no Python nodes, no LLM integration, and most workflows took weeks to create, relying on scattered blog posts and incomplete examples on forums.
Fast forward to 2025, and everything has changed.
Today, thanks to native LLM nodes, you can simply ask ChatGPT, Claude, or any advanced AI assistant to generate automation n8n pipelines — whether for validating parameters or producing custom QTO tables — and get ready-to-run workflows in seconds.
Why Bother with Automation?
Let’s be honest: most “office work” is repetitive. Copy-paste, renaming files, sending the same email—again and again. It’s boring and, more importantly, wastes hours every week. For me, automation started as an experiment, but quickly became a must-have. Once you automate your first task, you won’t want to go back.
What is n8n and Why Use It?
n8n (pronounced “n-eight-n”) is a free, open-source tool for automating anything—emails, file operations, notifications, even AI tasks. The best part? No coding needed. You just drag, drop, connect blocks, and press play. It runs on Windows, Mac, or Linux. I set up my first workflow in under 15 minutes.
How I Got Started (And You Can Too)
Install Node.js (from the official site, takes 2 minutes)
Install n8n with one command
Open n8n in your browser (local or online)
Start building: drag blocks (“nodes”) to connect apps, add logic, or even call ChatGPT to write emails for you!
The next “wow moment” for me was connecting n8n to AI tools like Claude and ChatGPT. Need to generate text, analyze data, summarize, or respond to messages? Just add a ChatGPT node—no API coding, just your prompt.
Short on time? n8n has a big library of ready-made templates. You can find workflows for almost any need: document processing, cloud backups, database syncs, even advanced stuff like BIM/CAD data processing. Grab a template, tweak it for your needs, done.
Lessons Learned and Tips
Don’t overthink: Start simple. Even automating one small task (like downloading attachments from email) pays off.
Debug as you go: n8n makes it easy to see where something breaks—just follow the logs, tweak, and re-run.
Experiment: The community is active and shares real-life examples. Some of my best workflows came from GitHub repos or the official n8n library.
Combine tools: I use n8n with spreadsheets, databases, cloud storage, and AI. Everything connects!
Why You Should Try It
After a few weeks, I realized how much time I was saving. Reports that took 30 minutes now take 2. Integrations that seemed impossible (like sending BIM data to a spreadsheet, then to Teams) were suddenly simple.
Automation isn’t just for techies anymore. With tools like n8n, anyone can build and run real workflows—saving hours, reducing errors, and focusing on what really matters.
Repeater - планировщик для анализа данных, упрощенный Apache Airflow.
Repeater запускает задачи по расписанию. Задачи - последовательности консольных программ - описываются в toml-файлах. Запуски отображаются в веб-интерфейсе.
Пример задачи - запуск скриптов wiki_stats.py и wiki_pageviews.py импорта верхнеуровневой статистики Википедии в локальную базу.
title = "wiki"
cron = "0 55 * * * *"
[[tasks]]
name = "wiki_stats"
cmd = "python3 ./examples/wiki_stats.py"
[[tasks]]
name = "wiki_pageviews"
cmd = "python3 ./examples/wiki_pageviews.py --end_date={{.scheduled_dt}}"
git clone https://github.com/andrewbrdk/Repeater
cd Repeater
docker compose up --build
В примерах импорт количества просмотров страниц Википедии, курса биткоина, статистики репозитория Линукса на Гитхабе. Графики в Streamlit http://localhost:8002 .
Интересны применения проекта. Попробуйте! Впечатления пишите в комментариях. Спасибо!
Кто-то боится регулярных выражений, а потому избегает их. Кто-то пользуется этим инструментом и решает с его помощью сложные задачи. Мы подумали, что хорошо бы собрать полезные статьи по этой теме в одном месте и помочь читателям избавиться от «регекспофобии». Ну или, наоборот, усугубить ее — тут уж как получится.
В курсе разберем не только базовый синтаксис, но и осветим темы посложнее. Посмотрим даже, как можно комментировать регулярки в движках, которые не поддерживают такую функциональность. Уделим особое внимание работе с кириллицей. Все разбираем на примерах.
После изучения материалов вы сможете:
моментально извлекать данные из гигабайтов текста;
валидировать формы любой сложности;
правильно обрабатывать тексты на русском (никаких сломанных \b);
решать сложные задачи с помощью lookarounds и именованных групп;
повысить свой уровень в работе со скриптами и редакторами.
Все материалы бесплатные. Не требуется даже регистрация.
Рассказывает Слава, инженер машинного обучения в ЮMoney.
У нас в компании много данных, которые можно обрабатывать, чтобы улучшать пользовательский опыт. Например, данные пользовательских обращений ЮKassa из разных каналов: чатов с техподдержкой, почты, звонков в колл-центр.
Мы передаём тексты из обращений модели, которую обучили относить их к определённому классу (подключение СБП, вопросы по возвратам, платёжным методам и т. д.). Постоянно появляются новые темы, поэтому приходится регулярно дополнительно обучать модель. Разбив все поступающие обращения по группам, можно оценить их количество и построить дашборд.
Если по одной теме у нас пять тысяч обращений, по второй — десять тысяч, а по третьей — всего два, значит, нам нужно уделить особое внимание первым двум.
В классификаторе пользовательских обращений мы используем языковые модели типа BERT. Также развиваем использование больших языковых моделей (LLM). У них много знаний «из коробки», они не требуют дообучения и могут применяться для разных задач. Есть и недостатки (требовательность к вычислительным ресурсам или галлюцинации), но LLM способны выполнять задачи намного быстрее, чем человек.
Ещё одно интересное направление Data Science, которое мы тестируем, — распознавание изображений и классификация по категориям. Сейчас мы решаем эту задачу с помощью модели clip, но планируем проверить эффективность работы visual LLM, например Qwen-VL. Этот вид моделей анализирует изображение и даёт текстовое описание, которое можно использовать в продуктах, например при проверке сайтов, которые подключаются к ЮKassa.
Также LLM хорошо выполняет задачи написания саммари — например, по итогам проведённой встречи. Предварительно отдельная модель (у нас это Whisper) переводит аудио в текст, что сильно ускоряет работу коллег.
***
Делитесь в комментариях, есть ли команда Data Science в вашей компании и какие задачи она решает. 🙌 А также следите за нашими новыми материалами о том, как технологии меняют финтех изнутри. Впереди ещё много интересного!
Давненько не было постов! Теперь посты будут выходить намного чаще, поэтому ждите интересный контент! Сегодня хочу с Вами поделиться своими наблюдениями по самым распространенным страхам при входе или же в начале карьеры в IT, а также конечно же расскажу, как с ними бороться!
Поехали!
Большие деньги - большая ответственность, я еще немного поучусь и можно ходить на собеседования
Самое частое заблуждение и страх - это то, что я не до конца изучил материал и мне рано идти на собеседования. IT действительно кажется сложной сферой, особенно на старте. Куча непонятных терминов, новые технологии, быстрая смена трендов. Главное — не пытаться сразу охватить всё. Дроби путь на маленькие шаги: сначала разберись в основах, потом усложняй задачи.
Признайте, что никто не знает всего, даже сеньоры постоянно гуглят и учатся. Учись радоваться прогрессу, пусть даже небольшому — это отличный способ победить страх перед сложностью. Я часто на работе вижу людей, которые знают намного меньше меня, но при этом зарабатывают больше денег. Думаете, что они думают про это?
Убейте в себе внутреннего "отличника", который хочет всё идеально знать. Начните действовать как можно раньше, ведь главный наш ресурс - это время. Если не начнете ходить по собеседованиям сейчас, то потом может стать поздно!
Я слишком стар/молод/у меня нет профильного образования
Это миф. В IT реально можно войти в любом возрасте и с любым бэкграундом. Большинство компаний смотрит на твои навыки и то, как ты решаешь задачи, а не на диплом. Например у меня еще ни разу не спрашивали про мой диплом и про моё образование, но при этом огромное кол-во людей верит в то, что реально нужен крутой бэкграунд, а не опыт. Важно показывать интерес к профессии, прокачивать навык прохождения собеседований, учиться продавать себя на рынке труда и тогда у Вас всё получится! Как говорил Олег Тинькофф: "Продай свои мозги дорого". Это очень хорошо описывает в целом текущее состояние рынка.
Я буду выглядеть глупо среди опытных коллег Это нормально — не знать и ошибаться, особенно в начале. Важно не бояться задавать вопросы. В IT очень развита культура поддержки: тебе скорее помогут, чем осудят. Воспринимай каждую ошибку как точку роста, а не как провал. Ведь наш опыт - это сумма всех наших ошибок. Думаете, что какой-то сеньор никогда не допускал ошибок?
Я не найду работу без опыта От каждого второго человека слышу это. Мол я не могу найти работу без опыта, всё дело в опыте! А потом я открываю его резюме и вижу, что там полная каша и оказывается, что дело не в опыте, а в резюме или же в чём-то другом. Не бойтесь искать любую возможность попробовать реальные проекты. На старте важно показывать свою мотивацию и учиться командной работе. Не стесняйся писать в компании напрямую, предлагать свою помощь за отзыв или за опыт — так много кто стартует.
Теперь дам общие советы, которые подойдут под любой Ваш страх. Но помните, что я Вам даю всего лишь отмычки, а Вы их уже сами подбираете под Ваши "проблемные" двери:
Разделяй путь на маленькие задачи и радуйся каждому шагу.
Найди ментора, чтобы не оставаться один на один с вопросами.
Веди дневник успехов — записывай даже маленькие победы.
Не сравнивай свой путь с другими, особенно в соцсетях — у каждого свой старт и темп.
Признай: страх — это нормально. Его испытывали все, кто сегодня работает в IT.
Понравился пост? Тогда переходите ко мне в телеграмм канал, там находится много полезного материала, для входа в IT!
В начале был датасет, и был он в уме дата-инженера, и имя ему было Хаос...
В мире машинного обучения термин «датасет» звучит примерно из каждого утюга, и даже если ваша сфера не ML, вы наверняка догадываетесь: это какой-то набор данных. Вот только какой именно — сильно зависит от задачи. Порой один датасет похож на другой примерно как кактус на ёлку: что-то зелёное и колется.
Часто в начале данных нет вовсе, и их приходится создавать вручную, искать в открытых источниках или генерировать синтетически, а иногда комбинировать подходы. Упорядочить хаос — задача не из лёгких, особенно если вы создаёте кастомный датасет под конкретную модель.
От чего зависит структура датасета? Если коротко: буквально от всего.
Поставленная задача, тип данных, структура, формат аннотаций, объём, качество, наличие разметчиков или доступа к "умным" моделям и даже количество «мусора» — всё это влияет на итоговую структуру. Например, даже для такой относительно несложной задачи, как обучение чатбота для покупок товаров, мы иногда работаем с:
Парами «вопрос–ответ». Такой вариант был хорош на раннем этапе разработки.
Триплетами (вопрос + хороший и плохой ответ, чтобы модель точно знала, что НЕ нужно отвечать) - такой формат хорошо заходит reasoning-моделям, когда мы ожидаем от модели более сложного поведения и умения задать вопрос, быстро "отсекающий" нерелевантный товар или неважные признаки.
Пользователь: хочу морковь
Ответ A: вам мытую или обычную? Ответ B: скока вешать в граммах?
Предпочтение: ответ A
Примеры разных типов датасетов
📸 Computer Vision
Датасеты для задач компьютерного зрения. Картинки котиков, людей и машин (ImageNet) и (MS COCO). Учим ИИ отличать милую чихуахуа от маффина. Например, ImageNet содержит более 14 млн размеченных фотографий, а MS COCO — изображения с детальными аннотациями сцен.
Новый релиз от Яндекса — YAMBDA на Hugging Face, анонсирован в посте на Хабре. Это 500 млн взаимодействий с музыкальным контентом, включая признаки и флаги «рекомендовано/нет».
Чем он интересен:
Использует эмбеддинги вместо аудио
Подходит для обучения RecSys моделей в «индустриальных» условиях
Поддерживает архитектуры с input context (история прослушиваний)
🩺 Медицина
MIMIC-CXR — крупный публичный датасет рентгеновских снимков грудной клетки с диагнозами и метками. Один из главных бенчмарков в медицинском CV.
Проблемы: сложная лексика, разнообразие патологий, неполные аннотации. Такие датасеты часто требуют пост-обработки, аннотации врачами и серьёзного контроля качества.
📊 Табличные данные для задач логистической регрессии
UCI Adult — классика для бинарной классификации (доход >50K или нет). Здесь встречаются числовые и категориальные признаки. Часто используется для обучения простых моделей и feature engineering.
Именно такие данные лежат в основе скоринговых систем банков. Да-да, когда вы подаёте заявку на ипотеку, зачастую не человек, а модель принимает первичное решение на основе ваших параметров. ИИ тихо решает судьбу вашего жилья и кошелька.
🤖 Робототехника и сенсоры
KITTI Dataset — реальная дорожная обстановка с камеры, лидара и GPS. Используется в задачах:
Детекции объектов
3D реконструкции
SLAM и навигации
Датасеты для роботов — одни из самых тяжёлых по объёму, синхронизации и сложности синтеза сигналов.
По мере развития технологий модели обретают мультивозможности, и датасеты тоже усложняются…А как же понять, какой датасет подойдёт именно для вашей задачи?
Готовясь к обучению модели, важно помнить: 80% успеха — это грамотный датасет, причём не только по составу данных, но и по их комбинации и оформлению, подходящий под задачу. Гонка за модными тенденциями или применение готовых шаблонов тут вряд ли помогут.
В следующих постах разберу:
Можно ли полностью нагенерировать диалоговые датасеты синтетически - умными моделями типа О3 без проверки человеком.
Остальные 20% успеха в обучении модели;) Это будет не совсем про ML.
Я Павел Денисенко, отвечаю за развитие дата-платформы в X5 Tech!
Редко публикую тут посты (никогда), но сейчас не могу не поделиться новость о том, что наша команда CDO X5 Tech впервые участвует в Data Fest — главном событии года для сообщества Open Data Science!
В один из дней, 1 июня, мы принимаем фестиваль у нас в гостях, и это событие нельзя пропустить!
Наша программа будет насыщенной и интересной. Мы будем рады поделиться опытом X5 Tech с сообществом дата-экспертов. Наши эксперты поделятся докладами на самые актуальные темы в области инженерии данных и искусственного интеллекта. С участием признанных экспертов индустрии Data и ML в Retail мы поговорим о том, как данные меняют сферу ритейла и не только ее.
Но это еще не всё! В нейтральных секциях мы также поговорим о таких темах, как Advanced LLM и ML in Music. Узнаем, как большие языковые модели находят применение в разных сферах и что происходит на стыке машинного обучения и творчества.
🌟 И, конечно, не обойдется без неформальной части: холиварные зоны для тех, кто точно знает, как правильно, и вечеринка после официальной части для самых стойких.
📍 Где и когда? 1 июня, Москва, Loft Hall.
Data Fest 2025 — must visit для всех, кто интересуется работой с данными и хочет лучше понимать, как информационные технологии меняют бизнес и помогают в работе. Мест немного, так что успевайте зарегистрироваться по ссылке!
Не упустите шанс стать частью этого восхитительного события! Ждем вас!
