Кстати, вроде как в SparkR 2.0.0 они реализовали «синтаксис манипулирования данными» аналогичный к dplyr о чём они пишут в документации: https://spark.apache.org/docs/latest/sparkr.html (...similar to R data frames, dplyr) И возможно уже SparkR и не является настолько неудобным? Если Я правильно понял, то как раз реализация интерфейса, аналогичного с dplyr, и наличия разработок в пакете sparklyr, как раз и позволят относительно легко и быстро реализовать необходимые модели МО и недостающего функционала в SparkR. Очень хотелось бы иметь решение в виде одной целестной экосистемы. Как Я понял мы наблюдаем борьбу двух стандартов: Экосистема вокруг RStudio и экосистема распределённых вычислений на базе Hadoop.
Как Вы думаете есть ли смысл ожидать, что большинство кода с этого пакета послужит основой для существенного расширения списка доступных моделей в SparkR? Ведь работы над SparkR ведутся давно и вроде как поддержка этого проекта такой компанией как RStudio являлось бы хорошим стимулом к развитию. Вместо этого мы видим отдельный продукт, который повторяет цели уже существующего Open source решения.
А что Вы можете сказать по поводу удобства построения моделей на Spark c помощью языка Scala, Java или Python? Ведь, сюдя по документации, все перечисленные модели (Linear regression, logistic regression, Survival regression, Decision trees, Random forests, Gradient-Boosted Trees, Principal component analysis, Multilayer perceptron, Latent Dirichlet allocation, One-vs-Rest classifier) там реализованы.
Ссылки на документацию:
http://spark.apache.org/docs/latest/ml-classification-regression.html
http://spark.apache.org/docs/latest/mllib-ensembles.html
http://spark.apache.org/docs/latest/mllib-dimensionality-reduction.html
Тоесть метод indexBy выполняет лишь пост сортировку результатов выполнения запроса в базе?
Выходит, что бесмысленно использовать вместе методы orderBy и indexBy. Вроде как оба сортируют результат выборки, но… есть нюанс))
«для указания сложных индексов, вы можете передать в метод Jii.sql.Query.indexBy() анонимную функцию:… return row.id + row.username; „
А можете подробней расказать в каких случаях будет полезным использование таких кастомных индексов?
имхо:
Конструкции вида: “ORDER BY ((c_sent + 1) * online_coef * geo_coef * search_coef * premium_coef) ASC» хоть синтаксически правельны, но… мне жалко MySQL ((. Считаю, что такие конструкции в запросе нужно использовать «с пониманием» и если это действительно очень необходимо. Пока к сожалению я не придумал реальных случаев, когда это может быть полезным.
Ссылки на документацию:
http://spark.apache.org/docs/latest/ml-classification-regression.html
http://spark.apache.org/docs/latest/mllib-ensembles.html
http://spark.apache.org/docs/latest/mllib-dimensionality-reduction.html
Выходит, что бесмысленно использовать вместе методы orderBy и indexBy. Вроде как оба сортируют результат выборки, но… есть нюанс))
А можете подробней расказать в каких случаях будет полезным использование таких кастомных индексов?
имхо:
Конструкции вида: “ORDER BY ((c_sent + 1) * online_coef * geo_coef * search_coef * premium_coef) ASC» хоть синтаксически правельны, но… мне жалко MySQL ((. Считаю, что такие конструкции в запросе нужно использовать «с пониманием» и если это действительно очень необходимо. Пока к сожалению я не придумал реальных случаев, когда это может быть полезным.