GP
посмотри от чего спарк 3 зависит?
Size: a a a
2020 September 01
GP
я не помню
UD
Да чекну попозже, идея была подложить ему жарники хайва
GP
Т.е я думаю на какую-то говнину в зависимостей дистрибутива
Трифт может быть
UD
Трифт может быть
Типа spark.sql.hive.metastore.jars и spark.sql.hive.metastore.version
UD
Как вариант выбить ногой дверь, попробую втащить актуальный второй хайв
GT
Там просто все, хочется именно третий спарк на старье
попробуйте —conf spark.sql.metastore.jars=maven 🌝
UD
попробуйте —conf spark.sql.metastore.jars=maven 🌝
Слишком просто
UD
Там инета нет :)
A
Можно указать путь локальный :)
A
Или собрать uberjar, закинуть на hdfs, указать в списке addfiles
A
После локализации будет доступен :)
GP
Или собрать uberjar, закинуть на hdfs, указать в списке addfiles
ну да разделить класспасы и нужные депенси в жирный жарник сунуть
GP
как вариант
ИК
Ребят, а кто нить может подсказать, как в спарке в бэкграунде подсчитать статистику по количеству строк в записанном рдд?
Хоть вопрос и неоднозначный, вариантов немного:
1. Самый простой, прямолинейный и в тоже время затратный - обратиться к записанным файлам и подсчитать количество записей методом .count . Преимущества - будет совершенно точно известно, сколько записей действительно сохранено. Недостатки - если записи дописываются к уже существующим, надо их отфильтровать, в некоторых случая это нереализуемо; требуются вычислительные ресурсы; для запуска "в бэкграунде" (асинхронно/конкурентно) нужно делать thread/future/что умеете, а пользы от асинхронности может не быть никакой, потому что задание уже завершено
2. Аккумуляторы. Преимущества: значение доступно сразу после окончания обработки, можно сказать, что посчитано "в бекграунде"; для количества и суммы аккумуляторы подходят хорошо. Недостатки: документация говорит, что в аккумуляторах, при правильной реализации, соблюдается принцип exactly once, но иногда встречается информация, что это не так. Скорее всего, надо брать AccumulatorV2 и не делать кривых реализаций
1. Самый простой, прямолинейный и в тоже время затратный - обратиться к записанным файлам и подсчитать количество записей методом .count . Преимущества - будет совершенно точно известно, сколько записей действительно сохранено. Недостатки - если записи дописываются к уже существующим, надо их отфильтровать, в некоторых случая это нереализуемо; требуются вычислительные ресурсы; для запуска "в бэкграунде" (асинхронно/конкурентно) нужно делать thread/future/что умеете, а пользы от асинхронности может не быть никакой, потому что задание уже завершено
2. Аккумуляторы. Преимущества: значение доступно сразу после окончания обработки, можно сказать, что посчитано "в бекграунде"; для количества и суммы аккумуляторы подходят хорошо. Недостатки: документация говорит, что в аккумуляторах, при правильной реализации, соблюдается принцип exactly once, но иногда встречается информация, что это не так. Скорее всего, надо брать AccumulatorV2 и не делать кривых реализаций
M
Хоть вопрос и неоднозначный, вариантов немного:
1. Самый простой, прямолинейный и в тоже время затратный - обратиться к записанным файлам и подсчитать количество записей методом .count . Преимущества - будет совершенно точно известно, сколько записей действительно сохранено. Недостатки - если записи дописываются к уже существующим, надо их отфильтровать, в некоторых случая это нереализуемо; требуются вычислительные ресурсы; для запуска "в бэкграунде" (асинхронно/конкурентно) нужно делать thread/future/что умеете, а пользы от асинхронности может не быть никакой, потому что задание уже завершено
2. Аккумуляторы. Преимущества: значение доступно сразу после окончания обработки, можно сказать, что посчитано "в бекграунде"; для количества и суммы аккумуляторы подходят хорошо. Недостатки: документация говорит, что в аккумуляторах, при правильной реализации, соблюдается принцип exactly once, но иногда встречается информация, что это не так. Скорее всего, надо брать AccumulatorV2 и не делать кривых реализаций
1. Самый простой, прямолинейный и в тоже время затратный - обратиться к записанным файлам и подсчитать количество записей методом .count . Преимущества - будет совершенно точно известно, сколько записей действительно сохранено. Недостатки - если записи дописываются к уже существующим, надо их отфильтровать, в некоторых случая это нереализуемо; требуются вычислительные ресурсы; для запуска "в бэкграунде" (асинхронно/конкурентно) нужно делать thread/future/что умеете, а пользы от асинхронности может не быть никакой, потому что задание уже завершено
2. Аккумуляторы. Преимущества: значение доступно сразу после окончания обработки, можно сказать, что посчитано "в бекграунде"; для количества и суммы аккумуляторы подходят хорошо. Недостатки: документация говорит, что в аккумуляторах, при правильной реализации, соблюдается принцип exactly once, но иногда встречается информация, что это не так. Скорее всего, надо брать AccumulatorV2 и не делать кривых реализаций
Спасибо за обстоятельный ответ
AS
Хоть вопрос и неоднозначный, вариантов немного:
1. Самый простой, прямолинейный и в тоже время затратный - обратиться к записанным файлам и подсчитать количество записей методом .count . Преимущества - будет совершенно точно известно, сколько записей действительно сохранено. Недостатки - если записи дописываются к уже существующим, надо их отфильтровать, в некоторых случая это нереализуемо; требуются вычислительные ресурсы; для запуска "в бэкграунде" (асинхронно/конкурентно) нужно делать thread/future/что умеете, а пользы от асинхронности может не быть никакой, потому что задание уже завершено
2. Аккумуляторы. Преимущества: значение доступно сразу после окончания обработки, можно сказать, что посчитано "в бекграунде"; для количества и суммы аккумуляторы подходят хорошо. Недостатки: документация говорит, что в аккумуляторах, при правильной реализации, соблюдается принцип exactly once, но иногда встречается информация, что это не так. Скорее всего, надо брать AccumulatorV2 и не делать кривых реализаций
1. Самый простой, прямолинейный и в тоже время затратный - обратиться к записанным файлам и подсчитать количество записей методом .count . Преимущества - будет совершенно точно известно, сколько записей действительно сохранено. Недостатки - если записи дописываются к уже существующим, надо их отфильтровать, в некоторых случая это нереализуемо; требуются вычислительные ресурсы; для запуска "в бэкграунде" (асинхронно/конкурентно) нужно делать thread/future/что умеете, а пользы от асинхронности может не быть никакой, потому что задание уже завершено
2. Аккумуляторы. Преимущества: значение доступно сразу после окончания обработки, можно сказать, что посчитано "в бекграунде"; для количества и суммы аккумуляторы подходят хорошо. Недостатки: документация говорит, что в аккумуляторах, при правильной реализации, соблюдается принцип exactly once, но иногда встречается информация, что это не так. Скорее всего, надо брать AccumulatorV2 и не делать кривых реализаций
в случае action это так, в случае если применяются в трансформациях, то это не гарантируется
For accumulator updates performed inside actions only, Spark guarantees that each task’s update to the accumulator will only be applied once, i.e. restarted tasks will not update the value. In transformations, users should be aware of that each task’s update may be applied more than once if tasks or job stages are re-executed.
For accumulator updates performed inside actions only, Spark guarantees that each task’s update to the accumulator will only be applied once, i.e. restarted tasks will not update the value. In transformations, users should be aware of that each task’s update may be applied more than once if tasks or job stages are re-executed.
ИК
в случае action это так, в случае если применяются в трансформациях, то это не гарантируется
For accumulator updates performed inside actions only, Spark guarantees that each task’s update to the accumulator will only be applied once, i.e. restarted tasks will not update the value. In transformations, users should be aware of that each task’s update may be applied more than once if tasks or job stages are re-executed.
For accumulator updates performed inside actions only, Spark guarantees that each task’s update to the accumulator will only be applied once, i.e. restarted tasks will not update the value. In transformations, users should be aware of that each task’s update may be applied more than once if tasks or job stages are re-executed.
Получается, надо применять исключительно на RDD/Dataset, содержащих только Action. Правильно понимаю? Очевидного способа, чтобы аккумулятор использовался только в конкретном Action, я в API не увидел.
Или, если статистика не изменится от нескольких проходов, например, минимальное или максимальное значение поля, то можно и на трансформации применять
Или, если статистика не изменится от нескольких проходов, например, минимальное или максимальное значение поля, то можно и на трансформации применять
SS
коллеги, подскажите как можно перепроцессить поток данных из HDFS-каталога для spark structured streaming?