SI
Наверное, проблема тут может быть в том, что должна быть корректная эволюция схемы. Руками json править приведёт рано или поздно к взрыву на месте чтения сырых данных
Size: a a a
2021 August 08
SI
Потому что кто-то захочет int на double поменять или поле удалить
SI
avro и protobuf тут, имхо, отличные решения, только к паркету и парсингу сырых данных их сложно прикрутить
SI
У нас схему публикует в аналитику источник, мы ее тестируем на прямую и обратную совместимость с той, что в проде . Если она ок, то записываем ее и используем, если не ок, то хранилище метаданных алярмами орет, что источник поменял схему несовместимо
G
Могут. Они владельцы данных а мы один из потребителей
SI
avro registry по идёте кайфовое решение в мире, где сырые данные приходят в авро
G
Именно
Поэтому нужна история эволюции схему с тем чтобы поддерживать возможность чтения старых даннвх
Поэтому нужна история эволюции схему с тем чтобы поддерживать возможность чтения старых даннвх
G
Ну вот да но тут не авро
SI
Вот на описанную мной схему это отлично ложится
SI
Можно взять документную бд, и класть в неё схемы, которые прямо конвертируются в спарковый StructType
SI
Но да, это отдельный сервис будет
G
Куда публикует и в какие срок и главно - есть разрыв по срокам между изменением данпых и исправлением кода
SI
Это не проблема, если эволюция схемы прямо и обратно совместимая
SI
В таком случае ты с самой новой схемой сможешь перечитать старые данные
G
Именно так. Я в уелом так и проектировал ситуацию. Впрос был много проще - наличие уже готовой реализации
SI
Если его узнаёшь, буду рад если поделишься)
G
Таки нет такого :)
А на сомом деле - идея на поверхности и многим была бы нужна.
Странно
А на сомом деле - идея на поверхности и многим была бы нужна.
Странно
2021 August 09
NN
@pomadchin тут какой-то стремный физрук
PK
Физруки они такие, ушел в бан
NN
Данке