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

Сам термин "обогащение данных" это перевод англоязычного Data enrichment, который проводит аналогию между данными и... ураном. Точно так же, как промышленники насыщают урановую руду, увеличивая долю изотопа 235U, чтобы её можно было использовать (хочется надеяться, в мирных целях), в процессе обогащения данных мы насыщаем их информацией.

Обогащение данных это процесс дополнения сырых данных той информацией, которая в исходном виде в них отсутствует, но необходима для качественного анализа.

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

Заметим, что обогащение данных термин широкий, и получать данные из внешних источников можно весьма разнообразными способами. Например, представим бизнес-процесс регистрации нового клиента. Если в данных этого клиента отсутствует e-mail, то взаимодействие с внешним источником в этом случае может быть буквально следующим: взяли телефон, позвонили клиенту, узнали его e-mail. Получается, этот процесс может включать в себя такие совершенно не автоматизированные операции, как обычный телефонный разговор со всеми этими эс как доллар, "а" как русская. Это тоже можно считать обогащением данных, но данный пласт проблем в этой статье мы затрагивать не будем. Нас интересуют вполне конкретные случаи, когда данные хранятся в базе данных и именно БД служит внешним источником данных для обогащения.

Источниками сырых исходных данных могут быть:

• Система кассовых платежей, которая отслеживает транзакции и отправляет в хранилище данных: время, id торговой точки, количество и стоимость купленного товара и т.д.

• Логистическая система, которая отслеживает движение товара: id транспорта и его водителя, gps-координаты в заданные моменты времени, статус, маршрут и т.д.

• Телеметрия с датчиков интернета вещей.

• Система мониторинга инфраструктуры.

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

Таким образом, типовую задачу можно сформулировать следующим образом: на вход поступают данные вида <таймстамп, идентификатор источника, содержимое пакета>, а конечному потребителю требуется соединить (в смысле join) справочную информацию об источнике из хранилища данных с идентификатором источника из сырых данных.

Как обогащаем данные

Один из вариантов решения задачи сопоставления данных по расписанию запускать скрипты, которые подготовят подходящие для аналитиков представления. Например, это можно делать с помощью Apache Airflow. Но в любом случае потребуется ждать и сохранять данные из внешних источников.

Другой вариант использовать инструменты потоковой обработки данных. В этом случае нужно определиться, где же всё-таки хранить справочную информацию и что будет являться Single Source of Truth (SSOT), или единым источником истины для справочных данных. Если хранить справочные данные в хранилище, то к нему придется каждый раз обращаться, и это может быть накладным, так как к сетевым издержкам добавится ещё и обращение к диску. Вероятно, оптимальнее хранить справочную информацию в оперативной памяти или другом горячем хранилище, например, в Tarantool.

Мы, очевидно, отдаём предпочтению именно последнему варианту, и наша схема приобретает завершенный вид.

Она отличается от первой иллюстрации процесса обогащения данных тем, что появилась конкретика: процесс обогащения происходит на лету с помощью потокового обработчика, справочные данные хранятся в горячем хранилище (оперативной памяти).

Давайте посмотрим, какие плюсы и минусы мы получим, если возьмем за основу данную схему.

Преимущества потокового обогащения данных:

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

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

Недостатки:

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

• Требуется гораздо больше памяти как оперативной, так и постоянной. В целом, для любой системы аналитики желательно иметь побольше дискового пространства и оперативной памяти, но здесь это становится обязательным условием.

Какие технологии используем

Что касается технологий, то мы выбираем более-менее устоявшиеся на рынке решения с открытым исходным кодом и хорошей документацией, учитывая совместимость.

Выбранный стек технологий:

• Apache Kafka источник данных и брокер очередей;

• Apache Spark потоковый обработчик данных;

• Apache Ignite горячее хранение справочной информации;

• Greenplum и Apache Hadoop хранилище данных.

В выборе Greenplum мы немного поступились совместимостью. Связать его со Spark не совсем тривиальная задача, для этого не существует стандартного open source коннектора (подробнее рассказывали в этой статье). Поэтому мы разрабатываем такой коннектор сами.

В остальном набор достаточно стандартный. Hadoop держим на всякий случай, например, чтобы использовать тот же Hive поверх HDFS вместо Greenplum.

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

Итак, вот окончательные очертания нашей схемы обогащения данных.

Версии, которые используем:

• Apache Spark 2.4.6.

• Apache Ignite 2.8.1.

• Apache Kafka 2.4.1.

• Greenplum 6.9.0.

• Apache Hadoop 2.10.1.

Обращаю на это внимание, потому что от версий выбранных компонент зависит совместимость и возможность этих компонент взаимодействовать. Например, если нужно, чтобы Apache Spark писал данные в базу данных Greenplum, это может стать отдельной проблемой, и версии также будут важны. Наш коннектор на текущий момент работает именно со Spark v2, для Spark v3 его нужно отдельно дорабатывать.

Что в результате

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

Но есть и ограничения, связанные с тем, что source of truth, по сути, находится в оперативной памяти. Поэтому при редактировании справочной информации надо напрямую работать с Ignite через интерфейсы самого Ignite. Кроме этого, нужен аккуратный механизм синхронизации, чтобы кэш Ignite был персистентным. У Ignite есть собственный механизм для записи на диск, но все же Ignite больше ориентирован на работу в ОЗУ, поэтому для резервирования справочной информации в хранилище данных лучше использовать что-нибудь специально для этого предназначенное, например, Airflow.

