Práticas recomendadas para confiabilidade

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

1. Design para falhas

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

As transações ACID são um recurso essencial para manter a integridade de dados e a consistência. A escolha de um formato de dados compatível com transações ACID ajuda a criar pipelines mais simples e muito mais confiáveis.

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 escalonável e unifica o processamento de dados de transmissão e lotes. Delta Lake é totalmente compatível com o site Apache Spark APIs e foi projetado para uma forte integração com a transmissão estruturada, permitindo que o senhor use facilmente uma única cópia de dados para operações de lotes e transmissão e forneça processamento incremental em escala.

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

Apache SparkO mecanismo compute do Databricks lakehouse baseia-se no processamento resiliente de dados distribuídos. Se uma tarefa interna do Spark não retornar um resultado como esperado, o Apache Spark reprograma automaticamente a tarefa ausente e continua a executar o trabalho inteiro. Isso é útil para falhas fora do código, como um breve problema de rede ou uma VM Spot revogada. Trabalhando com a API SQL e a API DataFrame do Spark, essa resiliência é incorporada ao mecanismo.

No site Databricks lakehouse, Photon, um mecanismo vetorial nativo totalmente escrito em C++, é um mecanismo de alto desempenho compute compatível com Apache Spark APIs.

Recupere 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 a dados resgatados garante que o senhor 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 no esquema especificado, porque havia uma incompatibilidade de tipos 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, no caso do JSON, a coluna de dados resgatados contém todos os dados que não foram analisados, possivelmente porque estavam faltando no esquema fornecido, porque havia uma incompatibilidade de tipo ou porque o maiúsculas e minúsculas da coluna não correspondia. A coluna de dados resgatada faz parte do esquema retornado por Auto Loader como _rescued_data por default quando o esquema está sendo inferido.
• DLT: Outra opção para criar fluxo de trabalho para resiliência é usar DLT com restrições de qualidade. Veja como gerenciar a qualidade dos dados com pipeline expectativas. A DLT oferece suporte a três modos pelo site default: reter, descartar e falhar em registros inválidos. Para colocar em quarentena registros inválidos identificados, as regras de expectativa podem ser definidas de uma forma específica para que os registros inválidos sejam armazenados (“em quarentena”) em outra tabela. Consulte Quarentena de registros inválidos.

Configurar o Job para novas tentativas e encerramento automático

Os sistemas distribuídos são complexos e uma falha em um ponto pode potencialmente ocorrer em cascata por todo o sistema.

• Databricks Políticas de repetição de suporte de trabalho para tarefas que determinam quando e quantas vezes as execuções com falha são repetidas. Consulte Definir uma política de novas tentativas.
• O senhor pode configurar um limite de duração opcional para uma tarefa, incluindo um tempo de conclusão esperado para a tarefa e um tempo de conclusão máximo para a tarefa.
• O DLT também automatiza a recuperação de falhas usando novas tentativas crescentes para equilibrar velocidade e confiabilidade. Consulte Modos de desenvolvimento e produção.

Por outro lado, uma tarefa pendente pode impedir a conclusão de todo o trabalho, resultando em altos custos. Databricks Configuração do tempo limite do suporte a trabalhos para eliminar trabalhos que demoram mais do que o esperado.

Use uma infraestrutura de modelo de serviço dimensionável e de nível de produção

Para inferência de lotes e transmissão, use o Databricks Job e o MLflow para implantar modelos como Apache Spark UDFs para aproveitar a programação do Job, as novas tentativas, a escala automática e assim por diante. Consulte modelos implantados para inferência e previsão de lotes.

A servindo modelo fornece uma infraestrutura escalável e de nível de produção para a servindo modelo tempo real. Ele processa seu modelo de aprendizado de máquina usando MLflow e os expõe como REST API endpoint. Essa funcionalidade usa serverless compute, o que significa que o endpoint e o recurso compute associado são gerenciados e executados na nuvem Databricks account.

Aproveite o serviço gerenciado, como serverless SQL warehouse e servindo modelo sempre que possível. Esses serviços são operados pelo site Databricks de forma confiável e dimensionável, sem custo adicional para o cliente, tornando as cargas de trabalho mais confiáveis.

2. gerenciar a qualidade dos dados

Use uma arquitetura de armazenamento em camadas

