A análise de dados geralmente é organizada assim: aqui temos os desenvolvedores do repositório e aqui temos os analistas. No DWH (data warehouse, armazenamento), eles podem SQL e nossos analistas podem trabalhar com o Excel. Se precisarmos analisar alguma coisa, vá aos analistas, e eles vão buscar dados no DWH. Parece ser lógico. E muitos percebem que essa é uma divisão normal do trabalho. Neste artigo, quero transmitir a ideia de que essa divisão do trabalho é errônea e reduz drasticamente a eficiência e a produtividade de todo o processo de análise de dados.
Um ciclo de trabalho típico de um problema analítico se parece com o seguinte:
- Uma empresa surge com um problema e pede uma resposta.
- Os analistas estão discutindo com os negócios o que precisa ser feito.
- Os analistas perceberam que querem negócios com eles e entendem o que precisam aproximadamente nos dados.
- Os analistas escrevem uma consulta no DWH para obter os dados.
- DWH aceita uma solicitação, lê, pede, esclarece, recupera dados, fornece.
- Os analistas entendem que não aceitaram tudo ou os entenderam mal; eles escrevem a solicitação novamente em DWH para obter os dados.
- DWH aceita uma solicitação, lê, pede, esclarece, recupera dados, fornece.
- Os analistas entendem que não aceitaram tudo ou os entenderam mal; eles escrevem a solicitação novamente em DWH para obter os dados.
- Repita as etapas 7 e 8
Uma vez, os funcionários da DWH dizem que não podem fornecer dados ou não estão prontos para processar tantas solicitações de analistas. Em resposta, os analistas começam a acumular seus dados longe do DWH em algum tipo de excel. Lá eles começam a coletar seus processos de ETL, como podem, com base no que podem obter do DWH "sem luta".
O que temos como resultado:
- O DWH não cobre adequadamente as necessidades dos consumidores (bem, por parte do DWH, parece que os usuários não sabem o que querem).
- Os analistas começam a escrever maus processos de ETL e a criar pseudo DWHs de acordo com o volume de dados, mas sem reserva, controle de acesso, baixo desempenho etc.
- A interação de DWH e analistas sofre porque Um não dá a mínima para os negócios e o segundo não entende como a linguagem dos pássaros.
- O processo de obter uma resposta para uma pergunta comercial está atrasado, porque agora o processo de processamento de dados é um monte de trabalho manual fora do DWH. E por que criamos o DWH, exceto por um único repositório?
- Pequenas mudanças na declaração do problema dos negócios iniciam o ciclo de análise de dados de quase zero, porque O DWH novamente não mostrará flexibilidade e os analistas não terão dados em um novo contexto.
Qual poderia ser a solução? Se você deseja se livrar do problema de interação entre DWH e analistas, deve aproximar as competências de DWH e analistas. Uma pessoa que combina essas competências pode ser chamada de analista de dados.
O que um analista de dados do Full Stack deve fazer?
- Trabalhar com fontes de dados brutos, entende como o armazenamento de dados funciona.
- Para formular o que precisa ser alterado no repositório em termos de conteúdo de dados, quais dados adicionar e como processá-los metodologicamente, para que desenvolvedores DWH hardcore possam implementá-los.
- Entenda as necessidades dos negócios, discuta os requisitos e ajude seu cliente, interno ou externo, a formular um problema e uma solução para ele.
- Ser capaz de projetar uma solução analítica, ou seja, entender como resolver o problema, quais dados são necessários, o que precisa ser "inventado", que suposições precisam ser feitas
- Ser capaz de visualizar seus resultados e reportar aos seus clientes (internos ou externos)
- Para poder fazer um estudo "reproduzível", esta é uma análise que sempre pode ser repetida nos mesmos dados e obter o mesmo resultado. Para fazer isso, você precisa poder trabalhar com R / python ou sistemas que permitam formalizar o processo de análise.
Se você combinar competências técnicas e analíticas em uma única análise, terá um funcionário verdadeiramente integral que poderá resolver o problema de ponta a ponta. E isso é muito importante para tarefas analíticas, como somente esse analista entende o que está fazendo e por quê. A divisão entre quem "analisa" e quem "processa os dados" leva ao fato de que cada um desses funcionários está desativado: o analista está sem mãos, porque não é possível obter e processar nada em escala, e o engenheiro de dados está "sem cérebro", por assim dizer. Ele não pensa em como será usado e que hipóteses existem.
A divisão do trabalho é muito importante, mas deve ocorrer em um plano um pouco diferente. O analista deve ser capaz de obter tudo o que precisa para análise, e a tarefa do engenheiro de dados é criar sistemas que forneçam dados efetivamente em todas as seções possíveis de interesse para o analista. Para o Data Engineer, isso significa que os dados devem ser armazenados de forma bastante flexível, mas ao mesmo tempo de forma conveniente para uso: parcialmente desnormalizados, parcialmente com acesso por cubos, parcialmente pré-agregados e calculados.
E se você não conseguir encontrar o Full Stack Analyst, inclua pelo menos o Data Engeneer na equipe de análise, para que a competência no trabalho com dados não seja transferida da análise para um serviço externo.
Não é da conta do analista de dados oferecer suporte à recuperação de dados da API do google adwords, mas não é da conta da Data Engeneer escrever uma seleção para obter dados sobre a receita do mês passado.