Полезные ссылки, чтобы понять, как строить взаимодействие между Spark и Ignite и насколько это уже проработанный механизм:

• О том, как можно использовать содержимое базы Apache Ignite в качестве объекта dataframe, можно почитать здесь https://ignite.apache.org/docs/latest/extensions-and-integrations/ignite-for-spark/ignite-dataframe.

• Видео (на английском) про развитие Apache Ignite и его специфику, где-то с 12 минуты будет про использование Hadoop+Spark+Ignite https://databricks.com/session/fast-data-with-apache-ignite-and-apache-spark.

• Каким образом использовать Apache Spark + Apache Ignite (с хорошим и детальным техническим разбором), можно прочитать в блоге Сбербанка здесь же на Хабре http://personeltest.ru/aways/habr.com/ru/company/sberbank/blog/427297.

• Информацию о том, каким образом можно взаимодействовать с содержимым базы Apache Ignite через обычный интерфейс SQL, можно найти здесь https://ignite.apache.org/docs/latest/SQL/sql-api.

Пользуясь случаем: мы расширяем отдел систем обработки данных. Если вам интересно заниматься с подобного рода задачами, пишите мне в личку, в телеграм @its_ihoziainov или на job@itsumma.ru с пометкой data engineering.

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

Для будущих студентов курсов "Data Engineer" и "Экосистема Hadoop, Spark, Hive" подготовили еще один перевод полезной статьи.

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

Быстрая обработка больших данных имеет критическое значение для нашего бизнеса:

• мы часто обновляем наши модели, повышая их производительность для наших клиентов;

• мы быстро выводим новые продукты на базе машинного обучения на рынок за счет того, что можем быстро выполнять итерации;

• от скорости обработки данных зависят затраты на инфраструктуру.

В этой статье я расскажу о написании эффективного кода Spark и на примерах продемонстрирую распространенные подводные камни. Я покажу, что в большинстве случаев Spark SQL (Datasets) следует отдавать предпочтение перед Spark Core API (RDD), и если сделать правильный выбор, можно повысить производительность обработки больших данных в 210 раз, а это очень значимо.

Конфигурация для экспериментов

Spark 2.4.6, Macbook Pro 2017 с процессором Intel Core i7 с частотой 3,5ГГц

Измерения всегда производятся на разогретой виртуальной Java-машине (выполняется 100 прогонов кода, и берется среднее значение за последние 90 прогонов). Приведенный в этой статье код написан на Scala, но ее выводы должны быть справедливыми и для Python.

Заблуждения, связанные с обработкой больших данных

Существует распространенное мнение, что в процессах обработки больших данных есть два основных узких места, влияющих на производительность:

• перетасовка данных, поскольку для ее выполнения требуется отправлять данные по сети;

• дисковый ввод-вывод, поскольку доступ к данным на диске всегда намного медленнее, чем доступ к данным в ОЗУ.

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

В 2015 году висследовании Кей Остерхаут (Kay Ousterhout) и др. были проанализированы узкие места в заданиях Spark, и в результате выяснилось, что скорость их выполнения в большей степени определяется операциями, загружающими ЦП, а не вводом-выводом и передачей данных по сети. В частности, авторами этой научной работы был выполнен широкий спектр запросов к трем тестовым наборам данных, включаяTPC-DS, и было определено, что:

• если бы пропускная способность сети была безграничной, время выполнения заданий можно было бы сократить на 2% (медианное значение);

• если бы пропускная способность дискового ввода-вывода была безграничной, время выполнения стандартного аналитического процесса можно было бы сократить на 19% (медианное значение).

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

• Spark использует дисковый ввод-вывод не только при считывании входного набора данных и записи результата, но и в ходе выполнения заданий для кэширования и переноса на диск данных, которые не умещаются в ОЗУ.

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

Интересно, что специалисты Databricks примерно в 2016 году пришли к таким же заключениям, что заставило их переориентировать вектор развития Spark на оптимизацию использования процессора. Результатом стало внедрение поддержки SQL, а также API DataFrames и позднее Datasets.

Насколько быстро работает Spark?

Давайте рассмотрим простую задачу посчитаем наивным методом четные числа от 0 до 10. Для выполнения такого задания Spark, в принципе, не требуется, поэтому для начала напишем простую программу на Scala:

var res: Long = 0Lvar i: Long  = 0Lwhile (i < 1000L * 1000 * 1000) {  if (i % 2 == 0) res += 1  i += 1L}

Листинг1. Наивный подсчет

А теперь давайте также вычислим этот же результат с помощью Spark RDD и Spark Datasets. Чтобы эксперимент был честным, я запускаю Spark в локальном[1] режиме:

val res = spark.sparkContext  .range(0L, 1000L * 1000 * 1000)  .filter(_ % 2 == 0)  .count()

Листинг2. Подсчет с помощью RDD

val res = spark.range(1000L * 1000 * 1000)  .filter(col("id") % 2 === 0)  .select(count(col("id")))  .first().getAs[Long](0)

Листинг3. Подсчет с помощью Datasets

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

Парадокс Datasets

Парадокс: API-интерфейс Datasets построен на основе RDD, однако работает намного быстрее, почти так же быстро, как код, написанный вручную для конкретной задачи. Как такое вообще возможно? Дело в новой модели выполнения.

Прошлое модель Volcano

