Table of Contents

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

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

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

Объем и скорость

Один автономный испытательный автомобиль может генерировать от 1 до 10 терабайт сырых данных в день, когда все датчики полностью используются. Это включает в себя видеопотоки с высоким разрешением, облака точек от LIDAR, сканирование радаров, GPS-следы и журналы шины CAN транспортного средства. Системы баз данных должны принимать, индексировать и запрашивать эти данные в режиме реального времени для поддержки как автономного анализа, так и принятия решений на борту.

Задержка и требования реального времени

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

Целостность и последовательность данных

Алгоритмы синтеза датчиков объединяют данные из нескольких источников; любая непоследовательность в меток времени или заказ может привести к неправильным мировым моделям. Распределенные базы данных, используемые в разных парках, должны гарантировать возможную или сильную согласованность в зависимости от контекста. Кроме того, критически важные для безопасности системы должны придерживаться таких стандартов, как ISO 26262, который предъявляет строгие требования к регистрации данных, аудиторским следам и обнаружению ошибок.

Масштабируемость и стоимость

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

Edge Computing и распределенные базы данных

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

Распределенные базы данных, предназначенные для краевых сред, таких как Apache Cassandra, Riak и CockroachDB, позволяют каждому транспортному средству действовать как автономный узел базы данных.Эти системы копируют критические метаданные (например, обновления карт, журналы дорожно-транспортных происшествий) на транспортных средствах и центральных серверах с использованием бесконфликтных реплицированных типов данных (CRDT) или консенсусных протоколов, таких как Raft.В результате глобальная плоскость данных остается доступной даже тогда, когда отдельные транспортные средства отключены в течение длительных периодов времени.

Например, система Super Cruise от Cadillac опирается на комбинацию бортовых баз данных и облачной синхронизации для поддержания актуальной карты высокой четкости. Когда транспортное средство обнаруживает изменение дороги, оно аннотирует локальную базу данных; обновление затем распространяется на другие транспортные средства через ребра узлов. Этот шаблон, часто называемый «обучением флота», возможен только с распределенной архитектурой базы данных, которая придает приоритет возможной согласованности по сравнению с сильной согласованностью, где это уместно.

Обработка данных в реальном времени и базы данных в памяти

Критические для безопасности решения в АВ требуют доступа к данным в течение микросекунд. Традиционные дисковые реляционные базы данных вводят слишком большую задержку для бортовых операций. Базы данных в памяти стали стандартом для хранения и запроса информации о состоянии в реальном времени.

Redis широко используется для кэширования результатов синтеза датчиков, управления состояниями сеанса и хранения краткосрочных объектных треков. Его поддержка структур данных, таких как сортированные наборы и потоки, делает его особенно подходящим для данных датчиков временных рядов, которые должны быть запрошены с минимальными накладными расходами. MemSQL (теперь SingleStore) и VoltDB приносят обработку памяти в сочетании с возможностями SQL, позволяя выполнять сложные аналитические запросы по потоковым данным — например, вычислять вероятность пешеходного перехода на основе исторических траекторий.

В дополнение к чистым хранилищам в памяти, Apache Kafka стал незаменимым для отделения приема сенсоров от обработки. Темы Kafka служат центральной нервной системой конвейера данных AV: каждый датчик пишет на свою тему, а службы обработки потребляют и обогащают данные перед записью результатов в базы данных памяти для доступа с низкой задержкой. Эта архитектура позволяет инженерам воспроизводить исторические потоки для отладки и моделирования.

Заметным примером является использование Waymo специализированных баз данных в памяти для управления поведенческими прогнозами. Их система поддерживает «модель локальной среды», которая обновляется на частоте 100 Гц, смешивая данные LIDAR, камеры и радара. База данных должна поддерживать высокочастотные записи и запросы по времени - возможности, которые оптимизированные для памяти хранилища обеспечивают гораздо более эффективно, чем дисковые альтернативы.

