Кубернетес против Искры против Искры на Кубернетес

Question

Итак, у меня есть сценарий использования, когда я буду передавать около 1000 записей в минуту с kafka. Мне просто нужно вывести эти записи в необработанном виде в нет sql дБ или что-то вроде озера данных в этом отношении, я выполнил это с помощью двух подходов

Подход 1 —————————— Создайте потребителей kafka в java и запускайте их как три разных контейнера в kubernetes. Поскольку все контейнеры находятся в одной и той же группе потребителей kafka, все они будут способствовать чтению из одной и той же kafka topi c и выгружать данные в озеро данных. Это работает довольно быстро для объема рабочей нагрузки, который у меня есть

Подход 2 ——————————- Затем я создал искровой кластер и тот же java logi c для чтения из Кафка и данные дампа в озере данных

Наблюдения ———————————- Производительность kubernetes, если неплохо, была равна производительности искрового задания, работающего в кластерном режиме.

Итак, мой вопрос: каков реальный вариант использования искры над кубернетами так, как я ее использую, или даже искры над кубернетами? Искра будет только подниматься и освещать гораздо более тяжелые рабочие нагрузки, скажем, порядка 50 000 записей в минуту или случаи, когда необходимо выполнить некоторую обработку данных в реальном времени, прежде чем выгрузить их в приемник? С Spark связано больше затрат, поэтому мне нужно убедиться, что я использую его только в том случае, если он масштабируется лучше, чем решение для лечения туберкулеза

Answer 1

Запускать kafka внутри Kubernetes рекомендуется только в том случае, если у вас есть большой опыт в этом, поскольку Kubernetes не знает, что на нем размещается Spark, а Spark не знает, как он работает в Kubernetes, вам нужно будет дважды проверить каждую функцию, которую вы решите запустить.

Для вашей рабочей нагрузки я бы рекомендовал придерживаться Kubernetes. Эластичность, производительность, инструменты мониторинга и функции планирования, а также огромная поддержка сообщества значительно расширяют возможности в долгосрочной перспективе.

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

Answer 2

Если ваш случай только для архивации / снимка / записи дампа, я бы порекомендовал вам посмотреть Kafka Connect .

Если вам нужно обработать записи, которые вы передаете, например. агрегируйте или объединяйте потоки, затем Spark входит в игру. Также для этого случая вы можете взглянуть на Kafka Streams .

Каждая из этих платформ имеет свои собственные компромиссы и издержки производительности, но в любом случае вы экономите много усилий на разработке, используя инструменты, предназначенные для это вместо того, чтобы развивать своих собственных потребителей. Также эти платформы уже поддерживают большую часть обработки сбоев, масштабирования и настраиваемой семантики. Также у них достаточно опций конфигурации, чтобы настроить поведение в большинстве случаев, которые вы можете себе представить. Просто выберите доступную интеграцию, и вы готовы к go! И, конечно, остерегайтесь ошибок с открытым исходным кодом;).

Надеюсь, это поможет.