Хабрахабр

Exactly once is NOT exactly the same: анализ статьи

Введение

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

Приступим.

Анализ

Начинается все очень даже неплохо:

Notable Stream Processing Engines (SPEs) include Apache Storm, Apache Flink, Heron, Apache Kafka (Kafka Streams), and Apache Spark (Spark Streaming). Distributed event stream processing has become an increasingly hot topic in the area of Big Data. One of the most notable and widely discussed features of SPEs is their processing semantics, with “exactly-once” being one of the most sought after and many SPEs claiming to provide “exactly-once” processing semantics.

Обсудим же ее. Т.е., обработка данных крайне важна и т.п., а особенно обсуждаемая тема — это exactly-once.

There exists a lot of misunderstanding and ambiguity, however, surrounding what exactly “exactly-once” is, what it entails, and what it really means when individual SPEs claim to provide it.

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

I’ll discuss how “exactly-once” processing semantics differ across many popular SPEs and why “exactly-once” can be better described as effectively-once

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

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

Далее, идет описание семантик:

  • At-most-once, т.е. не более одного раза. При кажущейся очевидности, такое поведение крайне сложно гарантировать при краевых сценариях по типу падений, нарушение сетевой связности и другое. Но для автора тут все просто:

  • At-least-once, т.е. не менее одного раза. Схема более сложная. И граблей можно насобирать поболее:

  • Exactly-once. Что же такое exactly-once?

Events are guaranteed to be processed “exactly once” by all operators in the stream application, even in the event of various failures.

гарантия обработки exactly-once — это когда произошла обработка "ровно один раз". Т.е.

Перефразирую: обработка один раз — это когда обработка происходит "один раз". Чувствуете мощность определения? Но для распределенных систем это вещь очевидная. Ну да, там еще говорится про то, что эта гарантия должна сохраняться и в случае отказов. Давать определения с кавычками, не объясняя, что это означает — признак глубокого и вдумчивого подхода. И кавычки намекают на то, что что-то тут не так.

И здесь я бы хотел остановиться более подробно. Далее идет описание способов реализации такой семантики.

Two popular mechanisms are typically used to achieve “exactly-once” processing semantics.

  1. Distributed snapshot/state checkpointing
  2. At-least-once event delivery plus message deduplication

Если первый механизм по поводу снепшотов и чекпоинтов вопросов не вызывает, ну кроме некоторых деталей типа эффективности, то со вторым есть небольшие проблемы, о которых автор умолчал.

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

Однако переходим к самому вкусному:

Is exactly-once really exactly-once?

The label “exactly-once” is misleading in describing what is done exactly once. Now let’s reexamine what the “exactly-once” processing semantics really guarantees to the end user.

есть какие-то нестыковки. Говорится о том, что пора бы уже пересмотреть это понятие, т.к.

In reality, there is no SPE that can guarantee exactly-once processing. Some might think that “exactly-once” describes the guarantee to event processing in which each event in the stream is processed only once. To guarantee that the user-defined logic in each operator only executes once per event is impossible in the face of arbitrary failures, because partial execution of user code is an ever-present possibility.

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

Именно! Внимательный читатель тут же воскликнет: так ведь важен выхлоп, а не то, как это исполняется. Если результат такой, как если бы это происходило ровно один раз, так значит и произошло это ровно один раз. Важно то, что произошло в результате, а не то, как на самом деле это происходило. А все остальное — это шелуха, не относящееся к делу. Не находите? Нам кажется, что код выполняется последовательно, инструкция за инструкцией, что сначала идет чтение, потом запись, потом новая инструкция. Системы сложны, и получаемые абстракции создают лишь иллюзию выполнения определенным образом. И сущность правильных абстракций и заключается в том, чтобы поддерживать иллюзию простых и понятных гарантий, без ковыряния вглубь каждый раз, когда надо присвоить значения переменной. Но это не так, все гораздо сложнее.

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

Пример же кода в статье наглядно демонстрирует отсутствие понимания того, как надо писать обработчики:

Map (Event event) { Print "Event ID: " + event.getId() Return event
}

Читателю предлагается самостоятельно переписать код, чтобы не повторять ошибок автора статьи.

If user logic cannot be guaranteed to be executed exactly once then what is executed exactly once? So what does SPEs guarantee when they claim “exactly-once” processing semantics? When SPEs claim “exactly-once” processing semantics, what they’re actually saying is that they can guarantee that updates to state managed by the SPE are committed only once to a durable backend store.

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

Для более подробной информации можно кратко ознакомиться с моей статьей: Гетерогенная конкурентная обработка данных в реальном времени строго один раз.

In other words, the processing of an event can happen more than once but the effect of that processing is only reflected once in the durable backend state store.

Важен лишь эффект от обработки, т.е. То, что есть "durable backend state store" пользователю абсолютно фиолетово. Стоит отметить, что для некоторых задач нет необходимости иметь durable backend state store, а гарантировать exactly once было бы неплохо. консистентное состояние и выходные значения на всем промежутке выполнения обработки потоковых данных.

Here at Streamlio, we’ve decided that effectively-once is the best term for describing these processing semantics.

Точность и четкость определений вызывает по-настоящему яркий эмоциональный отклик. Типичный пример бестолкового ввода понятий: напишем некоторый пример и пространные рассуждения на целый абзац, а в конце допишем, что "мы так определяем это понятие".

Выводы

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

[1] Exactly once is NOT exactly the same.
[2] Гетерогенная конкурентная обработка данных в реальном времени строго один раз.

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть