Мы уже рассказывали, что на этапе поиска специалистов рекрутерам бывает сложно найти тех самых людей с нужным опытом и стеком для работы с DWH. Во-первых, из-за многообразия “имен”, которыми называют себя специалисты по данным. Во-вторых, из-за размытых границ обязанностей. Часто тот, кто называет себя системным аналитиком DWH, может решать задачи разработчика и наоборот.

Причина путаницы – разность подходов к построению работы с хранилищем. Решение здесь всегда за бизнесом. Определяющими факторами могут быть объем хранилища и количество средств, которые бизнес готов вкладывать в его развитие.

Есть два пути, по которым может строиться работа

1. Аналитик и разработчик DWH – один человек

Так бизнес может получить быстрый результат. Но...

Реальная история – когда за все, от общения с бизнесом и до укладки данных в хранилище и построения витрин, отвечает один человек. Он – и разработка, и поддержка 24/7. Реальные истории – это год работы без выходных и невозможность уехать в отпуск, потому что в любое время дня и ночи может случиться что-то экстренное.

Для владельца хранилища это риск: что делать, если такой сотрудник заболел или решил уйти из команды, не передав дела.

В усеченной команде также может не быть тестировщика, и вся ответственность за результат лежит на аналитике-разработчике. Так сложнее гарантировать, что изменения в хранилище не навредят хранилищу и бизнесу.

2. Аналитика, разработка и тестирование – компетенции разных людей

Высокоорганизованная структура снижает риск критических ошибок и неправильной загрузки данных. Каждый специалист несет ответственность за свою работу. Каждая команда специалистов – за свои задачи в хранилище.

Наша команда придерживается второго способа работы. Мы развиваем хранилища с очень большим объемом данных, поэтому параллельно над задачами работает много команд.

Как выглядит постановка задач в команде

1. Заказчик хочет ввести новый продукт.

2. Бизнес-аналитик расписывает, как.

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

4. Архитектор передает задачу на первичную оценку.

5. Команда аналитиков, разработки и тестирования проводит предварительную оценку задач. Системный аналитик подтверждает объем работ и возвращает бизнесу расчет, сколько нужно времени и людей на задачу.

6. Бизнес считает затраты и запускает разработку.

7. Системный аналитик проверяет, какие объекты нужно изменить, какие ETL перенастроить. После этого аналитик готовит прототип задачи и с ним идет на утверждение. Тим-лиды проверяют правильность подхода аналитика к решению задачи. Если есть замечания, то возвращается на доработку. Если нет, аналитик оформляет ТЗ.

8. ТЗ согласуется с аналитиком, разработкой и заказчиком и переходит в разработку.

9. Разработчик передает готовую задачу в тестирование.

10. Команда экспертов принимает задачу.

Четкий процесс определяет качество результата. На этапах видна принципиальная разница между аналитиком и разработчиком. Аналитик DWH плотно общается с бизнесом, ищет связи в хранилище, создает скрипт и передает его в разработку. Разработчик DWH нужен, чтобы построить выверенный и оптимизированный технический процесс по постановке аналитика.

Сколько нужно команд, зависит от хранилища. Архитектор - ведущее звено, хранитель концепции. Остальной набор специалистов дублируется для работы на разных участках.

Как это помогает улучшить работу хранилища данных?

Например, системный аналитик составил требования. Он определился, что из разных источников необходимо получить данные, написал запрос, который обращается к большому объему данных в разных таблицах и из разных мест получает информацию. И это скрипт на 600 строк. Он работает, но очень медленно.

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

Даже с учетом огромного объема информации долгое время работы запроса – это не всегда приемлемо, бизнес не может столько ждать. И тогда подключается разработчик. Он анализирует узкие места плана запроса и начинает оптимизацию. Таким образом можно сократить время получения данных, например, с 6 часов до 10-15 минут.

Нужно очень четко знать, как внутри работают эти “шестеренки”, как правильно выстроить способ соединения таблиц и т.д. И этим в том числе занимается разработчик DWH.

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

Как команда, которая развивает банковские хранилища данных, мы основываемся на лучших практиках крупных компаний и экспертизе своих специалистов. Опытные разработчики и аналитики подтверждают, что процесс и результат работы в команде с четким разделением ролей – более предсказуемый и стабильный.

Один за всех или каждый занят своим делом? Разбираемся в устройстве команд корпоративных хранилищ данных