Données haute fréquence

Volume de données et ingénierie

∞structurel

Revu le 4 juin 2026. En 2026 : un trait permanent du marché, pas un avantage qui s'érode.

Des téraoctets par jour et par marché. Les données haute fréquence sont énormes, irrégulièrement échelonnées dans le temps et impitoyables face au stockage naïf : l'ingénierie est la moitié de la bataille.

L'idée

Un instrument vers une place : brut contre stocké schéma annotéDG-FIREHOSE

Ce que montre ce schéma. Un seul instrument représente des dizaines de mégaoctets de flux par jour et une place entière des centaines de gigaoctets bruts, mais la compression colonnaire d'environ huit fois ramène cela à des dizaines de gigaoctets stockés, environ dix téraoctets par an. Le disque est donc trivialement bon marché. La vraie facture, c'est capturer le flux sans perte et payer la licence de données de marché de la place, qui écrasent le stockage de plusieurs ordres de grandeur.

Combien de données le trading haute fréquence génère-t-il vraiment ?

Reformulez les données haute fréquence : non plus un sujet de statistiques mais un sujet d'ingénierie, et le premier fait est l'échelle. Une barre quotidienne est une ligne par instrument et par jour ; un tape est une ligne par événement, et sur un instrument actif les événements arrivent des milliers de fois par seconde, en rafales (temps irrégulier). Le rapport de nombre de lignes entre un tape et une série de barres quotidiennes est de six à neuf ordres de grandeur. Comme ordre de grandeur en 2026 (à revérifier contre les statistiques publiées par la place), un flux de cotation top-of-book pour une action liquide dépasse confortablement le million de messages par jour ; le MBO en profondeur complète multiplie cela ; et les données d'options américaines consolidées (OPRA) sont le firehose canonique, mesuré en dizaines de millions de messages par seconde au pic et en téraoctets à deux chiffres par jour non compressés. La crypto ajoute du 24h/24 sans accalmie nocturne et des dizaines de places.

Elles ont grandi, et continuent de grandir, pour des raisons structurelles : des pas de cotation plus fins, plus de types d'ordres, plus de places (fragmentation), des horodatages à la nanoseconde, et le fait que le trafic de cotation croît de façon super-linéaire avec la participation, parce que chaque teneur de marché recote sur chaque entrée. Le volume n'est pas accessoire ; il est la caractéristique d'ingénierie de ces données. Traitez-les d'abord comme un problème de systèmes, et seulement ensuite comme un problème de statistiques.

Le rapport de lignes tape-sur-barre est de six à neuf ordres de grandeur : une série quotidienne a une ligne par instrument et par jour, un tape a une ligne par événement, et les événements arrivent en rafales, des milliers par seconde sur un titre actif.

\frac{\text{rows}_{\text{tape}}}{\text{rows}_{\text{daily}}} \;\sim\; 10^{6}\text{–}10^{9} \quad\text{per instrument}

Pourquoi ne pas simplement utiliser du CSV et Pandas ?

La plupart des requêtes sur tick sont « donne-moi les prix de transaction de cet instrument entre 14h00 et 14h05 ». Le stockage en lignes vous force à lire chaque champ de chaque ligne de cette plage ; le stockage colonnaire vous laisse ne lire que la colonne des prix pour ce seul créneau temporel. La disposition des données décide si cette requête se mesure en millisecondes ou en minutes. Le CSV est le mauvais outil sur tous les axes : il encode les nombres en texte (un flottant coûte environ 8 octets en binaire, plus de 15 en texte), sans typage, sans compression, sans indexation et sans predicate pushdown. Bien pour quelques milliers de lignes ; catastrophique pour un milliard.

Les dataframes orientés lignes peinent pour une raison voisine : charger une journée de MBO dans Pandas matérialise chaque colonne en RAM, si bien que vous manquez de mémoire avant de manquer de patience. Soit vous découpez laborieusement, soit vous passez à un moteur colonnaire qui streame. Ce n'est pas une préférence ; c'est la différence entre une analyse faisable et une analyse infaisable. Le choix du format est l'ingénierie.

Une requête colonnaire ne lit que les colonnes et les plages de lignes qu'elle touche ; un stockage en lignes lit tout ce qui est dans la plage. Pour une requête touchant quelques-unes des

C

colonnes sur une fraction des

N

lignes, le rapport d'octets lus est l'économie.

\frac{\text{bytes}_{\text{columnar}}}{\text{bytes}_{\text{row}}} \;\approx\; \frac{k}{C}\cdot\frac{n}{N}, \qquad k \ll C,\; n \ll N

Quels formats de stockage et quels moteurs règlent cela ?

