Kategorie: KI-News

Ein chinesisches Startup bringt ein KI-Modell heraus, das mit US-Spitzenmodellen mithalten kann und viel günstiger ist. Moonshot AI plant nun den Börsengang. Der neue Motor läuft.

Kimi K3 mit 2,8 Billionen Parametern

Am 16. Juli 2026 stellte Moonshot Kimi K3 vor, ein offenes Modell mit 2,8 Billionen Parametern. Parameter sind Lernvariablen – je mehr, desto leistungsfähiger. Das Modell nutzt eine Mixture-of-Experts-Architektur. Es aktiviert nur die für eine Aufgabe relevanten Spezialmodule, das spart Rechenleistung. Der Kontextfenster umfasst eine Million Token, genug für einen ganzen Roman. In Programmier-Benchmarks liegt Kimi K3 gleichauf mit führenden US-Modellen.

Händler sprachen von einem neuen „DeepSeek-Moment“. Der taiwanesische Aktienindex fiel um über sechs Prozent, japanische Aktien um vier Prozent, der Nasdaq um 1,5 Prozent. Besonders traf es Konkurrenten: Z.ai verlor 30 Prozent an einem Tag, MiniMax 16 Prozent, Alibaba vier Prozent. Der Markt hat einen neuen ernstzunehmenden Spieler registriert.

Milliardenbewertung und Börsenpläne

Moonshot ist auch finanziell erfolgreich. Eine laufende Finanzierungsrunde bewertet das Unternehmen mit über 30 Milliarden Dollar – fast das Siebenfache der Bewertung vom Dezember 2025 (4,3 Milliarden). Der jährlich wiederkehrende Umsatz verdoppelte sich bis April 2026 auf 200 Millionen Dollar. Investoren zeigen Interesse, trotz strenger Regulierung ausländischen Kapitals in Chinas KI-Branche.

Der Börsengang in Hongkong ist für die nächsten sechs Monate geplant. Moonshot baut seine Unternehmensstruktur von einer VIE-Struktur auf ein Joint-Venture um, das den Vorgaben der chinesischen Wertpapieraufsicht entspricht. Das deutet auf einen konkreten IPO-Plan hin.

Auch andere chinesische KI-Startups wie DeepSeek erwägen Börsengänge. Ein Trend zeichnet sich ab: Chinesische KI-Labore suchen Kapital für den Wettlauf mit US-Giganten. Die Aktienkurse traditioneller Technologiewerte reagieren empfindlich auf KI-Nachrichten. Im Juni 2026 zog eine vergleichbare Welle den Bitcoin vorübergehend auf 62.000 Dollar nach unten.

Reaktionen an der Wall Street

An der Wall Street gibt es unterschiedliche Meinungen. JPMorgan rät, KI-Chipaktien im Kursrutsch zu kaufen. Morgan Stanley setzt auf Hyperscaler wie Amazon, Microsoft und Google. Beide Strategien zeigen, dass der Markt chinesische Konkurrenz noch nicht richtig einpreist.

Die KI-Landschaft wird globaler und dynamischer. US-Unternehmen galten lange als uneinholbar. Doch chinesische Startups wie Moonshot holen technisch auf – mit geringerer Kapitalausstattung. Offene Gewichtsmodelle verbreiten sich schnell, sie senken Eintrittsbarrieren und beschleunigen den Fortschritt. Gleichzeitig erschweren geopolitische Spannungen – Chip-Handelsbeschränkungen, Kapitalkontrollen – das Geschäft.

Chancen und Risiken des Börsengangs

Ein Börsengang in Hongkong wäre ein Meilenstein. Chinesische Anleger könnten direkt in heimische KI investieren; das Unternehmen bekäme frisches Kapital. Aber es gibt Risiken: Abhängigkeit von politischen Entscheidungen, Marktvolatilität, hohe Erwartungen. Der DeepSeek-Moment zeigte, wie schnell Euphorie in Panik umschlagen kann.

Klar ist: KI ist kein exklusiver Spielplatz mehr. Die Technologie wird erschwinglicher, leistungsfähiger, globaler. Moonshot AI zeigt, wie ein Startup mit cleverem Modell und schnellem Erfolg Aufmerksamkeit erregt. Der Börsengang ist der nächste Schritt – er wird zeigen, ob Moonshot das Tempo halten kann. Die Vorstellung davon, wer die KI-Zukunft gestaltet, muss sich ändern. Vielleicht steht die Zukunft der KI in Peking.

Quelle: finance.yahoo.com

In einem riesigen Supermarkt voller Künstlicher Intelligenzen steht ein teures GPT-Modell, ein günstiges Open-Source-Modell, spezialisierte Bildgeneratoren. Jedes verspricht die Lösung für dein Problem. Welches nimmst du? Wie verhinderst du, dass deine Abteilung am Monatsende eine sechsstellige Rechnung bezahlt, weil alle wild drauflos Tokens verbraucht haben? Unternehmen stehen heute vor dieser Herausforderung, wenn sie KI integrieren wollen. Sie müssen aus einem wachsenden Angebot an Modellen das richtige auswählen, die Kosten im Griff behalten und gleichzeitig Sicherheit und Compliance gewährleisten. Databricks, ein Unternehmen in San Francisco, spezialisiert auf Daten und KI, will diese Komplexität lösen.

