Более того языки как Kotlin, вредны потому что давят на экосистему Scala, в частности по средствам того что утверждают себя как альтернативу, что не так. Оттягивая ресурсы и людей от, лучшего на сегодня выбора — именно лучшего, я так говорю не из-за фанатическое веры в Scala, а потому что Scala это новые мощные абстракции, мощные библиотеки, мощные фреймворки, т.е. в целом инфраструктура
Никогда не бывает ничего абсолютно лучшего, как и абсолютно худшего. Только Ситхи возводят все в абсолют
А по делу, Kotlin очень «мягко» интегрируется с java, поэтому для java разработчиков переход на Kotlin занимает от нескольких часов до недели. Причем переход вместе со всем «experience», наработками, либами и т.п. Scala же это отдельный свой мир. Мое мнение что существующий проект на java легче переписать на scala с нуля, чем частично использовать и то и то. А Kotlin можно легко использовать в существующем, без излишнего пригорания пятой точки. К тому же Kotlin позволяет писать красивый и лаконичный код, близкий к scala.
И что немаловажно, скомпилированный код в Kotlin очень близок к коду java. Тут проще, как мне кажется, понять как его лучше оптимизировать, и скорее всего JIT его лучше оптимизирует (поправьте если ошибаюсь)
Ну а какой язык использовать в новом проекте, это спорный вопрос. Поставьте себя на место тех. дира, и подумайте, из кого вы бы набрали команду? С учетом поиска людей в команду, его поддержки и т.п.
А с сайтами, которые динамически собирают страницу (spa и т.п.), каким образом вы собираете информацию (если не секрет)? На своей стороне полностью рендерите html и потом ее парсите?
Product API извлекает данные о товарах из любого интернет-магазина в любой стране.
Получает название, изображение, цену, валюту и другие характеристики.
Поддерживает любую валюту и язык интернет-магазина, а так же географическое положение.
Попробовал несколько ссылок указать, тот же ссылка. В начале несколько минут было «Ваш запрос обрабатывается..», а потом что превышено время ожидания.
У меня как раз сложилось обратное впечатление, после Eclipse в VS было очень непривычно и неудобно работать (тут думаю на вкус и цвет как говорится..). Но лучше обоих Intellij Idea, ее не пробовали?
А какого порядка размеры кластеров, если не секрет?
Опять же по опыту общения с коллегами из других компаний: запустить Spark на 100 машинах действительно не представляет труда, но вот отмасштабировать его на несколько тысяч, да еще и обеспечить изоляцию между пользователям и гарантировать им хоть что-то, по их словам, пока практически невозможно.
Сотни серверов. Возможно тут Вы и правы, что при масштабировании до нескольких тысяч серверов появляются такие проблемы. Хотя если не рассматривать изоляцию пользователей то может все будет не так уж и плохо…
Отсутствие промежуточной материализации — это конечно плюс, но если working set вычисления помещается в память, то хороший storage layer под MapReduce-системой и так разместит его в памяти
Это при условии хорошего storage layer. Хотя в оригинальном MapReduce все равно каждая операция персистится на диск и причем только в hdfs со всем оверхедом. В Spark операции могут выполняется в памяти либо, если не помещаются, то локально записываться на диск как есть с минимальными издержками.
А вот когда нужно отсортировать петабайт, грубо говоря, то непонятно, чем тут Spark поможет.
Но тут уже смотря какая задача. Если только отсортировать то да. А вот если еще с этим петабайтом нужно много всего сделать (отфильтровать, найти только нужное, изменить как-нибудь, что мне кажется более распространенной задачей) то тут уже Spark может весьма помочь.
Про сложность написания невозможно судить в отрыве от задач. Тем более, что выражать свои мысли совсем не обязательно в MapReduce-терминах, есть и более высокоуровневые средства для описания вычислений (в т.ч. и в Яндексе).
Если сравнивать MapReduce из Hadoop и Spark, то тут для любой задачи куда проще написать на Spark.
Да и сама реализация (если говорить о Spark) еще очень далека до идеала, по крайней мере такие выводы можно сделать из кулуарного общения с теми, кто ее реально применяет.
У нас в компании активно используется Spark, и им полностью довольны. До этого как раз было решение на «классическом Hadoop»
Опять же все мои утверждения по поводу MapReduce могут быть неприменимы к вашей реализации. Поэтому мне и интересно как он у вас устроен внутри.
MapReduce дает оптимальный с точки зрения IO способ обработки больших объемов данных, но ценой значительной латентности (минуты, часы). Stream processing дает возможность сократить латентность до секунд, но заметно дороже в плане IO и CPU и зачастую требует менять сам алгоритм..
Построить сложный алгоритм обработки на MapReduce куда сложнее чем сделать аналогичный при подходе Spark. К тому же не соглашусь что это будет дороже в плане IO и CPU, как раз IO удастся сократить за счет того что часть операций будут выполняться в памяти. А CPU будет в среднем один и тот же.
Может конечно мне не хватает понимания принципов работы вашего MapReduce, поправьте если ошибаюсь.
Вы не могли расписать чуть подробнее, почему выбрали для обработки данных именно MapReduce за основу, вместо того чтобы взять за основу подход Apache Spark?
2) По поводу зависания.
Попробовал аналогичный код, у меня все работает. forEachLine по сути перебирает Sequence из BufferedReader:
public fun File.forEachLine(charset: Charset = Charsets.UTF_8, action: (line: String) -> Unit): Unit {
// Note: close is called at forEachLine
BufferedReader(InputStreamReader(FileInputStream(this), charset)).forEachLine(action)
}
public fun Reader.forEachLine(action: (String) -> Unit): Unit = useLines { it.forEach(action) }
public inline fun <T> Reader.useLines(block: (Sequence<String>) -> T): T =
buffered().use { block(it.lineSequence()) }
public inline fun Reader.buffered(bufferSize: Int = DEFAULT_BUFFER_SIZE): BufferedReader
= if (this is BufferedReader) this else BufferedReader(this, bufferSize)
public inline fun <T> Sequence<T>.forEach(action: (T) -> Unit): Unit {
for (element in this) action(element)
}
public fun BufferedReader.lineSequence(): Sequence<String> = LinesSequence(this).constrainOnce()
Думаю что у вас проблема не в Kotlin, а в чем-то другом.
reified type parameters связаны как раз именно с инлайном
C инлайном, насколько я понимаю, они связаны из-за того, что для обычных функций такой трюк не работает, поэтому такая возможность есть только для inline.
TypeTag это вообще вроде как фича из рефлекшена
Из рефлекшена, но в итоге TypeTag в Scala позволяет «прокидывать» информацию о типе в рантайм. Reified type в Kotlin делает примерно тоже самое.
то в статье не упомянули про инлайн функций и reified type parameters
inline все же в scala есть считай из «коробки», а вместо reified type есть TypeTag (если не путаю) с большим функционалом.
Основное преимущество Kotlin в его времени компиляции (в теории можно довести до уровня Java), интеропе с Java (нет отдельного мира с коллекциями как в Scala) и удобном наборе возможностей языка, достаточным для продуктивной работы. Тот же DSL на extension функциях/параметрах можно сделать очень даже просто.
Также чуть позже должна появиться возможность использовать «Destructuring Declarations» в when, тогда станет еще проще.
Но то что полноценный pattern matching нужен, тут я с вами согласен. Но это пожалуй единственная вещь который не хватает в Kotlin. И совокупное впечатление от языка только положительное.
Никогда не бывает ничего абсолютно лучшего, как и абсолютно худшего.
Только Ситхи возводят все в абсолютА по делу, Kotlin очень «мягко» интегрируется с java, поэтому для java разработчиков переход на Kotlin занимает от нескольких часов до недели. Причем переход вместе со всем «experience», наработками, либами и т.п. Scala же это отдельный свой мир. Мое мнение что существующий проект на java легче переписать на scala с нуля, чем частично использовать и то и то. А Kotlin можно легко использовать в существующем, без излишнего пригорания пятой точки. К тому же Kotlin позволяет писать красивый и лаконичный код, близкий к scala.
И что немаловажно, скомпилированный код в Kotlin очень близок к коду java. Тут проще, как мне кажется, понять как его лучше оптимизировать, и скорее всего JIT его лучше оптимизирует (поправьте если ошибаюсь)
Ну а какой язык использовать в новом проекте, это спорный вопрос. Поставьте себя на место тех. дира, и подумайте, из кого вы бы набрали команду? С учетом поиска людей в команду, его поддержки и т.п.
Попробовал несколько ссылок указать, тот же ссылка. В начале несколько минут было «Ваш запрос обрабатывается..», а потом что превышено время ожидания.
Сотни серверов. Возможно тут Вы и правы, что при масштабировании до нескольких тысяч серверов появляются такие проблемы. Хотя если не рассматривать изоляцию пользователей то может все будет не так уж и плохо…
Это при условии хорошего storage layer. Хотя в оригинальном MapReduce все равно каждая операция персистится на диск и причем только в hdfs со всем оверхедом. В Spark операции могут выполняется в памяти либо, если не помещаются, то локально записываться на диск как есть с минимальными издержками.
Но тут уже смотря какая задача. Если только отсортировать то да. А вот если еще с этим петабайтом нужно много всего сделать (отфильтровать, найти только нужное, изменить как-нибудь, что мне кажется более распространенной задачей) то тут уже Spark может весьма помочь.
Если сравнивать MapReduce из Hadoop и Spark, то тут для любой задачи куда проще написать на Spark.
У нас в компании активно используется Spark, и им полностью довольны. До этого как раз было решение на «классическом Hadoop»
Опять же все мои утверждения по поводу MapReduce могут быть неприменимы к вашей реализации. Поэтому мне и интересно как он у вас устроен внутри.
Построить сложный алгоритм обработки на MapReduce куда сложнее чем сделать аналогичный при подходе Spark. К тому же не соглашусь что это будет дороже в плане IO и CPU, как раз IO удастся сократить за счет того что часть операций будут выполняться в памяти. А CPU будет в среднем один и тот же.
Может конечно мне не хватает понимания принципов работы вашего MapReduce, поправьте если ошибаюсь.
Это как раз в Kotlin есть
2) По поводу зависания.
Попробовал аналогичный код, у меня все работает. forEachLine по сути перебирает Sequence из BufferedReader:
Думаю что у вас проблема не в Kotlin, а в чем-то другом.
C инлайном, насколько я понимаю, они связаны из-за того, что для обычных функций такой трюк не работает, поэтому такая возможность есть только для inline.
Из рефлекшена, но в итоге TypeTag в Scala позволяет «прокидывать» информацию о типе в рантайм. Reified type в Kotlin делает примерно тоже самое.
inline все же в scala есть считай из «коробки», а вместо reified type есть TypeTag (если не путаю) с большим функционалом.
Основное преимущество Kotlin в его времени компиляции (в теории можно довести до уровня Java), интеропе с Java (нет отдельного мира с коллекциями как в Scala) и удобном наборе возможностей языка, достаточным для продуктивной работы. Тот же DSL на extension функциях/параметрах можно сделать очень даже просто.
Можете привести примеры кода?
when в Kotlin это switch на стероидах. Он, конечно, полноценно не может заменить pattern matching, но с ним можно жить.
Ниже несколько примеров:
Также чуть позже должна появиться возможность использовать «Destructuring Declarations» в when, тогда станет еще проще.
Но то что полноценный pattern matching нужен, тут я с вами согласен. Но это пожалуй единственная вещь который не хватает в Kotlin. И совокупное впечатление от языка только положительное.