Влияние Spark на обработку данных автономных транспортных средств в области инженерных исследований и разработок

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

Масштаб данных в производственных АВ-флотах

Для инженерных команд, эксплуатирующих испытательные парки 50-100 автомобилей, скорость генерации данных может превышать 50 терабайт в день. Хранение, индексирование и запрос этих данных для разработки алгоритма требует распределенных систем хранения, таких как HDFS или хранилища облачных объектов, в сочетании с уровнем обработки, который может эффективно сканировать петабайт данных. Способность Spark считывать данные из нескольких систем хранения, применять преобразования в памяти и записывать результаты обратно в постоянное хранилище делает его подходящим для этих крупномасштабных конвейеров данных.

R&D-команды обычно используют Spark для таких задач, как извлечение маркированных примеров обучения из журналов необработанных датчиков, вычисление статистики по большим наборам данных для проверки и выполнение крупномасштабных проверочных операций параметров во время настройки алгоритма. Без распределенных возможностей обработки эти задачи заняли бы дни или недели на одномашинных системах, замедляя цикл разработки и ограничивая количество команд экспериментов.

Архитектура Spark для трубопроводов обработки AV-данных

Потребление данных и ETL

Первый этап в любом AV-проводнике данных — извлечение, преобразование и загрузка необработанных данных датчиков в формат, пригодный для анализа. DataFrames Spark может считывать данные из Parquet, Avro, JSON и других общих форматов напрямую, позволяя командам обрабатывать необработанные журналы без промежуточных этапов преобразования. Для организаций, использующих облачное хранилище, Spark может считывать из S3, Azure Blob Storage или Google Cloud Storage, позволяя командам отделять вычисления из хранилища и масштабировать каждый независимо.

Типичный конвейер ETL для данных LiDAR может включать чтение необработанных облачных файлов точек, фильтрацию наземных точек, вычислительные функции, такие как нормальные поверхности и статистика интенсивности, и запись преобразованных данных в виде файлов Parquet для задач машинного обучения. Ленивая модель оценки Spark означает, что эти преобразования компилируются в оптимизированный план выполнения, при этом оптимизатор запросов автоматически выбирает эффективные стратегии соединения и выталкивания предикатов.

Для данных камеры инженерным командам часто требуется извлекать кадры в определенные временные метки, применять геометрические поправки и генерировать метаданные изображения, включая параметры камеры и информацию о позе.Встроенная поддержка Spark для пользовательских функций позволяет командам интегрировать OpenCV или пользовательские библиотеки обработки изображений в API DataFrame, хотя при обработке больших полезных нагрузок изображения требуется тщательное управление памятью, чтобы избежать узких мест на стороне водителя.

Обработка данных в реальном времени с помощью потоковой передачи Spark

В то время как большая часть AV R&D фокусируется на автономном анализе зарегистрированных данных, возможности обработки в режиме реального времени необходимы для определенных вариантов использования, особенно во время тестирования и проверки транспортных средств. Spark Streaming предоставляет модель обработки микропакетов, которая разделяет входящие потоки данных на небольшие партии (обычно от 500 миллисекунд до 2 секунд) и обрабатывает их с использованием того же API DataFrame, используемого для пакетных рабочих нагрузок.

В контексте исследований и разработок автономных транспортных средств случаи использования потоковой передачи включают:

• Обнаружение аномалий в реальном времени: Мониторинг состояния здоровья датчика и качества данных во время тест-драйвов, немедленное помечение поврежденных или отсутствующих показаний датчика.
• Анализ телеметрии в реальном времени: Обработка данных о состоянии транспортного средства, включая данные о скорости, ускорении и управлении, для обнаружения небезопасных моделей вождения во время автономной работы.
• Фильтрация данных с края до облака: Выбор и загрузка только наиболее релевантных сегментов данных из транспортных средств в облако для дальнейшего анализа, снижения требований к пропускной способности и затрат на хранение.
• Операционный мониторинг: Отслеживание показателей в масштабе всего парка, таких как мили, пройденные за вмешательство, разъединение водителя и охват сценария в режиме реального времени.

Для инженерных команд возможность обрабатывать как пакетные, так и потоковые данные с одной и той же кодовой базой упрощает разработку и тестирование.Переработка, написанная для пакетной обработки, может быть развернута в потоковом контексте с минимальными модификациями, позволяя командам прототипировать офлайн, а затем переходить к операциям в реальном времени, когда они будут готовы.

Интеграция машинного обучения для автономных систем вождения

Подготовка данных для моделей восприятия

