Os sistemas de dados tendem para a produção

Os últimos dez anos viram uma mudança quase completa nas ferramentas disponíveis para um profissional de dados. Olhando para o Modern Data Stack de hoje, a maioria das ferramentas (dbt, Looker, Snowflake, Fivetran, Hightouch, Census) não estava disponível comercialmente em 2012. Categorias inteiras (ELT, Reverse ETL, armazenamentos em nuvem) e estruturas (ativação de dados, malhas de dados , malhas de dados, contratos de dados) foram criados. (Ou, em alguns casos, práticas de SWE de décadas foram redescobertas por equipes de dados.) Seguidores do Twitter + Substack, projetos de código aberto, carreiras e empresas subiram e desceram. Oportunidade abunda.

A possibilidade e área de superfície para um profissional de dados influenciar a direção de uma empresa é substancialmente maior do que uma década atrás. Infelizmente, a área de superfície do que pode dar errado cresceu com a mesma rapidez. Os desafios variam de SLAs técnicos de baixo nível a sistemas, cultura, padrões e design organizacional de alto nível. As novas ferramentas são incrivelmente poderosas. As empresas podem construir e quebrar sistemas de dados em maior velocidade do que nunca.

Observei três tendências para sistemas de dados nos últimos cinco anos, abrangendo verticais técnicas dentro das equipes de dados, bem como verticais de negócios suportadas por dados. Tentarei descrever essas tendências por meio de exemplos generalizáveis ​​para muitas empresas e, com sorte, descrever oportunidades, problemas e soluções de maneira que generalizem para sua equipe. As tendências, oportunidades, problemas e soluções:

Os sistemas tendem para a produção

• Resumo : trabalho de dados valiosos e saídas acabam sendo consumidos em casos de uso cada vez mais importantes/grau de produção.
• Oportunidade : os resultados de uma equipe de dados podem ser espalhados por uma área de superfície muito maior e mais impactante.
• Problema : como as saídas de dados são consumidas por casos de uso mais importantes, não há um “endurecimento” correspondente dos fluxos de trabalho, que inicialmente foram configurados de maneira muito leve.
• Solução : Crie um caminho para que os fluxos leves sejam promovidos à “produção”, celebre o tempo gasto nos sistemas de endurecimento à medida que avançam para o grau de produção.

• Resumo : as saídas de dados inicialmente destinadas a uma finalidade específica são adotadas cada vez mais e inconscientemente por muitas equipes e casos de uso.
• Oportunidade: insights projetados para um caso de uso específico podem conduzir a uma melhor tomada de decisão/resultados em mais equipes.
• Problema : não há duas equipes com exatamente as mesmas especificações, as melhorias para um caso de uso não são consumidas em outro lugar.
• Solução : crie compromissos de consumidor/produtor + visibilidade das dependências, centralize a lógica de negócios.

• Resumo : os dados podem ser transformados em várias etapas ao longo de sua jornada, a lógica de negócios reside em uma variedade de ferramentas.
• Oportunidade : ferramentas de dados modernas permitem que as partes interessadas acessem dados e executem transformações de última milha para se moverem mais rapidamente e se desbloquearem.
• Problema : a lógica de negócios em toda a pilha torna a reprodutibilidade impossível, as transformações de última milha não beneficiam outros consumidores de dados.
• Solução : reduza as áreas onde a lógica de negócios pode ser injetada, crie políticas de “tempo de vida” nas transformações de última milha, crie uma cultura de padronização + celebração do acesso a bases de código multifuncionais.

Verão 2019 . A ascensão do seltzer cravado é imparável, mas ainda existem alguns donos de lojas de bebidas alcoólicas inconscientes. Você é um engenheiro analítico em um mercado de álcool B2C. Seus gerentes de conta (especialistas em consumo de álcool) SABEM que as Garras voarão das prateleiras, se você conseguir comprá-las nas lojas. Este é o indescritível mercado de melhoria de pareto ganha/ganha/ganha, onde um melhor estoque beneficia o cliente, o varejista e a empresa. Você foi encarregado de descobrir os itens mais vendidos que uma loja de bebidas em sua rede não vende.

