IP-Funktionen sind allgemein verfügbar und bringen leistungsstarke Netzwerkanalysen ins Lakehouse

IP-Daten sind Warehousing-Daten

Jede Firewall, jeder Load Balancer, jedes VPN, jede CDN-Edge, jeder DNS-Resolver, jeder Kubernetes-Cluster und jeder Anwendungsserver gibt einen Datenstrom von Datensätzen aus, die auf einer einzigen Sache basieren: einer IP-Adresse. Für ein großes Unternehmen erzeugen diese Ströme zusammen täglich Dutzende Milliarden von Ereignissen und bilden die Grundlage für einige der wertvollsten Analysen, die ein Unternehmen durchführt, darunter Bedrohungserkennung, Betrugsuntersuchung und Netzwerkbeobachtbarkeit (Network Observability). In der Vergangenheit hat die Branche diese Anwendungsfälle der Netzwerkbeobachtbarkeit als spezialisierte Anwendungsfälle behandelt, die einen spezialisierten Stack erforderten, was zu Silos, fragmentierter Governance und Lock-in-Effekten führte.

Das ändert sich jetzt. Ab heute sind IP-Funktionen allgemein verfügbar (Generally Available). Mit dieser Einführung werden IP-Adressanalysen zu einem erstklassigen, hochleistungsfähigen SQL-Workload auf dem Lakehouse. Sicherheits-Teams können so ihre volumenstärksten IP-Daten zusammen mit den restlichen Analysen unter einem einzigen Governance-Modell parsen, anreichern und analysieren.

Warum Netzwerkanalysen früher mühsam waren

In der Vergangenheit waren IP-Adressen in SQL trügerisch schwer zu handhaben. Eine IPv4-Adresse sieht aus wie ein String, verhält sich aber wie eine 32-Bit-Ganzzahl (Integer); IPv6 hat 128 Bit. Ein CIDR-Block wie 10.0.0.0/8 ist überhaupt kein einzelner Wert – es ist ein Bereich von 16 Millionen Adressen. Die Frage „Liegt diese IP in diesem Subnetz?“ ist ein Problem der Bereichszugehörigkeit, das sich hinter einem Text verbirgt.

Ohne native Unterstützung waren Teams gezwungen, auf fehleranfällige Behelfslösungen auszuweichen – von denen jede Abstriche bei der Korrektheit, Leistung oder Wartbarkeit bedeutete:

Das Ergebnis war eine Lose-Lose-Situation. Analysten, die nur SQL beherrschen, blieben von der grundlegenden IP-Filterung ausgeschlossen, da diese prozeduralen Code erforderte. Data Engineers verschwendeten wertvolle Zeit mit der Wartung von UDF-Bibliotheken und CIDR-Erweiterungs-Jobs. Vor allem aber liefen kritische Workloads, wie das Anreichern von Milliarden von Ereignissen mit Bedrohungsdaten (Threat Intelligence) und Geo-IP-Tabellen, über eine Stunde, obwohl das Unternehmen Antworten in Minuten benötigte. Bei Datenmengen im Petabyte-Bereich entscheidet diese Verzögerung darüber, ob man einen laufenden Einbruch abwehrt oder erst im Nachhinein im Post-Mortem-Bericht davon liest.

Native IP-Funktionen, direkt in SQL integriert

Databricks führt ein vollständiges Set an integrierten IP-Funktionen ein, die Netzwerkdaten zu einem erstklassigen Bestandteil des Lakehouse machen. Sie verarbeiten IPv4 und IPv6 einheitlich, akzeptieren sowohl lesbare STRING als auch kompakte BINARY Darstellungen, verstehen die CIDR-Notation nativ und sind direkt in der Engine implementiert, sodass der Optimizer und Photon sie beschleunigen können.

Das folgende Beispiel reichert rohe Netzwerk-Flow-Logs mit Bedrohungsdaten (Threat Intelligence) an und identifiziert dann verdächtige Quellnetzwerke, die eine große Anzahl von Zielen und Ports scannen. Was früher benutzerdefinierte Parsing-Logik und spezielle IP-Bibliotheken erforderte, kann jetzt direkt in SQL mithilfe nativer IP- und CIDR-Operationen ausgedrückt werden.

Keine UDFs. Keine Regex. Keine Integer-Akrobatik. Es liest sich genau wie die Frage, die der Analyst eigentlich stellt.

Die Funktionen

Das GA-Release liefert das komplette Toolkit, das zum Parsen, Normalisieren, Überprüfen und Zusammenführen (Joinen) von IP-Daten erforderlich ist:

