Les fonctions IP sont désormais généralement disponibles, apportant des analyses réseau haute performance au Lakehouse

Les données IP sont des données d'entreposage

Chaque pare-feu, équilibreur de charge, VPN, point de terminaison CDN, résolveur DNS, cluster Kubernetes et serveur d'application émet un flux d'enregistrements indexés sur une seule chose : une adresse IP. Pour une grande entreprise, ces flux génèrent collectivement des dizaines de milliards d'événements par jour et constituent le fondement de certaines des analyses les plus précieuses qu'une organisation puisse réaliser, notamment la détection des menaces, les enquêtes sur les fraudes et l'observabilité du réseau. Historiquement, le secteur traitait ces cas d'usage d'observabilité réseau comme des cas d'usage spécialisés nécessitant une pile technologique dédiée, ce qui entraînait des silos, une gouvernance fragmentée et un verrouillage technologique.

Tout cela change aujourd'hui. Aujourd'hui, les fonctions IP sont disponibles en version générale (GA). Avec ce lancement, l'analyse des adresses IP devient une charge de travail SQL de premier plan et hautement performante sur le lakehouse, permettant aux équipes de sécurité d'analyser, d'enrichir et de traiter leurs données IP aux volumes les plus élevés aux côtés du reste de leurs analyses, sous un modèle de gouvernance unique.

Pourquoi l'analyse réseau était autrefois si difficile

Par le passé, les adresses IP étaient étonnamment difficiles à gérer en SQL. Une adresse IPv4 ressemble à une chaîne de caractères mais se comporte comme un entier de 32 bits ; l'IPv6 fait 128 bits. Un bloc CIDR comme 10.0.0.0/8 n'est pas du tout une valeur : c'est une plage de 16 millions d'adresses. Se demander « cette IP est-elle dans ce sous-réseau ? » est un problème d'inclusion de plage masqué derrière un simple texte.

Sans prise en charge native, les équipes étaient contraintes d'adopter des approches fragiles, chacune sacrifiant l'exactitude, les performances ou la maintenabilité :

Le résultat était perdant-perdant. Les analystes utilisant uniquement SQL étaient exclus du filtrage IP de base car cela nécessitait du code procédural. Les ingénieurs de données perdaient un temps précieux à maintenir des bibliothèques d'UDF et des tâches d'expansion de CIDR. Surtout, les charges de travail critiques, comme l'enrichissement de milliards d'événements à l'aide de tables de threat intelligence et de géo-IP, prenaient plus d'une heure alors que l'entreprise avait besoin de réponses en quelques minutes. À l'échelle du pétaoctet, cet écart fait toute la différence entre intercepter une intrusion en cours et en lire le rapport d'autopsie.

Fonctions IP natives, intégrées à SQL

Databricks introduit un ensemble complet de fonctions IP intégrées qui font des données réseau un citoyen de première classe du lakehouse. Elles gèrent l'IPv4 et l'IPv6 de manière uniforme, acceptent à la fois les représentations lisibles par l'homme STRING et compactes BINARY, comprennent nativement la notation CIDR, et sont implémentées directement dans le moteur afin que l'optimiseur et Photon puissent les accélérer.

L'exemple ci-dessous enrichit les journaux de flux réseau bruts avec de la threat intelligence, puis identifie les réseaux sources suspects qui scannent un grand nombre de destinations et de ports. Ce qui nécessitait auparavant une logique d'analyse personnalisée et des bibliothèques IP sur mesure peut désormais être exprimé directement en SQL à l'aide d'opérations IP et CIDR natives.

Pas d'UDF. Pas de regex. Pas de gymnastique sur les entiers. Le code se lit exactement comme la question que se pose l'analyste.

Les fonctions

La version GA fournit la boîte à outils complète nécessaire pour analyser, normaliser, inspecter et joindre des données IP :

Inclusion et jointures

• ip_cidr_contains(cidr, needle) - teste si une adresse IP ou un autre bloc CIDR se trouve dans un bloc CIDR. C'est le prédicat unique derrière les jointures de blocs CIDR et le filtrage à haut volume, et la fonction sur laquelle se concentre tout l'effort d'optimisation.

Analyse et canonisation

• ip_host(ip) - normalise une adresse IPv4 ou IPv6 sous sa forme standard (par exemple, réduit 2001:0db8:0000::1 en 2001:db8::1).
• ip_cidr(cidr) - génère la représentation canonique d'un bloc CIDR.

Inspection d'un CIDR

• ip_network(cidr) / ip_network_first(cidr) - renvoie la première adresse (réseau) d'un bloc CIDR.
• ip_network_last(cidr) - renvoie la dernière adresse d'un bloc CIDR.
• ip_prefix_length(cidr) - renvoie la longueur du préfixe (le nombre après le /).
• ip_version(ip_or_cidr) - renvoie 4 ou 6 afin de pouvoir aiguiller les adresses de protocoles mixtes sans traitement particulier

Conversion de représentation - pour les performances

• ip_as_binary(ip_or_cidr) - convertit une adresse ou un CIDR sous sa forme binaire canonique et compacte (4 octets pour l'IPv4, 16 pour l'IPv6). Le stockage et la jointure sur BINARY évitent les analyses répétées et réduisent l'espace de stockage.
• ip_as_string(ip_or_cidr) - reconvertit une représentation binaire en texte lisible par l'homme pour le reporting.

Variantes sécurisées pour les données désordonnées

• try_ip_host(ip), try_ip_cidr(cidr), try_ip_as_binary(ip_or_cidr), try_ip_as_string(ip_or_cidr) - identiques à leurs homologues, mais renvoient NULL au lieu de générer une erreur en cas d'entrée non valide. Indispensable lors de l'ingestion de journaux bruts où une fraction des enregistrements est toujours malformée, évitant ainsi qu'une seule ligne erronée ne fasse échouer une tâche d'un milliard de lignes.

