Apache Flink для приземления данных из Kafka в HDFS: практика применения

Объем больших данных, которые накапливаются и подлежат аналитике в компаниях, постоянно растет. Для их обработки всё больше ИТ-команд выбирают Apache Flink. Такой гигант, как Alibaba не только использует этот инструмент для своих нужд, но и вкладывает огромные средства в его развитие. Одна из причин в том, что Flink одинаково хорошо поддерживает как пакетную (батчевую), так и потоковую (стриминговую) обработку данных, причем в данном случае батч вырос из стриминга, а не наоборот. Поговорим о более конкретной практической задаче: чтении и записи данных из Kafka в Hadoop Distributed File System (HDFS). Какие фичи Flink позволяют сделать это грамотно и без потери данных, рассказывает дата-инженер компании IT_One Вадим Опольский.

Преимущества Flink

Сценариев применения аналитики Big Data становится всё больше, особенно с распространением IoT-устройств. Для принятия правильного, объективного бизнес-решения необходимо, в первую очередь, сформировать из разных источников слой сырых данных, неоднородных по структуре и объему. Точность аналитики зависит от того, сможем ли мы собрать наиболее полные данные. В этом процессе существует очередь или точка сбора данных (в нашем случае Kafka), откуда они перемещаются в реальном времени в место хранения (HDFS). Одним из способов этого применения является Flink. Альтернативой ему могут стать самостоятельно написанный код (API у Kafka позволяет писать на Python, Java и Scala), а также другие инструменты типа Nifi, Kafka Connect, Kafka Streams, Streamset, Flume, Apache Gobblin. Разберемся, какие преимущества перед ними имеет Flink.

Apache Flink позволяет передать все данные без потерь (далее мы посмотрим, как ему это удается) и реализовать лямбда-архитектуру, которая сегодня наиболее распространена. С помощью Flink формируется слой сырых данных: он читает их из Kafka и пишет в HDFS. Батчевую обработку этих данных впоследствии обеспечат Spark, Hive или другой фреймфорк. Flink также дает возможность реализовать real-time data processing прямо из источника данных, то есть стриминговую обработку.

С точки зрения доступности Flink – это Open Source технология, для ее использования не нужно покупать лицензии на стороннее ПО, а разместить ее можно даже в облаке, не тратясь на соответствующее "железо". Кроме того, API у Flink, с помощью которого описываются пайплайны, так же поддерживает самые популярные языки в среде Big Data – Java, Python и Scala. Это означает, например, что в России, где много Java-разработчиков, компании достаточно легко будет найти специалиста, чтобы выстроить аналитику Big Data таким образом.

Flink поддерживает множество источников данных: не только Kafka, но и реляционные базы данных JDBC, и облачные хранилища S3, и другие источники. Пожалуй, у него могут возникнуть сложности с коннектом к каким-то отечественным базам данных, но эта проблема также решаема. Этот инструмент сегодня набирает популярность среди финансовых организаций, логистических компаний, предприятий ритейла и других отраслей. Это дает возможность предполагать, что Flink будет активно развиваться и дальше.

Трудности "приземления" данных Big Data

Задачу "приземления" данных из Kafka в HDFS с помощью Flink мы рассмотрим на примере бизнес-процесса крупной логистической компании, имеющей более 50 тысяч пунктов выдачи и осуществляющей ежедневно около 2,5 миллионов доставок товаров разными способами. По факту завершения каждой доставки генерируются набор событий (ивенты), общее число которых в сутки достигает 200-400 млн. Эти ивенты и попадают в Kafka. Для того, чтобы построить на их основе аналитику (например, оценка популярности локаций для доставки), необходимо выгрузить эти данные в HDFS и обработать с помощью Spark, Hive, Presto или других фреймворков для работы с данными. Apache Flink, как некая воронка между потоком и базой данных, позволяет прочитать данные из Kafka и записать их в HDFS, минуя различные проблемы, которые встают на этом пути.

