Minha equipe de dados de inicialização precisa de um engenheiro de dados?

O papel do engenheiro de dados em uma equipe de dados de inicialização está mudando rapidamente. Você está pensando nisso da maneira certa?

Tristan Handy Blocked Desbloquear Seguir Seguindo 3 de janeiro

Eu me encontro regularmente conversando com líderes de análise que estão estruturando o papel dos engenheiros de dados de sua equipe de acordo com um modelo mental desatualizado. Esse erro pode prejudicar significativamente toda a sua equipe de dados e gostaríamos que mais empresas evitassem esse resultado.

Este post representa minhas crenças sobre quando, como e por que você deve contratar engenheiros de dados como parte de sua equipe. É baseado na minha experiência na Fishtown Analytics trabalhando com mais de 100 startups apoiadas pelo VC para construir suas equipes de dados e em conversas com centenas de empresas na comunidade de dados mais ampla.

Se você executar uma equipe de dados em uma inicialização suportada pelo VC, esta postagem foi escrita para você.

A função do engenheiro de dados está mudando.

O software está cada vez mais automatizando as partes chatas da engenharia de dados.

Em 2012, se você quisesse ter uma prática sofisticada de análise em sua inicialização apoiada por um VC, você precisava de um ou mais engenheiros de dados. Esses engenheiros eram responsáveis por extrair dados de seus sistemas operacionais e canalizá-los em algum lugar que os analistas e os usuários de negócios pudessem obter. Muitas vezes, eles fariam algum trabalho de transformação para facilitar a análise dos dados. Sem os engenheiros de dados, os analistas e os cientistas não tinham nenhum dado para trabalhar, então, com frequência, os engenheiros eram os primeiros membros de uma nova equipe de dados.

Chegando em 2019, você pode comprar tecnologias off-the-shelf para fazer a maior parte desse trabalho. Na maioria dos cenários, você e seus analistas de dados e cientistas poderiam construir o pipeline inteiro sem a necessidade de qualquer pessoa com experiência em dados pesados . E você não estaria construindo um pipeline de merda de segunda categoria: as ferramentas prontas para uso são, na verdade, a melhor maneira de resolver esses problemas hoje em dia.

Essa capacidade de analistas de dados e cientistas de construir pipelines de auto-atendimento é nova – cerca de 2 a 3 anos de idade neste momento. O driver disso são três produtos específicos: Stitch , Fivetran e dbt . Inicialmente, esses produtos foram lançados após o lançamento do Amazon Redshift, quando as equipes de dados de inicialização descobriram uma tremenda fome latente para construir data warehouses. Levou vários anos para os produtos ficarem bons – embora em 2016 ainda estivéssemos em terras pioneiras.

Neste ponto, um pipeline construído em cima de Stitch / Fivetran / dbt é muito mais confiável do que um construído em cima de tarefas Airflow customizadas. Esta é uma afirmação empírica, não teórica: não estou dizendo que não é possível construir uma infra-estrutura de fluxo de ar confiável, só estou dizendo que a maioria das startups não. Na Fishtown Analytics, trabalhamos com mais de 100 equipes de dados apoiadas por VC e vimos isso acontecer repetidas vezes. Estamos constantemente migrando pessoas de pipelines customizados para uma infraestrutura pronta para uso e, literalmente, em todos os casos, o impacto foi tremendamente positivo.

Engenheiros não devem escrever ETL.

Em 2016, Jeff Magnusson escreveu um post de blogue fundamental chamado Engineers Shouldn't Write ETL . Foi o primeiro post que eu estou ciente de onde alguém chamou essa mudança. Aqui está a minha parte favorita:

As ferramentas e tecnologias de processamento de dados evoluíram maciçamente nos últimos cinco anos. A menos que você precise processar muitos petabytes de dados, ou esteja ingerindo centenas de bilhões de eventos por dia, a maioria das tecnologias evoluiu a um ponto em que elas podem ser dimensionadas de acordo com as suas necessidades .

