Как использовать моделирование данных для облегчения интеграции инженерных данных из нескольких источников

От датчиков до САПР: использование моделирования данных для унификации инженерных данных в Directus

Современные инженерные организации работают в богатом данными, но фрагментированном ландшафте. Потоки датчиков от устройств IoT, параметрические модели САПР, системы планирования ресурсов предприятия (ERP) и базы лабораторных испытаний каждый производят данные в разных форматах, в разных каденциях и с различными смысловыми значениями. Интеграция этих источников в единое, запрашиваемое целое является основой для прогнозного обслуживания, цифровых двойников и улучшения дизайна замкнутого цикла. Моделирование данных обеспечивает план для этой интеграции, и с гибкой платформой, такой как Directus, инженеры могут перевести этот план в рабочий, управляемый API центр данных без тяжелого пользовательского кодирования.

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

Что такое моделирование данных (и почему это важно для инженерных данных)

Моделирование данных — это процесс определения схемы, которая описывает структуру, отношения, ограничения и семантику данных, на которые опирается ваша организация. Она отвечает на такие вопросы, как: Как считывание датчика ветряной турбины связано с серийным номером турбины? Какие атрибуты сборки САПР должны присутствовать до того, как можно будет создать заказ на покупку? Без модели интеграция становится спагетти «точка-точка» — один скрипт Python для ERP, другой для SCADA и ни одного источника истины.

Три уровня абстракции являются стандартными в машинном моделировании данных:

Концептуальная модель данных

На этом высоком уровне вы идентифицируете ключевые бизнес-субъекты (например, «Актив», «Измерение», «Лог обслуживания», «Компонент») и их основные отношения, но вы не детализируете атрибуты или ключи. Инженерный менеджер и архитектор данных могут обсудить, связано ли «Измерение» с одним «Активом» или с «Активом» и «сенсором» отдельно. Эта модель часто рисуется как диаграмма отношений с объектом (ERD) с использованием простых коробок и линий.

Логическая модель данных

Здесь вы указываете каждый атрибут, тип данных и отношения. Например, логическая модель для «Измерения» будет включать в себя временную метку (ДАТЕЛЬ), значение (FLOAT), блок (TEXT) и иностранный ключ к «Сенсору». Ограничения, такие как «значение не может быть отрицательным» или «временная метка должна быть в UTC», написаны на этом уровне. Логическая модель не зависит от какого-либо конкретного двигателя базы данных.

Модель физических данных

Наконец, физическая модель отображает логические определения для реальных объектов базы данных: таблицы, столбцы, индексы, разделы. В Directus это переводится как Коллекционные материалы (таблицы), Поле (колонки) и Отношения (зарубежные ключи). Физическая модель также учитывает производительность — например, добавление составного индекса на (sensor id, метка времени) для ускорения запросов временных рядов.

Сила Directus заключается в том, что он разрушает разрыв между логическим и физическим моделированием: вы можете определить логическую модель непосредственно в Data Studio приложения, а Directus автоматически создает физическую схему базы данных (PostgreSQL, MySQL, SQLite и т. Д.).

Преимущества моделирования данных в инженерной интеграции

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

Семантическая последовательность в дисциплинах

Инженеры-механики могут назвать часть «Бракетой», в то время как закупки называют ее «Предметом инвентаризации No 447». Логическая модель определяет псевдонимы, допустимые значения и каноническое название, чтобы каждая система говорила на одном языке. Directus поддерживает правила проверки на уровне поля и выпадения из соответствующих коллекций для обеспечения этой согласованности.

Качество данных в точке входа

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

Упрощенное управление изменениями

Инженерные среды не являются статическими. Добавлены новые типы датчиков, обновлены продукты и сдвинуты правила. Хорошо смоделированная схема изолирует изменения в ограниченной области. Добавление нового атрибута («температура окружающей среды») в коллекцию «Измерение» не нарушает существующие панели приборов или API — пока модель в версии. Directus хранит полную историю схем и позволяет просматривать изменения перед публикацией.

