Avançando na qualidade dos dados: explorando contratos de dados com Lyft

Parece que é a parte 2 da minha série sobre qualidade de dados!

Num post anterior , explorei a estratégia da Airbnb para melhorar a qualidade dos dados através de incentivos. Implementaram uma pontuação única e critérios de pontuação claros para estabelecer um entendimento comum entre produtores e consumidores de dados, promovendo um verdadeiro sentimento de apropriação.

Agora, Lyft está adotando uma abordagem distinta, não tentando fazer a mesma coisa de maneira diferente, mas concentrando-se em diferentes aspectos da qualidade dos dados. E a estratégia da Lyft complementa os esforços do Airbnb. Embora eu considere a pontuação DQ do Airbnb (ou qualquer pontuação semelhante) um meio eficaz de consolidar várias tentativas de elevar a qualidade dos dados, a Lyft está enfrentando esse desafio de um ângulo diferente.

A pontuação DQ do Airbnb serve como uma ferramenta valiosa para fornecer uma visualização concreta da qualidade dos dados. Em essência, qualquer iniciativa para melhorar a qualidade dos dados deve manifestar um impacto perceptível nesta pontuação. Por outro lado, Lyft apresenta uma iniciativa possível para melhorar proativamente a qualidade, testando e validando dados de acordo com critérios de qualidade específicos.

Fundamentalmente, é um ponto diferente no ciclo de vida da qualidade dos dados. A introdução de um mecanismo para melhorar a qualidade exige a capacidade de medi-la inicialmente.

Assim, embora o foco do Airbnb esteja em medir e observar a qualidade dos dados, contando com o interesse do produtor em melhorar essa qualidade e “ter uma boa aparência”, a Lyft adota uma abordagem diferente. Lyft coloca ênfase em testar e validar ativamente a qualidade dos dados, fornecendo aos produtores e consumidores os meios para melhorar e controlar efetivamente a qualidade.

Coletivamente, estas abordagens fornecem uma estratégia abrangente para abordar e melhorar a qualidade dos dados ao longo do seu ciclo de vida .

Por esse motivo, fiquei particularmente interessado em examinar mais de perto a abordagem da Lyft.

Outro fator que me intrigou são os testes, mais especificamente, os testes de contrato, que já são utilizados há muitos anos na engenharia básica de software com o surgimento da arquitetura de microsserviços. Os contratos de dados, no entanto, são algo mais recente no domínio da engenharia de dados e são vistos como o ápice ou uma das últimas etapas a serem implementadas no caminho para a construção de pipelines de dados de alta qualidade. É por isso que quis examinar a abordagem de Lyft com mais detalhes e explorar alguns paralelos potenciais.

Conforme mencionado, as abordagens adotadas pelo Airbnb e pelo Lyft são complementares e visam atingir o mesmo objetivo: melhorar a qualidade dos dados.

A Airbnb desenvolveu a pontuação DQ, que se concentra em medir e melhorar 4 aspectos distintos da qualidade dos dados :

O DQ Score tem princípios orientadores, incluindo cobertura total, automação, capacidade de ação, multidimensionalidade e capacidade de evolução. Possui dimensões como Precisão, Confiabilidade, Administração e Usabilidade.

Verity da Lyft é uma plataforma projetada para melhorar a qualidade dos dados em 5 dimensões

Define a qualidade dos dados como a medida de quão bem os dados podem ser usados conforme pretendido, abrangendo aspectos como correção semântica, consistência, integridade, exclusividade, boa formação e atualidade .

É fácil traçar paralelos entre os 5 aspectos de qualidade de dados melhorados pelo Verity da Lyft e as 4 dimensões de qualidade de dados medidas pela pontuação DQ do Airbnb. Por exemplo, aspectos como a Oportunidade certamente contribuiriam para a Confiabilidade da pontuação DQ, enquanto a Precisão dependeria da correção semântica, da integridade e da exclusividade dos dados. A pontuação de Usabilidade, por outro lado, é influenciada pela consistência dos dados entre outros fatores.

O Verity da Lyft se concentra na definição de verificações relacionadas à correção semântica, consistência, integridade, exclusividade, boa formação e oportunidade . Segue uma abordagem de teste e validação, enquanto a pontuação DQ unificada do Airbnb enfatiza a avaliação da qualidade dos dados através de várias dimensões.

Se quiséssemos incorporar a pontuação DQ neste último esquema, ela estaria ao lado das etapas de Alerta/Depuração.

