Роли вокруг модели данных
С моделью данных в компании работает не один человек. Над ней трудятся несколько ролей, и у каждой своя зона ответственности, свой уровень модели и свой набор инструментов. Понимать это деление важно по двум причинам. Во-первых, вы выбираете, кем стать, — и должны видеть, чем эти роли отличаются. Во-вторых, в работе вы будете взаимодействовать с другими ролями, и надо знать, кто за что отвечает, чтобы не дублировать чужую работу и не ронять её на пол.
Сразу важная оговорка: роль и должность — не одно и то же. В маленькой компании один человек может играть все роли сразу. В большой каждая роль — это отдельная команда. Дальше мы говорим про роли как про наборы ответственности, а не про строчки в штатном расписании.
Четыре роли вокруг модели
Разберём четыре ключевые роли, расставив их по тому, на каком уровне модели они в основном работают.
Data modeler
Data modeler (специалист по моделированию данных) — роль, для которой моделирование является основной задачей. Data modeler работает в основном на conceptual и logical уровнях: общается с бизнесом, выделяет сущности и связи, проектирует строгую структуру, проводит нормализацию, выбирает ключи, поддерживает корпоративный словарь данных.
Как отдельная должность data modeler чаще встречается в крупных организациях — банках, телекоме, корпорациях с большими и сложными данными. В компаниях поменьше эту работу выполняют data engineer, analytics engineer или backend-разработчик. Но сама работа — проектирование модели — никуда не девается; она просто распределяется между другими ролями. Именно поэтому навык моделирования нужен всем перечисленным ниже.
Data engineer
Data engineer (инженер данных) отвечает за инфраструктуру и конвейеры данных. Его зона:
- хранилища данных и базы — поднять, настроить, поддерживать;
- конвейеры (pipelines) — перемещение данных из источников в хранилище;
- оркестрация — расписание и зависимости задач (Airflow, Dagster и подобные);
- потоковая обработка, интеграция систем.
По отношению к модели data engineer чаще работает на physical-уровне: реализует спроектированную структуру в реальной инфраструктуре, наполняет её данными. Но в командах без отдельного data modeler инженер данных и проектирует модель тоже. Это типичная стартовая роль для входа в работу с данными, и моделирование — её обязательный навык.
Analytics engineer
Analytics engineer (аналитический инженер) — роль на стыке инженерии и аналитики, оформившаяся в профессию около 2018-2019 годов вместе с инструментом dbt. Его задача — превращать сырые данные в хранилище в чистые, надёжные, удобные для аналитики таблицы.
Чем занимается analytics engineer:
- моделирует аналитический слой — проектирует star schema, dimension- и fact-таблицы;
- пишет трансформации на SQL (как правило, в dbt);
- покрывает данные тестами и документацией;
- применяет инженерные практики: версионирование, code review, CI.
Analytics engineer много занимается размерным моделированием — это прямо его инструмент. Вся вторая половина курса — это, по сути, его профессиональная область. Он не поднимает инфраструктуру (это data engineer) и не строит дашборды (это аналитик) — он отвечает за модель аналитического слоя.
Analytics engineering и роль dbtDBA
DBA (database administrator, администратор баз данных) отвечает за эксплуатацию СУБД — за то, чтобы база работала надёжно, быстро и безопасно. Его зона:
- производительность: настройка движка, проектирование и поддержка индексов, анализ медленных запросов;
- надёжность: резервное копирование, восстановление, репликация, доступность;
- безопасность: права доступа, шифрование, аудит;
- сопровождение: обновления СУБД, мониторинг.
DBA работает глубоко в physical-уровне модели. Он обычно не проектирует логическую структуру с нуля, но критически на неё влияет: подсказывает, какие индексы нужны, где структура породит проблемы с производительностью, как партиционировать большие таблицы. Хороший data modeler советуется с DBA ещё на этапе логической модели.
Зачем нужны индексы: взгляд DBA на производительностьКто на каком уровне модели
Соберём роли и уровни модели (из урока про три уровня) в одну таблицу.
| Роль | Основной уровень модели | Главная ответственность | Типичные инструменты |
|---|---|---|---|
| Data modeler | Conceptual, logical | Проектирование модели, словарь данных | ER-редакторы, dbdiagram, нотации |
| Data engineer | Physical (и logical в малых командах) | Конвейеры, хранилище, оркестрация | Airflow, Spark, SQL, облачные хранилища |
| Analytics engineer | Logical и physical аналитики | Моделирование аналитического слоя | dbt, SQL, warehouse |
| DBA | Physical (эксплуатация) | Производительность, надёжность, безопасность | Инструменты СУБД, мониторинг, EXPLAIN |
Видно, что роли покрывают модель сверху донизу: data modeler начинает наверху, data engineer и analytics engineer реализуют середину и низ, DBA отвечает за эксплуатацию самого низа. Ни одна роль не покрывает всё — поэтому они и взаимодействуют.
Как роли взаимодействуют
Хорошая модель данных — результат сотрудничества. Типичный поток на примере новой аналитической потребности бизнеса:
- Бизнес формулирует потребность: «нужен отчёт по выручке».
- Data modeler (или тот, кто играет эту роль) уточняет требования, проектирует или дополняет conceptual/logical модель.
- Data engineer обеспечивает, чтобы нужные сырые данные доезжали до хранилища.
- Analytics engineer моделирует аналитический слой — star schema под этот отчёт — и пишет трансформации.
- DBA следит, чтобы запросы к этим данным были производительными, советует индексы.
- Аналитик/BI строит на готовых данных сам отчёт.
Главный риск на стыках ролей — «работа упала на пол»: каждый думал, что задачу делает другой. Классический пример — индексы под аналитический запрос: data engineer думает, что это забота DBA, DBA — что analytics engineer заложил их при моделировании. Поэтому важно явно понимать границы ролей и проговаривать, кто что делает. Размытая зона ответственности дороже, чем кажется.
Смежные роли вокруг данных
Кроме четырёх ролей, напрямую работающих с моделью, рядом есть смежные роли — с ними тоже придётся взаимодействовать, и полезно понимать их место.
Data analyst / BI-специалист. Работает на готовых данных: строит дашборды, считает метрики, отвечает на ad-hoc вопросы бизнеса в Tableau, Power BI, Metabase. Аналитик — потребитель модели, а не её создатель. Но именно его запросы и потребности задают требования, под которые модель проектируется, поэтому хороший проектировщик внимательно слушает аналитиков.
Backend-разработчик. Пишет приложение и проектирует базу данных под него — то есть занимается OLTP-моделированием, часто не называя это так. В компании без отдельного data modeler схему приложения проектирует именно backend-разработчик. Поэтому материал первой половины курса напрямую применим в backend-разработке.
Data scientist / ML-инженер. Обучает модели машинного обучения. Он — требовательный потребитель данных: качество и структура данных напрямую влияют на качество ML-моделей. Плохо смоделированные данные означают плохие признаки (features) и плохие предсказания.
Граница «создатели — потребители» не жёсткая: потребности потребителей становятся требованиями для создателей, и хорошая модель рождается в этом диалоге.
Почему моделирование нужно всем этим ролям
Может показаться, что моделирование данных — забота только data modeler. Это не так. Data engineer проектирует модель, когда отдельного modeler нет. Analytics engineer моделирует аналитический слой каждый день. DBA должен понимать логическую модель, чтобы грамотно её обслуживать. Даже backend-разработчик проектирует схему базы своего приложения.
Поэтому неважно, какую из ролей вы выберете на старте карьеры в данных — моделирование будет частью вашей работы. Этот курс даёт навык, общий для всех перечисленных профессий. Освоив его, вы получаете фундамент, на который дальше ляжет специализация в любую из ролей.
Попробуй сам
Выпишите четыре роли из урока и для каждой одной фразой сформулируйте её главную ответственность и основной уровень модели, на котором она работает. Затем подумайте о знакомой вам компании или команде (можно гипотетической): какие из этих ролей в ней есть как отдельные должности, а какие совмещены в одном человеке? Если знаете кого-то, кто работает с данными, прикиньте, какие из четырёх ролей он на себе совмещает. Наконец, честно ответьте себе: какая из ролей кажется вам интересной для собственной карьеры и почему — и обратите внимание, что моделирование данных понадобится в любой из них.