Contratos de dados desmistificados: Tudo o que você precisa saber

Contratos de dados semânticos

As validações de dados semânticos garantem que os dados sejam logicamente consistentes e estejam alinhados com a lógica comercial.

As validações semânticas precisam ser aplicadas explicitamente.

De fato, ao contrário das verificações de esquema, os contratos de dados semânticos dependem da lógica comercial e devem ser implementados externamente.

A semântica em muitos cenários de casos de uso parece uma extensão de contratos validados por esquema. Muitas vezes, ele depende de regras comerciais e representa um conjunto de condições de linha com as quais nosso modelo de dados deve estar em conformidade. 

Um exemplo de um contrato semântico pode ser o seguinte:

• Desvio de métrica: da média móvel ou de qualquer outro limite. Na verdade, podemos aceitar que o número de usuários ativos de ontem fique abaixo de 75% da média móvel de 7 dias, mas não toleraremos 0%.
• Lógica de negócios: Monitoramento de transações, sinalizadores de alerta e pontuações de prevenção de fraudes. Nesse cenário, o pagamento deve ser 0.
• Linhagem de dados: Isso descreve como as entidades de dados evoluem. Por exemplo, transaction_completed_at não pode ocorrer antes de created_at.
• Integridade referencial: Os relacionamentos entre entidades são importantes e também podem ser descritos por meio de contratos semânticos. Considere o código dbt abaixo. Ele explica que o refund_id de cada reembolso mapeia de volta para um transaction.id válido.

- name: refunds
   enabled: true
   description: An incremental table
 columns:
     - name: refund_id
       tests:
         - relationships:
             tags: ['relationship']
             to: ref('transactions')
             field: id

Cabe ao usuário final definir o nível de alerta em contratos semânticos, e isso geralmente é implementado com testes de qualidade de dados personalizados.

Várias regras de lógica comercial geralmente se referem à integridade dos dados. Cenários de dados ilógicos podem surgir de erros nas configurações do banco de dados e do servidor ou da injeção não intencional de dados de teste no ambiente de produção. As verificações de integridade dos dados são projetadas para validar os dados em relação a essas regras comerciais, ajudando a identificar valores que não parecem corretos ou são ilógicos.

As entidades do banco de dados sempre se relacionam umas com as outras. Isso é chamado de relacionamento entre entidades e geralmente é apresentado pelo diagrama de relacionamento entre entidades (ERD). Uma integridade referencial inadequada pode levar a problemas como dados ausentes ou incompletos. Os contratos de dados devem abordar essas possíveis armadilhas para garantir a integridade e a precisão dos dados.

Por exemplo, um relacionamento comum é uma associação de um para muitos entre customers e orders, em que um único cliente pode ter vários orders.. Nesse cenário, um pedido é considerado válido somente se contiver um customer_id válido no conjunto de dados customers.

Esse tipo de restrição, uma restrição de restrição de integridade referencialgarante que o relacionamento entre as entidades seja mantido com precisão.

Acordos de nível de serviço (SLAs) em contratos de dados

Os SLAs são um nível extra de verificações de qualidade de dados que podem ser implementadas usando contratos de dados.

Os SLAs referem-se à atualização dos dados.

Como os modelos de dados são atualizados regularmente com novos dados, os SLAs podem incluir verificações do último horário em que se espera que os novos dados estejam disponíveis ou o atraso máximo permitido. Por exemplo, no dbt, isso pode ser obtido usandoos testes de atualização do :

- name: orders
   enabled: true
   description: A source table declaration
   tests:
     - dbt_utils.recency: # https://github.com/dbt-labs/dbt-utils#recency-source
         tags: ['freshness']
         datepart: day
         field: timestamp
         interval: 1

Suponha que queiramos gerar um relatório sobre os fatos de ontem; para isso, queremos garantir que os dados existam. De fato, seria estranho não ver os novos pedidos por alguns dias ou mais.