Organize os 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 posteriores são criados a partir da camada bruta, é possível reconstruir as camadas subsequentes a partir dessa camada conforme necessário.
• Camada curada (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 geração de relatórios em todos os cargos e funções.
• Camada final (ouro): A terceira camada é criada com base nas necessidades do negócio ou do projeto. Ele oferece um view diferente como produto de dados para outras unidades de negócios ou projetos, preparando os dados em torno das necessidades de segurança (como dados anônimos) ou otimizando o desempenho (como a visualização pré-agregada). Os dados produzidos nessa camada são considerados a verdade para os negócios.

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

Melhorar a integridade dos dados, reduzindo a redundância de dados

A cópia ou duplicação de dados cria redundância de dados e leva à perda de integridade, à perda de linhagem de dados e, muitas vezes, a diferentes permissões de acesso. Isso reduz a qualidade dos dados no lakehouse.

Uma cópia temporária ou descartável dos dados não é prejudicial por si só — às vezes é necessária para 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 na qualidade dos dados, levantando questões como "Qual conjunto de dados é o principal?" ou "O conjunto de dados está atualizado?

Gerenciar ativamente os esquemas

Alterações não controladas no esquema podem levar a dados inválidos e a falhas no trabalho que usa esses conjuntos de dados. A Databricks tem vários métodos para validar e aplicar o esquema:

• Delta Lake oferece suporte à validação de esquema e à imposição de esquema, tratando automaticamente as variações de esquema para evitar a inserção de registros incorretos durante a ingestão. Ver imposição de esquema.
• O Auto Loader detecta a adição de novas colunas à medida que processa seus dados. Em default, a adição de uma nova coluna faz com que a transmissão pare com um UnknownFieldException. O Auto Loader oferece suporte a vários modos de evolução do esquema.

Use restrições e expectativas de dados

As tabelas Delta suportam cláusulas de gerenciamento de restrições 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 lança um erro InvariantViolationException para sinalizar que os novos dados não podem ser adicionados. Consulte Restrições em Databricks.

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

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

Um princípio orientador que permanece no centro da visão da AI para a Databricks Data Intelligence Platform é uma abordagem centrada em dados para o aprendizado de máquina. À medida que o AI generativo se torna mais predominante, essa perspectiva continua sendo igualmente importante.

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

3. Projeto para autoescala

Habilitar a autoescala para cargas de trabalho do ETL

O autoscale permite que o clustering seja redimensionado automaticamente com base nas cargas de trabalho. A autoescala pode beneficiar muitos casos de uso e cenários, tanto do ponto de vista do custo quanto do desempenho. A documentação fornece considerações para determinar se o autoscale deve ser usado e como obter o máximo de benefícios.

Para cargas de trabalho de transmissão, o site Databricks recomenda o uso de DLT com autoescala. Databricks O autoscale aprimorado otimiza a utilização do clustering alocando automaticamente o recurso de clustering com base no volume da carga de trabalho, com impacto mínimo sobre a latência do processamento de dados do pipeline.

Habilitar a escala automática para SQL warehouse

O parâmetro de dimensionamento de um SQL warehouse define o número mínimo e máximo de agrupamentos pelos quais as consultas enviadas ao depósito são distribuídas. O site default é um clustering único sem autoescala.

Para lidar com mais usuários concorrentes em um determinado depósito, aumente o número de clustering. Para saber como o site Databricks adiciona e remove o clustering de um depósito, consulte SQL warehouse sizing, scaling, and queuing behavior.

4. Procedimentos de recuperação de testes

Recuperação de falhas na consulta de transmissão estruturada

A transmissão estruturada oferece tolerância a falhas e consistência de dados para consultas de transmissão. Usando o Databricks Jobs, o senhor pode configurar facilmente suas consultas de transmissão estruturada para reiniciar automaticamente em caso de falha. Ao ativar o checkpointing para uma consulta de transmissão, o senhor pode reiniciar a consulta após uma falha. A consulta reiniciada continuará de onde a consulta falhada parou. Veja os pontos de controle da transmissão estruturada e as considerações de produção para a transmissão estruturada.

Recuperar ETL Job usando recursos de viagem de dados do tempo

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 o Delta Time travel, os usuários podem reverter facilmente as alterações para uma versão ou data/hora mais antiga, reparar o pipeline e reiniciar o pipeline corrigido.

Uma maneira conveniente de fazer isso é o comando RESTORE comando.

Utilizar uma estrutura de automação de trabalhos com recuperação integrada

Os Jobs da Databricks são projetados para recuperação. Quando uma tarefa em um Job multitarefa falha (e, como tal, todas as tarefas dependentes), o Databricks Jobs fornece uma matriz view da execução que permite que o senhor investigue o problema que causou a falha, consulte visualizar a execução de um único Job. Não importa se foi um problema de rede de curta duração ou um problema real nos dados, o senhor pode corrigi-lo e começar uma execução de reparo em Databricks Jobs. Ele executará apenas a tarefa com falha e a tarefa dependente e manterá os resultados bem-sucedidos da execução anterior, economizando tempo e dinheiro; consulte Solução de problemas e reparo de falhas de trabalho

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

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

Databricks é geralmente uma parte central de um ecossistema geral de dados que inclui muitos serviços, inclusive o serviço de ingestão de dados upstream (lotes/transmissão), armazenamento nativo em nuvem, como Google Cloud Storage, ferramentas e serviços downstream, como aplicativos de Business Intelligence e ferramentas de orquestração. Alguns de 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 continuidade da infraestrutura e dos sistemas tecnológicos vitais após um desastre natural ou induzido pelo homem. Um grande serviço de nuvem, como o Google Cloud, atende a muitos clientes e tem proteções integradas 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, falhas na região da nuvem podem ocorrer, e a gravidade da falha e seu impacto em sua empresa podem variar.

5. Automatize implantações e cargas de trabalho

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

6. Monitore sistemas e cargas de trabalho

Consulte Excelência operacional - Configure o monitoramento, os alertas e o registro.