Код, написанный с использованием RDD, выполняется с помощью модели выполнения Volcano. На практике это означает, что каждый RDD следует стандартному интерфейсу:

• знает свой родительский RDD;

• предоставляет посредством методаcomputeдоступ к итератору Iterator[T], который перебирает элементы данного RDD (он является private и должен использоваться только разработчиками Spark).

abstract class RDD[T: ClassTag]def compute(): Iterator[T]

Листинг4. RDD.scala

С учетом этих свойств упрощенная версия реализации функции подсчета для RDD, которая игнорирует разбиение, выглядит вот так:

def pseudo_rdd_count(rdd: RDD[T]): Long = {  val iter = rdd.compute  var result = 0  while (iter.hasNext) result += 1  result}

Листинг5. Псевдокод для действия подсчета на основе RDD

Почему этот код работает значительно медленнее, чем написанный вручную код, который приведен в листинге 1? Есть несколько причин:

• Вызовы итераторов виртуальной функцией: вызовы Iterator.next() несут дополнительную нагрузку по сравнению с функциями, не являющимися виртуальными, которые могут выполняться компилятором илиJIT как встроенные (inline).

• Отсутствие оптимизации на уровне ЦП: виртуальная Java-машина и JIT не могут оптимизировать байт-код, образуемый листингом 5, так же хорошо, как байт-код, получаемый при использовании листинга 1. В частности, написанный вручную код позволяет виртуальной Java-машине и JIT хранить промежуточные результаты вычислений в регистре ЦП, а не помещать их в основную память.

Настоящее формирование кода всего этапа

Код, написанный с помощью Spark SQL, выполняется не так, как код, написанный с использованием RDD. Когда запускается действие, Spark генерирует код, который сворачивает несколько трансформаций данных в одну функцию. Этот процесс называется формированием кода всего этапа (Whole-Stage Code Generation). Spark пытается воспроизвести процесс написания специального кода для конкретной задачи, в котором не используются вызовы виртуальных функций. Такой код может выполняться JVM/JIT более эффективно. На самом деле Spark генерирует довольно много кода, см., например, код Spark для листинга 3.

Технически Spark только формирует высокоуровневый код, а генерация байт-кода выполняется компилятором Janino. Именно это и делает Spark SQL настолько быстрым по сравнению с RDD.

Эффективное использование Spark

Сегодня в Spark есть 3 API-интерфейса Scala/Java: RDD, Datasets и DataFrames (который теперь объединен с Datasets). RDD все еще широко применяется в Spark в частности, из-за того, что этот API используется большинством созданных ранее заданий, и перспектива продолжать в том же духе весьма заманчива. Однако, как показывают тесты, переход на API-интерфейс Datasets может дать громадный прирост производительности за счет оптимизированного использования ЦП.

Неправильный подход классический способ

Самая распространенная проблема, с которой я сталкивался при использовании Spark SQL, это явное переключение на API RDD. Причина состоит в том, что программисту зачастую проще сформулировать вычисление в терминах объектов Java, чем с помощью ограниченного языка Spark SQL:

val res = spark.range(1000L * 1000 * 1000)    .rdd    .filter(_ %2 == 0)    .count()

Листинг6. Переключение с Dataset на RDD

Этот код выполняется в течение 43 секунд вместо исходных 2,1 секунды, при этом делая абсолютно то же самое. Явное переключение на RDD останавливает формирование кода всего этапа и запускает преобразование элементов наборов данных из примитивных типов в объекты Java, что оказывается очень затратным. Если мы сравним схемы этапов выполнения кода из листингов 3 и 6 (см. ниже), то увидим, что во втором случае появляется дополнительный этап.

Неправильный подход изысканный способ

Производительность Spark SQL является на удивление хрупкой. Это незначительное изменение приводит к увеличению времени выполнения запроса в три раза (до 6 секунд):

val res = spark  .range(1000L * 1000 * 1000)  .filter(x => x % 2 == 0) // note that the condition changed  .select(count(col("id")))   .first()  .getAs[Long](0)

Листинг7. Замена выражения Spark SQL функцией Scala

Spark не способен генерировать эффективный код для условия в фильтре. Условие является анонимной функцией Scala, а не выражением Spark SQL, и Spark выполнит десериализацию каждой записи из оптимизированного внутреннего представления, чтобы вызвать эту функцию. Причем вот что примечательно это изменение никак не сказывается на визуальном представлении этапов (рис. 1a), поэтому его невозможно обнаружить, анализируя направленный ациклический граф (DAG) задания в пользовательском интерфейсе Spark.

Высокая производительность Spark SQL обеспечивается за счет ограничения круга доступных операций чем-то все равно приходится жертвовать! Чтобы получить максимальную производительность, нужно использовать преобразования, которые работают со столбцами: используйтеfilter(condition: Column)вместоfilter(T => Boolean) иselect()вместоmap(). При этом Spark не придется перестраивать объект, представленный одной строкой набора данных (Dataset). И, разумеется, избегайте переключения на RDD.

Заключение и итоговые замечания

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

Правильное применение компиляции запросов может сократить время обработки в 210 раз, а это означает ускорение экспериментов, снижение затрат на инфраструктуру и громадное удовольствие от элегантного выполнения своей работы!

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

Использованные материалы

1. Ousterhout, Kay, et al. Making sense of performance in data analytics frameworks (Анализ производительности платформ анализа данных).12-й симпозиум {USENIX} по проектированию и реализации сетевых систем ({NSDI} 15). 2015.

