A Databricks está animada para apresentar a observabilidade aprimorada de streaming dentro dos Workflows e pipelines Delta Live Tables (DLT). Este recurso fornece às equipes de engenharia de dados ferramentas robustas para otimizar o processamento de dados em tempo real. A interface do usuário foi projetada para ser intuitiva, permitindo que os usuários monitorem métricas-chave como duração do backlog em segundos, bytes processados, registros ingeridos e arquivos manipulados em fontes de streaming proeminentes como Kafka, Kinesis, Delta e Autoloader.
Com a implementação de alertas proativos em nível de tarefa, a ambiguidade é removida do gerenciamento de backlog, facilitando a utilização mais eficiente dos recursos de computação e garantindo a manutenção da atualidade dos dados. Essas inovações capacitam as organizações a escalar análises em tempo real com confiança, melhorando assim os processos de tomada de decisão e impulsionando resultados superiores através de pipelines de streaming confiáveis e de alto desempenho.
Um backlog crescente geralmente indica problemas subjacentes, que podem variar desde correções únicas até a necessidade de reconfiguração ou otimização para lidar com volumes de dados aumentados. Abaixo estão algumas áreas críticas nas quais as equipes de engenharia se concentram para manter a taxa de transferência e a confiabilidade de um pipeline de streaming.
Compreender o backlog de um fluxo anteriormente exigia várias etapas. No Delta Live Tables, isso envolvia a análise contínua do registro de eventos do pipeline para extrair informações relevantes. Para o Structured Streaming, os engenheiros geralmente contavam com o StreamingQueryListener do Spark para capturar e enviar métricas de backlog para ferramentas de terceiros, o que introduzia um overhead adicional de desenvolvimento e manutenção. A configuração de mecanismos de alerta adicionou mais complexidade, exigindo mais código personalizado e configuração.
Depois que as métricas são entregues, ainda existem desafios em gerenciar as expectativas em relação ao tempo necessário para limpar o backlog. Fornecer estimativas precisas para quando os dados irão se atualizar envolve variáveis como taxa de transferência, disponibilidade de recursos e a natureza dinâmica das cargas de trabalho de streaming, tornando as previsões precisas difíceis.
Com o lançamento da observabilidade de streaming, os engenheiros de dados agora podem facilmente detectar e gerenciar atrasos por meio de indicadores visuais nos Workflows e na interface do usuário do DLT. As métricas de backlog de streaming estão lado a lado com o código dos notebooks Databricks na interface do usuário dos Workflows.
O gráfico de métricas de streaming, exibido no painel direito da interface do Workflow, destaca o backlog. Este gráfico mostra o volume de dados não processados ao longo do tempo. Quando a taxa de processamento de dados fica atrás da taxa de entrada de dados, começa a acumular um atraso, claramente visualizado no gráfico.
A Databricks também está aprimorando sua funcionalidade de alerta, incorporando métricas de backlog juntamente com suas capacidades existentes, que incluem alertas para início, duração, falha e sucesso. Os usuários podem definir limites para métricas de streaming dentro da interface do usuário dos Workflows, garantindo que notificações sejam acionadas sempre que esses limites forem ultrapassados. Alertas podem ser configurados para enviar notificações via email, Slack, Microsoft Teams, webhooks ou PagerDuty. A melhor prática recomendada para implementar notificações em pipelines DLT é orquestrá-las usando um Fluxo de Trabalho Databricks.
A notificação acima foi entregue por e-mail e permite que você clique diretamente na interface do usuário dos Fluxos de Trabalho.
Gerenciar e otimizar pipelines de streaming em Delta Live Tables é um desafio significativo, particularmente para equipes que lidam com fontes de dados de alta capacidade, como o Kafka. À medida que o volume de dados aumenta, o backlog também aumenta, o que leva à degradação do desempenho. Em DLT sem servidor, recursos como pipeline de streaming e autoescalabilidade vertical ajudam a manter o desempenho do sistema de forma eficaz, ao contrário do não servidor, onde essas capacidades não estão disponíveis.
Um grande problema é a falta de visibilidade em tempo real nas métricas de backlog, o que dificulta a capacidade das equipes de identificar rapidamente problemas e tomar decisões informadas para otimizar o pipeline. Atualmente, os pipelines DLT dependem de métricas de log de eventos, que exigem painéis personalizados ou soluções de monitoramento para rastrear atrasos de forma eficaz.
No entanto, o novo recurso de observabilidade de streaming permite que os engenheiros de dados identifiquem e gerenciem rapidamente os atrasos através da interface do DLT, melhorando a eficiência do monitoramento e otimização.
Aqui vamos examinar um pipeline do Delta Live Tables que ingere dados do Kafka e os escreve em uma tabela Delta de streaming. O código abaixo representa a definição da tabela em DLT.
O kafka_stream_bronze é uma tabela Delta de streaming criada no pipeline, projetada para processamento contínuo de dados. A configuração maxOffsetsPerTrigger, configurada para 1000, controla o número máximo de offsets do Kafka que podem ser processados por intervalo de gatilho dentro do pipeline DLT. Este valor foi determinado analisando a taxa de processamento necessária com base no tamanho atual dos dados. O pipeline está processando dados históricos do Kafka como parte de sua configuração inicial.
Inicialmente, os fluxos Kafka estavam produzindo menos de 1000 registros por segundo, e as métricas de atraso mostravam uma queda constante (conforme mostrado na imagem1). Quando o volume de dados vindos do Kafka começa a aumentar, o sistema começa a mostrar sinais de tensão (como mostrado nas imagens 2 e 3), o que indica que o processamento está lutando para acompanhar o volume crescente de dados. A configuração inicial levará a atrasos no processamento, exigindo uma reavaliação das configurações da instância e de configuração.
Ficou claro que a configuração inicial, que limitava maxOffsetsPerTrigger a 1000, era insuficiente para lidar efetivamente com a carga crescente. Para resolver isso, a configuração foi ajustada para permitir até 10.000 offsets por gatilho, conforme mostrado abaixo.
Isso ajudou o pipeline a processar lotes de dados maiores em cada gatilho, aumentando significativamente a taxa de transferência. Após fazer esse ajuste, vimos uma redução consistente nas métricas de backlog (imagem 4), indicando que o sistema estava conseguindo acompanhar o fluxo de dados de entrada. A redução do backlog melhorou o desempenho geral do sistema.
Esta experiência destaca a importância de visualizar as métricas de backlog de stream, pois permite ajustes proativos nas configurações e garante que o pipeline possa gerenciar efetivamente as necessidades de dados em mudança. O rastreamento em tempo real do backlog nos permitiu otimizar o pipeline de streaming do Kafka, reduzindo atrasos e melhorando a taxa de transferência de dados sem a necessidade de consultas complexas de log de eventos ou navegação na interface do usuário do Spark.
Não deixe gargalos te pegarem de surpresa. Aproveite nossas novas capacidades de observabilidade para monitorar o backlog, a atualidade e o throughput. Experimente hoje e experimente o gerenciamento de pipeline de dados sem estresse.
(This blog post has been translated using AI-powered tools) Original Post