Модели восприятия объектов для обнаружения, сегментации полосы движения и распознавания дорожных знаков требуют больших, меченых наборов данных. Библиотека Spark MLlib предоставляет характерные трансформаторы для масштабирования, нормализации и кодирования категориальных переменных, но реальная ценность для AV-команд заключается в способности Spark готовить обучающие данные в масштабе. Инженеры используют Spark для объединения данных датчиков с наземными ярлыками правды, генерировать примеры обучения с помощью методов раздвижного окна и вычислять статистику по всем наборам данных для нормализации и отбеливания.

Для моделей обнаружения объектов подготовка данных обучения включает извлечение областей интереса из кадров камеры, вычисление координат ограничивающих коробок относительно системы координат транспортного средства и выравнивание меток из нескольких модальностей датчиков.Распределённые операции соединения Spark позволяют командам комбинировать списки объектов LiDAR с обнаружением камер и радиолокационными дорожками через большие временные окна, производя обучающие примеры, которые захватывают полный контекст синтеза датчика.

Одним из распространенных шаблонов в AV R&D является использование Spark для курирования данных - выбор примеров для включения в учебный набор на основе разнообразия, сложности или охвата сценария. Вычисляя встраиваемые векторы или статистику функций по всему набору данных, команды могут идентифицировать избыточные примеры, обнаруживать ошибки меток и балансировать распределения классов до начала обучения. Этот ориентированный на данные подход к разработке моделей становится все более важным, поскольку AV-команды признают, что качество данных часто имеет большее значение, чем архитектура модели для реальной производительности.

Оценка и валидация крупномасштабных моделей

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

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

Параметрические швы и гиперпараметрическая оптимизация

Автономные системы вождения содержат десятки параметров, которые должны быть настроены для оптимальной производительности - параметры калибровки датчика, отслеживание усиления фильтра, планирование весов затрат и усиление управления, среди прочего. Поиск правильной комбинации параметров требует проведения экспериментов в нескольких измерениях, причем каждый эксперимент требует обработки значительных объемов тестовых данных. Модель распределенного исполнения Spark позволяет командам параллелизовать пройденные параметры, выполняя различные конфигурации параметров на разных узлах или кластерах одновременно.

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

Преимущества Spark для автономных команд R&D

Скорость развития

Наиболее значительным преимуществом Spark для AV R&D команд является скорость разработки. Задачи обработки данных, которые занимали бы часы или дни на одномашинных системах, завершаются за считанные минуты на кластерах Spark. Это ускорение сжимает петлю обратной связи между формированием гипотез и экспериментальной валидацией. Инженер, который хочет протестировать новый алгоритм предварительной обработки или оценить вариант модели, может получить результаты, пока идея еще свежа, а не ждать ночных партийных заданий.

Интерактивные оболочки Spark (PySpark, spark-shell) позволяют инженерам исследовать данные итеративно, проверяя промежуточные результаты и корректируя преобразования на лету. Эта исследовательская способность особенно ценна при работе с новыми конфигурациями датчиков или новыми средами вождения, где соответствующие преобразования данных заранее не известны. Команды могут прототипировать в интерактивной оболочке, а затем производить код в качестве приложений Spark, сокращая время от концепции до развертывания.

Эффективность затрат за счет оптимизации ресурсов

Развертывание Spark на основе облачных вычислений позволяет AV-командам сопоставлять вычислительные ресурсы с требованиями к рабочей нагрузке. В пиковые периоды, например, при обработке новой партии данных из многотранспортной тестовой кампании, команды могут создавать большие кластеры, которые обрабатывают данные в течение нескольких часов. В более тихие периоды кластеры могут быть уменьшены или полностью отключены, избегая фиксированных затрат, связанных с локальной инфраструктурой. Спотовые экземпляры и упреждаемые виртуальные машины еще больше снижают затраты на отказоустойчивые пакетные нагрузки.

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

Интеграция с существующими экосистемами данных

Большинство автономных транспортных организаций уже инвестируют в инфраструктуру данных, включая хранилища объектов, хранилища данных и инструменты оркестровки рабочего процесса. Spark интегрируется с этими системами, считывая S3, ADLS или GCS, записывая в таблицы Delta Lake или Iceberg и управляясь такими инструментами, как Apache Airflow, Prefect или Dagster. Эта интеграция означает, что инженерные команды могут принять Spark без капитального ремонта своей существующей архитектуры данных, снижения риска миграции и сохранения предыдущих инвестиций.

Для команд, использующих Databricks, платформа управляемых Spark предоставляет дополнительные возможности, включая совместные ноутбуки, автоматизированное управление кластерами и интеграцию с MLflow для отслеживания экспериментов.Хотя эти управляемые сервисы не требуются для использования Spark, эти управляемые сервисы уменьшают операционные накладные расходы на запуск кластеров Spark, позволяя командам R&D сосредоточиться на разработке алгоритмов, а не на управлении инфраструктурой.