2. http://www.tpc.org/tpcds/

3. https://databricks.com/blog/2015/04/28/project-tungsten-bringing-spark-closer-to-bare-metal.html

4.https://janino-compiler.github.io/janino/

5.http://people.csail.mit.edu/matei/papers/2015/sigmodsparksql.pdf

6.https://databricks.com/blog/2016/05/23/apache-spark-as-a-compiler-joining-a-billion-rows-per-second-on-a-laptop.html

Узнать подробнее о курсах "Data Engineer" и "Экосистема Hadoop, Spark, Hive".

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

Установка gnuplot

Gnuplot высокоуровневый язык команд и сценариев, предназначенный для построения графиков математических функций и работы с данными, активно развивающийся с 1986 года. Исходный код gnuplot защищён авторским правом, но распространяется как свободное программное обеспечение и способен работать на Linux, OS/2, MS Windows, OSX, VMS и многих других платформах. Для установки gnuplot на компьютер с MS Windows наиболее удачным решением будет обратиться к официальному сайту gnuplot.info, перейти по ссылке Download и загрузить актуальную версию с ресурса sourceforge.net. Размер скачиваемого файла около 30 Мб, после установки пакет занимает примерно 100 Мб дискового пространства.

Установщик задаст несколько простых вопросов о конфигурации (на английском языке), одно из окошек будет называться Select Additional Tasks, в нем я рекомендую выбрать тип терминала wxt, а также поставить галочку в последнем пункте Add application directory to your PATH environment variable. После установки в меню запуска программ появятся два новых пункта, кажется они называются gnuplot и gnuplot console version. Если выбрать второй вариант, появится черное окно с командной строкой, как показано на рисунке:

Если ввести командуpwd, вы увидите директорию, в которой запускается gnuplot. Команда
plot sin(x)откроет графический терминал wxt и нарисует в нем график функции .

Если запускать просто gnuplot (не консоль), окно для ввода команд будет белое с черным текстом, при этом в нем будет отображатся верхнее меню с многочисленными командами. В gnuplot есть команда help для быстрого получения справки по любой из команд. Для облегчения работы с gnuplot пользователям MS Windows настоятельно рекомендую обзавестись нормальным текстовым редактором (я не очень в курсе текущей ситуации с Notepad).

Эксперимент

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

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

Теоретическая зависимость измеряемого напряжения от угла поворота поляризатора описывается законом Малюса:

где максимальное значение напряжения, угол межу плоскостью поляризации света и оптической осью поляризатора.

Моделирование

Применим gnuplot для моделирования возможных результатов эксперимента, в котором измеряется зависимость от угла поворота . Стоит отметить, что в реальных экспериментах моделирование изучаемого явления широко используется для создания и тестирования средств анализа результатов измерений. Отличие наблюдаемых величин от модельных данных заставляет исследователей проверять и совершенствовать модель, добавляя в нее уже известные науке эффекты. Ситуация, в которой результаты эксперимента невозможно описать известными явлениями называется открытием. Итак, создадим текстовый файл model.gpl со сценарием из gnuplot-команд и комментариев к ним:

reset # сбрасываем все ранее определенные переменные среды gnuplotset angles degrees    # используем градусы как единицу измерения угловset xrange [0:350]    # диапазон изменения угла поворота поляризатораset samples 36        # число точек для вычисления значений функцииset format x "%5.1f"  # формат вывода значения угла  set format y "%5.3f"  # формат вывода величины напряжения# Применим преобразование Бокса-Мюллера для моделирования 'ошибки' # измерения угла, которая описывается нормальным распределением # с нулевым средним и дисперсией D. Воспользуемся имеющимся в# gnuplot генератором псевдо-случайных чисел, функцией rand(x):err(D) = D * cos(360*rand(0))*sqrt(-2*log(rand(0))) # Создадим функцию для описания закон Малюса:U(x) = Uo * cos(x + err(D) - To)**2 + B Uo = 0.65  # параметр UoTo = 71.   # параметр oB  = 0.02  # напряжение на фотодетекторе при выключенном источнике света D  = 1.0   # ошибка считывания значения угла со шкалы на оправеset table "exp.dat" # имя текстового файла для вывода результатов plot U(x)           # записываем результаты в файлunset table         # закрываем файл

В окне gnuplot набираем командуload 'model.gpl'.Подразумевается, что созданный нами файл находится в рабочей директории, в противном случае директорию можно сменить, введя команду cd 'your_path'. В результате выполнения скрипта мы получим текстовый файл cрезультатами моделированияexp.dat, который выглядит примерно так:

# Curve 0 of 1, 36 points# Curve title: "U(x)"# x y type  0.0 0.089  i 10.0 0.176  i 20.0 0.283  i 30.0 0.395  i 40.0 0.505  i 50.0 0.595  i 60.0 0.643  i ...

Анализ данных

Начнем обработку данных с построения графика результатов моделирования (или измерений). Также используем метод наименьших квадратов для сравнения полученных результатов с теорией. Редуцированное значение взвешенного параметра хи-квадрат определяется так:

• называется числом степеней свободы алгоритма поиска минимального значения и определяется как число измерений (точек на графике) минус количество свободных параметров функции ,

• точки на оси x, в которых проведены измерения,

• результат измерения в точке ,

• значение теоретической функции в точке ,

