Обновить
87.66

Data Engineering *

Обсуждаем вопросы сбора и подготовки данных

Сначала показывать
Порог рейтинга

Недавно вышла новая версия dplyr 1.2.0, и она принесла несколько важных обновлений, которые делают работу с данными в R ещё проще и удобнее. Опубликовал видео обзор в котором я рассказываю про самые интересные новинки: новые функции фильтрации filter_out(), when_any() и when_all(), обновлённую систему перекодировки с recode_values(), replace_values() и replace_when(), а также о важных оптимизациях старых функций.

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

Видео снято по статье "dplyr 1.2.0".

Теги:
0
Комментарии0

Друзья, 12 февраля проведём открытый вебинар по следам нашего ESB-исследования в «Кругах Громова».

Если коротко — за последний год мы оценили 18 российских интеграционных платформ по единой методологии: 12 категорий, 1 000 баллов. Такого раньше на рынке не было. Результаты местами предсказуемые, местами — неожиданные.

На вебинаре поговорим:

— Почему компании до сих пор путают Kafka, ESB и data pipeline — и платят за это дважды
— 5 классов интеграционных решений: когда какой работает, а когда — категорически нет
— Как мы строили матрицу зрелости и кто в итоге получил номинацию
— Что планируем исследовать дальше — и как повлиять на приоритеты

Будет живой эфир с интерактивом, не просто «говорящая голова».

Кто работает с интеграциями, выбирает платформу или просто в теме — приходите, будет интересно.

📅 12 февраля 2026, 11:00 МСК
📍 Онлайн, бесплатно

👉 Нужна регистрация: тут

Теги:
0
Комментарии0

12 февраля вебинар про ETL-платформу в облаке

Это будет практический вебинар, на котором мы покажем, как за несколько часов создать надежную и масштабируемую ETL-платформу в облаке. С такой платформой можно сосредоточиться на создании ценности для бизнеса, а не решении проблем с задержками в аналитике, ошибками в отчетах и потерей времени на поддержку инфраструктуры.

Какие вопросы обсудим на вебинаре:

  • как интегрировать данные из различных источников (базы данных, S3, API) в единую экосистему;

  • как централизовать управление метаданными и схемами для согласованности и качества данных;

  • как настроить SQL-запросы к разнородным источникам без переноса данных;

  • как оценить экономию времени и ресурсов при переходе с self-hosted решений на управляемые сервисы.

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

📅 Когда? 12 февраля в 11:00 мск.

📍Где? Онлайн. Зарегистрируйтесь, чтобы задать вопросы экспертам в прямом эфире.

P.S. Если вы руководитель или инженер данных, BI-лидер или архитектор данных, то перед вебинаром предлагаем скачать чек-лик и проверить зрелость ваших ETL/ELT‑процессов. В итоге у вас будет готовый план оптимизации с применением cloud native подходов, который вы обсудите с нашим архитекторов, а на вебинаре увидите, как решение выглядит изнутри и сможете уточнить технические детали.

Теги:
0
Комментарии0

GlowByte разработала методику выбора BI на основе сценарного анализа

Источник: Freepik.com
Источник: Freepik.com

Практика Business Intelligence GlowByte разработала подробное руководство по сценарному выбору BI с готовой Excel-матрицей для сравнения платформ.

GlowByte выделяет 4 ключевых сценария с разными потребностями и акцентами:

  • отчеты для руководителя,

  • self-service,

  • регламентная отчетность,

  • исследование данных.

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

ℹ️ Методика учитывает изменения в BI-ландшафте, запрос на адаптивность и гибкость, а также необходимость подстраивать инструмент под задачу, а не наоборот. Исследование содержит детальные чек-листы по каждому сценарию, критерии оценки и примеры расчетов.

Впервые GlowByte выпустила сравнительную таблицу инструментов для анализа данных в 2022 году (рассказывали о подходе в статье “Как выбрать BI-платформу”). Подробнее о том, как GlowByte пересмотрела методику и почему старый подход не работает, - в новой статье "От универсальных критериев к сценарному подходу".  

Теги:
+3
Комментарии0

Open Table Formats — Iceberg vs Paimon — практика использования

В блоге партнеров GlowByte вышла новая статья.

