Práticas recomendadas para confiabilidade

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

1. Projeto para falha

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.

Usar um mecanismo de dados distribuídos resiliente para todas as cargas de trabalho

Apache SparkO sistema compute, como o mecanismo 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 todo o Job. 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 sistema de alto desempenho compute compatível com Apache Spark APIs.

Resgate 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, a prática recomendada é filtrar dados inválidos e não conformes na ingestão. O suporte para 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 faltando no 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, 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.
Delta Live Tables: Outra opção para criar fluxo de trabalho para resiliência é usar Delta Live Tables com restrições de qualidade. Veja como gerenciar a qualidade dos dados com Delta Live Tables. De imediato, o Delta Live Tables oferece suporte a três modos: Reter, descartar e falhar em registros inválidos. Para colocar em quarentena os registros inválidos identificados, as regras de expectativa podem ser definidas de forma específica, de modo que os registros inválidos sejam armazenados ("em quarentena") em outra tabela. Consulte Quarentena de dados inválidos.

Configurar Job para novas tentativas automáticas e encerramento

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

Databricks Políticas de repetição de suporte a trabalhos 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 Delta Live Tables também automatiza a recuperação de falhas usando 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 Job, 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 a inferência de lotes e transmissão, use Databricks Job e MLflow para implantar modelos como Apache Spark UDFs para aproveitar a programação do Job, as 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 do machine learning usando MLflow e o expõe como endpoint REST API . Essa funcionalidade usa o serverless compute, o que significa que o endpoint e o recurso compute associado são gerenciados e executados no Databricks cloud account.

Use o serviço gerenciado sempre que possível

Aproveite o serviço gerenciado (serverless compute) da Databricks Data Intelligence Platform, como, por exemplo:

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. Gerencie a qualidade dos dados

Use uma arquitetura de armazenamento em camadas

Faça a curadoria dos dados criando uma arquitetura em camadas e garantindo que a qualidade dos dados aumente à medida que os dados passam 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 reconstruir as camadas subsequentes a partir dessa camada, conforme necessário.
Camada com curadoria (prata): O objetivo 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 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

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 esquemas ativamente

Mudanças de esquema não controladas podem levar a dados inválidos e falha Job que usa esses conjuntos de dados. Databricks tem vários métodos para validar e impor 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 sua 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 manuseio, o Delta Live Tables oferece suporte a 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 sobre as consultas usam decoradores Python ou cláusulas de restrição SQL. Veja como gerenciar a qualidade dos dados com Delta Live Tables.

Adote uma abordagem centrada em dados para machine learning

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 machine learning. À medida que a IA generativa 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 IA na mesma plataforma usada para gerenciar os dados de produção. Consulte MLOps e LLMOps centrados em dados

3. Projeto para autoscale

Habilitar a autoescala para cargas de trabalho do ETL

O autoscale permite que o clusters 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 do Delta Live Tables com autoscale. Databricks O autoscale aprimorado otimiza a utilização do cluster alocando automaticamente o recurso cluster com base no volume da carga de trabalho, com impacto mínimo na latência de processamento de dados do pipeline.

Ativar autoscale para SQL warehouse

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

Para lidar com mais usuários concorrente em um determinado depósito, aumente o número de clusters. Para saber como Databricks adiciona clusters e remove clusters de um depósito, consulte SQL warehouse sizing, scaling, and queuing behavior (comportamento de dimensionamento, dimensionamento e enfileiramento).

4. Teste os procedimentos de recuperação

Recuperar-se de falhas de consulta estruturada transmitida

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, o site Job pode falhar na produção ou produzir dados inesperados, até mesmo inválidos. Às vezes, isso pode ser corrigido com um Job 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 site Job 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`.

Utilize uma estrutura de automação Job 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 Job. Independentemente de ser 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 cloud de análise de dados como Databricks a , 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 cloud, 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), o armazenamento nativo cloud, como Amazon S3, ferramentas e serviços downstream, como Business Intelligence apps, 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 cloud, como o AWS, atende a muitos clientes e tem proteções integradas contra uma única falha. Por exemplo, uma região é um grupo de prédios 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 cloud e a gravidade da falha e seu impacto nos negócios podem variar.

5. Automatize implantações e cargas de trabalho

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

6. Monitorar sistemas e cargas de trabalho

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