Как Big Data спасает жизни в реальном времени аналитика данных Интернета вещей помогает предотвратить аварии

Как Big Data и аналитика данных Интернета вещей спасают жизни и предотвращают аварии в реальном времени

Интернет Вещей в автомобилях, или IoV, – это продукт соединения автомобильной промышленности и IoT. Ожидается, что IoV данные будут становиться все больше и больше, особенно с ростом электромобилей на автомобильном рынке. Вопрос в том: ваша платформа готова к этому? В этой статье показано, как выглядит OLAP решение для IoV.

Что особенного в данных IoV?

• От перцептрона до Адалайна
• Эта исследовательская статья по искусственному интеллекту предлагает новую стратегию предварительного обучения, называемую Privacy-Preserving MAE-Align, для эффективного объединения синтетических данных и реальных данных, обработанных без участия человека
• Практическое руководство GenAI для руководителей продукта и инженерии

Идея IoV интуитивна: создать сеть, чтобы автомобили могли обмениваться информацией друг с другом или с городской инфраструктурой. Однако часто не объясняется подробно сеть внутри каждого автомобиля. На каждой машине есть что-то, называемое контроллером области сети (CAN), который работает как коммуникационный центр электронных систем управления. Для автомобиля, движущегося по дороге, CAN является гарантией его безопасности и функциональности, поскольку он отвечает за:

• Мониторинг системы автомобиля: CAN является пульсом системы автомобиля. Например, датчики отправляют CAN температуру, давление или положение, которые они обнаружили; контроллеры отправляют команды (например, регулировку клапана или приводного мотора) исполнителю через CAN.
• Временная обратная связь: Через CAN датчики отправляют скорость, угол поворота и статус тормоза контроллерам, которые вносят своевременные корректировки в автомобиль, чтобы обеспечить безопасность.
• Обмен и координация данных: CAN позволяет обмениваться данными (такими как статус и команды) между различными устройствами, что позволяет всей системе работать более производительно и эффективно.
• Управление сетью и устранение неполадок: CAN следит за устройствами и компонентами в системе. Он распознает, конфигурирует и контролирует устройства для обслуживания и устранения неполадок.

Учитывая множество задач CAN, можно представить, какой объем данных ежедневно проходит через CAN. В данной статье речь идет о производителе автомобилей, который объединяет 4 миллиона автомобилей и должен обрабатывать 100 миллиардов фрагментов данных CAN каждый день.

Обработка данных IoV

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

• Запись данных в масштабе: Датчики есть повсюду в автомобиле: двери, сиденья, стоп-сигналы… Плюс, многие датчики собирают более одного сигнала. 4 миллиона автомобилей приводят к пропускной способности данных в миллионы TPS, что означает десятки терабайт ежедневно. С ростом продаж автомобилей это число продолжает расти.
• Анализ в реальном времени: Это, возможно, лучший пример принципа “время – жизнь”. Производители автомобилей собирают данные в реальном времени с их автомобилей, чтобы определить потенциальные неисправности и исправить их до возникновения каких-либо повреждений.
• Вычисление и хранение низкой стоимости: Невозможно говорить о больших объемах данных не упоминая их стоимость. Низкая стоимость делает обработку больших данных устойчивой.

От Apache Hive до Apache Doris: переход к анализу в реальном времени

Как и Рим, принцип платформы обработки данных в реальном времени не создается за один день. Производитель автомобилей раньше полагался на сочетание пакетного аналитического движка (Apache Hive) и некоторых потоковых фреймворков и движков (Apache Flink, Apache Kafka), чтобы получить почти реальное время анализа данных. Они не осознали, что им так сильно нужен был анализ в реальном времени до тех пор, пока реальное время не стало проблемой.

Платформа анализа данных почти в режиме реального времени

Раньше они использовали следующий подход: Данные от CAN и автомобильных датчиков передаются через сеть 4G на облачный шлюз, который записывает данные в Kafka. Затем Flink обрабатывает эти данные и передает их в Hive. Проходя через несколько слоев хранилищ данных в Hive, агрегированные данные экспортируются в MySQL. В конце концов, Hive и MySQL предоставляют данные на уровень приложения для анализа данных, создания инфографики и т. д.

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