Автор рассказывает об опыте работы с новым открытым табличным форматом (OTF) Paimon от разработчиков Apache Flink, представляет практические выводы, которые были сделаны на промышленных средах; а также проводит репрезентативное тестирование, где иллюстрирует ключевые практические сценарии.

Появление open table formats исполнило вековую мечту data-инженеров: совместило эффективность хранения и чтения Apache Parquet с возможностью обновления данных без полной их перезаписи. Достигается это за счет парадигмы Merge-On-Read и «отложенного удаления», когда информация об удалении старых версий записи пишется в deletion-файлы. Для фреймворков потоковой обработки, например Flink, это открывает возможности по обновлению данных прямо в Data Lake в режиме, близком к реальному времени, а для движков пакетной обработки — Spark, Impala, Trino, StarRocks — сокращает расход ресурсов на MERGE новых порций данных в витрины.

Читать статью полностью по ссылке.

Теги:
+4
Комментарии0

Процедурное SQL-расширение в Lakehouse-платформе — новые возможности для работы с данными

В блоге технологического партнера GlowByte вышла новая статья. Команда Data Sapience рассказала о реализации процедурного расширения для работы с MPP-движками Lakehouse-платформы данных Data Ocean Nova, которое стало доступным для пользователей.

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

Теги:
+4
Комментарии0

Привет!

В рамках «Кругов Громова» сейчас запускаем новое исследование — по российским платформам роботизации бизнес‑процессов (RPA). Хотим собрать честный опыт внедрения: что реально автоматизировали, где программные роботы помогают, а где мешают жить.

Если вы участвовали во внедрении RPA, запускаете и поддерживаете программных роботов (RPA‑ботов) в проде или, наоборот, уже обожглись и отказались от платформы — очень нужны ваши ответы. Опрос занимает 5–10 минут, он про практику, а не про маркетинг.

👉 Опрос RPA-круга Громова: https://forms.yandex.ru/cloud/6937ddf7068ff0b2dab7e0ee/

Результаты войдут в открытое исследование по российским RPA‑платформам на russianbi.ru — в духе прошлых исследовательских кругов: с разбором сильных и слабых сторон и типичных граблей.

Если есть история «как у нас роботы пошли не по плану» или, наоборот, показательный успешный кейс — кратко накидайте в комментарии к этому посту, это тоже поможет исследованию.

Теги:
Всего голосов 2: ↑1 и ↓10
Комментарии2

Call for Pioneers: Launching the StarRocks Russian Community

Hello, Russian Developers!

We are the team behind StarRocks, a next-generation, high-performance analytical database (OLAP) widely adopted by leading tech companies globally for its blazing-fast query speeds and unified architecture.

We have always admired the Russian tech community. From ClickHouse to Nginx, Russia has a legendary reputation for engineering excellence and database innovation. We believe StarRocks has a lot to offer to this vibrant ecosystem, but we face a challenge: Language.

To bridge this gap, we are launching the StarRocks Russia Localization Program. We are looking for 3-5 technical experts to become the founding contributors of our Russian community.

The Mission

We don't just need translators; we need technical evangelists. Your goal is to help us localize high-quality technical content (Architecture deep dives, Benchmarks, User Cases) from English/Chinese into native, professional Russian, ensuring the local community can access the best resources.

Who We Are Looking For

- Native Russian Speaker: You have a high command of technical writing.

- Tech Savvy: You have mastered SQL, OLAP, and Data Warehousing, and your current job involves working with OLAP databases.(Experience with ClickHouse or PostgreSQL is a huge plus).

- Language Skills: You have a good understanding of English (or Chinese).

- Passion: You are active on Habr, Reddit or Telegram tech groups, or GitHub.

What You Will Get

- Competitive Bounties: We pay for every high-quality article translated or proofread.

- Official Recognition: We will be launching an official website in Russia, where you will be certified and listed as a Community Evangelist (subject to your consent for public disclosure).

- Inner Circle Access: Direct communication with our core R&D team and early access to new features.

- Exclusive Swag: Limited edition StarRocks geek gear.

Теги:
Всего голосов 4: ↑2 и ↓20
Комментарии7

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

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

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

Попробуйте!