No exemplo abaixo, podemos testar nosso conjunto de dados quanto a atrasos inesperados de pedidos usando a configuração de teste no dbt. Isso permite que você selecione e faça referência ao teste usando esse nome específico.

version: 2
models:
 - name: orders
   columns:
     - name: status
       tests:
         - accepted_values:
             name: unexpected_order_status_today
             values: ['placed', 'shipped', 'completed', 'returned']
             config:
               where: "order_date = current_date"

Ao definir um nome personalizado, você obtém controle total sobre como o teste é exibido em mensagens de log e artefatos de metadados.

Da mesma forma, em pipelines de dados em tempo real, espera-se que os dados não tenham mais do que algumas horas. Os SLAs são essenciais para aplicativos de processamento de fluxo em que os dados são processados em tempo real com minutos ou até segundos de latência.

Em aplicativos de streaming, queremos verificar o atraso máximo permitido para eventos de chegada tardia e métricas como tempo médio entre falhas (MTBF) e tempo médio de recuperação (MTTR). Para implementar isso, você precisa rastrear meticulosamente os incidentes e extrair dados relevantes das ferramentas de monitoramento de aplicativos e gerenciamento de incidentes, como PagerDuty, Datadog e Grafana.

Contratos de governança de dados

O tratamento correto das informações de identificação pessoal (PII) é essencial para o processo de transformação de dados. Para muitas empresas, é fundamental que esses conjuntos de dados sejam, no mínimo compatíveis com o GDPR e cumpram as normas de privacidade de dados, como HIPAA ou PCI DSS.

Os contratos de governança de dados garantem a pseudonimização ou mascaramento de dados estejam em vigor.

Considere o código dbt abaixo. Os contratos aplicados como tests exigem que um user_email seja um hash SHA256 (mascarado):

models:
 - name: customer_data
   columns:
       - name: user_email
         tests:
           - dbt_expectations.expect_column_values_to_not_match_regex:
               regex: "^(?!.*\b@\b).* # Ensure identifiers do not contain emails
               flags: i # Case-insensitive matching

Por outro lado, talvez você queira impor a correspondência de padrões para outras tabelas. Por exemplo, no exemplo abaixo, o campo transaction_reference deve seguir o padrão [“TRX-%”, “%-2023”]:

models:
 - name: transaction_data
   columns:
       - name: transaction_reference
         tests:
           - dbt_expectations.expect_column_values_to_match_like_pattern_list:
               like_pattern_list: ["TRX-%", "%-2023"]
               match_on: any

Os contratos de governança de dados também podem ser benéficos quando incluem colunas com dados confidenciais, metadados (proprietários de dados, etc.) e funções de usuário autorizadas a acessar um produto de dados.

Por exemplo, podemos indicar o proprietário do modelo de dados e o estágio do ciclo de vida do desenvolvimento do modelo usando o campo meta no dbt:

# models/schema.yaml
version: 2
models:
 - name: users
   meta:
     owner: "@data_mike"
     model_maturity: in dev
     contains_pii: true
   columns:
     - name: email
       meta:
       contains_pii: true

O campo meta permite que você defina metadados para um recurso, que são compilados no arquivo manifest.json gerado pelo dbt e podem ser visualizados na documentação gerada automaticamente. 

Podemos usar pacotes como o dbt-checkpoint para examiná-lo durante o pull request para garantir que nossos metacampos obrigatórios estejam presentes. O hook falhará se algum modelo (de um manifesto ou de arquivos YAML) não tiver as meta-chaves especificadas.

As chaves meta do modelo devem estar no arquivo YAML ou no manifesto.

Padrões de implementação de contratos de dados

A validação do contrato pode ser realizada em pipelines de dados de streaming (por linha) antes da ingestão dos dados e depois dela - na fonte (camada do modelo de dados de origem).

Quando ingerimos dados "como estão", o processo de validação atua como uma etapa de transformação, aplicando regras de contrato e filtrando dados inválidos, ou seja, em uma exibição de banco de dados dedicada ou em uma tabela em que os dados podem ser investigados mais detalhadamente.