• Запись данных: При таком огромном объеме данных время ввода данных из Flink в Hive было заметно долгим. Кроме того, Hive поддерживает обновление данных только на уровне разделов, что недостаточно для некоторых случаев.
• Анализ данных: Аналитическое решение на основе Hive обладает высокой задержкой запросов, что является многопричинной проблемой. Во-первых, работа Hive оказалась медленнее ожидаемого при обработке больших таблиц с 1 миллиардом строк. Во-вторых, в Hive данные извлекаются из одного слоя в другой при выполнении Spark SQL, что может занимать некоторое время. В-третьих, так как Hive должен работать с MySQL для удовлетворения всех потребностей со стороны приложения, передача данных между Hive и MySQL также увеличивает задержку запросов.

 

Платформа анализа данных в реальном времени

 

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

  По сравнению с предыдущей платформой на основе Hive, новая платформа работает более эффективно в трех аспектах:

• Запись данных: Ввод данных в Apache Doris быстрый и простой, без сложной конфигурации и введения дополнительных компонентов. Он поддерживает различные методы ввода данных. Например, в данном случае данные записываются из Kafka в Doris с помощью Stream Load, а из Hive в Doris с помощью Broker Load.
• Анализ данных: Для демонстрации скорости запросов в примере, Apache Doris может вернуть результат из 10 миллионов строк в течение секунд при запросе с объединением таблиц. Кроме того, он может работать как единый шлюз запросов с быстрым доступом к внешним данным (Hive, MySQL, Iceberg и т. д.), поэтому аналитики не должны переключаться между несколькими компонентами.
• Расчетные и хранилищные затраты: Apache Doris использует алгоритм Z-Standard, который может обеспечить в 3-5 раз более высокое сжатие данных. Именно так он помогает снизить затраты на вычисления и хранилище данных. Кроме того, сжатие может быть выполнено только в Doris, поэтому не будет использоваться ресурсы Flink.

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

 

1. Упорядочение данных CAN

 

В Kafka данные CAN были упорядочены по измерению идентификатора CAN. Однако в целях анализа данных аналитикам приходилось сравнивать сигналы с разных автомобилей, что означало объединение данных разных идентификаторов CAN в плоскую таблицу и их выравнивание по временной метке. Из этой плоской таблицы они могли получить различные таблицы для различных аналитических целей. Такая трансформация была реализована с использованием Spark SQL, что было затратно по времени в старой архитектуре на основе Hive, и SQL-запросы требовали постоянного обслуживания. Кроме того, данные обновлялись пакетно по ежедневной основе, что означало, что они могли получить данные только за предыдущий день.

В Apache Doris им просто нужно построить таблицы с помощью модели Aggregate Key, указать VIN (номер идентификации транспортного средства) и метку времени как Aggregate Key, а другие поля данных определить с помощью REPLACE_IF_NOT_NULL. С помощью Doris им не нужно беспокоиться о SQL-запросах и плоской таблице, но они могут извлекать информацию в реальном времени из данных в реальном времени.

 

 

3. Запрос данных DTC

 

Из всех данных CAN высокое внимание и отдельное хранение заслуживает DTC (Diagnostic Trouble Code), потому что он сообщает вам, что не так с автомобилем. Каждый день производитель получает около 1 миллиарда кодов DTC. Чтобы получить жизненно важную информацию из DTC, инженерам по данным необходимо связать данные DTC с таблицей конфигурации кодов DTC в MySQL.

Раньше они писали данные DTC в Kafka каждый день, обрабатывали их в Flink и сохраняли результаты в Hive. Таким образом, данные DTC и таблица конфигурации DTC хранились в двух разных компонентах. Это вызывало дилемму: 1-миллиарднуя таблица DTC была сложна для записи в MySQL, а запросы из Hive были медленными. Поскольку таблица конфигурации DTC также постоянно обновлялась, инженеры могли импортировать ее версию в Hive регулярно. Это значило, что они не всегда могли связать данные DTC с последними конфигурациями DTC.

Как уже упоминалось, Apache Doris может работать как единый шлюз запросов. Это подтверждается его функцией Multi-Catalog. Они импортируют свои данные DTC из Hive в Doris, а затем создают каталог MySQL в Doris для сопоставления с таблицей конфигурации DTC в MySQL. Когда все это сделано, они могут просто объединить две таблицы внутри Doris и получить ответы на запросы в реальном времени.

 

 

Заключение

 

Это фактическое решение для аналитики IoV в режиме реального времени. Оно разработано для работы с данными на действительно большом масштабе и сейчас поддерживает производителя автомобилей, который ежедневно получает 10 миллиардов строк новых данных для улучшения безопасности и опыта вождения.

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

[Zaki Lu](https://www.linkedin.com/in/zaki-lu-99a06b148/) является бывшим менеджером продукта в Baidu и теперь разработчиком в Apache Doris open source community.