Die Zukunft von kdb+?

 (timestored.com)
1 Punkte von GN⁺ 2024-08-04 | 1 Kommentare | Auf WhatsApp teilen
  • Im Finanzsektor war kdb+ ein starkes Werkzeug für die Analyse historischer Marktdaten und Echtzeitberechnungen, doch inzwischen gibt es für jeden Einsatzbereich ausreichend ausgereifte Alternativtechnologien
  • Viele Nutzer brauchen die maximale Geschwindigkeit von kdb+ nicht, und auch bankinterne Plattformen schöpfen diese Leistung nicht vollständig aus, sodass der Geschwindigkeitsvorteil weniger entscheidend geworden ist
  • Für lokale Quant-Analysen dominiert faktisch das Python-Ökosystem, und kostenlose Community-Tools wie DuckDB und Polars sind beim Lernen und bei Jobwechseln im Vorteil
  • Echtzeit-Streaming und verteiltes Rechnen bleiben zwar Stärken von kdb+, doch die Komplexität des Aufbaus sowie der wachsende Mindshare von Kafka, Flink und RisingWave erschweren die Verbreitung
  • Um langfristig zu bestehen, braucht kdb+ einen kostenlosen Nutzungsweg, Fokus auf das Kernprodukt, eine flachere Lernkurve und genug Breitenwirkung, um über den Finanzsektor hinaus zu wachsen

Welche Rolle kdb+ im Finanzsektor gespielt hat

  • kdb+ wurde in verschiedenen Finanzsystemen und Analyseaufgaben eingesetzt
    • Speicherung und Analyse historischer Marktdaten: Beispiele sind MS Horizon, Citi CloudKDB und UBS Krypton
    • Lokale Quant-Analysen: Liquiditätsanalyse, PnL-Analyse, kundenbezogene Rentabilitätsanalyse
    • Echtzeit-Streaming-Engine für Berechnungen: Streaming VWAP, Streaming TCA
    • Verteiltes Rechnen: Aufgaben wie Margin-Berechnung für Aktienportfolios und Risikoanalyse, bei denen Daten aufgeteilt, berechnet und anschließend wieder zusammengeführt werden

Historische Marktdaten: Bestandskunden bleiben, aber Neukundengewinnung ist schwierig

  • Viele Nutzer möchten große Datenmengen abfragen, Minute Bars erzeugen, asof join nutzen oder noch fortgeschrittenere Zeitreihenanalysen durchführen
  • Die Konkurrenz umfasst inzwischen neue Datenbanken wie ClickHouse und QuestDB, Cloud-Anbieter wie BigQuery und Redshift sowie Market Data as a Service
  • Dass der Geschwindigkeitsvorteil von kdb+ nicht mehr so entscheidend ist wie früher, hat drei Gründe
    • Die meisten Nutzer brauchen die „Geschwindigkeit“ von kdb+ gar nicht
    • Die meisten bankinternen Plattformen können die Geschwindigkeit von kdb+ nicht vollständig ausschöpfen
    • Konkurrenzprodukte sind inzwischen schnell genug geworden
  • Die ClickBench-Benchmarks werden als transparent veröffentlichte Benchmarks erwähnt
  • kdb+ kann Bestandskunden halten, doch für Unternehmen der zweiten Reihe ist die Neuanschaffung schwierig, da sie Cloud-native oder andere Optionen bevorzugen
  • Große Bestandskunden mussten stark in den Aufbau eigener Plattformen investieren, und die kdb-cloud-Plattform hat weiterhin Bereiche, die noch ausgereift werden müssen