Milliardenrunde untermauert den Plattform-Anspruch

Mit einer aktuellen Finanzierungsrunde – einer strategischen Runde zu einer Bewertung von 188 Milliarden US-Dollar – bekräftigt Databricks seinen Anspruch, die zentrale Plattform für Unternehmens-KI zu werden. Angeführt wird die Runde vom Bestandsinvestor Coatue, weitere neue und bestehende Investoren sollen hinzukommen. Der Abschluss wird für den Spätsommer 2026 erwartet, so das Unternehmen in einer Pressemitteilung. Das frische Kapital soll vor allem in drei Produktbereiche fließen: Unity AI Gateway, Genie und Lakebase. Diese Werkzeuge adressieren genau die Probleme, die viele Firmen plagen: Daten sind oft verstreut, nicht mit KI verbunden und schwer zu kontrollieren – einen Zustand, den Databricks als „Context Gap“ bezeichnet.

Ali Ghodsi, Mitgründer und CEO von Databricks, bringt die Strategie auf den Punkt: „Unternehmen bewegen sich vom Tokenmaxxing zum Valuemaxxing. Sie wollen nicht für jede Aufgabe die teuersten Tokens verbrennen, sondern das beste Ergebnis pro Dollar erzielen.“ Ein Token ist die kleinste Einheit, die ein KI-Modell verarbeitet – je mehr Tokens, desto höher die Kosten. Ghodsi meint, dass Firmen nicht ein einzelnes, teures KI-Modell für alles einsetzen, sondern je nach Aufgabe das passende – und kosteneffizienteste – Modell auswählen können. Diese Freiheit der Wahl ist der Kern von Databricks‘ Multi-AI-Ansatz. Das Unternehmen will seinen Kunden die Möglichkeit geben, aus einem Ökosystem von Modellen zu schöpfen, ohne die Kontrolle über Kosten, Sicherheit und Governance zu verlieren.

Ein Bild hilft, diese Vision zu verstehen: Ein Werkzeugkasten. Für einen Nagel brauchst du keinen Presslufthammer. Ebenso müssen Unternehmen die Wahl haben: Für eine einfache Textanalyse reicht ein leichtes Modell, für komplexe strategische Analysen vielleicht ein großes. Databricks hilft, diesen Werkzeugkasten zu verwalten – mit Unity AI Gateway als zentrale Schaltstelle. Unity AI Gateway ist eine Multi-AI-Governance-Lösung, die Unternehmen unterstützt, den Zugriff auf verschiedene KI-Modelle zu steuern, Kosten zu überwachen und Sicherheitsrichtlinien durchzusetzen. Es fungiert als Verkehrspolizist für KI-Anfragen: Es entscheidet, welches Modell für welche Anfrage verwendet wird, blockiert unautorisierte Zugriffe und protokolliert alle Aktivitäten für Compliance-Zwecke.

Genie, Lakebase und offene Infrastruktur

Ein weiteres Produkt, das von der Finanzierung profitiert, ist Genie. Databricks beschreibt Genie als KI-Co-Worker, der Geschäftsdaten in vertrauenswürdige Antworten und Aktionen umwandelt. Stell dir vor, du fragst: „Wie war unser Umsatz im dritten Quartal nach Region?“ und bekommst sofort eine präzise Antwort, ohne dass ein Data Scientist ein Dashboard bauen muss. Genie versteht natürliche Sprache und greift direkt auf die Daten im Lakehouse zu – der einheitlichen Datenarchitektur von Databricks. Es soll Business-Anwendern helfen, selbstständig Erkenntnisse zu gewinnen, ohne tiefe technische Kenntnisse zu benötigen. Das spart Zeit und entlastet die oft überlasteten Data-Teams.

Der dritte Schwerpunkt ist Lakebase, eine serverlose Postgres-Datenbank, optimiert für KI-Agenten. KI-Agenten sind autonome Programme, die Aufgaben erledigen, indem sie auf Daten zugreifen, diese analysieren und Aktionen auslösen. Lakebase bietet diesen Agenten einen schnellen, strukturierten und skalierbaren Speicher, der keine manuelle Serververwaltung erfordert. „Serverless“ bedeutet, dass sich Unternehmen nicht um die Infrastruktur kümmern müssen – die Datenbank skaliert automatisch mit der Nachfrage. Das ist wichtig für Echtzeitanwendungen, bei denen Agenten sofort auf aktuelle Daten zugreifen müssen, etwa in Kundenservice-Chatbots oder dynamischen Preisoptimierungen.

