VS
3.1 же потраченный, хотфиксы даже прилетают на 3.0
Size: a a a
2021 March 03
K
3.1 же потраченный, хотфиксы даже прилетают на 3.0
там 3.1.0 случайно релизнули
K
Терь 3.1.1 по-сути первая версия
GP
прикольно интересно когда делать будут
K
прикольно интересно когда делать будут
так сделали
GP
так сделали
Я долбоюсь в глаза) Вижу теперь фиксед
K
Хотя я наверное не прав
PK
Thomas Graves - это чувак из нашей Spark GPU команды
PK
так сделали
SPIP обусдили, теперь заимплементить осталось
IK
Просто ради интереса, кто-то пользуется спарком через Beam? Интересно узнать кейсы.
A
до недавнего времени beam это в идеале google dataflow
на онпремис flink (контрибьютят активно сами разрабы флинка)
не сильно давно линкедин вагон патчей подвёз для запуска с samza (у них оно в проде)
а вот спарк поддерживать датабриксу совсем не хочется (считай что в перспективе люди могут уйти на другие раннеры которые им удобней, никакого вендорлока)
поэтому что и попадает туда, то по остаточному принципу всегда
это видно уже сразу по матрице
https://beam.apache.org/documentation/runners/capability-matrix/
на онпремис flink (контрибьютят активно сами разрабы флинка)
не сильно давно линкедин вагон патчей подвёз для запуска с samza (у них оно в проде)
а вот спарк поддерживать датабриксу совсем не хочется (считай что в перспективе люди могут уйти на другие раннеры которые им удобней, никакого вендорлока)
поэтому что и попадает туда, то по остаточному принципу всегда
это видно уже сразу по матрице
https://beam.apache.org/documentation/runners/capability-matrix/
A
пол года назад ещё всё было очень плохо со спарк раннерами
A
3й спарк там не поддерживается ещё
https://issues.apache.org/jira/browse/BEAM-7093
https://issues.apache.org/jira/browse/BEAM-7093
2021 March 04
ИК
А разве когда на паркетах без всего просто делаешь каунт, он так не делает? Там же вроде такая логика и есть - читает просто футеры и складывает
Для восстановления справедливости: да, так и делает. Паркетный ридер читает количество из футера всегда, сколько бы полей ни было в схеме, хоть все, хоть ни одного, иначе невозможно (или недопустимо сложно) корректно обработать паркет. Поэтому можно сказать, что если хотя бы одна колонка не указана в select, то читается не весь файл, а только его часть. Но потом всё равно Iterator, план спарка, аггрегация. Так что просто читать футеры в .mapPartitions и агрегировать одно только число будет всё же быстрее, но не очень-то универсально
ИК
Закрыл гештальт ))
AA
Для восстановления справедливости: да, так и делает. Паркетный ридер читает количество из футера всегда, сколько бы полей ни было в схеме, хоть все, хоть ни одного, иначе невозможно (или недопустимо сложно) корректно обработать паркет. Поэтому можно сказать, что если хотя бы одна колонка не указана в select, то читается не весь файл, а только его часть. Но потом всё равно Iterator, план спарка, аггрегация. Так что просто читать футеры в .mapPartitions и агрегировать одно только число будет всё же быстрее, но не очень-то универсально
Ого, спасибо, буду знать) Я на самом деле помнил, что хотел посмотреть, но всё никак руки не доходили
NN
Для восстановления справедливости: да, так и делает. Паркетный ридер читает количество из футера всегда, сколько бы полей ни было в схеме, хоть все, хоть ни одного, иначе невозможно (или недопустимо сложно) корректно обработать паркет. Поэтому можно сказать, что если хотя бы одна колонка не указана в select, то читается не весь файл, а только его часть. Но потом всё равно Iterator, план спарка, аггрегация. Так что просто читать футеры в .mapPartitions и агрегировать одно только число будет всё же быстрее, но не очень-то универсально
А с орками не знаешь, так же?
ИК
А с орками не знаешь, так же?
Надо лезть смотреть в соседний ридер. Будет время - посмотрю и напишу