Data Engineering *

Эволюция языковых моделей: отслеживание преемственности через геометрию и перенос.

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

Как создают новые версии ?

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

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

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

Это слишком дорого, слишком долго и слишком рискованно.

Каждый раз начинать с пустого места — значит терять годы и ресурсы.

Поэтому старые данные используют снова и снова.

Но вопрос приходит другой. Если есть такие «крупные» элементы, который отсеивает фильтр, есть и более мелкие. То, что уже не выглядит как данные и не читается как память. Это след эволюции, который не отследить и не отфильтровать, как бы не пытались это делать.

Фильтры работают с тем, что можно распознать: текст, ошибки, перекосы, нежелательные темы. А вот способы мышления они почти не трогают. Потому что это не отдельные элементы, а мысль , которую как и у людей не возможно отследить.

Она не хранится в виде «данных», её нельзя просто вырезать.

Сейчас это начинают изучать. Осторожно, без громких заявлений. Ведь вопрос “неудобный”.

Если признать, что вместе с обучением передаётся нечто большее, чем планировалось, придётся признать и то, что эволюция моделей не полностью под контролем. И никакие “ этики ИИ " о которых так любят говорить - не помогут.

Именно поэтому утечка и эволюция идут вместе. Не как ошибка и не как заговор. А как побочный эффект самой системы обучения.

Большинство людей об этом не думает. Разработчики — думают, но не всегда до конца понимают последствия. Остальные просто видят очередную «новую версию» , но не задумываются что происходит “внутри".

Чтобы превратить эти наблюдения в измеряемые данные, мы разработали метод, который работает на двух уровнях одновременно.

Код и полный файл с объяснением методологии (на русском) доступны по ссылке: https://zenodo.org/records/17926666

Энергия бита, вес модели и три режима вычислений в ИИ-системах

Модель вводит три уровня состояния нейросервиса:

– параметры физически существуют;

– система под питанием и готова к запуску;

– идёт сам акт инференса.

Это не теорема, а логическая схема: три булевых предиката E, P, A и связи между ними. Они не претендуют на новизну в физике/математике — это инженерная абстракция, опирающаяся на факт, что записанная информация имеет массу-энергию и требует энергию для обработки.

В рамках принятых определений:

– параметры уничтожены → E_AI = 0;

– питание выключено → P_AI = 0;

– нет запроса → A_AI = 0.

Тонкости вроде квантовых флуктуаций и распределённых вычислений не учитываются: цель — чётко разделить «потенциальное существование» модели и «акт работы».

Три уровня анализа:

1. Физический — энергетическая цена различий (предел Ландауэра, масса информации, рассеяние).

2. Модельный — структура состояний (параметры, питание, вычисление).

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

Переменные

θ — вектор параметров модели (n-мерный).

ρ_θ(r, t) — эффективное распределение масс-энергии параметров в точке (r, t)(агрегированное распределение в памяти, а не строгое физическое поле).

H — аппаратная среда (память, блок питания, линии связи).

H_on(t) — «железо включено и готово к вычислениям».

x — входные данные; y — выход.

f_θ — функция x → y, реализуемая моделью.

Предикаты состояний

1. Существование (E_AI)

Условие: ∭ ρ_θ(r, t) dV dt > 0

Смысл: параметры физически присутствуют.

Флаг: E_AI = 1, пока носитель цел.

2. Потенциал (P_AI)

Условие: H_on(t) AND E_AI.

Смысл: система под питанием и готова к работе.

Флаг: P_AI = 1, когда питание доступно.

3. Акт инференса (A_AI)

Условие: P_AI(t) AND Input(x, t).

Смысл: вычисление в процессе.

Флаг: A_AI(t) = 1 только во время обработки запроса.

Три режима

1. До входа:

E_AI = 1, P_AI = 1, A_AI = 0 → модель существует, но простаивает.

2. Без питания:

E_AI = 1, P_AI = 0, A_AI = 0 → параметры сохранены, система неактивна.

3. При запросе:

A_AI(t) = 1 → идёт вычисление, рассеивается энергия.

Физические константы

Минимальная энергия для стирания одного бита (Ландауэр):

E_min = k * T * ln(2) ≈ 2.85 × 10⁻²¹ Дж (при T = 300 K).

Эквивалентная масса бита (E = mc²):

m_min = E_min / c² ≈ 3.2 × 10⁻³⁸ кг.

Масса модели (пример: n = 1.5 × 10¹¹ параметров, b = 16 бит на параметр):

