Observabilidade de dados

A observabilidade de dados é a capacidade de compreender a integridade dos sistemas de dados e dados, coletando e correlacionando eventos em áreas como pipelines de dados, de armazenamento, de computação e de processamento.

A compilação e a operação de uma plataforma de dados resiliente, escalonável e eficaz exigem a adoção de processos comprovados inspirados em DevOps em todas as equipes que representam domínios funcionais. A observabilidade de dados permite que proprietários de negócios, engenheiros do DevOps, arquitetos de dados, engenheiros de dados e engenheiros de confiabilidade do site automatizem a detecção, previsão e prevenção de problemas e evitem o tempo de inatividade que pode interromper a análise de produção e a IA.

Principais áreas de observabilidade de dados

A maioria das plataformas de dados opera nessas principais áreas de observabilidade de dados:

• Monitoramento de Serviço da Plataforma de Dados
• Monitoramento de Desempenho do Pipeline de Dados
• Monitoramento da Qualidade de Dados
• Linhagem de Dados
• Descoberta de Dados

A observabilidade de dados de ponta a ponta envolve não apenas capturar eventos e medir métricas em todos esses componentes, mas também correlacionar esses eventos e métricas. Isso fornece uma visão abrangente da integridade e confiabilidade do ambiente de dados corporativos.

Este artigo descreve cada componente e sua contribuição para obter observabilidade de dados.

Monitoramento de serviço da plataforma de dados

A infraestrutura fundamental de uma plataforma de dados corporativos pode incluir uma combinação de infraestrutura gerenciada pelo provedor e autogerenciada, para habilitar o armazenamento e a computação. Os engenheiros do DevOps ou engenheiros de infraestrutura precisam monitorar essa infraestrutura fundamental para que possam identificar e resolver as interrupções de sistema e os gargalos de desempenho que afetam os pipelines modernos de dados e de análise.

O monitoramento de dados dos bancos de dados e das camadas de rede pode melhorar a taxa de transferência de processamento e minimizar a latência de rede. As equipes precisam de ferramentas que possam ser usadas para capturar métricas, notificar, acompanhar e corrigir incidentes, e que possam ser correlacionadas com os problemas de dados e de análise.

Recomendamos que as equipes incorporem a observabilidade como código à camada de infraestrutura como código para que o monitoramento da instrumentação pronta para uso seja habilitado assim que criarem um recurso. A maioria dos serviços do Azure oferece instrumentação pronta para uso para as principais métricas de recursos, como dados de diagnóstico.

Monitoramento de desempenho do pipeline de dados

Os pipelines de dados cada vez mais complexos que contêm vários estágios e dependências agora geram grandes volumes de dados de monitoramento. Esses dados incluem eventos, métricas e logs. Você pode otimizar o desempenho do pipeline de dados, coletando e analisando os dados de monitoramento.

As equipes de dados devem acompanhar o estado dos pipelines de dados em vários produtos de dados e domínios de negócios relacionados. Quando a equipe é notificada antecipadamente sobre falhas ou runtimes mais demorados do que o esperado, ela pode minimizar e corrigir o tempo de inatividade. A correlação dos dados de monitoramento do pipeline e o monitoramento de serviço da plataforma pode fornecer recomendações para ajuste de desempenho, como aumentar a CPU e a memória para os pipelines de alta utilização de carga.

Monitoramento da qualidade de dados

A qualidade de dados é o nível de precisão, integralidade, periodicidade e consistência dos dados em relação aos requisitos da sua organização. Você precisa monitorar constantemente os conjuntos de dados quanto à qualidade para garantir que os aplicativos de dados alimentados por eles permaneçam confiáveis e válidos. O DataOps vem melhorando consistentemente a confiabilidade e o desempenho dos dados, automatizando os testes de qualidade de dados (unidade, funcionalidade e integração). Essas melhorias possibilitam a detecção de falhas e a análise de dados mais rápidas e mais eficientes.

Para adotar os princípios de DevOps e SRE na qualidade de dados, as equipes devem compilar processos e estruturas repetíveis e iterativos para capturar problemas de qualidade de dados, acompanhar esses problemas nos painéis e configurar alertas para desvios.

