- En el sector financiero, kdb+ fue una herramienta poderosa para el análisis de datos históricos de mercado y los cálculos en tiempo real, pero ahora han aparecido tecnologías alternativas lo bastante maduras para cada caso de uso
- Muchos usuarios no necesitan la velocidad máxima de kdb+, y las plataformas internas de los bancos tampoco logran exprimir por completo ese rendimiento, por lo que la ventaja de velocidad se ha vuelto menos decisiva
- En el análisis cuantitativo local, el ecosistema de Python domina de facto, y herramientas comunitarias gratuitas como DuckDB y Polars resultan más ventajosas en términos de aprendizaje y movilidad laboral
- El streaming en tiempo real y el cómputo distribuido siguen siendo fortalezas de kdb+, pero la dificultad de implementación y el creciente mindshare de Kafka, Flink y RisingWave dificultan su expansión
- Para que kdb+ sobreviva a largo plazo, necesita una ruta de uso gratuita, enfocarse en su producto principal, suavizar la curva de aprendizaje y ganar atractivo masivo para expandirse fuera del sector financiero
El papel que ha desempeñado kdb+ en el sector financiero
- kdb+ se ha utilizado en diversos sistemas y tareas analíticas del sector financiero
- Almacenamiento y análisis de datos históricos de mercado: casos como MS Horizon, Citi CloudKDB y UBS Krypton
- Análisis cuantitativo local: análisis de liquidez, análisis de PnL, análisis de rentabilidad por cliente
- Motor de cálculo de streaming en tiempo real: Streaming VWAP, Streaming TCA
- Cómputo distribuido: tareas como cálculo de margen de portafolios de acciones y análisis de riesgo, donde los datos se dividen, se procesan y luego se vuelven a unir
Datos históricos de mercado: los clientes actuales siguen, pero es difícil crecer con nuevos
- Muchos usuarios quieren consultar grandes volúmenes de datos para crear minute bars y realizar
asof joino análisis de series de tiempo más avanzados - Las alternativas competitivas se han ampliado hacia nuevas bases de datos como ClickHouse y QuestDB, proveedores cloud como BigQuery y Redshift, y Market Data as a Service
- Hay tres razones por las que la ventaja de velocidad de kdb+ ya no es tan decisiva como antes
- La mayoría de los usuarios no necesita la “velocidad” de kdb+
- La mayoría de las plataformas internas de los bancos no puede aprovechar por completo la velocidad de kdb+
- Los productos competidores ahora ya son lo suficientemente rápidos
- El benchmark de ClickBench se menciona como una comparación publicada de forma transparente
- kdb+ puede retener a los clientes actuales, pero las empresas de segundo nivel quieren opciones cloud-native u otras alternativas, así que no es fácil captar nuevos clientes
- Los principales clientes existentes tuvieron que invertir mucho para construir sus propias plataformas, y la plataforma kdb cloud todavía tiene aspectos que necesitan más pulido
Análisis cuantitativo local: el ecosistema de Python va adelante
- Las alternativas para el análisis cuantitativo local se organizan en su mayoría alrededor de Python
- Python + DuckDB
- Python + Polars
- Python + PyKX
- Python + dataframe, Modin, etc.
- En este terreno, Python ya ganó, y la pregunta restante se parece más a quién ofrece mejores herramientas complementarias de alto rendimiento
- DuckDB y Polars son fuertes contendientes porque son gratuitos
- Quienes empiezan en la universidad aprenden con herramientas gratuitas y luego es muy probable que no cambien
- Los quants que ya trabajan en una empresa también prefieren herramientas gratuitas con las que puedan seguir haciendo análisis similares en su próximo empleo
- Si dependes solo de kdb+, puedes perder una parte importante de tu stack de habilidades al cambiarte a una empresa que no use kdb+
- kdb+ es un producto de nicho que no ha logrado expandirse mucho fuera de finanzas, tiene un alto costo de entrada y además una sintaxis poco familiar
Streaming en tiempo real y cómputo distribuido: hay fortalezas, pero el ganador es incierto
- El streaming en tiempo real y el cómputo distribuido siempre fueron casos de uso menos populares para kdb+, y tampoco eran la razón principal para cerrar contratos
- La capacidad de combinar datos en tiempo real e históricos dentro de un mismo modelo se considera una de las mayores fortalezas de kdb+
- En implementaciones reales, a veces se necesitaba gente muy especializada o el sistema terminaba hecho un desastre
- Estos casos de fracaso también afectan negativamente la adopción de kdb+ en otras áreas dentro de la misma empresa
- Aún no está claro quién será el ganador final en este espacio, pero parece poco probable que sea kdb+
- Kafka ya consiguió despliegues a gran escala y mindshare, y también están surgiendo tecnologías como Flink y RisingWave
El open source y la estandarización absorben las ventajas de kdb+
- kdb+ es una gran tecnología, pero mientras se mantuvo sobresaliente en un nivel similar al de hace 15 años, el ecosistema a su alrededor cambió rápidamente
- Buenas empresas de open source tomaron ideas clave de kdb+
- Parquet/Iceberg se parece al formato en disco de kdb+ para almacenamiento columnar optimizado
- El formato en memoria de Apache Arrow se parece al formato columnar en memoria de kdb+
- Los conceptos de log/replay/ksql en Kafka también pueden verse, desde cierto ángulo, como algo parecido a tplog
- QuestDB, DuckDB y ClickHouse todos soportan asof join
- Los competidores no solo aprendieron las ventajas de kdb+, también las estandarizaron
- Snowflake, Dremio, Confluent y Databricks pasaron a soportar Apache Iceberg y Parquet
- QuestDB, DuckDB y Python pasaron a soportar Parquet de forma nativa
- Si los datos están en Parquet, múltiples herramientas pueden ejecutarse sobre los mismos datos
- La comparación ya no es KX contra un solo competidor, sino KX contra el conjunto de varios competidores
Lo que KX debe cambiar
- Se considera que KX está cambiando, pero no lo suficientemente rápido
- Los cambios necesarios se resumen en cuatro puntos
- Debe ofrecer una versión gratuita útil para varios casos de uso y una licencia razonable que también permita a clientes con poco presupuesto usarla fácilmente
- Debe enfocarse en hacer excelente su producto principal
- MongoDB e InfluxDB son casos comparativos donde solo una buena base de datos bastó para conseguir grandes contratos
- La solidez del producto principal importa más que productos periféricos como Delta o kdb.ai
- También debe reducir la empinada curva de aprendizaje de kdb+
- Si hace falta, eso incluiría incluso cambiar el lenguaje y la tecnología en sí
- Si no logra volverse más popular, podría entrar en una lenta decadencia
- También deberían considerarse cambios más amplios a nivel empresa, no solo en el producto tecnológico principal, sino incluyendo grandes costos e iniciativas como AI y un gasto fuerte en marketing
1 comentarios
Comentarios de Hacker News
También pondría a TimescaleDB como candidato. Al ser una extensión de PostgreSQL, mantiene tal cual elementos relacionados con SQL como replicación y autenticación
También soporta compresión en almacenamiento columnar y es muy rápido. Lo usé en algunas aplicaciones financieras, y una cantidad enorme de datos de ticks llegaba a la aplicación casi a la velocidad máxima que permitía el hardware
El soporte también es bueno y responden rápido en Slack. También usé kdb, pero tiene la gran desventaja de ser caro, y el lenguaje Q a veces está bien para divertirse como si fuera code golf, pero al final uno se da cuenta de que los caracteres sueltos no son tan expresivos como parece
Si el objetivo es el análisis cuantitativo improvisado, puede que kdb sea lo indicado si vas a pasarte el día tecleando cadenas cortas en un REPL buscando algo que dé dinero. Pero muchos trabajos en realidad se parecen más a tareas de cron, así que si vas a ejecutar consultas definidas según un horario, es mejor hacerlo en una forma legible para que la siguiente persona pueda entenderlo y mantenerlo
Escenarios como “mostrar sensores en un mapa y enseñar la gráfica de valores de cada sensor” se pueden resolver de forma rápida y limpia con una sola consulta
Eso sí, mis datos son algo patológicos, así que del lado de origen pueden cambiar la estructura a su antojo y yo tengo que aceptarlo. Si el precio de InfluxDB no estuviera completamente loco, sinceramente habría usado InfluxDB de inmediato
Una vez renuncié en dos semanas a un trabajo de trading cuantitativo donde usaban kdb+. Podía usarlo, pero la experiencia fue pésima
Podría quejarme de que el diseño del lenguaje o la depuración son terribles, pero lo más frustrante era la forma en que había o no había reglas de programación, y creo que ahí el lenguaje y la comunidad juegan un papel importante. La cultura de la empresa también influyó: cuando pregunté por qué la documentación era tan mala, me respondieron “con el tiempo nosotros lo entenderemos, y así evitamos que otros equipos usen nuestras ideas”
Todo el stack también estaba anticuado, y con una herramienta como Q era difícil hacer muchas cosas interesantes. Por ejemplo, copiaban datos desde qStudio a Excel para hacer gráficos
Lo único bueno era que no se habían subido a la moda de Docker/Kubernetes y desplegaban directamente en servidores. Tiene sentido que un quant pueda arreglar rápido algo en producción, pero también creo que un desarrollador web no debería esperar 10 minutos para ver el resultado de un cambio en producción
Tengo una teoría sobre por qué a los quants les gusta kdb. kdb es una buena arma. Sirve para ciertos fines, pero como construir con él es aburrido, cuesta llamarlo una herramienta. Lo que les gusta es que funciona de inmediato. Pero porque puedas clavar un clavo con un cuchillo no significa que ese sea el propósito del cuchillo
Siguiendo esa teoría, LISP, especialmente Racket, podría ser la mejor herramienta. No es el lenguaje más poderoso desde el inicio, pero permite crear muchas abstracciones con funciones que modifican el propio lenguaje. C++ y Python son excelentes lenguajes de programación para hacer buen software, y Python también es un arma bastante buena
Q puede dar la ilusión de ser el mejor lenguaje para explorar datos cuantitativos, pero eso se debe a que los quants no invierten lo suficiente en hacer buen software y usar buenas herramientas. Si aprendes bien un IDE de Python, puedes ser más productivo que cualquier programador de Q
Ni siquiera voy a empezar con el tema del rendimiento. Aunque el artículo enlazado no sea muy bueno, sí cubre esa parte
Hace tiempo Kdb+ me impresionó bastante. Incluso fui a un meetup en Chicago, donde consultas grandes se ejecutaban casi al instante y la sintaxis tipo APL parecía un conjuro mágico que solo conocía la gente de matemáticas. El vendedor decía que Kdb estaba tan optimizado que cabía en la caché L1 de los procesadores de ese momento
Diez años después, ahora hago lo mismo con Python, DuckDB y Jupyter sobre archivos Parquet. DuckDB no solo paraleliza, también vectoriza. No sé cómo saldría en benchmarks contra kdb+, pero en datasets grandes la capacidad de respuesta de DuckDB se siente al menos tan rápida como kdb+. Claro, kdb+ seguramente está mucho más optimizado, pero la diferencia es que DuckDB es gratis
Más bien parece mucho más probable que se haya frustrado por no entender el código y por eso renunció
Si fuera un desarrollador quant con experiencia y fuera un buen puesto, irse en dos semanas por condiciones de contrato habría sido un desastre para manejar la siguiente búsqueda laboral
Por ejemplo, basta con abrir un Jupyter Notebook y hacer esto
import pykx as kxdf = kx.q(“select from foo where bar”)plt.plot(df[“x”], df[“y”])Es una integración realmente fluida y potente. Puedes aprovechar lo mejor de ambos mundos, y podría terminar siendo la función que mantenga vivo este producto durante la próxima década
Una función atractiva de kdb+/Q que no se mencionó explícitamente aquí es su integración vertical. A menudo permite resolver con una sola tecnología casos de uso de toda una pila que normalmente requieren elegir y ensamblar varias tecnologías ya existentes
Gracias al lenguaje Q, las funciones básicas de serialización de datos y la comunicación entre procesos, un programador experimentado puede construir a medida exactamente el sistema que necesita en un solo lenguaje, y la base de código a veces cabe en unas pocas páginas de documentación en vez de cientos o miles
Si una organización ya decidió cubrir parte de ese rol con otro software, protocolos o formatos, las ventajas de la integración vertical en el flujo de desarrollo y el rendimiento general se reducen. Como kdb+ además es privativo y caro, se entiende que sea difícil justificar una adopción total en proyectos nuevos. Es una pena, porque la tecnología en sí es una joya
El producto de dashboards es difícil de usar y tiene bugs graves: incluso en dashboards de complejidad media el editor se cae con frecuencia. Q tiene tantas capacidades que escribir aplicaciones web con él sería realmente divertido, pero si quieres ofrecer algo a los usuarios, estás obligado a usar un editor de arrastrar y soltar
Si Shakti incluyera librerías para casos de uso empresariales comunes como balanceo de carga, permisos de usuario y SSO, creo que podría convertirse en un competidor real de Kx. Un programador experto en K probablemente podría hacerlo en una o dos semanas, pero muchas grandes empresas suelen exigir que esas funciones ya estén implementadas para autorizar la adopción de un producto
Estoy experimentando con la idea de construir una capa de integración así sobre tecnologías open source como Kafka, Flink, Postgres e Iceberg usando SQL, y añadir azúcar sintáctica que haga más cómodo el procesamiento de series temporales en SQL
https://github.com/DataSQRL/sqrl/
El objetivo es transformar SQL, crear un DAG de cómputo y luego dividir ese DAG con un optimizador basado en costos para desplegarlo sobre las tecnologías de datos subyacentes, de modo que el poder de kdb+ se ofrezca como un paquete que integra tecnologías open source y SQL
Deberían haber lanzado una versión gratuita para varios usos
Creo que ese fue el mayor obstáculo para que kdb+ fuera reconocido como una gran tecnología y producto, y para que creciera dentro de la comunidad de desarrolladores
Me volví fan de kdb+ tras usarlo mucho durante años en el sector financiero. En su diseño y simplicidad hay una elegancia que parece venir de una filosofía tipo Unix. Incluso después de dejar finanzas y de no volver a trabajar en una empresa que usara kdb+, muchas veces me dieron ganas de usar kdb+ en pequeños proyectos por aquí y por allá
Frustraba no poder usarlo más, ni poder mostrárselo a colegas como esa herramienta de nicho poco conocida y geekear sobre lo simple y eficiente que era para ciertas tareas y cálculos
Hace tiempo tuve que escribir código C++ que enviaba datos a kdb y también un decodificador de su protocolo en red, y claramente había un binario de kdb para pruebas para ambos casos
Solo necesitaba hacer pruebas. Me suena que Kx daba una licencia de desarrollo, aunque fue hace bastante tiempo
En general estoy de acuerdo con el contenido de este artículo. Si lo hiciera de nuevo, guardaría los datos en Parquet y accedería con Polars o DuckDB
Odiaba tanto q/kdb+ que terminé creando mi propio lenguaje para análisis de series temporales, pero desde hace años el ganador ya era Python
Construí una startup bastante exitosa con kdb+. Era la tecnología que conocía y me ayudó a crear un producto sólido rápidamente. Pero a medida que crecimos, tuvimos que reescribirlo con software open source para poder ampliar el equipo
En general estoy de acuerdo con las recomendaciones, pero creo que Kx debería liberar la plataforma como open source. Así podría atraer al tipo de desarrolladores que quieren aportar mejoras y herramientas al ecosistema
Kdb+ realmente se ve genial y lo estudié un poco por diversión junto con APL. En mi industria también parece que encajaría bastante bien para varios usos, pero el precio es absurdo
No puedo pagar algo como 100 mil dólares por CPU como pagan los bancos del sector financiero. En la práctica, eso significa ignorar a una capa enorme de clientes potenciales
Otros pueden aprender sus técnicas y hacer lo mismo adaptado a otros ámbitos y lenguajes
El artículo necesita algunas correcciones
clickhouse-localychdbAun así, todavía no he visto a ninguna ejecutar realmente la transición. Supongo que es una decisión grande si se consideran todas las integraciones que han surgido alrededor de KDB. Pero sin duda se siente como su heredero espiritual
Me pregunto si todavía hoy se puede aprender desarrollo con kdb+ desde cero y ganar muchísimo dinero con eso. Recuerdo haber visto hace algunos años una oferta de alrededor de 1 millón de dólares al año, y me sorprendió
Es una pena que kdb+ tenga una cláusula DeWitt, así que nadie puede compararlo en benchmarks con las otras bases de datos mencionadas en el artículo
También me pregunto si existe algún benchmark público hecho por terceros