В эпоху, когда объемы данных растут экспоненциально, традиционные подходы к аналитике часто упираются в физические ограничения процессоров. Многоузловые CPU-кластеры, хотя и надежны, сталкиваются с проблемами задержек (latency) и узких мест при вводе-выводе (I/O). Однако появление GPU-ускоренных решений, таких как Presto, работающий на архитектуре NVIDIA, меняет правила игры. Это не просто incremental улучшение — это качественный скачок в скорости обработки аналитических запросов, который позволяет инженерам данных и ученым работать с терабайтами данных практически в реальном времени.
В этой статье мы подробно разберем результаты тестирования GPU-ускоренного Presto на оборудовании NVIDIA, включая DGX B200 и флагманскую систему GB200 NVL72. Мы посмотрим, как технологии NVIDIA cuDF, NVLink и GPUDirect Storage (GDS) в связке с IBM Storage Scale позволяют достичь беспрецедентной производительности. Это руководство для тех, кто хочет понять не только «что» работает быстрее, но и «почему», а также как применить эти знания на практике в своих проектах.
01Почему GPU-ускоренный Presto меняет парадигму аналитики?
Presto — это открытый распределенный SQL-движок, созданный для выполнения быстрых интерактивных запросов на очень больших наборах данных. Исторически он работал на CPU, что требовало масштабирования кластера (добавления новых серверов) для обработки растущих объемов данных. GPU-ускоренный Presto, использующий библиотеки NVIDIA, такие как cuDF (CUDA Data Frame), переносит вычислительную нагрузку на графические процессоры. Это дает два ключевых преимущества: пиковую производительность для аналитических рабочих нагрузок и низкую задержку для пользователей и AI-агентов.
Низкая задержка означает, что вы и ваши AI-агенты не блокируются ожиданием результатов запросов. Вы можете итерировать модели, строить дашборды и принимать решения в режиме, близком к реальному времени. В контексте современных AI-приложений, где время отклика критично, это становится конкурентным преимуществом. GPU-ускоренный Presto не просто ускоряет запросы; он делает аналитику «живой» и отзывчивой.
02Сравнение производительности: CPU против GPU на DGX B200
Чтобы оценить реальный прирост производительности, команда NVIDIA провела бенчмарки на основе стандарта TPC-H, который включает 22 аналитических запроса. В тестировании использовались данные в формате Parquet, а типы данных decimal были заменены на float для оптимизации. Измеряемое время выполнения запроса включало парсинг SQL, оптимизацию плана, выполнение рабочими узлами (workers) и возврат финальных результатов.
Тесты проводились на двух масштабах данных (scale factors): 1K (~1 ТБ данных) и 3K (~3 ТБ данных). Для сравнения использовалась конфигурация Presto CPU, работающая на 8-10 узлах серверов Intel Xeon 6642Y с 250 ГБ оперативной памяти на узел. Для GPU-версии использовался один узел NVIDIA DGX B200 с различным количеством активных GPU (от 1 до 8).
Результаты оказались впечатляющими. На масштабе 1K GPU-ускоренный Presto показал задержку, в 2,5–8 раз ниже, чем у многоузлового CPU-кластера. Если один GPU B200 работал в 2,5 раза быстрее, чем кластер из 8 CPU-узлов, то использование всех 8 GPU на DGX B200 дало ускорение в 8,2 раза. На более крупном масштабе 3K прирост составил от 3 до 8 раз. Например, конфигурация с 3 GPU была в 3,6 раза быстрее 10-узлового CPU-кластера, а 8-GPU конфигурация — в 7,8 раза быстрее.
Это демонстрирует, что GPU-архитектура не только лучше справляется с параллельными вычислениями, но и масштабируется линейно внутри одного узла, избегая накладных расходов на межсерверную коммуникацию, которые неизбежны в распределенных CPU-системах.
03Масштабирование на GB200 NVL72: Архитектура и интеграция
Когда требования растут beyond одного узла, на сцену выходит NVIDIA GB200 NVL72. Это система, состоящая из 18 узлов, где каждый узел содержит два процессора Grace CPU, четыре GPU B200 и четыре сетевых интерфейса ConnectX-7 (CX7) со скоростью 400 Гбит/с. Ключевая особенность этой системы — все GPU в кластере соединены через NVLink, что создает единую высокоскоростную сеть для трафика между вычислениями и хранилищем.
Для тестирования GB200 NVL72 был использован IBM Storage Scale — распределенная файловая система с емкостью 10 ПБ и пиковой пропускной способностью ~4,5 ТБ/с. IBM Storage Scale (ранее GPFS) поддерживает прямой доступ к памяти (RDMA) через InfiniBand/RoCE. В связке с NVIDIA GPUDirect Storage (GDS) это позволяет передавать данные напрямую с устройства хранения в память GPU, полностью минуя процессор хоста и буферы системной памяти. Это критически важно для снижения нагрузки на CPU и устранения задержек, связанных с копированием данных.
В тестах масштабирования использовалось 8 из 18 узлов NVL72, что соответствовало 32 рабочим узлам Presto GPU. Запросы TPC-H на масштабах 10K и 30K показали, что правильная настройка I/O и коммуникаций может дать значительный прирост скорости. Изначально, при использовании стандартных POSIX-чтений и неоптимизированных параметров, производительность была ниже ожидаемой. Однако серия оптимизаций позволила радикально улучшить результаты.
04Оптимизация I/O и коммуникаций: От POSIX к GDS
Одним из самых важных открытий в ходе тестирования стала роль GPUDirect Storage (GDS). В системе NVL72 с IBM Storage Scale доступны два основных пути передачи данных: POSIX-чтения (которые сначала копируют данные в пул страниц клиента, а затем в GPU) и GDS-чтения (которые используют RDMA для прямого заполнения памяти GPU).
GDS является «осведомленным о топологии» (topology-aware) решением. Это означает, что он гарантирует, что путь от сетевого адаптера CX7 к памяти GPU остается в пределах одного узла NUMA (Non-Uniform Memory Access). Это избегает штрафов за пересечение границ NUMA, которые возникают при использовании POSIX-чтений, особенно если файловая система не настроена на учет топологии.
Тестирование на масштабе 10K с двумя узлами (8 GPU) показало, что холодные чтения через GDS (GDS cold) работают примерно в 2 раза быстрее, чем холодные POSIX-чтения (POSIX cold). Причина — устранение копирования через буферы (bounce buffers) и минимизация использования ресурсов хоста. Для достижения пиковой производительности и оптимального соотношения цены и производительности на NVL72 с IBM Storage Scale, GDS становится предпочтительным методом.
Кроме того, были применены следующие оптимизации, которые в совокупности дали ускорение на 64%:
- Увеличение размера задачи I/O: Переход с 4 МБ на 16 МБ (рекомендуемый размер для IBM Storage Scale) дал ускорение на ~30%.
- Увеличение количества потоков I/O: Использование 16 потоков I/O вместо 4 улучшило насыщение NVLink и дало еще ~17% прироста.
- Ребатчинг и переписывание запросов: Оптимизация размеров пакетов обмена и переписывание запроса Q11 снизили время простоя GPU и дало дополнительные 35% ускорения.
05Практические шаги для внедрения GPU-ускоренного Presto
Для организаций, рассматривающих переход на GPU-ускоренную аналитику, важно понимать, что это не просто «включить и забыть». Требуется настройка инфраструктуры и оптимизация рабочих нагрузок. Интеграция GPU-ускоренного Presto уже доступна в платформе IBM watsonx.data, что упрощает тестирование в production-средах.
Для разработчиков и инженеров, желающих протестировать Presto Native, доступен тег gpu-nightly в репозитории Presto DockerHub. Также рекомендуется изучить репозиторий rapidsai/velox-testing на GitHub, где представлены полные скрипты для сборки, развертывания и бенчмаркинга.
Ключевые рекомендации для старта:
- Используйте GDS: Если ваше хранилище поддерживает RDMA (например, IBM Storage Scale, Cleversafe или другие совместимые решения), обязательно настройте GPUDirect Storage. Это даст наибольший прирост в скорости чтения данных.
- Оптимизируйте I/O потоки: Увеличьте количество потоков ввода-вывода и размер задач I/O (до 16 МБ и более) для лучшего использования пропускной способности NVLink и сети.
- Анализируйте планы запросов: Некоторые запросы, особенно те, которые возвращают большие объемы данных на координатор, могут стать узким местом. Рассмотрите возможность переписывания таких запросов (например, использование INSERT INTO вместо SELECT для промежуточных результатов), чтобы держать GPU загруженными.
- Мониторинг NUMA: Убедитесь, что ваша файловая система и драйверы правильно обрабатывают топологию NUMA, чтобы избежать штрафов за пересечение границ памяти.
06Что это значит на практике
Для бизнеса и команд данных GPU-ускоренный Presto на базе NVIDIA GB200 NVL72 означает переход от «аналитики вчерашнего дня» к «аналитике настоящего времени». Скорость, в 8 раз превышающая традиционные CPU-кластеры, позволяет:
- Ускорить принятие решений: Дашборды и отчеты генерируются мгновенно, что критично для финансовых аналитиков, маркетологов и операционных директоров.
- Интегрировать AI в реальном времени: AI-агенты, которые полагаются на быстрые запросы к базам данных для получения контекста, могут работать эффективнее, не ожидая ответа от базы данных.
- Сократить инфраструктурные затраты: Один узел DGX B200 или несколько узлов NVL72 могут заменить десятки серверов с CPU, снижая затраты на электроэнергию, охлаждение и обслуживание ЦОД.
- Экспериментировать быстрее: Data Scientists могут запускать больше итераций запросов за то же время, ускоряя цикл разработки моделей машинного обучения.
Хотя внедрение требует настройки специфических компонентов (GDS, NVLink, оптимизация запросов), потенциал производительности делает это вложение оправданным для организаций, работающих с большими данными. Будущее аналитики — за гибридными системами, где GPU берут на себя тяжелую вычислительную работу, а CPU остаются для управления и координации, и решения вроде GPU-ускоренного Presto уже показывают, как это работает в масштабе.
Для получения дополнительной информации о технической предварительной версии GPU-ускоренного Presto в watsonx.data рекомендуется зарегистрироваться на доступ. Разработчикам стоит начать с изучения документации по Velox и cuDF, чтобы глубже понять механизмы ускорения.
Источник: NVIDIA Developer ↗