Аналитик грузит выгрузку на 40 ГБ в Excel: сервер вместо мучений

MAATRIX

Знакомая сцена: выгрузка из CRM, биллинга или рекламного кабинета весит 40 ГБ, вы двойным щелчком открываете её в Excel — и следующие двадцать минут смотрите на курсор-часы, а потом на окно «Excel не отвечает». Дело не в кривых руках и не в старом ноутбуке: Excel физически не рассчитан на такие объёмы, и чем раньше вы это признаете, тем быстрее перестанете воевать с программой вместо того, чтобы анализировать данные. Ниже — почему так происходит и как обработка на арендованном сервере с правильными инструментами закрывает вопрос раз и навсегда.

Когда Excel сдаётся первым

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

Отдельная засада — тихая потеря данных. У листа Excel жёсткий лимит: 1 048 576 строк и 16 384 столбца. Если в выгрузке строк больше, Excel либо откажется её открыть, либо (в старых версиях импорта через «Данные → Из текста») молча обрежет файл на лимите — и вы неделю строите отчёт по неполным данным, даже не подозревая об этом. При 40 ГБ в CSV с типичной для аналитики шириной строки это почти гарантированный сценарий, а не редкое исключение.

Дальше — попытки «подлечить» проблему: закрыть все вкладки браузера, перезагрузить ноутбук, разбить файл на части в текстовом редакторе, скопировать данные в новую книгу без форматирования. Это тратит рабочий день, но не решает саму причину — Excel не создан как движок для обработки больших объёмов, он создан как редактор таблиц с формулами для объёмов на два-три порядка меньше.

Что на самом деле происходит с памятью

Excel — это классическое in-memory приложение: чтобы с данными можно было работать (сортировать, фильтровать, считать формулы), вся таблица целиком должна поместиться в оперативную память процесса. Дисковый размер файла и объём памяти, который он займёт после открытия, — разные числа: несжатый CSV после парсинга в объекты Excel обычно требует заметно больше памяти, чем весит на диске, — точный коэффициент зависит от типов данных и того, сколько в файле текстовых полей против чисел, но ориентир «в разы больше», а не «один к одному», справедлив почти всегда.

У обычного рабочего ноутбука аналитика — 8, 16, реже 32 ГБ RAM, и эта память делится между операционной системой, десятком вкладок браузера, Slack или Teams, и уже потом — Excel. Когда процессу не хватает физической памяти, Windows и macOS подключают файл подкачки (swap) на диске — а диск на порядки медленнее RAM. Именно в этот момент интерфейс подвисает: система не «упала», она судорожно перекладывает данные между диском и памятью при каждой операции. Если оперативной памяти не хватает совсем, процесс Excel просто вылетает с потерей несохранённого.

Важно понимать: это не следствие «плохого» ноутбука, а архитектурный предел инструмента. Решать проблему более мощным ноутбуком — плохая инвестиция: вы либо упрётесь в тот же лимит на выгрузке в 80 ГБ через полгода, либо переплатите за железо, которое почти всё время простаивает. Разумнее не наращивать мощность личной машины под редкие пиковые задачи, а обрабатывать большие выгрузки там, где для этого есть ресурсы, — на сервере, оставив ноутбук для повседневной работы налегке.

Сервер с памятью под задачу вместо мощного ноутбука

Идея простая: вместо того чтобы пытаться впихнуть выгрузку в Excel на слабой машине, вы переносите обработку на арендованный сервер с объёмом памяти, рассчитанным на такие объёмы, — и используете там инструменты, которые для этого спроектированы. Ноутбук в этой схеме становится тонким клиентом: вы подключаетесь по SSH или через Jupyter в браузере, а вся тяжёлая работа — парсинг, агрегация, джойны — происходит на сервере.

Плюсы такого подхода накапливаются, а не проявляются одним эффектом:

