Управление целостностью данных Smart Ship Solution (далее — SS): от обнаружения отсутствующих данных до восстановления, проверки и обнаружения аномальных данных
На судах данные навигации, двигателя и оборудования непрерывно генерируются различными системами, включая IAS, VDR и ACONIS. SS — это интегрированная судовая и береговая платформа данных, которая собирает, стандартизирует и обрабатывает эти данные на борту, использует их в таких сервисах, как управление механизмами, управление навигацией и управление судном, а также передаёт необходимые данные на берег.
Однако обеспечение надёжности данных в судовой среде невозможно решить простым определением того, были ли данные «отправлены» на берег. Между судном и берегом могут возникать разрывы или задержки сетевого соединения, а данные также могут быть потеряны в Pipeline сбора и обработки на борту.
В конечном итоге необходимо проверить три момента.
Были ли данные нормально сгенерированы в нужный момент, были ли они полностью доставлены с борта на берег и являются ли сами значения, поступившие на берег, корректными данными, которые действительно можно использовать?
В SS эта проблема в широком смысле называетсяуправлением отсутствующими данными и восстановлениеми решается с помощью двух функций: управления обнаружением аномалий данных и управления отсутствующими данными и восстановлением.Управление отсутствующими данными и восстановлениемотвечает за целостность сбора, передачи и восстановления данных, а управление обнаружением аномалий данных проверяет, являются ли собранные значения датчиков аномальными.
Иными словами, SS предоставляет не просто функцию передачи данных, а создаёт систему управления надёжностью данных, которая включает весь процесс:обнаружение отсутствующих данных → отслеживание причины → восстановление → проверка восстановления → проверка качества данных.
1. Почему одной отметки «Передача выполнена успешно» недостаточно для судовых данных
Поток данных SS начинается с судового оборудования. Данные, генерируемые IAS, VDR, ACONIS и другими системами, проходят через модуль сбора данных судовых датчиков в модуль обработки данных на борту, где преобразуются в необработанные данные временных рядов и периодические агрегированные данные. Затем они используются такими предметными сервисами, как управление механизмами и управление навигацией, либо передаются на берег через судовую систему связи с берегом.
С операционной точки зрения особенно важной целью являются1-минутныепериодические агрегированные данные.
Управление отсутствующими данными и восстановлением определяется как функция, которая для каждого судна проверяет, собираются ли ежедневные 1-минутные данные надлежащим образом вплоть до береговой стороны, определяет место потери данных в случае их утраты и выполняет повторную передачу.
День, переведённый в минуты, выглядит следующим образом.
24 часа × 60 минут = 1 440 записей
Следовательно, если все данные за прошедший день были собраны надлежащим образом, должно существовать 1 440 Timestamp.
Однако на практике определение целостности является более детальной задачей, чем простая проверка того, чтоCount = 1440.
Когдаагрегированные данные по времени/интервалу генерируются на борту и поступают на берег, фиксируется Timestamp получения. Потеря определяется на основе фактического времени получения после исключения дублирующихся Timestamp. Вместо подтверждения потери данных по одному показателю SS совместно проверяет состояние получения данных, события Backfill, историю восстановления и состояние Pipeline.
Поэтому управление целостностью данных SS начинается со следующего вопроса.
Если в течение дня отсутствует хотя бы одна из 1 440 точек данных, как система обнаружит это, определит место потери и восстановит данные?
2. Этап 1 — отправная точка управления целостностью: «сделать отсутствующие данные видимыми»
Для управления целостностью данных отсутствующие данные сначала должны статьвидимыми.
Управление отсутствующими данными и восстановлениемпредоставляет для этого три представления.
В разделе Overview отображается состояние каждого судна на текущий момент, в разделе Daily — состояние сбора 1-минутных данных за выбранную дату, а в разделе Recovery Status (On-Board) — состояние восстановления на борту.
С помощью этих представлений операторы могут определить не только то, что «со сбором данных возникла проблема», но и
на каком судне → за какую дату → сколько точек данных отсутствует, шаг за шагом.
Здесь важно не просто наличие сбоя, аопределение границ сбоя. В среде, где управляются данные сотен судов, трудно предпринимать реальные действия, основываясь только на простом сообщении об ошибке.
С другой стороны, если область отсутствующих данных можно сузить по судну, дате и Timestamp, последующий анализ причин и процедуры восстановления становятся гораздо понятнее. Поэтому первый принцип управления целостностью данных в SS можно сформулировать следующим образом.
«Мы не ограничиваемся тем, что узнаём об отсутствии данных; мы определяем, данные какого судна и за какой период отсутствуют.»
3. Этап 2 — Не ограничивайтесь1440 → 1439; отслеживайте отсутствующий интервал
Если должно быть 1 440 записей, но имеется только 1 439, мы можем определить, что одна запись отсутствует.
Однако этого недостаточно для восстановления после инцидента.
Для восстановления необходимо определить, какой Timestamp отсутствует и насколько далеко эти данные были успешно доставлены по Pipeline.
SS включает несколько секций обработки, охватывающих бортовую и наземную среды.
С операционной точки зрения это можно концептуально представить следующим образом.
Поэтому даже если отсутствует одна и та же одиночная запись, причина может быть разной.
Если данных, сгенерированных на борту, недостаточно, сначала следует проверить секции генерации и обработки данных на борту — например, модуль приёма данных, модуль предварительной обработки данных и модуль обработки данных.
И наоборот, если данные на борту генерируются нормально, но количество записей, полученных на берегу, недостаточно, можно проверить межузловую сеть после модуля передачи данных, EMQX, наземный модуль интеграции данных, Kafka и наземный модуль обработки данных.
Смысл этой структуры очевиден.
Для фактического восстановления недостаточно остановиться на симптоме «данные отсутствуют» — необходимо пойти на шаг дальше и определить, «насколько далеко дошли данные и где они исчезли».
4. Шаг 3 — Сначала выполняется возможное восстановление на борту
Одна из особенностей SS заключается в том, что обнаружение потери данных не означает автоматически, что наземный оператор должен напрямую запросить у судна повторную передачу данных.
На борту отсутствующие данные выявляются на основе Pipeline генерации и обработки данных, а при необходимости данные, которые можно восстановить самостоятельно, обрабатываются повторно.
Общий процесс можно упростить следующим образом.
Поскольку периодические агрегированные данные за 1 минуту впоследствии служат критерием определения согласованности потери данных и управления восстановлением на берегу, важно, чтобы на борту они генерировались и поддерживались в нормальном состоянии.
Область управления потерей и восстановлением данных включает обработку данных на борту и на берегу, мониторинг данных, сбор данных с бортовых датчиков, предварительную обработку данных, наземную интеграцию данных и интеграцию с Kafka, а основные операции включают выявление предполагаемых потерь, повторную обработку и окончательное подтверждение восстановления.
Иными словами, согласованность данных рассматривается не как ответственность одной центральной системы,а как структура, в которой роли разделены, чтобы восстановление можно было выполнять также на судне, где генерируются данные.
Это можно выразить одним предложением следующим образом.
«Вместо того чтобы просто ждать восстановления сети, мы обеспечиваем возможность сначала выполнить восстановление в месте, где находятся данные».
5. Шаг 4 — На берегу подтверждение и повторная передача через наземный модуль интеграции данных управляются как единый процесс состояний
Если после восстановления на борту данные всё ещё невозможно подтвердить на берегу, запускается процедура восстановления с наземной стороны.
Здесь важно, что обнаружение отсутствующих данных не означает немедленного запроса судну на повторную отправку тех же данных. Сначала наземный модуль интеграции данных проверяется на наличие данных и возможность повторной передачи; только если данные по-прежнему невозможно восстановить, процесс переходит к этапу повторной передачи с борта.
Запрос на повторную передачу с берега → Обнаружение цели восстановления на борту → Восстановление с помощью модуля обработки данных → Получение BackfillResponse и отражение результата → Повторная попытка после задержки ответа или сбоя
Для пользователей этот процесс восстановления упрощается и отображается в виде состояний.
Управление потерей и восстановлением данных также предоставляет функции, связанные с ежедневной повторной передачей.
В этой структуре повторная передача — это не просто кнопка или единичный вызов API, а
обнаружение отсутствующих данных → определение возможности повторной передачи → запрос → обработка → подтверждение фактического восстановленияпроцесс со статусомРабочий процесс восстановления .
6. Шаг 5 — Различайте «успешный запрос» и «завершённое восстановление»
Распространённая ошибка в системах восстановления данных — считать успешный вызов API повторной передачи успешным восстановлением данных.
Однако на самом деле требуется не ответ 200 OK на запрос.
Повторно переданные данные должны снова пройти через Pipeline и попасть в наземный модуль обработки данных, а фактический отсутствующий Timestamp должен быть отражён в истории приёма.
Поэтому критерии завершения восстановления в SS лучше всего понимать следующим образом.
То есть Успешный запрос ≠ Завершённое восстановление.
Управление потерей и восстановлением данных включает не только обнаружение участка потери и запрос на повторную обработку, но и процедуру подтверждения окончательного результата восстановления; операторы могут одновременно проверять состояние приёма данных, события Backfill, историю восстановления и состояние Pipeline.
Это важный аспект управления согласованностью данных в SS.
Цель заключается не в создании функции повторной передачи, а в повторной проверке того, действительно ли результат повторной передачи отражён в состоянии системы.
7. Шаг 6 — Получение всех 1 440 записей не означает, что данные находятся в нормальном состоянии
После устранения этой проблемы мы можем подтвердитьполнотуданных, то есть наличие необходимых данных.
Однако остаётся ещё одна проблема.
Даже если получены все 1 440 записей, данные нельзя использовать как есть для анализа или оперативной поддержки, если все 1 440 записей указывают на одно и то же значение или непрерывно демонстрируют аномальные диапазоны.
На этом этапеУправление обнаружением аномалий данных дополняет Управление отсутствующими данными и восстановлением.
Управление обнаружением аномалий в данных — это функция, которая ежедневно проверяет на суше данные датчиков каждого судна на наличие аномалий, управляет историей создания, сохранения и снятия тревог и передаёт результаты ответственному сотруднику.
К её внутренним компонентам относятся справочник судов, условия тревог, статус тревог для конкретных судов, подробная история, ежедневные агрегированные данные и группы получателей писем.
Пользователи могут настроить условие тревоги, применимые суда и группу получателей для каждого Tag, просматривать статус тревог для каждого судна и экспортировать его в формате CSV.
В частности, зависшая тревога и пользовательская тревога обнаруживают данные датчиков, в которых одно и то же значение сохраняется в течение длительного времени или которые соответствуют заранее заданным условиям.
Таким образом, с точки зрения надёжности данных SS можно выделить следующие четыре этапа.
|
Аспект |
Проверочные вопросы |
Ключевая функция |
|---|---|---|
|
Полнота |
Все ли необходимые данные существуют без пропусков? |
Управление отсутствующими данными и восстановлением |
|
Непрерывность |
В какой момент было разорвано соединение между судном и берегом? |
Проверка состояния конвейера |
|
Восстановление |
Были ли восстановлены отсутствующие данные? |
Заполнение пропусков / повторная отправка |
|
Достоверность |
Являются ли сами значения данных достоверными? |
Управление обнаружением аномалий в данных |
Иными словами, управление отсутствующими данными и восстановлением проверяет, «существуют ли данные», а управление обнаружением аномалий в данных проверяет следующий этап: «находятся ли эти данные в пригодном для использования состоянии».
8. Операционный аспект — определение границы между автоматизацией и вмешательством оператора
По мере увеличения числа функций управления целостностью данных возникает ещё одна проблема.
Если операторы вручную проверяют каждую ситуацию, операционная нагрузка также резко возрастает по мере увеличения числа судов и объёма данных.
И наоборот, если система автоматически принимает решения и обрабатывает каждый сбой, становится трудно контролировать ошибочные решения или повторные отправки.
SS разделяет области автоматической обработки и вмешательства оператора, находящиеся между этими двумя крайностями.
Система непрерывно проверяет состояние приёма данных, рассчитывает потенциальные потери данных и управляет состоянием заполнения пропусков и восстановления. Управление обнаружением аномалий в данных также проверяет данные датчиков судов посредством ежедневного пакетного задания и обрабатывает историю создания, сохранения и снятия тревог.
На основе этих результатов операторы выбирают конкретные суда и даты, выбирают цели, для которых разрешена повторная отправка, и управляют состоянием Tag, условиями Remark, Hazard и целевыми судами.
Иными словами, философию эксплуатации можно обобщить следующим образом.
«Система автоматизирует стандартные процессы восстановления, решения по которым можно принимать повторно, и предоставляет операторам чётко обозначенные ситуации, требующие дополнительного анализа».
Цель автоматизации заключается не в устранении операторов, а в том, чтобы дать операторам возможность сосредоточиться на проблемах, по которым действительно требуется их решение.
9. Заключение — целостность данных между судном и берегом представляет собой не отдельную функцию, а замкнутый цикл
Если рассматривать управление целостностью данных в SS только как отдельные функции, такие как управление отсутствующими данными и восстановлением или управление обнаружением аномалий в данных, может показаться, что различные функции существуют параллельно, однако на деле они образуют единый связанный поток.
Это не просто «функция повторной отправки», а замкнутый циклОна близка к структуре управления надёжностью данных.
Управление пропусками и восстановлением данных проверяет, были ли данные, генерируемые на борту каждую минуту, должным образом доставлены на берег, а если какие-либо данные отсутствуют, выявляет причину, восстанавливает данные, а затем проверяет фактические результаты восстановления.
Управление обнаружением аномалий в данных повторно проверяет, являются ли значения таким образом полученных данных нормальными, и при обнаружении аномалии уведомляет операторов с помощью оповещений и журналов истории.
В конечном счёте ключ к обеспечению надёжности данных между судном и берегом — это неоднократная корректная отправка данных— не в этом.
Необходимо создать замкнутую систему управления, которая автономно обнаруживает пропуски, определяет место возникновения проблемы и восстанавливает данныеи затем повторно проверяет, действительно ли восстановленные данные были отражены на берегу, и наконец проверяет качество значений данных.Именно это и имеется в виду.
С этой точки зрения управление пропусками и восстановлением данных в SS и управление обнаружением аномалий в данных являются не двумя независимыми функциями, а
сквозной системой обеспечения надёжности данных, состоящей из этапов «наличие данных → целостность доставки → возможность восстановления → проверка восстановления → достоверность данных»,в которой их можно рассматривать как функции, охватывающие соответственно начальный и конечный этапы.
sypark2