Uncategorized

Проектирование конвейеров данных Интернета вещей для обеспечения глубокой наблюдаемости

Стенограмма

Шриджит: Я познакомлю вас с некоторыми интересными проблемами с данными и потоками, которые вы видите только в пространстве Интернета вещей. Я начну с небольшой проблемы, которая может вас коснуться. Tesla разработала сеть нагнетателей, чтобы сделать поездку незабываемой и приятной. Подъехать к нагнетателю только для того, чтобы заметить, что он не работает, может быть довольно неприятным. Мы предоставляем информацию о состоянии нагнетателя в режиме реального времени. Мы получаем телеметрию от наших нагнетателей, которые сообщают нам, когда пост занят, и различные другие статистические данные. Используя эти данные, мы можем оценить работоспособность нашего нагнетателя. На первый взгляд, это решаемая проблема. Есть много крайних случаев, которые могут оказаться новыми. Некоторые проблемы, такие как сломанный разъем или забитое место на парковке, препятствуют зарядке автомобиля через эту стойку нагнетателя. В некоторых случаях нагнетатель может быть совершенно исправным, но из-за экстремальной погоды или по какой-либо другой причине он может потерять соединение с облаком и перестать отправлять телеметрию. Алгоритм обнаружения сбоев, алгоритм, который определяет, куда направить пользователя, должен использовать множество эвристик. Он должен быть не только готов к работе с нагнетателями, которые отправляют данные безупречным образом, но также должен учитывать тот факт, что данные могут отсутствовать много раз. Хотя любой алгоритм, зависящий от данных, должен быть подготовлен к отсутствию данных, но в случае Интернета вещей это не редкое событие, а на самом деле довольно распространенное явление. Именно такие проблемы делают пространство данных IoT уникальным для работы.

Задний план

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

Трубопровод данных Интернета вещей от 10 000 футов

Начнем с обзора конвейера данных Интернета вещей на высоте 10000 футов. Большинство устройств, по крайней мере, в случае Tesla, работают под управлением операционной системы Linux и обеспечивают локальное хранилище данных, вычисления и управление, сохраняя при этом двунаправленную связь с облаком. Связь проходит через пограничный шлюз, который обеспечивает связь, а также безопасность. Пограничный шлюз интегрируется с облаком, за которым стоит кластер Kafka для приема больших объемов телеметрии. Pub / Sub на основе Kafka обеспечивает надежность сообщений, отделяет производителей данных от потребителей данных и позволяет совместно использовать эту телеметрию во многих последующих сервисах.

Не Clickstream

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

Неопределенный, ошибочный и шумный

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

Безграничная неоднородность

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

Данные Интернета вещей – шаблоны проектирования

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

Изолированные трубопроводы

Самый первый шаблон проектирования, который мы используем, – это изоляция. Мы можем найти конвейеры данных по нескольким измерениям. Очевидные измерения – это бизнес-единицы. В случае Tesla у нас есть сквозной поток данных для каждого бизнес-подразделения. Базовая инфраструктура, в которой работают эти потоки данных, может быть общей. Например, мы можем совместно использовать кластер Kafka. Мы могли бы поделиться настройкой Kubernetes. Мы можем даже совместно использовать некоторые базы данных на уровне инфраструктуры. На уровне приложений они полностью изолированы. Следующее измерение, очевидное измерение, которое нужно разделить после бизнес-единицы, – это продукты. Если у нас есть несколько моделей продуктов, например, если у вас несколько моделей транспортных средств, все они будут иметь свои собственные сквозные потоки данных. Мы не будем смешивать данные из модели A с моделью B. Следующее измерение, по которому мы все изолируем, – это география. Это были некоторые из очевидных измерений. Затем есть некоторые интересные параметры, такие как режимы передачи. Устройства периодически собирают данные, и это очевидный режим передачи, когда они периодически отправляют некоторую полезную нагрузку в облако. Бывают случаи, когда вам нужен внеполосный сбор данных. Например, технический специалист, желающий узнать больше о вашем устройстве, может запросить специальное извлечение, которое может быть более подробным. Это еще одно место, где мы бы не хотели, чтобы периодический сбор мешал внеполосному сбору. Хотя эта стратегия изоляции конвейеров и потоков данных по нескольким измерениям позволяет нам ограничить шум и позволяет уменьшить проблемы, связанные с шумными соседями, а затем улучшить качество данных, недостатком является то, что у нас слишком много наборов данных и слишком много конвейеров данных. справляться.

Отложенная сложность

