Реальное время.
И время, близкое к реальному

Для понятия реального времени существует несколько стандартов.
В стандартах ISO понятие «real time» определяется не конкретным числом миллисекунд, а тем, что обработка должна укладываться во временные требования, заданные внешним процессом. ISO/IEC 2382:2015 остаётся действующим стандартом терминологии. Такой же подход используется и в стандартах по real-time IoT.

То есть в строгом инженерном смысле:

Именно поэтому в промышленной автоматике «реальное время» может означать миллисекунды, а в другом предметном контексте допустимый интервал может быть значительно больше.

Near real-time, «время близкое к реальному» – это прикладной термин, значение которого определяется отраслью. Как пример: NASA для спутниковых данных использует собственную классификацию: real-time – менее часа, near real-time – 1–3 часа. Для такой предметной области это вполне оправданно.

В области корпоративных данных шкала реального времени и времени, близкого к реальному строится от задач. В частности, IBM в статье «What is data latency» указывает, что для операционных сценариев c применением реального времени типичная задержка измеряется миллисекундами или секундами и подчёркивает, что универсального порога нет – он определяется бизнес-сценарием.

Для аналитики недостаточно говорить просто «задержка 1 секунда». Следует различать как минимум два вида задержки.

1. Задержка при загрузке (Data freshness / ingest latency) – сколько времени проходит от возникновения события до момента, когда оно становится доступно для запроса.

Здесь мы видим цепочку: Событие – CDC/Kafka – обработка – хранилище (Lakehouse) – доступные данные

2. Задержка выполнения запроса (Query latency) – сколько времени проходит от запроса к уже доступным данным до получения результата.

Поэтому общая система может иметь: freshness = 2 секунды, но query latency = 15 секунд, и тогда называть такую аналитику полноценным реальным временем уже сложно.

Реальное время – необходимое условие для ИИ-агентов.

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

Кроме того, ИИ-агенты формируют шторм запросов, которые не являются однотипными и формализованными. В этом смысле Data Lakehouse, а точнее их узкий спектр, выглядит как единственное решение, которое может обеспечить ИИ-агентов с учётом жестких требований к времени запросов и их количества. Традиционные хранилища данных (DWH) не могут справиться с такой высокой нагрузкой. А витрины данных, ориентированные на огромные объёмы данных, ограничены в способности выполнять сложные и нетипичные запросы, например, по связыванию множества таблиц и предоставлению семантического слоя и качества данных для ИИ-агентов.

С точки зрения реального времени для ИИ-агентов лучше смотреть на сводную метрику: Сквозная задержка для принятия решения (End-to-end decision latency).

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

Между терминами «потоковая аналитика» (streaming) и «реальное время» (real-time) есть тонкая грань. Потоковая передача описывает способ обработки или доставки данных, а реальное время означает временную характеристику.

Можно построить потоковый конвейер данных с задержкой 30 секунд или даже несколько минут. Это всё ещё потоковая обработка данных, но уже скорее в условиях времени, близкого к реальному (near real-time).