"Про ~~Data~~ Analytics Engineer Новый год и новый проект заставил вернуться к теме балансировки базовых дата ролей. Вроде казалось, что все ясно, но нет. В больших дата платформах роли формируются нешаблонно. Наблюдение этой недели: - Дата инженер в data mesh модели всегда стремится скрыться от бизнеса в свою ""базу"" - в построение и поддержку инфраструктуры, разработку платформы, тюннинг архитектуры, мониторинг производительности, ETL/ELT первичных интеграций, игры с облачными сервисами, кластерами и контейнерами. - BI аналитик в data mesh модели получает право и обязанность готовить себе данные сам - моделировать раскладку на слои и оптимизировать. Можно добиться того, что Синьорные BI в результате будут делать все от качественного кода и подготовки данных до качественного аналитического продукта и визуала. Но на практике здесь возникает зона для потерь. BI под прессингом бизнес задач, адхоков, коммуникаций оказывается не способен строить и поддерживать сложные инженерные процессы с их постоянным мониторингом и оптимизацией. Заниматься дотошным гавернансом, документацией и датачеками дата слоя без ущерба BI проектам. А без этого мы быстро теряем ""ощущение качества"", и домен погружается в ""костыли"" и непрозрачность. Решение? - Analytics Engineer (термин придумал вроде dbt, еще встречается Business Data Engineer) - как я его понимаю это подтип дата инженера, работающего на бизнес-юнит на задачах от BI и дата аналитиков, задача которого создавать структурированную и качественную среду для работы с данными домена. Он отвечает за - подготовку данных для дашбордов, аналитических моделей. Либо выступая как сервис для BI, либо курируя то что пишут BI, беря на себя самое сложное - работу над метадатой и качеством (метрики покрытия документацией и чекерами) - оптимизацию пайплайнов и причесывание всей ""поляны"" данных домена (метрики usage и переиспользования сертифицированных таблиц) плюс функционал со звездочкой: *выступает продактом для данных в домене - упаковывает сертифицированные объекты в дата-продукты, обеспечивает прозрачное развитие с нотификациями и уровнем сервиса для потребителей из разных доменов. идеально подходит на роль domain data custodian (вспоминаем DG) Фактически это тот же дата инженер, и можно не выделять его в отдельную роль, скажет кто-то. и будет прав. Но отличия есть - в скилах. требуется прогрузка в бизнес-логику - в треке развития. вечная проблема гибридных ролей Еще одна проблема такой роли - это найти на нее людей - приходится искать либо дата инженера, который будет готов работать так близко к бизнесу или хардового биайщика, который всегда мечтал быть инженером. Скорее всего роль неуниверсальна и подходит для определенных сценариев сложных дата платформ. Мы набирали ее в одном желтом банке еще года 4 назад. Эксперимент был успешен. 1 такой внедренный дата инженер напрашивается на домен, где есть как минимум 3 плодовитых биащика. На фото и по ссылке** новый шаблон по этой теме с примером ""разгрузки"" BI роли. Может кому будет полезен. Все ваши примеры решения похожих кейсов из практики - приму с благодарностью. (если вы дочитали пост до конца доставьте + в комментарии 🤔)"