Lokale Quant-Analysen: Das Python-Ökosystem ist überlegen

  • Die Alternativen für lokale Quant-Analysen lassen sich meist Python-zentriert zusammenfassen
    • Python + DuckDB
    • Python + Polars
    • Python + PyKX
    • Python + DataFrame, Modin usw.
  • In diesem Bereich hat Python bereits gewonnen; die verbleibende Frage ist fast nur noch, wer die schnelleren Zusatzwerkzeuge liefert
  • DuckDB und Polars gelten vor allem deshalb als starke Kandidaten, weil sie kostenlos sind
    • Nutzer, die an der Universität anfangen, lernen mit kostenlosen Tools und wechseln später oft nicht mehr
    • Auch Quants im Unternehmen bevorzugen kostenlose Werkzeuge, mit denen sie ähnliche Analysen im nächsten Job weiterführen können
    • Wer sich nur auf kdb+ stützt, kann beim Wechsel in ein Unternehmen ohne kdb+ einen großen Teil seines Skillsets verlieren
  • kdb+ ist ein Nischenprodukt, das sich außerhalb des Finanzsektors nicht stark verbreitet hat, mit hohen Einstiegskosten und einer ungewohnten Syntax als Schwächen

Echtzeit-Streaming und verteiltes Rechnen: Stärken vorhanden, aber der Sieger ist unklar

  • Echtzeit-Streaming und verteiltes Rechnen waren bei kdb+ schon immer weniger populäre Einsatzbereiche und auch nicht der Hauptgrund für Vertragsabschlüsse
  • Die Fähigkeit, Echtzeitdaten und historische Daten in einem Modell zu verbinden, gilt als größte Stärke von kdb+
  • In realen Implementierungen waren oft sehr erfahrene Fachleute nötig, andernfalls geriet das System leicht in Unordnung
    • Solche Fehlschläge wirken sich auch negativ darauf aus, ob andere Abteilungen im Unternehmen kdb+ für weitere Zwecke übernehmen
  • Wer in diesem Bereich am Ende gewinnt, ist noch unklar, aber dass es kdb+ sein wird, erscheint unwahrscheinlich
  • Kafka hat bereits großflächige Deployments und Mindshare gewonnen, und Technologien wie Flink und RisingWave sind ebenfalls im Aufwind

Open Source und Standardisierung übernehmen die Stärken von kdb+

  • kdb+ ist eine hervorragende Technologie, doch während sie auf einem ähnlichen Niveau wie vor 15 Jahren hervorragend blieb, hat sich das umliegende Ökosystem schnell verändert
  • Gute Open-Source-Unternehmen haben die Kernideen von kdb+ übernommen
    • Parquet/Iceberg ähnelt dem kdb+-Disk-Format für optimierte spaltenorientierte Speicherung
    • Das In-Memory-Format von Apache Arrow ähnelt dem In-Memory-Spaltenformat von kdb+
    • Auch die Konzepte log/replay/ksql von Kafka lassen sich aus einer bestimmten Perspektive mit tplog vergleichen
    • QuestDB, DuckDB und ClickHouse unterstützen alle asof join
  • Die Konkurrenz hat die Stärken von kdb+ nicht nur gelernt, sondern auch standardisiert
    • Snowflake, Dremio, Confluent und Databricks unterstützen Apache Iceberg und Parquet
    • QuestDB, DuckDB und Python unterstützen Parquet nativ
  • Wenn Daten in Parquet vorliegen, können mehrere Tools auf denselben Daten arbeiten
  • Das Vergleichsbild ist nicht länger KX gegen einen einzelnen Wettbewerber, sondern KX gegen das gesamte Feld mehrerer Wettbewerber