1. Uso interno (ferramenta de BI/Looker)

A consulta inicial é fácil de escrever. Há uma tabela de lojas (com market_id, SKUs mais vendidos por mercado e um feed de inventário diário para cada loja). Cada loja tem um feed de inventário diário. Algo assim obtém os itens mais vendidos que cada loja não possui:

select
  s.store_id,
  skus.sku_id,
  skus.market_rank
from dim_stores as s
left join tbl_top_selling_market_skus as skus
  on s.market_id = skus.market_id
left outer join dim_store_inventory as inv
  on s.store_id = inv.store_id
  and inv.sku_id = skus.sku_id
  and inv.remaining_qty > 0
where inv.sku_id is null
order by store_id, skus.market_rank desc
;

…o gerente de conta inicial fornece feedback no painel durante todo o processo.

Nota: A ferramenta de BI é a infraestrutura da equipe de dados. Nenhum insight/caso de uso/produto saiu do domínio da equipe de dados. Um erro tem poucas consequências, o feedback é provável + imediato.

2. Uso interno (Ferramentas Internas / Salesforce)

No entanto, uma equipe de vendas/sucesso do cliente/gerenciamento de contas não passa o dia todo no Looker — eles passam o dia todo no Salesforce. Ter dois navegadores abertos é uma dor. Este é um caso de uso de ETL reverso de livro didático. Coloque os dados onde serão usados . Isso era difícil anos atrás, agora é trivial — assine um provedor ETL reverso, mova seus pontos de dados de A para B em menos de um dia.

Os itens mais vendidos que uma loja não vende agora estão no Salesforce. A equipe de dados adicionou contexto para outra equipe de uma forma de baixo atrito. É disso que se trata a ativação de dados — capacitar outras equipes a fazerem melhor seus trabalhos nas ferramentas com as quais estão familiarizados. Mais gerentes de contas examinam mais itens de estoque ausentes, ligam para mais lojas, mais SKUs importantes chegam às lojas de bebidas, mais vendas ocorrem. Todos ganham.

…um gerente de contas percebe que uma loja de cerveja e vinho tem itens de bebidas alcoólicas em sua lista de itens mais vendidos. O AM usa seu contexto de negócios e ignora a recomendação de itens que eles sabem que a loja não pode vender legalmente. Lógica de negócios adicional foi adicionada por meio de uma camada de decisão humana.

Observação: o Salesforce NÃO é uma infraestrutura de equipe de dados. Insights e casos de uso deixaram o domínio da equipe de dados, mas não da empresa. Nada é voltado para o cliente. Um erro tem poucas consequências, mas o feedback não é garantido. Lógica adicional foi adicionada (via julgamento humano).

3. Uso externo (Automação de Marketing)

A implementação do Salesforce é útil, mas ainda bastante manual por natureza. Gerentes de contas e donos de lojas de bebidas gastam muito tempo ao telefone. A maioria das lojas de bebidas faz pedidos de estoque uma vez por semana. O AM conta com a ajuda de dados e operações de marketing para agilizar a comunicação por meio de e-mails automatizados em uma cadência semanal.

Mais algumas colunas são necessárias, então a tabela bruta é reversa ETL'd em Hubspot / Iterable / Braze. Um associado de CRM dá os toques finais na campanha de e-mail, e uma campanha de e-mail intitulada “Principais itens que você não carrega” é lançada.

…o associado de CRM responsável pelo e-mail avisa que alguns dos itens mais vendidos (por contagem) são goles de álcool. Isso não corresponde à visão da marca da empresa / caso de uso desejado pelo cliente. A maioria dos sistemas de e-mail permite uma camada adicional de lógica - o associado de CRM usa seu julgamento para filtrar todos os itens com volume de 50 ml ou menos.

