Обновить
0
0
temonix@temonix

Пользователь

Отправить сообщение

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

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

Привет, Хабр!

Я навайбкодил Вам систему управления отчетами на 100500 Jupyter ноутбуков

Расскажу историю о том, как я решил проблему с хаосом в Jupyter-отчетах и создал систему juport (Jupyter Report System) ссылка на GitHub. А заодно поделюсь мыслями о том, как меняется разработка в эпоху AI-ассистентов.

Проблема: 100500 отчетов и никакого порядка

У меня накопилось огромное количество отчетов, сделанных в Jupyter Lab. Каждый — отдельный файл с кодом, паролями и прочей «кухней».

Главные проблемы:

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

  • Рутина. Нет централизованного места для запуска отчетов, автоматизации по расписанию и единого интерфейса для просмотра.

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

Концепция решения

Нужно было что-то, что позволит разрабатывать отчеты в привычном Jupyter Lab, а потом автоматически запускать их, генерировать чистые HTML-версии без кода и собирать все артефакты в одном месте.

Решение: juport — система управления отчетами

Я создал систему (ну как сам, навайбкодил), состоящую из двух компонентов:

  1. Jupyter Lab Sidecar. Это обычный Jupyter Lab в Docker-контейнере. Здесь разработчики пишут и тестируют отчеты, как привыкли.

  2. juport — система управления. Веб-приложение на Python, которое сканирует папку с ноутбуками. Оно позволяет запускать отчеты вручную или по расписанию, выполняет их в изолированном окружении, генерирует HTML-версии без лишней информации, собирает все артефакты (Excel, картинки) в одну табличку и предоставляет удобный веб-интерфейс. Авторизация — через LDAP.

Как это работает

Разработка отчета:

  1. Вы создаете ноутбук в Jupyter Lab.

  2. Пишете код, тестируете, сохраняете.

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

Запуск отчета:

  1. Заходите в веб-интерфейс juport.

  2. Видите список всех ноутбуков.

  3. Нажимаете «Запустить» или настраиваете расписание.

  4. Система выполняет ноутбук и собирает результаты.

Результат:

  • Чистый HTML-отчет без кода и паролей, доступный для просмотра.

  • Все Excel-файлы, картинки и PDF собраны в одном месте.

  • Удобный интерфейс для скачивания.

  • История выполнений и логи.

Как это сделано

Я не написал ни одной строчки кода сам. Все навайбкодил через Cursor с помощью промптов.

Да, именно так. Привыкайте. Такова реальность.

Андрея Карпатый говорил о том, что скоро разработка будет выглядеть совсем иначе. И он прав.

Мы, миллениалы, единственное поколение, которое разбиралось, как собрать компьютер с нуля. Бумеры были до бума ПК, а зумеры уже родились, когда все было готово. С кодом происходит то же самое. Через N лет опытные разработчики будут получать отличные результаты через промпты, потому что у них есть 20 лет опыта. Этот опыт — не знание синтаксиса, а понимание:

  • Архитектурных паттернов

  • Принципов проектирования

  • Торговых компромиссов

  • Потенциальных проблем

Именно поэтому те, кто шарит, получат отличный результат, а те, кто не шарит, получат «коричневую субстанцию».

AI-ассистенты — это не замена разработчикам, а инструмент, который многократно увеличивает нашу скорость. Опыт и понимание архитектуры становятся еще важнее. А новичкам будет сложнее, потому что им придется мотивированно изучать технологии, чтобы получать от нейросетей качественные вещи.

Выводы

  1. AI-ассистенты — это не замена, а инструмент.

  2. Опыт и понимание архитектуры становятся критически важными.

  3. Скорость разработки для опытных специалистов вырастет в разы.

  4. Новичкам придется приложить больше усилий для освоения профессии.

А как вы видите будущее разработки с AI? Делитесь в комментариях!

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

Информация

В рейтинге
Не участвует
Дата рождения
Зарегистрирован
Активность