O TTD (Tempo de Detecção), o TTR (Tempo de Recuperação) e outras métricas de qualidade de dados podem ser controladas a partir do monitoramento da qualidade de dados. O TTD se refere ao tempo necessário para que a equipe de dados detecte um problema de qualidade de dados de qualquer tipo, desde anomalias de atualização até alterações de esquema que interrompem pipelines inteiros. O TTR se refere ao tempo necessário para que a equipe resolva um incidente de dados após o alerta. Melhorar a qualidade de dados é mais do que um desafio técnico, envolve um suporte organizacional e cultural considerável.

A seção de governança sobre qualidade de dados explora como você pode implementar a qualidade de dados em seu cenário.

Linhagem de dados

A linhagem de dados é amplamente compreendida como um registro contínuo que segue a origem, as transformações e a movimentação dos dados ao longo do tempo no patrimônio de dados. A linhagem de dados é usada em tarefas retrospectivas, incluindo solução de problemas, depuração e rastreamento de causas raiz dos problemas de pipeline. A linhagem também é usada para análise de qualidade de dados, conformidade e cenários "what if", que geralmente são chamados de análise de impacto.

A linhagem tem uma representação visual para mostrar a movimentação dos dados da origem para o destino, incluindo a maneira como os dados foram transformados ao longo do tempo.

A seção de governança sobre linhagem de dados explora como você pode implementar a linhagem de dados em seu cenário.

Descoberta de dados

A descoberta de dados é a primeira etapa para uma análise de dados ou uma carga de trabalho de governança de dados para consumidores. Em uma plataforma de data lake corporativo, os consumidores de dados (como cientistas e analistas de dados) têm dificuldades para localizar os dados necessários e avaliar a confiabilidade deles. Os catálogos de dados com metadados precisos facilitam a pesquisa, usando o índice de dados que fornece:

• Localização dos dados disponíveis
• Detecção da qualidade dos dados
• Compreensão da estrutura de dados
• Compreensão da linhagem de dados
• Acesso aos dados desejados

Os catálogos de dados que oferecem essas funcionalidades de pesquisa aumentam a velocidade de todos os processos de descoberta de dados.

A seção de governança sobre catálogos de dados explora como você pode implementar a descoberta de dados em seu cenário.

Definir SLAs, SLIs e SLOs

As equipes da sua organização podem adotar práticas de SRE (Engenharia de Confiabilidade de Sites) no estilo do DevOps para monitoramento de dados. Os SLAs (contratos de nível de serviço), os SLIs (indicadores de nível de serviço) e os SLOs (objetivos de nível de serviço) podem ajudar sua organização a reduzir o tempo de inatividade e garantir a confiabilidade dos dados.

Contratos de nível de serviço (SLAs)

Os SLAs exigem SLIs bem definidos, que são medidas quantitativas da qualidade de serviço, e SLOs pré-estabelecidos, que são os valores ou intervalos ideais a que cada SLI deve atender.

Definir um SLA de dados exige participação e colaboração ativas de todos os stakeholders que serão afetados por um SLA. Esses stakeholders podem incluir produtores de dados, engenheiros de dados, analistas de dados, consumidores de dados, analistas de negócios e outros.

A configuração de SLAs de confiabilidade geralmente inclui três etapas: definir, medir e acompanhar.

Comece a configuração do SLA definindo o que significa confiabilidade. Todos os principais stakeholders devem concordar com essa definição. Garanta a participação e adesão de todos os principais stakeholders, especialmente se os consumidores downstream vêm de diferentes equipes ou diferentes regiões geográficas e fusos horários.

O SLA precisa ser criado cuidadosamente. Entre em contato com a equipe jurídica, se os consumidores de dados forem clientes pagos externos. Para clientes internos, a definição do SLA deve incluir as áreas-chave, como promessa de dados, qualidade de dados e um processo para lidar com incidentes de dados, se a promessa não for cumprida.

Exemplo de SLA

