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 Delta Lake

Delta Lake é um formato de armazenamento de código aberto que traz confiabilidade aos data lakes. O Delta Lake fornece transações ACID, aplicação de esquema, manipulação de metadados escaláveis e unifica o processamento de dados de lotes e transmissão. A execução do Delta Lake sobre seu data lake existente é totalmente compatível com as APIs do Apache Spark. O Delta Lake no Databricks permite que você configure o Delta Lake com base em seus padrões de carga de trabalho. Veja O que é Delta Lake?.

Use Apache Spark ou Photon para computação distribuída

O Apache Spark, como o mecanismo compute do Databricks lakehouse, baseia-se no processamento de dados distribuídos resilientes. Caso uma tarefa interna do Spark não retorne um resultado conforme o esperado, o Apache Spark reprograma automaticamente as tarefas ausentes e continua com a execução de todo o Job. Isso é útil para falhas fora do código, como um problema de rede curto ou uma VM local revogada. Trabalhar com a API SQL e a API DataFrame do Spark vem com essa resiliência incorporada ao mecanismo.

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

Resgate automaticamente dados inválidos ou não conformes

Dados inválidos ou não conformes podem levar a falhas de 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 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 estava faltando no esquema fornecido, porque havia uma incompatibilidade de tipo ou a capitalização da coluna no registro ou arquivo não correspondia ao esquema.

  • Databricks Auto Loader: O Auto Loader é a ferramenta ideal para transmissão da ingestão de arquivos. Ele suporta 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 estavam ausentes do esquema fornecido, porque havia uma incompatibilidade de tipo ou porque as maiúsculas e minúsculas da coluna não correspondiam. A coluna de dados resgatados faz parte do esquema retornado pelo Auto Loader como _rescued_data por default quando o esquema está sendo inferido.

  • Delta Live Tables: Outra opção para construir fluxo de trabalho para resiliência é usar Delta Live Tables com restrições de qualidade. Veja como gerenciar qualidade de dados com Delta Live Tables. Pronto para uso, 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 para que os registros inválidos sejam armazenados (“quarentenados”) em outra tabela. Consulte Colocar dados inválidos em quarentena.

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.

Por outro lado, uma tarefa que trava pode impedir que todo Job seja finalizado, gerando altos custos. Job do Databricks oferece suporte a uma configuração de tempo limite para encerrar Job que leva mais tempo do que o esperado.

Use uma infraestrutura de atendimento de modelo escalonável e de nível de produção

Para inferência de lotes e transmissão, use Databricks Job e MLflow para implantar modelos como Apache Spark UDFs para aproveitar a programação Job , retries, autoscale e assim por diante. Consulte Usar MLflow para inferência de modelo.

