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

Все эти события реального мира у нас отражаются сообщениями в Кафка. Но эти сообщения кто-то должен получить и обработать, чтобы посылки не терялись. На стороне обработки есть разные задачи:
* нужно писать лог событий. В Кафке у нас JSON или avro, а лог мы пишем в Hadoop, и там нужен ORC или Parquet;
* поверх получаемых данных нужна real-time-аналитика. Например, хочется понимать пропускную способность всей логистической компании;
* нужно сопоставлять факт отправки и получения и поднимать тревогу, если посылка задерживается. Для этого нужно где-то до нескольких дней помнить про отправку.

Для всех этих задач нужно иметь компонент, который делает real-time-обработку и пишет лог. В нашем случае это Apache Flink. Он берет на себя горизонтальное масштабирование обработки, отказоустойчивость и мониторинг.

Но для того чтобы это работало, Flink нужно правильно готовить, иначе можно столкнуться со следующими проблемами:
* на пиках потока данных из источника можно не успеть отмасштабироваться;
* при переносе расчетов с упавшей ноды можно потерять данные;
* на выходе может получиться очень много мелких файлов, это неудобно для HDFS.

В докладе рассмотрим принципы проектирования пайплайнов на основе Flink, которые позволяют забирать и приземлять данные из Kafka максимально безболезненно.