Nota: Insights e casos de uso deixaram o domínio da equipe de dados e da empresa. As saídas da equipe de dados agora são voltadas para o cliente. Um erro tem consequências maiores, é menos provável que o feedback seja entregue corretamente à parte interessada certa. Lógica de negócios adicional foi adicionada (via transformação de última milha na camada de CRM).

4. Uso externo (Aplicativo de produção)

A equipe de dados ouve a equipe de AM e CRM - algumas lojas de bebidas são bem antigas e não verificam o e-mail. Outras lojas de bebidas são novas e não querem esperar uma semana inteira para receber um e-mail sobre as tendências do mercado. O grupo decide envolver a equipe de aplicativos de varejo para colocar os “Itens principais que você não carrega” no aplicativo de produção que todos os varejistas executam. A equipe de dados move sua saída para um bucket S3 da AWS, onde é coletada pela engenharia de produção. Os funcionários da loja de bebidas agora podem ver essa lista todos os dias, sem a necessidade de gerente de contas ou atrito por e-mail. White Claw e Whispering Angel chegam a todas as lojas da América.

…um varejista faz uma reclamação ao Varejista CX - eles deliberadamente pararam de estocar Smirnoff Peppermint Vodka após as férias. Pode ser literalmente um item L90 mais vendido, mas é extremamente sazonal e eles não querem vê-lo em sua lista de recomendados. Esse feedback chega à equipe de engenharia de produção, que faz um ajuste lógico na camada do aplicativo para identificar e remover itens sazonais anteriores.

Nota: Insights e casos de uso deixaram o domínio da equipe de dados e da empresa. As saídas da equipe de dados são voltadas para o cliente. Um erro tem consequências maiores, o feedback é menos provável de ser entregue à parte interessada certa. Lógica adicional foi incluída (via lógica de negócios na camada de aplicativo de produção).

Uma última hipótese: a equipe de engenharia responsável pelo consumo dos feeds de inventário (diferente da equipe responsável pelo aplicativo do varejista) migra para um novo esquema de inventário. Eles não estão cientes de uma única etapa do projeto “Principais itens que você não carrega”, as dependências que a equipe de dados construiu silenciosamente em cima de seu trabalho ou as dependências que outros construíram em cima do trabalho da equipe de dados. Eles excluem a tabela inicial. NULLs fluem para Looker, Salesforce, Hubspot e o aplicativo de varejo de produção. A equipe de dados quebrou o prod.

Vamos recapitular o que aconteceu, bom e ruim:

Do ponto de vista de um profissional de dados que iniciou sua carreira antes da “ativação de dados”, tudo o que acabou de acontecer (exceto o final) é incrível! O que começou como um painel do Looker se transformou rapidamente em um aplicativo de produção, com valor comercial demonstrado em cada etapa. Nenhum recurso de SWE foi necessário até o final, quando o produto sugerido já havia sido validado pelos usuários.

O impacto e a trajetória de carreira de um profissional de dados são limitados pela área de superfície que eles podem influenciar. O analista de inteligência de negócios de 2012 foi limitado no Tableau + apresentações internas. O profissional de dados de hoje PODE colocar linhas no Salesforce, acionar e-mails de marketing e criar produtos de dados para consumo em serviços e aplicativos de produção. Esta é uma notícia incrível!

Do lado ruim: o profissional de dados de dez anos atrás estava acostumado com mensagens “Ei, os dados parecem estranhos”. O pior cenário foi colocar métricas erradas em um deck de tabuleiro. Hoje, a equipe de dados pode acordar com as notificações do Pagerduty de que eles quebraram o Salesforce, o Hubspot e o aplicativo de produção, se o Pagerduty estiver configurado . A ativação de dados aumentou as apostas do que uma equipe de dados pode quebrar.

