Как стать автором
Обновить

Комментарии 10

Стоит добавить, что расплата за высокую производительность Spark - требования к объему оперативной памяти.

Вообще говоря — нет. Спарк много чего умеет, и производительность достигается разными способами.

Прежде всего спарк — это оптимизатор, который достаточно умный, чтобы понимать, что имеющиеся данные обладают определенными характеристиками, например, партиционированы, и способен строить планы соответствующим образом. И в итоге скажем предикат вида a=123 будет выполнен на уровне HDFS, т.е. спарк будет обрабатывать только файлы из папки ../a=123/*, понимая, что это партиция таблицы, и только она нам и нужна. А файлы эти (список) он получит у namenode, не просматривая физические диски.

И где вы тут видите другие требования к оперативной памяти?

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

я не так давно искал разницу между табличкой и ее бэкапом размером гигов 60, пришлось выкручивать до 6G memory и 4G overhead

Вы ощущаете разницу между «бывают проблемы, если налицо перекос», и «спарк потребляет больше памяти» (без какого-либо уточнения, когда и зачем)?

>в случае джойна у оптимизатора не хватает ума предсказать какого размера окажется партиция 123
В случае map reduce вам вообще придется забыть о том, что существуют какие-то там join, потому что в нем нет такого механизма. А в случае спарка вы вполне сможете запрограммировать оценку размера сами, и выбрать другой алгоритм для джойна, или репартиционировать данные перед ним.

Речь о том, что у спарка нет никакого врожденного высокого потребления памяти. А есть скорее умение имеющуюся в наличии память использовать, чтобы увеличивать производительность. Да, бывает что это чревато ООМ. Но говорить что спарк всегда потребляет больше памяти? Чем что? Чем mapreduce? Так сначала надо тоже самое на оном запрограммировать (что будет далеко нетривиально в общем случае), и еще далеко не факт, что самописная реализация на mapreduce не выжрет памяти еще больше).

выглядит, что вы совершенно не понимаете предмет. переджоинить данные в map-reduce геморно, но никогда не было непреодолимым препятствием. в книгах разжевываются с десяток стратегий для MR. да, стратегию подбирают под задачу, это не будет каким-то общим, но практически гарантированно по памяти нет нужны затягивать целую партицию, как это делает спарк. в MR редюсер вычитывает строку и это up to you как потратить память. затягивать все в подавляющем большинстве случаев не нужно. вот как с моей задачей сравнения с бэкапом, MR более двух строк в принципе в памяти не требуется, а спарк зачем-то пытается засосать десяток гигов и упасть.

>выглядит, что вы совершенно не понимаете предмет.
Скорее вы не пытаетесь понять, о чем я говорю. В API mapreduce нет понятия join, в отличие от спарка, где это можно сделать как через dataset, так и через SQL.

Разумеется, вы можете сделать join по факту, хоть на ассемблере. Но делать вы скорее всего будете все теми же стратегиями, т.е. Nested Loop, Hash Join, или Sort-Merge, или еще какая-то (просто потому, что ничего нового тут не придумано практически со времен публикации Исскусства программирования) — и ни одна из них не будет оптимальна для любой задачи, любого размера и распределения датасета. И делая join врукопашную, вы точно так же имеете возможность накосячить, как оптимизатор спарка — ну или затратить на реализацию кучу своего времени, потому что API mapreduce по сравнению со спарком сильно ниже уровнем.

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

А уж выбирать, что вам важнее, ваше время или память железки — только вам.

простите но вы говорите не понятную ерунду. спарк это по сути высокоуровневая надстройка над MR, у которой стратегия - зачитывать в память и все операции проводить в памяти. товарищ выше свершено прав - расплата за мощь и универсальность спарка - память. что вы пытаетесь доказать противопоставляя низкоуровневому MR не понятно.

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

У меня в проме спокойно джойнятся терабайтовые датасеты без всякого ООМ. А у вас проблемы на 60 гигабайтах. Ну и с чего я должен верить вам, а не своему опыту?

Как хранятся файлы? Или как получать эти файлы? А может, сразу — как анализировать данные? Читайте подробнее под катом.

Но ничего этого под катом нет.

конечно немного офтоп но что то у вас там совсем не так с HR

Диана Андреева, [26.08.21 11:56] Добрый день, Михаил! К сожалению, придется отменить интервью по позиции Системного администратора в Quadcode. Пока что коллеги не готовы рассмотреть вашу кандидатуру, так как общались только в мае. Если что-то изменится, мы с вами свяжемся! Спасибо большое за уделенное время!

Mishka Ivashka, [26.08.21 12:01] В Мае?? Вы что то путаете )), ну ладно

Диана Андреева, [26.08.21 12:04] Не знаю, мне коллеги передали просто) спасибо)

Mishka Ivashka, [26.08.21 12:06] Там приходили за админ openstak , а тут нужна Voip админ это разные позиции , ваши коллеги просто перепутали

Диана Андреева, [26.08.21 12:07] Да. всё верно. Коллеги не перепутали, просто мало прошло времени, когда можно снова в одну и ту же компанию собеседоваться.

Mishka Ivashka, [26.08.21 12:08] Бред , какой-то , я не собеседовался, ладно, выложу на хабр , пусть народ рассудить

Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.