Melhores práticas para a fiabilidade

Este artigo aborda as práticas recomendadas de confiabilidade organizadas por princípios de arquitetura listados nas seções a seguir.

1. Conceção em caso de falha

Usar um formato de dados que ofereça suporte a transações ACID

As transações ACID são um recurso crítico para manter a integridade e a consistência dos dados. A escolha de um formato de dados que suporte transações ACID ajuda a criar pipelines mais simples e muito mais confiáveis.

O Delta Lake é uma estrutura de armazenamento de código aberto que fornece transações ACID, bem como imposição de esquema, manipulação de metadados escaláveis e unifica streaming e processamento de dados em lote. O Delta Lake é totalmente compatível com as APIs do Apache Spark e foi projetado para integração total com streaming estruturado, permitindo que você use facilmente uma única cópia de dados para operações em lote e streaming e forneça processamento incremental em escala.

Use um mecanismo de dados distribuído resiliente para todas as cargas de trabalho

O Apache Spark, como o mecanismo de computação do Azure Databricks lakehouse, é baseado no processamento de dados distribuídos resilientes. Se uma tarefa interna do Spark não retornar um resultado conforme o esperado, o Apache Spark reagendará automaticamente as tarefas ausentes e continuará a executar todo o trabalho. Isso é útil para falhas fora de código, como um breve problema de rede ou uma VM spot revogada. Trabalhando com a API SQL e a API Spark DataFrame, essa resiliência é incorporada ao mecanismo.

No lago Databricks, Photon, um mecanismo vetorizado nativo inteiramente escrito em C++, é uma computação de alto desempenho compatível com APIs do Apache Spark.

Recuperar automaticamente dados inválidos ou não conformes

Dados inválidos ou não conformes podem causar falhas nas cargas de trabalho que dependem de um formato de dados estabelecido. Para aumentar a resiliência de ponta a ponta de todo o processo, é uma prática recomendada filtrar dados inválidos e não conformes na ingestão. O suporte para dados resgatados garante que você nunca perca ou perca dados durante a ingestão ou ETL. A coluna de dados resgatados contém todos os dados que não foram analisados, seja porque estavam ausentes do esquema fornecido, porque havia uma incompatibilidade de tipo ou porque o corpo da coluna no registro ou arquivo não correspondia ao do esquema.

• Databricks Auto Loader: Auto Loader é a ferramenta ideal para transmitir a ingestão de arquivos. Ele suporta dados resgatados para JSON e CSV. Por exemplo, para JSON, a coluna de dados resgatados contém quaisquer dados que não foram analisados, possivelmente porque estavam ausentes do esquema fornecido, porque havia uma incompatibilidade de tipo ou porque o invólucro da coluna não correspondia. A coluna de dados resgatados faz parte do esquema retornado pelo Auto Loader como _rescued_data por padrão quando o esquema está sendo inferido.
• Delta Live Tables: Outra opção para criar fluxos de trabalho para resiliência é usar Delta Live Tables com restrições de qualidade. Consulte Gerenciar a qualidade dos dados com o Delta Live Tables. Pronto para usar, o Delta Live Tables suporta três modos: Reter, soltar e falhar em registros inválidos. Para colocar em quarentena registros inválidos identificados, as regras de expectativa podem ser definidas de uma maneira específica para que os registros inválidos sejam armazenados ("em quarentena") em outra tabela. Consulte Quarentena de dados inválidos.

Configurar trabalhos para repetições e encerramentos automáticos

Os sistemas distribuídos são complexos e uma falha num momento pode potencialmente propagar-se por todo o sistema.

• Os trabalhos do Azure Databricks dão suporte a uma política de repetição automática que determina quando e quantas vezes as execuções com falha são repetidas.
• Você pode configurar limites de duração opcionais para uma tarefa, incluindo um tempo de conclusão esperado para a tarefa e um tempo máximo de conclusão para a tarefa.
• O Delta Live Tables também automatiza a recuperação de falhas usando tentativas de escalada para equilibrar velocidade e confiabilidade. Consulte Modos de desenvolvimento e produção.

Por outro lado, uma tarefa suspensa pode impedir que todo o trabalho seja concluído, resultando em altos custos. Os trabalhos Databricks suportam a configuração de tempo limite para eliminar trabalhos que levam mais tempo do que o esperado.

Use um modelo escalável e de nível de produção que atenda a infraestrutura

Para inferência em lote e streaming, use os trabalhos do Azure Databricks e o MLflow para implantar modelos como UDFs do Apache Spark para aproveitar o agendamento de tarefas, tentativas, dimensionamento automático e assim por diante. Consulte Usar MLflow para inferência de modelo.

O serviço de modelos fornece uma infraestrutura escalável e de nível de produção para o serviço de modelos em tempo real. Ele processa seus modelos de aprendizado de máquina usando MLflow e os expõe como pontos de extremidade da API REST. Essa funcionalidade usa computação sem servidor, o que significa que os pontos de extremidade e os recursos de computação associados são gerenciados e executados na conta de nuvem do Azure Databricks.