• среднеквадратическое отклонение измеренного значения величины от ее среднего значения .

В gnuplot отношение из последней формулы обозначается как WSSR / NDF, что является аббревиатурой от фраз Weighted Sum of Squared Residuals и Number of Degrees of Freedom.

Рассматриваемый здесь пример лабораторной работы является частным случаем обширного класса задач, в которых есть набор данных измерений/моделирования и теоретическая функция, которая должна описывать изучаемое явление. Для проверки соответствия между теорией и экспериментом мы будем варьировать свободные параметры функции так, чтобы минимизировать величину . Для этого в gnuplot есть команда fit, изпользующая алгоритм Левенберга Марквардта. На русский язык фраза fit function to data переводится как подогнать функцию к данным.

Создадим текстовый файлlook.gpl со сценарием для gnuplot.

resetset angles degreesf(x) = Uo * cos(x-To)**2 + B            # определение теоретической функцииUo  = 0.6                               # параметр UoTo = 10                                 # параметр ToB  = 0.05                               # параметр Bset fit nolog         # отмена опции записи логов процесса подгонки в файл# Запускаем алгоритм поиска минимума хи-квадрат, используя 1 колонку файла# "exp.dat" в качестве X[i], а вторую - в качестве Y[i]. При поиске минимума# алгоритм варьирует значения свободных параметров Uo, B, Tofit f(x) "exp.dat" using 1:2  via Uo, To, B# Среднее квадратичное отклонение эксперимента и теории в милливольтахL = sprintf("Закон Малюса: {/Symbol s} = %.2f [мВ]", 1000*FIT_STDFIT) # Найденное значение угла поворота оси и оценка его точностиT = sprintf("Поворот оси поляроида {/Symbol q_0} = %.2f  %.2f", To, To_err)set title T # Название для получившегося графикаset grid    # Указание рисовать сетку на графикеset key box width -14 # прямоугольник для отображения подписей к графикамset xlabel 'угол поворота поляризатора {/Symbol q} [  ]'set ylabel 'напряжение на фотоприёмнике U [ В ]'set yrange [0:0.8] # диапазон графика по вертикальной осиset terminal png size 800, 600 # выбираем тип терминала - png файлset out 'look.png' # имя файла для записи графика# Рисуем функцию и точки из файла:plot f(x) with line title L ls 3 lw 2, \"exp.dat" u 1:2 title 'эксперимент' with points ls 7 ps 1.5 set out # закрываем файл

Символ \ используется в сценариях для переноса длинных строк и должень быть последним символом в своей строке. В окне gnuplot вводим команду load 'look.gpl', в результате выполнения которой у нас появится файл look.png с построенными графиками данных и теоретической функции:

Итак, мы видим, что на глазок данные хорошо совпадают с теорией. Нам даже удалось правильно измерить угол с точностью 0.2 градуса. Однако, мы имеем среднеквадратическое отклонение теории от моделирования 9 милливольт. Что бы это могло означать?

Если посмотреть на использование команды fit (строка 11 в файле look.gpl), можно заметить, что мы не передаём процедуре подгонки никаких данных об ошибках измерений, т. е. алгоритм ничего не знает о величинах из последней формулы. Что же он (алгоритм) делает в таком случае? А вот что: все считаются равными безразмерной единице и мы получаем невзвешенное значение редуцированного параметра хи-квадрат, квадратный корень из которого является размерной величиной, описывающей среднеквадратическое отклонение функции от экспериментальных точек те самые 8.88 милливольт, приведенные на графике.

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

В нашем моделировании (см. файлmodel.gplв начале этого текста) мы учли погрешность измерения угла, добавив его к закону Малюса как случайную величину с нормальным распределением и среднеквадратическим разбросом в 1 градус. Чтобы учесть погрешности измерений, создадим усовершенствованный скрипт для обработки данных. Заодно, нарисуем графики в полярных координатах (удобных для визуализации поляризационных явлений), а также сохраним картинку в формате pdf.

resetset angles degreesf(x) = Uo * cos(x-To)**2 + B      # определение теоретической функцииv(x) = Uo * sin(2*(To-x))*pi/180  # производная f(x)Uo  = 0.6                         # параметр UoTo = 10                           # параметр ToB  = 0.05                         # параметр BdT = 1.0                          # ошибка измерения углаset fit nolog#  Запускаем алгоритм поиска минимума (не-взвешенный хи-квадрат)fit f(x) "exp.dat" using 1:2             via Uo, To, B#  Запускаем алгоритм поиска минимума (взвешенный хи-квадрат)fit f(x) "exp.dat" using 1:2:(dT*v($1)) via Uo, To, BL = sprintf("Теория: {/Symbol c^2}/NDF = %.1f/%2d\n \Вероятность: %.2f \%", FIT_WSSR, FIT_NDF, 100*FIT_P) T = sprintf("Поворот оси поляроида {/Symbol q_0} = %.2f  %.2f", To, To_err)set title T # Название для получившегося графикаset key box left opaque  width -12 spacing 2unset border # не рисовать рамкуunset xtics  # не показывать ось xunset ytics  # не показывать ось yset polar    # рисуем графики в полярных координатахset grid polar linetype 2 lc rgb 'black' lw 0.25 dashtype 2set rtics 0.1 format '%.1f'unset raxisUmax = 0.76  # максимальное значение напряженияset rrange [0:Umax]set rlabel 'U_{ФД} [В]'set trange[0:360]set for [i=0:330:30] label at first Umax*cos(i), \first Rmax*sin(i) center sprintf('%d', i)set terminal pdf background rgb '0xFFFFF0' size 5, 5 # тип терминала - pdf файлset out 'closelook.pdf' # имя файла для записи графикаplot f(t) with line title L ls 3 lw 2, \"exp.dat" u 1:2:(dT*v($1)) title 'эксперимент' with err ls 7 ps 0.5 set out # закрываем файл

