Комментарии 6
Мы тоже проходили этот путь :)
Про Marquize не знал, а OpenMetadata и особенно Datahub хороши.
Немного может напугать сложность моделирования своей собственной модели метаданных, но с должным погружением в устройство Datahub всё это реализуемо.
Мы общались с создателями на их townhall встречах и просили улучшить этот вопрос.
Вроде как там сделали улучшения на этот счёт, правда после распада основной команды (уход Марса Лана и реорганизация после этого) всё как-то замедлилось.
Если честно, то по тому что я видел когда с этой темой работал, большинство компаний кто серьёзно и на перспективу хочет себя обеспечить удобной системой каталогизации данных - они форкают что-то event-based (как Datahub или OpenMetadata) или пишут своё.
Это сопоставимые усилия если хочется что-то по-настоящему удобное иметь.
Соглашусь, но когда думаешь о разработке своего, смотришь на задачи, прикидываешь архитектуру и т.д. внезапно понимаешь, что придумал уже имеющееся на рынке и просто берёшь готовое. Да, может немного сложновато будет въехать в чужой и opensource код для доработок, но это экономит уйму времени на первом этапе.
Спасибо за статью!
Небольшой вопрос про недостаткам OpenMetaData:
Добавление или редактирование данных в автоматическом режиме выполняется через отправку AVRO-сообщений в Kafka.
Никак не могу найти у них это в документации. Насколько я знаю, все взаимодействие с OpenMetaData идет через API и какой-то нативной интеграции с Kafka для обновления данных в реал тайме OpenMetaData не предоставляет.
Возможно в каких-то старых версиях это было невозможно. Но вот документация, где коннектор с Kafka описывается. Может вам поможет:
https://docs.open-metadata.org/latest/connectors/messaging/kafka
Хорошая статья. Спасибо автору.
Мы внедрили OpenMetadata в банке (топ-5), в целом довольны. Единственное, в проде сделали две ключевые вещи после тестирования:
базу данных для хранения метаданных заменили с mysql (по-умолчанию) на postgres, так как mysql при работе 200+ пользователей и хранению метаданных по топ-20 систем начинал сильно подтормаживать в целом
Elastic Search нужен отдельный: изначально стартовали на общебанковском, но быстро поняли, что это не самый лучший вариант, так как в момент нагрузки на "елку" поиск в OMD начинал сильно подтормаживать, что было не совсем user friendly
Data catalog: от истории до сравнения решений