A menos que você precise ampliar os limites do que essas tecnologias são capazes, você provavelmente não precisará de uma equipe altamente especializada de engenheiros dedicados para construir soluções sobre eles. Se você conseguir contratá-los, eles ficarão entediados. Se eles estão entediados, eles vão deixar você para o Google, Facebook, LinkedIn, Twitter, … – lugares onde a sua experiência é realmente necessária. Se eles não estão entediados, as chances são de que eles são muito medíocres. Engenheiros medíocres realmente se superam em construir enormemente em complicados problemas com o trabalho que eles chamam de “soluções”.

Eu amo muito essa seção porque ela não apenas destaca por que você não precisa de engenheiros de dados para resolver a maioria dos problemas de ETL hoje, ela também declara porque é melhor você não pedir a eles para resolver esses problemas .

Se você contratar um engenheiro de dados e pedir que ele construa pipelines, eles pensarão que seu trabalho é construir pipelines. Isso significará que ferramentas como Stitch e Fivetran e dbt parecerão ameaças à sua existência, em vez de tremendos multiplicadores de força. Eles encontrarão razões para que os pipelines de prateleira não atendam às suas necessidades de dados muito personalizadas e às razões pelas quais os analistas não deveriam estar construindo suas próprias transformações de dados. Eles escrevem código que é frágil, difícil de manter e não performante. E você vai confiar nesse código porque está abaixo de tudo que seu time faz.

Evite esta situação como a peste. O ritmo de inovação em sua equipe de dados irá despencar e você gastará todo o seu tempo pensando em problemas de infraestrutura que não são realmente geradores de receita para os negócios.

Se não ETL, então … O que?

Então, você ainda precisa de engenheiros de dados na sua equipe de dados de inicialização? Você faz.

Mesmo com a disponibilidade de novas ferramentas que capacitam analistas de dados e cientistas a construir pipelines de autoatendimento, os engenheiros de dados ainda são parte essencial de qualquer equipe de dados de alto desempenho . No entanto, as tarefas em que devem se concentrar mudaram, assim como o seqüenciamento em que você as contrata. Vou discutir a questão “quando” em uma seção posterior; por enquanto, vamos falar sobre o que os engenheiros de dados são responsáveis pelas modernas equipes de dados de inicialização.

Engenheiros de dados ainda são uma parte crítica de qualquer equipe de dados de alto desempenho.

Em vez de construir pipelines de processamento que estão disponíveis no mercado e implementando transformações de dados baseadas em SQL, aqui está o foco dos seus engenheiros de dados:

  • gerenciar e otimizar a infraestrutura de dados principais,
  • construção e manutenção de oleodutos personalizados,
  • suporte aos recursos da equipe de dados com otimização de design e desempenho e
  • construindo pipelines de transformação não SQL.

Gerenciando e otimizando a infra-estrutura de dados principal

Embora os engenheiros de dados não precisem mais gerenciar clusters do Hadoop ou dimensionar hardware para o Vertica em startups apoiadas por VC, ainda há uma engenharia real a ser feita nessa área. Certificar-se de que sua tecnologia de dados está operando em seu pico resulta em melhorias massivas de desempenho, custo ou ambos. Isso normalmente envolve:

  • construir infra-estrutura de monitoramento para dar visibilidade ao status do duto,
  • monitorar todos os trabalhos para impacto no desempenho do cluster,
  • executando rotinas de manutenção regularmente,
  • esquemas de tabelas de ajuste (ou seja, partições, compressão, distribuição) para minimizar os custos e maximizar o desempenho, e
  • desenvolvimento de infraestrutura de dados personalizada não disponível no mercado.

Esses tipos de esforços são frequentemente negligenciados nos estágios iniciais da maturidade de uma equipe de dados, mas se tornam incrivelmente importantes à medida que a equipe e o conjunto de dados crescem. Em um projeto, conseguimos reduzir os custos do BigQuery para construir uma tabela de forma incremental de US $ 500 / dia para US $ 1 / dia otimizando as partições de tabela. Isso é importante.