Zugehörigkeit und Joins

• ip_cidr_contains(cidr, needle) – prüft, ob eine IP-Adresse oder ein anderer CIDR-Block innerhalb eines CIDR-Blocks liegt. Dies ist das einzige Prädikat hinter CIDR-Block-Joins und hochvolumiger Filterung sowie die Funktion, auf die sich der gesamte Optimierungsaufwand konzentriert.

Parsing und Kanonisierung

• ip_host(ip) – normalisiert eine IPv4- oder IPv6-Adresse in ihre Standardform (z. B. wird 2001:0db8:0000::1 zu 2001:db8::1 verkürzt).
• ip_cidr(cidr) – erzeugt die kanonische Darstellung eines CIDR-Blocks.

Überprüfung eines CIDR-Blocks

• ip_network(cidr) / ip_network_first(cidr) – gibt die erste (Netzwerk-)Adresse eines CIDR-Blocks zurück.
• ip_network_last(cidr) – gibt die letzte Adresse eines CIDR-Blocks zurück.
• ip_prefix_length(cidr) – gibt die Präfixlänge zurück (die Zahl nach dem /).
• ip_version(ip_or_cidr) – gibt 4 oder 6 zurück, sodass bei Adressen mit gemischten Protokollen ohne Sonderfälle verzweigt werden kann.

Konvertierung der Darstellung – für mehr Leistung

• ip_as_binary(ip_or_cidr) – konvertiert eine Adresse oder ein CIDR in ihre kanonische, kompakte Binärform (4 Bytes für IPv4, 16 für IPv6). Das Speichern und Joinen auf BINARY vermeidet wiederholtes Parsen und reduziert den Speicherbedarf.
• ip_as_string(ip_or_cidr) – konvertiert eine Binärdarstellung für Berichte wieder in lesbaren Text zurück.

Sichere Varianten für unstrukturierte Daten

• try_ip_host(ip), try_ip_cidr(cidr), try_ip_as_binary(ip_or_cidr), try_ip_as_string(ip_or_cidr) – identisch mit ihren Gegenstücken, geben jedoch NULL zurück, anstatt bei ungültigen Eingaben einen Fehler auszugeben. Dies ist unerlässlich beim Erfassen von Rohprotokollen, bei denen ein kleiner Teil der Datensätze immer fehlerhaft ist, sodass eine einzige fehlerhafte Zeile niemals einen Job mit einer Milliarde Zeilen fehlschlagen lässt.

Diese nativen Funktionen fügen sich nahtlos in das restliche SQL ein, stehen jedem SQL-Benutzer ohne Einrichtung zur Verfügung und werden vom Optimizer verstanden – was die enorme Leistungssteigerung erst möglich macht.

Rearc, ein Unternehmen, das Betriebe bei der Entwicklung von GenAI-, Daten- und Cloud-Plattformen unterstützt, nutzt die IP-Funktionen, um Anwendungsfälle für die Netzwerkbeobachtbarkeit bei Großkunden zu realisieren.

Wir haben ein Produkt für ein großes Finanzunternehmen entwickelt, das regelmäßig mehr als 30 TB Daten pro Tag verarbeitet, wobei Performance und Kosteneffizienz von entscheidender Bedeutung sind. Mit den nativen IP-Funktionen der Databricks-Engine konnten wir IP-Daten direkt in SQL parsen, validieren und verknüpfen und so eine frühere Ad-hoc-Implementierung durch eine weitaus elegantere und wartungsfreundlichere Lösung ersetzen. Da die Funktionen direkt in die Engine integriert sind, konnten wir dies erreichen, ohne auf die Performance verzichten zu müssen, die unsere Workloads in dieser Größenordnung erfordern. Sie haben es uns ermöglicht, Netzwerk-Analysen im Lakehouse einfacher und schneller bereitzustellen." —Dara Kharabi, Practice Lead, AI & Data bei Rearc

Für den Petabyte-Bereich entwickelt: Sekunden statt Minuten

Eine häufige Herausforderung bei der IP-Analyse besteht darin, eine einzelne Adresse oder ein Sub-CIDR innerhalb eines viel größeren Bereichs zu finden. Dies ist entscheidend, um Bedrohungen schnell zu erkennen, Betrug zu untersuchen und Netzwerkaktivitäten im großen Stil zu überwachen. Dieser Anwendungsfall stellt einen Range-Join dar, mit dem Engines in der Vergangenheit oft Probleme hatten, da Standard-Join-Algorithmen auf Gleichheit basieren. Die Engine von Databricks unterstützt einen optimierten Range-Join für IP-Adressen über ip_cidr_contains. 

