Notebooks auf isoliertem Compute
Python auf Ihren gesteuerten Daten, in einem Notebook, das in Sekunden startet, auf eigenem isoliertem Compute läuft und beim Schließen zerstört wird. Kein gemeinsam genutzter Kernel, keine Kopien auf Laptops.
Eigenes isoliertes Compute
Jede Notebook-Sitzung startet in einer isolierten microVM mit einem deklarierten Rahmen für CPU, Arbeitsspeicher und Storage — nie ein gemeinsam genutzter Kernel, und zerstört, sobald die Sitzung endet.
Gesteuerter Datenzugriff
Notebooks lesen über die Ontologie unter derselben Identität und Richtlinie wie jede andere Workload — niemand bekommt eine private Hintertür zum Lakehouse.
Reaktiv und reproduzierbar
Ändern Sie einen Wert, und alles Nachgelagerte läuft neu; Abhängigkeiten werden mit dem Notebook deklariert, sodass es sich für die nächste Person, die es öffnet, gleich verhält.
Ein Notebook ist der Ort, an dem ein Analyst oder Data Scientist tatsächlich arbeitet: etwas Python schreiben, die Daten ansehen, plotten, entscheiden, was zu tun ist. Heikel war immer, wo dieser Code läuft und was er erreichen kann. Hier läuft er innerhalb der Plattform, auf Compute, das niemand anderem gehört, auf Daten, die Sie ohnehin sehen dürfen — und er hinterlässt nichts.
Lesenswert, wenn Sie als Analyst, Data Scientist oder Engineer echten Code auf echten Daten brauchen, in einer Umgebung, die Ihr Sicherheitsteam freigeben kann.
Notebooks sind interaktive Python-Umgebungen, die innerhalb der Plattform auf pro Sitzung isoliertem Compute laufen, gesteuerte, ontologieverankerte Daten über dieselben Berechtigungen lesen wie jede andere Workload, mit reproduzierbaren Abhängigkeiten und ohne persistente Laufzeitumgebung, die kompromittiert werden könnte.
Jede Organisation, die Analytik ernst nimmt, landet bei Notebooks, und jedes Sicherheitsteam wird dabei unruhig: ein gemeinsam genutzter Jupyter-Server, der Zugangsdaten ansammelt, oder schlimmer, eine Kopie der Daten auf irgendeinem Laptop. Scrydons Notebooks schließen beide Lücken. Jede Sitzung erhält ihr eigenes isoliertes Compute mit einem deklarierten Rahmen für CPU, Arbeitsspeicher und Storage; die Laufzeitumgebung wird von der Plattform verwaltet und ist read-only; Daten werden über die Ontologie und dieselbe Zugriffsrichtlinie erreicht, die der Rest der Plattform durchsetzt; und wenn die Sitzung endet, wird die Umgebung zerstört. Notebooks sind reaktiv statt Zellen-der-Reihe-nach-ausführen: Ein geänderter Wert aktualisiert alles, was davon abhängt — und genau das macht ein Notebook zu etwas, das man einer Kollegin geben und dem man vertrauen kann.
Notebooks in der Scrydon-Plattform
Eine integrierte, souveräne Architektur. Hier fügt sich Notebooks ein — hervorgehoben im Kontext des gesamten Stacks, mit dem es zusammenarbeitet.
Das AI OS für Menschen und KI-Agenten
Ontologie- und Semantikschicht: ein zusammenhängendes Modell für Ihre Daten, Ihr Wissen und Ihre Prozesse
Das Beste aus Data Lakes, Data Warehouses und Suche vereint
KI-Agenten, Workflows und Automatisierungen, die über Ihre Systeme hinweg ausgeführt werden
Integrieren Sie über A2A, MCP, Legacy-Systeme und Datenquellen
Sichere Domänenföderation, vertrauenswürdiger Datenaustausch und Intelligenz über Grenzen hinweg
Souveräne Grundlagen
Notebooks im Detail
Analytik
Daten, die in Warehouses und Dashboards liegen, die niemand liest, sind Daten, die niemand nutzen kann. Die Analytik-Schicht ändert das — sie gibt den richtigen Menschen die richtigen Informationen, ohne dass sie danach fragen müssen. Jede Kennzahl ist in der Cognitive Enterprise-Ontologie verankert, sodass eine Umsatzzahl nie isoliert eintrifft. Daten im Kontext — nicht nur in Dashboards.
Entscheidungsträger erhalten einen Live-Blick auf das Unternehmen — Finanzleistung, operative Gesundheit, Beschaffungsstatus — ohne darauf zu warten, dass ein Datenteam einen Bericht erstellt.
- Interaktive Notebooks: Python- und SQL-Umgebungen mit vollem Zugriff auf Ihre Lakehouse-Daten — ganz ohne Datenbewegung.
- Visuelle Dashboards: Vorgefertigtes, stets aktuelles Reporting, das sich automatisch mit dem Geschäft aktualisiert — kein manuelles Refresh, keine veralteten Zahlen.
- Agent-native Analytik: KI-Agenten können Erkenntnisse autonom abfragen, zusammenfassen und danach handeln — und schließen so den Kreis zwischen Analyse und Aktion.
Cortex ist die Schnittstelle für natürliche Sprache, die menschliche Konversation mit den vollen Fähigkeiten des AI OS verbindet. Sprechen Sie mit Ihren Daten, lösen Sie komplexe Workflows aus und befragen Sie Ihren Knowledge Graph — alles in einfacher Sprache, ohne technische Hürde.
- Ontologie-bewusst: Versteht die Struktur Ihres Enterprise Knowledge Graph und ermöglicht so präzise, kontextsensitive Antworten.
- Workflow-Trigger: Beschreiben Sie, was geschehen soll, und Cortex leitet die Anfrage automatisch an die richtigen Human + AI Orchestrator-Prozesse weiter.
- Multimodale Eingabe: Akzeptiert Text, Dokumente und strukturierte Daten und stützt Antworten auf Ihre tatsächlichen Unternehmensdaten statt auf generisches LLM-Wissen.
- Audit-Trail: Jedes Gespräch wird protokolliert, ist zuordenbar und überprüfbar — und erfüllt damit die Compliance-Anforderungen regulierter Branchen.
Das Lakehouse ist das hochperformante Datenfundament, das die Cognitive Enterprise trägt. Es basiert auf StarRocks — einer blitzschnellen, vektorisierten MPP-Query-Engine, die Analytik im Sekundenbruchteil, Echtzeit-Updates und hohe Parallelität liefert — und fragt offene Apache Iceberg-Tabellen direkt ab. So vereint es die Flexibilität eines Data Lake mit der Geschwindigkeit eines Warehouse unter einem einzigen, souveränen Dach.
- Offene Iceberg-Tabellen: Fragen Sie Apache Iceberg und andere offene Tabellenformate direkt ab — Ihre Daten bleiben Ihre, ohne proprietäres Lock-in und ohne Datenbewegung.
- Blitzschnelles OLAP: Die vektorisierte Engine, der kostenbasierte Optimierer und die materialisierten Views von StarRocks ermöglichen Echtzeit-SQL — von Dashboards bis zum Schlussfolgern der Agenten — ohne Datenduplizierung.
- Integrierte Vector Search: Speichern und durchsuchen Sie Embeddings neben herkömmlichen Daten, wodurch das Lakehouse sofort bereit für KI-Workloads ist.
Was Notebooks hier leisten
Ein Notebook ist hier eine interaktive Python-Umgebung, die innerhalb der Plattform öffnet, direkt neben den Daten, statt auf einem Laptop oder einem gemeinsam genutzten Server irgendwo anders. Sie schreiben Code, fragen das Lakehouse über die Ontologie ab, plotten das Ergebnis und überlegen es sich anders — und weil das Notebook reaktiv ist, führt das Ändern eines Wertes alles neu aus, was davon abhängt, statt oben veraltete und unten frische Ausgaben zu hinterlassen. Die Umgebung wird vom Notebook selbst beschrieben: Die Abhängigkeiten, die es braucht, werden mit ihm deklariert, sodass die Kollegin, die es nächsten Monat öffnet, dieselbe Umgebung vorfindet statt eines Rätsels. Wenn ein Notebook etwas bewiesen hat, kann es zu einer geplanten Pipeline auf derselben Plattform befördert werden, statt von einem anderen Team in einer anderen Sprache neu geschrieben zu werden.
In der Plattform laufen — Das Notebook läuft neben den Daten, innerhalb Ihres Perimeters — nichts wird zur Analyse auf einen Laptop exportiert.
Jedes Mal sauber starten — Eine Sitzung startet ihr eigenes Compute mit deklarierten Abhängigkeiten, sodass es keine Drift gibt zwischen dem, was Sie ausgeführt haben, und dem, was eine Kollegin ausführt.
Auf Änderungen reagieren — Bearbeiten Sie eine Zelle, und jede abhängige Zelle aktualisiert sich, statt veralteten Zustand zu hinterlassen, über den die nächste Leserin stolpert.
Zur Pipeline heranwachsen — Ein Notebook, das etwas bewiesen hat, kann zu einer geplanten Pipeline befördert werden, statt von Grund auf neu geschrieben zu werden.
Warum Notebook-Governance ein Sicherheitsproblem ist
Fragen Sie ein Sicherheitsteam, was es beim Thema Analytik nachts wachhält, und Notebooks kommen schnell zur Sprache. Die übliche Konstruktion ist ein langlebiger Notebook-Server, den alle teilen: Er sammelt Pakete, Zugangsdaten und den Zustand anderer Leute an, und eine einzige Kompromittierung erreicht all das. Die Alternative, in die die meisten Organisationen abdriften, ist schlimmer — die Plattform ist mühsam, also exportiert jemand einen Auszug und analysiert ihn auf einem Laptop, und die Kopie, die niemand steuert, ist die, die das Gebäude verlässt.
Es gibt ein zweites, leiseres Problem. Ein Ergebnis, das nicht erneut ausgeführt werden kann, kann nicht überprüft werden, und eine Zahl, die nicht überprüft werden kann, sollte keine Entscheidung stützen, die jemand vor einem Vorstand oder einer Aufsichtsbehörde verteidigen muss. „Bei mir hat es funktioniert" ist kein Beleg.
Beide Probleme verschärfen sich in dem Moment, in dem ein KI-Agent eigenen Code schreibt und ausführt. Ab diesem Punkt ist Isolation kein Analystenkomfort mehr, sondern eine Kontrolle — dasselbe Argument, und dieselbe Nahtstelle, wie bei der Sandbox, in der Agenten laufen.
Gemeinsam genutzte Kernel sammeln an — Ein langlebiger Notebook-Server sammelt Zugangsdaten, Pakete und den Zustand anderer Leute; eine einzige Kompromittierung erreicht all das.
Das eigentliche Leck sind Laptops — Ist die Plattform mühsam, exportieren Analysten einen Auszug — die Kopie, die niemand steuert, ist die, die das Gebäude verlässt.
Nicht reproduzierbar heißt nicht prüfbar — Wenn ein Ergebnis nicht erneut ausgeführt werden kann, kann es nicht geprüft werden — und es sollte keine Entscheidung stützen, die verteidigt werden muss.
Agenten brauchen dieselbe Nahtstelle — Sobald ein KI-Agent Code ausführt, sind Isolation und Richtlinie kein Analystenkomfort mehr, sondern eine Kontrolle.
Isoliertes Compute, gesteuerte Daten, nichts bleibt zurück
Das Öffnen eines Notebooks startet eine eigene Sitzung: Der Zugriff wird geprüft, isoliertes Compute wird gestartet, das Notebook und seine deklarierten Abhängigkeiten werden geladen, und die Datenverbindung wird unter Ihrer Identität aufgebaut. Der Compute-Rahmen ist explizit — CPU, Arbeitsspeicher und temporärer Storage sind deklariert, die Laufzeitumgebung wird von der Plattform verwaltet und ist read-only, und die gesamte Umgebung wird zerstört, sobald die Sitzung endet. Es gibt keinen gemeinsam genutzten Kernel zwischen Nutzern und keinen langlebigen Host, den man härten müsste.
Start eines Notebooks: Zugriff geprüft, isoliertes Compute gestartet, Abhängigkeiten installiert, Daten verbunden. Das Compute-Profil wird benannt statt angenommen — und die Laufzeitumgebung ist read-only und wird von der Plattform verwaltet.
Daten werden über die Ontologie unter derselben Identität, Richtlinie und demselben Logging erreicht wie jede andere Workload — ein Notebook ist also nie ein privater Weg ins Lakehouse; Daten-Governance gilt hier genauso wie für Dashboards und Agenten. Und weil Abhängigkeiten aus dem Inneren des Perimeters kommen, startet dasselbe Notebook in einer souveränen Cloud, on-premises oder in einem air-gapped Netz — ohne externen Dienst, der aufgerufen werden müsste.
Isolation pro Sitzung — Jedes Notebook erhält seine eigene microVM mit einem expliziten Ressourcenprofil; die Laufzeitumgebung wird von der Plattform verwaltet und ist read-only.
Ein Zugriffsmodell — Daten werden über die Ontologie unter Ihrer Identität erreicht — dieselben Berechtigungen, dasselbe Logging und dieselbe DLP-Nahtstelle wie bei jeder anderen Workload.
Flüchtig per Konstruktion — Die Umgebung existiert für die Dauer der Sitzung. Es gibt keinen langlebigen Notebook-Host, den man härten, patchen oder kompromittieren müsste.
Souverän, überall — Dieselben Notebooks laufen in einer souveränen Cloud, on-premises oder in einem getrennten Netz — ohne externen Dienst, der aufgerufen werden müsste.
Häufig gestellte Fragen
Was ist ein souveränes Notebook?+
Wie ist jedes Notebook isoliert?+
Können Notebooks beliebige Daten im Lakehouse erreichen?+
Sind Ergebnisse reproduzierbar?+
Kann ein Notebook zu einer Produktions-Pipeline werden?+
Funktionieren Notebooks, wenn das Netz getrennt ist?+
Wie verhält sich das zu Cortex?+
Die Plattform entdecken
Verwandte Themen
Lieber schreiben? Senden Sie eine E-Mail an hello [at] scrydon.com und wir melden uns bei Ihnen.
Partner