Nesse caso hipotético, os gerentes de lojas e contas ficarão aborrecidos por um ou dois dias até que o erro seja corrigido. Considerando tudo — esse erro é relativamente gratuito.

Isso não significa que não pode ser caro! Imagine uma saída de ciência de dados que preveja a rotatividade de clientes e um código promocional de $ 5 seja enviado quando essa probabilidade ultrapassar um determinado limite. Agora, imagine que o modelo foi retreinado incorretamente, ou recalibrado, ou realmente qualquer coisa. Os mesmos canais de ativação de dados podem ser usados ​​para enviar inadvertidamente milhões de dólares em códigos promocionais.

A pilha de dados moderna torna incrivelmente fácil produzir as saídas de dados — independentemente se elas devem ser produzidas ou se a equipe que construiu as entradas sabe como as saídas estão sendo consumidas. Essas ferramentas não exigem que a consulta inicial ou o pipeline sejam fortalecidos, pois são elevados a casos de uso mais importantes. Eles não requerem o consentimento ou visibilidade daqueles que construíram a produção inicial.

Se você se lembra da lógica de negócios adicional:

• O gerente de contas usou seu julgamento e deixou de recomendar SKUs de bebidas para lojas de cerveja/vinho
• O associado de CRM removeu SKUs <= 50ml devido a considerações de marca
• A equipe de aplicativos do varejista removeu SKUs altamente sazonais devido ao feedback do cliente

Então, o que podemos fazer para corrigir esses problemas?

Sistemas Tendem à Produção

As histórias de terror, problemas generalizados e soluções técnicas para sistemas de produção foram escritos de forma eloquente no twitter de dados e no substack. As soluções são, em grande parte, as melhores práticas que os SWEs conhecem há décadas (ou, como Zach Kanter disse de outra forma , a engenharia de dados do status quo é apenas engenharia de software sem as melhores práticas ). Algumas das peças/princípios que mais me marcaram para as equipes de dados:

As equipes de dados não controlam suas entradas (h/t Nick Schrock )

As saídas de dados são a base de muitas decisões nas organizações, independentemente de um ser humano ou um algoritmo ser o responsável. No entanto, as equipes de dados não controlam suas entradas da mesma forma que os engenheiros de software. As equipes de dados devem ser defensivas em seus cálculos, investindo em controle de qualidade; para questões passadas, bem como para problemas que ainda não ocorreram. Este teste deve incluir:

• Validade de linhas únicas ( intquando você espera um int, <50 quando você espera <50)
• Validade de linhas agregadas (suposições de granularidade, contexto de negócios em torno de contagens de linhas, contagens de linhas relativas a ontem, distribuições de agregações como somas, médias, p90s, medianas)
• Existência/desatualização de dados (as últimas tabelas de tempo foram atualizadas)

O custo de um erro é exponencialmente maior em um sistema de produção do que em um estágio. Crie pipelines de teste de dados e padrões de desenvolvimento + implantação que detectam erros e testam suposições o mais cedo possível.

Essas são soluções que podem ser implementadas por equipes de dados que escolhem as ferramentas certas (nós gostamos de Grandes Expectativas ) e se esforçam. Isso é 20% do problema. Os 80% restantes de desafios organizacionais + de comunicação são o que causa a quebra dos sistemas. Aqui estão as soluções para toda a empresa:

Crie escapes de dados de nível de produção

Ou crie dados . As empresas que acreditam que a ciência de dados é poderosa também devem acreditar na criação deliberada de dados de produção para potencializar casos de uso de aprendizado de máquina e análises avançadas (h/t Yali Sasoon). Isso requer parceria com engenheiros e um alinhamento de toda a empresa para que os dados possam ser criados deliberadamente, não extraídos dolorosamente.

Crie e celebre um caminho para a produção

As empresas frequentemente comemoram iterações rápidas em um ambiente de desenvolvimento sem obter orientação ou tempo para endurecer esse trabalho em direção à produção. Celebre este trabalho e reserve tempo explícito entre funções e propriedade para fortalecer os sistemas.