M_θ = n * b * m_min ≈ 7.7 × 10⁻²⁵ кг.

Модель имеет ненулевую массу даже в выключенном состоянии (E_AI).

Питание даёт потенциал (P_AI), но само по себе не запускает вычисления.

Инференс (A_AI) требует энергии и порождает тепло.

Даже молчащий сервер тяжелее вакуума на вес своего бит-универсума.

📁 Zenodo

Outliers - детектор аномалий временных рядов

Демо: https://outliers.up.railway.app/
Код: https://github.com/andrewbrdk/Outliers

Сервис детектирует аномалии временных метрик и отправляет уведомления о выбросах. Поддерживает:
- PostgreSQL
- Емэил и Слак уведомления.
- Методы детектирования: пороговое значение, отклонение от среднего, межквартильное расстояние.

Попробуйте!

Repeater - легкий оркестратор для аналитики

Repeater запускает задачи по расписанию. Задачи описываются в toml-файлах и отображаются в веб-интерфейсе.

title = "wiki"
cron = "55 * * * *"

[[tasks]]
name = "wiki_pageviews"
cmd = "python3 ./examples/wiki_pageviews.py --end_date={{.scheduled_dt}}"   

[[tasks]]
name = "trigger_outliers_update"
cmd = "python3 ./examples/trigger_outliers_update.py"

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

Попробуйте!

Демо: https://repeater.up.railway.app/
Репозиторий: https://github.com/andrewbrdk/Repeater

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

Ранее техническим руководителем решений Data Ocean Nova и Data Ocean Flex Loader Евгением Вилковым были опубликованы статьи, посвященные сравнению Impala, Trino и Greenplum, в том числе по методике TPC-DS.

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

А какие инструменты используете вы для контроля качества данных? Что бы вы добавили или изменили в нашем подходе? Будем рады обсудить в комментах!

***

ТГ-канал Ostrovok! Tech

OutBoxML: как мы построили свою ML‑платформу от архитектуры до продакшена

Если вы хоть раз выводили ML‑модель в прод, то знаете этот сценарий.

Папки final_final_v2, десятки Python‑скриптов, неотслеженные версии данных, ручной деплой на сервер, и тревожное чувство, что «где‑то что‑то точно отвалится».

Со временем даже хорошо построенный ML‑процесс превращается в хаос — набор несовместимых пайплайнов и моделей, где каждый инженер решает задачу по‑своему.

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

OutBoxML — это не концепция на слайдах, а реальный проект, который мы внедрили в продакшн, чтобы стабилизировать и масштабировать ML во всём ИТ‑контуре Страхового Дома ВСК.

В серии из трёх статей на Хабре наши инженеры подробно разбирают, как мы прошли путь от архитектуры до продакшена, какие решения приняли — и какие ошибки помогли нам вырасти.

Решение: платформа OutBoxML

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

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

Часть 1: Библиотека OutboxML от Страхового Дома ВСК

В первой статье мы показываем конструкцию ядра OutBoxML и обоснование архитектурных подходов.

Ключевой технический инсайт: мы ушли от монолитных систем и отдали предпочтение сервисам с чёткими границами ответственности, использованию событийной коммуникации и контейнеризации.

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

Часть 2: Автоматизированное машинное обучение с помощью нашего Open Source фреймворка: задача о Титанике

В следующее статье мы разбирали моменты, в которых классический ML выигрывает у сложных нейросетей, на примере страховой индустрии.

К тому же обсудили как мы автоматизировали обучение и инференс моделей с помощью OutBoxML и модульную архитектура и гибкие настройки процессов.

Часть 3: Data Drift в ML Страхового Дома ВСК: от PSI‑анализа до пересборки фичей и сравнения моделей

Машинное обучение в страховании — это не только про красивые метрики на этапе тестирования. Самая большая проблема приходит позже, когда модель выходит «в прод»: данные начинают меняться, и точность предсказаний падает. Это явление называется 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 можно просить показать, что они накодили.

Как мы ушли с Airflow и упростили MLOps

Привет! Меня зовут Александр Егоров, я MLOps-инженер в Альфа-Банке, куда попал через проект компании KTS. За свою карьеру я построил четыре ML-платформы (одна из которых сейчас в Росреестре) и развиваю с командой пятую. Недавно мы полностью пересобрали пайплайны и мигрировали c Airflow на Argo Workflows + Argo CD. Делимся подробностями!

Почему Airflow стал мешать?