Hinter diesen Produkten steht die Databricks Data + AI Platform, die Datenverwaltung, Analytik, KI und Governance in einer Umgebung vereint. Das Unternehmen spricht von „Agent-ready Infrastructure“ – einer Infrastruktur, bereit für die nächste Welle von KI-Agenten. Laut Databricks nutzen bereits mehr als 20.000 Organisationen weltweit die Plattform, darunter Adidas, AT&T, Bayer, Block, Mastercard, Rivian, Unilever und 70 Prozent der Fortune 500. Diese Kundenbasis zeigt: Databricks ist kein Nischenanbieter mehr, sondern eine feste Größe im Enterprise-Bereich. Die aktuelle Finanzierungsrunde soll nicht nur die Produktentwicklung vorantreiben, sondern auch für Akquisitionen und vertiefte KI-Forschung genutzt werden.

Die 188-Milliarden-Bewertung eingeordnet

Die Bewertung von 188 Milliarden Dollar ist bemerkenswert. Sie spiegelt das Vertrauen der Investoren wider, dass Databricks die Plattform der Wahl für Enterprise-KI werden könnte – ähnlich wie Salesforce für CRM oder SAP für ERP. Der Unterschied: Databricks kombiniert Datenverwaltung, Analytics, KI und Governance in einem Haus. Das ist ein Alleinstellungsmerkmal in einer Zeit, in der Unternehmen unter dem sogenannten „AI Sprawl“ leiden – der zunehmenden Zersplitterung von KI-Tools, Modellen und Datenquellen. Viele Firmen haben heute Dutzende KI-Initiativen, die unkoordiniert nebeneinanderlaufen, ohne zentrale Steuerung. Databricks will hier Ordnung schaffen, indem es eine einheitliche Kontrollebene bietet.

Aus technischer Sicht ist der Multi-AI-Ansatz clever, denn er erkennt an, dass kein Modell alle Aufgaben perfekt beherrscht. Ein spezialisiertes Modell für Betrugserkennung kann günstiger und genauer sein als ein allgemeines Large Language Model. Doch die Verwaltung mehrerer Modelle ist komplex: Wer entscheidet, welches Modell wann verwendet wird? Wie werden die Kosten auf die Abteilungen verteilt? Wie stellt man sicher, dass keine sensiblen Daten an ein externes Modell gesendet werden? Unity AI Gateway soll diese Fragen beantworten, indem es eine Richtlinien-Engine bereitstellt, die auf Unternehmensregeln basiert. Es kann festlegen, dass nur interne Modelle für Personalthemen genutzt werden dürfen, während Marketing offene Modelle verwenden kann – jeweils mit Budgetlimits.

Was Unternehmen konkret davon haben

Was bedeutet das konkret für Unternehmen, die KI einführen wollen? Statt einen teuren Alleskönner zu kaufen, können sie auf einen Mix aus spezialisierten und generalistischen Modellen setzen – zu geringeren Gesamtkosten. Databricks positioniert sich als Betriebssystem-Kern dieser neuen Multi-AI-Welt. Die Plattform soll nicht nur die Auswahl der Modelle erleichtern, sondern auch deren Ergebnisse nachvollziehbar machen. Das ist entscheidend für Branchen wie Finanzen oder Gesundheitswesen, in denen jede KI-Entscheidung begründet werden muss. Genie liefert die Business-Schnittstelle, Lakebase übernimmt die Datenhaltung für Agenten und Unity AI Gateway die Kontrolle.

Die Runde ist noch nicht abgeschlossen, aber die Richtung ist klar: Databricks setzt auf eine offene, steuerbare und kosteneffiziente KI-Infrastruktur. Ob das gelingt, wird sich zeigen – die 188-Milliarden-Bewertung spricht eine deutliche Sprache. In einer Branche mit Hype und hektischen Investments setzt Databricks auf solide Governance und Business-Value. Das ist eine strategische Antwort auf ein reales Problem: KI ins Unternehmen zu bringen, ohne die Kontrolle zu verlieren. Die Plattform bietet einen Rahmen, der Unternehmen hilft, diesen Spagat zu meistern. Für KI-Interessierte lohnt es sich, die Entwicklung dieser Produkte zu verfolgen. Databricks‘ Ansatz könnte zur Blaupause für die nächste Generation von Enterprise-KI werden.

Quelle: databricks.com

Eine E-Mail-Anlage wird manchmal zu groß und muss komprimiert werden. Datenbanken haben das gleiche Problem bei großen Textfeldern. PostgreSQL steht seit den ersten Versionen mit einem 8-Kilobyte-Limit pro Zeile vor dieser Herausforderung. Mehr als zwei Jahrzehnte später plant das Kernteam eine grundlegende Änderung: Der Standard-Komprimierungsalgorithmus für TOAST (The Oversized-Attribute Storage Technique) wechselt von pglz auf LZ4. Das klingt technisch, hat aber direkte Auswirkungen auf die Performance deiner Datenbank.

Wie PostgreSQL Daten komprimiert