Интеграция искусственного интеллекта

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

Особенности магазинов для AV Development

Магазин функций действует как централизованное хранилище для многоразовых, версионных функций, используемых для обучения моделей восприятия и планирования. Решения, такие как Feast и Tecton , все чаще накладываются поверх распределенных баз данных (например, AlloyDB или Firestore ), чтобы обеспечить функцию с низкой задержкой, обслуживающую как во время обучения, так и в режиме онлайн. Для автономных транспортных средств функции могут включать агрегированные показания датчиков, исторические траектории или погодные условия — все они хранятся и обслуживаются в масштабе.

Базы данных векторов для семантического поиска

Модели глубокого обучения часто представляют объекты (пешеходы, транспортные средства, знаки) в качестве высокоразмерных встраиваемых объектов. Векторные базы данных, такие как Pinecone, Milvus, и Weaviate, позволяют AV выполнять поиск сходства через эти встраиваемые объекты в миллисекундах. Эта возможность используется для идентификации редких случаев кромки — например, «найти все сцены вождения, где пешеход был закупорен грузовиком» — путем поиска похожих векторов встраивания, а не полагаться исключительно на метаданные теги.

База данных Driven Model Lifecycle Management

Поскольку AV-компании собирают петабайты маркированных данных, им необходимо управлять версиями наборов данных, отслеживать модельную линию и обеспечивать воспроизводимость. Такие инструменты, как DVC и LakeFS, привносят семантику управления версиями в крупномасштабные озера данных, в то время как специализированные базы данных записывают метаданные каждого тренировочного запуска, включая гиперпараметры, метрики проверки и точный используемый срез данных. Эта интеграция имеет решающее значение для соблюдения нормативных требований и постоянного улучшения.

Базы данных временных рядов для сенсорных журналов и телеметрии

Большинство данных, генерируемых автономными транспортными средствами, по своей сути являются временными: сканирование LIDAR, сообщения шины CAN, GPS-координаты и кадры камеры все несут временные метки. Базы данных общего назначения часто борются с шаблонами пропускной способности записи и запросов, требуемыми данными временных рядов. Поэтому специализированные базы данных временных рядов (TSDB) стали популярным выбором как для бортового, так и для облачного хранения.

InfluxDB и TimescaleDB (расширение PostgreSQL) являются ведущими опциями. Они предлагают автоматические политики хранения данных, выборку и непрерывные агрегаты, которые позволяют инженерам запрашивать длинные исторические тенденции (например, «средняя скорость на пересечении X за прошедшую неделю») без сканирования исходных данных. поставщики LIDAR, такие как Velodyne, опубликовали эталонные архитектуры с использованием InfluxDB для хранения и визуализации метаданных облака точек.

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

Графические базы данных для картирования и маршрутизации высокой четкости

Автономные транспортные средства зависят от карт высокой четкости, которые представляют геометрию дороги, разметку полос движения, дорожные знаки и динамические препятствия в качестве сети взаимосвязанных узлов и краев. Относительные базы данных не оптимизированы для запросов на прохождение, таких как «найти кратчайший путь из точки А в точку В, избегая зон строительства».

Neo4j и Amazon Neptune используются компаниями AV для моделирования топологий карт, хранения метаданных дорожного графа и поддержки обновлений маршрутизации в реальном времени. Например, когда транспортное средство получает уведомление о закрытии дороги через V2X (транспортное средство для всего), база данных графов может быстро пересчитать альтернативные маршруты и обновить запланированный путь транспортного средства. Базы данных графов также облегчают запрос сложных отношений — например, «какие знаки ограничения скорости видны из заданной точки на дороге?» — что громоздко в схемах плоских таблиц.

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

Озера данных и облачное хранилище