Suponha que a Contoso seja uma empresa de mídia que gerencia um data lake corporativo e esse data lake alimenta vários produtos de dados em diferentes domínios de negócios. A equipe de aplicativos de dados da Contoso é responsável por fornecer os dados de vendas do dia anterior, que alimentam o painel de vendas da Contoso. Quando uma entrega de dados é perdida ou dados incompletos são fornecidos, a equipe de engenharia de dados recebe emails de executivos frustrados e precisa fazer a triagem manual do pipeline interrompido, que deveria fornecer os dados de vendas. Para medir e melhorar as entregas, a equipe de dados define um SLA com a equipe de Vendas, conforme demonstrado na seção a seguir.

Contrato de Nível de Serviço – da Equipe de Dados para a Equipe de Vendas

Contrato	Descrição
Área de negócios	A equipe de dados promete capacitar a equipe de vendas para tomar decisões controladas por dados
Promessa	A equipe de dados promete fornecer os dados de vendas do dia anterior que alimentam o painel de vendas. Esses dados podem fornecer taxas de vendas e de conversão para todas as regiões dos EUA. Os pipelines de dados fornecerão os dados para alimentar o painel de vendas, antes das 06:00 UTC
Qualidade dos dados	Verificação de nulo: o nome do cliente não pode ser nulo. Valor ausente: a região do cliente não pode estar ausente. Atualização: a data de vendas deve incluir qualquer transação antes das 00:00 UTC
Gerenciamento de incidentes de dados	Se a promessa de entrega de dados acima não for cumprida, a equipe de vendas pode relatar o problema e a equipe de dados promete resolver o problema com um TTR < 6 Horas

SLIs (indicadores de nível de serviço)

Os SLIs sempre devem atender ou exceder os SLOs descritos no SLA. Ao definir um SLI, comece identificando as principais métricas que você pode controlar e medir para obter o SLA pré-estabelecido.

Exemplo de SLI

Suponha que a equipe de dados da Contoso identifique as principais métricas de diferentes áreas para atender ao SLA descrito no exemplo anterior. Eles também compilam um painel, configuram alertas para o caso de desvio das principais métricas em relação a uma linha de base definida e automatizam ações para atenuar alguns problemas.

Metric	Finalidade
Uso de CPU e memória do cluster do Spark	Para medir os gargalos de desempenho na infraestrutura subjacente usada para executar pipelines de dados
Tempo de execução total do pipeline em minutos	Para medir se um pipeline leva mais tempo do que o esperado para ser executado
Taxas de sucesso e de falha do pipeline	Para medir quantos pipelines apresentam falha ou sucesso
Métricas de qualidade de dados (downstream)	Para garantir que os dados entregues pelo pipeline de dados atendam às expectativas
Métricas de qualidade de dados (upstream)	Para garantir que a integridade upstream da qualidade de dados brutos seja atendida
Atualizações dos metadados de transformação	Para garantir que a linhagem de upstream para downstream contenha metadados sobre todas as transformações aplicadas aos dados
Indexação e atualizações de dados downstream	Para garantir que a equipe de vendas descubra todos os conjuntos de dados que alimentam o painel
Processo definido para medir o TTD e o TTR	Para medir o TTD e o TTR e garantir o TTR < 6 horas

SLOs (objetivos de nível de serviço)

Um SLO consiste em um SLI, no período em que esse SLI é medido e na taxa de sucesso pretendida que é alcançável de fato. Definir a direção e o sucesso pretendido pode ser uma tarefa assustadora inicialmente. Não espere perfeição, mas a melhoria constante ao longo de várias iterações.

Os SLOs podem contar com o seguinte:

• Produto de dados
• Categoria de dados
• Regiões de fonte de dados
• Componentes de observabilidade de dados

Exemplo de SLO

Suponha que a equipe de dados da Contoso forneça dados de vendas em sete regiões diferentes dos Estados Unidos. 210 conjuntos de dados são entregues a cada ano civil em todas as regiões e apenas 200 conjuntos de dados são concluídos e atendem ao SLA. Essas entregas bem-sucedidas são convertidas em uma taxa de sucesso de 95,99% para esse ano. Os dez conjuntos de dados com falha (incompleta) ocorreram a uma taxa de erro aceitável de 4%.

