И вообще какое-то неинженерное вознесение спарка, это популярный тул для написания пакетной логики над данными в объектном сторадже и (сильно хуже) в стриминге, но у него же море проблем: нет своего каталога и беда со статистикой от этого (и тормоза на ad-hoc analytics), отношения на Вы с ресурсными менеджерами (отсюда проблемы с памятью и преемпшеном, в том числе беда с интеграционным задачами) и не говоря про метаданные и модель безопасности самого движка (column/row level security?); нормальный инструмент чтобы вытеснить Pig/Hive для пакетных задач, но не более того..

умеет хайвовым каталогом пользоваться

из ресурс менеджеров, он же практически все поддерживает

что есть на рынке

спарк - фреймворк, а не продукт

да, главное всегда помнить об этом, плюсую

+

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

я не писал что он не поддерживает, я написал что "на Вы", то есть работа по настройке конкретного приложения на конкретный менеджер ложится на пользователя: как запросить памяти и ядер так чтобы их оптимально использовать, как избежать OoM или preemption там где логика приложения его не допускает..

так и хайв и престо это фреймворки, в чем поинт то?

я ток не понимаю, чем концептуально хайв лучше спарка или о чем у вас разговор?

шо то шо то одного поля ягоды

никто ж не топит за хайв

разговор про какое-то не очень техническое коленопреклонение перед спарком, я пытаюсь показать что это просто один из инструментов, а не the best thing since sliced bread

надеюсь

ну мы ж инженеры; сильные мнения пфф

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

зачем удалили, вопрос вроде про биг дату был

Проверил, маленькая дата