PostgreSQL verwendet ein einheitliches Komprimierungs-Framework für Heap-Tabellen, TOAST und Indizes. Bei Heap und TOAST läuft die Komprimierung automatisch und ist standardmäßig aktiviert – für alle variablen Datentypen wie TEXT, VARCHAR, BYTEA und JSONB. Bei Indizes ist die Komprimierung opportunistisch: Sie greift nur, wenn ein einzelner Schlüssel eine bestimmte Größenschwelle überschreitet. Das vereinfacht die Architektur. Müsste jedes Datenbankmodul eigenen Komprimierungs-Code schreiben, wäre die Wartung ein Albtraum. Stattdessen teilen sich alle Komponenten denselben Mechanismus.

Die Geschichte: Vom Workaround zur Standardlösung

Die erste Komprimierung in PostgreSQL kam mit Version 7.0 im Jahr 2000 – in einer ganz anderen Form. Damals gab es ein striktes Limit von 8 kB pro Zeile. Wer mehr Daten einfügen wollte, bekam einen Fehler. Die Entwickler versuchten zuerst, das Problem mit einem explizit komprimierten Datentyp namens lztext zu lösen. Das war ein Fortschritt, aber die 8-kB-Grenze blieb bestehen, und Anwender mussten sich bewusst für einen speziellen Typ entscheiden. Der nächste logische Schritt wäre gewesen, weitere komprimierte Typen einzuführen – so wie es viele kommerzielle Datenbanken taten. Das PostgreSQL-Kernteam wählte einen anderen Weg. In Diskussionen auf der pgsql-hackers-Mailingliste spalteten sie das Problem in zwei Teile: ein Datentyp-Problem und ein physisches Speicherproblem. Für Letzteres entwickelten sie TOAST in Version 7.1 – zusammen mit dem hauseigenen Algorithmus pglz.

pglz wurde von Jan Wieck geschrieben und basiert auf einer Idee von Adisak Pochanayon, die ursprünglich für die Spieleindustrie gedacht war – zur Komprimierung von Grafiken und Audiodaten. Die Prioritäten waren klar: Geschwindigkeit vor Kompressionsrate, minimaler Speicherverbrauch (ein 4096-Byte-Schiebefenster) und aggressives Frühabbruchverhalten bei inkompressiblen Daten. Außerdem brauchte PostgreSQL keine externen Abhängigkeiten. Damals – vor der Cloud-Ära – musste PostgreSQL auf jeder Plattform laufen, ohne auf Bibliotheken wie zlib angewiesen zu sein. pglz war ein pragmatischer, solider Kompromiss. Die Zeiten haben sich geändert.

Warum LZ4 den Platz von pglz einnimmt

LZ4 ist ein moderner Algorithmus, dessen Trade-offs zu heutiger Hardware passen. Seit PostgreSQL 14 kann man LZ4 systemweit (default_toast_compression = 'lz4') oder spaltenspezifisch (column TEXT COMPRESSION lz4) aktivieren. Jetzt wird es zum Standard. Der Vorteil liegt in der Geschwindigkeit. In einem Test mit 2000 INSERTs von je ~10 kB großen Werten brauchte LZ4 nur 6 Millisekunden, pglz dagegen 50 Millisekunden – etwa achtmal schneller. Die Dekomprimierung ist bei beiden ähnlich schnell, weil hier die I/O- und Speicherlatenz dominiert. Auch das Kompressionsverhältnis kann besser sein: LZ4s 64-kB-Schiebefenster findet mehr Back-References als pglz mit seinen 4 kB. Im Test ergab LZ4 111 Bytes gespeichert pro 10.400 Bytes Rohdaten (98,9 % Reduktion) gegenüber 186 Bytes bei pglz (98,2 % Reduktion). Der gesamte Heap-Speicher sank von 472 kB auf 312 kB. In seltenen Fällen komprimiert pglz noch besser. LZ4 hat ebenfalls einen effizienten Frühabbruch, um bei Zufallsdaten keine CPU zu verschwenden.

Diese Änderung folgt demselben Muster wie der ursprüngliche pglz-Rollout: zuerst als Option, dann als Standard. Das Kernteam hat die Algorithmen jahrelang parallel getestet und sich nun für den Wechsel entschieden.

Die Speicherstrategien im Detail

PostgreSQL kennt vier Speicherstrategien für Spalten. EXTENDED (großgeschrieben wie in der Dokumentation) ist der Standard für variable Typen. Hier darf PostgreSQL alle Werkzeuge nutzen: Speicherung unkomprimiert, komprimiert, im Heap oder in TOAST. PLAIN speichert die Spalte inline und unkomprimiert – der Default für fixe Typen wie INT, FLOAT, BOOL. EXTERNAL zwingt die Spalte in die TOAST-Tabelle, aber ohne Komprimierung. MAIN versucht zu komprimieren, aber die Spalte möglichst im Heap zu behalten. Die Entscheidungslogik ist ein Baum: Ist die gesamte Zeile kleiner als ca. 2 kB (toast_tuple_target, Standard 2040 Bytes), wird sie direkt in den Heap geschrieben. Überschreitet sie die Schwelle, sortiert PostgreSQL die EXTENDED-Spalten nach Größe und komprimiert die größte zuerst. Reicht das, um unter die Schwelle zu kommen, wird gestoppt. Sonst geht es zur nächsten Spalte. Wenn alle komprimiert sind und die Zeile immer noch zu groß ist, wandert die größte EXTENDED- oder EXTERNAL-Spalte in die TOAST-Tabelle, ersetzt durch einen 18-Byte-Zeiger. Falls immer noch zu groß, werden auch MAIN-Spalten nachkomprimiert, und als letzte Möglichkeit wandern auch diese out-of-line.