Os sistemas tendem para uma federação cega

Mais uma vez — vamos celebrar este problema! Se muitas pessoas encontrarem diferentes casos de uso de negócios para saídas da equipe de dados, você está fazendo algo certo. Mas, da mesma forma que algum painel ad-hoc poderia se transformar em um painel de controle 10 anos atrás, essa consulta ad-hoc pode se transformar em um aplicativo de produção sem que você saiba.

Aproveite um único plano de controle para orquestração orientada a eventos

Fivetran, dbt e Hightouch têm a capacidade de agendar tarefas por meio de agendas cron e interface do usuário. Isso permite que a orquestração seja criada de maneiras que não atrapalhem a visibilidade de dependências implícitas. Imagine que o Hightouch está programado para se mover exp_fb_click_idstodos os dias às 8h por meio da interface do usuário. Fivetran e dbt não têm visibilidade dessa dependência, nem aqueles que contribuem para as bases de código upstream do Hightouch.

Em vez disso, use uma ferramenta de orquestração (Dagster/Prefect/Airflow) como um único plano de controle. Mescle as dependências entre as ferramentas e crie um DAG holístico executado com base nos sucessos das etapas anteriores, em vez de esperar que as tarefas upstream sejam bem-sucedidas em um determinado horário do dia. Reempacotar .

Crie mapeamentos um-para-um das exportações da equipe de dados para casos de uso downstream

As equipes de dados devem estar familiarizadas com as sugestões de dbt para estruturar projetos . Normalmente, a camada de preparação é organizada e nomeada de forma a tornar extremamente clara a relação um-para-um com as entradas de origem. Use um padrão semelhante para saídas. Da mesma forma que deve ser óbvio que o objeto Salesforce Opportunity e Account representam uma tabela dbt na preparação, deve ser óbvio que as exportações de dados são usadas para um e apenas um caso de uso.

select * -- Extremely clear this comes from one and only one place
from raw.salesforce.opportunity
;

select * -- Extremely clear this comes from one and only one place
from raw.salesforce.account
;

select * -- Extremely clear this goes to one and only one place
from ml_outputs.model_results.exp_top_items_retailer_app
;

select * -- Extremely clear this goes to one and only one place
from ml_outputs.model_results.exp_top_items_salesfrce
;

Em vez de resumir a layerinite, vou direcioná-lo novamente para o maravilhoso tópico e definição de Jean-Michel Lemieux. O conselho geral é dele, com alguns dados específicos que funcionaram para mim.

A definição técnica para layerinitis é que as equipes colocam o código onde se sentem mais confortáveis, otimizando a velocidade, em vez de colocar o código onde ele pertence ao considerar uma perspectiva de longo prazo no sistema geral de software.

Reduza as áreas onde a lógica de negócios pode ser injetada na última milha:

Hightouch e Census permitem transformações SQL. Fivetran costumava . A maioria dos consumidores de ativação de dados (CRMs de vendas/CX, CDPs) permite uma camada lógica de negócios SQL ou com pouco/sem código. Sempre que possível, não escreva lógica de negócios nessas ferramentas. Se você seguir o mapeamento um-para-um das exportações da equipe de dados para casos de uso downstream, seu ETL reverso sempre poderá ser:

select * from exp_table_for_single_use_case;

As alterações na lógica de negócios devem ser aplicadas a esse modelo de dbt, em vez de na última milha.

Crie políticas “Time To Live” nas transformações de última milha:

Uma equipe de dados não pode se livrar totalmente das transformações de última milha. Você não quer que seus stakeholders se sintam bloqueados pela equipe de dados. Sempre haverá a necessidade de introduzir hot fixes ou iterar na lógica de negócios que seja mais rápida do que uma atualização dbt PR + Snowflake.