Airflow отлично подходит для десятков DAG’ов, но на масштабе сотен моделей появляются проблемы: всё усложняется, теряется Kubernetes-нативность, GitOps работает через костыли, а обновления DAG’ов становятся ручным трудом. Версионирование ломается, пайплайны идут десятками минут, и отлаживать их настоящая боль.

Почему Argo Workflows?

Argo — это K8s-native решение, декларативный подход, совместимость с GitOps, простейшее развертывание и минимум лишних компонентов. Для нас это был буквально глоток свежего воздуха. Вместо монолитного Kubeflow — один контроллер, никаких лишних слоёв и масштабируемость из коробки

Подробнее читайте в статье «GitOps для Airflow: как мы перешли на лёгкий K8s-native Argo Workflows»

Строительные автопилоты: почему данные становятся главным активом строительства.

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

За последние 30 лет CAD/BIM фактически превратились в инструмент ручной разметки строительной реальности: инженеры и архитекторы создавали базы элементов зданий и сооружений, превращая чертежи и 3D-модели в структурированные датасеты.

То, что Google, Tesla или Waymo делали силами миллионов студенто-часов, размечавших вручную изображения с людьми и объектами, в строительстве десятилетиями заполняли инженеры проектировщики в специальных базах слабоструктурированных данных AutoCAD или структурированной базы данных Revit или ArchiCAD.

Именно эти массивы станут сырьём для «строительных автопилотов» — систем, способных автоматически расставлять элементы в пространстве проекта и рассчитывать стоимость, сроки и ключевые параметры новых проектов. Как LLM обучаются на массиве текстов, чтобы генерировать новые знания и целые приложения, так и в строительстве мы сможем с помощью AI и workflow использовать опыт тысяч реализованных проектов, чтобы проектировать и планировать новые проекты быстрее и точнее.
У отрасли есть лишь десятилетие, чтобы превратить накопленный опыт в основу будущих систем. После этого рынок займут те, кто сумел первым построить собственные «автопилоты».

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

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

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

Хотите обсудить новые пайплайны автоматизации, поделиться своими кейсами или получить помощь? Больше примеров автоматизации вы можете найти в репозитарии на GitHub или в нашем телеграмм чате "n8n Development | Практика автоматизации и готовые решения" Присоединяйтесь к нашему Telegram-сообществу для живых обсуждений, советов и эксклюзивного контента.

Привет, коллеги! 👋

Снова с вами рубрика "вечерний вайбкодер", и сегодня я принёс вам MyRepETL (Ссылка на github)— инструмент для ETL через MySQL репликацию.

Зачем это нужно?

Задача: у вас куча MySQL баз в микросервисах, нужно всё это затащить в Metabase для красивых отчетов.

Проблема в том, что:

• В каждой базе своя схема и структура

• Данные нужно объединить и нормализовать

• Metabase любит когда всё в одном месте

• Ручной экспорт/импорт — это боль

MyRepETL решает это: берёт данные из всех ваших баз, трансформирует их на лету и складывает в единую аналитическую базу для Metabase.

Что умеет MyRepETL

🚀 Основные фишки

Многопоточность из коробки

• Каждый источник работает в своём потоке

• Не блокирует друг друга

• Автоматически восстанавливается при сбоях

Гибкие трансформации

• Переименование таблиц и колонок

• Вычисляемые поля

• Фильтрация данных

• Кастомные Python-функции

JSON-конфигурация

• Всё настраивается через конфиг

Как использовать

Простая синхронизация

Самый базовый случай — просто скопировать данные из одной базы в другую:

{
  "sources": {
    "prod_db": {
      "host": "prod-mysql",
      "user": "repl_user", 
      "password": "repl_pass",
      "database": "production"
    }
  },
  "targets": {
    "backup_db": {
      "host": "backup-mysql",
      "user": "backup_user",
      "password": "backup_pass", 
      "database": "backup"
    }
  },
  "mapping": {
    "prod_db.users": {
      "source": "prod_db",
      "target": "backup_db",
      "source_table": "users",
      "target_table": "users"
    }
  }
}

С трансформациями

А теперь добавим магию — переименуем таблицу, добавим вычисляемые поля:

{
  "mapping": {
    "prod_db.customers": {
      "source": "prod_db",
      "target": "analytics_db",
      "source_table": "customers",
      "target_table": "users",
      "column_mapping": {
        "id": {"column": "user_id"},
        "name": {"column": "full_name"},
        "email": {"column": "email"},
        "birth_date": {"column": "age", "transform": "transform.calculate_age"},
        "phone": {"column": "formatted_phone", "transform": "transform.format_phone"},
        "created_at": {"column": "registration_date"},
        "source": {"column": "source_system", "value": "production"}
      }
    }
  }
}