A pontuação DQ do Airbnb usa sinais diferentes para avaliar a qualidade dos dados nos aspectos de precisão, confiabilidade, administração e usabilidade .

Também tivemos um conjunto de sinais de entrada que medem mais diretamente a qualidade (certificação Midas, validação de dados, bugs, SLAs, verificações automatizadas de DQ, etc.), enquanto outros eram mais como proxies de qualidade (por exemplo, propriedade válida, boa governança, higiene, o uso de ferramentas de caminho pavimentado).

Conforme discutido anteriormente, é provável que haja sobreposições entre a pontuação DQ do Airbnb e a Verity. Enquanto o Airbnb se concentra em empurrar a qualidade dos dados para a direita, enfatizando a medição e a pontuação, o Verity da Lyft adota uma abordagem proativa, mudando as configurações de definição de verificação, testes e processos de validação para a esquerda, enfatizando a melhoria proativa da qualidade dos dados.

Agora, meu interesse principal está à esquerda, nas configurações de definição de verificação, testes e aspectos de validação.

Como a Lyft integra testes de qualidade de dados em seus processos?

Vamos primeiro examinar os caminhos de execução.

Atualmente, o Verity da Lyft está focado principalmente em garantir a qualidade dos dados armazenados em seu data warehouse Hive. No entanto, existem planos para expandir as suas capacidades para suportar outras fontes de dados no futuro.

Observe que, embora se refiram ao Hive como um data workhouse, na verdade o utilizam como uma solução híbrida de armazenamento de dados, operando como um data warehouse para dados estruturados, processados e limpos (camada prateada), ao mesmo tempo que serve como um data lake para eventos brutos. dados (camada de bronze).

A baixa qualidade dos dados no Hive causou métricas de experimentação contaminadas, recursos de aprendizado de máquina imprecisos e painéis executivos falhos.

As verificações do Verity podem ser integradas a um DAG do Airflow para garantir que apenas dados brutos de alta qualidade sejam processados e armazenados no Hive como dados derivados.

Os produtores e consumidores de dados podem definir suas verificações de qualidade de dados e verificar os dados quando são produzidos ou antes de serem consumidos internamente. Fluxo de ar ou Voar .

…

O VerityAirflowOperator pode ser usado de forma bloqueadora para interromper um DAG em caso de falha na verificação, evitando que dados incorretos cheguem à produção. Isso utiliza o “ Estágio-Verificação-Troca ”Padrão: criamos dados em um esquema preparado, verificamos os dados com um operador de bloqueio e, em seguida, os promovemos para produção se passarem nas verificações de qualidade.

As verificações também podem ser realizadas manualmente ou programadas automaticamente para verificar dados brutos e derivados.

As verificações agendadas do Verity são isoladas de qualquer mecanismo de orquestração de dados, portanto, ainda são executadas mesmo se o Airflow ou o Flyte estiverem completamente inativos. Isso resolve um problema comum de verificações que não alertam porque a tarefa Airflow nunca foi executada.

Portanto, existem essencialmente três maneiras principais de acionar uma verificação: como parte de um DAG do Airflow, manualmente ou agendada por meio da plataforma/IU Verity.

Não acredito que as verificações atuais possam ser integradas em pipelines de streaming em tempo real (como Flink + Kafka) para validar, por exemplo, dados à medida que entram no Hive (ou até antes).

A implementação deste tipo de verificação em tempo real permitiria a detecção imediata de discrepâncias, levando à redução dos custos de armazenamento e processamento e à melhoria geral da qualidade dos dados.

Bem, para ser mais completo, as verificações do Verity são gerenciadas por meio de um servidor API, que pode ser usado para acionar verificações programaticamente por meio de algumas APIs.

Verity API Server – Este serviço lida com todas as APIs externas relacionadas à execução de verificações, bem como à persistência e recuperação de seus resultados. O API Server não executa nenhuma verificação, mas escreve uma mensagem em nossa Check Queue, que utiliza SimpleQueueService (SQS).

Então, talvez você possa acionar esses trabalhos de uma forma mais em tempo real, como a partir de um trabalho de streaming ou até mesmo, em um longo período, integrando-se com a captura de dados de alteração (CDC) do Hive.

No entanto, quando executados fora do Airflow, esses trabalhos não conseguiriam bloquear o trabalho de processamento de dados; em vez disso, eles gerariam alertas assíncronos enviados para a fila de verificação. Alguns consumidores prefeririam que o processamento dos dados fosse adiado quando uma verificação falhasse, enquanto outros prefeririam prosseguir e receber um alerta.

