L’avenir de kdb+ ?
(timestored.com)- Dans la finance, kdb+ a été un outil puissant pour l’analyse de données de marché historiques et les calculs en temps réel, mais des technologies de remplacement désormais suffisamment matures ont émergé pour chaque cas d’usage
- Beaucoup d’utilisateurs n’ont pas besoin de la vitesse maximale de kdb+, et les plateformes internes des banques n’en exploitent pas pleinement les performances, ce qui rend l’avantage en vitesse moins décisif
- Pour l’analyse quantitative en local, l’écosystème Python domine de fait, et des outils communautaires gratuits comme DuckDB et Polars sont plus avantageux en matière d’apprentissage et de mobilité professionnelle
- Le streaming en temps réel et le calcul distribué restent des points forts de kdb+, mais la difficulté de mise en œuvre ainsi que la diffusion de Kafka, Flink et RisingWave dans les esprits compliquent son expansion
- Pour survivre à long terme, kdb+ a besoin d’un parcours d’usage gratuit, d’une concentration sur son produit cœur, d’une réduction de la courbe d’apprentissage et d’une accessibilité plus large au-delà du secteur financier
Le rôle joué par kdb+ dans la finance
- kdb+ a été utilisé dans de nombreux systèmes et travaux d’analyse du secteur financier
- Stockage et analyse de données de marché historiques : des cas comme MS Horizon, Citi CloudKDB et UBS Krypton
- Analyse quantitative en local : analyse de liquidité, analyse du PnL, analyse de rentabilité par client
- Moteur de calcul de streaming en temps réel : Streaming VWAP, Streaming TCA
- Calcul distribué : tâches comme le calcul de marge de portefeuille actions et l’analyse des risques, où les données sont réparties, calculées puis réassemblées
Données de marché historiques : les clients existants restent, mais l’expansion vers de nouveaux clients est difficile
- Beaucoup d’utilisateurs veulent interroger de grands volumes de données pour produire des minute bars, faire des asof join et mener des analyses de séries temporelles plus avancées
- Les alternatives concurrentes se sont élargies à de nouvelles bases de données comme ClickHouse et QuestDB, à des fournisseurs cloud comme BigQuery et Redshift, ainsi qu’au Market Data as a Service
- Trois raisons expliquent pourquoi l’avantage de vitesse de kdb+ est moins décisif qu’auparavant
- La plupart des utilisateurs n’ont pas besoin de la « vitesse » de kdb+
- La plupart des plateformes internes des banques n’exploitent pas pleinement la vitesse de kdb+
- Les produits concurrents sont désormais suffisamment rapides
- Le benchmark ClickBench est cité comme un benchmark publié de manière transparente
- kdb+ peut conserver ses clients existants, mais les entreprises de second rang veulent du cloud native ou d’autres options, ce qui rend l’acquisition de nouveaux clients difficile
- Les grands clients historiques ont dû investir massivement dans la construction de leurs propres plateformes, et la plateforme kdb cloud a encore besoin d’être peaufinée
Analyse quantitative en local : l’écosystème Python a l’avantage
- Les alternatives pour l’analyse quantitative en local s’organisent principalement autour de Python
- Python + DuckDB
- Python + Polars
- Python + PyKX
- Python + dataframe, Modin, etc.
- Dans ce domaine, Python a déjà gagné, et la seule vraie question restante est de savoir qui fournira les meilleurs outils rapides en complément
- DuckDB et Polars sont bien placés surtout parce qu’ils sont gratuits
- Les utilisateurs qui commencent à l’université apprennent avec des outils gratuits et ont de fortes chances de ne pas en changer ensuite
- Les quants en entreprise préfèrent aussi des outils gratuits qui leur permettront de poursuivre des analyses similaires dans leur prochain poste
- Dépendre uniquement de kdb+ peut faire perdre une grande partie de son socle de compétences lors d’un changement vers une entreprise qui n’utilise pas kdb+
- kdb+ est un produit de niche qui ne s’est pas vraiment diffusé au-delà de la finance, avec des coûts d’entrée élevés et une syntaxe peu familière comme points faibles
Streaming en temps réel et calcul distribué : des points forts, mais un vainqueur encore incertain
- Le streaming en temps réel et le calcul distribué ont toujours été des usages moins populaires de kdb+ et n’ont pas été la principale raison de gagner des contrats
- La capacité à combiner données en temps réel et données historiques dans un seul modèle est citée comme le plus grand point fort de kdb+
- En pratique, la mise en place a parfois exigé des personnes très expérimentées, faute de quoi le système tournait mal
- Ces échecs ont aussi un impact négatif sur l’adoption de kdb+ pour d’autres usages dans d’autres divisions de l’entreprise
- Le vainqueur final dans ce domaine n’est pas encore clair, mais il semble peu probable que ce soit kdb+
- Kafka a déjà obtenu des déploiements à grande échelle et une forte mindshare, tandis que des technologies comme Flink et RisingWave montent en puissance
L’open source et la standardisation absorbent les atouts de kdb+
- kdb+ est une excellente technologie, mais alors qu’elle est restée remarquable à un niveau comparable à celui d’il y a 15 ans, l’écosystème autour a changé rapidement
- De bonnes entreprises open source ont repris les idées clés de kdb+
- Parquet/Iceberg ressemble au format disque de kdb+ pour le stockage colonnaire optimisé
- Le format en mémoire d’Apache Arrow ressemble au format colonnaire en mémoire de kdb+
- Les concepts de log/replay/ksql de Kafka peuvent aussi, sous un certain angle, rappeler tplog
- QuestDB, DuckDB et ClickHouse prennent tous en charge les asof join
- Les concurrents n’ont pas seulement appris des points forts de kdb+, ils les ont aussi standardisés
- Snowflake, Dremio, Confluent et Databricks prennent en charge Apache Iceberg et Parquet
- QuestDB, DuckDB et Python prennent en charge Parquet nativement
- Quand les données sont en Parquet, plusieurs outils peuvent travailler sur les mêmes données
- La comparaison n’est plus KX contre un concurrent unique, mais KX contre l’ensemble de plusieurs concurrents
Ce que KX doit changer
- KX évolue, mais pas assez vite selon cette analyse
- Les changements nécessaires se résument en quatre points
- Fournir une version gratuite utilisable pour plusieurs usages, ainsi qu’une licence raisonnable que des clients aux budgets modestes puissent adopter facilement
- Se concentrer sur l’excellence du produit cœur
- MongoDB et InfluxDB sont cités comme contre-exemples montrant que de gros contrats peuvent être remportés avec une bonne base de données seulement
- Le degré de finition du produit cœur compte davantage que des produits périphériques comme Delta ou kdb.ai
- Il faut aussi réduire la forte courbe d’apprentissage de kdb+
- Si nécessaire, cela peut aller jusqu’à modifier le langage et la technologie eux-mêmes
- À défaut de devenir plus grand public, kdb+ pourrait entrer dans un lent déclin
- Au-delà du produit technologique cœur, des changements plus larges à l’échelle de l’entreprise doivent aussi être envisagés, y compris des coûts et initiatives majeurs comme l’IA et de grandes dépenses marketing
1 commentaires
Avis de Hacker News
J’aimerais aussi ajouter TimescaleDB parmi les candidats. Comme c’est une extension PostgreSQL, les éléments liés à SQL comme la réplication et l’authentification restent tels quels
Le stockage en colonnes prend aussi en charge la compression et c’est très rapide. Je l’ai utilisé dans quelques applications financières, et d’énormes volumes de données de ticks arrivaient jusqu’à l’application quasiment à la vitesse maximale permise par le matériel
Le support est bon aussi, avec des réponses rapides sur Slack. J’ai aussi utilisé kdb, mais il a le gros inconvénient d’être cher, et le langage Q est parfois sympa pour s’amuser comme au code golf, mais on finit par se rendre compte que ces caractères uniques ne sont pas aussi expressifs qu’on l’imaginait
Si l’objectif est de faire de l’analyse quant ad hoc, kdb peut être le bon choix pour taper toute la journée de courtes chaînes dans un REPL à la recherche de quelque chose de rentable. Mais beaucoup de tâches ressemblent en réalité davantage à des jobs cron : si vous allez exécuter des requêtes définies selon un planning, mieux vaut les écrire sous une forme lisible, que la personne suivante pourra comprendre et maintenir
Un scénario comme « afficher des capteurs sur une carte et montrer le graphe des valeurs de chaque capteur » peut être traité de façon rapide et propre avec une seule requête
Cela dit, mes données sont un peu pathologiques : la source peut changer la structure comme elle veut, et je dois m’y adapter. Honnêtement, si les tarifs d’InfluxDB n’étaient pas complètement délirants, je pense que j’aurais directement utilisé InfluxDB
Il m’est arrivé de quitter au bout de deux semaines un poste de trading quant utilisant kdb+. Je pouvais l’utiliser, mais l’expérience était vraiment mauvaise
Je pourrais me plaindre de la conception du langage ou du débogage, qui sont horribles, mais le plus frustrant était la manière dont les règles de codage existaient ou non ; à mon avis, le langage et la communauté y jouent un grand rôle. La culture de l’entreprise y contribuait aussi : quand j’ai demandé pourquoi la documentation était aussi médiocre, on m’a répondu « avec le temps, nous, on comprend, et il faut faire comme ça pour que les autres équipes ne puissent pas utiliser nos idées »
Toute la stack était aussi vieillissante, et avec des outils comme Q, il était difficile de faire beaucoup de choses intéressantes. Par exemple, on copiait les données depuis qStudio vers Excel pour tracer des graphes
Le seul point positif, c’est qu’ils n’avaient pas acheté la mode Docker/Kubernetes et déployaient directement sur les serveurs. Le fait que les quants doivent pouvoir corriger rapidement en production a du sens, mais je pense que les développeurs d’apps web ne devraient pas non plus attendre 10 minutes pour voir le résultat d’une modification en production
J’ai une théorie sur la raison pour laquelle les quants aiment kdb. kdb est une bonne arme. Il convient à certains usages, mais il est difficile de le qualifier d’outil, parce qu’en fabriquer avec est pénible. Ce qu’ils aiment, c’est que ça marche tout de suite. Mais ce n’est pas parce qu’on peut enfoncer un clou avec un couteau que c’est le but d’un couteau
Si l’on poursuit cette théorie, LISP, en particulier Racket, pourrait être le meilleur outil. Ce n’est pas le langage le plus puissant dès le départ, mais sa capacité à modifier le langage lui-même permet de créer beaucoup d’abstractions. C++ et Python sont d’excellents langages de programmation avec lesquels on peut faire de bons logiciels, et Python est aussi une assez bonne arme
Q peut donner l’illusion d’être le meilleur langage pour explorer des données quant, mais c’est parce que les quants n’investissent pas suffisamment dans la création de bons logiciels et l’utilisation de bons outils. En apprenant correctement un IDE Python, on peut être plus productif que n’importe quel programmeur Q
Je ne vais même pas commencer à parler des performances. Même si l’article lié n’est pas terrible, il aborde ce point
À l’époque, Kdb+ m’avait fait forte impression. J’étais aussi allé à une rencontre à Chicago : les grosses requêtes s’exécutaient presque instantanément, et la syntaxe façon APL ressemblait à des incantations magiques que seuls les matheux comprenaient. Le commercial disait que Kdb était tellement optimisé qu’il tenait dans le cache L1 des processeurs de l’époque
Dix ans plus tard, je fais aujourd’hui la même chose avec Python, DuckDB et Jupyter au-dessus de fichiers Parquet. DuckDB ne fait pas seulement de la parallélisation, mais aussi de la vectorisation. Je ne sais pas ce que donnerait un benchmark face à kdb+, mais sur de grands jeux de données, la réactivité de DuckDB me paraît au moins aussi rapide que celle de kdb+. Bien sûr, kdb+ est sans doute beaucoup plus optimisé, mais la différence, c’est que DuckDB est gratuit
Il semble beaucoup plus probable que vous ayez été frustré de ne pas comprendre le code et que vous soyez parti
Si vous étiez un développeur quant expérimenté et que le poste était bon, démissionner au bout de deux semaines dans ce type de conditions contractuelles aurait été catastrophique pour gérer votre prochain changement de poste
Par exemple, il suffit d’ouvrir un Jupyter Notebook et de faire ceci
import pykx as kxdf = kx.q(“select from foo where bar”)plt.plot(df[“x”], df[“y”])C’est une intégration vraiment fluide et puissante. On obtient le meilleur des deux mondes, et cela pourrait être la fonctionnalité qui maintiendra ce produit en vie pendant les dix prochaines années
Une fonctionnalité séduisante de kdb+/Q qui n’est pas explicitement abordée ici est l’intégration verticale. Elle permet de traiter avec une seule technologie des cas d’usage couvrant toute une stack, là où il faudrait généralement assembler plusieurs technologies prêtes à l’emploi.
Grâce au langage Q, aux fonctionnalités de base de sérialisation des données et aux communications interprocessus, un programmeur expérimenté peut concevoir précisément le système nécessaire dans un seul langage, et la base de code tient souvent dans quelques pages de documentation plutôt que dans des centaines ou des milliers de pages.
Si une organisation a déjà décidé de confier une partie de ces rôles à d’autres logiciels, protocoles ou formats, les bénéfices de l’intégration verticale sur le flux de développement et les performances globales diminuent. kdb+ étant en plus propriétaire et coûteux, on comprend qu’il soit difficile de justifier son adoption complète dans un nouveau projet. La technologie elle-même est un joyau, c’est vraiment dommage.
Le produit de dashboard est difficile à utiliser, et il souffre de graves bugs où l’éditeur plante souvent, même sur des dashboards de complexité moyenne. Q est suffisamment riche en fonctionnalités pour qu’écrire des applications web avec soit vraiment amusant, mais pour fournir quelque chose aux utilisateurs, il faut impérativement passer par l’éditeur en glisser-déposer.
Si Shakti incluait des bibliothèques couvrant des cas d’usage d’entreprise courants comme l’équilibrage de charge, les permissions utilisateur ou le SSO, il pourrait devenir un concurrent sérieux de Kx. Un programmeur K expérimenté pourrait probablement les créer en une ou deux semaines, mais les grandes entreprises exigent souvent que ce type de fonctionnalités soit déjà implémenté avant d’autoriser l’adoption d’un produit.
J’expérimente l’idée de construire une couche d’intégration de ce type en SQL au-dessus de technologies open source comme Kafka, Flink, Postgres et Iceberg, avec un peu de sucre syntaxique pour rendre le traitement des séries temporelles plus confortable en SQL.
https://github.com/DataSQRL/sqrl/
L’objectif est de transformer le SQL, de créer un DAG de calcul, puis de découper ce DAG avec un optimiseur basé sur les coûts pour le déployer sur les technologies de données sous-jacentes, afin d’offrir la puissance de kdb+ sous forme d’un package intégrant technologies open source et SQL.
Ils auraient dû proposer une version gratuite utilisable pour de nombreux usages.
À mon avis, c’est ce qui a le plus freiné la reconnaissance de kdb+ comme excellente technologie et produit, ainsi que sa croissance dans la communauté des développeurs.
J’ai beaucoup utilisé kdb+ pendant des années dans la finance et j’en suis devenu fan. Sa conception et sa simplicité ont une élégance qui semble enracinée dans la philosophie Unix. Même après avoir quitté la finance et cessé de travailler dans une entreprise utilisant kdb+, j’ai souvent eu envie d’utiliser kdb+ pour de petits projets ici et là.
C’était frustrant de ne plus pouvoir m’en servir, ni montrer à mes collègues cet outil de niche peu connu en m’enthousiasmant sur sa simplicité et son efficacité pour certaines tâches et certains calculs.
Il y a longtemps, j’ai dû écrire du code C++ qui envoyait des données vers kdb, ainsi qu’un décodeur pour leur protocole filaire, et il y avait clairement un binaire kdb pour tester les deux.
Je n’avais besoin que de tests. Il me semble que Kx fournissait une licence de développement, mais cela remonte à assez loin.
Je suis globalement d’accord avec cet article. Si l’on repartait de zéro, on stockerait les données dans Parquet et on y accéderait avec Polars ou DuckDB.
Je détestais tellement q/kdb+ que j’ai créé mon propre langage pour l’analyse de séries temporelles, mais cela fait déjà plusieurs années que le gagnant est Python.
J’ai créé une startup qui a eu un certain succès avec kdb+. C’était une technologie que je connaissais, et elle nous a aidés à construire rapidement un produit robuste. Mais avec la montée en charge, nous avons dû le réécrire avec du logiciel open source pour pouvoir agrandir l’équipe.
Je suis globalement d’accord avec les recommandations, mais je pense que Kx devrait ouvrir sa plateforme en open source. Cela attirerait le type de développeurs qui voudraient contribuer des améliorations et des outils à l’écosystème.
Kdb+ a vraiment l’air superbe, et je l’ai un peu appris pour le plaisir, avec APL. Il me semble assez bien adapté à plusieurs usages dans mon secteur, mais son prix est absurde.
Nous ne pouvons pas payer quelque chose comme 100 000 dollars par CPU, comme le font les banques dans la finance. Ils ont donc, de fait, ignoré une énorme clientèle potentielle.
Les autres peuvent apprendre leurs techniques et faire la même chose pour d’autres domaines et d’autres langages.
Quelques corrections sont nécessaires à propos de l’article.
clickhouse-localetchdb.Cela dit, aucune n’a encore réellement effectué la migration. Vu les nombreuses intégrations qui se sont développées autour de KDB, c’est sans doute une décision lourde. Mais il est clair que ClickHouse donne l’impression d’être son héritier spirituel.
Je me demande si l’on peut encore apprendre le développement kdb+ à partir de zéro et gagner beaucoup d’argent. Je me souviens avoir vu il y a quelques années une offre autour de 1 million de dollars par an, ce qui m’avait stupéfié.
C’est dommage que kdb+ ait une clause DeWitt, empêchant quiconque de le benchmarker contre les autres bases de données citées dans l’article.
Je me demande aussi s’il existe des benchmarks publics réalisés par des tiers.