spark-on-kubernetes

[Сабина]

Это как альтернативе spark-on-yarn
Посмотрела презентацию на Scale of the Bay, очень впечатлило.
Прилагаю слайды

Интересно делает ли кто нибудь что похожее

[iDesperado]

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

[Сабина]

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

"хадуп запускает спарк экзекьютеры там где данные, а в варианте k8s своего сториджа не предполагается".

Не поняла. local SSDs тоже есть, но в идеале надо побольше workers (tune pod sizing etc) правильную partitioning to minimize shuffle.
Если уж сравнивать то этот spark-on-kubernetes с Dataproc

[iDesperado]

Не поняла. local SSDs тоже есть, но в идеале надо побольше workers (tune pod sizing etc) правильную partitioning to minimize shuffle.

речь про data locality
https://www.programmersought.com/article/79962500149/

local ssd, это про хранение промежуточных данных между стадиями. по мне так основная проблема в том, что k8s вынужден данные каждый раз перекачивать (с внешнего сториджа).

Если уж сравнивать то этот spark-on-kubernetes с Dataproc

так они с ним и сравнивали. но данные dataproc брал не со своего hdfs, а с google stotage. сомневаюсь что кто-то так будет использовать hadoop на задачах аля tpc-ds

[Сабина]

Не знаю где disconnect но GCS это основной способ хранения данных для Dataproc Spark jobs. На этом же практически вся Big Data/ML/AI в гуглоклауде построено.
Кластер он эфемерный по сути что Dataproc что Кубернетис, никто там не хранит результат обработки

Data Locality - это принцип task scheduling и тут ничего нового, многие дистрибутивные системы по такому принципу так работают.
Но речь тут идёт о данных которые уже вычитаны скопированы в кластер для выполнения. Или промежуточные результаты. А дальше только that much you can do to tune it - allocate proper memory, прикрутить адекватный быстрый диск на случай spill, adjust partitioning, minimise shuffle etc. И рекламируемый manager ( Кубернетис) якобы справляется лучше Yarn с ситуациями когда экзекьютор ушёл в туман из-за persistent socket timeout или OOM, безотносительно data locality - это вообще separate concern.
Запуск экзекторов внутри контейнера ничего в этом по сути не меняет.

[iDesperado]

Не знаю где disconnect но GCS это основной способ хранения данных для Dataproc Spark jobs.

а кто-то использует dataproc в связке со спарк ? какой смысл поднимать целый хадуп кластер, если в aws и azure спарк джобы можно гонять в severless варианте ? какой смысл оплачивать поднятие dataproc/hadoop кластера ?

На этом же практически вся Big Data/ML/AI в гуглоклауде построено.

https://cloud.google.com/ai-platform
что-то не заметно. выглядит что упор на bigquery и tensorflow кластер, без всяких спарков и хадупов.

Data Locality - это принцип task scheduling и тут ничего нового, многие дистрибутивные системы по такому принципу так работают.
Но речь тут идёт о данных которые уже вычитаны скопированы в кластер для выполнения. Или промежуточные результаты. А дальше только that much you can do to tune it - allocate proper memory, прикрутить адекватный быстрый диск на случай spill, adjust partitioning, minimise shuffle etc. И рекламируемый manager ( Кубернетис) якобы справляется лучше Yarn с ситуациями когда экзекьютор ушёл в туман из-за persistent socket timeout или OOM, безотносительно data locality - это вообще separate concern.
Запуск экзекторов внутри контейнера ничего в этом по сути не меняет.

когда экзекьютор читает локальный hdfs блок с локального дика и в той же jvm обрабатывает это меняет суть.

[Сабина]

Уверена что в ажурном облаке свои нюансы, и кому то можно начхать на Спарк и для их задач хватает ноутбуков. Мне же интересно про нормальный рабочий BigData setup для GCP, в частности сравнивал ли кто spark-on-Kubernetes с Dataproc