В последние годы автономное вождение стало популярным направлением.Стартапы, производители новых автомобилей и традиционные автомобильные заводы, которые сосредоточены на технологии автономного вождения, вложили много ресурсов в эту область, продвигая опыт автономного вождения уровня L4 и L5, чтобы выйти на рынок. наша повседневная жизнь как можно скорее.
Основным звеном в реализации технологии автономного вождения является обучение моделей автономного вождения.Обучающие данные представляют собой реальные видеоролики о вождении, собранные автомобилями, а масштаб данных составляет от нескольких петабайт до десятков петабайт. Прежде чем модель будет обучена, эти исходные видео должны быть обработаны, а ключевые кадры захвачены и сохранены как фотографии. Затем профессиональная команда по маркировке данных отметит на изображении ключевую информацию, такую как светофоры, дорожная разметка и т. д. В конце концов, миллиарды изображений и размеченных данных становятся тем, что действительно «питает» тренировочную среду.
Друзья, знакомые с распределенными системами и распределенными хранилищами, должны знать, что LOSF (множество мелких файлов) представляет собой большую проблему в области хранения. В области искусственного интеллекта CV (Computer Vision) обучение на базе LOSF просто необходимо, включая такие подразделения, как автоматическое вождение, распознавание лиц и обнаружение объектов.
Эта статья основана на архитектурной практике клиента в индустрии автономного вождения JuiceFS, которая провела серию успешных исследований в сценарии обучения десятков миллиардов небольших файлов, надеясь принести некоторую справку и вдохновение для применения смежные отрасли.
Конечная задача управления десятками миллиардов небольших файлов
Большинство обучающих наборов данных для систем автономного вождения содержат от миллиардов до десятков миллиардов небольших файлов (файлы размером менее 1 МБ), а для одного обучения обычно требуется от десятков миллионов до сотен миллионов файлов. Более того, обучающим работникам необходимо часто обращаться к системе хранения каждый раз, когда они генерируют мини-пакеты, большинство из которых являются запросами метаданных, поэтому производительность метаданных напрямую влияет на эффективность обучения модели.
Это требует, чтобы система хранения не только могла управлять десятками миллиардов файлов, но и поддерживать производительность метаданных с низкой задержкой и высокой пропускной способностью при большом количестве одновременных запросов.
При выборе систем хранения объектное хранилище может содержать десятки миллиардов файлов, но отсутствие встроенной поддержки каталогов, отсутствие полной семантической поддержки POSIX и низкая производительность метаданных делают объектное хранилище непригодным для сценариев обучения больших объемов небольших файлов.
В некоторых распространенных архитектурах распределенных файловых систем HDFS не подходит для хранения небольших файлов.Хотя для размещения определенного масштаба данных можно использовать Scale-Up NameNode и федерацию, хранить десятки миллиардов небольших файлов по-прежнему сложно. очень сложная вещь; хотя MDS CephFS имеет возможность масштабирования, возможности одновременной обработки одного процесса невелики.По мере роста размера кластера MDS увеличиваются затраты на координацию между процессами, так что общая производительность не может достигать линейный рост.
Хотя формат TFRecord объединения нескольких небольших файлов в большие файлы поддерживается в TensorFlow для снижения нагрузки метаданных на систему хранения в процессе обучения, в области автономного вождения эта схема снижает точность случайной выборки набора данных, Другие обучающие фреймворки (такие как PyTorch) также несовместимы, доставляя массу неудобств.
Как JuiceFS решает эту проблему?
JuiceFS — это распределенная файловая система с открытым исходным кодом, разработанная для облачных сред.Инновации JuiceFS заключаются в следующем:
- Любое объектное хранилище можно использовать в качестве уровня сохраняемости данных для сохранения содержимого данных. JuiceFS можно использовать в любой общедоступной или частной облачной среде при наличии службы хранения объектов;
- 100% совместимость с тремя основными протоколами доступа POSIX, HDFS, S3, возможность подключения ко всем приложениям;
- Механизм метаданных представляет собой подключаемую архитектуру и поддерживает в качестве механизмов хранения различные базы данных, включая Redis, TiKV, MySQL и т. д. В то же время он также предоставляет коммерческие механизмы метаданных с высокой производительностью и большим объемом памяти.
Коммерческий механизм метаданных JuiceFS использует алгоритм Raft для формирования распределенного кластера, чтобы обеспечить надежность, согласованность и высокую доступность данных. Все метаданные хранятся в памяти узла, чтобы обеспечить отклик с малой задержкой. Движок метаданных использует схему динамического дерева каталогов для горизонтального расширения.Каждый сегмент представляет собой независимую группу Raft.Дерево каталогов файловой системы может быть разделено произвольно и распределено по нужным сегментам.Автоматическая балансировка и ручная балансировка объединены. Механизм сегментирования прозрачен для клиентского доступа.
Гибкая конфигурация кеша значительно повышает эффективность обучения
Поскольку задача обучения требует частого доступа к системе хранения, накладные расходы на каждое прохождение по сети также составляют большую избыточность.В настоящее время отрасль изучает решения по ускорению кэширования после разделения хранилища и вычислений. JuiceFS имеет встроенную возможность кэширования.Данные, к которым обращается клиент, могут быть автоматически кэшированы на носителе данных, указанном узлом.При следующем доступе к кешу можно напрямую попасть, и нет необходимости его читать через сеть. Точно так же метаданные автоматически кэшируются в памяти клиента.
Механизм кеша прозрачен в использовании, и нет необходимости изменять существующее приложение, просто добавьте несколько параметров при монтировании клиента JuiceFS, указав путь кеша, емкость и другую информацию. Влияние кэширования на ускорение обучения очень очевидно, вы можете обратиться к другой нашей статье «Как использовать JuiceFS для ускорения обучения модели AI в 7 раз». Кэширование не только ускоряет обучение, но и значительно сокращает количество вызовов API объектного хранилища, тем самым уменьшая накладные расходы.
Для распределенной обучающей платформы одни и те же обучающие данные могут совместно использоваться разными задачами, и эти задачи не могут быть запланированы для одного и того же узла.Если они распределены по разным узлам, можно ли совместно использовать данные кэша? Используя функцию «совместного использования данных кэша» JuiceFS, несколько обучающих узлов образуют кластер кэша, и задачи обучения в этом кластере могут совместно использовать данные кэша. То есть, когда узел, на котором находится обучающая задача, не попадает в кеш, данные можно получить через другие узлы в том же кластере, не запрашивая удаленное объектное хранилище.
Учебная нода не может быть статическим ресурсом.Особенно в контейнерной платформе жизненный цикл меняется очень быстро.Повлияет ли это на эффект совместного использования данных кеша? Это приводит к следующему вопросу.
Проблемы механизмов кэширования в эластичных кластерах
В каждой компании, занимающейся беспилотным вождением, есть много исследователей алгоритмов и инженеров, и их алгоритмы должны совместно использовать вычислительные ресурсы компании для завершения обучения и проверки. С точки зрения платформы эластичное масштабирование ресурсов — хороший способ улучшить общее использование ресурсов.Ресурсы выделяются для каждой учебной задачи по мере необходимости, чтобы избежать потерь.
Однако в таком эластично масштабируемом кластере вышеупомянутые данные локального кэша будут затронуты в определенной степени. Хотя кэш-кластер гарантирует, что при изменении членов кластера данных, которые необходимо перенести, будет как можно меньше за счет согласованного хеширования, но для крупномасштабных обучающих кластеров такая миграция данных все равно повлияет на общую эффективность обучения.
Существует ли метод, который может удовлетворить спрос на эластичное масштабирование ресурсов обучающего кластера без существенного влияния на эффективность обучения модели?
Для этого требуется уникальная функция «независимый кластер кеша» JuiceFS.
Так называемый независимый кеш-кластер относится к независимому развертыванию узлов, ответственных за хранение кэшированных данных, для предоставления услуг резидентных кэшированных данных. На это не повлияют динамические изменения обучающего кластера, так что обучающая задача будет иметь более высокую и стабильную скорость попадания в кэш.
Общая архитектура системы показана на следующем рисунке:
Например, если есть динамический обучающий кластер A и кластер B, предназначенный для кэширования, они оба должны использовать одни и те же параметры монтирования.--cache-group=CACHEGROUPПостроить группу кеша, в которую нужно добавить узлы кластера А при их монтировании--no-sharingпараметр. Когда приложение кластера A читает данные, если в памяти текущего узла и на кэш-диске нет кэшированных данных, оно выберет узел из кластера B для чтения данных в соответствии с согласованным хэшем.
В настоящее время вся система состоит из трех уровней кешей: системного кеша учебного узла, дискового кеша учебного узла и кеша в кластере кеша B. Пользователи могут настраивать носитель кеша и емкость каждого уровня. в соответствии с характеристиками доступа конкретных приложений.
Чтобы гарантировать, что учебные задачи не пострадают при повреждении диска, JuiceFS также предоставляет возможности аварийного восстановления данных кэша. Если диск узла кэша случайно поврежден, JuiceFS может автоматически восстановить требуемые данные кэша после замены нового диска.
Как снизить затраты и повысить эффективность в гибридном облаке?
Учебная задача автономного вождения требует много ресурсов GPU, при условии полной загрузки покупка GPU в машинном зале может быть намного дешевле, чем использование публичных облаков, это также выбор многих компаний, занимающихся автономным вождением. Однако построить самодельную СХД в компьютерном зале не так просто и придется столкнуться с двумя трудностями:
- Данные быстро растут, и отделу закупок трудно угнаться за скоростью расширения. Покупка слишком большого количества данных за один раз приведет к потерям;
- Чтобы поддерживать крупномасштабный кластер хранения, вы должны столкнуться с такими проблемами, как повреждение диска, высокие затраты на эксплуатацию и обслуживание и низкая эффективность;
По сравнению с самодельной системой хранения, служба хранения объектов в общедоступном облаке может быть эластично масштабирована, бесконечно расширяться, а удельная стоимость является низкой.По сравнению с самостоятельно построенной системой хранения в компьютерном зале, надежность данных и доступность сервиса выше, это хороший выбор для хранения больших объемов данных.
JuiceFS очень подходит для этой гибридной облачной архитектуры IDC room + public cloud. Пользователи подключают свой собственный компьютерный зал IDC к выделенной линии общедоступного облака, и данные сохраняются в объектном хранилище общедоступного облака через JuiceFS, а в компьютерном зале IDC создается кластер кеша для кэширования данных для ускорения обучения. экономить только пропускную способность выделенной линии, но и экономить стоимость вызовов API объектного хранилища.
Когда гибридная облачная архитектура сочетается с JuiceFS, она не только обладает удобством, обеспечиваемым облачным хранилищем, но и снижает затраты на GPU благодаря самостоятельно созданному IDC. Это очень просто и удобно для пользователей и специалистов по обслуживанию учебной платформы, а также отвечает разнообразным потребностям предприятий в проектировании инфраструктуры.
Синхронизация данных и управление несколькими компьютерными залами
В этом практическом случае у клиента есть два IDC, которые находятся в тысячах километров друг от друга, и задачи обучения также будут распределяться между двумя IDC, поэтому доступ к набору данных также должен быть в двух IDC. Ранее клиенты вручную поддерживали и реплицировали наборы данных в два IDC. После использования JuiceFS функция «зеркалирования данных» может сэкономить предыдущий ручной труд, а данные синхронизируются в режиме реального времени для удовлетворения потребностей совместной работы в нескольких местах.
В частности, для функции зеркалирования данных требуется, чтобы кластер метаданных JuiceFS был развернут в обоих IDC.Когда зеркалирование данных включено, исходная файловая система автоматически копирует метаданные в зеркалируемую область. После монтирования зеркальной файловой системы клиент извлекает данные из хранилища объектов исходной файловой системы и записывает их в хранилище объектов зеркальной файловой системы. После монтирования зеркальной файловой системы данные сначала будут считываться из локального объектного хранилища, если чтение не удалось из-за неполной синхронизации, данные будут считаны из объектного хранилища исходной файловой системы.
После включения зеркального отображения данных все данные могут быть автоматически реплицированы в два объектных хранилища для аварийного восстановления за пределами площадки. Если удаленное аварийное восстановление не требуется, в зеркальной области нельзя настроить объектное хранилище, а реплицировать можно только метаданные, которые можно предварительно разогреть в независимый кэш-кластер в зеркальной области для ускорения обучения. Это позволяет сэкономить на объектном хранилище, которое в данном случае принял заказчик.
Комплексная защита данных
Независимо от того, идет ли речь о вождении с помощником или о подлинном автономном вождении, необходимо ежедневно собирать большое количество данных о горных работах с помощью транспортных средств, и эти данные будут храниться в системе хранения предприятия после вторичной обработки посредством некоторой обработки. процедуры. Предприятия, занимающиеся автономным вождением, предъявляют чрезвычайно высокие требования к безопасности и надежности этих данных, поэтому защита данных является очень важным вопросом.
Давайте сначала рассмотрим проблемы безопасности после того, как предприятия перейдут в облако. Часто у предприятий возникают определенные проблемы с безопасностью данных при переходе в облако, особенно когда речь идет о некоторых конфиденциальных данных. Функция «Шифрование данных», предоставляемая JuiceFS, поддерживает как шифрование при передаче, так и шифрование при хранении, чтобы обеспечить безопасность данных во всех аспектах процесса миграции в облако.
Вторая возможная проблема — управление данными. Чтобы предотвратить утечку данных или неправомерное использование, компаниям может потребоваться управлять разрешениями для разных групп и пользователей и контролировать их. Служба хостинга JuiceFS может ограничивать права на чтение и запись для определенного диапазона IP-адресов и доступных подкаталогов с помощью «токенов доступа». После установки JuiceFS поддерживает модель управления разрешениями на основе «пользователь/группа пользователей», которая может гибко устанавливать разрешения для групп или отдельных лиц.
Если у пользователя уже есть разрешение на доступ к некоторым данным, все равно необходимо дополнительно защитить данные, например, пользователь может удалить или обновить данные по ошибке. В случае случайного удаления функция «Корзина», предоставляемая службой хостинга JuiceFS, может гарантировать, что данные можно будет снова восстановить в течение определенного периода времени после их удаления.
Но если данные обновлены по ошибке или повреждены по какой-либо причине, даже наличие корзины не поможет.В настоящее время функция «защита данных в реальном времени» JuiceFS очень полезна. Принцип реализации этой функции заключается в сохранении журнала Raft в течение определенного периода времени, чтобы при некорректном обновлении данных метаданные на тот момент можно было восстановить, воспроизведя исторический журнал. В то же время, поскольку файлы, записываемые JuiceFS в объектное хранилище, хранятся в блоках, обновление файла не изменит исторические блоки, а создаст новые блоки, поэтому до тех пор, пока исторические блоки в объектном хранилище не будут удалены , данные могут быть полностью восстановлены.Это как "машина времени", которая может вернуться в прошлое в любой момент!
Суммировать
Полный архитектурный проект
На следующем рисунке показана общая схема архитектуры этого случая.Кластер метаданных JuiceFS и соответствующий независимый кластер кеша развернуты в машинном зале A и B. Во время обучения модели набор данных будет сначала считываться через кластер кеша.Чтение данных из хранилища объектов . В реальном тесте, поскольку частота попаданий в кэш очень высока, комнате B вряд ли потребуется доступ к хранилищу объектов в другой комнате.
На следующем рисунке показан процесс записи данных. Клиенты записывают данные через шлюз S3, предоставляемый JuiceFS. При записи новых данных метаданные будут скопированы в другую компьютерную комнату в соответствии с описанным выше процессом зеркалирования данных. В то же время в обоих компьютерных залах есть соответствующие задачи, отвечающие за предварительный прогрев независимого кэш-кластера, чтобы обеспечить своевременное кэширование новых данных.
Преимущества для клиентов
Данное решение запущено в производственную среду заказчика Ниже приведены некоторые важные показатели:
- Миллиарды файлов были сохранены и продолжают расти;
- Метаданные JuiceFS по-прежнему могут обеспечивать задержку в 1 мс при сотнях тысяч запросов в секунду;
- Пропускная способность обучения модели составляет десятки ГиБ/с;
- Независимый кэш-кластер с вероятностью попадания 95%+;
- Средняя задержка синхронизации данных между двумя IDC составляет десятки миллисекунд.
Перейдя на систему хранения на основе JuiceFS, клиенты могут не только легко управлять массивными наборами данных, но и обеспечить эффективность обучения моделей с помощью функции независимого кэш-кластера JuiceFS.Несмотря на то, что затраты на эксплуатацию и обслуживание значительно снижены, гибридная облачная архитектура «компьютерный зал + общедоступное облако» имеет более низкую совокупную стоимость владения, чем единая общедоступная облачная архитектура.Он может не только использовать экономичные вычислительные ресурсы компьютерного зала, но и объединить эластичные ресурсы хранения в общедоступном облаке..
Благодаря полной совместимости JuiceFS с POSIX клиентам не нужно вносить какие-либо изменения в код обучающих задач в процессе миграции.
Благодаря функции зеркалирования данных JuiceFS данные автоматически синхронизируются из одной компьютерной комнаты в другую, решая проблему совместной работы в нескольких местах и удовлетворяя потребности предприятий в удаленном аварийном восстановлении.
Рекомендуемое чтение: Elasticsearch экономит затраты на хранение на 60%
адрес проекта: Гитхаб (GitHub.com/juice data/ просто…) если полезноДобро пожаловать, чтобы следовать за нами!(0ᴗ0✿)