Uma empresa que seguiu esse caminho é a Uber. Os engenheiros de dados da Uber construíram uma ferramenta chamada Queryparser que monitora automaticamente todas as consultas executadas em sua infraestrutura de dados e reúne estatísticas sobre os recursos utilizados e os padrões de utilização. Os engenheiros de dados da Uber podem usar metadados para ajustar a infraestrutura de acordo.

Os engenheiros de dados também são frequentemente responsáveis pela criação e manutenção do pipeline de CI / CD que executa a infraestrutura de dados. Enquanto muitas equipes de dados tinham VCS extremamente ruim, gerenciamento de ambiente e infraestrutura de testes em 2012, isso está mudando, e os engenheiros de dados estão liderando essa carga.

Por fim, engenheiros de dados em empresas líderes também estão envolvidos na construção de ferramentas que não existem no mercado. Por exemplo, os engenheiros de dados da Airbnb criaram o Airflow porque não tinham como construir e agendar de forma eficaz os DAGs. E os engenheiros de dados da Netflix são responsáveis por criar e manter uma infraestrutura sofisticada para desenvolver e executar dezenas de milhares de notebooks Jupyter .

Você pode obter a maior parte de sua infraestrutura básica atualmente, mas alguém ainda precisa monitorá-la e garantir que ela esteja funcionando. E se você for realmente uma organização de dados de ponta, provavelmente vai querer ultrapassar os limites do ferramental existente. Os engenheiros de dados podem ajudar com ambos.

Construir e manter pipelines de ingestão

Embora os engenheiros de dados não precisem mais transferir manualmente o transporte de dados do Postgres ou do Salesforce, existem “apenas” cerca de 100 integrações disponíveis no mercado dos fornecedores modernos de integração de dados. A maioria das empresas com as quais trabalhamos tem uma cobertura de 75 a 90% das fontes de dados com as quais trabalham.

Na prática, as integrações são implementadas em ondas. Normalmente, a primeira fase inclui o banco de dados principal de aplicativos e o rastreamento de eventos, com a segunda fase incluindo sistemas de marketing, como plataformas ESP e de publicidade. Estas duas primeiras fases estão disponíveis completamente fora da prateleira hoje. Depois que você for mais fundo em seus fornecedores de SaaS mais específicos de domínio, precisará de engenheiros de dados para criar e manter esses pipelines de ingestão de dados mais específicos.

Por exemplo, as empresas de comércio eletrônico acabam lidando com uma tonelada de produtos diferentes no domínio de ERP / logística / expedição. Muitos desses produtos são muito específicos para verticais particulares, e quase nenhum deles está disponível na prateleira. Espere que seus engenheiros de dados construam isso no futuro previsível.

Construir e manter pipelines de ingestão confiáveis é difícil. Se você decidir gastar os recursos para construir um, espere que ele leve mais tempo do que o inicialmente orçado e espere que ele exija mais manutenção do que gostaria. Chegar à V1 é fácil, mas é difícil conseguir um canal para fornecer dados consistentemente ao seu warehouse. Não se comprometa a dar suporte a um pipeline de processamento de dados personalizado até ter certeza de que o caso de negócios está lá. Depois disso, invista o tempo e construa-o para ser robusto. Considere o uso do framework Singer de código aberto do Stitch – nós construímos ~ 20 integrações personalizadas usando-o.

Suporte a recursos de equipe de dados com otimização de design e desempenho para transformações SQL

Uma das mudanças que vimos na engenharia de dados nos últimos cinco anos é a ascensão do ELT: o novo sabor do ETL que transforma os dados depois de serem carregados no warehouse em vez de antes. O que e o porquê dessa mudança estão bem cobertos em outros lugares; A razão pela qual menciono aqui é que essa mudança tem um tremendo impacto sobre quem constrói esses oleodutos .

