а в каких кейсах нужна SR?

Когда есть более-менее стабильная схема

Источник Ваши данные генерит по схеме, или просто дампит какие-то хэшмапы в Json и посылает вам?

то есть меняется не чаще раза в месяц ?

дампит коллекции/документы из Mongo

Может меняться и чаще, но важно чтобы источник также придерживался схемы, пусть она и меняется.. по факту вы придумываете схему на каждое сообщение (или пачку) а потом эти повышенные обязательства которые сами себе придумали несёте и пытаетесь исполнять дальше

то есть пока поставщики данных не будут сами обновлять схему перед изменением своих продюсеров - нечего и пытаться в это влезать?

Если коллекции с валидатором по схеме и validationAction=error то тогда можно подумать про SR,  иначе - нет

Да, строгую схему выводить на своей стороне не нужно; но аналитику все равно как-то надо делать, поэтому обычно мы договариваемся с такими товарищами не о схеме, а о наборе соглашений, конвенций, какие атрибуты в каком виде должны быть, какие опциональные (и как трактовать их отсутствие)... эти конвенции мы уже приводим к схеме, отбрасывая все о чем мы не знаем (суть паттерна tolerant reader), но сырые данные тогда точно придётся хранить, они гораздо чаще нужны

сырые данные, безусловно, храним!
Антон, спасибо за развернутые ответы!

У нас там схемы для чтения avro формата лежат. Он и жмётся лучше жсона, и структурировано что-то на входе

Всем привет. Ребят достался мне в наследство небольшой scala приклад. Читает из hbase, выполняет небольшие преобразования, делит выборку на несколько логических блоков и каждый блок пишет в parquet файл. Объемы смешные - 200-300 Мб. Но выполняется это по несколько часов. Например так:

Может кто подскажет в какую сторону можно начать "копать"?

Начни с того как он читает с hbase

Мы используем как фиксированный контракт с пользователями данных а требуемой информации (Сырые данные лежат отдельно на всякий случай) а схема говорит о том что аналитикам нужно из сырья, и служит основанием для создания таблиц в RDB. Если просто брать JSon то таблицы надо будет пересоздавать динамически, ну или при обработке сразу идти от таблиц (что показалось не хорошей идеей лазить постоянно в базу смотреть что там за таблица, показалось что это лучше вынести в специализированный инструмент) Ну и кроме того схема реджистри позволяет жить с мультиформатом, по хорошему без разницы что у тебя за данные в источнике JSON CSV AVRO (даже местами XML) ты можешь описать их в схеме. А ну и да мы тоже зачастую внутри потоков данных используем AVRO.

Можно подробнее? что может быть не так?

А залоггировать операции и смотреть логи с экзекьюторов нынче немодно?

Вы можете вычитывать всю таблицу и на спарке ее фильтровать

Модно. Пока не нашел там ничего, что могло бы прояснить ситуацию. Но у меня и доступ к кластеру и логам ограничен, к сожалению. Параллельно пытаюсь решить и эту проблему, но пока приходится работать как с черным ящиком.