A equipe de dados cria um painel de monitoramento, que rastreia os SLIs agregados para monitorar esse SLO, durante um período de 30 dias. A equipe de dados e a equipe de vendas são notificadas, quando a taxa de sucesso de destino não é alcançada.

Modelo de maturidade da observabilidade de dados

A observabilidade de dados é uma parte essencial da estrutura do DataOps e deve ser considerada paralela aos esforços de melhoria dos processos do DataOps da sua organização. O modelo de maturidade a seguir pode ajudar a avaliar o estado atual da observabilidade de dados e decidir sobre as próximas etapas da jornada.

Estágio	Monitoramento de serviço da plataforma de dados	Monitoramento de desempenho do pipeline de dados	Monitoramento da qualidade de dados	Linhagem de dados	Descoberta de dados
Estágio 5 (altamente avançado)	Os dados são coletados em todos os componentes de observabilidade de dados de um ou mais produtos de dados em uma exibição unificada e são correlacionados usando o aprendizado de máquina para encontrar anomalias. Os painéis rastreiam o SLO, SLI e SLA em todos os componentes de observabilidade de dados.	As métricas de desempenho do pipeline de dados são controladas em vários produtos de dados. A análise de causa raiz é concluída e controlada pelo sistema.	Um alto nível de confiança na qualidade de dados é estabelecido. Os consumidores de dados podem verificar a confiabilidade dos dados.	A linhagem de dados tem uma representação visual e é usada de várias maneiras, como rastreamento de causas raiz da falha de pipeline, análise de qualidade de dados e conformidade.	Os consumidores de dados podem encontrar com facilidade os dados disponíveis necessários.
Estágio 4 (Avançado)	Os painéis rastreiam o SLO, SLI e SLA em todos os componentes de observabilidade de dados mais críticos. Os dados de monitoramento da plataforma e os dados de monitoramento de desempenho do pipeline são correlacionados usando a automação.	As ferramentas de incidentes de dados monitoram e medem as métricas de TTD e TTR quanto a incidentes.	A qualidade de dados é mantida por meio de uma estrutura utilizável em vários produtos de dados e controlada usando painéis.	A linhagem de dados inclui marcas de qualidade de dados e está conectada à descoberta de dados.	A linhagem de dados agora está conectada à descoberta de dados e também inclui marcas de qualidade de dados.
Estágio 3 (Em evolução)	SLO, SLI e SLA bem definidos abrangem quase todos os componentes mais críticos da Observabilidade de Dados. Os incidentes de dados são gerenciados com ferramentas especializadas.	Os dados de monitoramento da plataforma são correlacionados com o monitoramento de desempenho do pipeline de dados, usando um pouco de automação.	As verificações de qualidade de dados são bem definidas e mapeadas para as métricas personalizadas.	A linhagem de dados desenvolvida para conter os metadados suficientes necessários para a tomada de decisão.	A descoberta de dados é obtida usando as ferramentas especializadas do catálogo de dados.
Estágio 2 (Planejamento)	Um rascunho inicial do SLO, SLI e SLA abrange os componentes mais críticos necessários para a observabilidade de dados. Os dados de monitoramento da plataforma são centralizados e existe uma exibição unificada de todo o ambiente de dados. Todo o gerenciamento de incidentes de dados é manual.	As métricas de desempenho do pipeline de dados são definidas e medidas.	Existem verificações de qualidade de dados, mas nenhuma métrica padrão é definida, medida e visualizada.	A linhagem de dados é limitada a um único produto de dados ou não é controlada.	A descoberta de dados é obtida, mas nenhuma ferramenta avançada é usada.
Estágio 1 (Aprendizado)	Cada serviço crítico de plataforma (gerenciado pelo provedor e autogerenciado) é monitorado no cenário de dados.	O monitoramento de pipeline é mínimo. As falhas disparam alertas, mas não têm informações sobre as possíveis causas.	Os testes de qualidade de dados podem ser executados no pipeline, mas nenhuma métrica é medida ou controlada.	A linhagem de dados não existe.	A descoberta de dados não existe.