De forma mais geral, as partes interessadas do seu negócio têm um contexto que você não tem. Você quer ver como eles estão alterando seus dados. Pense no SKU sazonal, no volume e na lógica de categorização da loja que o engenheiro de análise perdeu. Crie um mundo onde os stakeholders do seu negócio possam melhorar o seu trabalho!

Uma política de “tempo para viver” é um retrocesso gravitacional em direção à centralização. Permita transformações de última milha, mas revise-as e coloque a lógica de negócios de volta em uma camada central de dbt/ciência de dados em uma cadência que funcione para sua equipe de dados e partes interessadas nos negócios

Crie uma cultura de padronização + celebração do acesso a bases de código multifuncionais

As pessoas costumam escrever a lógica de negócios na ferramenta com a qual se sentem mais à vontade. Para um associado de CRM, isso pode ser Hubspot / Iterable / Braze. A melhor maneira para as equipes de dados evitarem a expansão da lógica de negócios não é apenas limitar as transformações de última milha em outras ferramentas, mas também convidar outras pessoas para suas ferramentas.

Isso pode ser uma tomada ️️️. Há muitos motivos para se preocupar com membros da equipe que não são de dados escrevendo lógica em SQL e fazendo PRs de dbt. O que posso garantir é que essa lógica será gravada e, se a equipe de dados a controlar, ela será gravada fora de sua visibilidade. Se uma equipe de dados pode educar e incentivar contribuições para sua base de código, ela convida o código a ser escrito onde ele mais pertence.

Pousando o avião:

É um ótimo momento para ser um líder de dados. A última década de desenvolvimento do ecossistema de dados comoditizou a movimentação e a manipulação de dados em ferramentas próprias e de terceiros. Um talentoso profissional de análise com um sonho e um cartão de crédito pode alimentar relatórios internos, ferramentas internas, automações de marketing e aplicativos de produção. Esta é uma notícia objetivamente incrível para empresas e profissionais de dados.

• A pilha de dados moderna permite que uma equipe de dados produza qualquer coisa, independentemente de ser ou não, e sem permissão ou visibilidade da engenharia de produção.
• A pilha de dados moderna permite que uma parte interessada de negócios adicione lógica de negócios de última milha para alimentar fluxos de trabalho de produção, independentemente de serem ou não, e sem permissão ou visibilidade da equipe de dados.

Em algum momento, seus produtos de dados interromperão o aplicativo de produção. Serão enviados e-mails de marketing que não deveriam ter sido. A equipe de CRM culpará a equipe de dados, a equipe de dados culpará a equipe de engenharia de produção. Uma das lições mais importantes que aprendi, mas com a qual ainda luto diariamente: a capacidade de entrar em uma sala/Zoom tensa e lembrar a todos que estamos todos no mesmo time é um superpoder. Esse é o verdadeiro resumo de como colocar sistemas de dados em produção.

Se você pode criar uma cultura onde:

• Os engenheiros de produção criam exaustão de dados com intenção e entusiasmo sobre como os dados serão usados
• Os membros da equipe de dados procuram casos de uso, pedem feedback e perguntam às partes interessadas: “Ei, o que você realmente faz com os dados que envio a você?”
• Os SWEs podem orientar e aprimorar as melhores práticas e padrões da equipe de dados para elevar os fluxos de dados ad hoc ao nível de produção
• Os membros da equipe de dados podem orientar e aprimorar as partes interessadas nos negócios sobre como adicionar lógica de negócios, estruturas para onde a lógica pertence
• Cada equipe convida outras pessoas para suas bases de código e incentiva uma perspectiva de longo prazo sobre a arquitetura geral da empresa

Ian Macomber é o chefe de ciência de dados e engenharia analítica da Ramp, o primeiro e único cartão corporativo que ajuda as empresas a gastar menos. Anteriormente, ele foi vice-presidente de análise e engenharia de dados da Drizly.

Há uma quarta tendência também! Fique atento para Data Systems Tend Towards Calculation , que foi um pouco demais para caber em um artigo.