Проблемы в развертывании Spark для AV Workloads

Сериализация данных и накладные расходы на производительность

Одна из практических задач, с которой сталкиваются инженерные команды при использовании Spark для AV-данных, — это накладные расходы на сериализацию данных. Облака точек LiDAR и изображения камеры обычно хранятся в двоичных форматах, оптимизированных для скорости чтения, но среда выполнения Spark на основе JVM требует десериализации данных в объекты Java или Python для обработки. Для рабочих нагрузок, которые включают сканирование больших объемов данных датчиков, накладные расходы на сериализацию могут доминировать во времени выполнения, уменьшая преимущество производительности обработки в памяти.

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

Ограничения задержки для контроля в реальном времени

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

Даже для менее чувствительных к времени сценариев использования потоковой передачи характеристики задержки Spark Streaming должны быть тщательно управляемыми. Для приложений оперативного мониторинга, где допустимы 1-2 секундные задержки, Spark хорошо работает. Приложения, требующие задержки менее 100 миллисекунд, должны учитывать альтернативные потоковые платформы, такие как Apache Flink или специализированные двигатели обработки потоков, предназначенные для рабочих нагрузок с низкой задержкой.

Сложность управления кластерами

Для запуска кластеров Spark в масштабе требуется операционный опыт в распределенных системах. Параметры конфигурации для распределения памяти, перетасовки разделов и размера исполнителя должны быть настроены для каждой рабочей нагрузки для достижения оптимальной производительности. Для команд AV R&D, чья основная компетенция заключается в автономных алгоритмах вождения, а не распределенной инфраструктуре, управление кластерами Spark может отвлекать от основных инженерных целей.

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

Будущие направления: Spark и эволюция обработки AV-данных

Edge Computing и федеративное обучение

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

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

Spark 3.x и GPU-ускорение

Последние версии Spark добавили поддержку ускорения GPU через ускоритель RAPIDS для Apache Spark и библиотеку Spark Accelerator. Эти инструменты позволяют инженерам использовать аппаратное обеспечение GPU для операций обработки данных, таких как соединения, агрегации и сортировка, достигая значительных улучшений производительности для вычислительно-интенсивных рабочих нагрузок. Для AV-команд, уже использующих графические процессоры для обучения глубокому обучению, возможность использовать то же самое оборудование для обработки данных снижает затраты на инфраструктуру и упрощает управление кластерами.

Ожидается, что проект Hydrogen, инициатива по улучшению интеграции Spark с графическими процессорами и фреймворками глубокого обучения, обеспечит более тесную интеграцию между конвейерами данных Spark и популярными библиотеками глубокого обучения, такими как PyTorch и TensorFlow. Эта интеграция позволит инженерным командам создавать сквозные трубопроводы, которые обрабатывают подготовку данных, обучение модели и оценку в рамках одного приложения Spark, уменьшая сложность перемещения данных между отдельными системами обработки.

Интеграция моделирования в реальном времени

Моделирование является критическим компонентом AV R&D, позволяя командам тестировать системы в миллионах сценариев, которые было бы опасно или непрактично воспроизводить в реальном мире. Роль Spark в моделировании двояка: во-первых, он обрабатывает результаты крупномасштабного моделирования, выполняет вычисление агрегатных метрик и идентификацию краевых случаев; во-вторых, он готовит библиотеки сценариев и экологические модели, используемые для управления моделированием. По мере увеличения точности моделирования и роста требований к вычислениям возможности распределенной обработки Spark становятся все более важными для поддержания темпов объемов данных моделирования.

Тенденция к моделированию замкнутого цикла, когда системы восприятия и планирования AV взаимодействуют с имитируемой средой, генерирует непрерывные потоки данных, которые должны обрабатываться в режиме реального времени для проверки поведения системы. Spark Streaming в сочетании с фреймворками моделирования, которые подают данные в трубопроводы Spark, позволяет командам проводить кампании моделирования, которые охватывают недели или месяцы, непрерывно отслеживая производительность системы.

Заключение

Apache Spark зарекомендовал себя как важный инструмент в автономном инструменте для разработки и разработки транспортных средств, предоставляя распределенную вычислительную инфраструктуру, необходимую для обработки массивных наборов данных, генерируемых тестовыми парками, оснащенными датчиками. От приема данных и ETL до подготовки конвейера машинного обучения и крупномасштабной проверки, Spark поддерживает полный жизненный цикл обработки AV-данных с помощью единого API, который охватывает пакетные и потоковые рабочие нагрузки.

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

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