Apache Flink для приземления данных из Kafka в HDFS: практика применения
22 нояб 2021 08:40 #106452
от ICT
Объем больших данных, которые накапливаются и подлежат аналитике в компаниях, постоянно растет. Для их обработки всё больше ИТ-команд выбирают 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, минуя различные проблемы, которые встают на этом пути. К таким проблемам относятся:
- неравномерный поток данных,
- сбой в работе обработчика и, соответственно, потеря данных,
- большой объем данных,
- возникновение очереди на входе (у получателя пропускная способность ниже, чем у источника),
- неконтролируемый размер файлов на выходе.
Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.