Data mesh

Data mesh — это подход к архитектуре аналитических данных, переносящий владение данными с единой центральной команды на доменные команды, которые эти данные порождают, и требующий от каждой такой команды публиковать свои данные как продукт: с документированным интерфейсом, названным владельцем и уровнем сервиса. Это прежде всего организационный дизайн; технологии под ним по большей части те же самые хранилища, озёра и конвейеры, что и в централизованных схемах. Подход отвечает на конкретный режим отказа центральной команды данных. По мере роста компании она становится узким местом: владеет конвейерами для доменов, которых не понимает, её бэклог растёт быстрее штата, а когда исходная система меняется, ей никто не сообщает, потому что команда-производитель не знает о существовании конвейера. Качество падает структурно, а не из-за нехватки усилий: люди, понимающие данные, не те же, кто за них отвечает. У mesh обычно называют четыре принципа: доменное владение данными, данные как продукт, самообслуживаемая инфраструктура и федеративное управление. На практике основную работу делают второй и третий. Относиться к данным как к продукту означает, что команда платежей публикует набор данных о платежах со схемным контрактом, метаданными для обнаружения, ожиданиями по качеству и ответственным человеком на случай поломки — теми же обязательствами, которые команда приняла бы для API. Самообслуживаемая инфраструктура означает, что центральная платформенная группа никуда не исчезает, но строит асфальтированную дорогу, а не конвейеры: хранение, оркестрацию, каталогизацию, контроль доступа и мониторинг, которыми доменные команды пользуются, не запрашивая платформенную работу под каждый новый набор данных. Федеративное управление оставляет сквозные правила — классификации приватности, сроки хранения, именование, совместимость — глобальными, а содержание локальным. Mesh не является выбором по умолчанию. Он несёт реальные накладные расходы и предполагает, что у доменных команд есть инженерная ёмкость и желание вести продукты данных, что ниже определённого размера компании часто неверно; хорошо работающая центральная команда обычно оказывается лучшим ответом для компании поменьше. Практическое замечание: внедряйте постепенно, сделав сначала один высоконагруженный набор данных настоящим продуктом — контракт, владелец, SLA, документация — и посмотрите, вытянет ли это команда-производитель, прежде чем что-то перестраивать.