Коллеги,

Как только команда DWH/BI разрастается до нескольких человек возникает вопрос, как её структурировать.

Чаще всего видел такие варианты.

1. Вертикально по направлениям: пара человек на продажи, один на склад и т.д. Каждый пилит всё: выгрузку из источников, семантический слой и отчеты.

2. Горизонтально по функционалу. Пара-тройка человек на ETL, пара-тройка на кубы или модели и отчеты.

(Тестеры, аналитики и руководство пусть остануться за скобками)

Один раз встретил экзотику, когда хранилище пилили одни люди, а модели и кубы строили аналитики в бизнес-подразделениях.

Какой у вас опыт?
Что наиболее оптимально? (Может уже всё совсем по-другому в новых проектах, а я отстал от жизни)

Критикa_voroninПри вертикальном делении команды, также придется делить само DWH. Располодится куча дублей данных, но каждый будет решать свою задачу.

Не расплодится (при наличии архитектурной группы, с которой согласовываются модели данных по направлениям).
А по сути вариант 1, но с применением варианта 2 (для студентов, или разработчиков, которые кодят как студенты)

При варианте два я уже видел не раз, что хранилище превращают в "болото данных", постоянно добавляя что-то новое не имея возможности удалить, т.к. чистые ETL-щики сидят очень далеко от бизнеса. Часто поддерживаются загрузжи для давно умерших подразделений и т.д.

Alex_496tarrus,

преимущественно распределение такое, основные моменты

1.
Руководитель = он же Data архитектор = он же бизнес аналитик по некоторым ключевым направлениям
Исследует, понимает потребности бизнеса, готовит модель данных, глоссарий, требования по DWH/ETL/BI/MDM, ведет карту мэппингов, распределение задач,
также моделирует многомерную модель,
архитектуру и правила MDM


2.
ETL архитектор = он же ведущий разработчик ETL + несколько ETL-щиков

ETL-щики: системный анализ источников с полным погружением (разделение по предметным областям/подобластям), разработка и тестирование ETL (по карте мэппингов), далее сопровождение и разбор инцидентов по прилетающим данным

ETL архитектор: системный анализ источников с полным погружением, разработка и тестирование ETL (по карте мэппингов), оркестровка, всего data-интеграционного проекта, контроль за этим проектом, администрирование серверов


3.
Разработчики отчетов:
Анализ потребностей бизнеса в части отчетов, согласование методик, разработка алгоритмов и отчетов, оптимизация отчетов (по количеству/качеству наполнения/производительности/удобству), разбор инцидентов по отчетам


и 2 и 3 погружаются и концентрируются в предметных областях; все пожелания по улучшению моделей сообщают 1.
Модель-центричная организация.
Ничего лишнего: ни лишних серверов, баз, таблиц, кубов, отчетов, никаких болот
Болота начинаются там где: Agile/Scrum, безбашенные срочно и вчера и всё сразу, жадность, интриги и включение посторонних людей

Да, пожалуй, это наиболее устойчивая модель, если всё идет хорошо, но также она наиболее уязвима при изменениях. Люди увольняются, приоритеты меняются, да и Agile или на-Agile выбрать тоже не удается. Плюс поиск квалифицированных людей и ввод их в строй сильно затягивается.

.ЕвгенийtarrusДа, пожалуй, это наиболее устойчивая модель, если всё идет хорошо, но также она наиболее уязвима при изменениях. Люди увольняются, приоритеты меняются, да и Agile или на-Agile выбрать тоже не удается. Плюс поиск квалифицированных людей и ввод их в строй сильно затягивается.
Ну-ну.
В первом случае человек должен быть фуллстеком (одинаково хорошо знать SQL, ETL, Reporting и OLAP). Во втором - хватит любой половины перечисленного. Поиск людей, говорите?
Сужение предметной области для айтишника вторично, особенно при наличии аналитиков. А если вспомнить про необходимость подмены коллег, то сужение оборачивается сплошной фикцией.

Не уловил вашу мысль. Я имел ввиду, что искать фуллстекера тяжело. Хороший базист воротит нос от отчетов. OLAP-девелопер смотрит с высока на базистов и т.п.

.Евгенийtarrusпропущено...


Не уловил вашу мысль. Я имел ввиду, что искать фуллстекера тяжело. Хороший базист воротит нос от отчетов. OLAP-девелопер смотрит с высока на базистов и т.п.
Еще раз. Вы предложили два варианта структурирования: первый вертикальный (по направлениям бизнеса), второй горизонтальный (по функционалу ИТ).
Alex_496 высказался за разделение на ETL и Reporting - т.е. за второй вариант.
Вы отметили, что данный вариант уязвим и проблемен для подбора персонала.
Я возражаю, что проблемен как раз первый вариант.

Я не предложил, это просто мой опыт работы и то, что я вижу у клиентов сейчас. Я считаю, что оба варианта уязвимы и интересуюсь опытом других.

StarikNavytarrus считаю, что оба варианта уязвимы и интересуюсь опытом других.
да, у обоих вариантов свои плюсы и свои минусы. как и в любой области.

у нас сейчас тоже пытаюстся скрестить эти два варианты (типа разрабы должны быть универсальны во всех областях). скрещение идет со скрипом ии не очень (то что мне делать 5 минут, коллеге приходится делать полдня, потому что надо вникнуть и разобраться)

Я вижу, что всё чаще выгрузки из источников расслаиваются на три потока.

Первый поток: DWH+BI

Второй поток: Продвинутые бизнес пользователи с новыми тулами вроде Power BI.

Третий: Статистики/дата-саинтесты.


Эти потоки слабо пересекаются, хотя конечно возможны варианты. Область DWH+BI из-за этого сужается, ну соответственно требования к разрабам падают. Это видно у многих крупных клиентов.

StarikNavytarrus требования к разрабам падают
ага за последнее время надо было срочно учить новые знания по 4 новым продуктам, а требования оказываются падают ))

Везет вам. Хотел бы попасть в такую команду. Я в среднем по больнице смотрю.