Se você estiver escrevendo código Scalding para varrer terabytes de dados de eventos no S3 e agregá-los a um nível de sessão para que possam ser carregados no Vertica, você provavelmente precisará de um engenheiro de dados para escrever esse trabalho. No entanto, se os dados dos seus eventos já estiverem no BigQuery (carregados pelo Google Analytics 360), eles já serão totalmente endereçáveis em um ambiente escalonável e de alto desempenho. A diferença é que esse ambiente fala SQL . Isso significa que os analistas de dados podem agora construir seus próprios pipelines de transformação de dados .

Essa tendência começou com a versão do recurso do Viewer em 2014. Ela avançou de forma agressiva com equipes de dados inteiras construindo DAGs de mais de 500 nós e processando conjuntos de dados de várias TB usando dbt nos últimos dois anos. Nesse ponto, o padrão está profundamente arraigado nas equipes de dados modernas e permitiu que os analistas se auto-servissem de uma maneira que nunca puderam antes.

Essa mudança para o ELT significa que os engenheiros de dados não precisam criar a maioria dos trabalhos de transformação de dados . Isso também significa que as equipes de dados sem engenheiros de dados ainda podem percorrer um longo caminho com as ferramentas de transformação de dados criadas para os analistas. Os engenheiros de dados ainda têm um papel significativo a desempenhar na construção desses pipelines de transformação. Existem duas áreas principais onde os engenheiros de dados devem se envolver:

  1. Quando o desempenho é crítico.
    Às vezes, a lógica de negócios requer alguma transformação particularmente pesada, e é útil ter um engenheiro de dados envolvido para avaliar as implicações de desempenho de uma abordagem específica para construir uma tabela. Muitos analistas não são profundamente experientes com a otimização do desempenho dentro dos bancos de dados analíticos do MPP e essa é uma ótima oportunidade de colaboração com alguém mais técnico.
  2. Quando o código fica complicado.
    Os analistas são ótimos para responder perguntas de negócios usando dados, mas freqüentemente não são treinados para pensar em como escrever código extensível. É muito fácil começar a criar tabelas em seu depósito e fazer com que todo o projeto fique fora de controle rapidamente. Faça com que um engenheiro de dados se envolva pensando na arquitetura geral do seu depósito e faça revisões de design em transformações particularmente perniciosas ou você se encontrará com uma tigela de espaguete para limpar.

Crie pipelines de transformação não SQL

Embora o SQL possa realizar nativamente a maioria das necessidades de transformação de dados, ele não pode lidar com tudo. Uma necessidade comum é fazer o enriquecimento geo tomando um lat / long e atribuindo uma determinada região. No momento, isso não é amplamente suportado em bancos de dados analíticos MPP modernos (embora isso esteja começando a mudar !), Então a melhor resposta é escrever um pipeline baseado em Python que aumente os dados em seu warehouse com informações de região.

O outro caso de uso óbvio para Python (ou outras linguagens não SQL) é para o treinamento de algoritmo. Se você tiver um recomendador de produto, um modelo de previsão de demanda ou um algoritmo de previsão de cancelamento que coleta dados de seu warehouse e gera uma série de ponderações, você deverá executá-lo como um nó no final de seu DAG baseado em SQL.

A maioria das empresas que estão executando um desses tipos de cargas de trabalho não-SQL hoje está usando o Airflow para orquestrar todo o DAG. O dbt é usado para a parte baseada em SQL do DAG e, em seguida, os nós não SQL são adicionados no final. Essa abordagem fornece o melhor resultado de ambos os mundos, no qual os analistas de dados ainda podem ser os principais responsáveis pelas transformações baseadas em SQL, enquanto os engenheiros de dados podem ser responsáveis pelo código ML de nível de produção.

Quando minha equipe precisa de um engenheiro de dados?

