MySQL ⇄ Excel через Python CLI: простой ETL без тяжёлой платформы

Обмен данными между базой и Excel кажется скучной задачей, пока она не ломается на реальных файлах. Кодировки, даты, дробные числа, большие таблицы, пустые значения, разные форматы колонок и неожиданные изменения структуры быстро превращают «просто выгрузить в xlsx» в маленький ETL-проект.

Для разовых и полурегулярных задач не всегда нужна Airflow, Pentaho или тяжёлая интеграционная платформа. Иногда достаточно аккуратной Python CLI-утилиты, которая умеет читать MySQL, писать Excel и делать обратный импорт с проверками.

Где возникает такая задача

Типовые сценарии:

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

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

Почему старые подходы ломаются

Ручной экспорт через phpMyAdmin или случайный PHP-скрипт часто работает только на маленьком примере. На больших файлах появляются проблемы:

• неверная кодировка;
• даты превращаются в строки или числа;
• дробные значения округляются;
• leading zeros теряются;
• nullable-поля импортируются как пустые строки;
• память заканчивается на больших xlsx;
• структура файла расходится со схемой таблицы.

Если утилита не контролирует типы, она незаметно портит данные.

Архитектура CLI

Удобно разделить инструмент на команды:

mysql-excel export --table products --out products.xlsx
mysql-excel import --table products --file products.xlsx --dry-run
mysql-excel schema --table products
mysql-excel validate --table products --file products.xlsx

Такой интерфейс понятен и автоматизируется в cron, CI или shell-скриптах. Важно, чтобы каждая команда имела явный exit code и писала понятный лог.

Сохранение типов

Самая важная часть — маппинг типов между SQL и Excel. Нужно заранее определить, как обрабатываются:

• INT, BIGINT;
• DECIMAL;
• DATE, DATETIME, TIMESTAMP;
• VARCHAR, TEXT;
• BOOLEAN;
• NULL;
• enum-like поля.

Для денежных значений лучше использовать Decimal, а не float. Для дат — явно фиксировать timezone и формат. Для идентификаторов с leading zeros — хранить как текст.

Импорт должен быть осторожным

Обратная загрузка из Excel опаснее экспорта. Пользователь мог удалить колонку, переименовать заголовок, вставить формулу, поменять тип или случайно скопировать лишние строки.

Поэтому нужны проверки:

• обязательные колонки;
• типы значений;
• ограничения длины;
• foreign keys;
• уникальность;
• пустые значения;
• diff перед записью;
• dry-run режим.

По умолчанию импорт лучше делать через --dry-run, показывая, сколько строк будет создано, изменено или пропущено.

Batch processing

Большие файлы нельзя читать и писать бездумно целиком в память. Для MySQL-запросов нужны batches или server-side cursors. Для Excel — streaming writer/reader, если библиотека поддерживает.

Практические настройки:

• размер batch;
• лимит строк;
• progress output;
• retry для соединения;
• timeout;
• транзакция на импорт;
• rollback при ошибке.

Если импорт обновляет важные данные, лучше сохранять snapshot или backup перед операцией.

Безопасность

Даже внутренняя CLI-утилита должна быть безопасной:

• не логировать пароли;
• брать credentials из env или secret storage;
• не собирать SQL строковой конкатенацией;
• ограничивать список разрешённых таблиц;
• иметь read-only режим;
• писать audit log для импортов.

Если дать инструменту доступ ко всей базе и произвольному SQL, он быстро станет опаснее, чем полезнее.

Итог

Python CLI для MySQL ⇄ Excel — хороший пример прагматичного ETL без лишней инфраструктуры. Но качество такого инструмента определяется не фактом чтения xlsx, а вниманием к типам, dry-run, валидации, batch processing и безопасности.

Правильно сделанная утилита экономит часы ручной работы и снижает риск повреждения данных. Неправильно сделанная — просто автоматизирует хаос быстрее.