• Память под задачу, а не под бюджет ноутбука. Арендовали сервер с нужным объёмом RAM на нужный срок — и забыли о лимитах. Пришла выгрузка в 80 ГБ — увеличили тариф, не покупая новое железо.
• Ноутбук больше не рискует. Зависание тяжёлого процесса на сервере не тянет за собой рабочую машину — можно спокойно продолжать переписку, пока на сервере считается агрегация.
• Данные не гуляют по флешкам и локальным дискам. Выгрузка один раз попадает на сервер и там же обрабатывается, а не расползается копиями по ноутбуку и почте — важно для персональных или финансовых данных.
• Воспроизводимость. Скрипт обработки запускается повторно на новой выгрузке за пару команд, а не десятью кликами в Excel каждый раз заново.
• Совместная работа. Если с той же выгрузкой должен поработать коллега, ему не нужно пересылать файл на 40 ГБ по почте — достаточно доступа к серверу.

Это не значит «откажитесь от Excel навсегда». Excel остаётся отличным инструментом для финальной таблицы на пару тысяч строк, которую вы показываете заказчику или руководителю. Меняется только то, где происходит тяжёлая часть: сырые 40 ГБ обрабатываются на сервере, а в Excel попадает уже готовый агрегат, который там прекрасно открывается и с которым удобно работать дальше.

Какой сервер брать под такие выгрузки

Для разовой обработки выгрузок на десятки гигабайт ключевой параметр — оперативная память, а не количество ядер процессора. Практический ориентир: если вы работаете с файлом целиком в памяти (через pandas), под комфортную работу стоит закладывать оперативку в несколько раз больше веса файла на диске — это тот же принцип, что и с Excel, просто на сервере есть возможность взять сервер с такой памятью, а не упираться в физический потолок ноутбука. Если использовать инструменты с потоковой обработкой данных (о них — в следующем разделе), требования к памяти можно снизить в разы, потому что весь файл целиком в память грузить не обязательно.

Второй по важности параметр — диск. Берите NVMe, а не обычный SSD или сетевое хранилище: чтение и запись десятков гигабайт при парсинге и конвертации форматов упираются именно в скорость диска, и разница между NVMe и медленным хранилищем ощущается сразу на любой операции с файлом.

Ориентировочная логика подбора конфигурации:

Для третьего сценария, когда выгрузки приходят регулярно и превращаются в постоянный аналитический контур, дешевле один раз развернуть колоночную базу вместо повторной ручной обработки файлов — подробнее в статье про выбор между ClickHouse и PostgreSQL для аналитики. Общий обзор конфигураций под аналитическую нагрузку — в статье про выделенный сервер для аналитики больших данных, а сколько именно RAM закладывать под конкретную задачу — в статье сколько оперативной памяти закладывать с запасом.

Чем обрабатывать вместо Excel

Замена Excel на сервере — не «Excel, но мощнее», а другой класс инструментов, спроектированных под большие объёмы с самого начала.

pandas (Python) — самый привычный путь для аналитика, который уже думает таблицами и формулами: DataFrame читается похоже на лист Excel, но без лимита строк и с полноценным языком программирования вместо ограниченных формул. Минус — pandas по умолчанию тоже грузит данные в память целиком, поэтому на действительно больших файлах его стоит использовать с чтением по частям (chunksize) или сразу перейти на DuckDB.

DuckDB — движок для аналитических запросов, который умеет читать CSV и Parquet-файлы напрямую с диска, не загружая всё в память сразу, и выполнять над ними обычный SQL. Для разовой обработки одной большой выгрузки — часто самый быстрый путь к результату: не нужно поднимать сервер БД, DuckDB работает как обычная программа поверх файла.

ClickHouse или PostgreSQL — когда выгрузки приходят не разово, а становятся постоянным источником данных, есть смысл один раз загрузить их в полноценную СУБД и дальше просто писать запросы, вместо того чтобы каждый месяц заново открывать очередной CSV. ClickHouse особенно хорош, когда речь про агрегации на десятках-сотнях миллионов строк — колоночное хранение читает с диска только нужные столбцы, а не всю строку целиком.