Следующее изображение - скриншот получившегося файла closelook.pdf.

В результате применения алгоритма подгонки мы получили редуцированное значение взвешенного параметра хи-квадрат . Используя распределение хи-квадрат с соответствующим числом степеней свободы мы получаем значение вероятности (p-value) получения наблюдаемого результата в предположении, что исходная теоретическая гипотеза верна. В нашем случае эта вероятность довольно высока - 42%.

Заключение

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

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

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

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

Беспилотный автомобиль: базовые требования

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

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

Система глобального позиционирования (GPS) позволяет автомобилю узнать, где он находится. Сегодня приемники GPS встроены во многие SoC, благодаря вычислительным ядрам они обеспечивают быстрый и точный поиск положения автомобиля. Для вычислений используются данные, как минимум, четырех спутников. Некоторые чипы GPS, такие как Linx Technologies F4 Series GPS Receiver Module, могут одновременно принимать сигналы до 48 спутников. Данные о перемещении автомобиля передаются на периферийные серверы, где они используются для дальнейшего анализа.

Беспилотный автомобиль в любой момент времени должен знать свое точное местоположение, а также оценивать ситуацию вокруг. Несколько камер обеспечивают обзор окружения на все 360 градусов. Каждая камера дает двумерные кадры, то есть массив пикселей, где к каждому пикселю привязана информация цвета и яркости. И здесь как раз стоит упомянуть весьма интересные инновации.

MIT ShadowCam способна заглянуть за угол

Развитие технологий искусственного интеллекта и глубокого обучения, позволяет выполнить исчерпывающий анализ изображений, в том числе отслеживать объекты по информации нескольких камер и анализировать положение пешеходов и велосипедистов. Исследователи MIT анонсировали систему ShadowCam, которая использует технологии компьютерного видения: анализируются малейшие изменения яркости, позволяющие определить тени на поверхности земли, едва различимые человеческому глазу. Технология позволяет беспилотным автомобилям буквально заглянуть за угол, определяя приближающиеся объекты, которые потенциально могут вызывать столкновение.

Загрязнение камер, слабое освещение и плохая видимость снижают качество данных с камер, здесь на помощь приходит лидар (LIDAR, Light Detection and Ranging), собирающий информацию о ближайшем окружении автомобиля. Лидар применяет лазерные импульсы для измерения расстояний до объектов, в итоге создается трехмерная карта, позволяющая анализировать окружение автомобиля. Все эти вычисления должны выполняться бортовым компьютером, чтобы мгновенно принимать необходимые решения. Для захвата и хранения данных трехмерной карты объектов и потоков с нескольких камер требуется достаточная емкость на периферии.

Проблема объема данных

Даже обычные автомобили, с водителем за рулем, генерируют все больше данных. Новые модели оснащаются бортовым компьютером с 25-50 вычислительными ядрами, обеспечивающими круиз-контроль, устранение слепого пятна, предупреждение о наезде на препятствие и автоматическое торможение. Узлы автомобиля обмениваются данными между собой через внутреннюю сеть.

В своей речи бывший CEO Intel Брайан Кржанич назвал данные новой нефтью. Он упомянул, что типичный беспилотный автомобиль может генерировать в день около 4 Тбайт данных. Но прогноз уже превышен роботакси AutoX, которые генерируют 1 Тбайт в час. О них мы расскажем чуть ниже.

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

Задержки смерти подобны

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

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

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

Взаимодействие друг с другом и с периферийной инфраструктурой

GPS и системы компьютерного видения обеспечивают беспилотные автомобили информацией о локации и ближайшем окружении. Но при повышении дальности просчитываемого окружения один автомобиль может собрать лишь ограниченное количество информации, поэтому необходим обмен данными. В результате каждый автомобиль сможет лучше проанализировать условия вождения, опираясь на более обширный массив данных, собранный парком беспилотных автомобилей. Системы коммуникации Vehicle-to-vehicle (V2V) опираются на mesh-сети, создаваемые автомобилями в одной географической области. V2V используются для обмена информацией и подачи сигналов другим автомобилям, например, предупреждения об опасной дистанции.

Сети V2V можно расширить для обмена информацией с инфраструктурой дорожного движения, например, светофорами. Здесь уже уместно говорить о коммуникации V2I (vehicle-to-infrastructure). Стандарты V2I продолжают развиваться. В США Федеральная дорожная администрация (FHWA) выпустила руководство по V2I, которое должно помочь внедрению технологии. Как сказал администратор FHWA Григорий Надю, преимущества V2I простираются намного дальше безопасности: Кроме улучшения безопасности, технология автомобиль-инфраструктура дает преимущества по мобильности и взаимодействию с окружением.