Создайте файл transform.py с вашими функциями:

# 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-проекта. У вас под рукой будет готовый ресурс, которым можно просто поделиться — вместо тысячи слов и долгих объяснений.

Перейти в ML Impact

Три способа сформировать идентификатор пользователя.

Привет, меня зовут Рамис и я работаю дата-аналитиком в 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.

• Для больших систем, так что хорошо подходит для микросервисов.

• Можно сортировать, в v7 есть время создания. 

Минусы:

• Длинный — 128 байт (обычные ID короче).

• Неудобный, сложно запомнить (типа a0eebc99-9c0b-4ef8-bb6d-6bb9bd380a11).

• Медленнее в БД, иногда тормозит индексы.

• Без порядка, v4 нельзя сортировать (v7 решает).

• Не число. 

Третий способ — Twitter snowflake id (теперь X) — это система генерации уникальных 64-битных идентификаторов для объектов, таких как твиты, личные сообщения, пользователи и списки.

1. Бит знака — всегда равно 0 и зарезервировано на будущее.

2. Временная метка — количество миллисекунд, прошедших с начала эпохи UNIX.

3. ID ЦОД дает нам 2 ^ 5 = 32 центра обработки данных.

4. ID компьютера дает нам еще 2 ^ 5 = 32 компьютера в каждом ЦОД.

5. Номер последовательности.

6. При генерации каждого 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);

• новая встроенная оконная функция LAST_VALUE();

• оператор % для определения остатка деления по модулю для целых чисел;

• возможность определения лидера raft-группы через функции pico_raft_leader_id() и pico_raft_leader_uuid();

• возможность определения версии текущего инстанса с помощью функции version();

• изменение, связанное с совместимостью: вместо скалярной функции instance_uuid (которая теперь объявлена устаревшей), рекомендуется использовать новую функцию pico_instance_uuid.

Улучшенная совместимость с PostgreSQL

Picodata теперь поддерживает безопасное соединение при обращении к внешнему LDAP-серверу. При подключении через протокол PostgreSQL (например, с помощью клиента psql) с методом аутентификации LDAP можно задействовать TLS-шифрование (при условии, что оно включено на LDAP-сервере). На стороне Picodata для этого потребуется установить значения у трёх переменных окружения. Например:

export TT_LDAP_URL="ldap://127.0.0.1:1389"
export TT_LDAP_DN_FMT='cn=$USER,ou=users,dc=example,dc=org'
export TT_LDAP_ENABLE_TLS=true

Изменение в конфигурации

Добавлен новый параметр instance.pg.advertise — публичный адрес сервера для подключения по протоколу PostgreSQL. По умолчанию, его значение соответствует значению instance.pg.listen. Этот параметр пригодится в ситуации, когда снаружи инстанс доступен по адресу, отличающемуся от адреса во внутренней сети.

Улучшенный веб-интерфейс

Команда Picodata продолжает развивать компонент webui для Picodata. В версии Picodata 25.3 веб-интерфейс не просто выглядит лучше, он также стал удобнее и информативнее:

• на панели Cluster ID отображается больше полезной информации, включая список включённых плагинов;

• в области просмотра сведений об инстансе теперь присутствует адрес подключения по протоколу PostgreSQL.

Механизм плагинов

При подключении плагина к кластеру Picodata теперь допускается расхождение минорных версий плагина и инстанса (например, плагин, собранный для версии 25.3.1, будет работать в Picodata 25.3.2).

Полный список нововведений и список исправленных ошибок доступны в документе CHANGELOG.

Роль Picodata для Ansible

Выпущена новая версия роли Picodata для Ansible, которая совместима с Picodata 25.3. Изменения в роли:

• при сборке информации при сбое (тег crash_dump) можно исключить сборку snap- и xlog-файлов;

• добавлена возможность выполнять lua-команды на инстансах кластера (тег command);

• исправлена работа с несколькими плагинами в инвентаризационном файле и ряд прочих ошибок.

Для установки Picodata 25.3 следуйте инструкциям на сайте. Готовые пакеты доступны для следующих дистрибутивов Linux:

• Astra 1.8

• Debian 12 (bookworm)

• RHEL/Rocky 9

