В эпоху больших данных и искусственного интеллекта традиционные базы данных, работающие исключительно на центральных процессорах (CPU), всё чаще упираются в физические пределы пропускной способности памяти и шины PCIe. Когда объемы данных исчисляются терабайтами, а запросы требуют мгновенного ответа, классические подходы становятся узким горлышком. Именно здесь на сцену выходит NVIDIA с новой архитектурой — GPU Query Engine (GQE). Это не просто еще одна библиотека, а фундаментально переработанный подход к выполнению SQL-запросов, который использует всю мощь современных графических процессоров, таких как NVIDIA Blackwell, для обработки аналитических нагрузок.
В этой статье мы подробно разберем, как работает GQE, какие аппаратные особенности NVIDIA GB200 NVL4 используются для ускорения, и почему гибридная стратегия сжатия данных позволяет достичь ускорения до 7,5 раз по сравнению с лучшими CPU-решениями. Мы рассмотрим архитектуру слоев, механизмы оркестровки данных, методы отсечения неактивных разделов (partition pruning) и реальные результаты бенчмарков TPC-H. Это руководство для инженеров данных, архитекторов баз данных и специалистов по AI, которые хотят понять, как перенести аналитику в эпоху GPU.
01Архитектура GQE: Три слоя производительности
GPU Query Engine (GQE) — это эталонная архитектура, разработанная NVIDIA для выполнения SQL-запросов с высокой производительностью на больших наборах данных. В основе системы лежат библиотеки NVIDIA CUDA-X, включая cuDF (для манипуляций с данными), nvCOMP (для сжатия) и nvSHMEM (для коммуникации). Главная цель GQE — не просто запустить запрос на GPU, а полностью переосмыслить путь данных от диска до результата, минимизируя задержки и максимизируя использование вычислительных ресурсов.
Архитектура GQE разделена на три логических слоя, каждый из которых решает свою задачу в конвейере обработки запроса:
1. Слой запросов (Query Layer)
Этот слой отвечает за понимание и оптимизацию SQL-запроса. GQE нативно поддерживает формат планов запросов Substrait — открытый стандарт, который позволяет экспортировать планы из существующих СУБД (например, Apache DataFusion) и выполнять их в GQE. Это критически важно для совместимости: вы можете взять готовый оптимизированный план запроса, передать его в GQE, и система добавит специфичные для GPU улучшения, преобразовав логический план в физический, готовый к исполнению на графическом процессоре.
2. Слой данных (Data Layer)
Слой данных абстрагирует хранение информации. Он использует подключаемые модули (readers) для работы с различными форматами и носителями: памятью GPU, памятью CPU или дисковым пространством. В данной статье мы фокусируемся на высокопроизводительном формате in-memory таблиц, где данные хранятся в CPU-памяти, но передаются на GPU по требованию. GQE не загружает весь терабайный датасет в видеопамять сразу; вместо этого он передает чанки (кусочками), насыщая GPU работой и избегая переполнения HBM (High Bandwidth Memory). Как только чанк поступает на GPU, управление передается исполняющему слою.
3. Исполняющий слой (Execution Layer)
Здесь происходит магия вычислений. GQE преобразует физический план запроса в граф задач (task graph), который определяет порядок выполнения операций. Реляционные операторы реализованы на базе библиотеки NVIDIA cuDF с использованием оптимизированного кода на CUDA C++. Благодаря тому, что слой данных передает данные чанками, GQE может разбивать операторы и выполнять задачи параллельно, используя конвейерные потоки CUDA (pipelined CUDA streams). Это позволяет скрыть задержки ввода-вывода за вычислениями.
02Оркестровка передачи данных и организация памяти
Одной из главных проблем при использовании GPU является задержка при перемещении данных между CPU и GPU. Даже с быстрыми шинами PCIe или NVLink-C2C, простое копирование гигабайтов данных может занять больше времени, чем сами вычисления. GQE решает эту проблему через тщательную организацию памяти и конвейерную передачу.
Формат данных в памяти
Внутреннее представление данных в GQE оптимизировано для работы с cuDF. Таблица горизонтально разбивается на группы строк (row groups). Каждая группа содержит столбцы и метаданные. Внутри группы столбцы хранятся как непрерывные разделы (partitions). При передаче данных слой преобразует набор этих разделов в формат столбца cuDF. Такая структура позволяет скрыть детали сжатия и отсечения разделов от самого исполняющего движка, делая интерфейс чистым и эффективным.
Конвейерная передача (Pipeline Parallelism)
GQE использует технику конвейерного параллелизма для перекрытия различных этапов обработки. Передача сжатых и разбитых на разделы данных состоит из четырех стадий, которые выполняются асинхронно:
- Стадия 0 (Планирование): Поток на хосте (CPU) вычисляет диапазоны памяти для передачи, выделяет буферы назначения и вызывает необходимые методы CUDA.
- Стадия 1 (Передача H2D): GPU выполняет передачу данных с хоста на устройство (Host-to-Device).
- Стадия 2 (Декомпрессия): Данные разжимаются. Здесь используются специализированные аппаратные блоки.
- Стадия 3 (Вычисление): CUDA-ядра выполняют сам запрос к данным.
Идеальная ситуация — когда эти стадии перекрываются во времени. Время выполнения всего конвейера определяется самой длинной стадией, а остальные стадии «прячут» свои задержки. Это достигается за счет использования нескольких потоков CUDA (CUDA streams), которые позволяют CPU планировать следующую передачу, пока GPU все еще обрабатывает предыдущий чанк.
03Гибридная компрессия: nvCOMP и Blackwell DE
Сжатие данных — это не просто способ сэкономить место. В контексте GQE сжатие является инструментом ускорения. Передача сжатых данных по шине занимает меньше времени, а быстрая декомпрессия на GPU позволяет восстановить исходные данные быстрее, чем их передача в несжатом виде. GQE использует гибридный подход, комбинируя алгоритмы сжатия для достижения баланса между степенью сжатия и скоростью декомпрессии.
Библиотека NVIDIA nvCOMP
nvCOMP — это библиотека для ускоренного сжатия и декомпрессии на GPU. Она поддерживает множество алгоритмов, позволяя выбирать между соотношением сжатия и пропускной способностью. GQE использует nvCOMP как основной движок сжатия, оборачивая даже CPU-библиотеки (например, lz4hc) в свой высокоуровневый интерфейс.
Движок декомпрессии Blackwell (DE)
Архитектура NVIDIA Blackwell представила новшество — Decompression Engine (DE). Это выделенный аппаратный блок, который позволяет декомпрессировать форматы на базе LZ77 (такие как LZ4, Snappy, Deflate) без использования ресурсов Streaming Multiprocessors (SM). Это критически важно, так как освобождает вычислительные ядра GPU для выполнения полезных задач по обработке запросов.
На одном GPU NVIDIA Blackwell B200 DE может достигать скорости декомпрессии до 400 ГБ/с. При коэффициенте сжатия 4:1 это дает эффективную пропускную способность передачи данных 400 ГБ/с, оставляя еще 100 ГБ/с пропускной способности NVLink-C2C для передачи других данных. Это означает, что GPU может одновременно принимать новые данные и обрабатывать старые, не простаивая.
Гибридная стратегия: Cascaded vs LZ4
GQE не заставляет пользователя выбирать алгоритм сжатия вручную. Вместо этого система автоматически решает, какой алгоритм использовать для каждого столбца, пробуя оба варианта:
- LZ4: Выбирается для общих данных. Он обеспечивает хорошее соотношение сжатия и полностью поддерживается аппаратным DE.
- Cascaded: Специализированный алгоритм, который комбинирует дельта-кодирование, кодирование длин серий (run-length encoding) и битовую упаковку. Он невероятно быстр (до 500 ГБ/с на B200) и эффективен для структурированных данных с повторяющимися паттернами.
Система сжимает данные обоими методами и выбирает тот, который дает лучшее соотношение, при условии, что Cascaded превосходит LZ4 по коэффициенту сжатия с учетом настраиваемого порога. Это позволяет балансировать использование пропускной способности C2C, DE и ресурсов SM.
04Отсечение разделов (Partition Pruning) и Zone Maps
Еще один мощный инструмент оптимизации в GQE — это отсечение неактивных разделов (filter pruning). Идея проста: если запрос запрашивает данные за определенный период или с определенным условием, зачем загружать в GPU данные, которые заведомо не подходят под это условие?
Zone Maps как метаданные
GQE использует Zone Maps — метаданные, которые хранят минимальные и максимальные значения для каждого столбца в каждом разделе (partition) таблицы. Эти метаданные хранятся в GPU-памяти в виде таблиц cuDF, что позволяет проверять их мгновенно, без задержек на доступ к CPU.
При загрузке данных в память GQE горизонтально разделяет таблицу на группы строк и фиксированные разделы (по умолчанию 10 миллионов строк). Вычисление Zone Maps добавляет всего около 1% к времени первоначальной загрузки из Parquet, но происходит только один раз, а не при каждом запросе.
Процесс отсечения
При построении графа задач GQE преобразует предикаты SQL-запроса в сравнения с Zone Maps. Если, например, запрос ищет значения больше 15, а Zone Map раздела показывает, что все значения в нем меньше 9, этот раздел полностью отбрасывается. Он не передается на GPU, не декомпрессируется и не обрабатывается.
Даже если отсеченные разделы разбросаны по разным группам строк в CPU-памяти, GQE собирает оставшиеся разделы в непрерывный блок памяти на GPU, упаковывая их в таблицу cuDF. Это минимизирует фрагментацию и упрощает дальнейшую обработку.
Эффективность этого метода на датасете TPC-H (1 ТБ) заключается в том, что filter pruning пропускает 31% данных во всех 22 запросах. Это дает ускорение всей системы на 1,43x. Оценку Zone Maps можно выполнить в среднем за 2,2 мс, что является ничтожно малой накладной нагрузкой.
05Пакетная передача (Batched Transfer)
Еще одна инновация GQE — оптимизация пакетной передачи разделов. Вместо того чтобы передавать каждый раздел по отдельности, что создает накладные расходы на вызовы функций и может вызывать задержки из-за переплетения потоков CUDA, GQE группирует несколько разделов в один пакет.
Используется функция cudaMemcpyBatchAsync, которая позволяет передать несколько блоков памяти за один вызов. Это не только снижает накладные расходы CPU на управление передачами, но и предотвращает задержки, когда передача из одного потока может заблокировать запуск ядра в другом. Пакетная передача обеспечивает более плавный и предсказуемый поток данных.
06Результаты производительности: TPC-H на GB200
Чтобы оценить реальную эффективность описанных оптимизаций, NVIDIA протестировала GQE на сервере NVIDIA GB200 NVL4. В тесте использовался один из двух GPU B200, соединенных с CPU Grace через NVLink-C2C. В качестве базовой линии (baseline) выступала база данных DuckDB 1.4.1, работающая на процессоре AMD Turin EPYC 9755. Тестирование проводилось на датасете TPC-H с масштабным фактором 1000 (1 ТБ данных), с включенным сжатием и отсечением разделов в обоих случаях.
Сравнение с CPU
Результаты оказались впечатляющими. GQE превзошел DuckDB в 20 из 22 запросов. Наибольшая разница наблюдалась в запросах Q11, Q14 и Q15, где отсечение разделов и сжатие резко сократили объем передаваемых данных по NVLink-C2C. Даже запросы, требующие большой пропускной способности (например, Q1 и Q6), выполнялись на GPU значительно быстрее.
Общее время выполнения всех 22 запросов в GQE составило 9,0 секунд, в то время как DuckDB потребовал 74,0 секунды (в одноплатной конфигурации) и 70,6 секунды (в двухплатной). Это означает агрегированное ускорение в 7,5 раз.
Максимальное ускорение для отдельного запроса достигло 25,5 раз. В 17 из 22 запросов ускорение составило 3x или выше. Эти цифры демонстрируют, что GPU-ускоренные базы данных могут не просто «быть быстрее», а кардинально менять парадигму аналитики, делая интерактивный анализ терабайтных данных рутинной задачей.
07Что это значит на практике
Для инженеров данных и архитекторов систем внедрение GQE или подобных GPU-ускоренных решений означает переход от «ожидания результата» к «мгновенному ответу». Вот ключевые выводы, которые стоит учитывать при проектировании современных аналитических платформ:
- Используйте аппаратные ускорители там, где это возможно. Выделенные блоки, такие как DE в Blackwell, освобождают основные вычислительные ресурсы. Не заставляйте SM-ядра заниматься тривиальной декомпрессией, если есть специализированный контроллер.
- Гибридное сжатие — это не роскошь, а необходимость. Автоматический выбор между быстрыми алгоритмами (Cascaded) и универсальными (LZ4) позволяет адаптироваться к структуре данных без вмешательства администратора.
- Отсечение данных до передачи — золотое правило. Никогда не передавайте на GPU то, что не нужно. Zone Maps и предикатная фильтрация на CPU-стороне (или в метаданных GPU) экономят драгоценную пропускную способность шины.
- Конвейеризация скрывает задержки. Асинхронная передача, декомпрессия и вычисления должны работать параллельно. Использование
cudaMemcpyBatchAsyncи множественных потоков CUDA — стандарт де-факто для высокопроизводительных систем.
Архитектура NVIDIA GQE показывает, что будущее аналитических баз данных лежит в плоской интеграции CPU и GPU, где каждый компонент выполняет свою узкоспециализированную задачу максимально эффективно. Для российских компаний и разработчиков, работающих с большими данными, понимание этих принципов становится критически важным в условиях импортозамещения и перехода на отечественные или альтернативные аппаратные платформы, где оптимизация кода и алгоритмов становится главным конкурентным преимуществом.
Если вы планируете внедрять GPU-ускоренную аналитику, начните с аудита ваших текущих узких мест: сколько времени уходит на передачу данных? Насколько эффективно используется сжатие? Ответы на эти вопросы помогут вам выбрать правильную стратегию оптимизации, будь то переход на cuDF, внедрение nvCOMP или пересмотр архитектуры хранения данных.
Источник: NVIDIA Developer ↗