"Анализ данных" часто организован так: вот у нас разработчики хранилища, а вот у нас аналитики. В DWH (data warehouse, хранилище) умеют SQL, а аналитики у нас умеют работать c экселем. Если нам нужно что-то проанализировать, то идете к аналитикам, а они идут за данными к DWH за данными. Вроде бы логично. И многие воспринимают, что это нормальное разделение труда. В этой статье я хочу донести мысль, что это разделение труда ошибочное и грандиозно снижает эффективность и производительность труда всего процесса анализа данных.
Типичный цикл работы по аналитической задаче выглядит так:
- Бизнес приходит с проблемой и просит получить ответ.
- Аналитики обсуждают с бизнесом, что надо сделать.
- Аналитики поняли, что от них хочет бизнес и понимают, что им примерно нужно в данных.
- Аналитики пишут запрос в DWH, чтобы получить данные.
- DWH берет запрос, читает, спрашивает, уточняет, извлекают данные, отдают.
- Аналитики понимают, что взяли не все или их неверно поняли, они пишут снова запрос в DWH, чтобы получить данные.
- DWH берет запрос, читает, спрашивает, уточняет, извлекают данные, отдают.
- Аналитики понимают, что взяли не все или их неверно поняли, они пишут снова запрос в DWH, чтобы получить данные.
- Повторяем п. 7 и п.8
Однажды ребята из DWH говорят, что не могут дать данных или не готовы обрабатывать столько запросов от аналитиков. В ответ аналитики начинают копить свои данные в стороне от DWH в каких-то эксельках. Там же они начинают собирать свои ETL процессы, как умеют, на основе того, что они могут получить от DWH “без боя”.
Что мы имеем в итоге:
- DWH неадекватно покрывает потребности потребителей (ну со стороны DWH выглядит так, что пользователи не знают, что хотят).
- Аналитики начинают писать плохие ETL процессы и создают псевдо DWH по своим объемом данных, но без резерва, управлением доступа, с низкой производительностью и т.п.
- Взаимодействие DWH и аналитиков страдает, т.к. Одним “плевать” на бизнес смысл, а вторым не комильфо понимать “птичий язык”.
- Процесс получения ответа на вопрос бизнеса затягивается, ведь теперь процесс обработки данных — это куча ручной работы за рамками DWH. А зачем мы строили DWH, разве не для того чтобы было одно хранилище?
- Мелкие изменения в постановке задачи от бизнеса запускает цикл анализа данных почти с нуля, т.к. DWH вновь не проявит гибкость, а у аналитиков не окажется данных в новом разрезе.
Какое может быть решение? Если вы хотите избавится от проблемы взаимодействия DWH и аналитиков, то вы должны сблизить компетенции DWH и аналитиков. Человек, кто совмещает эти компетенции и можно назвать аналитиком данных.
Что же должен уметь такой Full Stack Data Analyst?
- Работать с источниками данных в сыром виде, понимает, как устроено хранение данных.
- Сформулировать, что нужно изменить в хранилище в смысле содержания данных, какие данные добавить и как их методологически обрабатывать, чтобы hardcore разработчики DWH могли это имплементировать.
- Понять потребности бизнеса, обсудить требования и помочь своему заказчику, внутреннему или внешнему сформулировать проблему и решение к ней.
- Уметь дизайнить аналитическое решение, т.е. понять, как решать задачу, какие нужны данные, какие надо “придумать”, какие надо сделать допущения
- Уметь визуализировать свои результаты и докладывать своим заказчикам (внутренним или внешним)
- Уметь сделать “воспроизводимое” исследование, это такой анализ, который всегда можно повторить на тех же данных и получить тот же результат. Для этого нужно уметь работать с R/python или системами, которые позволяет формализовать процесс анализа.
Если вы совмещаете в одном аналитике технические и аналитические компетенции, то вы получаете действительно цельного сотрудника, кто может решить проблему end-to-end. И это очень важно для аналитических задач, т.к. только у этого аналитика и есть понимание, что он делает и почему. Разделение же на тех, кто “анализирует” и тех, кто “обрабатывает данные” приводит к тому, что каждый из этих сотрудников как инвалид: аналитик как без рук, т.к. ничего не умеет получить и обработать в масштабе, а инженер данных как бы “без мозгов”, т.к. не думает, как это будет использоваться и какие есть гипотезы.
Разделение труда очень важно, но оно должно проходить несколько в иной плоскости. Аналитик должен уметь получить все что ему нужно для анализа, а задача же Data Engineer построить системы, которые эффективно предоставляют данные в любых возможно интересных для аналитика данных разрезах. Для Data Engineer это означает, что данные должны хранится в достаточно гибком виде, но при этом в удобном для использования: частично денормализованные, частично с доступами через кубы, частично предварительно агрегированные и предрассчитанные.
И уж если вы не можете найти для себя Full Stack Analyst, то хотя бы включите в состав команды аналитиков Data Engeneer, чтобы компетенция по работе с данными не была вынесена из анализа во внешнюю службу.
Не дело аналитика данных поддерживать получение данных из API google adwords, но и не дело Data Engeneer писать селект, чтобы получить данные по выручке за прошлый месяц.