R
Понятно, думал, совсем нельзя трогать бронзовый слой
это изменение data layout, не контента
@barloc , спасибо! сделаю над одним readStream два разных writeStream:
- приземление сырых данных в бронзу
- парсинг и трансформация в серебро
Size: a a a
2020 December 14
R
@barloc , спасибо! сделаю над одним readStream два разных writeStream:
- приземление сырых данных в бронзу
- парсинг и трансформация в серебро
- приземление сырых данных в бронзу
- парсинг и трансформация в серебро
так у вас bronze и silver разойдется жеж
SS
а ночью spark-batch повторно перельет/перепарсит данные из бронзовой партиции за день
R
смысл то как раз в том что слои работают по цепочке:
sourceToBronze = spark.readStream.format("kafka").load().writeStream.save(bronzeDir)
bronzeToSiver = spark.readStream.load(bronzeDir).apply(myCoolTransformation).save(silverDir)SS
"
spark.readStream.load(bronzeDir)" - вот эту штука эффективно работает над обычной паркет-таблицей/каталогом?R
"
spark.readStream.load(bronzeDir)" - вот эту штука эффективно работает над обычной паркет-таблицей/каталогом?если это S3/ADLS, будет больно от ценника ListFiles вызовов
если это HDFS, в целом не страшно, и вполне норм над паркетом
если это HDFS, в целом не страшно, и вполне норм над паркетом
S
Там были какие то подводные камни на этот счёт, в сстриминге с сурцом хдфс вроде
S
Чисто на вскидку вопрос, а почему не хранить этот самый сырой слой в самой кафке тогда? Репликации такая же, сжатие такое же, данные как есть
S
Если хочется, сделать архивный кластер с большим ретеншном
R
Чисто на вскидку вопрос, а почему не хранить этот самый сырой слой в самой кафке тогда? Репликации такая же, сжатие такое же, данные как есть
в компаниях с клаудом так не делают потому что:
- cloud-based кафка (или аналог) дороже чем object storage (с учетом ценника за сеть)
- потребность в GDPR hard delete where id=XXX
- как управлять правами доступа?
если все онпрем - ну наверное можно, только зачем головняк с настройкой архивного кластера?
- cloud-based кафка (или аналог) дороже чем object storage (с учетом ценника за сеть)
- потребность в GDPR hard delete where id=XXX
- как управлять правами доступа?
если все онпрем - ну наверное можно, только зачем головняк с настройкой архивного кластера?
AZ
в компаниях с клаудом так не делают потому что:
- cloud-based кафка (или аналог) дороже чем object storage (с учетом ценника за сеть)
- потребность в GDPR hard delete where id=XXX
- как управлять правами доступа?
если все онпрем - ну наверное можно, только зачем головняк с настройкой архивного кластера?
- cloud-based кафка (или аналог) дороже чем object storage (с учетом ценника за сеть)
- потребность в GDPR hard delete where id=XXX
- как управлять правами доступа?
если все онпрем - ну наверное можно, только зачем головняк с настройкой архивного кластера?
Кафка давно поддерживает удаление через compacted topic + tombstone
SS
Антон, на вас уповаю! расскажите как по-уму делать
AZ
Вообще «Кафка как база данных» это вполне рабочий паттерн, для определённых применений он набирает популярность
N
Вообще «Кафка как база данных» это вполне рабочий паттерн, для определённых применений он набирает популярность
чем это лучше базы?
AZ
(но узкая ниша, не всем подходит)
AZ
Nikolay
чем это лучше базы?
Смотря какой, но если сравнивать например с обычной SQL MPP - лучше масштабируется под OLTP нагрузку, использует готовую инфру, отдельное масштабирование компьюта даёт гибкость
AZ
Антон, на вас уповаю! расскажите как по-уму делать
Извините, занят сейчас
ИК
тут два момента:
- local checkpointing
- stable storage
локал чейкпонтинг никакого не даст стейбл стораджа
хочешь стейбла используй обычные чекпойнты и персисить их хоть на s3
другое дело что сам механизм чекпойнтов очень нежный
рекавериться можно хоть после кила кластера и заново его создания
- local checkpointing
- stable storage
локал чейкпонтинг никакого не даст стейбл стораджа
хочешь стейбла используй обычные чекпойнты и персисить их хоть на s3
другое дело что сам механизм чекпойнтов очень нежный
рекавериться можно хоть после кила кластера и заново его создания
ИК
@pomadchin, раз уж пошло обсуждение, то в описании локальных чекпоинтов указывается executor storage. Что означает этот термин?
Механизм чекпоинтов нежный, но рекавериться можно после кила и рестора кластера. Как это сочетается одно с другим, или я не уловил сарказма?
Механизм чекпоинтов нежный, но рекавериться можно после кила и рестора кластера. Как это сочетается одно с другим, или я не уловил сарказма?