Für variable Typen verwendet PostgreSQL das Format varlena. Es ist ein selbstbeschreibendes Format mit einem Header, der die Länge und einen Komprimierungs-Bit enthält. Nur variable Typen werden komprimiert. Fixe Typen nie. In der Praxis bedeutet das: Große TEXT-Felder werden intelligent verpackt, während eine INTEGER-Spalte unangetastet bleibt.

Kompression in Indizes – ein Sonderfall

B-Tree-Indexseiten speichern Schlüssel als IndexTuple-Einträge: ein 8-Byte-Header gefolgt vom eigentlichen Wert. Für variable Typen wird dasselbe varlena-Format verwendet. PostgreSQL prüft, ob der Heap den Wert bereits komprimiert hat. Wenn ja, kommt er komprimiert in den Index. Ist er unkomprimiert und überschreitet 510 Bytes (TOAST_INDEX_TARGET, etwa 1/16 der 8-kB-Bufferpage), dann versucht der Index, ihn selbst zu komprimieren. Passt der komprimierte Wert, wird er gespeichert. Wenn nicht, schlägt der Schreibvorgang fehl. Das erklärt, warum ein String wie repeat('x', 5000) problemlos in einem B-Tree indiziert werden kann: LZ4 komprimiert die 5000 Wiederholungen auf etwa 38 Bytes – weit unter der Grenze von 2704 Bytes. Ein zufälliger String gleicher Länge dagegen bleibt fast so groß und kann nicht indiziert werden.

Was die Zukunft bringt

Die Umstellung von pglz auf LZ4 ist mehr als ein Algorithmen-Tausch. Sie zeigt, wie PostgreSQL seine Architektur weiterentwickelt: Der frühe Fehltritt mit dedizierten komprimierten Datentypen wurde korrigiert, und die zugrunde liegende pglz-Arbeit wurde in TOAST integriert. Jetzt geht man den gleichen Weg: erst testen, dann migrieren. Das Kernteam hat sich bewusst Zeit gelassen, um sicherzustellen, dass die Änderung der richtige Weg ist. Für Entwickler und Administratoren bedeutet das: Wer PostgreSQL 19 einsetzt, profitiert automatisch von schnelleren Schreibvorgängen, ohne etwas umstellen zu müssen. Die Datenbank wird effizienter mit großen Datenmengen umgehen, besonders bei vielen INSERTs. In seltenen Fällen liefert pglz ein besseres Kompressionsverhältnis. In den meisten Alltagsszenarien überwiegen die Vorteile von LZ4. Es ist ein weiterer Schritt in Richtung einer Datenbank, die stabil, zuverlässig und performant im modernen Cloud-Zeitalter ist.

Quelle: crunchydata.com

Du arbeitest täglich mit Daten. Importierst sie aus verschiedenen Quellen, bereinigst sie, definierst Kennzahlen und fütterst damit Dashboards und KI-Modelle. Immer wieder stolperst du über Inkonsistenzen: Ein BI-Report zeigt andere Umsatzzahlen als das modellierte System. Ein KI-Agent greift auf veraltete Kundenprofile zu. Das kostet Zeit und Vertrauen. Apache Spark 4.2 adressiert genau diese Probleme.

Das Entwicklerteam hat mit Version 4.2 eine Reihe von Neuerungen vorgestellt, die das Daten-Engine-Konzept deutlich erweitern. Statt nur ein Werkzeug für Batch-Verarbeitung zu sein, wird Spark zu einer zentralen Kommandozentrale für alle Daten- und KI-Workloads. Vier große Nutzen stehen im Vordergrund: Metric Views für einheitliche Geschäftskennzahlen, Spark Connect für die Anbindung aus beliebigen Umgebungen, native Vektor- und Geodatenfunktionen in SQL und die automatisierte Verarbeitung von Datenänderungen (Auto CDC). All das macht Spark zu einer leistungsstarken Basis für KI-Anwendungen – und zu einem Werkzeug, das auch Einsteiger schnell verstehen können. Betrachte Spark fortan als das zentrale Nervensystem deiner Datenarchitektur, in dem alle Signale ankommen, analysiert und in die richtige Bahn gelenkt werden.

Metric Views: Eine verbindliche Wahrheit

