As funções de IP estão em disponibilidade geral, trazendo análise de rede de alto desempenho para o Lakehouse

Dados de IP são dados de data warehouse

Cada firewall, balanceador de carga, VPN, borda de CDN, resolvedor de DNS, cluster de Kubernetes e servidor de aplicação emite um fluxo de registros indexados por uma única coisa: um endereço IP. Para uma grande empresa, esses fluxos geram coletivamente dezenas de bilhões de eventos por dia e são a base de algumas das análises mais valiosas que uma organização executa, incluindo detecção de ameaças, investigação de fraudes e observabilidade de rede. Historicamente, o setor tratava esses casos de uso de observabilidade de rede como casos de uso especializados que exigiam uma pilha especializada, levando a silos, governança fragmentada e lock-in.

Isso muda agora. Hoje, as IP Functions estão em disponibilidade geral (GA). Com este lançamento, a análise de endereços IP se torna uma carga de trabalho SQL de alto desempenho e de primeira classe no lakehouse, permitindo que as equipes de segurança analisem, enriqueçam e processem seus dados de IP de maior volume junto com o restante de suas análises, sob um único modelo de governança.

Por que a análise de rede costumava ser difícil

No passado, os endereços IP eram enganosamente difíceis de manipular em SQL. Um endereço IPv4 se parece com uma string, mas se comporta como um número inteiro de 32 bits; o IPv6 tem 128 bits. Um bloco CIDR como 10.0.0.0/8 não é um valor propriamente dito - é um intervalo de 16 milhões de endereços. Perguntar "este IP está dentro daquela sub-rede?" é um problema de contenção de intervalo oculto por trás de um texto.

Sem suporte nativo, as equipes eram forçadas a adotar padrões frágeis, cada um comprometendo a precisão, o desempenho ou a capacidade de manutenção:

O resultado era uma situação em que todos saíam perdendo. Os analistas que usavam apenas SQL ficavam impedidos de fazer filtragem básica de IP porque isso exigia código procedural. Os engenheiros de dados perdiam tempo mantendo bibliotecas de UDF e jobs de expansão de CIDR. Acima de tudo, as cargas de trabalho críticas, como enriquecer bilhões de eventos com tabelas de inteligência de ameaças e geo-IP, demoravam mais de uma hora para rodar, quando a empresa precisava de respostas em minutos. Em escala de petabytes, essa diferença é o que separa a detecção de uma intrusão em andamento de ler sobre ela em um relatório pós-incidente (post-mortem).

Funções nativas de IP, integradas ao SQL

A Databricks apresenta um conjunto completo de funções de IP integradas que tornam os dados de rede cidadãos de primeira classe no lakehouse. Elas tratam IPv4 e IPv6 de forma uniforme, aceitam representações legíveis por humanos STRING e compactas BINARY, compreendem a notação CIDR nativamente e são implementadas no próprio mecanismo para que o otimizador e o Photon possam acelerá-las.

O exemplo abaixo enriquece logs de fluxo de rede brutos com inteligência de ameaças e, em seguida, identifica redes de origem suspeitas que estão varrendo um grande número de destinos e portas. O que antes exigia lógica de análise personalizada e bibliotecas de IP sob medida agora pode ser expresso diretamente em SQL usando operações nativas de IP e CIDR.

Sem UDF. Sem regex. Sem malabarismos com números inteiros. O código é lido exatamente como a pergunta que o analista realmente está fazendo.

As funções

A versão GA traz o kit de ferramentas completo necessário para analisar, normalizar, inspecionar e unir (join) dados de IP:

Contenção e junções (joins)

• ip_cidr_contains(cidr, needle) - testa se um endereço IP ou outro bloco CIDR está dentro de um bloco CIDR. Este é o predicado único por trás de junções de blocos CIDR e filtragem de alto volume, e a função na qual todo o esforço de otimização se concentra.

Análise e canonicalização

• ip_host(ip) - normaliza um endereço IPv4 ou IPv6 para sua forma padrão (por exemplo, reduz 2001:0db8:0000::1 para 2001:db8::1).
• ip_cidr(cidr) - produz a representação canônica de um bloco CIDR.

Inspecionando um CIDR

• ip_network(cidr) / ip_network_first(cidr) - retorna o primeiro endereço (de rede) de um bloco CIDR.
• ip_network_last(cidr) - retorna o último endereço de um bloco CIDR.
• ip_prefix_length(cidr) - retorna o comprimento do prefixo (o número após a /).
• ip_version(ip_or_cidr) - retorna 4 ou 6 para que endereços de protocolos mistos possam ser ramificados sem a necessidade de casos especiais

Conversão de representação - para desempenho

• ip_as_binary(ip_or_cidr) - converte um endereço ou CIDR para sua forma binária compacta e canônica (4 bytes para IPv4, 16 para IPv6). Armazenar e realizar junções em BINARY evita análises repetidas e reduz o armazenamento.
• ip_as_string(ip_or_cidr) - converte uma representação binária de volta para texto legível por humanos para relatórios.

Variantes seguras para dados desorganizados

