по крайней мере маркетингового булшита и питонолячканья минимум.

веду студентов оффлайново из местного сантиметростроительного, это вся предподская работа на которую меня хватает :(

даже скала для самых маленьких есть 2 топиков.

А на жабке там никто не учился? Тоже дендрофекально или норм?

Ну перекатовальщики джуны после них такие себе были

Я на первом потоке там был. Твои занятия были лучшими! Спасибо огромное 👍 Жаль, что не преподаешь там больше.

Big Data vs Data #Science: The 15 Differences To Know


https://reconshell.com/big-data-vs-data-science/

коллеги, а можете на пальцах объяснить когда (и как) spark structured streaming задание вычитывает полный/compact-файл от FileStreamSinkLog (которые падают в _spark_metadata) ?
я хочу проверить будет ли в каких-то граничных ситуациях падать пишущая в HDFS стриминг-джоба если сделана компакция файлов в какой-нибудь саб-директории

Этож просто лог файлов по батчам. Компакт он вроде может вычитать только при мердже в следующий компакт, а до этого они ему и не нужны впринцепи. Падать  будет если не будет видеть его при попытке мерджа в новый компакт файл.

то есть стриминговая джоба вообще не проверяет при записи в инкрементальные WAL-файлы или при компакции инкрементальных WAL-файлов в compact-файл соответствие содержимого этого файла реальному состоянию файловой системы?

compact-файл и инкрементальные файлы используются для реального сканирования файлововой системы только если есть downstream-джоба, подписанная на этот HDFS-каталог, верно?

Так а как она проверит если по сути это уже записанные батчи этих файлов физически уже нет?

мои действия:
1) создан и запущен Spark Structured Streaming джоб, который пишет в каталог «/data/bronze/load_dt=YYYY-MM-DD/load_hh=NN»
2) я хочу регулярно (ночью) компактить позавчерашние партиции/субпартиции (проблема мелких файлов)
3) если я прогоню компакцию над каталогом «/data/bronze/load_dt=2020-12-27» и его подкаталогами, то содержимое в них перестанет соответствовать записям в Write-Ahead-Log-файлах внутри «/data/bronze/_spark_metadata»
4) как минимум я не смогу сделать
spark.read.parquet(«/data/bronze»)
потому что будет вычитываться список файлов для чтения из WAL внутри «_spark_metadata»
на это мне пофиг…

я хочу убедиться, что кроме чтения прочие операции (хаускипинг, восстановления при сбоях) не будут падать

пока склоняюсь к варианту вообще выключить WAL в  «_spark_metadata»

При чтение паркета он вал логи читать никоем образом не будет. Компактить в таком случае лучше уже постфактум когда окно ушло за дату компакта.

Ну и для стриминг джобы настроить необходимое кол-во партиций для записи :)

Looker у кого есть экспириенс?

У меня

На что сажаем? Если вот на Redshift, то query performance как?

На Редшифт, да. Всё отлично.
Просто в Редшифт витрины причесаны