Потоковая обработка данных и нано второе разрешение

Question

Я только начинаю тему фреймворков для обработки потоковых данных в реальном времени, и у меня есть вопрос, на который я до сих пор не смог найти какого-либо окончательного ответа:

Делают ли обычные подозрения (Apache'sSpark, Kafka, Storm, Flink и т. Д.) Поддерживают обработку данных с разрешением времени события наносекунд (или даже пикосекунд)?

Большинство людей и документация говорят о разрешении в миллисекундах или микросекундах,но я не смог найти однозначного ответа, если будет возможно большее разрешение или проблема.Единственная структура, на которую я полагаю, чтобы иметь такую ​​возможность, - это структура Kapacitor от infxData, так как их TSDB influenxDB, похоже, хранит временные метки с наносекундным разрешением.

Может ли кто-нибудь здесь предложить некоторую информацию об этом или даже некоторые информированные факты?Альтернативные решения / рамки, предлагающие эту возможность?

Что-нибудь будет высоко оценено!

Спасибо и всего наилучшего,

Саймон

---

Справочная информация о моем вопросеЯ работаю в среде с целым рядом запатентованных реализаций для хранения и обработки данных и думаю о некоторой организации / оптимизации в настоящее время.Мы проводим эксперименты по физике плазмы с множеством различных диагностических / измерительных систем с различной частотой дискретизации, в настоящее время до «выше гигабайтных выборок в секунду».Один общий факт / предположение в наших системах заключается в том, что каждый образец имеет записанное время события в наносекундном разрешении.При попытке использовать установленную потоковую (или также пакетную) среду обработки, мы должны будем сохранить это разрешение метки времени.Или пойти еще дальше, поскольку мы недавно нарушили порог 1 Gsps в некоторых системах.Отсюда и мой вопрос.

Answer 1

В то время как Kafka Streams использует миллисекундное разрешение, время выполнения на самом деле является довольно независимым.В конце концов, это просто длинные.

Сказав это, «проблема» - это определение временного окна.Если вы укажете временное окно в 1 минуту, но разрешение вашей временной метки будет меньше миллисекунды, ваше окно будет меньше 1 минуты.В качестве обходного пути вы можете увеличить окно, например, на 1000 минут или 1 000 000 минут для микро / нано-секундного разрешения.

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

Answer 2

В случае, если это неясно, вы должны знать о разнице между временем события и временем обработки:

время события - время генерации события в источнике

время обработки - время выполнения события в обработчике

src: Flink docs

AFAIK Storm не поддерживает время событияи Spark имеет ограниченную поддержку.Это оставляет Kafka Streams и Flink для рассмотрения.

Flink использует длинный тип для отметок времени.В документах упоминается, что это значение указано в миллисекундах с 1970-01-01T00: 00: 00Z, но AFAIK, когда вы используете временную характеристику события, единственной мерой прогресса являются метки времени события.Итак, если вы можете вписать свои значения в большой диапазон, то это должно быть выполнимо.

edit:

В общем водяные знаки (основанные на метках времени) используются для измерения хода времени событияв окнах, триггерах и т. д. Таким образом, если вы используете:

• AssignerWithPeriodicWatermarks , тогда новый водяной знак испускается с интервалами, определенными в config (интервал автоматической пометки) во временной области обработки- даже если используется характеристика времени события.Подробнее см., Например, метод org.apache.flink.streaming.runtime.operators.TimestampsAndPeriodicWatermarksOperator#open(), где зарегистрирован таймер времени обработки.Таким образом, если для автоматического водяного знака установлено значение 500 мс, то каждые 500 мс времени обработки (как взято из System.currentTimeMillis()) генерируется новый водяной знак, но временная метка водяного знака основывается на временной метке событий.

• AssignerWithPunctuatedWatermarks тогда наилучшее описание можно найти в документах для org.apache.flink.streaming.api.datastream.DataStream#assignTimestampsAndWatermarks(org.apache.flink.streaming.api.functions.AssignerWithPunctuatedWatermarks<T>):

Назначение меток времени элементам в потоке данныхи создает водяные знаки, чтобы сигнализировать о прогрессе времени события на основе самих элементов.

Этот метод создает водяные знаки исключительно на основе элементов потока. Для каждого элемента, который обрабатывается с помощью AssignerWithPunctuatedWatermarks#extractTimestamp(Object, long), AssignerWithPunctuatedWatermarks#checkAndGetNextWatermark(Object, long) вызывается метод, и генерируется новый водяной знак, если возвращенное значение водяного знака неотрицательно и больше, чем предыдущий водяной знак.

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

Чтобы понять, как работают водяные знаки, настоятельно рекомендуется прочитать следующее: Тайлер Акидау в потоковом режиме 102