Files

8.0 KiB
Raw Permalink Blame History

P08. PGVal: сквозная проверка гарантий потоковой обработки

  • Версия и дата проверки: 1.1, 07.09.2026.
  • Статус: готово к назначению.

Статья и исходные материалы

  • Основная статья: Jawad Tahir и соавт. — How Reliable Are Streams? End-to-End Processing-Guarantee Validation and Performance Benchmarking of Stream Processing Systems. PVLDB 2024.
  • Кратко о статье: Заявленная системой гарантия обработки потока ещё не доказывает, что входные события дали правильный сквозной результат при сбое. PGVal сопоставляет выход с независимо рассчитанным ожидаемым результатом, вводит процессные и сетевые отказы и измеряет надёжность, надёжную пропускную способность и стоимость отказа. Авторы показывают зависимость результата от топологии, разбиения и параллелизма. Проект воспроизводит такую проверку для одной потоковой системы.
  • Почему результат актуален: Flink и Kafka Streams активно развиваются, а сквозная гарантия по-прежнему зависит от источника, приёмника, топологии и конфигурации. Модульный расчёт ожидаемого результата и модель отказов позволяют проверять современные версии систем и новые операторы вместо буквального повторения снимка 2024 года.
  • Артефакты и данные: jawadtahir/DSPF-BM под Apache-2.0, с Docker-развёртыванием Kafka Streams, Apache Storm и Apache Flink, генератором данных, модулем независимого расчёта ожидаемого результата и инъекцией отказов. Зафиксированные ревизии: jawadtahir/DSPF-BM@d74c9b80a3a1 (Apache-2.0).
  • Что уже предоставляет артефакт: PGVal содержит топологии, источник, расчёт ожидаемого результата, инфраструктуру и режимы процессных и сетевых отказов, включая потери, дублирование и переупорядочивание. Инфраструктуру и исполнитель отказов можно использовать; готовый benchmark служит исходным сравнением. Проверенные исходные материалы: сценарий benchmark, сетевые отказы.

Обязательный результат

  • Проверяемый вопрос или утверждение: заявленной гарантии обработки недостаточно для правильного сквозного результата: надёжность существенно меняется с топологией, разбиением данных, параллелизмом и типом отказа.
  • Технический результат: Развернуть локальные Kafka и одну потоковую систему. Самостоятельно реализовать новую оконную топологию и независимый расчёт ожидаемого результата; инфраструктуру PGVal и воспроизводимый источник можно адаптировать. Добавить управляемый отказ, связанный с этапом обработки новой топологии, например недоступность приёмника между закрытием окна и подтверждением записи результата. Общий запуск должен вводить отказ, собирать выход и автоматически сравнивать его с эталоном.
  • Обязательное приращение команды: Самостоятельно реализовать новую оконную топологию и независимый эталон, а также добавить отсутствующий в готовых сценариях отказ, привязанный к этапу обработки этой топологии. Показать отличия от закреплённых топологий и scripts и сопоставить режимы на одинаковых входных событиях.
  • Эксперимент: На одинаковых входных событиях сравнить обычный режим, перезапуск процесса, сетевую задержку и добавленный сценарий по доле правильных результатов, надёжной пропускной способности, задержке и времени восстановления. В отчёте указать, чем новая топология и момент или условие отказа отличаются от готового benchmark; смены значения задержки или процента потерь недостаточно.
  • Границы выводов: сквозная гарантия проверяется для одной потоковой системы, выбранной топологии и заданных отказов; выводы не распространяются на все операторы, конфигурации и крупные кластеры поддерживаемых систем.
  • Ресурсный профиль: Расширенно локально, Docker, CPU, желательно 16 ГБ памяти. Если полный PGVal требует слишком много процессов, оставить Kafka и одну систему на одном компьютере и уменьшить нагрузку, сохранив новую топологию, независимый эталон и перечисленные режимы.

Содержательные направления

  • новая оконная топология и воспроизводимая нагрузка.
  • независимый эталон результата и метрики корректности.
  • новый сценарий отказа, повторные запуски и анализ восстановления.

Возможное продолжение

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

История уточнений

Дата Версия Основание Изменение обязательного результата
07.09.2026 1.1 Статический просмотр закреплённого артефакта: готовые сценарии частично покрывают задание. Закреплены новая оконная топология, независимый эталон и отказ, связанный с этапом её обработки.