In vielen Unternehmen definiert jedes Team seine eigenen Metriken. Der Vertrieb berechnet den Umsatz anders als das Controlling. Das Dashboard zeigt plötzlich abweichende Werte – und keiner weiß, wer recht hat. Spark 4.2 führt sogenannte Metric Views ein, eine Art zentrales Nachschlagewerk für Geschäftskennzahlen. Du legst einmal fest, wie eine Metrik definiert ist – etwa der durchschnittliche Bestellwert oder die Kundenbindungsrate – und Spark sorgt dafür, dass diese Definition in SQL, BI-Tools und sogar in KI-Agenten konsistent angewendet wird.

Das ist besonders wichtig für nicht-additive Metriken, also Kennzahlen, die man nicht einfach aufsummieren kann, wie zum Beispiel Verhältnisse, eindeutige Zählungen oder Retentionsraten. Jedes Mal, wenn jemand die Formel neu schreibt, lauern Fehler. Mit Metric Views werden Dimensionen und Maße zu Objekten, die Spark versteht. Der Anwender fragt einfach nach den Metriken und erhält einheitliche Ergebnisse – egal, ob er nach Region, Produkt oder Zeitraum gruppiert. Für KI-Modelle bedeutet das: Der Agent berechnet den gleichen Wert wie das Dashboard. Das schafft Vertrauen und verhindert Widersprüche.

Spark Connect: Erreichbarkeit aus allen Welten

Bisher erforderte Spark eine vollständige Installation mit einer Java Virtual Machine (JVM) auf dem Client. Das war umständlich für Webdienste, Python-Skripte oder Mikroservices. Spark Connect trennt nun Client und Server durch ein Protokoll auf Basis von gRPC und Arrow. Der Client baut lediglich einen logischen Plan, schickt ihn an den Server, und dieser führt die Analyse aus. Zurück kommen die Ergebnisse als Arrow-Batches. Der Client benötigt kein eigenes Spark-Runtime und keine JVM.

Diese Trennung erleichtert die Einbettung von Spark in Notebooks, Web-Apps und KI-Agenten. Ein Chatbot kann beispielsweise eine komplexe Abfrage an Spark senden, ohne selbst rechenintensiv zu werden. In Spark 4.2 wurde die Kompatibilität zu Spark Classic weiter verbessert: RDD-API, DataFrame-Inputs und Debugging-Funktionen sind nun besser unterstützt. Auch die Python-Integration profitiert massiv. Arrow-optimierte Python-UDFs sind standardmäßig aktiviert, Pandas 3 wird unterstützt, und der Datenaustausch mit Tools wie Polars oder DuckDB erfolgt über die Arrow C Data Interface – ohne Kopieren oder Serialisieren. Das senkt die Hürden für Data Scientists, die Python bevorzugen, und macht Spark zu einem offenen Partner im gesamten Ökosystem.

AI-native Analytics in SQL

Ein entscheidender Schritt für KI-Workloads sind die neuen Vektor- und Ranking-Funktionen in Spark SQL. Mit Version 4.2 erhältst du integrierte Funktionen für Vektordistanz und -ähnlichkeit, Vektor-Normalisierung und vor allem den Befehl NEAREST BY. Das ist eine Top-K-Ranking-Operation, die ähnlich wie eine KNN-Abfrage funktioniert: Du übergibst einen Vektor (z. B. eine Embedding-Repräsentation eines Produkts) und Spark liefert die nächsten Nachbarn aus einer Tabelle. Keine zusätzliche Bibliothek mehr nötig – alles in SQL.

Hinzu kommen native Geodatentypen wie GEOMETRY und GEOGRAPHY sowie die dazugehörigen ST_-Funktionen. Bisher musstest du für räumliche Analysen oft auf externe Erweiterungen zurückgreifen. Jetzt kannst du Standortdaten direkt in Spark verarbeiten, inklusive Parquet-Unterstützung und SRID-Erhalt. Weitere SQL-Ergänzungen wie time_bucket für Zeitreihen, QUALIFY für das Filtern von Fensterergebnissen und max_by/min_by für Top-K-Aggregationen machen Spark SQL zu einer vollwertigen Analyseplattform. Das alles läuft im gleichen Engine-Kontext, sodass du keine Daten mehr zwischen verschiedenen Systemen verschieben musst.

Auto CDC und Declarative Pipelines: Datenänderungen sicher verarbeiten

Change Data Capture (CDC) ist die Technik, um Änderungen aus Datenbanken wie PostgreSQL oder MySQL in Echtzeit zu erfassen und in ein Data Warehouse zu spiegeln. Bisher war das mit Spark oft mühsam: Du musstest selbst Merge-Logik schreiben, Löschungen behandeln und mit verzögerten Ereignissen umgehen. Spark 4.2 vereinfacht das mit Auto CDC in den sogenannten Spark Declarative Pipelines (SDP). Du konfigurierst lediglich, wie die Änderungen auf eine Zieltabelle angewendet werden sollen – und Spark kümmert sich um den Rest.