Следующий часто используемый шаблон – это отложенная сложность. Как уже отмечалось, из-за ограниченных ресурсов устройства не могут обрабатывать такие операции, как очистка, установка некоторого стандартного формата. Я все время говорю о стандартном формате, потому что во многих случаях данные являются собственностью. Дедупликация – это еще одна вещь, которую устройства никогда не смогут выполнить. Они всегда перекладывают все эти сложные операции на облако. Устройство всегда работает в режиме, в котором оно может передавать как можно больше данных, как можно быстрее и с минимально возможной полезной нагрузкой, с которой оно может отправить эти данные. На стороне облачной платформы, чтобы ограничить неоднородность, прерывистость и шумность данных, мы пытаемся взорвать получаемые полезные нагрузки, которые обычно являются пакетными. Получаем телеметрию партиями. Мы стараемся развиваться независимо от того, из какого подразделения или продукта поступают эти данные. Мы стараемся использовать некоторые общие стратегии, чтобы мы могли включить санитарную обработку, общие стандартные форматы и некоторые другие стандартные шаги очистки на первом этапе самого сбора данных. Этот слайд демонстрирует то, как вы увеличиваете масштаб волшебного черного ящика Kubernetes, который вы видите там, который запускает некоторые конвейеры данных в реальном времени, которые мы разработали на основе фреймворка под названием Akka. Мы называем этот продукт «каналами Kafka». Там мы применяем эти сложные операции в первую очередь, когда получаем эти полезные данные. При дальнейшем увеличении масштаба в любом заданном подпотоке дезинфекции или очистки данных вы найдете больше подпотоков. Этот шаблон приводит к тому, что обработка данных разбивается на несколько промежуточных наборов данных и суб-конвейеров на стороне облачной платформы. У нас уже было слишком много наборов данных и слишком много конвейеров, которыми нужно было управлять из-за изолированности, которую мы делали. Теперь из-за этой поломки поток данных в подпотоки еще больше увеличивает эти наборы данных и конвейеры данных.

Свежий набор болевых точек

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

Для открытия данных нужен герой

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

Мы без проблем собираем данные от начала до конца. Это могут быть датчики или подмножество датчиков, которые перестали отправлять данные. Это тоже не редкий сценарий. В контексте обнаружения данных пользователь не может просто спросить, где данные для устройства x? Или где данные по определенной категории устройств? Более острый вопрос, более частый вопрос: где данные для устройства x типа Y? Затем вы бросаете измерение региона, например, где находятся данные для устройства x типа y по причине z? Затем вы добавляете больше измерений и видите, как усложняется обнаружение данных.

Управление данными, формальность

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

Доступны ли и полны ли данные?

Затем с данными IoT дается неопределенность, ошибочность и зашумленность. Мы никогда не ожидаем 100% покрытия в любой момент времени. Датчик устройства для того же устройства, некоторые датчики могут отправлять данные, а другие могут не работать. Покрытие говорит вам, что у вас могут быть некоторые данные, но 100% это или нет, это то, что вы пытаетесь получить из вопроса о покрытии. У нас были специально разработанные метрики, которые дадут вам представление о качестве данных и охвате данными для некоторых продуктов, но у нас не было ничего, что хорошо обобщало бы для всех бизнес-единиц и продуктов. Это было очень важно в течение периода времени, когда мы можем с уверенностью дать оценку того, каков охват наших наборов данных.

Насколько свежи данные?

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

Все это понимают. По прошествии некоторого времени, когда вы выяснили нюансы, на самом деле довольно легко вычислить. У нас был отличный инструмент для расчета задержки для отдельных шагов. Однако для кого-то на дальнем конце спектра, например для специалистов по данным, поток данных начинается с устройства и заканчивается на каком-то наборе данных, который они хотят запросить. Все, что находится между ними, – это детали реализации для них. Их не волнует, сколько времени потребовалось для любого этапа обслуживания, их волнует, какова сквозная задержка? У нас не было возможности это разоблачить. То, чем мы действительно гордились, мы думали, что наш показатель качества обслуживания с точки зрения свежести был отличным. На самом деле они были не так уж хороши.

Решение – DataFlow Toolchain

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

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

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

Таксономия DataFlow

Как разработчик платформы, мы мало контролировали, как владельцы курируют эти наборы данных. Помимо лучших практик, мы решили не диктовать их имена и схемы, так как это ограничило бы выразительность владельца данных, что не очень хорошо. У нас есть пример. Представьте, что у вас есть компания, у которой есть два бизнес-домена: один занимается камерами, есть бизнес-домен, связанный с термостатами, и есть несколько регионов, в которых они работают. У каждого бизнес-подразделения есть модели продуктов, которые они продают. Обычно в инфраструктуре Интернета вещей вы делите развернутые устройства на несколько категорий. У вас может быть клиентская категория устройств. У вас может быть категория прототипов или инженеров, чтобы вы могли тестировать свои устройства. Затем я объяснил концепцию режима публикации или режима триггера, периодического или внеполосного. Это может быть еще одно измерение, в котором вы хотите пометить наборы данных. Наконец, у вас могут быть типы данных. Хотя это вымышленный пример таксономии, но структура вполне реальна. Именно этим мы занимаемся в Tesla. Мы позволяем бизнес-подразделениям иметь гибкость в наборе значений, допускаемых в определенном измерении. У вас может быть любое количество продуктов, которые вы хотите, и вы решаете называть продукты, как хотите, очевидно. У каждого бизнес-подразделения должны быть все эти измерения, они общие. У каждого должен быть регион, продукт, парк, триггеры и типы данных, а также их комбинация. Это естественно иерархично. Если вы возьмете эти файлы и поместите их в единую структуру данных, вы получите дерево. Какой путь в дереве?

