Геодезист привозит с объекта гигабайты съёмки: сервер под облака точек

MAATRIX

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

Ноутбук с объекта: почему облака точек его переполняют

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

С фотограмметрией картина ещё тяжелее. Дрон делает не десятки, а сотни и тысячи кадров с перекрытием, и уже на этапе выгрузки RAW или JPEG с карты памяти вы получаете десятки гигабайт на один вылет. А ведь это только исходники — до плотного облака точек и ортофотоплана дело ещё не дошло, а обработка добавит ещё столько же, если не больше, во временных и промежуточных файлах.

Проблема не в том, что один проект не помещается на диск ноутбука. Проблема в том, что объекты накапливаются. После пятого-шестого выезда за сезон на рабочем диске уже лежат десятки проектов, часть из которых нельзя удалить — заказчик может попросить пересчитать облако с другими параметрами через полгода, или понадобится сверка при судебном споре о границах. Ноутбук с SSD на 1–2 ТБ, который отлично тянул полевую работу, оказывается заложником архива, который сам же и создал.

Второй эффект — обработка. Регистрация сканов, склейка облаков, построение плотного облака по фотограмметрии — операции, которые требуют держать в памяти огромные массивы точек одновременно. На полевом ноутбуке с 16–32 ГБ ОЗУ софт либо работает медленно из-за подкачки на диск, либо падает по нехватке памяти на действительно крупных объектах. И это при том, что ноутбук вам ещё нужен работоспособным — для следующего выезда, а не только для обработки прошлого.

Сервер вместо ноутбука: что меняется в рабочем процессе

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

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

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

Второй практический момент — не обязательно гонять терабайты туда-обратно по интернету, если у вас нестабильный канал в дороге. Часть данных можно физически привезти на внешнем диске и один раз залить на сервер по локальной сети или через дата-центр с хорошим каналом, а дальше уже работать с сервером удалённо — через RDP, VNC или SSH, в зависимости от того, какой у вас софт.

Сколько места на диске закладывать и какой диск выбрать

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

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

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

Отдельно стоит подумать про избыточность. Один диск — это всегда риск: посыпался массив, и архив с полевыми данными за пару сезонов исчез. Для сервера, где лежит несезонный архив, имеет смысл RAID с избыточностью (зеркало или что-то с чётностью, в зависимости от бюджета) — разница между уровнями и когда какой выбирать разобрана в статье RAID на сервере: уровни и как выбрать. Даже простое зеркало из двух дисков спасает от классической ситуации «диск умер молча, а бэкапа не было — было же „потом сделаю“».

CPU и оперативная память: что реально ест ресурс при обработке

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

• Регистрация (совмещение) сканов — сопоставление облегчённых копий облаков между собой, поиск общих опорных точек или маркеров. Нагружает в основном процессор, память нужна под все совмещаемые сканы одновременно, если вы не работаете попарно.
• Склейка/объединение множества сканов в единое облако — здесь память становится узким местом первой: чем больше исходных сканов держится в оперативной памяти одновременно, тем быстрее и стабильнее идёт процесс, без ухода в подкачку на диск.
• Фильтрация шума и децимация (прореживание) — не самая тяжёлая операция, но на плотных облаках с миллиардами точек она всё равно требует времени и заметного объёма памяти под буферы.
• Построение плотного облака по фотограмметрии — обычно самый долгий этап во всей цепочке, задействует и CPU, и (в софте с поддержкой) видеокарту, если она есть на сервере.
• Генерация меша, текстурирование, ортофото — снова CPU-интенсивная задача, плюс дисковый ввод-вывод под временные файлы, которые на этом этапе могут в несколько раз превышать объём исходников.

Практический вывод для выбора конфигурации сервера: под регулярную обработку облаков точек нужен процессор с хорошей многопоточностью (большинство современного софта для облаков точек умеет параллелить тяжёлые операции по ядрам) и объём оперативной памяти с явным запасом — если по факту вашей текущей практике для комфортной работы с проектом нужно условно 32 ГБ, на сервере разумно закладывать больше, а не впритык, потому что упереться в лимит памяти на середине многочасовой обработки и потерять прогресс — обидная и частая история.

