Pull to refresh

Full stack Data analyst

Reading time 3 min
Views 11K

"Анализ данных" часто организован так: вот у нас разработчики хранилища, а вот у нас аналитики. В DWH (data warehouse, хранилище) умеют SQL, а аналитики у нас умеют работать c экселем. Если нам нужно что-то проанализировать, то идете к аналитикам, а они идут за данными к DWH за данными. Вроде бы логично. И многие воспринимают, что это нормальное разделение труда. В этой статье я хочу донести мысль, что это разделение труда ошибочное и грандиозно снижает эффективность и производительность труда всего процесса анализа данных.


Типичный цикл работы по аналитической задаче выглядит так:


  1. Бизнес приходит с проблемой и просит получить ответ.
  2. Аналитики обсуждают с бизнесом, что надо сделать.
  3. Аналитики поняли, что от них хочет бизнес и понимают, что им примерно нужно в данных.
  4. Аналитики пишут запрос в DWH, чтобы получить данные.
  5. DWH берет запрос, читает, спрашивает, уточняет, извлекают данные, отдают.
  6. Аналитики понимают, что взяли не все или их неверно поняли, они пишут снова запрос в DWH, чтобы получить данные.
  7. DWH берет запрос, читает, спрашивает, уточняет, извлекают данные, отдают.
  8. Аналитики понимают, что взяли не все или их неверно поняли, они пишут снова запрос в DWH, чтобы получить данные.
  9. Повторяем п. 7 и п.8

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


Что мы имеем в итоге:


  1. DWH неадекватно покрывает потребности потребителей (ну со стороны DWH выглядит так, что пользователи не знают, что хотят).
  2. Аналитики начинают писать плохие ETL процессы и создают псевдо DWH по своим объемом данных, но без резерва, управлением доступа, с низкой производительностью и т.п.
  3. Взаимодействие DWH и аналитиков страдает, т.к. Одним “плевать” на бизнес смысл, а вторым не комильфо понимать “птичий язык”.
  4. Процесс получения ответа на вопрос бизнеса затягивается, ведь теперь процесс обработки данных — это куча ручной работы за рамками DWH. А зачем мы строили DWH, разве не для того чтобы было одно хранилище?
  5. Мелкие изменения в постановке задачи от бизнеса запускает цикл анализа данных почти с нуля, т.к. DWH вновь не проявит гибкость, а у аналитиков не окажется данных в новом разрезе.

Какое может быть решение? Если вы хотите избавится от проблемы взаимодействия DWH и аналитиков, то вы должны сблизить компетенции DWH и аналитиков. Человек, кто совмещает эти компетенции и можно назвать аналитиком данных.


Что же должен уметь такой Full Stack Data Analyst?


  1. Работать с источниками данных в сыром виде, понимает, как устроено хранение данных.
  2. Сформулировать, что нужно изменить в хранилище в смысле содержания данных, какие данные добавить и как их методологически обрабатывать, чтобы hardcore разработчики DWH могли это имплементировать.
  3. Понять потребности бизнеса, обсудить требования и помочь своему заказчику, внутреннему или внешнему сформулировать проблему и решение к ней.
  4. Уметь дизайнить аналитическое решение, т.е. понять, как решать задачу, какие нужны данные, какие надо “придумать”, какие надо сделать допущения
  5. Уметь визуализировать свои результаты и докладывать своим заказчикам (внутренним или внешним)
  6. Уметь сделать “воспроизводимое” исследование, это такой анализ, который всегда можно повторить на тех же данных и получить тот же результат. Для этого нужно уметь работать с R/python или системами, которые позволяет формализовать процесс анализа.

Если вы совмещаете в одном аналитике технические и аналитические компетенции, то вы получаете действительно цельного сотрудника, кто может решить проблему end-to-end. И это очень важно для аналитических задач, т.к. только у этого аналитика и есть понимание, что он делает и почему. Разделение же на тех, кто “анализирует” и тех, кто “обрабатывает данные” приводит к тому, что каждый из этих сотрудников как инвалид: аналитик как без рук, т.к. ничего не умеет получить и обработать в масштабе, а инженер данных как бы “без мозгов”, т.к. не думает, как это будет использоваться и какие есть гипотезы.


Разделение труда очень важно, но оно должно проходить несколько в иной плоскости. Аналитик должен уметь получить все что ему нужно для анализа, а задача же Data Engineer построить системы, которые эффективно предоставляют данные в любых возможно интересных для аналитика данных разрезах. Для Data Engineer это означает, что данные должны хранится в достаточно гибком виде, но при этом в удобном для использования: частично денормализованные, частично с доступами через кубы, частично предварительно агрегированные и предрассчитанные.


И уж если вы не можете найти для себя Full Stack Analyst, то хотя бы включите в состав команды аналитиков Data Engeneer, чтобы компетенция по работе с данными не была вынесена из анализа во внешнюю службу.


Не дело аналитика данных поддерживать получение данных из API google adwords, но и не дело Data Engeneer писать селект, чтобы получить данные по выручке за прошлый месяц.

Tags:
Hubs:
+6
Comments 7
Comments Comments 7

Articles