Оверхед всегда надо увеличивать дефолтный параметр. Про это есть даже тикет в Spark Jira. Для scala меньше увеличивать для Python сильно больше. И с этим надо смириться))
А то будешь как одна команда у одного из моих бывших работодателей — выкинули спарк отчасти потому что не смогли найти причину почему он внезапно падает без всяких причин. А ответ оказался в NodeManager логах — yarn прибивал контейнер текущий по памяти.
Кажется что когда есть метрики схожести между вершинами кластеризация по этим метрикам первична, а по графовой состовляющей вторична. Так что это не идеальный пример
semi-clustering — такой вид кластеризации, когда вершина может принадлежать сразу нескольким кластерам. все статьи по кластеризации соц сеточек, которые я читал юзают только этот метод
Выделение сообществ в социальных сетях
Задача, которую сложно отнести к какому-то конкретному задач. Зачастую она рассматривается в контексте задачи «кластеризации на графах». Методов решения тут масса — от простого выделения компонент связности (алгоритм упоминался выше) при правильно определенном подмножестве вершин, до последовательного удаления ребер из графа до тех пор пока не останется нужная компонента. Здесь, опять же — очень важно сперва понимать, какие именно сообщества мы хотим выделять в сети, т.е. сперва поработать с описанием вершин и ребер, а уже потом думать, как в полученном подграфе выделять сами сообщества.
Занимался я таким в Яндексе для одного проекта на GraphX. Первое что тут надо понимать — что тут речь не о graph clustering, а graph semi-clustering. В Pregel есть описание semi-clustering алгоритма, но для больших групп он должен падать по OOM. Это мое прочтение — информации в инете по практики реализации его совсем нету.
Нахождение компонент связанности не поможет никак, ибо все сильно связано и каждая вершина всегда принадлежит множеству кластеров. Задача — найти какому кластеру в какой степени.
На эту тему есть несколько white paper но они очень теоритические без проверки работы алгоритма на больших данных.
Я все сделал на pregel модели, с самопальным алгоритмом — разбросать k центров кластеров по крупнейшим группам в вк(соц графф был из ВК) и на каждой итерации красить соседние вершины. А вершины красят дальше. Проверить эффективность не получилось нормально — я принадлежность кластерам использовал как feature set для machine learning и эти кластера не дали дополнительного сигнала. Почему не дали, я не понял, то ли кластеры не так важны, то ли я нашел их плохо, то ли шума много в данных.
Если кому код понадобитсья — я могу у себя поискать. Он не под NDA, так как я его на выходных по своей инициативе писал
Computational model другая, а API действительно прегелевской. не могу сказать за сигнатуры, ибо процесс мапинья google white paper на scala сигнатуры — процесс творческий и насколько они точь в точь, сказать сложно.
Мне кажется здесь важно понимать и подчеркнуть, что GraphX не может рассматривать как идеальный implementation of pregel по причине того, что он не гарантирует вычислительную модель а значит и свойства pregel. Если внимательно читать Pregel часть graphx то можно увидеть, что он писался 2-3 людьми и использовался в 2 example. Это очень очень очень молодая фигня
В индустрии не известно не одного случая использования GraphX для работы с реально большими графами. Чтобы в этом убедиться достаточно просмотреть Spark Summitы за последние 3 года и почитать блог DataBricks(компания коммерциализруящая спарк).
Более того, конкретно с Pregel оберткой в dev-list существует описание проблемы, что при большом кол-во итерации на больших данных каждая следующая итерация исполняется дольше. Лично мне не удавалось сделать более 100 итераций на 1 гб. Я связываю это с большим кол-вом presist unpersist в pregel обертке, но это на уровне гипотезы.
(известными инструментами, являются, например, GraphLab — нынешний Dato.com или Pregel — на котором GraphX и основан)
не верно: Pregel не инструмент, а computational model, потому что существует только в виде white paper. GraphX никак не основан на Pregel. Для pregel в graphx есть один класс обертки, который реализует pregel API, при этом что computational model совсем не pregelевская.
Фантастика я думаю, чаще всего по определению не может быть простой. Там либо научные термины, либо политические(как в Вавилон 5) обычно обязательно присутвуют. Хотя тот же «лост» в какой-то мере фантастика, а довольно прост.
Теперь стало понятно на что пошли частично деньги от IPO. А некоторые урезания бюджетов по ряду направлений в яндексе в последнее время заставляли беспокоится.
Все авторы комментов выше, говорят, что на сериалах нельзя выучиться языку, ибо нельзя выучиться грамматике. Вы на русском хорошо говорили еще до того, как пошли в школу, начали изучать грамматику и узнали слова «глагол» или «подлежащие». Почему так же не может произойти в англиском? Меня преподаватель мучил 16 английскими временами и для меня мука был все их употреблять. После 2 лет просто просмотра сериалов я могу говорить на 6-7 временах, но мне думать при этом не надо вовсе. Для нормального тойфеля этого хватит. Так может меньше зубрить и больше смотреть?
А то будешь как одна команда у одного из моих бывших работодателей — выкинули спарк отчасти потому что не смогли найти причину почему он внезапно падает без всяких причин. А ответ оказался в NodeManager логах — yarn прибивал контейнер текущий по памяти.
Занимался я таким в Яндексе для одного проекта на GraphX. Первое что тут надо понимать — что тут речь не о graph clustering, а graph semi-clustering. В Pregel есть описание semi-clustering алгоритма, но для больших групп он должен падать по OOM. Это мое прочтение — информации в инете по практики реализации его совсем нету.
Нахождение компонент связанности не поможет никак, ибо все сильно связано и каждая вершина всегда принадлежит множеству кластеров. Задача — найти какому кластеру в какой степени.
На эту тему есть несколько white paper но они очень теоритические без проверки работы алгоритма на больших данных.
Я все сделал на pregel модели, с самопальным алгоритмом — разбросать k центров кластеров по крупнейшим группам в вк(соц графф был из ВК) и на каждой итерации красить соседние вершины. А вершины красят дальше. Проверить эффективность не получилось нормально — я принадлежность кластерам использовал как feature set для machine learning и эти кластера не дали дополнительного сигнала. Почему не дали, я не понял, то ли кластеры не так важны, то ли я нашел их плохо, то ли шума много в данных.
Если кому код понадобитсья — я могу у себя поискать. Он не под NDA, так как я его на выходных по своей инициативе писал
Мне кажется здесь важно понимать и подчеркнуть, что GraphX не может рассматривать как идеальный implementation of pregel по причине того, что он не гарантирует вычислительную модель а значит и свойства pregel. Если внимательно читать Pregel часть graphx то можно увидеть, что он писался 2-3 людьми и использовался в 2 example. Это очень очень очень молодая фигня
Более того, конкретно с Pregel оберткой в dev-list существует описание проблемы, что при большом кол-во итерации на больших данных каждая следующая итерация исполняется дольше. Лично мне не удавалось сделать более 100 итераций на 1 гб. Я связываю это с большим кол-вом presist unpersist в pregel обертке, но это на уровне гипотезы.
не верно: Pregel не инструмент, а computational model, потому что существует только в виде white paper. GraphX никак не основан на Pregel. Для pregel в graphx есть один класс обертки, который реализует pregel API, при этом что computational model совсем не pregelевская.