К таким проблемам относятся:

• неравномерный поток данных,
• сбой в работе обработчика и, соответственно, потеря данных,
• большой объем данных,
• возникновение очереди на входе (у получателя пропускная способность ниже, чем у источника),
• неконтролируемый размер файлов на выходе.

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

Тестовый стенд, на котором мы можем увидеть указанные преимущества Flink, сделан на Docker Compose и доступен по ссылке: https://github.com/vadopolski/flink-playgrounds.git . Данная конфигурация содержит Client, Generator, Job Manager и Task Manager в Apache Flink, Name Node и Data Node в Kafka. Job Manager работает на отдельной ноде и координирует работу Task Manager, которые распределенно выполняют функции обработки, в том числе и чтение с Kafka. На этом макете можно смоделировать обозначенные выше проблемы, возникающие при передаче данных в хранилище, и устранить их.

Консистентность даннных: продвинутые фичи Flink

Данные, предназначенные для обработки и аналитики, должны оставаться консистентными и не должны пропадать в результате сбоя джобы Flink. Для решения этой проблемы Flink предлагает уникальные функции Checkpoint и Safepoint, а также три варианта стратегии самовосстановления. Цель Checkpoint – обеспечение бесшовного восстановления процесса после сбоя. Это контрольная точка, которая создается после каждого обработанного сообщения. Цель Savepoint такая же, как и у Checkpoint, только такая контрольная точка появляется при ручном останове процесса.

Стратегия самовосстановления позволяет автоматически перезапускать Job Manager при сбое – это важно, например, ночью, когда оперативная поддержка инженеров недоступна. Управлять этой функцией можно различными политиками: Fixed Delay (перезапуск заданное количество раз в заданный промежуток времени), Failure Rate (то же самое, но на определенном интервале) и None (отсутствие перезапуска – для тестировщиков, которым необходимо как можно раньше обнаружить ошибку).

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

Пропускная способность у получателя, то есть у самого Flink, может быть ниже, чем у источника данных. Для решения этой задачи Flink показывает полный статус работы и позволяет мониторить отставание с помощью веб-интерфейсов или отправлять эту информацию на платформу мониторинга типа Grafana. В Flink удобно подключаются метрики: например, LAG для Kafka Consumer.

Неконтролируемый размер файлов на выходе также может стать причиной некорректной работы HDFS. Системы, которые считывают и накапливают данные, могут формировать файлы небольшого размера, каждый из них содержит "обвязку", которую в HDFS придется хранить отдельно, затрачивая лишние ресурсы. Функция File Sink, работает в одном интерфейсе не только со стримингом, но и с батчем. Этот инструмент позволяет задавать стандартные параметры для записи файлов, ограничить данные в одном файле за определенное количество времени (RollOverInterval) и закрывать файл, если в течение какого-то времени данных не приходят (InactivityInterval). Есть также параметр MaxPartSize, который задает границу максимального размера файла.

Сами файлы, или на HDFS, могут находиться в трех состояниях: In-Progress (активно происходит запись), Pending (запись закончилась, но файл еще не внесен в хранилище) и Finished (когда происходит финализация файла). Так Flink поддерживает гибкие настройки ротации файлов для получателя.

Поток данных неравномерен, иногда происходят резкие скачки, влекущие за собой критические нагрузки на ресурсы системы. При использовании Flink такие скачки нивелируются: он использует технологии Akka Streams и Akka Actors, которые позволяют оптимизировать потребление ресурсов при работе с большими нагрузками.

Для решения проблем, возникающих при чтении и записи данных, Apache Flink использует несколько продвинутых функций: распределенную архитектуру, инструментарий Akka, стратегии самовосстанавления без потерь, распределенный режим работы с несколькими уровнями параллелизации, мониторинг, гибкие настройки для получателя. Скачав и запустив тестовый стенд, каждый может убедиться в этом самостоятельно.