Les données tick vivent dans des stockages colonnaires, et 2026 offre un menu à plusieurs niveaux. Parquet + Arrow + (DuckDB / ClickHouse / Polars) est le défaut ouvert : des fichiers colonnaires en stockage objet cloud, interrogés par un moteur embarqué ou colonnaire ; bon marché, portable, sans licence, qui passe à l'échelle horizontalement. C'est la plus grande raison à elle seule de la chute de la barrière du stockage. kdb+/q est le titulaire pour le travail sérieux sur tick : une base de données de séries temporelles colonnaire d'abord en mémoire, avec un langage vectoriel laconique, exceptionnelle aux as-of joins (aligner une transaction sur la cotation en vigueur, exactement ce dont a besoin l'inférence du sens des transactions) et à l'analytique en streaming temps réel. Historiquement coûteuse ; encore la référence pour l'analytique tick sensible à la latence.

Arctic / ArcticDB est un stockage de séries temporelles versionné, natif Python (à l'origine celui de Man AHL, adossé à MongoDB ; ArcticDB est la réécriture colonnaire moderne), populaire là où la pile de recherche est en Python et où vous voulez un stockage tick rapide, versionné et en forme de dataframe sans q. Et le pcap brut se tient au bord de la capture : les paquets réseau bruts stockés sans perte pour pouvoir redécoder le flux à l'identique plus tard ; la vérité terrain, au prix de la taille, avant de normaliser en colonnes. La décision est un triangle coût / vitesse / opérabilité : Parquet sur stockage objet pour une portée bon marché, kdb+ pour l'analytique à faible latence, Arctic pour le versionnement natif Python, pcap pour la fidélité forensique. La plupart des firmes sérieuses utilisent plus d'un niveau.

Le choix du format arbitre le coût contre la latence des requêtes contre l'opérabilité contre la fidélité : Parquet sur stockage objet pour une portée bon marché, kdb+ pour l'analytique à faible latence, ArcticDB pour le versionnement Python, pcap pour une vérité terrain sans perte.

\text{pcap (fidelity)} \;\to\; \text{Parquet (cost)} \;\to\; \text{kdb+ (latency)}

Comment fonctionne la compression sur les données tick ?

Les données tick se compressent extrêmement bien, souvent 5 à 20×, parce qu'elles sont répétitives et lentement variables. Une colonne de prix lit « 50,00 ; 50,00 ; 50,01 ; 50,01 ; 50,01 ; 50,00 » : stockez la première valeur et les deltas, et l'essentiel de la colonne devient quasi nul, ce qu'un compresseur général écrase. La disposition colonnaire est ce qui rend cela possible, parce que les valeurs semblables sont adjacentes. Les encodages qui comptent sont le delta-of-delta sur les horodatages (monotones, à espacement quasi constant dans une rafale), l'encodage par dictionnaire sur les colonnes sens / code-condition / instrument (une poignée de valeurs distinctes mappées sur de petits entiers), le codage par plages (run-length) sur les prix et tailles répétés, et le bit-packing des petits entiers, puis un codec au niveau octet par-dessus, Zstandard pour le ratio ou LZ4 pour la vitesse de décodage.

L'arbitrage est CPU contre octets : une compression plus forte économise le stockage et le réseau mais coûte du CPU à la lecture, alors vous maximisez le ratio pour l'archivage et favorisez la vitesse de décodage sur les chemins de requête chauds. La conséquence pratique est grande : ce chiffre brut de « téraoctets par jour » devient souvent quelques centaines de gigaoctets par jour stockés, ce qui est exactement ce qui fait tenir l'économie du stockage objet cloud. La compression est la raison de la chute de la barrière.

L'encodage delta transforme une colonne lentement variable en un flux de quasi-zéros, l'encodage par dictionnaire mappe quelques catégories distinctes sur de petits entiers, et un codec général écrase le résultat, ce qui se compose jusqu'à environ 5 à 20× sur de vraies données tick.

\text{prices} \;\xrightarrow{\;\Delta\;}\; \{0,0,+1,0,0,-1,\dots\} \;\xrightarrow{\;\text{Zstd}\;}\; \tfrac{1}{5}\text{–}\tfrac{1}{20}\ \text{size}

Que faut-il vraiment pour capturer le flux correctement ?

Le stockage est bon marché et le devient de plus en plus ; ne pas perdre un message à trois millions de messages par seconde est la partie difficile. Capturer signifie recevoir chaque message sans perte et dans l'ordre, l'horodater à la carte réseau, détecter les trous de séquence et les récupérer, et le persister sans rien laisser tomber sous charge. Une capture qui perd silencieusement des paquets produit un tape troué qui corrompt tout carnet reconstruit en aval (numéros de séquence). Concrètement, cela exige des NIC à contournement du noyau (pour que l'ordonnanceur de l'OS ne perde pas le multicast en rafale), un horodatage matériel/PTP (synchronisation d'horloge), une arbitration de flux A/B pour une récupération sans trou, et assez de débit d'écriture et de tampon pour qu'un blocage de stockage ne fasse pas remonter une contre-pression jusqu'à la perte de paquets. C'est la pile à faible latence et la colocation et FPGA, vues du côté des données.

C'est aussi là que se situe désormais le moat. Les formats ouverts ont banalisé le stockage et la requête ; ils n'ont rien fait pour la capture sans perte au bord, qui exige toujours du matériel colocalisé et une ingénierie soignée. La valeur d'un tape propre tient de plus en plus à la capture, pas au disque.

Pourquoi le volume de données est-il à la fois une barrière et une activité ?

Le volume est une barrière parce que des données tick propres, complètes et correctement capturées sont véritablement difficiles et coûteuses à obtenir, stocker et interroger, et la plupart des quants en herbe ne les obtiennent jamais. Cette même difficulté est précisément pourquoi un jeu de données propre est une chose pour laquelle on paie. Si des données L2/L3 propres étaient triviales, elles seraient gratuites et il n'y aurait pas de produit de données ; c'est la difficulté tirée par le volume (capture, stockage, reconstruction, justesse) qui rend un jeu de données de carnet propre et reconstructible digne d'être vendu (jeux de données). Pendant ce temps les flux extraient une rente : les places facturent des frais de données de marché substantiels, une ligne de coût reconnue et un débat réglementaire vivant, si bien que comprendre le problème du volume, c'est comprendre pourquoi la couche données est défendable et pourquoi votre budget d'infrastructure en est dominé.

Ce que 2026 déplace, c'est quelle moitié est difficile. L'économie du stockage s'est effondrée (stockage objet plus Parquet plus DuckDB) ; l'économie de la capture et des licences, non. L'avantage s'est donc déplacé de « pouvez-vous vous payer kdb+ » à « pouvez-vous capturer sans perte et la nettoyer correctement », ce qui tient plus de la discipline d'ingénierie que du budget, une bonne nouvelle pour la boutique solo (se lancer en indépendant en 2026).

Exemple travaillé

Un dimensionnement de stockage au dos de l'enveloppe pour un instrument-jour, en 2026, illustratif ; revérifiez les débits de messages contre les statistiques publiées par la place. Prenez une action liquide, MBO en profondeur complète, et supposez environ 2 000 000 de messages sur une journée active. Un message normalisé fait à peu près 40 octets (horodatage 8, séquence 8, type 1, sens 1, prix 8, taille 8, identifiants et drapeaux environ 6), si bien que la taille brute est de $2{,}000{,}000 \times 40 = 80\ \text{MB}$ par instrument-jour non compressé. Mis à l'échelle d'une place de 3 000 instruments actifs, cela fait environ 240 Go par jour bruts.

Par instrument-jour : 2 M de messages × ~40 octets ≈ 80 Mo bruts. Une place de 3 000 titres ≈ 240 Go/jour bruts, que la compression colonnaire à ~8× ramène à ~30 Go/jour stockés, soit environ 10 To/an pour la profondeur complète de cette place.

\underbrace{240\ \text{GB/day}}_{\text{raw}} \;\xrightarrow{\;\div\,8\,(\text{Zstd})\;}\; \underbrace{30\ \text{GB/day}}_{\text{stored}} \;\approx\; 10\ \text{TB/yr}

Maintenant la leçon. Dix téraoctets par an sur du stockage objet de commodité, c'est quelques dizaines de dollars par mois de stockage. Trivial. Le coût n'est pas le disque ; c'est l'infrastructure de capture (matériel colocalisé, flux redondants) et les frais de licence de données de marché, qui éclipsent le stockage de plusieurs ordres de grandeur. Le titre « téraoctets par jour » est un vrai chiffre brut, mais la compression et le stockage objet bon marché rendent facile de le garder. L'argent et la difficulté sont dans le fait de le capturer sans perte et de le payer à la place. Ces chiffres sont illustratifs et synthétiques ; les débits de messages, largeurs et frais réels sont spécifiques à la place, alors vérifiez les statistiques publiées de la place et sa grille tarifaire de données de marché en 2026. Un jeu de données tick/LOB propre, compressé et reconstructible est précisément ce que ce problème de volume rend digne d'être acheté plutôt que construit (jeux de données et outils).

Où cela s'inscrit

↑ Vers le haut · brique de Données haute fréquence ↔ En travers · se combine avec La pile à faible latence ↔ En travers · se combine avec Protocoles de messagerie → Application · rapporte sur Tenue de marché en crypto → Application · rapporte sur Actions & futures ⤓ Construire / Acheter · outil nécessaire Jeux de données et outils

Questions fréquentes

Pourquoi les données haute fréquence sont-elles difficiles à exploiter ?

Parce qu'elles cassent les hypothèses que des données plus lentes vous laissent faire. Elles sont énormes (téraoctets par jour et par marché), irrégulièrement échelonnées (des événements, pas des ticks d'horloge), à queues lourdes et non normales, et contaminées par le bruit de microstructure comme le rebond bid-ask. Les horodatages exigent du soin, et le rééchantillonnage naïf détruit justement le signal voulu. Cela demande une pensée événementielle et de processus ponctuels plutôt que des statistiques à intervalle fixe.