flink streaming или пакетная обработка

Question

Мне поручено перепроектировать существующий процессор для каталога, и требование идет как ниже. Требования: у меня есть от 5 до 10 поставщиков (каждый поставщик может иметь несколько магазинов), которые предоставили мне файл «XML» для каждого магазина. В основном, 1 файл xml файла для Магазина и несколько файлов Store для каждого Продавца. Максимальный размер файла может быть 500 Мбайт, а мин может быть 100 МБ. Средство для каждого файла может быть 100 000.

Пример формата XML может быть, как это ... ... ...

Оно не займет более 30 минут, чтобы загрузить файл на хранилище, и эти файлы обновляются один раз в день или каждые 3 6 часов.

В настоящее время приоритетным требованием является то, что детали продукта являются крайне неорганизованными, и эти файлы должны быть организованы, обработаны (10+ процессов) и преобразованы в другой общий объект (json), а затем файл, хранящийся в Cassandra.

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

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

Мой вопрос заключается в том, что, зная, что файлы имеют конечный размер и конечный счет, невосприимчивый к числу продавцов, будет ли обработка потока излишним или пакетная обработка будет латентной нагрузкой позже?

Answer 1

Вопрос сильно зависит от инструмента, который вы будете использовать. Если вы идете на Flink, я считаю, что использование потока в порядке и не создаст проблемы в долгосрочной перспективе. Если вы правильно напишете свои функции и задания, переход с DataStream API на DataSet API будет легким, если потребуется. Пакет здесь вводит бесполезную задержку и без дополнительной информации не кажется подходящим подходом. Я считаю, что все равно будет работать нормально, но неясно, является ли латентность строгим требованием.

Это, я считаю, Флинк сам по себе является излишним. В этом конкретном случае использования более традиционный, такой как Spark, был бы лучшим вариантом с точки зрения удобства использования, но если вы хотите инвестировать в Flink, это совершенно нормально и с учетом использования, я не думаю, что вам понадобится какая-либо конкретная библиотека, которая присутствует/интегрирован с искровым светом, но отсутствует на Flink.