csvkit / xsv — лёгкие консольные утилиты для быстрой разведки: посмотреть первые строки, посчитать количество записей, найти конкретное значение — без запуска Python или SQL вообще, когда нужно быстро сориентироваться в незнакомом файле.

Выбор между ними — не религиозный вопрос, а вопрос частоты задачи: разовая выгрузка — DuckDB или pandas с chunksize, регулярный поток — ClickHouse или PostgreSQL, быстрая разведка перед тем как выбрать инструмент — csvkit.

Пошагово: перенос и обработка выгрузки на сервере

Дальше — практический маршрут для типичного случая: пришла выгрузка на несколько десятков гигабайт в CSV, нужно её отфильтровать, агрегировать и выгрузить компактный результат для отчёта.

1. Перенос файла на сервер. Если файл уже локально:

rsync -avP --progress export.csv user@server:/data/exports/

rsync в отличие от scp умеет докачивать при обрыве соединения — важно на файле такого размера. Если выгрузка изначально лежит в облачном хранилище (S3-совместимом или аналогичном), удобнее скачать её сразу на сервер через rclone или curl, минуя ноутбук вообще.

2. Подготовка окружения. Одноразово на сервере:

apt update && apt install -y python3-venv python3-pip
python3 -m venv /opt/analytics/venv
source /opt/analytics/venv/bin/activate
pip install pandas duckdb pyarrow jupyterlab

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

3. Первая разведка без загрузки в память. Прежде чем что-то грузить целиком, посмотрите на структуру файла через DuckDB — запрос читает только нужный кусок, а не весь файл:

duckdb -c "SELECT * FROM read_csv_auto('/data/exports/export.csv') LIMIT 20;"
duckdb -c "SELECT count(*) FROM read_csv_auto('/data/exports/export.csv');"

4. Конвертация в Parquet. Колоночный формат Parquet весит на диске в разы меньше исходного CSV за счёт сжатия и читается быстрее при повторных запросах — конвертировать стоит один раз при первой обработке:

duckdb -c "
COPY (SELECT * FROM read_csv_auto('/data/exports/export.csv'))
TO '/data/exports/export.parquet' (FORMAT PARQUET);
"

5. Собственно агрегация. Дальше — обычный SQL вместо сводных таблиц Excel, например суммы по клиентам за период:

SELECT
    client_id,
    date_trunc('month', event_date) AS month,
    sum(amount) AS total_amount,
    count(*) AS events_count
FROM read_parquet('/data/exports/export.parquet')
WHERE event_date >= '2026-01-01'
GROUP BY client_id, month
ORDER BY month, total_amount DESC;

Такой запрос над десятками гигабайт выполняется за секунды-минуты в зависимости от объёма и конфигурации сервера — конкретное время зависит от железа и структуры данных, поэтому не берите чужие цифры производительности как обещание для своего случая: лучше один раз замерить на своей выгрузке.

6. Экспорт компактного результата обратно в Excel. Итоговая агрегация — уже не 40 ГБ, а разумные тысячи строк, которые прекрасно открываются в Excel и годятся для отправки заказчику:

import duckdb
df = duckdb.sql("""
    SELECT client_id, month, total_amount, events_count
    FROM read_parquet('/data/exports/export.parquet')
    ...
""").df()
df.to_excel('/data/exports/report_for_client.xlsx', index=False)

Дальше файл report_for_client.xlsx весит уже мегабайты, а не гигабайты, и скачивается на ноутбук без проблем.

7. Повторяемость. Если выгрузки приходят регулярно (еженедельно, ежемесячно), весь пайплайн из шагов 3-6 оформляется одним Python-скриптом или Jupyter-ноутбуком, который запускается на новом файле командой или по расписанию через cron — вместо повторения одинаковых действий вручную каждый раз.

Частые вопросы