Ces fonctions natives s'associent naturellement avec le reste de SQL, sont accessibles à tous les utilisateurs SQL sans configuration préalable, et sont comprises par l'optimiseur, ce qui rend ces performances exceptionnelles possibles.

Rearc, qui aide les entreprises à développer des plateformes GenAI, Data et Cloud, exploite les fonctions IP pour concevoir des cas d'usage d'observabilité réseau pour des clients à grande échelle.

Nous avons conçu un produit pour une grande institution financière qui traite régulièrement plus de 30 TB de données par jour, où les performances et la rentabilité sont cruciales. Grâce aux fonctions IP natives du moteur Databricks, nous avons pu analyser, valider et joindre des données IP directement en SQL, remplaçant ainsi une ancienne implémentation ad hoc par une solution bien plus élégante et facile à maintenir. Comme ces fonctions sont intégrées au moteur, nous y sommes parvenus sans sacrifier les performances requises par nos charges de travail à cette échelle. Elles nous ont permis de proposer des analyses réseau sur le lakehouse de manière plus simple et plus rapide." —Dara Kharabi, Practice Lead, AI & Data chez Rearc

Conçu pour l'échelle du pétaoctet : des secondes, pas des minutes

L'un des défis courants de l'analyse IP consiste à trouver une adresse unique ou un sous-CIDR au sein d'une plage beaucoup plus large, ce qui est essentiel pour détecter rapidement les menaces, enquêter sur les fraudes et surveiller l'activité réseau à grande échelle. Ce cas d'usage représente une jointure par plage (range join), une opération avec laquelle les moteurs ont historiquement du mal car les algorithmes de jointure standard reposent sur l'égalité. Le moteur de Databricks prend en charge une jointure par plage optimisée pour les adresses IP via ip_cidr_contains. 

ip_cidr_contains de Databricks surpasse les entrepôts de données traditionnels en termes de prix et de rapidité, quelle que soit la taille des tables de recherche (les « aiguilles ») et de blocs (les « bottes de foin »). Nous avons évalué les performances de ip_cidr_contains sur cinq scénarios représentatifs :

Les résultats montrent que les performances des fonctions IP de Databricks sont bien supérieures à celles de la concurrence, même à grande échelle. Une fois que le nombre de recherches dépasse 10 milliards d'adresses IP et que le nombre de blocs dépasse 1 million de CIDR, la vitesse des requêtes commence à stagner. 

L'écart de coût est tout aussi flagrant. Même lorsque les charges de travail augmentent, Databricks reste 2x à 6,4x moins cher.

Stanby a rapidement compris l'intérêt d'exécuter ses cas d'usage de surveillance réseau directement sur le lakehouse, plutôt que sur des systèmes externes :

"Les fonctions IP natives de Databricks nous permettent de travailler directement avec les données IP et CIDR en SQL. Nous ne dépendons plus d'une analyse de chaînes fragile ou d'une logique binaire manuelle. Le fait de pouvoir analyser, valider et joindre des données IP en tant qu'opérations SQL de premier ordre a rendu ce travail plus simple et plus facile à maintenir pour notre équipe. C'est une solution naturelle pour exécuter des analyses de réseau et de trafic aux côtés du reste de nos données sur le lakehouse."—Stanby, responsable de l'ingénierie des données

En fin de compte, ces fonctions IP hautement performantes permettent de créer toute une catégorie de charges de travail réseau directement sur le lakehouse.

Ce que cela permet de réaliser

Grâce à des fonctions IP natives et rapides, des charges de travail entières qui ne pouvaient pas y figurer auparavant sont transférées vers le lakehouse :

• Jointures d'enrichissement CIDR à grande échelle - attribuez à chaque événement des métadonnées GeoIP, ASN, de renseignement sur les menaces ou de propriété en quelques secondes, afin que les requêtes de détection et d'investigation en aval s'exécutent sur des données enrichies.
• Filtrage en temps réel à grand volume - « affichez-moi toutes les connexions de ce /16 suspect au cours des dernières 24 heures » devient une requête interactive plutôt qu'une tâche par lots.
• Analyses IPv4 et IPv6 unifiées - les tables de protocoles mixtes fonctionnent immédiatement, de sorte que le trafic moderne est analysé et non abandonné.
• Correspondance CIDR dans CIDR - vérifiez si un sous-réseau entier s'inscrit dans un autre, avec les mêmes performances que pour l'IP dans CIDR, pour l'analyse de la topologie réseau et des politiques.
• Accessibilité SQL de premier ordre - les analystes bénéficient du filtrage et des jointures IP avec du simple SQL, sans code procédural ni bibliothèques UDF requis.

Ces fonctions étant prises en charge de manière native sur le lakehouse, ces charges de travail réseau partagent une copie unique et gouvernée des données avec le reste de l'entreprise, sans qu'il soit nécessaire d'acquérir une licence, de sécuriser et de synchroniser un système spécialisé distinct.

Lancez-vous dès aujourd'hui

Les fonctions IP natives sont désormais disponibles en disponibilité générale sur Databricks Runtime LTS ou version ultérieure. 

Consultez la documentation de référence des fonctions IP pour obtenir la liste complète des fonctions et leurs signatures. Le flux de données réseau a toujours été l'un de vos ensembles de données les plus volumineux ; il peut désormais enfin résider là où se trouvent toutes vos autres analyses.

(Cet article de blog a été traduit à l'aide d'outils basés sur l'intelligence artificielle) Article original