Водители, которые ездят одним и тем же маршрутом каждый день, запоминают все ямки на дороге. Беспилотные автомобили тоже постоянно учатся на своем опыте. Как указывает Data Center Knowledge, в будущем беспилотные автомобили будут сгружать имеющуюся полезную информацию в периферийные дата-центры, например, интегрированные в станции зарядки.Станции зарядки будут опираться на алгоритмы искусственного интеллекта, которые помогут анализировать полученные от автомобиля данные и предложат возможные решения. Через облако эти данные будут переданы и другим беспилотным автомобилям в общей сети.

Если подобная модель обмена данными между всеми беспилотными автомобилями действительно воплотится через несколько лет, то можно ожидать экзабайты (миллионы терабайт) данных в день. На дорогах к этому времени должны появиться, по разным оценкам, от сотен тысяч до десятков миллионов беспилотных автомобилей. Действительно впечатляет!

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

Виртуальные пешеходы и симуляция облегчают задачу

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

В материале Reuters указано, что Volvo - один из многих производителей, тестирующий автономное вождение с помощью манекенов и других искусственно созданных объектов, симулирующих условия городской среды без каких-либо рисков. Производители грузовиков, такие как Scania, экспериментируют с тягачами на закрытых полигонах.

Автономное вождение все чаще переносится в виртуальный мир, как упоминается в MIT Technology Review. В одной симуляции Waymo, например, участвуют 25 тысяч автомобилей, которые в общей сложности проезжают больше 16 млн. километров в день. Подобный массовый сценарий слишком опасен, чтобы переносить его в современный мир.

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

Объемы данных, которые при этом предстоит обработать, просто огромны. Но без их анализа нельзя запускать технологию автономного вождения в массы.

Для передачи данных на сравнительно большие расстояния уже требуются современные технологии сотовой связи, а именно 5G, которые способны обеспечить пропускную способность до 300 Мбит/с с задержками 1 мс. Huawei ранее как раз анонсировала компоненты 5G, ориентированные на беспилотные автомобили. Настало время поговорить о 5G.

5G как ключ к успеху беспилотных автомобилей

Наш беспилотный автомобиль может получать информацию о пешеходах и велосипедистах не только опираясь на свои сенсоры, но и благодаря обмену данными с другими машинами, светофорами и прочими объектами городской инфраструктуры. Звучит нереально, но именно такую демонстрацию могли увидеть посетители муниципалитета Оспиталет (провинция Барселона) в рамках проекта автомобиля, подключенного по 5G.

Автомобили Ateca и Arona, изготовленные Seat, использовали сеть оператора Telefonica 5G и технологию Ficosa C-V2X (Cellular Vehicle-to-Everything) для обмена информацией с другими машинами, велосипедистами и даже светофорами. Последние оснащены тепловизорами, которые определяют пешеходов, приближающихся к переходу, в результате на приборной панели автомобиля появляется соответствующее предупреждение. Велосипедисты, подключенные к сети, информируют о своем местоположении, что предотвращает опасные ситуации. В случае плохой видимости у припаркованных автомобилей автоматически включится аварийка, они будут оповещать все приближающиеся автомобили о своем положении.

Как ускорить внедрение автономного вождения?

Беспилотные автомобили, тестируемые на улицах Оспиталета, это интересно, но чтобы автономное вождение стало реальностью, требуется намного больше. Здесь как нельзя кстати подходят возможности новых мобильных сетей 5G, а именно огромные скорости, очень низкие задержки и способность поддерживать большое число подключений одновременно.

Мультигигабитные скорости 5G, распределенные периферийные сети и сервисы с низкими задержками позволят автономному вождению стать реальностью в ближайшие годы, сказал Крис Пенроуз, президент подразделения IoT в AT&T. 5G даст необходимые возможности по распределению обрабатываемых данных, чтобы соответствовать и превышать потребности беспилотных автомобилей.

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

Интеграция 5G идет полным ходом

Неудивительно, что крупные производители автомобилей, такие как Audi, BMW, Daimler, Ford, Hyundai и Toyota, интегрируют технологии 5G в свои продукты.

Возьмем для примера Ford. Компания к 2022 году планирует оснащать все выпускаемые в США автомобили технологией связи CV2X на основе 5G. Миллиарды долларов уже потрачены сотовыми операторами на создание сетей 5G, поэтому нам кажется, что настал подходящий момент, чтобы наши транспортные средства получили ряд умений, которые будут полезны в повседневной эксплуатации, сказал Дон Батлер, исполнительный директор Ford Connected Vehicle Platform and Product.

Компания Daimler, производитель люкс-авто Mercedes-Benz, вместе с крупнейшим своим акционером Zhejiang Geely Holding Group планирует собирать полностью электрические автомобили Smart компактного класса в Китае на экспорт. Они тоже будут оснащаться поддержкой 5G. Первые автомобили планируется выпустить в 2022 году. А Hyundai Mobis, производитель запчастей в составе Hyundai Motor Group, объявил о партнерстве с телекоммуникационной компанией KT по совместной разработке технологий подключенных к 5G автомобилей.

Телекоммуникационные компании не стоят в стороне. Audi является одним из основателей ассоциации 5G Automotive Association (5GAA), созданной для взаимодействия представителей телекоммуникационной индустрии и автопроизводителей. Audi планирует выпустить подключенные к 5G автомобили в ближайшем будущем, чему способствует сотрудничество с такими телекоммуникационными компаниями, как Huawei, которая ранее объявила о том, что стала первым производителем компонентов 5G для беспилотных автомобилей. Huawei надеется на большие продажи фирменного модуля 5G.