Esta mudança no papel também informa um repensar do seqüenciamento de contratações de engenheiro de dados. A opinião aceita anteriormente era de que você precisava de engenheiros de dados primeiro, porque os analistas de dados e os cientistas não tinham nada com quem trabalhar se não houvesse uma plataforma de dados. Hoje, os analistas de dados e cientistas devem se auto-servir e construir a primeira versão de sua pilha de dados usando ferramentas prontas para uso. Contrate engenheiros de dados à medida que você começa a atingir os pontos de escala:

  • Ponto de escala nº 1: considere contratar seu primeiro engenheiro de dados quando tiver 3 analistas de dados / cientistas em sua equipe.
  • Ponto de escala nº 2 : considere contratar seu primeiro engenheiro de dados quando tiver 50 usuários ativos de sua plataforma de BI.
  • Ponto de escala nº 3: considere contratar seu primeiro engenheiro de dados quando a maior tabela do seu depósito atingir 1 bilhão de linhas.
  • Ponto de escala nº 4: considere contratar seu primeiro engenheiro de dados quando souber que precisará construir três ou mais pipelines de processamento de dados personalizados nos próximos trimestres e todos eles serão de missão crítica.

Se você não atingiu nenhum desses pontos, seus analistas de dados e cientistas provavelmente conseguirão se auto-utilizar usando tecnologia de prateleira, suporte de consultores externos e conselhos das comunidades de dados das quais você faz parte ( como o Locally Optimistic e dbt Slacks !).

A principal coisa a perceber é que os engenheiros de dados não fornecem valor comercial direto – seu valor está em tornar seus analistas de dados e cientistas mais produtivos . Seus analistas de dados e cientistas são os que trabalham com as partes interessadas, medem os KPIs e criam relatórios e modelos – são eles que ajudam sua empresa a tomar decisões melhores todos os dias. Contrate engenheiros de dados para atuar como um multiplicador para a equipe mais ampla: se adicionar um engenheiro de dados fará com que seus quatro analistas de dados sejam 33% mais eficientes, essa é provavelmente uma boa decisão.

Os engenheiros de dados fornecem valor comercial, tornando seus analistas de dados e cientistas mais produtivos.

Conforme você dimensiona sua equipe de dados, eu geralmente vejo que a proporção que funciona melhor é de cerca de 5 analistas de dados / cientistas para 1 engenheiro de dados. Se você estiver trabalhando com conjuntos de dados particularmente grandes ou incomuns, talvez essa proporção mude, mas é uma boa referência.

Quem você deve contratar?

À medida que o papel do engenheiro de dados muda, o mesmo acontece com o perfil do candidato ideal. Meu estimado colega Michael Kaminsky colocou isso melhor do que eu jamais poderia em um e-mail que trocamos sobre esse assunto, então vou citá-lo aqui:

A maneira como penso sobre essa mudança é uma mudança no papel da engenharia de dados na equipe. Passou de um construtor de infra-estrutura para uma função de suporte à equipe de dados mais ampla. Na verdade, é uma mudança muito grande e que alguns engenheiros de dados (que querem se concentrar na criação de infraestrutura) nem sempre estão empolgados.

Na verdade, acho que isso é importante para as startups apreciarem: elas precisam contratar um engenheiro de dados que esteja entusiasmado com a criação de ferramentas para a equipe de análise / DS . Se você contratar um engenheiro de dados que só quer se meter no back-end e odiar trabalhar com pessoas menos técnicas, você terá um mau momento. Eu procuro engenheiros de dados que estão entusiasmados em fazer parceria com analistas e cientistas de dados e têm o olho para dizer “o que você está fazendo parece realmente ineficiente, e eu quero construir algo para torná-lo melhor”.

Eu não poderia concordar mais com esse sentimento. Os melhores engenheiros de dados nas startups atuais são os players de suporte envolvidos em quase tudo que a equipe de dados faz. Eles devem estar empolgados com essa função colaborativa e motivados para que toda a equipe seja bem-sucedida.