Важный нюанс: значительная часть профессионального софта для облаков точек (наземное сканирование, обработка данных БПЛА) — это Windows-приложения с полноценным графическим интерфейсом, а не консольные утилиты. Это не проблема — на сервере можно поднять Windows-окружение и работать с ним через удалённый рабочий стол (RDP), запуская обработку прямо в привычном интерфейсе, только не на полевом ноутбуке, а на мощной машине в дата-центре, к которой вы просто подключаетесь. У части пакетов есть и headless/командный режим для пакетной обработки без интерфейса — если ваш инструмент это умеет, ночной прогон обработки без открытого экрана удобнее для сервера, который вы не держите постоянно перед собой.

Как загружать данные с поля на сервер

Самое узкое место в этой схеме — не сервер, а канал между полем и дата-центром. С этим стоит определиться заранее, а не в момент, когда нужно срочно перекинуть 80 ГБ с объекта.

Если на объекте есть нормальный интернет (гостиница, офис заказчика, точка с хорошим 4G/5G), можно грузить сразу на сервер по мере съёмки — это разгружает полевой накопитель и снижает риск потери данных при поломке карты памяти или ноутбука. Для передачи больших файлов по SSH удобен rsync — он докачивает прерванную передачу с того места, где оборвалось, а не с начала:

rsync -avP --partial /media/field-drive/objekt-42/ user@server:/data/geodesy/objekt-42/

Флаг -P здесь совмещает --partial (не удалять недокачанное) и --progress (показывать прогресс) — критично, когда передача идёт часами на нестабильном канале и обрывается.

Если интернета на объекте нет или он слишком медленный для десятков гигабайт, разумная тактика — довезти данные на внешнем диске до места с нормальным каналом и залить одним разом, а сервер тем временем стоит и ждёт, не требуя вашего постоянного внимания. Для монтирования сетевого хранилища сервера на рабочей станции можно использовать SFTP-клиент с графическим интерфейсом, если работа в терминале неудобна — тот же итоговый rsync или scp можно запускать и из GUI-обёрток.

Отдельно продумайте структуру каталогов на сервере до того, как туда попадёт первый проект — переименовывать и переносить сотни гигабайт постфактум куда дольше, чем сразу завести разумную схему: год → объект → тип данных (сырьё / обработка / результат). Плоская свалка файлов с именами вида scan1_final_v3 быстро превращается в архив, в котором сами не разберётесь через полгода.

Организация архива: структура проектов и резервные копии

Хранение — это не только «положить файлы на диск», а ещё и возможность их найти и не потерять. Для геодезической практики стоит различать три слоя данных с разными требованиями:

1. Активные проекты — объекты в работе прямо сейчас. Нужен быстрый диск, регулярный локальный снапшот на случай, если обработка пойдёт не так и понадобится откатиться.
2. Завершённые проекты текущего года — сданы заказчику, но могут понадобиться повторно (уточнения, споры, допсъёмка). Быстрый доступ не критичен, но должны легко находиться по названию объекта или адресу.
3. Архив прошлых сезонов — хранится по обязательствам (часто годами), почти никогда не открывается, но терять нельзя. Здесь уместно более дешёвое и ёмкое хранилище, необязательно на самых быстрых дисках.

Резервное копирование для этой схемы стоит настраивать раздельно: активные проекты — с частым снапшотом (хоть раз в сутки, объёмы позволяют), архив прошлых сезонов — с редкой, но обязательной копией во второе место, физически отдельное от основного сервера. Правило «одна копия — это отсутствие копии» здесь работает буквально: облако точек, снятое на объекте один раз, повторно снять зачастую либо очень дорого, либо вообще невозможно (объект изменился, доступ закрыт, дрон разбился — бывает всякое).

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

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