As verificações de validação podem ser aplicadas post-facto quando os dados são ingeridos diretamente em um lago de dados brutos.

A principal vantagem da validação de contratos de dados em tempo real é a capacidade de filtrar registros inválidos antes que eles cheguem ao destino final - um data lake ou um data warehouse. Essa abordagem é predominante no processamento de dados orientado por eventos ou em tempo real, como eventos de captura de dados de alteração (CDC). Nesse tipo de validação, determinados aspectos do contrato são verificados à medida que os dados fluem pelo pipeline.

Ferramentas de contratos de dados

A comunidade de dados está reconhecendo gradualmente os possíveis benefícios dos contratos de dados, uma área de engenharia de dados em constante evolução. Existem muitas ferramentas nesse espaço, algumas ainda em seus estágios iniciais. O dbt pode ser considerado uma estrutura universal para contratos de dados.

Você pode implementar contratos semelhantes usando o Dataform do Google na origem (camada de modelo de dados de origem), ou seja, quando os dados tiverem sido ingeridos com sucesso em nosso data warehouse. Para isso, você deve usar condições de linha simples. 

Considere o exemplo abaixo. Ele aplica determinadas condições de linha à nossa tabela:

-- my_table.sqlx
config {
 type: "table",
 assertions: {
   nonNull: ["user_id", "customer_id", "email"]
 }
}
SELECT …

A seguir, você verá outro exemplo de implementação de contrato de dados, que pode ser realizado usando o Soda.io, uma estrutura de qualidade de dados de nicho:

# Checks for basic validations
checks for dim_customer:
 - row_count between 10 and 1000
 - missing_count(birth_date) = 0
 - invalid_percent(phone) < 1 %:
     valid format: phone number
 - invalid_count(number_cars_owned) = 0:
     valid min: 1
     valid max: 6
 - duplicate_count(phone) = 0

O ajuste das configurações de alerta permite que você configure uma verificação para emitir um aviso em vez de falhar na validação. Uma varredura do Soda executa as verificações especificadas em um contrato, verifica o arquivo YAML ou em linha em uma invocação programática e retorna um resultado para cada verificação: aprovação, falha ou erro.

Pela minha experiência, a introdução de contratos de dados em muitas empresas continua fragmentada, dependendo de fatores como padrões de design de pipeline de dados (em lote ou em tempo real), opções de serialização de dados e sistemas usados para armazenamento e processamento.

A implementação do contrato de dados depende dos requisitos e da lógica do negócio.

A Great Expectations, uma biblioteca Python, pode ser usadapara implementar contratos de dados em nível semântico. Ele pode ser instalado usando o pip: pip install great_expectations. 

Depois de executar great_expectations init, você pode prosseguir com a validação de dados:

Using v3 (Batch Request) API
 ___              _     ___                  _        _   _
/ __|_ _ ___ __ _| |_  | __|_ ___ __  ___ __| |_ __ _| |_(_)___ _ _  ___
| (_ | '_/ -_) _ |  _| | _|\ \ / '_ \/ -_) _|  _/ _ |  _| / _ \ ' \(_-<
\___|_| \___\__,_|\__| |___/_\_\ .__/\___\__|\__\__,_|\__|_\___/_||_/__/
                               |_|
            ~ Always know what to expect from your data ~
Let's create a new Data Context to hold your project configuration.
Great Expectations will create a new directory with the following structure:
   great_expectations
   |-- great_expectations.yml
   |-- expectations
   |-- checkpoints
   |-- plugins
   |-- .gitignore
   |-- uncommitted
       |-- config_variables.yml
       |-- data_docs
       |-- validations
OK to proceed? [Y/n]:

Considere o trecho de código abaixo. Ele explica como você pode criar uma definição de verificação de dados para a coluna price:

"expectation_type": "expect_column_values_to_match_regex",
"kwargs": {
 "column": "price",
 "mostly": 1.0,
 "regex": "^\\$([0-9],)*[0-9]+\\.[0-9]{2}$"
},

Práticas recomendadas de contrato de dados

Não há uma resposta certa ou errada aqui, pois, pela minha experiência, uma implementação bem-sucedida de contrato de dados depende muito dos requisitos comerciais. Para que os contratos de dados funcionem de forma eficaz, siga estas práticas recomendadas fundamentais:

• Escalabilidade: Recomendo que você adicione mecanismos de extensibilidade (por exemplo, on_schema_change: append) e controle de versão, o que permitiria modificar os termos do contrato de dados sem interromper as integrações de pipeline existentes. Projetar contratos de dados com vistas a mudanças futuras e escalabilidade. Essa abordagem garante que o contrato possa se adaptar à evolução das necessidades e do crescimento.
• Regras claras: Recomendo que você use uma linguagem direta e concisa no contrato de dados para evitar mal-entendidos e interpretações errôneas. O contrato deve ser redigido e nomeado de forma acessível e compreensível para todas as partes envolvidas, independentemente de seus conhecimentos técnicos.
• Colaboração: O esforço colaborativo garante uma compreensão abrangente e completa dos requisitos, abordando várias perspectivas e necessidades. Ao criar contratos de dados, envolva diversas partes interessadas, incluindo produtores de dados, engenheiros de dados, cientistas de dados e representantes dos departamentos comercial, de TI, jurídico e de conformidade.
• Metadata: Recomendo que você forneça contratos de dados com documentação e metadados completos. Uma documentação abrangente ajuda na aplicação e na manutenção do contrato. Isso deve incluir descrições detalhadas, definições de campo, regras de validação e outras informações relevantes que apoiem um entendimento claro e uma implementação eficaz do contrato.
• Avaliações regulares: A revisão contínua ajuda a manter a relevância e a eficácia do contrato ao longo do tempo. Implementar uma abordagem estruturada para monitoramento e atualizações de contratos de dados. Revisões regulares garantem que o contrato permaneça atualizado, esteja alinhado com os requisitos comerciais em evolução e esteja em conformidade com regulamentos novos ou em mudança.

Conclusão

Recentemente, houve uma mudança em direção à propriedade de dados distribuídos, em que as equipes de domínio são responsáveis por seus produtos de dados. Essa mudança forçou as organizações a redefinir as expectativas de qualidade dos dados, formalizadas por meio de contratos de dados.

As validações de dados semânticos garantem que os dados sejam logicamente consistentes e estejam alinhados com a lógica comercial. Eles ajudam a verificar os pipelines de dados em busca de exceções nos dados, no valor, na linhagem e na integridade referencial. Uma integridade referencial inadequada pode levar a dados ausentes ou incompletos, e é por isso que ela também é importante. 

Os contratos de governança de dados também podem ser implementados em pipelines de CI/CD e se tornam muito úteis quando indicam colunas com dados confidenciais, metadados (proprietários de dados, etc.) e funções de usuário autorizadas a acessar um produto de dados. 

Os metadados de um modelo, juntamente com quaisquer outros metacampos obrigatórios definidos pelo desenvolvedor, ajudam a monitorar o uso e o desempenho dos recursos do modelo. 

Os acordos de nível de serviço (SLAs) dos contratos de dados descrevem compromissos específicos relacionados à atualização, integridade e recuperação de falhas dos dados.

Os contratos de dados são essenciais para as técnicas modernas de modelagem de dados e ajudam a garantir que a plataforma de dados seja propensa a erros e tenha um bom dimensionamento. A resolução de problemas de qualidade de dados pode ser cara. Para empresas de nível empresarial, maximizar o retorno sobre o investimento (ROI) a partir dos dados torna-se cada vez mais importante, aproveitando as ferramentas de qualidade de dados existentes que dão suporte à validação de contratos de dados.