Agora, vamos dar uma olhada nesses testes de qualidade de dados.

Aqui está um exemplo que verifica se rider_events.session_id nunca é nulo. Isso é realizado por meio de uma combinação de componentes de consulta e condição.

 core rider events session_id is not null: # check name metadata: id: 90bde4fa-148b-4f06-bd5f-f15b3d2ad759 ownership_slack: #dispatch-service-dev tags: [rides, core-data, high-priority] query: type: dsl data_source_id: hive.core.rider_events filters: - session_id = null condition: type: fixed_threshold max: 0 notifier_group: pagerduty_policy: dispatch-service email: [email protected]

A Verity se concentra principalmente em definir e aplicar verificações de qualidade de dados, em vez de definir esquemas de dados completos.

A validação de esquema não é um conceito novo. Existem vários métodos para definir esquemas de dados de eventos em sistemas baseados em eventos, como JSON Schema, Protocol Buffers, Avro ou formatos de armazenamento como Parquet. A escolha ideal depende da sua pilha de tecnologia, uso e requisitos específicos.

Embora os esquemas de dados sejam valiosos para definir a estrutura geral de objetos de dados ou linhas de tabelas, eles são insuficientes na captura de verificações de validação mais sofisticadas específicas para consumidores, como distribuição de dados, regras de negócios, SLAs e limites.

Os contratos de dados vão além da validação de esquema, que se concentra na identificação de erros sintáticos . Pessoalmente, acho que o JSON Schema oferece aqui uma opção mais adequada e legível, separando efetivamente esses recursos de validação estrutural e sintática das questões de serialização ou armazenamento.

No entanto, para resolver erros semânticos e melhorar a precisão dos dados, ter um meio eficaz de definir verificações de dados permite definir a outra faceta dos contratos de dados.

É aqui que o Verity DSL entra em ação.

Além da validação semântica, os contratos de dados oferecem outro aspecto crucial que merece atenção.

Do ponto de vista sintático, as verificações de validação permanecem consistentes, independentemente do consumidor ou produtor envolvido. O conjunto de regras de validação não está vinculado a nenhum consumidor ou produtor específico e pode ser definido de uma vez por todas como um único esquema.

No entanto, o contrato de dados DSL da Verity oferece uma granularidade mais refinada que define pequenas regras independentes, o que é particularmente adequado para este contexto: o significado semântico e o uso dos dados variam dependendo do consumidor específico. Além disso, nem todos os consumidores precisam utilizar todas as propriedades de um objeto. Suas expectativas são diferentes. Isto não significa que sejam contraditórios (o que certamente seria um problema), mas sim complementares e distintos.

Portanto, é crucial permitir que todos os consumidores estabeleçam regras únicas que, quando combinadas de forma colaborativa, possam fornecer uma compreensão abrangente do significado semântico da qualidade dos dados.

E é esse aspecto colaborativo que ressoa particularmente em mim. Tenha paciência, isso pode parecer um exagero, mas do meu ponto de vista, vale a pena mencionar. :)

A troca de dados permite que diferentes equipes (produtores e consumidores) colaborem de forma eficaz. Estabelecer um entendimento compartilhado dessas trocas de dados é fundamental, assim como as APIs no desenvolvimento de software tradicional. Nas arquiteturas de microsserviços, surgiu uma abordagem de teste colaborativo conhecida como contratos orientados ao consumidor (CDC), onde os consumidores definem o comportamento esperado das APIs fornecidas pelos produtores. Os produtores são responsáveis por verificar esses contratos antes de lançar novas versões.

Acredito que os contratos de dados compartilham um espírito colaborativo semelhante. Embora a validação de dados seja realizada em dados reais, e não no momento da divulgação, e não bloqueie as liberações, ela é baseada na cooperação e incentiva o trabalho em equipe entre produtores e consumidores de dados. Acredito firmemente que esta abordagem colaborativa é fundamental para melhorar a qualidade dos dados e deve ser ainda mais integrada no processo.

Bem, sou um grande fã de traçar paralelos…

Observe, na verdade, que esse aspecto colaborativo também é mencionado como parte da carta de veracidade de Lyft.

