Melhores práticas de confiabilidade

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

1. Design para falha

Usar um formato de dados que dê 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. Escolher um formato de dados que dê suporte a transações ACID ajuda a criar pipelines mais simples e muito mais confiáveis.

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

Usar 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, baseia-se no processamento de dados distribuídos resilientes. Se uma tarefa interna do Spark não retornar um resultado conforme o esperado, o Apache Spark reagenda automaticamente as tarefas ausentes e continua 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 do SQL e a API de DataFrame do Spark, essa resiliência é incorporada ao mecanismo.

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

Resgatar automaticamente dados inválidos ou em não conformidade

Dados inválidos ou não em formatação podem causar falhas em 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 em conformidade 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 ele estava ausente do esquema fornecido, porque havia uma incompatibilidade de tipo ou porque o corpo da coluna no registro ou arquivo não correspondia a esse no esquema.

• Carregador Automático do Databricks: o Carregador Automático é a ferramenta ideal para transmitir a ingestão de arquivo. Ele dá suporte a dados resgatados para JSON e CSV. Por exemplo, para JSON, a coluna de dados resgatados contém todos os dados que não foram analisados, possivelmente porque ele estava ausente do esquema fornecido, porque havia uma incompatibilidade de tipo ou porque a inválida da coluna não correspondeu. A coluna de dados resgatados faz parte do esquema retornado pelo Carregador Automático como _rescued_data por padrão, quando o esquema está sendo inferido.
• Tabelas Dinâmicas Delta: outra opção para criar fluxos de trabalho para resiliência é usar Tabelas Dinâmicas Delta com restrições de qualidade. Confira Gerenciar a qualidade dos dados com o Delta Live Tables. Pronto para uso, o Delta Live Tables dá suporte a três modos: reter, descartar e falhar em registros inválidos. Para colocar em quarentena registros inválidos identificados, as regras de expectativa podem ser definidas de maneira específica para que os registros inválidos sejam armazenados ("em quarentena") em outra tabela. Confira Colocar dados inválidos em quarentena.

Configurar trabalhos para novas tentativas e encerramento automáticos

Sistemas distribuídos são complexos e uma falha em um ponto potencialmente pode se disseminar em cascata por todo o sistema.

• Os trabalhos do Azure Databricks dão suporte a políticas de repetição para tarefas que determina quando e quantas vezes as execuções com falha são repetidas. Consulte Definir uma política de repetição.
• 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 novas tentativas crescentes para equilibrar a velocidade e a confiabilidade. Confira os Modos de desenvolvimento e produção.

Por outro lado, uma tarefa pendente pode impedir que todo o trabalho seja concluído, resultando em altos custos. Os trabalhos do Databricks dão suporte à configuração de tempo limite para encerrar trabalhos que levam mais tempo do que o esperado.

Usar infraestrutura de serviço de modelo escalonável e de nível de produção

Para inferência de 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 trabalho, novas tentativas, dimensionamento automático e assim por diante. Consulte Implantar modelos para inferência e previsão em lote.

O serviço de modelo fornece uma infraestrutura escalonável e de nível de produção para o serviço de modelo em tempo real. Ele processa seus modelos de machine learning usando o MLflow e os expõe como pontos de extremidade da API REST. Essa funcionalidade usa a 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.

Usar serviços gerenciados sempre que possível

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

• SQL warehouses sem servidor
• serviço de modelo
• trabalhos sem servidor
• computação sem servidor para notebooks
• Delta Live Tables

Esses serviços são operados pelo Databricks de maneira confiável e escalonável sem nenhum custo adicional para o cliente, tornando as cargas de trabalho mais confiáveis.

2. Gerenciar a qualidade dos dados

Usar uma arquitetura de armazenamento em camadas

Faça a curadoria de 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 camadas é:

• Camada bruta (bronze): os dados de origem são ingeridos no lakehouse na primeira camada e devem ser mantidos lá. Quando todos os dados downstream são criados a partir da camada bruta, é possível recompilar as camadas subsequentes dessa camada, conforme necessário.
• Camada coletada (prata): a finalidade da segunda camada é manter dados limpos, refinados, filtrados e agregados. O objetivo dessa camada é fornecer uma base sólida e confiável para análise e relatórios em todas as funções e funções.
• Camada final (ouro): a terceira camada é criada em torno das necessidades de negócios ou projeto. Ele fornece uma exibição diferente como produtos de dados para outras unidades de negócios ou projetos, preparando dados em relação às necessidades de segurança (como dados anônimos) ou otimizando o desempenho (como com exibições pré-agregadas). Os produtos de dados nessa camada são considerados como a verdade para a empresa.

A camada final deve conter apenas dados de alta qualidade e ser totalmente confiável de uma perspectiva de negócios.

Melhorar 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 no lakehouse.

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, ele tem um impacto negativo significativo na integridade e na qualidade dos dados, levantando questões como "Qual conjunto de dados é o mestre?" ou "O conjunto de dados é atual?"