Автоматизированное картирование данных и ETL

Когда у вас есть четкая логическая модель, отображение полей источника для целевых полей становится механической задачей, которая часто может быть автоматизирована с помощью инструментов ETL или Directus Flows. Например, CSV из системы ERP может быть отображен на коллекцию «Часть» с использованием правил поля за полем, и повторяющиеся несоответствия (например, несоответствия формата даты) улавливаются во время преобразования.

Шаг за шагом: Постройте модель инженерной интеграции в Directus

Давайте рассмотрим конкретный сценарий: интеграция данных вибрации в реальном времени от трех датчиков ветряных турбин с метаданными модели CAD турбины и историей обслуживания. Каждый источник имеет свою собственную схему — API датчика возвращает JSON, как , в то время как система CAD экспортирует XML-файл с вложенными компонентными структурами.

1. идентификация и документирование источников данных

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

Документируйте поля, которые посылает каждый источник, типы данных и частоту обновления. Это становится входом для вашей концептуальной модели.

2.Проектирование концептуальной модели

Определить основные объекты и их взаимосвязи, не беспокоясь о конкретных областях. Для интеграции ветровых турбин:

Нарисуйте эти коробки и линии на доске или в инструменте, таком как Lucidchart. Покажите, что TurbineAsset имеет много компонентов, а компонент может иметь много измерений вибрации. Поделитесь этой диаграммой с экспертами по домену - они будут обнаруживать недостающие объекты (например, сам «сенсор» в качестве актива).

3.Создание логической модели в Directus

Откройте Directus Data Studio и создайте коллекцию для каждого объекта. Для Вибрационное измерение:

[ Компонент :

Directus автоматически создает много-к-одному иностранному ключу и генерирует конечную точку REST/GraphQL API для каждой коллекции.На этом этапе вы строите логическую модель непосредственно поверх базовой базы данных (например, PostgreSQL).

4.Создание физической модели (оптимизация производительности)

Теперь добавьте индексы и настройки поля, которые влияют на производительность запроса. В Directus вы можете установить поле в качестве «первичного ключа» (целое число автоматического увеличения или UUID) и добавить пользовательские индексы через интерфейс базы данных или запустив сырой SQL в контексте Directus. Для таблицы временных рядов, такой как VibrationMeasurement:

Физическая модель также включает в себя правила хранения данных. Вы можете использовать Directus Flows или запланированный скрипт для очистки показаний старше 90 дней или архивировать их на более дешевый уровень хранения, сохраняя при этом модель неповрежденной.

5. Интеграция источников в Directus

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

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

6. Проверка и эволюция модели

После потоков данных проверьте, чтобы запросы возвращали правильные результаты. Например, запустите встроенный фильтр Directus, чтобы найти все записи «VibrationMeasurement», где и присоедините их к коллекциям и . Имеет ли результаты инженерный смысл? Если нет, настройте логическую модель — возможно, «Измерение» должно быть связано как с «Компонентом», так и с «Сенсором», чтобы различать происхождение данных.

Со временем вы добавите новые источники (например, результаты анализа нефти) или обесцените старые.В Directus вы можете добавлять новые поля в существующие коллекции или создавать новые коллекции, не затрагивая существующие API — просто регенерируйте SDK или документируйте изменения в спецификации OpenAPI.

Инструменты и методы для инженерного моделирования данных

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

Схема проектирования и документирования

ETL и Data Pipelines

Управление данными и метаданные

Подумайте о том, чтобы рассматривать саму схему Directus как регулируемый актив. Используйте поля «Комментарий» и «Примечание» Directus в каждой коллекции для хранения бизнес-определений, ответственного владельца и политики хранения. Для более крупных организаций внешний каталог данных, такой как Alation или DataHub , может использоваться для индексации схемы Directus и отслеживания линии.

Лучшие практики и общие подводные камни

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

Лучшие практики

Общие подводные камни

Реализация интегрированной платформы инженерных данных

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

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

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