O VerityUI oferece uma experiência simplificada de descoberta de dados por meio da página inicial do Verity. Nossa pesquisa de texto completo nos metadados de definição de verificação permite que os usuários vejam todas as verificações atualmente aplicadas e seus resultados de verificação. Isso tem agregações úteis, como equipe proprietária, nome da tabela e tags.

Não estou totalmente claro sobre como as questões de contrato de dados são compartilhadas entre consumidores e produtores por meio da interface da plataforma Verity, mas definitivamente reconheço a importância da colaboração por meio dos painéis:

• O produtor de uma interface de produto de dados pode garantir com segurança que não causará inadvertidamente interrupções no downstream que não haviam previsto.

• O consumidor da interface pode ter certeza de que sua confiança na interface não está e não será comprometida.

Embora o Verity seja uma ferramenta notável para definir verificações de qualidade de dados, infelizmente não é de código aberto.

Felizmente, existe outra estrutura de qualidade de dados de código aberto chamada Soda Core que oferece funcionalidade semelhante.

Soda Core é uma ferramenta de linha de comando gratuita e de código aberto e uma biblioteca Python que permite aos engenheiros de dados testar a qualidade dos dados. Ele utiliza entradas definidas pelo usuário para gerar consultas SQL que executam verificações em conjuntos de dados em uma fonte de dados para encontrar dados inválidos, ausentes ou inesperados. Quando as verificações falham, eles revelam os dados que você definiu como “ruins” na verificação.

Durante a varredura de um conjunto de dados, o Soda Core avalia as verificações predefinidas para identificar dados inválidos, ausentes ou inesperados.

Aqui está a verificação equivalente usando a sintaxe Soda.core para o teste Verity DSL que foi definido anteriormente.

 name: rider_events_session_id_check source: hive query: SELECT * FROM rider_events WHERE session_id IS NULL; raise_alert: true threshold: 10 action: slack message: "There are more than 10 rows that are null for the 'session_id' property in the 'rider_events' table. Please investigate this issue."

 soda run --check checks/rider_events_session_id_check.yaml

Soda Core é uma ferramenta poderosa para garantir a qualidade dos seus dados. Pode ajudá-lo a identificar e corrigir problemas de dados antecipadamente, antes que possam causar problemas para o seu negócio.

É importante notar que o Soda Core também pode facilitar as verificações de qualidade de dados para streaming de dados, integrando-se perfeitamente com Spark DataFrames.

Embora as verificações de qualidade de dados da Verity para o Hive sejam aplicadas a conjuntos de dados estáticos, as verificações de dados de streaming precisam ser mais leves e eficientes.

Os dados normalmente seriam processados em pequenos lotes de eventos, com latência muito baixa, tornando-os adequados para verificações em tempo real e casos de uso específicos, como detecção de anomalias.

Por fim, mencionemos que existem outras ferramentas de validação de dados disponíveis, como DeeQu, Great Expectations, …

Ao encerrarmos, espero que você tenha uma compreensão mais clara das etapas que pode seguir para aprimorar sua jornada de qualidade de dados.

Vimos duas abordagens distintas para a melhoria da qualidade dos dados, cada uma com seus próprios pontos fortes e metodologias. Um deles se concentra em aumentar a visibilidade e a observabilidade, motivando os produtores de dados a elevar o padrão de qualidade. A outra prioriza a elevação do padrão de qualidade por meio de uma abordagem de teste e validação em primeiro lugar. Ambos são complementares.

Verity não é apenas uma linguagem específica de domínio (DSL) para definir verificações de dados; é uma plataforma centralizada que capacita os profissionais de dados a colaborar de forma eficaz. Esta plataforma ajuda produtores e consumidores a alinharem-se com as expectativas de qualidade dos dados, incluindo formato, estrutura e precisão.

Os recursos de gerenciamento de contratos de dados da Verity poderiam (são?) aprimorados ainda mais pela integração com um conjunto mais amplo de recursos, como gerenciamento e descoberta de metadados, para atender a necessidades mais sofisticadas de qualidade de dados.

Semelhante à pontuação DQ do Airbnb, o Verity da Lyft promove um ciclo de feedback colaborativo entre produtores de dados e consumidores. Ao incentivar e capacitar cada equipe para assumir a responsabilidade pela qualidade dos dados, a Verity cultiva um ambiente de apoio onde a qualidade dos dados melhora continuamente.

Achou este artigo útil? Siga-me Linkedin , Hora de Hacker , e Médio ! Por favor 👏 este artigo para compartilhá-lo!