Gerenciar 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 dá suporte à validação de esquema e à imposição de esquema manipulando automaticamente variações de esquema para evitar a inserção de registros inválidos durante a ingestão. Consulte Imposição do esquema.
• O Carregador Automático detecta a adição de novas colunas à medida que processa seus dados. Por padrão, a adição de uma nova coluna fará com que os fluxos sejam interrompidos com uma UnknownFieldException. O Carregador Automático dá suporte a vários modos de evolução do esquema.

Usar restrições e expectativas de dados

As tabelas Delta dão suporte a cláusulas de gerenciamento de restrição SQL padrão 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 gera um erro InvariantViolationException para sinalizar que os novos dados não podem ser adicionados. Confira Restrições no Azure Databricks.

Para melhorar ainda mais essa manipulação, o Delta Live Tables dá suporte às 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, uma invariável e uma ação a ser tomada se um registro violar o invariável. As expectativas em consultas usam decoradores Python ou cláusulas de restrição SQL. Confira Gerenciar a qualidade dos dados com o Delta Live Tables.

Adotar uma abordagem centrada em dados para aprendizado de máquina

Um princípio norteador que permanece no centro da visão de IA para a Plataforma de Data Intelligence do Databricks é uma abordagem centrada em dados para o aprendizado de máquina. À medida que a IA generativa se torna mais prevalente, essa perspectiva permanece tão importante quanto.

Os principais componentes de qualquer projeto de ML podem simplesmente ser considerados pipelines de dados: engenharia de recursos, treinamento, implantação de modelo, inferência e pipelines de monitoramento são todos pipelines de dados. Dessa forma, a operacionalização de uma solução de ML requer a mesclagem de dados de previsão, monitoramento e tabelas de recursos com outros dados relevantes. Fundamentalmente, a maneira mais fácil de fazer isso é desenvolver soluções alimentadas por IA na mesma plataforma usada para gerenciar dados de produção. Consulte MLOps e LLMOps centrados em dados

3. Design de dimensionamento automático

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

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

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

Habilitar o dimensionamento automático para o SQL warehouse

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

Para lidar com usuários mais simultâneos para um determinado armazém, aumente o número de clusters. Para saber como o Azure Databricks adiciona e remove clusters de um warehouse, confira Dimensionamento, colocação em escala e comportamento de enfileiramento do SQL Warehouse.

4. Testar procedimentos de recuperação

Recuperar-se de falhas de consulta de Streaming Estruturado

O Streaming Estruturado fornece tolerância a falhas e consistência de dados para consultas de streaming. Usando os Trabalhos do Databricks, você poderá facilmente configurar suas consultas de Fluxo Estruturado para reiniciar automaticamente em caso de falha. Ao habilitar o ponto de verificação para uma consulta de streaming, é possível reiniciar a consulta após uma falha. A consulta reiniciada continuará de onde a consulta com falha parou. Consulte Pontos de verificação de streaming estruturado e Considerações de produção para streaming estruturado.

Recuperar trabalhos ETL usando recursos de viagem de tempo de dados

Apesar dos testes completos, 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 a viagem no Tempo do Delta, os usuários podem facilmente reverter as alterações para uma versão ou carimbo de data/hora mais antigo, reparar o pipeline e reiniciar o pipeline fixo.

Uma maneira conveniente de fazer isso é o comando RESTORE.

Aproveitar uma estrutura de automação de trabalho com recuperação interna

Os Trabalhos do Databricks foram criados para recuperação. Quando uma tarefa em um trabalho de várias tarefas falha (e, como tal, todas as tarefas dependentes), os trabalhos do Azure Databricks fornecem uma exibição de matriz das execuções que permitem investigar o problema que causou a falha, consulte Exibir execuções para um trabalho. Se foi um problema de rede curto ou um problema real nos dados, você pode corrigi-lo e iniciar uma execução de reparo 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 no trabalho

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

Para uma plataforma de análise de dados nativa de nuvem, como o Azure Databricks, um padrão de recuperação de desastre claro é fundamental. É fundamental que suas equipes de dados possam usar a plataforma do 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 central de um ecossistema de dados geral que inclui muitos serviços, incluindo serviços de ingestão de dados upstream (lote/streaming), armazenamento nativo de 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 casos de uso podem ser particularmente sensíveis a uma interrupção regional em todo o serviço.

A recuperação de desastre envolve um conjunto de políticas, ferramentas e procedimentos que permitem a recuperação ou continuação de sistemas e infraestruturas de tecnologia vitais após um desastre natural ou induzido pelo homem. Um serviço de nuvem grande, 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 fontes de energia diferentes para garantir que uma única interrupção de energia não derrube uma região. No entanto, podem ocorrer falhas na região de nuvem, e a gravidade da falha e seu impacto em sua empresa podem variar.

5. Automatize implantações e cargas de trabalho

Consulte Excelência Operacional – Automatizar implantações e cargas de trabalho.

6. Monitorar sistemas e cargas de trabalho

Consulte Excelência Operacional – Configurar monitoramento, alertas e registro em log.