Size: a a a

2020 April 21

K

KrivdaTheTriewe in Moscow Spark
я все еще дремучий и считаю это нежизнеспособынм
источник

R

Renarde in Moscow Spark
ты имеешь в виду autoscaling по типу - в батч прилетело 10к - обработали в 4 воркера, прилетело 100к - обработали в 10 воркеров?
источник

K

KrivdaTheTriewe in Moscow Spark
да
источник

R

Renarde in Moscow Spark
мне сложно сказать как это в standalone / k8s / yarn-based спарке обстоит, но в Databricks нормально с этим, если стримить из сырца который replayable (kafka / kinesis). Тогда по метаданным смотрят на скорость обработки относительно триггера (стоит, скажем триггер в 1 минуту, а статистика батча показывает что обработка происходит за 2 минуты - тогда будет апскейл)
источник

R

Renarde in Moscow Spark
Replayable нужен чтобы в случае downscale понимать что уже было прочитано, а что нет, так что какой-нибудь soket-based стрим стараемся тоже в event service заворачивать
источник

K

KrivdaTheTriewe in Moscow Spark
понял
источник

K

KrivdaTheTriewe in Moscow Spark
спасибо
источник

K

KrivdaTheTriewe in Moscow Spark
у нас реплейбл
источник

K

KrivdaTheTriewe in Moscow Spark
К сожалению датабрикса нету)
источник

M

Mi in Moscow Spark
Коллеги, вопрос по спарку, можем ли мы читать и писать с bucket by/distribute by/cluster by без метастора? Просто в папку. Сможет ли Спарк понять что данные уже удобно лежат? Или как ему об этом сказать
источник

M

Mi in Moscow Spark
={
источник
2020 April 22

R

Renarde in Moscow Spark
Mi
Коллеги, вопрос по спарку, можем ли мы читать и писать с bucket by/distribute by/cluster by без метастора? Просто в папку. Сможет ли Спарк понять что данные уже удобно лежат? Или как ему об этом сказать
Насколько я помню, не сможет, потому что статистика бакетов хранится в метасторе, а не в файлах на фс
источник

M

Mi in Moscow Spark
Renarde
Насколько я помню, не сможет, потому что статистика бакетов хранится в метасторе, а не в файлах на фс
Грустно слышать, спасибо
источник

AA

Anton Alekseev in Moscow Spark
Всем привет. Ребята я уже приходил в чатик с проблемой переполнения буфера pyarrow. (https://issues.apache.org/jira/browse/ARROW-4890
), но опять возникла такая проблема. В общем дело в том что после группировки получаются слишком большие массивы данных чтобы передать это в pudf, проиходит переполнение буфера. И вроде в ишью выше есть ссылка на фикс, который уже залили в новые версии pyarrow. Удалось завести новый pyarrow (0.17.0) (и заодно пофиксить ошибку обратной совместимости версий), но вылазит новая обшибка pyarrow. OSError: Invalid IPC message: negative bodyLength - выглядит как тоже самое переполнение, кто-то сталкивался, удалось пофиксить? гугл тут уже не помогает.
источник

AA

Anton Alekseev in Moscow Spark
В общем решилось (не прямо решение, но хоть заработало) как всегда с такой ошибкой, выпиливанием лишних колонок, которые прилетают в pudf.
источник

DY

Dmitriy Yampolskiy in Moscow Spark
Привет. Возникла проблема с использованием union. Как будто бы в колонке получаются неожиданные значения, которых не было ни в одном из объединяемых датафреймов. Я совсем недавно начал работать со спарком, так что, наверное, я делатю что-то простое и глупое. Буду благодарен за помощь.  Проблему проще показать на скринах.
источник

DY

Dmitriy Yampolskiy in Moscow Spark
источник

DY

Dmitriy Yampolskiy in Moscow Spark
источник

DY

Dmitriy Yampolskiy in Moscow Spark
источник

AS

Andrey Siunov in Moscow Spark
@yampolson а какие схемы у этих dataframe? IIRC, union сопоставляет столбцы не по имени, а в том порядке, в котором они даны в схеме.
источник