Но это еще не все. Несколько телекоммуникационных компаний создали бутафорские города для тестов беспилотных автомобилей. Samsung, например, совместно с Korea Transportation Safety Authority строит K-city В Корее с декорациями для проверки беспилотных автомобилей и подключения 5G в условиях, близких к реальным дорогам, перекресткам и туннелям.

Необходима инфраструктура 5G

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

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

Ценность собираемых данных

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

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

Как считает Брукс Райнвотер, директор Center for City Solutions в National League of Cities, данные, генерируемые беспилотными автомобилями, предоставят городу более скрупулезный обзор всего, от износа инфраструктуры до подобной информации о дорожном движении и самых нагруженных участках.

Как обрабатывать данные на периферии в тысячи экзабайт?

Для развития полностью автономного вождения необходимо решить проблему обработки и хранения огромных массивов данных. Каждый день беспилотный автомобиль может генерировать от 5 до 20 Тбайт данных. Всего один автомобиль! Только в США сегодня насчитывается больше 270 млн. автомобилей, что в будущем может привести к гипотетическому объему 5.449.600.000 Тбайт (или 5.449 экзабайт) и это только в один день и только в США! Для хранения таких данных необходима высокопроизводительная, гибкая, защищенная и надежная периферийная инфраструктура. Затем возникает проблема эффективной обработки данных, что тоже весьма непросто.

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

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

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

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

Seagate объединяет усилия с AutoX

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

Как мы уже неоднократно отмечали, беспилотные автомобили создают значительные объемы данных, получаемых со своих сенсоров. Seagate предоставила AutoX полное решение по созданию частного облака на основе систем Seagate Exos E 5U84. В результате повысилась скорость и эффективность обработки данных.

В июле 2020 года AutoX получила разрешение от калифорнийского Департамента транспортных средств, позволившее начать тесты беспилотных автомобилей на обычных дорогах в выделенном районе Сан-Хосе (Калифорния, США). Кроме того, компания управляет парком роботакси в Шэньчжэне и Шанхае. В апреле 2020 компания открыла операционный центр роботакси в Шанхае площадью 7400 м, ставший самым большим хабом беспилотных автомобилей в Азии.

Петабайты в день: данные новая нефть

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

Передача и хранение всех данных в публичных облаках приводит к задержкам, что замедляет обработку и анализ данных, увеличивает расходы. Как можно видеть в отчете Seagate Rethink Data, компании все чаще решают хранить данные в частных облаках.

Для обработки огромных объемов информации AutoX требуется надежная архитектура данных, сказал доктор Джан Вей Пан, вице-президент подразделения Technology and Partnerships в AutoX. Мы должны учитывать не только такие факторы, как цену, производительность и емкость, но и обрабатывать и хранить ценные данные с максимальной скоростью.

Периферийное частное облако: быстрая обработка, низкая стоимость владения

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

Решение Seagate соответствует потребностям AutoX по быстрой обработке данных и вместе с тем уменьшает совокупную стоимость владения (TCO). Но данные, которые обрабатываются на периферии, рано или поздно мигрируют в публичное облако для архивации и резервирования.

Для построения дата-центра с частным облаком Seagate использовала решение на основе Exos E 5U84, серверов и распределенной системы хранения данных Ceph. Seagate Exos E 5U84 может хранить до 1,1 петабайт данных, при этом обеспечиваются мощные возможности интеграции, повышающие эффективность использования частного облака. Благодаря высокой плотности хранения данных и производительности, система позволяет уменьшить совокупную стоимость владения. Масштабируемая архитектура обеспечивает рост вместе с бизнесом до 336 накопителей. Что поможет AutoX справиться с растущими объемами собираемых данных в будущем. Причем данное решение можно быстро реплицировать, что соответствует планам AutoX по расширению парков роботакси в Шанхае, Шэньчжэне, Ухани и многих других городах.

AutoX - отличный пример лидера индустрии IT 4.0, который вдохновил нас поставить более мощные системы хранения данных, способные быстрее справиться с анализом информации и выдачей вариантов действий, что позволяет как можно быстрее принимать решения и выходить из критических ситуаций, сказала Санди Сан, вице-президент Seagate и старший менеджер по Китаю. Мы рады партнерству с AutoX, поскольку компания продолжает внедрять инновации, будущее беспилотных автомобилей становится все ближе к реальности.

Renovo и Seagate объявили о сотрудничестве

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

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

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

Renovo уже давно разрабатывает платформу Aware, сотрудничество позволит Renovo использовать системы хранения данных Seagate во всех сферах, касающихся автономного вождения.

Seagate предлагает широкий набор решений для хранения данных, генерируемых беспилотными автомобилями, сказал Крис Хейзер, главный исполнительный директор Renovo. Мы рады работать с лидером индустрии Seagate, чтобы интегрировать лучшие технологии хранения данных в критические важные сферы автономного возждения.

Платформа Renovo используется во многих беспилотных автомобилях, в том числе Voyage.auto. Seagate присоединилась к экосистеме Renovo вместе с растущим числом других технологических партнеров, в том числе Samsung, Verizon, HERE, Velodyne LiDAR, Parsons, INRIX, Argus Cyber Security, Seoul Robotics, Affectiva, Phantom Auto, Metamoto, Understand.ai, NIRA Dynamics, Bestmile и т.д. Посмотрим, какие плоды принесет сотрудничество двух лидеров в будущем.

Заключение

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

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

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