Для расчёта данные нужно прочитать, а иногда сначала перенести по сети. Объясняем локальность вычислений, её ограничения и вопросы к размещению системы.
До расчёта сведения ещё нужно доставить
Представим условную компанию, которая хранит большой архив продаж в одном месте, а ежедневную обработку запускает в другом. Перед каждым расчётом исходные файлы передаются по сети. Само вычисление занимает лишь часть общего времени. Если обсуждать только мощность процессоров, можно упустить путь, который данные проходят до начала полезной работы.
Локальностью данных называют близость нужных сведений к месту вычислений. В описании архитектуры HDFS рассматривается принцип переноса вычисления ближе к хранимым данным, чтобы уменьшить сетевое перемещение. Это устройство определённой распределённой файловой системы. Общая идея полезна шире, но конкретный способ размещения зависит от выбранной инфраструктуры.
Близость бывает разного масштаба
На одном уровне речь идёт о выполнении работы на узле, где хранится нужная часть файла. На другом — о согласованном размещении хранилища и вычислительной системы в регионе облака. Эти случаи не равнозначны. Совпадение региона не означает, что процесс читает локальный диск без сети, а соседство серверов само по себе не даёт приложению нужные права.
В документации BigQuery о расположении ресурсов показано, что местоположение набора и облачного хранилища влияет на условия чтения и переноса. Правила различаются для разных сочетаний ресурсов. Здесь не приводится расчёт стоимости: он требует действующих условий конкретного сервиса и описания всей нагрузки. Важно заранее заметить, что расположение — часть проекта.
Иногда разумнее передать небольшой результат
Для нашей условной компании вопрос звучит так: нужно ли ежедневно перемещать весь архив на компьютер аналитика, если требуется только сводка по магазинам? Один возможный вариант — выполнить нужную обработку в доступном окружении рядом с архивом и передать готовый небольшой результат. Это предложение для обсуждения, а не обязательная схема для каждого проекта.
Такой вариант требует проверки: есть ли там подходящие вычислительные возможности, разрешён ли доступ, можно ли воспроизвести расчёт и достаточно ли результата для дальнейшей работы. Иногда аналитику нужны исходные детали для исследования, а не только сводка. Тогда сокращение передачи до одного итога лишило бы его необходимой информации. Близость должна поддерживать задачу пользователя, а не подменять её.
Сначала уменьшить ненужное чтение
Перенос работы ближе к данным не отменяет вопрос, какие данные вообще нужны. Если отчёт использует только текущий месяц и несколько признаков, чтение всей многолетней истории может оставаться лишней работой даже внутри одного региона. Предложим сначала явно назвать нужный период и поля, затем проверить фактический путь чтения и передачи.
С организацией чтения связан материал о строчном и колоночном хранении. Однако этот выбор и размещение ресурсов решают разные вопросы. Колоночное представление описывает расположение значений внутри хранимых данных, а локальность — близость вычисления к нужным данным. Один подход не гарантирует автоматически правильного решения другого.
Близость не устраняет весь обмен
После чтения частям расчёта может понадобиться передать промежуточные результаты друг другу. Поэтому локальное начало не означает полного отсутствия сетевых затрат. О таком обмене внутри вычисления рассказывает статья про перегруппировку данных в Spark. Здесь мы рассматриваем более ранний выбор: где организовать обработку относительно исходного хранения.
Для условного проекта сравним два полных пути: получение исходников, подготовку, вычисление и доставку результата. Отметим повторные переносы, разрешения и зависимость от сети. Не нужно обещать фиксированное ускорение только по карте размещения. Узким местом может оказаться чтение, вычисление или другой этап, а перенос окружения добавит собственную работу по сопровождению.
Как обсуждать размещение с командой
Нарисуйте путь одного результата от источника до пользователя. Подпишите, где находится каждая система, что передаётся между ними и зачем нужна каждая передача. Затем задайте вопрос, можно ли уменьшить ненужное движение без потери нужных сведений и управляемости процесса. Для дальнейшего изучения устройства систем посмотрите программу «Архитектор данных».