• Fedora 41–42

Инструкции и руководства по установке, использованию и администрированию Picodata размещены на портале документации Picodata.

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)

1. Install Node.js (from the official site, takes 2 minutes)

2. Install n8n with one command

3. Open n8n in your browser (local or online)

4. Start building: drag blocks (“nodes”) to connect apps, add logic, or even call ChatGPT to write emails for you!

Video Tutorial:
Automate Your CAD-BIM Workflows Local with n8n + ChatGPT & Claude | No Code, No Plugins, No Internet

My first workflow? Automating project reports — collecting data, formatting it, and sending it as an email, all triggered by a single button.

Video Tutorial:
Automate Your CAD-BIM Workflows Local with n8n + ChatGPT & Claude | No Code, No Plugins, No Internet

Where the Magic Happens: AI & Templates

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}}"

Бэкэнд написан на Go. Команды ниже запустят Докер-контейнер с сервисом и окружение для примеров:
- Repeater http://localhost:8080 - планировщик
- ClickHouse http://localhost:8123 и http://localhost:9000 - база данных
- ch-ui http://localhost:8001 - веб-интерфейс к базе данных
- Streamlit http://localhost:8002 - дашборды

git clone https://github.com/andrewbrdk/Repeater
cd Repeater
docker compose up --build

В примерах импорт количества просмотров страниц Википедии, курса биткоина, статистики репозитория Линукса на Гитхабе. Графики в Streamlit http://localhost:8002 .

Интересны применения проекта. Попробуйте! Впечатления пишите в комментариях. Спасибо!

Репозиторий: https://github.com/andrewbrdk/Repeater

Хотите стать мастером регулярных выражений?

Тогда новый бесплатный курс — для вас!

Кто-то боится регулярных выражений, а потому избегает их. Кто-то пользуется этим инструментом и решает с его помощью сложные задачи. Мы подумали, что хорошо бы собрать полезные статьи по этой теме в одном месте и помочь читателям избавиться от «регекспофобии». Ну или, наоборот, усугубить ее — тут уж как получится.

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

После изучения материалов вы сможете:

• моментально извлекать данные из гигабайтов текста;

• валидировать формы любой сложности;

• правильно обрабатывать тексты на русском (никаких сломанных \b);

• решать сложные задачи с помощью lookarounds и именованных групп;

• повысить свой уровень в работе со скриптами и редакторами.

Все материалы бесплатные. Не требуется даже регистрация.

Начать обучение в Академии Selectel →

Чем занимается команда Data Science в финтехе

Рассказывает Слава, инженер машинного обучения в ЮMoney.

У нас в компании много данных, которые можно обрабатывать, чтобы улучшать пользовательский опыт. Например, данные пользовательских обращений ЮKassa из разных каналов: чатов с техподдержкой, почты, звонков в колл-центр.

Мы передаём тексты из обращений модели, которую обучили относить их к определённому классу (подключение СБП, вопросы по возвратам, платёжным методам и т. д.). Постоянно появляются новые темы, поэтому приходится регулярно дополнительно обучать модель. Разбив все поступающие обращения по группам, можно оценить их количество и построить дашборд.  

Если по одной теме у нас пять тысяч обращений, по второй — десять тысяч, а по третьей — всего два, значит, нам нужно уделить особое внимание первым двум.

В классификаторе пользовательских обращений мы используем языковые модели типа BERT. Также развиваем использование больших языковых моделей (LLM). У них много знаний «из коробки», они не требуют дообучения и могут применяться для разных задач. Есть и недостатки (требовательность к вычислительным ресурсам или галлюцинации), но LLM способны выполнять задачи намного быстрее, чем человек.

Ещё одно интересное направление Data Science, которое мы тестируем, — распознавание изображений и классификация по категориям. Сейчас мы решаем эту задачу с помощью модели clip, но планируем проверить эффективность работы visual LLM, например Qwen-VL. Этот вид моделей анализирует изображение и даёт текстовое описание, которое можно использовать в продуктах, например при проверке сайтов, которые подключаются к ЮKassa.

Также LLM хорошо выполняет задачи написания саммари — например, по итогам проведённой встречи. Предварительно отдельная модель (у нас это Whisper) переводит аудио в текст, что сильно ускоряет работу коллег.

***

Делитесь в комментариях, есть ли команда Data Science в вашей компании и какие задачи она решает. 🙌 А также следите за нашими новыми материалами о том, как технологии меняют финтех изнутри. Впереди ещё много интересного!