ip_cidr_contains von Databricks übertrifft herkömmliche Warehouses in Bezug auf Preis und Geschwindigkeit bei allen Größenordnungen von Probe- (d. h. „Nadel“-) und Block- (d. h. „Heuhaufen“-) Tabellen. Wir haben ip_cidr_contains in fünf repräsentativen Szenarien getestet:

Die Ergebnisse zeigen, dass die Performance der IP-Funktionen von Databricks deutlich stärker ist als die der Mitbewerber, selbst bei zunehmender Skalierung. Sobald die Anzahl der Probes 10 Mrd. IP-Adressen und die Anzahl der Blöcke 1 Mio. CIDRs überschreitet, flacht die Abfragegeschwindigkeit ab. 

Der Kostenunterschied ist ebenso eklatant. Selbst bei der Skalierung von Workloads bleibt Databricks 2-mal bis zu 6,4-mal günstiger.

Stanby erkannte schnell den Wert, seine Anwendungsfälle für die Netzwerküberwachung direkt im Lakehouse statt auf externen Systemen auszuführen:

"Mit den nativen IP-Funktionen von Databricks können wir direkt in SQL mit IP- und CIDR-Daten arbeiten. Wir sind nicht mehr auf fehleranfälliges String-Parsing oder manuelle bitweise Logik angewiesen. Die Möglichkeit, IP-Daten als First-Class-SQL-Operationen zu parsen, zu validieren und zu verknüpfen, hat diese Arbeit für unser Team einfacher und wartungsfreundlicher gemacht. Es eignet sich hervorragend, um Netzwerk- und Traffic-Analysen zusammen mit unseren restlichen Daten im Lakehouse auszuführen."—Stanby, Data Engineering Leader

Letztendlich ermöglichen diese hochperformanten IP-Funktionen den Aufbau einer ganz neuen Klasse von Netzwerk-Workloads direkt im Lakehouse.

Was dadurch ermöglicht wird

Mit schnellen, nativen IP-Funktionen verlagern sich ganze Workloads in das Lakehouse, die dort zuvor nicht ausgeführt werden konnten:

• CIDR-Enrichment-Joins im großen Stil - versehen Sie jedes Ereignis in Sekundenschnelle mit GeoIP-, ASN-, Bedrohungsdaten- (Threat Intelligence) oder Eigentums-Metadaten, sodass nachgelagerte Erkennungs- und Untersuchungsabfragen auf angereicherten Daten ausgeführt werden.
• Echtzeit-Filterung bei hohem Datenvolumen - „Zeige mir jede Verbindung von diesem verdächtigen /16-Netzwerk in den letzten 24 Stunden“ wird zu einer interaktiven Abfrage statt zu einem Batch-Job.
• Einheitliche IPv4- und IPv6-Analysen - Tabellen mit gemischten Protokollen funktionieren standardmäßig (out of the box), sodass moderner Datenverkehr analysiert und nicht verworfen wird.
• CIDR-in-CIDR-Abgleich - Überprüfen Sie für die Netzwerk-Topologie- und Richtlinienanalyse, ob ein gesamtes Subnetz in ein anderes fällt, und zwar mit der gleichen Performance wie bei IP-in-CIDR.
• Erstklassiger SQL-Zugriff - Analysten erhalten IP-Filterung und Joins mit einfachem SQL, ohne dass prozeduraler Code oder UDF-Bibliotheken erforderlich sind.

Da diese Funktionen nativ im Lakehouse unterstützt werden, teilen sich diese Netzwerk-Workloads eine einzige, kontrollierte (governed) Kopie der Daten mit dem Rest des Unternehmens – ohne dass ein separates, spezialisiertes System lizenziert, gesichert und synchronisiert werden muss.

Legen Sie noch heute los

Native IP-Funktionen sind ab sofort allgemein verfügbar (Generally Available) auf Databricks Runtime LTS oder höher. 

In der Referenzdokumentation für IP-Funktionen finden Sie die vollständige Liste der Funktionen und Signaturen. Der Netzwerk-Firehose war schon immer einer Ihrer größten Datensätze – jetzt kann er endlich dort angesiedelt werden, wo auch Ihre restlichen Analysen stattfinden.

(Dieser Blogbeitrag wurde mit KI-gestützten Tools übersetzt.) Originalbeitrag