Теги:
Всего голосов 1: ↑1 и ↓0+1
Комментарии0

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

Теги:
Рейтинг0
Комментарии0

Бенчмарк бенчмарка Lakehouse-движков, в котором побеждает объективная реальность

В блоге Data Sapience, технологического партнера GlowByte, вышла крутая статья технического идеолога Lakehouse-платформы данных Data Ocean Nova Евгения Вилкова.

Недавно на Хабре вышла статья с громким заголовком “Бенчмарк lakehouse-движков, часть 1: StarRocks и Doris падают под нагрузкой, Presto аутсайдер, CedrusData быстрее всех”. В своей статье авторы из Кверифай Лабс выбрали методику TPC-DS, но вместо 99 запросов остановилась на одном, который к тому же запускается на одной машине. Обосновывается это тем, что на одном конкретном запросе нужно разобрать работу оптимизаторов. По результатам исследования делается вывод, что решение, разработанное авторами, является лучшим, в том числе для запуска одного конкретного запроса на одном узле. Давайте попробуем разобраться, действительно ли это так.

В качестве отступления замечу, что данный эксперимент не имеет ничего общего с массивно-параллельными вычислениями и Lakehouse. Архитектура раздельных вычислений предполагает интенсивный сетевой обмен не только между storage и compute, но и между узлами compute-движка. Как заметили в комментариях к оригинальной статье, с тем же успехом можно было включить в тест и MySQL. Складывается впечатление, что методика тестирования была выбрана исключительно из-за заявленных компетенций в области оптимизатора движка, а запрос – исходя из наличия собственных доработок для обработки схожего случая. Главной же целью было на частном выводе убедить аудиторию в общем выводе. Отдадим должное коллегам – они не скрывают субъективность своего отношения к упражнению.

Заинтригованы? Добро пожаловать в статью Евгения! Комментарии приветствуются.

Теги:
Всего голосов 1: ↑1 и ↓0+1
Комментарии0

Тестирование движков массивно-параллельных вычислений: 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.

Теги:
Всего голосов 1: ↑1 и ↓0+1
Комментарии0

Обеспечиваем качество данных в компании. Подборка 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

Теги:
Всего голосов 15: ↑15 и ↓0+17
Комментарии6

Ближайшие события

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 вам хотелось бы узнать подробнее. Удачи в реализации ваших проектов!

Теги:
Всего голосов 1: ↑1 и ↓0+3
Комментарии0

​​Про AI-ускорение рутины разработчиков, которого... НЕТ! ч.3. В предыдущих частях мы смотрели годные исследования от том, как AI влияет на результаты работы, со стороны самого разработчика (раз, два). 

Данные из innovation graph
Данные из innovation graph

А теперь быстро посмотрим на результаты труда разработчиков! Ведь бешеный прирост эффективности (которого нет) должен быть виден невооруженным взглядом.

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 можно просить показать, что они накодили.

Теги:
Всего голосов 6: ↑6 и ↓0+7
Комментарии2

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

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

GitOps для Airflow: как мы перешли на лёгкий K8s-native Argo Workflows
Привет! Меня зовут Александр Егоров, я MLOps-инженер в Альфа-Банке, куда попал через проект компании...
yg140.servegame.com

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

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

Почему Argo Workflows?

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

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

Теги:
Всего голосов 2: ↑2 и ↓0+4
Комментарии0

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

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

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

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

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

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

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

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

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

Теги:
Всего голосов 1: ↑0 и ↓1-1
Комментарии1

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

Снова с вами рубрика "вечерний вайбкодер", и сегодня я принёс вам 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

На этом всё, удачного кодинга! 👨‍💻

Теги:
Всего голосов 2: ↑0 и ↓2-2
Комментарии0

ML Impact — рассказываем, как компании внедряют ML и что из этого получается

Мы запустили ресурс о том, как эффективно использовать искусственный интеллект в рабочих задачах. Уже доступны материалы про настоящую роль ИИ в автоматизации и работу EDGE AI. Скоро появятся новые статьи! 

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

Перейти в ML Impact

Теги:
Всего голосов 4: ↑4 и ↓0+8
Комментарии0

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

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

Теги:
Всего голосов 5: ↑5 и ↓0+5
Комментарии5