Et encore un article un peu technique pour finir la journée en beauté ! Si je vous disais que votre serveur Linux pouvait gérer 10 exaoctets de données sans broncher ? Vous ne me croiriez pas je pense… D’ailleurs c’est quoi 10 exaoctets ?? Et bien ça correspond à 10 millions de To. C’est pas mal hein ?

Hé bien c’est exactement ce que permet de gérer TernFS, le système de fichiers qu’XTX Markets vient de libérer après trois ans d’utilisation intensive. XTX Markets est une boîte d’algo-trading qui brasse 250 milliards de dollars par jour et j’avoue que c’est un joli cadeau de presque-Noël qu’elle vient de nous faire…

D’après ce qu’ils expliquent sur leur site , NFS et les autres solutions classiques ne tenaient plus la charge face à leurs 650 pétaoctets de données utilisées leur machine learning. Alors ils ont fait ce que font les vrais geeks, ils ont codé leur propre solution… et après trois ans de production sans perdre “un seul octet”, ils ont tout balancé en en open source sur GitHub .

Le truc génial avec TernFS, c’est qu’il a été pensé pour les fichiers immuables, vous savez, ces gros datasets de plusieurs gigaoctets qu’on écrit une fois et qu’on relit des milliers de fois pour entraîner des modèles. Pas de modification après création, pas de prise de tête avec les locks et la cohérence. C’est simple et efficace.

L’architecture repose sur quatre composants principaux qui bossent ensemble : les metadata shards (256 shards logiques pour gérer les métadonnées), le CDC (Cross-Directory Coordinator) pour les opérations entre répertoires, les block services pour stocker les données, et un registry pour orchestrer tout ce petit monde. Le tout communique en UDP/TCP avec du Reed-Solomon pour l’erasure coding et du CRC32-C pour vérifier l’intégrité. Bref, ça semble être du solide.

Et les chiffres qu’ils donnent sur leur production sont assez dingues. Ils parlent de 500+ pétaoctets répartis sur 30 000 disques durs et 10 000 SSD, dans 3 datacenters différents, avec des débits qui montent à plusieurs téraoctets par seconde en vitesse de pointe. Et leur système gère ça tranquille, avec du multi-région natif et une tolérance aux pannes qui ferait pâlir d’envie n’importe quel admin sys.

Si ça vous chauffe, pour installer TernFS, c’est du classique. Vous clonez le repo, vous lancez ./build.sh alpine ou ./build.sh ubuntu selon votre distrib, et c’est parti. Il y a un module kernel Linux pour gratter les perfs maximales et toucher les étoiles, mais vous pouvez aussi utiliser FUSE si vous préférez rester en userspace. Ils ont même implémenté une API S3 pour ceux qui veulent migrer depuis AWS sans tout réécrire.

git clone https://github.com/XTXMarkets/ternfs
cd ternfs
./build.sh alpine
# Et pour tester en local
./scripts/ternrun

On est là en train de chiller dans une bonne journée bien normale quand SOUDAIN alerte rouge internationale, on apprend qu’il y a une faille critique CVSS 10 dans Apache Parquet, et que tout le monde panique bien évidemment !!

Vous, admin système ou développeur, vous vous précipitez sur votre téléphone qui n’arrête pas de sonner pendant que les experts du CERT vous bombardent de mails d’alerte… et au milieu de ce chaos, vous vous grattez la tête (ou autre chose) en vous demandant : “Mais est-ce que je suis vraiment concerné, ou c’est encore une tempête dans un verre d’eau ?”

Saviez vous que les fichiers Parquet se prenaient pour des bombes ? Alors pas des bombes latines mais plutôt des bombes zip.

Alors, pour ceux qui débarquent de la planète Mars, il faut savoir que Parquet est devenu le format de prédilection pour échanger des données tabulaires. Très utilisé dans tout ce qui est Big Data et qui met une claque à ce bon vieux CSV tout pourri, Parquet, c’est binaire, c’est colonnaire, c’est compressé, c’est top !

Mais attention, derrière cette apparente perfection se cache un danger mortel pour vos disques durs et autres SSD ! En effet, même un fichier Parquet parfaitement valide peut mettre un sacré bordel et faire planter tous vos services.

Comment ? Et bien simplement avec ce fichier de seulement 42 Ko qui contient… tenez-vous bien… plus de 4 PÉTAOCTETS de données !! Oui, on parle bien de 4 millions de gigaoctets dans un malheureux fichier de 42 Ko, fallait oser.

On appelle ça une bombe de décompression ! Alors comment ça fonctionne ?

Eh bien c’est grâce à un petit tour de passe-passe démoniaque appelé « encodage par dictionnaire« . En gros, on lui donne un dictionnaire avec une seule valeur, et ensuite on fait référence à cette valeur en boucle, environ 2 milliards de fois. Résultat, on obtient un fichier minuscule car compressable au maximum mais qui une fois dézippé représente une table monstrueusement gigantesque.

C’est subtil… mais c’est vicieux ! 😈

Imaginez un peu le carnage si vous balancez ce fichier innocent dans votre pipeline Big Data sans faire gaffe… Boom ! 💥 Plantage général, crash systémique, apocalypse nucléaire ! Vos services vont tenter de lire ce fichier en pensant que c’est un gentil petit fichier Parquet de rien du tout, et là… Surprise ! C’est le chaos total. Votre cluster va fondre comme neige au soleil en essayant d’avaler ces pétaoctets de données.

Morale de l’histoire, faites attention à tout, même à ce que vous dézippez.

Et si vous avez un peu de place sur votre disque dur, vous pouvez toujours tenter l’aventure en téléchargeant 42.zip ici. (NON, NE DEZIPPEZ PAS CE TRUC !! MAUVAISE IDEE !!) (le mot de passe du zip est : 42)

Source