Muitas vezes encontramos artigos legais em inglês que parecem úteis para nossa equipe e decidimos que seria ótimo compartilhar sua tradução com os leitores de Habra. Hoje preparamos a tradução de um artigo de Tristan Handy, fundador da Fishtown Analytics.
O papel de um engenheiro de dados em startups modernas está mudando rapidamente. Tem certeza de que entende bem quando e por que sua equipe pode precisar de um especialista?
Costumo me comunicar com os principais representantes do mundo analítico e percebo que a compreensão do papel de um engenheiro de dados em uma equipe não é verdadeira. Isso pode criar dificuldades para toda a equipe de análise de dados, e eu gostaria que as empresas aprendessem a evitar esses problemas.
Neste artigo, quero compartilhar minhas idéias sobre quando, como e por que vale a pena contratar um engenheiro de dados. Meu raciocínio é baseado na minha experiência na Fishtown Analytics , onde trabalhei com mais de cem startups com suporte a capital de risco e as ajudei a construir equipes de análise e processamento de dados, além do conhecimento adquirido através da comunicação com representantes de várias empresas de processamento de dados.
Se você está liderando uma equipe de especialistas em dados, esta postagem é para você.
O papel de um engenheiro de dados está mudando
O software moderno torna possível automatizar trabalhos mais chatos relacionados à análise e processamento de dados.
Em 2012, foi necessário pelo menos um engenheiro de dados para analisar todo o conjunto de dados em uma startup de capital de risco. Esse especialista teve que extrair dados de diferentes sistemas para que analistas e clientes corporativos pudessem trabalhar com eles ainda mais. Muitas vezes, era necessário transformar os dados de alguma maneira para facilitar a análise. Sem um engenheiro de dados, os especialistas em análise e processamento de dados simplesmente não teriam os dados com os quais poderiam trabalhar, tantas vezes foi com o engenheiro de dados que a equipe começou a se formar.
Até 2019, a maior parte disso poderá ser feita com soluções prontas. Na maioria dos casos, você e uma equipe de analistas podem criar um pipeline de processamento de dados por conta própria, sem a ajuda de uma pessoa com vasta experiência em ciência de dados. E esse pipeline não será de todo ruim - as ferramentas prontas e modernas são perfeitas para resolver esses problemas.
Analistas e cientistas de dados recentemente tiveram a oportunidade de construir oleodutos - apenas 2-3 anos atrás. Isso aconteceu principalmente devido a três produtos: Stitch , Fivetran e dbt (vale dizer que o dbt é um produto da minha empresa, a Fishtown Analytics). Eles foram lançados quase imediatamente após o Amazon Redshift, quando as equipes de inicialização perceberam que precisavam criar data warehouses. Levou vários anos para fabricar esses produtos de alta qualidade - em 2016 ainda éramos pioneiros.
Agora, um pipeline construído usando Stitch, Fivetran ou dbt é muito mais confiável do que o projetado especialmente usando o Airflow. Eu sei disso não pela teoria, mas por minha própria experiência. Não estou dizendo que é impossível construir uma infraestrutura confiável com o Airflow, a maioria das startups simplesmente não faz isso. No Fishtown Analytics, trabalhamos com mais de uma centena de equipes de análise em diferentes startups, e esse cenário foi repetido várias vezes. Ajudamos constantemente as pessoas a mudarem de seus próprios pipelines para soluções chave na mão, e cada vez que o efeito é positivo.
O engenheiro de dados não deve gravar ETL
Em 2016, Jeff Magnusson escreveu um post fundamental: Os engenheiros de dados não devem escrever ETL . Este foi o primeiro post em minha memória que exigiu essa mudança. Aqui está a minha parte favorita de lá:
* “Nos últimos 5 anos, as ferramentas e tecnologias de processamento de dados evoluíram. A maioria das tecnologias já desenvolveu tanto que pode se adaptar às suas necessidades, a menos que, é claro, você precise processar petabytes de dados ou bilhões de eventos por dia.
Se você não precisar ir além dos recursos dessas tecnologias, provavelmente não precisará de uma equipe de programadores altamente especializados para desenvolver soluções adicionais.
Se você conseguir contratá-los, eles logo ficarão entediados. Se eles ficarem entediados, deixarão você no Google, Facebook, LinkedIn, Twitter - os lugares onde a experiência deles é realmente necessária. Se eles não estão entediados, provavelmente são medíocres. E programadores medíocres realmente conseguiram criar uma quantidade enorme de coisas complicadas e inadequadas para as bobagens normais do trabalho, que eles chamam de "soluções". "*
Eu realmente gosto dessa citação, porque enfatiza não apenas que hoje você não precisa de engenheiros de dados para resolver a maioria dos problemas de ETL, mas também explica por que é melhor você não pedir a eles que resolvam esses problemas .
Se você contratar engenheiros de dados e solicitar que construam um pipeline, eles pensarão que sua tarefa é construir um pipeline. Isso significa que ferramentas como Stitch, Fivetran e dbt serão uma ameaça para eles, não uma poderosa fonte de força. Eles encontrarão razões pelas quais os pipelines concluídos não atendem às suas necessidades individuais de dados e por que os analistas não devem se envolver de forma independente na conversão de dados. Eles escreverão um código que será frágil, difícil de manter e ineficiente. E você confiará nesse código, porque está subjacente a tudo o que sua equipe faz.
Fuja de especialistas como a praga. A taxa de crescimento em sua equipe de analistas cairá acentuadamente e você gastará todo o seu tempo na solução de problemas de infraestrutura, e não é isso que gera renda para os seus negócios.
Se não ETL, então o que?
Sua equipe realmente precisa de um engenheiro de dados? Sim
Mesmo com novas ferramentas que permitem que analistas de dados e especialistas em ciência de dados criem pipelines, os engenheiros de dados ainda são uma parte importante de qualquer equipe de dados profissional. No entanto, as tarefas nas quais eles devem trabalhar mudaram e a sequência na qual vale a pena contratar funcionários para trabalhar com dados. Abaixo, vou falar sobre quando fazer isso, e agora vamos falar sobre o que os engenheiros de dados nas startups modernas são responsáveis.
Os engenheiros de dados ainda são uma parte importante de qualquer equipe de dados profissional.
Seus engenheiros de dados não devem criar pipelines para os quais já existem soluções prontas e gravar transformações de dados SQL. Aqui está o que eles devem focar:
- organização e otimização da infraestrutura de dados subjacente,
- construção e suporte de gasodutos personalizados,
- suporte de uma equipe de especialistas em dados, melhorando o design e o desempenho de pipelines e consultas,
- construindo transformações de dados não SQL.
Organização e otimização da infraestrutura de dados subjacente
Embora os engenheiros de dados nas startups não precisem mais gerenciar clusters do Hadoop ou configurar equipamentos para o Vertica, ainda é necessário trabalho nessa área. Depois de garantir que sua tecnologia para coletar, transmitir e processar dados esteja no auge, você obtém uma melhoria significativa no desempenho, nos custos ou em ambos. Isso geralmente envolve as seguintes tarefas:
- criação de uma infraestrutura de monitoramento para rastrear o status dos oleodutos,
- monitoramento de todas as tarefas que afetam o desempenho do cluster,
- manutenção regular
- esquemas de tabelas de ajuste (particionamento, compactação, distribuição) para minimizar custos e aumentar a produtividade,
- desenvolvimento de infraestrutura de dados personalizada quando não houver soluções prontas.
Essas tarefas geralmente são negligenciadas nos estágios iniciais do desenvolvimento, mas se tornam críticas à medida que a equipe cresce e a quantidade de dados. Em um projeto, conseguimos reduzir gradualmente o custo de construção de uma tabela no BigQuery de US $ 500 para US $ 1 por dia, otimizando as partições da tabela. Isso é realmente importante.
O Uber é um bom exemplo de empresa que conseguiu. Os especialistas em processamento de dados da Uber criaram uma ferramenta chamada Queryparser que rastreia automaticamente todas as solicitações de sua infraestrutura de dados e coleta estatísticas sobre os recursos utilizados e os padrões de uso. Os engenheiros da Uber Data podem usar metadados para personalizar a infraestrutura.
Os engenheiros de dados também são frequentemente responsáveis por criar e manter o pipeline de CI / CD que gerencia a infraestrutura de dados. Em 2012, muitas empresas tinham uma infraestrutura muito fraca para controle, gerenciamento e teste de versão, mas agora tudo está mudando, e é isso que os engenheiros de dados estão por trás.
Por fim, os engenheiros de dados das principais empresas geralmente participam da criação de ferramentas que não existem prontas. Por exemplo, os engenheiros da Airbnb criaram o Airflow porque não tinham como gerar eficientemente digrafos de processamento de dados . E os engenheiros da Netflix são responsáveis por criar e manter uma infra-estrutura sofisticada para desenvolver e operar dezenas de milhares de Jupyter Notebooks .
Você pode simplesmente comprar a maior parte da sua infraestrutura básica, mas alguém ainda deve fazer a manutenção. E se você é uma empresa verdadeiramente progressista, provavelmente deseja expandir os recursos das ferramentas existentes. Os engenheiros de dados podem ajudar com ambos.
Construindo e mantendo pipelines personalizados
Embora os engenheiros de dados não precisem mais transferir dados manualmente para o Postgres ou o Salesforce, os fornecedores têm "apenas" cerca de 100 opções de integração. A maioria dos nossos clientes pode chegar imediatamente a 75 a 90% das fontes de dados com as quais trabalha.
Na prática, a integração é realizada por ondas. Normalmente, o primeiro estágio inclui o banco de dados principal do aplicativo e o rastreamento de eventos, e o segundo estágio inclui sistemas de marketing, como ESP e plataformas de publicidade. Hoje, soluções turnkey para as duas fases já estão disponíveis para venda. Ao se aprofundar no trabalho com dados de fornecedores de SaaS em sua área de assunto, você precisará de engenheiros de dados para criar e manter esses núcleos de processamento de dados.
Por exemplo, as empresas que realizam vendas pela Internet interagem com diversos produtos na área de ERP, logística e entrega. Muitos desses produtos são muito específicos e quase nenhum deles está disponível comercialmente. Espere de seus engenheiros de dados que eles criarão produtos similares em um futuro próximo.
Construir e manter pipelines confiáveis de processamento de dados é uma tarefa difícil. Se você decidir investir seus recursos na criação deles, esteja preparado para exigir mais fundos do que o inicialmente previsto no orçamento, e a manutenção também exigirá mais esforço do que o planejado. A primeira versão do pipeline pode ser criada de maneira simples, mas é difícil manter a consistência dos dados em seu armazenamento. Não se comprometa a manter seu próprio pipeline de processamento de dados até ter certeza de que sua empresa está funcionando. Depois de fazer isso, reserve um tempo para torná-lo confiável. Pense em usar o Singer, a estrutura de código aberto dos criadores do Stitch, que construímos cerca de 20 integrações.
Suporte a uma equipe de especialistas em dados, melhorando o design e o desempenho de pipelines e consultas
Uma das mudanças que vimos no campo da engenharia de dados nos últimos cinco anos é o surgimento do ELT - uma nova versão do ETL, que converte dados após carregá-los no armazenamento, e não antes. A essência e as causas dessa mudança já estão bem abordadas em outras fontes. Quero enfatizar que essa mudança tem um enorme impacto sobre quem constrói esses oleodutos.
Se você escrever um código no Scalding para verificar terabytes de dados de eventos no S3 e depois enviá-los para o Vertica, provavelmente precisará de um engenheiro de dados. Mas se os dados do seu evento (exportados do Google Analytics 360) já estiverem no BigQuery, eles já estarão totalmente disponíveis em um ambiente escalável e de alto desempenho. A diferença é que esse ambiente fala SQL. Isso significa que os analistas agora podem criar seus próprios pipelines de transformação de dados.
Essa tendência se desenvolveu em 2014, quando a Looker lançou a ferramenta PDT . A tendência se intensificou quando equipes inteiras de especialistas em dados começaram a criar dígrafos de processamento de dados a partir de mais de 500 nós e processar grandes conjuntos de dados usando dbt nos últimos dois anos. Nesta fase, o modelo está profundamente enraizado nas equipes modernas e deu aos analistas tanta independência quanto sempre.
Mudar para o ELT significa que os engenheiros de dados não precisam mais executar a maioria das tarefas de conversão de dados . Isso também significa que equipes sem engenheiros podem percorrer um longo caminho usando ferramentas de transformação de dados projetadas para analistas. No entanto, os engenheiros de dados ainda desempenham um papel importante na construção de pipelines de conversão de dados. Existem duas situações em que sua participação é extremamente importante:
1. Quando você precisa aumentar a produtividade
Às vezes, a lógica de um processo de negócios requer uma transformação particularmente complexa e é útil envolver um engenheiro de dados para avaliar como uma abordagem específica para criar uma tabela afeta o desempenho. Muitos analistas não têm muita experiência em otimizar o desempenho em data warehouses analíticos, e esse é um excelente motivo para começar a trabalhar com um especialista mais restrito.
2. Quando o código fica muito complicado
Os analistas são muito bons em resolver problemas de negócios usando dados, mas geralmente não pensam em como escrever código extensível. À primeira vista, é fácil começar a criar tabelas no banco de dados, mas tudo pode sair rapidamente do controle. Envolva um engenheiro de dados que possa pensar na arquitetura geral do seu armazenamento e desenvolver transformações especialmente complexas; caso contrário, você corre o risco de ficar sozinho com um emaranhado que será quase impossível de desvendar.
Construindo transformações de dados não SQL
O SQL pode inicialmente satisfazer a maioria das necessidades de conversão de dados, mas não pode resolver todos os problemas. Por exemplo, geralmente é necessário adicionar dados geográficos ao banco de dados pegando latitude e longitude e vinculando-os a uma região específica. Muitos repositórios analíticos modernos ainda não conseguem resolver esse problema (embora isso esteja começando a mudar! ). Portanto, a melhor solução seria construir um pipline em Python, que complementará os dados em seu repositório com informações sobre a região.
Outro caso de uso óbvio para Python (ou outras linguagens além do SQL) é para aprendizado de máquina. Se você tiver recomendações personalizadas de produtos, um modelo de previsão de demanda ou um algoritmo de previsão de saída que coleta dados do seu armazenamento e organiza os pesos, você pode adicioná-los como os nós finais do seu dígrafo de processamento de dados SQL.
As empresas mais modernas que resolvem esses problemas usando não-SQL usam o Airflow. O dbt é usado para a parte do dígrafo de dados baseada em SQL e os nós não-SQL são adicionados como folhas. Essa abordagem leva o melhor das duas abordagens - os analistas de dados ainda podem ser os principais responsáveis pelas transformações baseadas em SQL, e os engenheiros de dados podem ser responsáveis pelo código ML para uso industrial.
Quando sua equipe precisa de um engenheiro de dados?
Alterar o papel de um engenheiro de dados também implica repensar a sequência de contratação de funcionários. Anteriormente, acreditava-se que você precisa principalmente de engenheiros de dados, porque analistas e especialistas em ciência de dados não têm nada para trabalhar sem uma plataforma de processamento e análise de dados pronta. Hoje, especialistas em análise e processamento de dados podem trabalhar de forma independente e criar a primeira versão da infraestrutura de dados usando ferramentas prontas. Pense em contratar um engenheiro de dados quando sua inicialização tiver um dos 4 sinais de escala:
- existem 3 analistas / especialistas em ciência de dados em sua equipe,
- sua plataforma de BI tem 50 usuários ativos,
- a maior tabela em seu armazenamento atinge 1 bilhão de linhas,
- Você sabe que precisa criar 3 ou mais pipelines de processamento de dados personalizados nos próximos trimestres, e todos eles são críticos.
Se você ainda não encontrou nenhuma dessas situações, sua equipe de especialistas em dados provavelmente poderá trabalhar de forma independente, usando tecnologias prontas, suporte de consultores externos e conselhos de colegas (por exemplo, nas comunidades Locally Optimistic ou dbt no Slack).
A principal coisa a entender é que um engenheiro de dados por si só não tem valor para os negócios, sua principal tarefa é aumentar a produtividade de seus analistas. , KPI – . - , : , -, 33 %, , , .
, data scientist- .
, , – 5 1: / data science -. , , , .
?
- . , :
« , , - . . , - ( ) .
, – -, / data science. -, , , , . -, : “, , , ”».
. - – , , . .
, , :) . , , , , – - .
, - , – , . , , , !
, Skyeng :
Skyeng 30+ - -. , , . Amazon Redshift , Stitch Matillion ETL 40+ -, Segment , Redash Tableau , Amazon SageMaker ML.
— - . , MVP- , , . , , , Tableau .
, , , - . , , : , .
- -, , , , . 90% , . , Skyeng.