Вступление

В этой статье мы представляем новую структуру, которая позволяет бесшовную интеграцию ПЛИС в платформу разработки Apache Arrow. Интеграция FPGA с Apache Arrow-совместимыми фреймворками позволяет ускорять приложения для обработки данных без какого-либо предшествующего опыта работы с FPGA.

Мы представляем прототип на Java, который обеспечивает бесшовную связь фреймворков с поддержкой Apache Arrow с FPGA. Сначала мы кратко объясняем цели нашей реализации, устраняя конкретные технические препятствия. Затем мы описываем наш конвейер обмена и передачи данных между ЦП и ПЛИС.

Мотивация

За последние несколько лет машинное обучение привлекло беспрецедентное внимание во многих отраслях. Изначально машинное обучение выполнялось в основном на процессорах общего назначения. Однако, поскольку машинное обучение требует чрезвычайно больших вычислений, для эффективной обработки огромных объемов данных требуется специализированное оборудование. Некоторые технологические гиганты переходят на специализированные аппаратные решения (среди недавних примеров - Tensor Processing Unit от Google).

Обслуживание центра обработки данных FPGA на месте представляет собой утомительный процесс, который препятствовал их широкому распространению, пока крупные поставщики облачных услуг не решили включить их в свои услуги. Поставщики гипермасштабируемых общедоступных облаков, такие как AWS, Alibaba Cloud, Baidu и Huawei, которые недавно развернули FPGA в своих центрах обработки данных. Это недавнее изменение привело к тому, что фреймворки оказались неподготовленными для учета взаимодействия с FPGA. Наше видение состоит в том, чтобы связать такие структуры с миром FPGA, чтобы обеспечить дальнейшие инновации в области машинного обучения.

Что такое Apache Arrow?

В последнее время Apache Arrow привлек значительное внимание в области фреймворков данных в памяти.

Apache Arrow определяет стандартизированный независимый от языка формат столбчатой ​​памяти для плоских и иерархических данных, организованных для эффективных аналитических операций на современном оборудовании. Формат памяти Arrow поддерживает чтение с нулевым копированием для эффективного доступа к данным без дополнительных затрат на сериализацию. - Программное обеспечение Apache

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

Почему Apache Arrow + FPGA?

В настоящее время Apache Arrow в первую очередь ориентирован на процессоры и графические процессоры. Наша цель - сделать шаг к тому, чтобы позволить ПЛИС использовать векторизованные данные и получать к ним доступ, учитывая, что ПЛИС и массивы обработки SIMD имеют много общих архитектурных особенностей. ПЛИС (или платформы Xilinx Adaptive Compute Acceleration Platforms - ACAP) предлагают преимущество индивидуальных архитектур для конкретных приложений, обеспечивая гораздо лучшую производительность и более высокую производительность на ватт.

InAccel, лидер в области ускорения FPGA как услуги, была первой компанией, предложившей ускорение Apache Spark ML на AWS с использованием экземпляров Xilinx f1 FPGA. Благодаря AWS он предлагает более чем 15-кратное ускорение для приложений машинного обучения. После нашей недавней интеграции с Apache Spark мы представляем наш прототип интеграции с Apache Arrow на Java.

описание проблемы

Предположим, мы хотим обучить модель машинного обучения с помощью кластера FPGA. Мы знаем, что FPGA работают лучше, чем оборудование общего назначения, если им поручено выполнение четко определенной задачи. Однако специалисты по обработке данных обрабатывают свои данные в памяти, и когда они планируют свою вычислительную задачу, ЦП просто должен выполнить ее, считывая данные из собственной памяти. С другой стороны, ядро ​​FPGA должно передать данные в свой банк памяти, чтобы продолжить выполнение.

В лучшем случае операции прямого доступа к памяти между FPGA и памятью, в которой находятся данные, будет достаточно для выполнения FPGA. Но это не всегда так. Мы должны убедиться, что минимизируют накладные расходы на копирование, которые могут возникнуть во время процесса, и при этом иметь возможность получать доступ к кадрам данных со стрелками из FPGA эффективным способом.

Решения системного дизайна

Ядро нашего конвейера ускорения во многом зависит от диспетчера Coral FPGA от InAccel, который отвечает за обработку запросов на ускорение и планирование их для оптимальных доступных аппаратных ресурсов. Менеджер ПЛИС сообщает ПЛИС, какую задачу им нужно выполнить и где находятся требуемые данные. В частности, запрос сериализуется и позже передается через сокеты TCP.

В идеале мы хотели бы обмениваться адресами данных между пользовательским процессом, FPGA-менеджером InAccel и фактическими FPGA. Совместно используемая память удовлетворила наше желание добиться передачи данных с нулевым копированием и была достигнута путем сопоставления памяти таких адресов со знаменитым каталогом Linux «/ dev / shm». Таким образом, все вышеперечисленные компоненты будут иметь доступ к той же области памяти, где находятся данные.

Следовательно, чтобы обеспечить передачу данных со стрелками на ПЛИС, нам нужно найти адреса, по которым находится каждый столбец со стрелками. Таким образом, мы можем сопоставить этот адрес с однозначно идентифицированным файлом в / dev / shm и соответственно сообщить об этом нашему менеджеру.

Мы настроили реализацию Apache Arrow, чтобы она работала иначе при передаче метаданных InAccel. В таком случае выделение столбца будет отображать в памяти начальный адрес памяти в файл совместно используемой памяти, к которому впоследствии будут обращаться ПЛИС.

Препятствие выравниванию страницы

Чтобы принудительно отобразить память файла на определенный адрес памяти, Linux требует, чтобы предоставленный адрес был выровнен по страницам. Реализация Arrow не поддерживала такую ​​опцию, что привело к заполнению пространства памяти до тех пор, пока у нас не были буферы данных, выровненные по страницам. Таким образом, мы обеспечили, чтобы все буферы данных с метаданными InAccel были выровнены по страницам. Судя по всему, столбцы со стрелками, не относящиеся к InAccel, никак не затронуты.

Вы можете найти пример использования логистической регрессии с помощью InAccel FPGA Manager, взаимодействующего с Apache Arrow здесь.

Будущие направления

Большинство случаев использования Arrow относятся к отправке заданий PySpark, чтобы избежать накладных расходов между пользовательской средой Python и исполнителем Spark, работающим на JVM. Поэтому в настоящее время мы работаем над расширением нашей интеграции, чтобы охватить реализацию C ++, а также тенденции преобразований науки о данных (например, от панд к стрелке). К счастью, выделение памяти, реализованное в C ++, позволяет выравнивать данные по страницам, что значительно облегчит нашу интеграцию .

Наконец, в следующей части нашей серии мы продемонстрируем вариант использования отправки искровых заданий через PySpark с пандами Dataframe с поддержкой Arrow и FPGA, обрабатывающими рабочую нагрузку под капотом.

Димитрис Леккас, инженер-программист, InAccel, ICCS-NTUA

Элиас Коромилас, соучредитель и главный архитектор InAccel

Иоаннис Стамелос, соучредитель и главный технолог InAccel

Крис Кахрис, соучредитель и генеральный директор InAccel