2. Gerencie 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 de camadas comum é:

  • 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, a reconstrução das camadas subsequentes dessa camada é possível, se necessário.

  • Camada selecionada (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álises e relatórios em todas as funções.

  • Camada final (ouro): a terceira camada é criada em torno das necessidades do negócio ou do projeto. Ele fornece uma view diferente como produtos de dados para outras unidades de negócios ou projetos, preparando dados em torno das necessidades de segurança (como dados anônimos) ou otimizando o desempenho (como com view pré-agregada). Os produtos de dados nesta camada são vistos como a verdade para o negócio.

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

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

Copiar ou duplicar dados cria redundância de dados e levará à perda de integridade, perda de linhagem de dados e, muitas vezes, a diferentes permissões de acesso. Isso diminuirá a qualidade dos dados na 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, se essas cópias se tornarem operacionais e usadas regularmente para decisões de negócios, elas se tornarão silos de dados. Esses silos de dados ficando fora de sincronia têm um impacto negativo significativo na integridade e qualidade dos dados, levantando questões como “Qual conjunto de dados é o mestre?” ou “Os dados configurados estão atualizados?”.

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:

  • O Delta Lake oferece 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.

  • O Auto Loader detecta a adição de novas colunas à medida que processa seus dados. Por 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 oferecem 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 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 Delta Live Tables oferece suporte a Expectations: Expectations definem restrições de qualidade de dados no conteúdo de um conjunto de dados. Uma expectativa consiste em uma descrição, uma invariante e uma ação a ser executada quando um registro falha na invariante. As expectativas para query usam decoradores Python ou cláusulas de restrição SQL. Veja como gerenciar qualidade de dados com Delta Live Tables.

Adote uma abordagem centrada em dados para machine learning

engenharia de recursos, treinamento, inferência e pipeline de monitoramento são pipeline de dados. Eles devem ser tão robustos quanto outros processos de engenharia de dados de produção. A qualidade dos dados é fundamental em qualquer aplicativo ML, portanto, o ML pipeline de dados deve empregar abordagens sistemáticas para monitorar e atenuar os problemas de qualidade dos dados. Evite ferramentas que dificultem a join dos dados de previsões de ML, monitoramento de modelos e assim por diante, com o restante de seus dados. A maneira mais simples de conseguir isso é desenvolver aplicativos de ML na mesma plataforma usada para gerenciar os dados de produção. Por exemplo, em vez de fazer o download dos dados de treinamento para um laptop, onde é difícil controlar e reproduzir os resultados, proteja os dados no armazenamento em nuvem e disponibilize esse armazenamento para o seu processo de treinamento.

3. Projeto para autoscale

Ativar autoscale para cargas de trabalho de lotes

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 Databricks recomenda o uso Delta Live Tables com autoscale. Consulte Usar autoscale para aumentar a eficiência e reduzir o uso de recursos.

Ativar autoscale para SQL warehouse

O parâmetro de escala de um SQL warehouse define o número mínimo e máximo de clusters sobre os quais query enviadas ao warehouse são distribuídas. O default é um mínimo de um e um máximo de um clusters.

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

Use autoscaleaprimorada do Delta Live Tables

autoscaleaprimorado do Databricks otimiza a utilização clusters alocando automaticamente recursos clusters com base no volume de carga de trabalho, com impacto mínimo na latência de processamento de dados de seus pipelines.

4. Teste os procedimentos de recuperação

Crie backups regulares

Para se recuperar de uma falha, os backups regulares devem estar disponíveis. O projeto migrate do Databricks Labs permite que os administradores do workspace criem backups exportando a maior parte do ativo de seu espaço de trabalho (a ferramenta usa a CLI/API do Databricks em segundo plano). Consulte Databricks Migration Tool. Os backups podem ser usados para restaurar o espaço de trabalho ou para importar para um novo workspace no caso de uma migração.

Recuperar-se de falhas de consulta estruturada transmitida

A transmissão estruturada fornece tolerância a falhas e consistência de dados para query de transmissão. Usando o fluxo de trabalho do Databricks, você pode configurar facilmente sua query de transmissão estruturada para reiniciar automaticamente em caso de falha. A query reiniciada continua onde a que falhou parou. Consulte Recuperar de falhas de consulta de transmissão estruturada com fluxo de trabalho.

Recuperar ETL Job baseado em Delta viagem do tempo

Apesar do teste minucioso, um Job em produção pode falhar ou produzir alguns 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 levou ao problema em primeiro lugar. No entanto, muitas vezes isso não é direto e o respectivo Job deve ser revertido. O uso do Delta viagem do tempo permite que os usuários revertam facilmente as alterações para uma versão ou carimbo de data/hora mais antigo, reparem o pipeline e reiniciem o pipeline fixo. Veja O que é Delta Lake viagem do tempo?.

Uma maneira conveniente de fazer isso é o comando RESTORE .

Use o fluxo de trabalho do Databricks e a recuperação integrada

Databricks fluxo de trabalho são construídos para a recuperação. Quando uma tarefa em um Job multitarefa falha (e, como tal, todas as tarefas dependentes), o fluxo de trabalho do Databricks fornece uma view de matriz da execução, que permite examinar o problema que levou à falha. Consulte Exibir execução de um Job. Quer tenha sido um problema de rede curto ou um problema real nos dados, você pode corrigi-lo e começar a executar um reparo no fluxo de trabalho do Databricks. Ele executa apenas as tarefas com falha e dependentes e mantém os resultados bem-sucedidos da execução anterior, economizando tempo e dinheiro.

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

Um padrão claro de recuperação de desastres é crítico para uma plataforma analítica de dados cloud nativa como o Databricks. Para algumas empresas, é fundamental que suas equipes de dados possam usar a plataforma Databricks mesmo no caso raro de uma interrupção do provedor de serviços cloudem todo o serviço regional, causada por um desastre regional como um furacão ou terremoto ou outra fonte.

O Databricks costuma ser uma parte essencial de um ecossistema de dados geral que inclui muitos serviços, incluindo serviços de ingestão de dados upstream (lotes/transmissão), armazenamento cloud nativo, ferramentas e serviços downstream, como aplicativos 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 continuação de infraestrutura e sistemas de tecnologia vital após um desastre natural ou induzido pelo homem. Um grande serviço cloud como Azure, AWS ou GCP atende a muitos clientes e possui 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 desligue uma região. No entanto, podem ocorrer falhas na região cloud , e o grau de interrupção e seu impacto em sua organização podem variar. Consulte Recuperação de desastres.

As partes essenciais de uma estratégia de recuperação de desastres são selecionar uma estratégia (ativa/ativa ou ativa/passiva), selecionar o conjunto de ferramentas correto e testar o failover e a restauração.

5. Automatize implantações e cargas de trabalho

Nos artigos de excelência operacional, consulte Excelência operacional - automatizar implantações e cargas de trabalho.

6. Configurar monitoramento, alerta e registro

Nos artigos de práticas recomendadas de excelência operacional, consulte Excelência operacional - configurar monitoramento, alerta e registro.