- **Основная статья:** Paris Carbone и соавт. — [Apache Flink: Stream and Batch Processing in a Single Engine](https://asterios.katsifodimos.com/assets/publications/flink-deb.pdf). IEEE Data Engineering Bulletin 2015, 11 страниц.
- **Кратко о статье:** Apache Flink объединяет потоковую и пакетную обработку в общем распределённом движке с состоянием операторов. Для согласованного восстановления система строит распределённые снимки состояния, не останавливая весь поток обработки. В этом проекте сравниваются режимы контрольных точек по накладным расходам, задержке и времени exactly-once-восстановления.
- **Почему результат актуален:** исходная статья описывает раннюю архитектуру, но система стала устойчивой отраслевой платформой и продолжает активно развиваться; [Flink 2.3.0](https://flink.apache.org/2026/06/25/apache-flink-2.3.0-release-announcement/) выпущен в июне 2026 года. Проект использует современную фиксированную версию и проверяет сохраняющийся механизм распределённых контрольных точек.
- **Артефакты и данные:** [apache/flink](https://github.com/apache/flink) под Apache-2.0; доступны актуальная стабильная ветвь, отдельная LTS-ветвь и [официальный локальный режим](https://nightlies.apache.org/flink/flink-docs-stable/docs/getting-started/local_installation/) без обязательного облака. Зафиксированные ревизии: `apache/flink@81389aca7136` (Apache-2.0).
- **Что уже предоставляет артефакт:** Flink уже реализует stateful-обработку, выровненные и невыровненные checkpoint, метрики и восстановление. Движок и локальное развёртывание разрешено использовать как основу.
- **Проверяемый вопрос или утверждение:** асинхронные контрольные точки обеспечивают exactly-once-восстановление состояния с измеримым компромиссом между накладными расходами, задержкой обработки и временем восстановления после отказа.
- **Технический результат:** Построить stateful-конвейер Flink с повторяемым источником, уникальными идентификаторами событий, файловым приёмником и автоматической проверкой эквивалентности результатов. Автоматизировать противодавление и отказ TaskManager.
- **Обязательное приращение команды:** Создать предусмотренный конвейер с повторяемыми событиями и файловым приёмником, автоматизировать противодавление и отказ TaskManager и самостоятельно проверять выходные идентификаторы и агрегаты. Провести сопоставимые серии двух режимов checkpoint.
- **Эксперимент:** Сравнить выровненные и невыровненные контрольные точки при двух уровнях противодавления и одном отказе. Измерить throughput, p95/p99, длительность и размер checkpoint, время восстановления, пропуски, дубликаты и ошибки агрегатов; выполнить не менее трёх серий.
- **Границы выводов:** накладные расходы и exactly-once-восстановление проверяются для одного локального конвейера, двух режимов противодавления и отказа TaskManager; результат не охватывает внешние источники и приёмники или крупный кластер.
- **Ресурсный профиль:** одна машина, CPU, 4–8 ГБ памяти и локальная файловая система; Docker и облако необязательны. При нехватке памяти уменьшаются параллелизм и состояние, но сохраняются отдельные процессы, контрольные точки, отказ и автоматическая проверка корректности.
## Содержательные направления
- нагрузка и эталон корректности.
- отказоустойчивость, контрольные точки и инструментирование.
- экспериментальные серии, статистический анализ и собственное расширение.
## Возможное продолжение
Варьировать размер состояния и период контрольных точек, исследовать savepoint и rescaling, сравнить хранилища состояния либо предложить политику переключения режима при противодавлении.