Use serviços gerenciados sempre que possível

Aproveite os serviços gerenciados (computação sem servidor) da Databricks Data Intelligence Platform, como:

• Armazéns SQL sem servidor
• modelo de serviço
• Trabalhos sem servidor
• computação sem servidor para notebooks
• Mesas Delta Live

sempre que possível. Esses serviços são operados pela Databricks de forma confiável e escalável, sem custo adicional para o cliente, tornando as cargas de trabalho mais confiáveis.

2. Gerencie a qualidade dos dados

Usar uma arquitetura de armazenamento em camadas

Organize dados criando uma arquitetura em camadas e garantindo que a qualidade dos dados aumente à medida que os dados se movem pelas camadas. Uma abordagem comum de criação de camadas é:

• Camada bruta (bronze): Os dados de origem são ingeridos na casa do lago na primeira camada e devem ser persistidos lá. Quando todos os dados downstream são criados a partir da camada bruta, é possível reconstruir as camadas subsequentes a partir dessa camada, conforme necessário.
• Camada curada (prata): O objetivo da segunda camada é armazenar dados limpos, refinados, filtrados e agregados. O objetivo dessa camada é fornecer uma base sólida e confiável para análise e geração de relatórios em todas as funções e funções.
• Camada final (ouro): A terceira camada é construída em torno das necessidades do negócio ou do projeto. Ele fornece uma visão diferente como produtos de dados para outras unidades de negócios ou projetos, preparando dados em torno de necessidades de segurança (como dados anonimizados) ou otimizando para desempenho (como com exibições pré-agregadas). Os produtos de dados nesta camada são considerados como a verdade para o negócio.

A camada final deve conter apenas dados de alta qualidade e ser totalmente confiável do ponto de vista comercial.

Melhore a integridade dos dados reduzindo a redundância de dados

Copiar ou duplicar dados cria redundância de dados e leva à perda de integridade, perda de linhagem de dados e, muitas vezes, permissões de acesso diferentes. Isso reduz a qualidade dos dados na casa do lago.

Uma cópia temporária ou descartável de dados não é prejudicial em si mesma - às vezes é necessário aumentar a agilidade, a experimentação e a inovação. No entanto, quando essas cópias se tornam operacionais e são usadas regularmente para tomar decisões de negócios, elas se tornam silos de dados. Quando esses silos de dados ficam fora de sincronia, isso tem um impacto negativo significativo na integridade e qualidade dos dados, levantando questões como "Qual conjunto de dados é o mestre?" ou "O conjunto de dados é atual?

Gerencie esquemas ativamente

Alterações de esquema não controladas podem levar a dados inválidos e trabalhos com falha que usam esses conjuntos de dados. O Azure Databricks tem vários métodos para validar e impor o esquema:

• O Delta Lake suporta validação de esquema e imposição de esquema manipulando automaticamente variações de esquema para evitar a inserção de registros incorretos durante a ingestão. Consulte Aplicação do esquema.
• O Auto Loader deteta a adição de novas colunas à medida que processa os seus dados. Por padrão, a adição de uma nova coluna faz com que seus fluxos parem com um UnknownFieldExceptionarquivo . Auto Loader suporta vários modos para a evolução do esquema.

Restrições de uso e expectativas de dados

As tabelas delta suportam cláusulas padrão de gerenciamento de restrições SQL que garantem que a qualidade e a integridade dos dados adicionados a uma tabela sejam verificadas automaticamente. Quando uma restrição é violada, o Delta Lake lança um InvariantViolationException erro para sinalizar que os novos dados não podem ser adicionados. Consulte Restrições no Azure Databricks.

Para melhorar ainda mais esse manuseio, o Delta Live Tables suporta expectativas: as expectativas definem restrições de qualidade de dados no conteúdo de um conjunto de dados. Uma expectativa consiste em uma descrição, um invariante e uma ação a ser tomada se um registro violar o invariante. As expectativas em consultas usam decoradores Python ou cláusulas de restrição SQL. Consulte Gerenciar a qualidade dos dados com o Delta Live Tables.

Adote uma abordagem centrada em dados para o aprendizado de máquina

Um princípio orientador que permanece no centro da visão de IA para a Databricks Data Intelligence Platform é uma abordagem centrada em dados para o aprendizado de máquina. À medida que a IA generativa se torna mais prevalente, esta perspetiva continua a ser igualmente importante.

Os componentes principais de qualquer projeto de ML podem ser simplesmente pensados como pipelines de dados: engenharia de recursos, treinamento, implantação de modelos, inferência e pipelines de monitoramento são todos pipelines de dados. Como tal, a operacionalização de uma solução de ML requer a fusão de dados de previsão, monitoramento e tabelas de recursos com outros dados relevantes. Fundamentalmente, a maneira mais fácil de conseguir isso é desenvolver soluções baseadas em IA na mesma plataforma usada para gerenciar dados de produção. Consulte MLOps e LLMOps centrados em dados

