Jede Cloud-Abrechnung erzählt eine Geschichte, aber um sie zu verstehen, müssen oft Millionen von Zeilen von Dutzenden von Cloud- und KI-Anbietern in etwas übersetzt werden, mit dem ein CFO, ein Engineering-Leiter oder ein FinOps-Team tatsächlich arbeiten kann. Genau dieses Problem löst nOps. Die Plattform des Unternehmens verwaltet jährliche Cloud-Ausgaben von über 5 Milliarden US-Dollar für Hunderte von Kunden. Sie verwandelt unfertige Abrechnungs- und Nutzungsdaten in Echtzeit-Dashboards, auf denen Unternehmen genau sehen, wohin ihr Geld fließt – heruntergebrochen auf Abteilungen, Kostenstellen oder benutzerdefinierte Tags.
Kunden erwarten, dass diese Transparenz sofort gegeben ist. Wenn sich eine Empfehlung für eine Verpflichtung ändert, die Ausgaben in einem unerwarteten Konto sprunghaft ansteigen oder eine neue KI-Workload Kosten verursacht, müssen die Dashboards dies in Echtzeit widerspiegeln. nOps bietet anpassbare Dashboard-Ansichten, und die Daten dahinter müssen für die individuelle Konfiguration jedes Kunden aktuell und reaktionsfähig bleiben. Als Built on Databricks-Partner hat nOps kürzlich Apache Druid durch Lakehouse//RT ersetzt, um diese Echtzeitschicht zu betreiben und gleichzeitig die Infrastrukturkosten zu senken und die Architektur auf einer einzigen, verwalteten Plattform zu konsolidieren.
Aufbau einer Echtzeitschicht für die nächste Generation von Unternehmenskunden
Jahre lang lief die Echtzeit-Abfrageschicht hinter den Kunden-Dashboards von nOps auf Apache Druid. Das Unternehmen begann mit einer selbst gehosteten Bereitstellung und wechselte dann zu einem verwalteten Druid-Dienst. Als die Plattform jedoch wuchs und Unternehmenskunden immer komplexere Berichterstellungsanforderungen stellten, wurde die Lücke zwischen den Geschäftsanforderungen und dem, was Druid leisten konnte, immer größer.
„Wir konnten einfach nicht die Leistung erzielen, die wir brauchten“, sagte Jordan Stein, Director of Engineering bei nOps. „Und es war wirklich schwer, den Nutzen daraus zu ziehen.“ Die Herausforderung war nicht nur die Geschwindigkeit. nOps ermöglicht es Kunden, eigene Zuordnungen, Tags und Gruppierungen zu definieren, sodass das Dashboard von keinem Kunden wie das eines anderen aussieht. Die Abfragen, die diese Ansichten antreiben, können äußerst komplex sein – manche sind bis zu 30.000 Zeilen SQL lang und beinhalten String-Matching über Billionen von Zeilen hinweg. Als nOps größere Unternehmenskunden mit mehr Abteilungen, mehr Kostenstellen und detaillierteren Berichterstellungsanforderungen gewann, wurden die Abfragen länger und anspruchsvoller. Das waren die Kunden, die nOps am liebsten bedienen wollte, und die bestehende Echtzeitschicht hielt die Plattform zurück.
Das Team benötigte eine Plattform, die die volle Komplexität dieser Abfragen bewältigen konnte, ohne dass nOps seine Daten aus S3 verschieben musste. Da etwa 380 TB an Cloud-Infrastrukturdaten in S3 die Delta-Tabellen antreiben, bedeutete die Duplizierung in eine separate Serving-Schicht zusätzliche Kosten, Latenz und einen operativen Mehraufwand, den das Team vollständig beseitigen wollte.
Lakehouse//RT: Keine Datenverschiebung, sofortige Rollbacks
nOps nutzte bereits Databricks-Metrikansichten in der Produktion und betrieb seine Anwendungsdatenbank auf Lakebase, als Lakehouse//RT eingeführt wurde. Der Zeitpunkt passte perfekt zur Suche des Teams nach einer neuen Echtzeit-Engine. „Das war genau das Problem, das wir lösen wollten“, sagte Stein. „Von dem Moment an, als wir Zugriff erhielten, war klar, dass Lakehouse//RT ein direkter Ersatz für unsere Druid-Schicht ist.“
Die wichtigste Voraussetzung war die Vermeidung jeglicher Datenverschiebung. nOps verfügt über rund 380 TB an Daten in S3, und diese in eine separate Serving-Schicht zu duplizieren war teuer und operativ mühsam. Lakehouse//RT fragt dieselben Delta-Tabellen direkt ab – ohne Kopieren, ohne Aufnahme-Pipelines und ohne sekundären Speicher. „Es ist bekannt, dass es ein Albtraum und teuer ist, über 380 Terabyte an Daten auf verschiedene Plattformen zu verschieben“, sagte Stein. „Mit Lakehouse//RT waren dafür keinerlei Änderungen an den zugrunde liegenden Daten erforderlich.“
Die Migration ermöglichte zudem sofortige Rollbacks von Tabellenversionen. Bei Druid bedeutete das Rollback einer Tabellenversion das Einreichen eines neuen Aufnahmesubs und eine Wartezeit von bis zu drei Stunden. Da Lakehouse//RT direkt aus Delta-Tabellen liest, erfolgen Rollbacks sofort. „Das ist eine der wirkungsvollsten Änderungen für uns“, sagte Stein. „Die Daten, die der Kunde sieht, sind dieselbe Tabelle, in die wir gerade geschrieben haben. Wir müssen keinem Duplikat dieser Daten hinterherlaufen, das an einem anderen Ort liegt.“
Über sechsfache Kostensenkung und eine einheitliche Datenplattform
Die finanziellen Auswirkungen waren beträchtlich. Die bisherige Architektur von nOps basierte auf durchgehend aktiven Druid-Clustern. Mit der serverlosen Autoskalierung von Lakehouse//RT senkte das Team die Ausgaben für die Echtzeit-Infrastruktur auf etwa 16 % der vorherigen Kosten, was einer Kostenreduzierung um mehr das Sechsfache entspricht. Durch die Migration wurden zudem 40 TB an duplizierten Bereitstellungsdaten eliminiert, die außerhalb von S3 im sekundären Druid-Speicher gespeichert waren.
Über Dashboards hinaus leitet nOps auch seine internen KI-Agenten und die MCP-Architektur (Model Context Protocol) über Lakehouse//RT, was die Antwortzeiten und die Qualität des Chat-Erlebnisses für Kunden deutlich verbessert hat. „Es ist großartig, dass die zugrunde liegenden Daten auf dem Backend und das, was der Kunde auf dem Frontend sieht, identisch sind“, sagte Stein. „Es bringt enormen Wert, diese voneinander abhängigen Architekturen an einem Ort zusammenzuführen.“
Als Built on Databricks-Partner veranschaulicht die Erfahrung von nOps, warum sich Lakehouse//RT hervorragend für ISV-Partner eignet, die datenintensive Anwendungen entwickeln. Observability- und Cloud-Kostenmanagement-Plattformen verarbeiten massive Datenmengen, komplexe kundenspezifische Abfragen und erfordern Echtzeit-Reaktionsfähigkeit. Lakehouse//RT ermöglicht es ISVs, diese Workloads direkt aus dem Lakehouse bereitzustellen, ohne eine separate Echtzeit-Datenbank zu pflegen, wodurch sowohl die Infrastrukturkosten als auch die operative Komplexität sinken. Die enge Zusammenarbeit von nOps mit dem Databricks-Produktteam während der Beta-Phase hat die Migration zusätzlich beschleunigt. „Diese Art von Partnerschaft ist sehr wertvoll, wenn Teams neue Technologien vorantreiben und wertvolles Feedback geben können“, sagte Stein.
nOps hat seine verwaltete Echtzeit-Abfrageschicht von Apache Druid durch Databricks Lakehouse//RT mit der Reyden-Engine ersetzt. Lakehouse//RT fragt dieselben in S3 gespeicherten Delta-Tabellen direkt ab, wodurch eine separate Serving-Datenbank, Datenduplizierung und Aufnahme-Pipelines überflüssig werden.