Comments 12
Спасибо за отличную статью!
А можно поподробнее про непонятную поддержку коннектора для Кассандры? Пользуюсь этим коннектором для чтения, вроде все нормально.
А можно поподробнее про непонятную поддержку коннектора для Кассандры? Пользуюсь этим коннектором для чтения, вроде все нормально.
Спасибо!
Не было много времени разбираться с коннектором — была надежда, что заработает хорошо из коробки. С чем столкнулись:
1. Не смогли собрать .jar чтобы не конфликтовал с Spark SQL, поэтому сразу вылетел SQL функционал
2. Ладно, для начала SQL не нужен был — перелопачиваем все таблицы. Делаем RDD, читаем, сохраняем в HDFS.
2.1. На одном узле все отлично.
2.2. На кластере вылетает с ошибкой, что файл уже существует на HDFS.
3. Ок, сохранять в HDFS нам и не нужно — читаем, map, пишем обратно:
3.1. На одном узле работает отлично
3.2. На кластере — job выполняется успешно, без ошибок. Ничего в Кассандру не попадает. Это вообще кошмар. Особенно то, что Spark рапортует, что все успешно.
В общем пока поставили на паузу. Появится время — вернемся к этому вопросу. Но вообще впечатление нехорошее
Не было много времени разбираться с коннектором — была надежда, что заработает хорошо из коробки. С чем столкнулись:
1. Не смогли собрать .jar чтобы не конфликтовал с Spark SQL, поэтому сразу вылетел SQL функционал
2. Ладно, для начала SQL не нужен был — перелопачиваем все таблицы. Делаем RDD, читаем, сохраняем в HDFS.
2.1. На одном узле все отлично.
2.2. На кластере вылетает с ошибкой, что файл уже существует на HDFS.
3. Ок, сохранять в HDFS нам и не нужно — читаем, map, пишем обратно:
3.1. На одном узле работает отлично
3.2. На кластере — job выполняется успешно, без ошибок. Ничего в Кассандру не попадает. Это вообще кошмар. Особенно то, что Spark рапортует, что все успешно.
В общем пока поставили на паузу. Появится время — вернемся к этому вопросу. Но вообще впечатление нехорошее
Немного с опозданием, но пару комментариев:
1) он стал частью Hadoop 2.0.
а можно узнать где и когда? хадуп 2.0 уже давно вышел, 3.0 на подходе, и спарк там никаким боком не светится
2) Spark можно описать одной фразой так — это внутренности движка массивно-параллельной СУБД
не правда, если уж и описывать одной фразой, то это: ленивая обработка вычислений и pipeline map фаз
выполнять параллельно несколько задач он не умеет, в dag последовательно проходят все агрерирующие операции, если нужно действительно параллельность, то или ручками в Tez углубляться и строить DAG, или смотреть проект Apache Flink у них на слайдах это хорошо показано.
3) groupBy
у этого оператора, как и всех операторов использующих ShuffleMapTask есть большая проблема: они ВСЕГДА пишут результат на диск, независимо от того кешируете вы результат в памяти или нет, следующие в списке забирают результат по http. поэтому слова на их слайды про in-memory немного приувеличения =) разница в обмене между map и reduce у них с хадупом почти нулевая.
4) а также AMP LAB (лаборатория, откуда вырос Spark) не собирается отказывать и от проекта Shark — полное замещение Apache HIVE
опять мимо, на шарк уже все забили, amp lab все что полезное вытянули в spark sql, то что осталось отправилось на свалку. что действительно пилят, так это hive on spark, совместные усилия клоудеры и amp lab по реализации еще одного бекенда для hive (на данный момент есть mr и tez), но с полной совместимостью hive sql
5) не только средствами RDD, но и дополнительными примитивами
можно подробней? так как там все построено поверх RDD, это главный примитив в самом спарке, по сути key-value, а уже поверх него строится все остальное
ну как-то так, если совсем кратко =)
1) он стал частью Hadoop 2.0.
а можно узнать где и когда? хадуп 2.0 уже давно вышел, 3.0 на подходе, и спарк там никаким боком не светится
2) Spark можно описать одной фразой так — это внутренности движка массивно-параллельной СУБД
не правда, если уж и описывать одной фразой, то это: ленивая обработка вычислений и pipeline map фаз
выполнять параллельно несколько задач он не умеет, в dag последовательно проходят все агрерирующие операции, если нужно действительно параллельность, то или ручками в Tez углубляться и строить DAG, или смотреть проект Apache Flink у них на слайдах это хорошо показано.
3) groupBy
у этого оператора, как и всех операторов использующих ShuffleMapTask есть большая проблема: они ВСЕГДА пишут результат на диск, независимо от того кешируете вы результат в памяти или нет, следующие в списке забирают результат по http. поэтому слова на их слайды про in-memory немного приувеличения =) разница в обмене между map и reduce у них с хадупом почти нулевая.
4) а также AMP LAB (лаборатория, откуда вырос Spark) не собирается отказывать и от проекта Shark — полное замещение Apache HIVE
опять мимо, на шарк уже все забили, amp lab все что полезное вытянули в spark sql, то что осталось отправилось на свалку. что действительно пилят, так это hive on spark, совместные усилия клоудеры и amp lab по реализации еще одного бекенда для hive (на данный момент есть mr и tez), но с полной совместимостью hive sql
5) не только средствами RDD, но и дополнительными примитивами
можно подробней? так как там все построено поверх RDD, это главный примитив в самом спарке, по сути key-value, а уже поверх него строится все остальное
ну как-то так, если совсем кратко =)
1) Он в Hadoop 2.0
2) В Спарке есть все операторы реляционной алгебры + дополнителные операторы для BlinkDB
3) Возможны другие имплементации groupBy — например если все уже отсортировано по ключу — не надо ничего делать. Такой оператор появится — например когда будут merge-joins
4) Нет, не забили, видел 3-х месячной давности презентацию
5) Прочитайте про broadcast variables и accumulators
6) да, кратко, чтобы можно было быстро прочесть и дальше изучать
2) В Спарке есть все операторы реляционной алгебры + дополнителные операторы для BlinkDB
3) Возможны другие имплементации groupBy — например если все уже отсортировано по ключу — не надо ничего делать. Такой оператор появится — например когда будут merge-joins
4) Нет, не забили, видел 3-х месячной давности презентацию
5) Прочитайте про broadcast variables и accumulators
6) да, кратко, чтобы можно было быстро прочесть и дальше изучать
1) Хмм… да, читал ананс давно, что будут включать, но не включили. Но уже есть другие дистрибутивы со Спарком
1) насколько помню даже и не собирались =) в момент выхода второго хадупа, спарк еще был в настолько сырой бете…
может вы перепутали с «Spark on Pivotal Hadoop 2.0» или с HDP 2.0 от hortonworks, но это всего лишь сборки конкретных дистрибутивов с полностью независимой от hadoop нумерацией
2) поддержка нескольких партиций и параллельная их обработка не делает из спарка «массивно-параллельной СУБД», с таким же успехом будет тоже «массивно-параллельной СУБД». реляционной алгебры — update и транзакционность уже прикрутили?
3) «если бы, да кабы»,
на данный момент в случае отсортированности какой либо таблицы, мы к ней делаем join, предварительно сортируя вторую
если отсортированы обе, то в любом случае со второй дергаем репартишинг, так как диапазоны ключей конечно же разные
выполнение repartition выкинет в обязательном порядке все данные на диск (в офф документации я что-то не заметил упоминания этого факта, благо хоть cloudera не молчит: The MapReduce and Spark shuffles use a “pull” model. Every map task writes out data to local disk, and then the reduce tasks make remote requests to fetch that data. А то на слайдах у датабрикса все так красиво)
MergeJoin operator relies on SortBasedShuffle to create partitions that sorted by the join key, так что магии не будет, все расходимся
4) ну за 3 месяца многое поменялось, меньше месяца назад они заявляли про spark sql как основная цель и catalist как движок для запиливания оптимизаций. можно даже пройти на офф сайт http://shark.cs.berkeley.edu/ «Shark has been subsumed by Spark SQL, a new module in Apache Spark. Please see the following blog post for more information: Shark, Spark SQL, Hive on Spark, and the future of SQL on Spark.» ;)
5) читал и использовал.
Ничем accumulators от таких в хадупе не отличаются (локальная работа в пределах партиции и сброс на агрегацию в драйвер. Tasks running on the cluster can then add to it using the add method or the += operator (in Scala and Python). However, they cannot read its value).
Broadcast Variables вообще сугубо read only и неизменяемы, раз разослали и все.
p.s. активно пользовался хадупом, когда он еще 0.18 был, за спарком тоже слежу почти с самого его начала, но пока вижу пиара вокруг него больше, чем он реально может. я согласен с тем, что продукт дальше развивает подход с параллельной обработкой данных, которые пнул гугл и дальше подхватил hadoop, но не согласен с уровнем маркетинга вокруг него.
может вы перепутали с «Spark on Pivotal Hadoop 2.0» или с HDP 2.0 от hortonworks, но это всего лишь сборки конкретных дистрибутивов с полностью независимой от hadoop нумерацией
2) поддержка нескольких партиций и параллельная их обработка не делает из спарка «массивно-параллельной СУБД», с таким же успехом будет тоже «массивно-параллельной СУБД». реляционной алгебры — update и транзакционность уже прикрутили?
3) «если бы, да кабы»,
на данный момент в случае отсортированности какой либо таблицы, мы к ней делаем join, предварительно сортируя вторую
если отсортированы обе, то в любом случае со второй дергаем репартишинг, так как диапазоны ключей конечно же разные
выполнение repartition выкинет в обязательном порядке все данные на диск (в офф документации я что-то не заметил упоминания этого факта, благо хоть cloudera не молчит: The MapReduce and Spark shuffles use a “pull” model. Every map task writes out data to local disk, and then the reduce tasks make remote requests to fetch that data. А то на слайдах у датабрикса все так красиво)
MergeJoin operator relies on SortBasedShuffle to create partitions that sorted by the join key, так что магии не будет, все расходимся
4) ну за 3 месяца многое поменялось, меньше месяца назад они заявляли про spark sql как основная цель и catalist как движок для запиливания оптимизаций. можно даже пройти на офф сайт http://shark.cs.berkeley.edu/ «Shark has been subsumed by Spark SQL, a new module in Apache Spark. Please see the following blog post for more information: Shark, Spark SQL, Hive on Spark, and the future of SQL on Spark.» ;)
5) читал и использовал.
Ничем accumulators от таких в хадупе не отличаются (локальная работа в пределах партиции и сброс на агрегацию в драйвер. Tasks running on the cluster can then add to it using the add method or the += operator (in Scala and Python). However, they cannot read its value).
Broadcast Variables вообще сугубо read only и неизменяемы, раз разослали и все.
p.s. активно пользовался хадупом, когда он еще 0.18 был, за спарком тоже слежу почти с самого его начала, но пока вижу пиара вокруг него больше, чем он реально может. я согласен с тем, что продукт дальше развивает подход с параллельной обработкой данных, которые пнул гугл и дальше подхватил hadoop, но не согласен с уровнем маркетинга вокруг него.
1) уже забыл, где видел
2) я же написал — движок, то есть процессор, а не хранилище. Но на самом деле основная масса MPP DBMS используется для аналитики, тем не особо нужны транзакции. Так что тут уже 1 шаг.
3) я привел пример groupBy, причем здесь reshuffling? GroupBy много разных имплементаций — если будет интегрировано свое хранилище с мета-данными то можно разшардить данные так, что они будут в пределах одного ключа для группировки лежать на одном узле. MergeJoin может ничего не сортировать, если данные идут из отсортированного индекса, например B-Tree. Далее — когда у нас здоровенный план запроса с кучей joins — можно 1 раз для всех сделать сортировку, и потом ей пользоваться, конечно, если ключи будут совпадать — а это очень частый случай (куча outerjoin-ов и группировкой например — часто хватит одной сортировки на весь план выполения).
4) broadcast очень полезны, по сути — это барьерная синхронизация из MPI. Я не писал, что их нет в хадупе, хотя не знал, что они там есть. Особо никогда за хадупом не следил.
5) маркетинга много, но тому есть резон. Уровень людей, которые делают стэк Спарка намного серьезнее, чем Хадупа.
2) я же написал — движок, то есть процессор, а не хранилище. Но на самом деле основная масса MPP DBMS используется для аналитики, тем не особо нужны транзакции. Так что тут уже 1 шаг.
3) я привел пример groupBy, причем здесь reshuffling? GroupBy много разных имплементаций — если будет интегрировано свое хранилище с мета-данными то можно разшардить данные так, что они будут в пределах одного ключа для группировки лежать на одном узле. MergeJoin может ничего не сортировать, если данные идут из отсортированного индекса, например B-Tree. Далее — когда у нас здоровенный план запроса с кучей joins — можно 1 раз для всех сделать сортировку, и потом ей пользоваться, конечно, если ключи будут совпадать — а это очень частый случай (куча outerjoin-ов и группировкой например — часто хватит одной сортировки на весь план выполения).
4) broadcast очень полезны, по сути — это барьерная синхронизация из MPI. Я не писал, что их нет в хадупе, хотя не знал, что они там есть. Особо никогда за хадупом не следил.
5) маркетинга много, но тому есть резон. Уровень людей, которые делают стэк Спарка намного серьезнее, чем Хадупа.
2) ок, hive это mpp dbms, так как там уже даже mvcc прикрутили
3) к тому что это все сделано поверх shuffle примитивов
5) резон один — набрать побольше клиентов на саппорт. и давайте не будем про уровень людей, для этого достаточно открыть репозитории и посмотреть на срач в нем в spark, если вы про «профессоров», то хочу вас расстроить, количество грантов на разработку выданных при развитии хадупа тоже не один десяток ушло в универы и написаны/защищены достаточно работ по оптимизациям.
в общем не вижу смысла продолжать спор, так как мы сейчас в разной плоскости: я — «как сейчас сделано и работает», вы — «как МОЖНО сделать или в будущем возможно сделают». само плохое когда люди начинают вместо реальной ситуации и положении дел в продукте рассказывают об их идеальном видении как это можно сделать.
3) к тому что это все сделано поверх shuffle примитивов
5) резон один — набрать побольше клиентов на саппорт. и давайте не будем про уровень людей, для этого достаточно открыть репозитории и посмотреть на срач в нем в spark, если вы про «профессоров», то хочу вас расстроить, количество грантов на разработку выданных при развитии хадупа тоже не один десяток ушло в универы и написаны/защищены достаточно работ по оптимизациям.
в общем не вижу смысла продолжать спор, так как мы сейчас в разной плоскости: я — «как сейчас сделано и работает», вы — «как МОЖНО сделать или в будущем возможно сделают». само плохое когда люди начинают вместо реальной ситуации и положении дел в продукте рассказывают об их идеальном видении как это можно сделать.
Ну спора тут мало — HIVE именно сверху шафлов, и сделать на них нормальный dbms не получится.
И UC Berkley — это серьезные ребята, я им верю
И UC Berkley — это серьезные ребята, я им верю
если вы так уверенны про шафлы, то посмотрите проект Apache Tez, там точно такой же pipeline задач можно сделать, распределенные hive tmp таблицы сугубо в памяти.
он за последнее время ооочень сильно вырос, пускай и тянет в основном только хортон его.
а уже если действительно хочется драйва, то Apache Flink, там и грамотный pipeline и parallel обработка
Tez и Flink позволяют строить пайплайны намного более удобные для ETL (много ETL'щиков спасибо скажут за такой функционал)
загрузили из source1, transform1, transform2, output (out1, out2, out3)
в спарке после второй трансформации нужно делать материализацию результата, чтобы потом в разные out скормить, если у вас большие объемы, то это гарантированно упадет на диск. у flink в разы более грамотная работа с памятью и тд.
В итоге когда дело касается веры, то я немцам в таких вещах больше верю ;)
spark — сделали прототип, шумиха пошла, докидываем на лету на map-reduce дополнительные модули (хотя к архитектуре вопросов более чем у меня), чисто американский подход
flink — провели исследования, вопросы оптимизации и runtime подстройки задач на основе статистики, начали делать прототипы и продукт, в общем классический немецкий подход
кто выживет покажет время
он за последнее время ооочень сильно вырос, пускай и тянет в основном только хортон его.
а уже если действительно хочется драйва, то Apache Flink, там и грамотный pipeline и parallel обработка
Tez и Flink позволяют строить пайплайны намного более удобные для ETL (много ETL'щиков спасибо скажут за такой функционал)
загрузили из source1, transform1, transform2, output (out1, out2, out3)
в спарке после второй трансформации нужно делать материализацию результата, чтобы потом в разные out скормить, если у вас большие объемы, то это гарантированно упадет на диск. у flink в разы более грамотная работа с памятью и тд.
В итоге когда дело касается веры, то я немцам в таких вещах больше верю ;)
spark — сделали прототип, шумиха пошла, докидываем на лету на map-reduce дополнительные модули (хотя к архитектуре вопросов более чем у меня), чисто американский подход
flink — провели исследования, вопросы оптимизации и runtime подстройки задач на основе статистики, начали делать прототипы и продукт, в общем классический немецкий подход
кто выживет покажет время
Sign up to leave a comment.
Apache Spark: что там под капотом?