3. Design para dimensionamento automático

Habilitar o dimensionamento automático para cargas de trabalho de ETL

O dimensionamento automático permite que os clusters sejam redimensionados automaticamente com base nas cargas de trabalho. O dimensionamento automático pode beneficiar muitos casos de uso e cenários do ponto de vista de custo e desempenho. A documentação fornece considerações para determinar se o dimensionamento automático deve ser usado e como obter o máximo benefício.

Para cargas de trabalho de streaming, o Databricks recomenda o uso do Delta Live Tables com dimensionamento automático. O dimensionamento automático aprimorado do Databricks otimiza a utilização do cluster alocando automaticamente os recursos do cluster com base no volume da carga de trabalho, com impacto mínimo na latência de processamento de dados de seus pipelines.

Habilitar o dimensionamento automático para SQL warehouse

O parâmetro de dimensionamento de um armazém SQL define o número mínimo e máximo de clusters sobre os quais as consultas enviadas para o armazém são distribuídas. O padrão é um cluster sem dimensionamento automático.

Para lidar com mais usuários simultâneos para um determinado depósito, aumente o número de clusters. Para saber como o Azure Databricks adiciona clusters e remove clusters de um depósito, consulte Dimensionamento, dimensionamento e comportamento de enfileiramento do SQL warehouse.

4. Procedimentos de recuperação de ensaios

Recuperar de falhas de consultas de Transmissão em Fluxo Estruturada

O Streaming Estruturado fornece tolerância a falhas e consistência de dados para consultas de streaming, usando o Databricks Jobs, você pode facilmente configurar suas consultas de Streaming Estruturado para reiniciar automaticamente em caso de falha. Ao habilitar o ponto de verificação para uma consulta de streaming, você pode reiniciar a consulta após uma falha. A consulta reiniciada continuará de onde a consulta com falha parou.

Recupere trabalhos de ETL usando recursos de viagem no tempo de dados

Apesar dos testes minuciosos, um trabalho pode falhar na produção ou produzir dados inesperados, até mesmo inválidos. Às vezes, isso pode ser corrigido com um trabalho adicional depois de entender a origem do problema e corrigir o pipeline que causou o problema em primeiro lugar. No entanto, muitas vezes isso não é simples e o trabalho em questão deve ser revertido. Usando Delta Time travel, os usuários podem facilmente reverter alterações para uma versão mais antiga ou carimbo de data/hora, reparar o pipeline e reiniciar o pipeline fixo.

Uma maneira conveniente de fazer isso é o RESTORE comando.

Aproveite uma estrutura de automação de tarefas com recuperação integrada

Os trabalhos do Databricks são projetados para recuperação. Quando uma tarefa em um trabalho multitarefa falha (e, como tal, todas as tarefas dependentes), os Trabalhos do Azure Databricks fornecem uma exibição matricial das execuções que permite investigar o problema que causou a falha, consulte Exibir execuções para um trabalho. Quer tenha sido um problema de rede curto ou um problema real nos dados, pode corrigi-lo e iniciar uma execução de reparação nos Trabalhos do Azure Databricks. Ele executará apenas as tarefas com falha e dependentes e manterá os resultados bem-sucedidos da execução anterior, economizando tempo e dinheiro, consulte Solucionar problemas e reparar falhas de trabalho

Configurar um padrão de recuperação de desastres

Para uma plataforma de análise de dados nativa da nuvem como o Azure Databricks, um padrão claro de recuperação de desastres é fundamental. É fundamental que suas equipes de dados possam usar a plataforma Azure Databricks mesmo no raro caso de uma interrupção regional em todo o serviço de um provedor de serviços de nuvem, seja causada por um desastre regional, como um furacão, terremoto ou alguma outra fonte.

O Azure Databricks geralmente é uma parte essencial de um ecossistema de dados geral que inclui muitos serviços, incluindo serviços de ingestão de dados upstream (lote/streaming), armazenamento nativo da nuvem, como o Azure Data Lake Storage Gen2, ferramentas e serviços downstream, como aplicativos de business intelligence e ferramentas de orquestração. Alguns dos seus casos de uso podem ser particularmente sensíveis a uma interrupção regional em todo o serviço.

A recuperação de desastres envolve um conjunto de políticas, ferramentas e procedimentos que permitem a recuperação ou a continuação de infraestruturas e sistemas tecnológicos vitais após um desastre natural ou induzido pelo homem. Um grande serviço de nuvem, como o Azure, atende a muitos clientes e tem proteções internas contra uma única falha. Por exemplo, uma região é um grupo de edifícios conectados a diferentes fontes de energia para garantir que uma única queda de energia não derrube uma região. No entanto, podem ocorrer falhas na região da nuvem e a gravidade da falha e o seu impacto no seu negócio podem variar.

5. Automatize implantações e cargas de trabalho

Consulte Excelência operacional - Automatize implantações e cargas de trabalho.

6. Monitorar sistemas e cargas de trabalho

Consulte Excelência operacional - Configurar monitoramento, alerta e registro.