Учитывая огромный объем данных AV, многие организации перешли от монолитных хранилищ данных к озерам данных, построенным на объектном хранении, таким как Amazon S3, Google Cloud Storage, FLT:3 или Azure Blob Storage, FLT:5. Эти системы обеспечивают практически неограниченную емкость и позволяют отделять вычисления и хранение — критическая функция для экономической эффективности.

Современные архитектуры озер данных используют колоннообразные форматы файлов, такие как Apache Parquet и ORC, чтобы сжимать и индексировать журналы датчиков AV. Запросные движки, такие как Presto, Apache Spark и DuckDB, могут затем запускать SQL-запросы непосредственно на озере данных, не требуя дорогостоящего ETL. Это делает возможным выполнение специального анализа на петабайтах данных LIDAR, хранящихся в недорогом объектном хранилище.

Основной тенденцией является принятие форматов открытых таблиц , таких как , , , , , и . Эти форматы приносят ACID-транзакции, эволюцию схемы и путешествия во времени в озера данных. Для AV-инженерии путешествие во времени особенно мощно: оно позволяет разработчикам запрашивать точное состояние набора данных, как оно существовало в конкретный момент в прошлом, что необходимо для воспроизведения ошибок или оценки производительности модели на исторических снимках данных.

Трубопроводы для версий и моделирования данных

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

DVC (Управление версиями данных) интегрируется с облачным хранилищем для создания Git-подобной системы версий для больших наборов данных. При моделировании обнаруживается регрессия, инженеры могут проследить точные данные и версии моделей, которые привели к сбою. Некоторые команды используют LakeFS для создания изолированных «ветвей» озера данных, позволяя проводить параллельные эксперименты, не мешая производственным наборам данных.

Еще одна новая практика - хранение журналов повторного воспроизведения симуляции в базе данных, которая может быть запрошена для статистического анализа. Записывая траекторию, скорость и выход решения каждого участника во время моделирования, инженеры могут запускать агрегированные запросы, такие как «найти все эпизоды моделирования, когда транспортное средство не смогло выйти на четырехсторонней остановке». Это гораздо более эффективно, чем навигация по каталогам необработанных файлов журнала.

Безопасность, соблюдение и управление данными

Автономные транспортные средства несут конфиденциальные данные, включая кадры с камер общественных мест, следы местоположения GPS и потенциально личную информацию о водителе, что вызывает значительные проблемы конфиденциальности и безопасности. Системы баз данных теперь должны обеспечивать надежное шифрование в состоянии покоя и при транспортировке, мелкозернистый контроль доступа и журналирование аудита в соответствии с такими правилами, как GDPR, CCPA и ISO 26262.

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

Происхождение данных на основе блокчейна является еще одной зарождающейся тенденцией. Храня хэши критически важных AV-данных в блокчейне, производители могут создавать очевидные следы аудита для реконструкции аварий и соблюдения нормативных требований. Пока еще не в основном, несколько консорциумов (например, ] Mobility Open Blockchain Initiative ] пилотируют эти подходы.

Будущее: квантовое, федеративное обучение и автономные базы данных

Технологии баз данных, поддерживающие AV-инжиниринг, будут продолжать развиваться в тандеме с аппаратными средствами и сетевыми достижениями.

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

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

Наконец, рост автономных баз данных , впервые запущенных Oracle Autonomous Database и Amazon Aurora, означает, что многие рутинные задачи управления базами данных, такие как индексация, настройка и масштабирование, будут обрабатываться ИИ. Для AV-команд это означает снижение накладных расходов и больше времени, затрачиваемого на разработку, а не администрирование баз данных.

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

External References:
  1. Waymo Fleet Engineering — управление данными в реальном времени в масштабе
  2. InfluxData — базы данных временных рядов для автономной телеметрии транспортных средств
  3. Neo4j — графические базы данных в HD-картировании и оптимизации маршрутов
  4. Delta Lake — форматы открытых таблиц для озер данных AV
  5. Справедливое использование ИИ — Происхождение данных блокчейна для соблюдения требований автономных транспортных средств