Логический набор данных

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

Единая абстракция для происхождения и каталога

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

График DataFlow

Мы придумали концепцию графа DataFlow. DataFlow для датчика устройства начинается с этого датчика в качестве источника и заканчивается набором данных в одном или нескольких хранилищах данных. Мы разбиваем поток на несколько промежуточных наборов данных и подпотоков. Линия данных захватывает этот поток от источника к месту назначения через различные изменения и переходы на своем пути. Как данные преобразуются в процессе, и как они разделяются, сходится после этапа. Естественно, лучше всего это представить в виде графика. Если это граф, каковы вершины и ребра? Каждый физический набор данных, например, тема Kafka в каком-то проприетарном формате или тема Kafka для того же проприетарного формата в каноническом формате, например в стандартном формате, в нашем случае это Avro. Затем одни и те же данные в базе данных временных рядов и тот же набор данных в пакетной базе данных, все они становятся набором данных или вершинами на этом графике, и все они помечены одной и той же меткой таксономии. Структура набора данных на этом слайде имеет имя, хранилище данных, в котором он находится, а затем – набор меток. Наконец, у него есть ярус. В нашем случае для организации предупреждений используется концепция уровня.

Преобразование DataFlow как Edge

Мы определили, как мы захватываем вершины, поговорим о ребрах. Мы представляем промежуточные шаги как шаги DataFlow. Эти шаги представляют собой потоки Kafka или пакетные задания, выполняемые Spark или MapReduce. Один шаг DataFlow может потреблять несколько наборов данных и создавать несколько наборов данных. Следовательно, это может быть преобразовано в несколько ребер в графе. Мы представляем край как преобразование потока данных. Преобразование DataFlow имеет шаг, который произвел это преобразование, а также кортеж, исходный и целевой наборы данных, которые участвуют в этом преобразовании DataFlow. Мы определили, что означает наличие вершины в графе и что такое ребро в этом графе, но как нам собрать граф?

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

ETL-ing the Graph

К счастью, в нашем случае, еще до того, как мы начали работать с DataFlow, одно из хороших результатов, которые мы делали, – это то, что каждое изменение проходит через систему контроля версий, поэтому у нас не было проблемы с тем, что кто-то делает что-то случайное непосредственно в процессе производства. У нас было всего одно хранилище. Мы используем монорепозиторий, который мы создали с помощью инструмента сборки под названием Bazel. Bazel упорядочивает правила сборки в простой конфигурации, где вы можете вводить исходный код, а затем изменять граф зависимостей. Этот пример представляет собой пример очень высокого уровня того, как мы на самом деле это делаем. Мы определяем группу файлов, называемую набором данных, в которую мы загружаем все файлы конфигурации, которые настраивают набор данных во все различные типы баз данных, которые у нас есть: темы Kafka, таблицы HBase, таблицы HDFS. Затем у нас есть файловая группа, которая захватывает все конвейеры данных. У нас есть конвейеры данных в реальном времени, с которыми мы работаем через созданную нами структуру, называемую каналами Kafka. В этой группе файлов также могут быть задания MapReduce и задания Spark.

Затем оба они вводятся в окончательное правило, которое является правилом генерации графа в качестве зависимости. Если что-то изменится, последнее правило сработает повторно, и график будет восстановлен заново. Bazel очень четко фиксирует эту зависимость и обнаруживает изменения. Также следует отметить, что мы не храним наш каталог и родословную в какой-либо причудливой базе данных. Даже с тысячами наборов данных и тысячами конвейеров эта информация при сериализации в виде структур данных может храниться в килобайтах. У нас есть двоичное представление нашего каталога и происхождения данных, которое мы можем предоставить любому последующему инструменту или любой последующей службе, которая этого хочет. Он восстанавливается для каждого запроса на перенос, так что теперь мы можем также применять строгие семантические проверки, что было одной из наших проблем. Мы можем проверить, что существует набор данных A и набор данных B, и они никогда не должны быть связаны ни в каких сценариях, потому что набор данных A может иметь некоторые частные данные, которые мы не хотим помещать в общедоступный набор данных B. Эта проверка может быть положить в стадию сборки.

Индикаторы качества данных, не зависящие от предметной области

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

Трассировка DataFlow

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

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

Покрытие DataFlow

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

Бесконечная свежесть

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

Заключение

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

Смотрите больше презентаций с расшифровками стенограмм

Related Articles

Leave a Reply

Your email address will not be published. Required fields are marked *

Back to top button