Das ist besonders wichtig für SCD-Typ-1-Tabellen, also Tabellen, die immer den aktuellsten Stand eines Datensatzes speichern, etwa Kundenprofile oder Produktkataloge. Mit Auto CDC definierst du den Quell-Change-Feed und die Ziel-Tabelle, Spark wendet die Änderungen atomar an. Kein kompliziertes Zusammenkleben von Operationen mehr. Parallel dazu wurde die Data Source V2 (DSv2) weiterentwickelt: Sie unterstützt nun direkt Change Data Feeds über den neuen CHANGES-SQL-Befehl. Connectors können standardisiert Änderungsströme bereitstellen, und Spark filtert automatisch Duplikate, berechnet Netto-Änderungen und behandelt Updates konsistent. Für operative Daten ist das ein riesiger Fortschritt: deine Daten bleiben frisch und korrekt, ohne dass du ständig Merge-Jobs überwachen musst.

Real-Time Mode und DSv2: Frische Daten in Millisekunden

Der Real-Time Mode in Structured Streaming erlaubt seit einiger Zeit End-to-End-Latenzen im Millisekundenbereich. Bisher war diese Funktion nur in der Skala- oder Java-API verfügbar. Mit Spark 4.2 wird der Real-Time Mode auch für PySpark geöffnet – allerdings nur für zustandslose Streaming-Queries ohne Python-UDFs. Das ist ein erster Schritt, um die niedrige Latenz einer breiteren Entwicklergruppe zugänglich zu machen. Das Team arbeitet bereits an zustandsbehafteten Operationen für zukünftige Versionen.

Parallel dazu wird Data Source V2 zur einheitlichen Schnittstelle für alle Datenquellen. DSv2 erlaubt nun nicht nur Lesen und Schreiben, sondern auch Row-Level-DML, Schema-Evolution, Transaktionslogik und eben Change Data Capture. Der neue CHANGES-Befehl macht es möglich, Änderungsströme wie normale Tabellen in SQL abzufragen. Das ist enorm praktisch für Datenpipeline-Entwickler: Sie können CDC-Daten genauso behandeln wie statische Tabellen – und Spark optimiert die Abfrage automatisch.

Infrastruktur: Web-UI, Kubernetes und mehr

Neben den funktionalen Neuerungen warten auch Plattform-Verbesserungen. Das Spark Web-UI wurde auf Bootstrap 5 umgestellt, unterstützt Dark Mode und bietet bessere SQL-Pläne. Kubernetes kann nun heterogene Executor-Typen verwalten – nützlich, wenn du manche Nodes mit GPUs ausstatten möchtest. JDK 25 wird unterstützt, und die Stabilität beim Remote-Betrieb wurde verbessert. Diese unsichtbaren Verbesserungen machen Spark zu einem zuverlässigeren und benutzerfreundlicheren Werkzeug für Administratoren und Entwickler.

Fazit: Ein durchdachtes Update für die Daten- und KI-Welt

Apache Spark 4.2 ist kein radikaler Umbruch, sondern eine sorgfältige Evolution. Die vier Hauptnutzen – Metric Views, Spark Connect, native KI-Funktionen in SQL und Auto CDC – adressieren reale Schmerzpunkte in modernen Datenarchitekturen. Besonders im KI-Kontext ist entscheidend, dass Daten frisch, konsistent und vertrauenswürdig sind. Spark 4.2 liefert genau das: Es definiert eine gemeinsame Wahrheit für Metriken, ermöglicht den Zugriff aus beliebigen Systemen, bringt KI-spezifische Operationen direkt in die Engine und automatisiert das schwierige Feld der Datenänderungen.

Für dich als Datenexperte oder Einsteiger bedeutet das: Du kannst dich stärker auf die fachliche Analyse konzentrieren und weniger auf die technische Integration. Spark wird immer mehr zu dem zentralen Motor, der sowohl klassische Reporting-Workloads als auch moderne KI-Pipelines antreibt. Die Zukunft der Datenverarbeitung ist offen, skalierbar und integriert – und Spark 4.2 zeigt, wie das konkret aussehen kann.

Quelle: databricks.com

Skyroot Aerospace hat als erstes indisches Startup eine orbitalfähige Rakete erfolgreich gestartet. Die Vikram-1 hob am Samstag vom Satish-Dhawan-Weltraumbahnhof auf Sriharikota Island ab und erreichte eine Umlaufbahn in rund 450 Kilometern Höhe. Der Erstflug gelang auf Anhieb. Der Vorstandsvorsitzende der indischen Raumfahrtbehörde ISRO, V. Narayanan, zeigte sich überrascht. Pawan Kumar Chandana, CEO von Skyroot, sagte: „Ich hätte nie gedacht, dass das beim ersten Mal klappt.“

Ein geglückter Erststart ist selten

Der Start ist ungewöhnlich. SpaceX brauchte vier Fehlversuche, bis die Falcon 1 2008 den Orbit erreichte. Rocket Labs Electron scheiterte 2017 beim ersten Start. Blue Origin absolvierte vor dem Orbitalflug der New Glenn Dutzende suborbitale Flüge. Skyroot hatte nur einen suborbitalen Test mit der kleineren Vikram-S im Jahr 2022 – und wagte dann den Schritt in den Orbit.

