А
Надо лезть смотреть в соседний ридер. Будет время - посмотрю и напишу
Можешь скинуть ссылку на гитхаб по паркету?
Size: a a a
2021 March 04
ИК
Можешь скинуть ссылку на гитхаб по паркету?
ИК
и дальше несложно отследить
ИК
во, тут подробно!
А
во, тут подробно!
спасибо!
ИК
А с орками не знаешь, так же?
На уровне спарка совершенно так же. Мне показалось, что реализация кринжовая, по сравнению с паркетом
Итератор по партициям спарк должен быть создан в любом случае, даже если ни одна колонка из файла не выбирается, потому что пользователь может добавить литералы или функции
Итератор по партициям спарк должен быть создан в любом случае, даже если ни одна колонка из файла не выбирается, потому что пользователь может добавить литералы или функции
NN
На уровне спарка совершенно так же. Мне показалось, что реализация кринжовая, по сравнению с паркетом
Итератор по партициям спарк должен быть создан в любом случае, даже если ни одна колонка из файла не выбирается, потому что пользователь может добавить литералы или функции
Итератор по партициям спарк должен быть создан в любом случае, даже если ни одна колонка из файла не выбирается, потому что пользователь может добавить литералы или функции
Ну т.е. он, к счастью, не читает полностью каждый файл, а ограничивается футерами каждой партиции?
ИК
ну, запрошенные поля в виде StructType передаются в ридер, ридер читает их, руководствуясь смещениями из метаданных. Честно сказать, не увидел, где именно берётся numberOfRows из метаданных, но колонки точно фильтруются, а значит количество должно быть известно до прочтения конкретной колонки
NN
ну, запрошенные поля в виде StructType передаются в ридер, ридер читает их, руководствуясь смещениями из метаданных. Честно сказать, не увидел, где именно берётся numberOfRows из метаданных, но колонки точно фильтруются, а значит количество должно быть известно до прочтения конкретной колонки
Так...я правильно понял, что чтение можно ускорить, если сделать count не всего датафрейма, а только одной колонки?
ИК
да, одна колонка или литерал должны считаться быстрее. Я раньше использовал count(lit(0)), по ощущениям было ускорение, но не бенчмаркал, так, на глаз прикидывал))
NN
да, одна колонка или литерал должны считаться быстрее. Я раньше использовал count(lit(0)), по ощущениям было ускорение, но не бенчмаркал, так, на глаз прикидывал))
Прикольно)
PK
да, одна колонка или литерал должны считаться быстрее. Я раньше использовал count(lit(0)), по ощущениям было ускорение, но не бенчмаркал, так, на глаз прикидывал))
Вроде ещё субдшные олды всегда рекомендовали делать count(1)
ИК
Вроде ещё субдшные олды всегда рекомендовали делать count(1)
в оракле оптимизатор транслирует в count(*)
а те, кто хотели сэкономить на спичках и посчитать count(null) - ничего не получали)) EXISTS (SELECT null FROM …) при этом работал отлично
а те, кто хотели сэкономить на спичках и посчитать count(null) - ничего не получали)) EXISTS (SELECT null FROM …) при этом работал отлично
AA
да, одна колонка или литерал должны считаться быстрее. Я раньше использовал count(lit(0)), по ощущениям было ускорение, но не бенчмаркал, так, на глаз прикидывал))
А почему не просто count(), то есть вообще без всего?
Я так понял по вот этому описанию
https://github.com/dennyglee/databricks/blob/master/misc/parquet-count-metadata-explanation.md
что если делаешь просто count(), то он схему даже не читает
Я так понял по вот этому описанию
https://github.com/dennyglee/databricks/blob/master/misc/parquet-count-metadata-explanation.md
что если делаешь просто count(), то он схему даже не читает
ИК
А почему не просто count(), то есть вообще без всего?
Я так понял по вот этому описанию
https://github.com/dennyglee/databricks/blob/master/misc/parquet-count-metadata-explanation.md
что если делаешь просто count(), то он схему даже не читает
Я так понял по вот этому описанию
https://github.com/dennyglee/databricks/blob/master/misc/parquet-count-metadata-explanation.md
что если делаешь просто count(), то он схему даже не читает
а потому что после десяти с лишним лет на оракле count() выглядел пугающе, как шаг в пропасть (ノ ͡❛ ෴ ͡❛)ノ
N
Это скорее ansi sql не позволяет написать count().
K
Ребят, а давайте объединимся и сборку сделаем вот такую, https://apache-mirror.rbc.ru/pub/apache/spark/spark-3.0.2/spark-3.0.2-bin-hadoop2.7-hive1.2.tgz но с 3.1 спарком, чтобы хайв старый был)
PZ
Так...я правильно понял, что чтение можно ускорить, если сделать count не всего датафрейма, а только одной колонки?
Если говорить про .groupBy(...).agg(count($"smth")), то это ведь другая семантика – это количество строк с not null значениями по этой колонке
A
Ребят, а давайте объединимся и сборку сделаем вот такую, https://apache-mirror.rbc.ru/pub/apache/spark/spark-3.0.2/spark-3.0.2-bin-hadoop2.7-hive1.2.tgz но с 3.1 спарком, чтобы хайв старый был)
Там же любой может сделать, достаточно параметры profile передать правильные и всё, мейвен соберёт
Или в чем вопрос?
Или в чем вопрос?