• try_ip_host(ip), try_ip_cidr(cidr), try_ip_as_binary(ip_or_cidr), try_ip_as_string(ip_or_cidr) - idênticas às suas contrapartes, mas retornam NULL em vez de gerar erro em entradas inválidas. Essencial ao ingerir logs brutos onde uma fração dos registros é sempre malformada, garantindo que uma linha ruim nunca cause a falha de um job de um bilhão de linhas.

Essas funções nativas se integram naturalmente com o restante do SQL, estão disponíveis para todos os usuários de SQL sem necessidade de configuração, e o otimizador as compreende, o que viabiliza esse nível de desempenho.

A Rearc, que ajuda empresas a desenvolver plataformas de GenAI, dados e nuvem, está aproveitando as IP Functions para criar casos de uso de observabilidade de rede para clientes de grande escala.

Desenvolvemos um produto para uma grande empresa financeira que processa regularmente mais de 30 TB de dados por dia, onde o desempenho e a eficiência de custos são essenciais. Com as funções de IP nativas do mecanismo do Databricks, conseguimos analisar, validar e fazer join de dados de IP diretamente em SQL, substituindo uma implementação ad-hoc anterior por algo muito mais elegante e fácil de manter. Como as funções são integradas ao mecanismo, conseguimos isso sem sacrificar o desempenho que nossas cargas de trabalho exigem nessa escala. Elas tornaram a análise de rede no lakehouse mais simples e rápida de entregar." —Dara Kharabi, Practice Lead, AI & Data na Rearc

Criado para a escala de petabytes: segundos, não minutos

Um desafio comum na análise de IP é encontrar um único endereço ou sub-CIDR dentro de um intervalo muito maior, o que é fundamental para detectar ameaças rapidamente, investigar fraudes e monitorar a atividade de rede em escala. Este caso de uso representa um range join, com o qual os mecanismos historicamente têm tido dificuldades porque os algoritmos de join padrão dependem de igualdade. O mecanismo do Databricks suporta um range join otimizado para endereços IP via ip_cidr_contains. 

O ip_cidr_contains do Databricks supera os data warehouses tradicionais em preço e velocidade em todas as escalas de tabelas de probe (ou seja, “agulha”) e block (ou seja, “palheiro”). Realizamos testes de benchmark do ip_cidr_contains em cinco cenários representativos:

Os resultados mostram que o desempenho das IP Functions do Databricks é muito superior ao dos concorrentes, mesmo em escalas cada vez maiores. Quando o número de probes excede 10B de endereços IP e o número de blocos passa de 1M de CIDRs, a velocidade da consulta começa a se estabilizar. 

A diferença de custo é igualmente impressionante. Mesmo com o aumento das cargas de trabalho, o Databricks continua sendo de 2x a até 6,4x mais barato.

A Stanby percebeu rapidamente o valor de executar seus casos de uso de monitoramento de rede diretamente no lakehouse, em vez de em sistemas externos:

"As funções de IP nativas do Databricks nos permitem trabalhar com dados de IP e CIDR diretamente em SQL. Não precisamos mais depender de análises de strings frágeis ou lógica bit a bit manual. Poder analisar, validar e fazer join de dados de IP como operações SQL de primeira classe tornou esse trabalho mais simples e fácil de manter para nossa equipe. É uma escolha natural para executar análises de rede e tráfego junto com o restante de nossos dados no lakehouse."—Stanby, Líder de Engenharia de Dados

No final das contas, essas IP Functions de alto desempenho permitem que toda uma classe de cargas de trabalho de rede seja criada diretamente no lakehouse.

O que isso possibilita

Com funções de IP rápidas e nativas, cargas de trabalho inteiras que antes não podiam ser executadas lá são transferidas para o lakehouse:

• Joins de enriquecimento de CIDR em escala - adicione tags a cada evento com metadados de GeoIP, ASN, inteligência de ameaças ou propriedade em segundos, para que as consultas de detecção e investigação downstream sejam executadas em dados enriquecidos.
• Filtragem em tempo real de alto volume - "mostre-me cada conexão deste /16 suspeito nas últimas 24 horas" torna-se uma consulta interativa em vez de um job em lote (batch).
• Análise unificada de IPv4 e IPv6 - tabelas de protocolos mistos funcionam prontas para uso, para que o tráfego moderno seja analisado, não descartado.
• Correspondência de CIDR em CIDR - verifique se uma sub-rede inteira está dentro de outra, com o mesmo desempenho de IP em CIDR, para análise de topologia de rede e políticas.
• Acessibilidade SQL de primeira classe - os analistas obtêm filtragem de IP e joins com SQL simples, sem a necessidade de código procedural ou bibliotecas UDF.

Com essas funções suportadas nativamente no lakehouse, essas cargas de trabalho de rede compartilham uma única cópia governada dos dados com o restante da empresa — sem a necessidade de um sistema especializado separado para licenciar, proteger e manter sincronizado.

Comece hoje mesmo

As funções de IP nativas já estão em Disponibilidade Geral (GA) no Databricks Runtime LTS ou posterior. 

Consulte a documentação de referência das funções de IP para obter a lista completa de funções e assinaturas. O fluxo de dados de rede sempre foi um dos seus maiores conjuntos de dados — agora ele pode finalmente residir onde o restante de suas análises está.

(Esta publicação no blog foi traduzida utilizando ferramentas baseadas em inteligência artificial) Publicação original