Die Vikram-1 ist 22 Meter hoch und bringt bis zu 350 Kilogramm Nutzlast in eine niedrige Erdumlaufbahn – etwas mehr als Rocket Labs Electron. Sie besteht aus drei Feststoffstufen und einer Flüssigkeitsstufe mit einem 3D-gedruckten Triebwerk. Der Start dauerte nur wenige Minuten. Fast alles lief perfekt. Bei der Trennung der dritten von der vierten Stufe blieb diese kurz nah, aber die Mission war nicht beeinträchtigt. Die vierte Stufe zündete planmäßig. US-Militär-Trackingdaten bestätigen die erreichte Bahn.

Bescheidene Ziele, ausgefeilte Technik

Skyroot hatte bescheidene Ziele angegeben. Im Presskit hieß es, primäres Ziel sei ein erfolgreiches Abheben und das Freimachen des Startturms – etwa 100 Meter Höhe. „Die Mission war nur dafür ausgelegt, abzuheben und den Turm zu passieren“, sagte Pawan Goenka, Vorsitzender der Regulierungsbehörde IN-SPACe. „Aber wir sind 450 Kilometer hoch geflogen und haben alle Satelliten ausgesetzt. Die Mission war absolut perfekt.“ Der Erfolg beruht auf einer klaren Strategie: Fokus auf Feststoffraketen, niedrige Entwicklungskosten, kurze Entwicklungszeit. Die Zusammenarbeit mit ISRO half bei Testanlagen und Startrampe. Die Regierung unter Narendra Modi fördert private Raumfahrt stark. Indien will von rund fünf Starts pro Jahr auf 50 bis 2030 kommen – ein ambitioniertes Ziel, das durch diesen Start greifbarer wird.

Moderne Raumfahrtsysteme nutzen Algorithmen für Echtzeitdatenverarbeitung. Die Flugsteuerung der Vikram-1 verarbeitet Sensordaten – das ist maschinelles Lernen in der Praxis. Der 3D-gedruckte Motor wurde mit KI-gestützten Simulationen optimiert. Datenauswertung während des Flugs wäre ohne solche Tools nicht in dieser Geschwindigkeit möglich. Skyroot plant künftig eine tägliche Startfrequenz mit wiederverwendbaren Raketen – ein logistisches Problem, das nur Automatisierung und Planung lösen können. Der Raketenstart zeigt, wie solche Technologien unter extremen Bedingungen funktionieren: als Werkzeug, nicht als Schlagwort.

Bedeutung für den Kleinsatelliten-Markt

Für Indien und die Welt bedeutet das: Ein Privatunternehmen mit 160 Millionen Dollar Kapital und einem jungen Team kann einen orbitalen Flug durchführen. Der indische Markt für kleine Satelliten wächst – Kommunikation, Erdbeobachtung, Wissenschaft. Die Vikram-Familie soll künftig mit Boostern und einer kryogenen Oberstufe bis zu 900 Kilogramm in den Orbit bringen. Chandana träumt von wiederverwendbaren Flüssigtreibstoffraketen, die täglich starten. Nach diesem Start wirkt das nicht unrealistisch.

Für Technikinteressierte gibt es eine Erkenntnis: Hype ist nicht nötig, wenn die Fakten stimmen. Skyroot hat leise und zielstrebig gearbeitet. Keine großen Versprechungen, keine überzogenen Roadmaps – sondern das Ziel: eine funktionierende Rakete entwickeln und starten. Das ist Ingenieurskunst. KI-Technologie war dabei ein Helfer, kein Selbstzweck. Die Lehre aus diesem indischen Startup: Fokussiere dich auf das Machbare, nutze vorhandene Infrastruktur, verlasse dich auf ein motiviertes Team.

Skyroot plant einen zweiten Start noch in diesem Jahr. Premierminister Modi gratulierte persönlich. Die Welt schaut zu: Ein neuer Player im Markt für kleine Satellitenstarts hat sich etabliert. Das senkt Preise und erhöht Wettbewerb – gut für alle, die Satelliten ins All bringen wollen. Indien hat mit ISRO bereits staatliche Fähigkeiten, jetzt kommt die Dynamik der Privatwirtschaft dazu. Ein Modell für viele Länder.

Ausblick auf wiederverwendbare Raketen

Ob Skyroot den Traum von täglichen Starts verwirklicht, hängt von Kapital, Kunden und einer wiederverwendbaren Rakete ab. Das ist eine schwierige Aufgabe – selbst SpaceX brauchte Jahre. Aber ein Unternehmen, das beim ersten Orbitalstart alles richtig macht, darf ambitionierte Ziele verfolgen. In einer Zeit, in der Raumfahrt zum Wirtschaftsfaktor wird, ist dieser Start ein starkes Signal. Der Zugang zum All ist nicht mehr nur Regierungen vorbehalten, sondern auch Start-ups mit kluger Technologie.

Quelle: arstechnica.com