Die Zukunft von kdb+?

Anwendungsfälle

• Speicherung und Analyse historischer Marktdaten

  • Beispiel: MS Horizon, Citi CloudKDB, UBS Krypton

• Lokale Quant-Analyse

  • Beispiel: Liquiditätsanalyse, PnL-Analyse, kundenbezogene Profitabilitätsanalyse

• Echtzeit-Streaming-Berechnungs-Engine

  • Beispiel: Streaming-VWAP, Streaming-TCA

• Verteiltes Computing

  • Beispiel: Margin-Berechnung oder Risikoanalyse für Aktienportfolios

Alternativen

Historische Marktdaten – Alternativen zu kdb+

• Neue Datenbanktechnologien

  • Clickhouse, QuestDB

• Cloud-Anbieter

  • Bigquery, Redshift

• Marktdaten-Services

  • Die meisten Nutzer benötigen die „Geschwindigkeit“ von kdb+ nicht
  • Die meisten internen Plattformen von Banken schöpfen die Geschwindigkeit von kdb+ nicht vollständig aus
  • Auch Wettbewerber sind inzwischen schnell genug

Erwartetes Ergebnis

• kdb+ kann bestehende Kunden halten, wird aber keine Unternehmen der zweiten Reihe gewinnen, die Cloud-Native oder etwas anderes wollen

Lokale Quant-Analyse – Alternativen

• Python
  • DuckDB, Polars, PyKX, dataframe/modin usw.

Erwartetes Ergebnis

• DuckDB oder Polars werden gewinnen, weil sie kostenlos sind

Echtzeit-Streaming / Verteiltes Computing

• Die größte Stärke von kdb+ ist die Kombination von Streaming- und historischen Daten in einem einzigen Modell
• Allerdings braucht es erfahrene Leute, sonst wird es schnell unübersichtlich

Erwartetes Ergebnis

• kdb+ wird nicht gewinnen. Kafka hat bereits den Mindshare erobert, und flink/risingwave sind aufstrebende Stars

Zusammenfassung

• kdb+ ist eine erstaunliche Technologie, aber auf demselben Stand wie vor 15 Jahren

• Die besten Open-Source-Unternehmen haben die Ideen von kdb+ übernommen

  • Parquet/Iceberg sind das Plattenformat von kdb+
  • Apache Arrow ist das In-Memory-Format von kdb+
  • Auch das Log-/Replay-/ksql-Konzept von Kafka ist ähnlich
  • QuestDB, DuckDB, Clickhouse unterstützen alle asof-Joins

• Wettbewerber haben die besten Teile von kdb+ standardisiert

  • Beispiel: Snowflake, Dremio, Confluent, Databricks unterstützen alle Apache Iceberg/parquet
  • QuestDB, DuckDB und Python unterstützen alle parquet nativ

• KX muss die folgenden vier Dinge tun

  • Eine kostenlose Version anbieten und Lizenzen bereitstellen, die sich zu geringen Kosten nutzen lassen
  • Das Kernprodukt hervorragend machen
  • Die Lernkurve verringern
  • Beliebter werden

Zusammenfassung von GN⁺

• kdb+ ist weiterhin eine starke Technologie, aber die Wettbewerber holen schnell auf
• Kostenlose und Open-Source-Tools werden immer beliebter, daher ist ein Rückgang des Marktanteils von kdb+ wahrscheinlich
• Damit kdb+ beliebter wird, braucht es eine kostenlose Version, eine flachere Lernkurve und ein stärkeres Kernprodukt
• Produkte mit ähnlichen Funktionen sind unter anderem DuckDB, Polars und QuestDB

[GN⁺]

Hacker-News-Kommentare

• TimeScale ist eine Postgres-Erweiterung, sodass die SQL-Funktionalität unverändert genutzt werden kann

  • Es verfügt über Komprimierung mit spaltenorientierter Speicherung und arbeitet daher sehr schnell
  • Ich habe es in Finanzanwendungen eingesetzt, und es kann große Datenmengen schnell verarbeiten
  • Der Support auf Slack ist gut, und ich bin persönlich sehr zufrieden damit
  • kdb ist teuer, und die Sprache ist ineffizient

• Ein Fall, in dem jemand wegen der Erfahrung mit kdb+ nach zwei Wochen kündigte

  • Sprachdesign und Debugging sind unkomfortabel, und Coding-Regeln fehlen oder sind unzureichend
  • Auch die Unternehmenskultur ist problematisch; der Code ist schlecht dokumentiert
  • Der gesamte Stack ist veraltet, und man kopiert Daten aus qStudio nach Excel, um Diagramme zu erstellen
  • Positiv ist, dass nicht Docker und k8s verwendet werden und stattdessen direkt auf Servern deployt wird
  • kdb wird eher wie eine Waffe als wie ein Werkzeug eingesetzt

• Die vertikale Integration von kdb+ ist ein Vorteil

  • Mit einer einzigen Technologie können mehrere Rollen abgedeckt werden
  • Mit der Sprache Q, Datenserialisierung und IPC-Funktionen lassen sich maßgeschneiderte Systeme aufbauen
  • Allerdings ist kdb+ proprietär und teuer, weshalb es schwer in neue Projekte einzuführen ist

• Dass es keine kostenlose Version von kdb+ gibt, sorgt für geringe Bekanntheit

  • Ich habe kdb+ im Finanzbereich verwendet, und Design und Einfachheit ähneln der Unix-Philosophie
  • Auch nach dem Verlassen der Finanzbranche wollte ich kdb+ weiter nutzen, aber das Fehlen einer kostenlosen Version ist unpraktisch

• Ein Fall, in dem aus Abneigung gegen q/kdb+ eine eigene Sprache entwickelt wurde

  • Python wird derzeit am häufigsten verwendet

• Erfahrung, ein Startup mit kdb+ erfolgreich betrieben zu haben

  • Für die Skalierung des Teams musste es als FOSS neu geschrieben werden
  • Ich denke, kx sollte die Plattform auf Open Source umstellen

• kdb+ ist interessant, aber viel zu teuer

  • Viele potenzielle Kunden werden ignoriert

• Einige Korrekturen zu ClickHouse

  • ClickHouse ist seit 2016 Open Source und wird seit 2009 entwickelt
  • ClickHouse kann alle drei Anwendungsfälle abdecken
  • ClickHouse war 2019 die erste SQL-Datenbank, die ASOF JOIN eingeführt hat

• Python dominiert derzeit, aber technische Schulden erschweren den Wechsel auf eine neue Plattform

  • Neue Entwicklungsprojekte werden Python verwenden

• Frage, ob man als kdb+-Entwickler viel Geld verdienen kann

  • Vor einigen Jahren gab es Positionen mit einem Jahresgehalt von 1 Million US-Dollar