Добро пожаловать в очередной выпуск Armchair Architects в рамках Azure Enablement Show. Сегодня мы обсудим, как вы извлекаете смысл из своих данных? Нашими ведущими будут Дэвид Бланк-Эдельман и наши архитекторы Ули Хоманн и Эрик Чарран.
Чего обычно не хватает необработанным данным, так это контекста.
Я плаваю в данных, некоторые там, некоторые там, а затем некоторые данные в этом другом хранилище. У меня так много данных, что я не знаю, как во всем этом разобраться. Как вы думаете, как получить смысл из ваших данных?
Эта тема близка и дорога сердцу Эрика, потому что это то, что он делает прямо сейчас для нескольких команд здесь, в Microsoft. Если вы помните из предыдущего блога о темных данных: «Я знаю, что собираю данные, но как мне их найти, использовать и фактически синтезировать, чтобы ответить на мои вопросы?» Эрик считает, что это обсуждение немного отличается от того, потому что давайте предположим, что у вас больше нет болота данных. Предположим, у вас есть относительно упрощенный способ извлечения данных из сотен тысяч транзакций или загадочных забавных сообщений, поступающих с небольших устройств, которые вы подключили к облачному провайдеру. Что обычно теряется, так это контекст. Вот как я понимаю это сообщение о временных рядах, которое я получил от этого забавного маленького устройства, которое идентифицируется только с помощью GUID. [globally unique identifier] в сценарии IoT или в пространстве IoT? Откуда мне знать, где была эта штука, кто ее изготовил, когда было последнее обновление прошивки, что она делает и где она находится в физическом пространстве? Все эти вещи по своей сути отсутствуют в небольшом сообщении, которое оно отправляет в облако, которое в конечном итоге попадает в ваш канал передачи данных.
Чтобы ответить на различные вопросы, которые возникают у многих наших клиентов, например, что происходит прямо сейчас? Насколько я эффективен? Что будет и что мне с этим делать? Контекст, связанный с данными, который, по моему мнению, обычно называется семантикой, то есть значением, которое содержат данные, и контекст, связанный с ним, очень важен.
Разработчики данных должны четко определять данные, которыми обмениваются.
Ули считает, что значение и контекстуализация, безусловно, очень важны, но подумайте о другом. Это часто бывает, если вы посмотрите на модели данных. Часто дизайнеры данных на самом деле не уточняют, что они имели в виду. Это давление в фунтах или давление в фунтах, или это в киловаттах, или какая-то другая единица измерения. Его часто опускают, потому что дизайнеры предполагают, что все считают одинаково или используют одни и те же единицы измерения. И это действительно еще один элемент этой контекстуализации, который часто упускается из виду, потому что люди должны «знать», что имеется в виду. Одним из примеров этого было известное мероприятие НАСА, когда один парень думал, что они работают в метрической системе, а другой человек думал, что они работают в имперской системе, что привело к потере дорогой ракеты и спутника. Ули считает, что очень важно подумать обо всех аспектах, о которых говорил Эрик, а также убедиться, что люди понимают, какую единицу измерения мы здесь используем.
Как архитекторы думают об отношениях между данными?
Это пример определения, важного для контекста в дополнение к отношениям. Например, я могу быть на автомобильном или химическом заводе, у меня есть одно устройство, которое может отправлять один набор данных, рядом с другим устройством, которое также отправляет другой набор данных, но я действительно не знаю, что они’ мы работаем, но между этими двумя устройствами IoT существует связь. Что мы думаем об отношениях, когда речь идет о значении, данных и контексте? Как мы думаем об отношениях данных и описываем их?
Эрик думает об этом с трех точек зрения. Существуют сущности, атрибуты и отношения между сущностями. Это вещи, в которых с точки зрения архитектуры, с точки зрения моделирования данных, это ваша основа. Итак, должен быть способ, технология или модель, в которой вы можете выразить эти вещи. И способ, которым вы это делаете, заключается в использовании таких языков, как RDF. [resource description framework] или помеченный граф свойств, или любой из этих языков моделирования, чтобы сказать, как выглядит мой мир. Это то, что меня волнует. Некоторые из этих вещей соотносятся с физическими объектами. Например, в традиционном случае использования цифровых двойников некоторые из них могут быть бизнес-объектами, такими как заказы на работу, контракты на поставку или что-то в этом роде. Все они существуют как сущности, имеющие атрибуты, то есть свойства. Эти свойства имеют значение, как в примере Ули, единицы измерения, а также отношения между ними, и это то, как мы хотим представить себя как архитекторы и разработчики решений. Мы хотим представить это нашим клиентам и нашим конечным пользователям. Не обязательно эта таблица имеет ассоциативный ряд. сущность, которая ссылается на эту таблицу, и это первичные ключи и связанные с ней внешние ключи, но конечный пользователь все еще не знает метрику измерения температуры или единицу измерения. Мы хотим иметь возможность сказать: «Эй, вот опыт, который говорит, что это сущности, атрибуты и отношения, которые вы, как бизнес-пользователи или обычные пользователи, понимаете, и если вы не уверены, что это такое, вы можете навести на это курсор. и получить семантическое значение». Это единица измерения этой температуры, которая объединяет контекст и контекстуализацию. Но чтобы добраться туда, вы должны быть в состоянии связать эти наборы данных вместе. Для этого необходимо провести слияние данных между несколькими источниками данных.
Как архитекторы думают об отношениях, которые еще неизвестны?
Один сценарий, с которым сталкиваются архитекторы, заключается в том, что не все отношения всегда известны заранее, чтобы понять смысл ваших данных. Иногда вы строите отношения постфактум или в процессе. Какие соображения следует учитывать в этой ситуации?
Ули предлагает некоторые из своих соображений по этому сценарию в том смысле, что есть две модели того, как вы думаете об этом. Первый — это временное выравнивание, где мера времени является ключевым краем отношения для использования языка графов, о котором упоминал Эрик. Графики — это один из способов описания вещей, и примером может служить робот Boston Dynamics Spot, который выглядит как собака, но имеет возможность размещать несколько наборов датчиков, но только по одному за раз. Пакеты могут включать пакеты 3D-сенсоров: один для зрения, один для звука и третий. Вы кладете один на Спот, Спот бегает, делает свое дело, а через час берет еще один набор датчиков. Как вы моделируете это и как убедиться, что вы понимаете это в 1ул. час, Спот использовал Vision Pack, и через 2й час Спот использовал аудиопакет? В этом примере Spot всегда был одним и тем же, и у нас был выбор из 3 разных пакетов датчиков, которые всегда были одним и тем же элементом, но их комбинация интересна, поскольку она меняется в зависимости от часа. И это не проблема обнаружения данных, это то, что вы планируете и настраиваете, но теперь вы должны отразить это в своей системе. Ваша система должна знать, что нес робот в час X дня Y и т. д., потому что ваша аналитика данных будет искажаться, если вы этого не понимаете. В том, как Пятно ходит, есть шаблон, когда вам нужно понять местность, местоположение таких вещей, а затем другие вещи, которые приходят из внешних данных.
В другом сценарии влажность играет очень большую роль, например, в производстве, особенно когда вы управляете технологическим процессом. Влажность действительно влияет на то, что происходит: сухо, жарко или холодно? Эти различные факторы действительно важны в производстве. Вы должны понимать, какие данные вас интересуют, а что оказывает влияние. И тогда вы должны расширить свое представление за пределы просто необработанных данных, которые вы должны получить, до контекстуальности, которая действительно имеет смысл. Это часть открытия, которое действительно влияет на ваш набор данных. У вас может быть набор данных, в котором указано, какая температура внутри, но действительно ли это имеет значение? Влияет ли на это сейчас окружающая среда, например, температура наружного воздуха? Поскольку сейчас на улице -15 градусов по Цельсию, влияет ли это на то, насколько сильно вы должны нагреть трубу, чтобы масло продолжало течь? Все эти вещи очень важны, и с моей точки зрения, это «открытие». Затем вам нужно смоделировать это, чтобы вы могли сохранять его, а затем отображать данные, когда кто-то задает вопрос: «Что случилось с этой трубой или с этой нефтью в той трубе в то время?» Вы точно знаете, какие элементы данных вам нужно вернуть, и это, к сожалению, приходит из опыта и экспериментов.
Ранее Ули упомянул, что с вопросом об отношениях связаны две вещи. Одно было временным выравниванием, а вторая его часть — причинно-следственной связью. Здесь у вас есть причинно-следственные данные, такие как температура снаружи, влажность и другие виды факторов, на которые вы не можете повлиять, но эти факторы влияют и влияют на то, что вы измеряете, и каково на самом деле значение этого измерения или влияние этого. является.
Эрик приводит пример «медленно меняющейся задачи второго типа».
Пример Ули заставил Эрика кое о чем задуматься, и для многих наших зрителей, побывавших в пространстве хранилищ данных, это не новая проблема. Итак, для тех людей, которые являются поклонниками инструментария хранилища данных, будь вы поклонником Билла Инмона или Ральфа Кимбалла, в зависимости от того, на какой стороне мира вы находитесь, мы делали это во времена хранилищ данных. Мы взяли таблицу фактов, которая представляет собой необработанные данные, скажем, данные о продажах, а затем у нас были измерения вокруг нее. У нас было измерение продавца, а также время и продукт, чтобы мы могли выяснить, кто что продал, когда и в каком количестве. Теперь одна из проблем, связанных с этим, заключается в том, что пример Ули заставил Эрика задуматься о другом сценарии.
Допустим, мы с вами работаем в одной компании, и я наследую вашу территорию продаж. Теперь у нас есть проблема с историей, в которой я не могу присвоить себе все ваши исторические продажи. Если мы внесем это изменение в измерение продавца, мы получим то, что мы привыкли называть медленно меняющейся проблемой второго типа. Это означает, что когда вы определяете сущности, отношения и атрибуты, которые помогут вам контекстуализировать необработанные транзакционные данные, вы должны сосредоточиться на том, как сами эти модели будут меняться с течением времени, чтобы вы на самом деле не оглядывались назад в историю с сегодняшним пониманием. того, как эти объекты, атрибуты и отношения реализованы. Это очень старая проблема, которая будет только усугубляться различными скоростями, потоками и источниками данных, которые есть в современном мире.
Чтобы услышать весь разговор, вы можете посмотреть видео ниже.
