¿El futuro de kdb+?

Casos de uso

• Almacenamiento y análisis de datos históricos de mercado

  • Ej.: MS Horizon, Citi CloudKDB, UBS Krypton

• Análisis cuantitativo local

  • Ej.: análisis de liquidez, análisis de PnL, análisis de rentabilidad por cliente

• Motor de cálculo de streaming en tiempo real

  • Ej.: VWAP en streaming, TCA en streaming

• Computación distribuida

  • Ej.: cálculo de margen o análisis de riesgo para portafolios de acciones

Alternativas

Datos históricos de mercado - alternativas a kdb+

• Nuevas tecnologías de bases de datos

  • Clickhouse, QuestDB

• Proveedores de nube

  • Bigquery, Redshift

• Servicios de datos de mercado

  • La mayoría de los usuarios no necesita la "velocidad" de kdb+
  • La mayoría de las plataformas internas de los bancos no aprovecha por completo la velocidad de kdb+
  • Los competidores ahora también son lo suficientemente rápidos

Resultado esperado

• kdb+ puede conservar a sus clientes actuales, pero no logrará captar a empresas de segundo nivel que quieran algo cloud-native o distinto

Análisis cuantitativo local - alternativas

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

Resultado esperado

• DuckDB o Polars ganarán, porque son gratis

Streaming en tiempo real / computación distribuida

• La mayor fortaleza de kdb+ es combinar datos de streaming e históricos en un solo modelo
• Pero se necesita gente con mucha experiencia; de lo contrario, todo se vuelve confuso

Resultado esperado

• kdb+ no va a ganar. Kafka ya se quedó con el mindshare, y flink/risingwave son las estrellas emergentes

Resumen

• kdb+ es una tecnología increíble, pero sigue al mismo nivel que hace 15 años

• Las mejores empresas de open source tomaron prestadas las ideas de kdb+

  • Parquet/Iceberg es el formato en disco de kdb+
  • Apache Arrow es el formato en memoria de kdb+
  • Los conceptos de log/replay/ksql de Kafka también son similares
  • QuestDB, DuckDB y Clickhouse todos soportan joins asof

• Los competidores estandarizaron las mejores partes de kdb+

  • Ej.: Snowflake, Dremio, Confluent y Databricks todos soportan Apache Iceberg/parquet
  • QuestDB, DuckDB y Python todos soportan parquet de forma nativa

• KX debe hacer estas cuatro cosas

  • Debe ofrecer una versión gratuita y licencias que puedan usarse a bajo costo
  • Debe hacer excelente su producto principal
  • Debe reducir la curva de aprendizaje
  • Debe volverse más popular

Resumen de GN⁺

• kdb+ sigue siendo una tecnología potente, pero los competidores la están alcanzando rápidamente
• Las herramientas gratuitas y de open source están ganando popularidad, por lo que es muy probable que la cuota de mercado de kdb+ disminuya
• Para que kdb+ gane más popularidad, necesita ofrecer una versión gratuita, suavizar la curva de aprendizaje y fortalecer su producto principal
• Productos con funciones similares incluyen DuckDB, Polars y QuestDB

[GN⁺]

Opiniones en Hacker News

• Timescale es una extensión de Postgres, por lo que se puede usar toda la funcionalidad de SQL

  • Tiene compresión con almacenamiento columnar, así que funciona muy rápido
  • Lo he usado en aplicaciones financieras y puede procesar grandes volúmenes de datos con rapidez
  • El soporte en Slack es bueno y, en lo personal, me ha dejado satisfecho
  • kdb es caro y su lenguaje es ineficiente

• Un caso de alguien que renunció después de 2 semanas por su experiencia usando kdb+

  • El diseño del lenguaje y la depuración son incómodos, y no hay reglas de codificación o son insuficientes
  • La cultura de la empresa también era un problema, y el código no estaba bien documentado
  • Todo el stack es anticuado, y usaban qStudio para copiar datos a Excel y hacer gráficas
  • Es positivo que desplieguen directamente en servidores sin usar Docker ni k8s
  • kdb se usa más como un arma que como una herramienta

• La integración vertical de kdb+ es una ventaja

  • Una sola tecnología puede cumplir varios roles
  • Con el lenguaje Q, la serialización de datos y las funciones de IPC, se pueden construir sistemas a medida
  • Sin embargo, como kdb+ es propietario y caro, es difícil adoptarlo en proyectos nuevos

• kdb+ tiene poco reconocimiento porque no existe una versión gratuita

  • Hay experiencia usándolo en el sector financiero, y su diseño y simplicidad se parecen a la filosofía Unix
  • Incluso después de dejar las finanzas, querían seguir usando kdb+, pero la falta de una versión gratuita resultaba incómoda

• Un caso de alguien que desarrolló su propio lenguaje porque odiaba q/kdb+

  • Python es el más usado actualmente

• Experiencia de haber operado con éxito una startup usando kdb+

  • Fue necesario reescribirlo como FOSS para poder escalar el equipo
  • Consideran que kx debería convertir la plataforma en open source

• kdb+ es interesante, pero su precio es demasiado alto

  • Está ignorando a muchos clientes potenciales

• Algunas correcciones sobre ClickHouse

  • ClickHouse es open source desde 2016 y se desarrolla desde 2009
  • ClickHouse puede cubrir los tres casos de uso
  • ClickHouse fue la primera base de datos SQL en introducir ASOF JOIN en 2019

• Python domina actualmente, pero la deuda técnica dificulta migrar a una plataforma nueva

  • Los nuevos proyectos de desarrollo usarán Python

• Pregunta sobre si se puede ganar mucho dinero como desarrollador de kdb+

  • Hace algunos años había puestos con salarios de 1 millón de dólares al año