Was KX ändern muss

  • KX verändert sich, aber nach Einschätzung mancher nicht schnell genug
  • Die nötigen Änderungen lassen sich in vier Punkte zusammenfassen
    • Es sollte eine kostenlose Version für verschiedene Einsatzzwecke geben sowie ein vernünftiges Lizenzmodell, das auch Kunden mit kleinem Budget leicht nutzen können
    • Das Unternehmen sollte sich darauf konzentrieren, das Kernprodukt exzellent zu machen
    • MongoDB und InfluxDB sind Gegenbeispiele, die zeigen, dass sich auch allein mit einer guten Datenbank große Verträge gewinnen lassen
    • Die Reife des Kernprodukts ist wichtiger als angrenzende Produkte wie Delta oder kdb.ai
  • Auch die steile Lernkurve von kdb+ muss abgeflacht werden
    • Wenn nötig, sogar durch Änderungen an Sprache und Technologie selbst
  • Wenn kdb+ nicht massentauglicher wird, könnte das in einen langsamen Niedergang münden
  • In Betracht zu ziehen sind nicht nur Änderungen am technischen Kernprodukt, sondern auch breitere Veränderungen auf Unternehmensebene, einschließlich großer Kosten und Initiativen wie AI und hohe Marketingausgaben

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2024-08-04
Meinungen auf Hacker News

  • TimescaleDB würde ich ebenfalls als Kandidaten aufnehmen. Da es eine PostgreSQL-Erweiterung ist, bleiben SQL-bezogene Aspekte wie Replikation und Authentifizierung unverändert erhalten.
    Es nutzt spaltenorientierte Speicherung, unterstützt Kompression und ist sehr schnell. Ich habe es in einigen Finanzanwendungen eingesetzt, und enorme Mengen an Tick-Daten kamen mit nahezu der maximalen Geschwindigkeit, die die Hardware zuließ, bis in die Anwendung hinein.
    Der Support ist ebenfalls gut, und auf Slack reagieren sie schnell. Ich habe auch kdb benutzt, aber der große Nachteil ist der hohe Preis; und die Q-Sprache macht zwar manchmal Spaß wie Code Golf, doch am Ende merkt man, dass einzelne Zeichen nicht so ausdrucksstark sind, wie man denkt.
    Wenn es um spontane Quant-Analysen geht, kann kdb richtig sein: den ganzen Tag kurze Zeichenketten in ein REPL tippen und nach etwas suchen, das Geld bringt. Viele Aufgaben ähneln aber eigentlich eher Cron-Jobs. Wenn man festgelegte Queries nach Zeitplan ausführt, ist es besser, sie so lesbar zu gestalten, dass die nächste Person sie verstehen und warten kann.

    • Eine weitere Stärke von TimescaleDB ist, dass es gut mit anderen PostgreSQL-Erweiterungen zusammenspielt. In Kombination mit PostGIS war meine Erfahrung sehr gut.
      Szenarien wie „Sensoren auf einer Karte anzeigen und zu jedem Sensor den Werteverlauf als Graph zeigen“ lassen sich mit einer einzigen Query schnell und sauber erledigen.
    • Wir verwenden bei der Arbeit TimescaleDB, und ich mag es ziemlich. Wenn die Datenstruktur gut modelliert ist, ist es wirklich angenehm.
      Meine Daten sind allerdings etwas krankhaft: Auf der Quellseite kann die Struktur beliebig geändert werden, und ich muss damit umgehen. Wenn die Preise von InfluxDB nicht völlig verrückt wären, hätte ich ehrlich gesagt sofort InfluxDB genommen.

  • Ich habe einmal einen Quant-Trading-Job mit kdb+ nach zwei Wochen gekündigt. Ich konnte es benutzen, aber die Erfahrung war furchtbar.
    Man könnte sich darüber beschweren, dass Sprachdesign oder Debugging schrecklich sind, aber am frustrierendsten war für mich, wie Coding-Regeln existierten oder eben nicht existierten; dabei spielen die Sprache und die Community meiner Meinung nach eine große Rolle. Die Unternehmenskultur trug ebenfalls dazu bei: Als ich fragte, warum die Dokumentation so miserabel sei, bekam ich die Antwort: „Mit der Zeit verstehen wir es, und so können andere Teams unsere Ideen nicht nutzen.“
    Der gesamte Stack war ebenfalls veraltet, und mit Werkzeugen wie Q war es schwer, viele interessante Dinge zu tun. Zum Beispiel haben wir Daten aus qStudio nach Excel kopiert, um Diagramme zu erstellen.
    Das einzig Gute war, dass sie den Docker/Kubernetes-Hype nicht mitgemacht und direkt auf Server deployt haben. Dass Quants in der Produktion schnell etwas korrigieren können müssen, ergibt Sinn; aber auch Web-App-Entwickler sollten nicht zehn Minuten warten müssen, um eine Änderung in Produktion zu sehen.
    Ich habe eine Theorie, warum Quants kdb mögen: kdb ist eine gute Waffe. Für manche Zwecke passt sie, aber sie ist langweilig herzustellen, daher würde ich sie schwerlich ein Werkzeug nennen. Man mag daran, dass es sofort funktioniert. Aber nur weil man mit einem Messer einen Nagel einschlagen kann, ist das nicht der Zweck eines Messers.
    Wenn man diese Theorie weiterführt, könnte LISP, besonders Racket, das beste Werkzeug sein. Es ist anfangs nicht die mächtigste Sprache, aber durch die Möglichkeit, die Sprache selbst zu verändern, kann man viele Abstraktionen bauen. C++ und Python sind hervorragende Programmiersprachen, mit denen man gute Software entwickeln kann, und Python ist auch eine ziemlich gute Waffe.
    Q kann die Illusion erzeugen, die beste Sprache zum Erkunden von Quant-Daten zu sein, aber das liegt daran, dass Quants nicht genug in gute Software und gute Werkzeuge investieren. Wer eine Python-IDE richtig beherrscht, kann produktiver sein als jeder Q-Programmierer.
    Über Performance fange ich gar nicht erst an. Auch wenn der verlinkte Artikel nicht besonders gut ist, behandelt er diesen Punkt.

    • Der Artikel nennt Python und DuckDB als mögliche Nachfolger.
      Früher war ich von Kdb+ ziemlich beeindruckt. Ich war auch bei einem Meetup in Chicago; große Queries liefen fast sofort, und die APL-artige Syntax wirkte wie ein magischer Zauberspruch, den nur Leute aus der Mathematik kennen. Der Sales-Mitarbeiter sagte, Kdb sei so optimiert, dass es in den L1-Cache der damaligen Prozessoren passe.
      Zehn Jahre später mache ich heute dasselbe mit Python, DuckDB und Jupyter auf Parquet-Dateien. DuckDB parallelisiert nicht nur, sondern vektorisiert auch. Ich weiß nicht, wie ein Benchmark gegen kdb+ ausfallen würde, aber bei großen Datasets fühlt sich DuckDB mindestens so reaktionsschnell an wie kdb+. Natürlich ist kdb+ wahrscheinlich deutlich stärker optimiert, aber der Unterschied ist: DuckDB ist kostenlos.
    • Wegen kdb keine zwei Wochen in einer Quant-Finance-Rolle durchzuhalten und anschließend zu sagen, man müsse alles in LISP neu schreiben, ist einer der HN-typischsten Rückfall-Kommentare, die ich bisher gesehen habe.
    • Ich glaube kaum, dass man nach zwei Wochen Q-Lernen qualifiziert ist, zu urteilen, dass jemand, der eine Python-IDE gut nutzt, produktiver ist als Quant-Entwickler mit Jahrzehnten Erfahrung.
      Viel wahrscheinlicher wirkt, dass er den Code nicht verstanden hat, frustriert war und gekündigt hat.
      Wenn er ein erfahrener Quant-Entwickler gewesen wäre und die Stelle gut war, wäre eine Kündigung nach zwei Wochen unter solchen Vertragsbedingungen eine Katastrophe fürs Management des nächsten Jobwechsels gewesen.
    • Die pykx-Integration schließt ziemlich viele Lücken. Dazu gehören Bereiche wie Charts, Machine Learning/statsmodels, HTML-Verarbeitung und Web Scraping.
      Zum Beispiel öffnet man ein Jupyter Notebook und macht Folgendes:
      import pykx as kx
      df = kx.q(“select from foo where bar”)
      plt.plot(df[“x”], df[“y”])
      Das ist eine wirklich reibungslose und leistungsfähige Integration. Man bekommt das Beste aus beiden Welten, und es könnte die Funktion sein, die dieses Produkt in den nächsten zehn Jahren am Leben hält.

  • Eine attraktive Eigenschaft von kdb+/Q, die hier nicht ausdrücklich behandelt wurde, ist die vertikale Integration. Use Cases für einen kompletten Stack, für die man normalerweise mehrere fertige Technologien auswählen und zusammenkleben müsste, lassen sich mit einer einzigen Technologie abdecken.
    Dank der Q-Sprache, der eingebauten Datenserialisierung und der Interprozesskommunikation können erfahrene Programmierer die benötigten Systeme in einer Sprache exakt maßschneidern, und die Codebasis passt oft in ein paar Seiten Dokumentation statt in Hunderte oder Tausende.
    Wenn eine Organisation bereits beschlossen hat, Teile dieser Rollen mit anderer Software, anderen Protokollen und Formaten abzudecken, schrumpfen die Vorteile der vertikalen Integration beim Entwicklungsfluss und der Gesamtperformance. Da kdb+ selbst proprietär und noch dazu teuer ist, ist es verständlich, dass sich eine umfassende Einführung in neuen Projekten schwer rechtfertigen lässt. Die Technologie selbst ist ein Juwel, wirklich schade.

    • Die Fähigkeit von kdb+/Q zur vertikalen Integration ist tatsächlich erstaunlich, aber es ist schwer zu verstehen, warum Kx sie nicht richtig nutzt. Die Kx Platform scheint größtenteils in Java geschrieben zu sein, und die Dokumentation der aus Q aufrufbaren APIs ist auch nicht besonders gut.
      Das Dashboard-Produkt ist schwer zu benutzen, und selbst bei Dashboards mittlerer Komplexität gibt es gravierende Bugs, bei denen der Editor häufig abstürzt. Q ist so funktionsreich, dass es wirklich Spaß machen müsste, Webanwendungen damit zu schreiben, aber wenn man Nutzern etwas bereitstellen will, muss man einen Drag-and-drop-Editor verwenden.
      Wenn Shakti Bibliotheken für gängige Enterprise-Use-Cases wie Load Balancing, Benutzerrechte und SSO enthielte, könnte es meiner Meinung nach ein echter Konkurrent für Kx werden. Ein erfahrener K-Programmierer könnte so etwas in ein bis zwei Wochen bauen, aber große Unternehmen erlauben die Einführung eines Produkts oft nur, wenn solche Funktionen bereits implementiert sind.
    • Dass man einen einzigen Code schreiben kann, der einen Use Case löst, ohne Message Queues, Stream-Prozessoren, Datenbanken, Query Engines usw. zusammenzubauen, ist ein großer Vorteil.
      Ich experimentiere mit der Idee, auf Open-Source-Technologien wie Kafka, Flink, Postgres und Iceberg eine solche Integrationsschicht in SQL zu bauen und syntaktischen Zucker darüberzulegen, der Zeitreihenverarbeitung in SQL bequemer macht.
      https://github.com/DataSQRL/sqrl/
      Ziel ist es, SQL zu transformieren, einen Berechnungs-DAG zu erstellen und diesen DAG dann mit einem kostenbasierten Optimierer aufzuteilen und auf die zugrunde liegenden Datentechnologien zu verteilen, um die Stärke von kdb+ als Paket aus Open-Source-Technologien und SQL bereitzustellen.

  • Es hätte eine kostenlose Version geben müssen, die man für verschiedene Zwecke nutzen kann.
    Meiner Meinung nach war das das größte Hindernis dafür, dass kdb+ als hervorragende Technologie und als Produkt anerkannt wird und in der Entwickler-Community wächst.
    Ich habe kdb+ über Jahre im Finanzsektor intensiv genutzt und bin ein Fan geworden. Im Design und in der Einfachheit liegt eine Eleganz, die in der Unix-Philosophie verwurzelt zu sein scheint. Auch nachdem ich den Finanzsektor verlassen hatte und nicht mehr bei einem Unternehmen arbeitete, das kdb+ nutzt, hatte ich oft den Drang, kdb+ für kleine Projekte hier und da einzusetzen.
    Es war frustrierend, es nicht mehr nutzen zu können und Kollegen dieses wenig bekannte Nischenwerkzeug nicht zeigen und bei bestimmten Aufgaben und Berechnungen darüber geek outen zu können, wie einfach und effizient es ist.

    • Gab es nicht so etwas wie eine kostenlose Version?
      Ich musste früher C++-Code schreiben, der Daten an kdb sendet, sowie einen Decoder für ihr Wire Protocol, und für beides gab es definitiv ein kdb-Binary zum Testen.
      Ich brauchte es nur zum Testen. Vielleicht hat Kx eine Entwicklerlizenz vergeben, aber das ist schon ziemlich lange her.
    • Ich frage mich, ob Open-Source-Versionen wie ngn/k oder Kerf nicht brauchbar waren.

  • Ich stimme dem Artikel insgesamt zu. Wenn man heute neu anfängt, kann man die Daten in Parquet speichern und mit Polars oder DuckDB darauf zugreifen.
    Weil ich q/kdb+ so sehr gehasst habe, habe ich selbst eine Sprache für Zeitreihenanalyse gebaut, aber der Gewinner war schon seit mehreren Jahren Python.

  • Ich habe ein Startup aufgebaut, das mit kdb+ einigen Erfolg hatte. Es war eine Technologie, die ich kannte, und sie half dabei, schnell ein robustes Produkt zu bauen. Als wir jedoch größer wurden, mussten wir es zur Skalierung des Teams mit Open-Source-Software neu schreiben.
    Den Empfehlungen stimme ich weitgehend zu, aber ich denke, Kx sollte die Plattform als Open Source veröffentlichen. Dann könnten sie die Art von Entwicklern anziehen, die Verbesserungen und Tools zum Ökosystem beitragen wollen.

    • Ich würde gern wissen, welches Startup das war und auf welche Open-Source-Software ihr umgestiegen seid.

  • Kdb+ sieht wirklich cool aus, und ich habe es zusammen mit APL zum Spaß ein wenig gelernt. Auch in meiner Branche würde es für mehrere Zwecke ziemlich gut passen, aber der Preis ist absurd.
    Wir können keine Beträge wie 100.000 Dollar pro CPU zahlen, wie es Banken im Finanzsektor tun. Damit hat man faktisch eine riesige potenzielle Kundengruppe ignoriert.

    • Sie haben eine Nische gefunden, die diesen Preis für ein innovatives Produkt zahlen kann. Ich halte das für die richtige Entscheidung. Schließlich ist es kein Produkt, das von Anfang an alle Probleme der Welt lösen sollte.
      Andere können ihre Techniken lernen und dasselbe für andere Bereiche und Sprachen tun.

  • Zum Artikel sind ein paar Korrekturen nötig.

    1. ClickHouse ist keine neue Technologie. Es ist seit 2016 Open Source und wird seit 2009 entwickelt.
    2. ClickHouse kann alle drei Use Cases abdecken. Historische und Echtzeitdaten, verteilte und lokale Verarbeitung sind alle möglich. Siehe clickhouse-local und chdb.
    3. ClickHouse war 2019 die erste SQL-Datenbank, die ASOF JOIN im Hauptprodukt angeboten hat. kdb+ war früher dran, aber nicht SQL.
    • Ich betreibe eine Datenberatungsfirma, die stark auf ClickHouse fokussiert ist. Es gibt viel Interesse daran, KDB durch ClickHouse zu ersetzen. Ich habe wahrscheinlich etwa zehnmal mit Unternehmen gesprochen, die eine Migration prüfen.
      Allerdings hat bisher noch niemand die Migration tatsächlich umgesetzt. Wenn man die vielen Integrationen bedenkt, die aus KDB herausgewachsen sind, ist das offenbar eine große Entscheidung. Trotzdem fühlt es sich eindeutig wie ein geistiger Nachfolger an.
    • Punkt 3 ist etwas, das Leute, die Q und verwandte Tools für Finanzberechnungen nutzen, leicht übersehen. Es gab einen Grund, warum sie kdb+ gewählt haben, und dieser Grund war nicht die Datenbank. So habe ich auch den Kern des Artikels verstanden.

  • Ich frage mich, ob man heute noch von Grund auf lernen und mit kdb+-Entwicklung viel Geld verdienen kann. Ich erinnere mich, vor ein paar Jahren eine Ausschreibung mit etwa 1 Million Dollar pro Jahr gesehen zu haben, was mich überrascht hat.

  • Es ist schade, dass kdb+ eine DeWitt-Klausel hat, sodass es niemand mit den anderen im Artikel genannten Datenbanken benchmarken kann.
    Ich frage mich auch, ob es öffentliche Benchmarks von Dritten gibt.