Halcyon

Le problème

Les analystes attendaient plusieurs minutes des tableaux de bord qui auraient dû s’afficher en quelques secondes. Le moteur existant scannait bien plus de données que nécessaire, et le planificateur ignorait tout de la disposition physique sur disque.

Avec un entrepôt de 4 Po et plus de 600 utilisateurs quotidiens, chaque scan inutile se multipliait en coût réel et en frustration réelle.

L’approche

J’ai reconstruit la couche d’exécution autour du predicate pushdown — les filtres sont évalués au plus près du stockage, éliminant des row groups entiers avant même qu’ils quittent le SSD.

Un planificateur à base de coûts réécrit les requêtes à l’échelle du cluster, arbitrant entre coût de shuffle et parallélisme pour garder les 64 nœuds saturés sans étouffer le réseau.

• Saut de row groups et de pages piloté par les statistiques Parquet.
• Exécution vectorisée sur des record batches Apache Arrow.
• Réécriture adaptative des plans selon des estimations de cardinalité en direct.

Les requêtes qui prenaient 90 secondes reviennent désormais en moins de 8. L’équipe a cessé de pré-agréger les données juste pour rendre les tableaux de bord utilisables.

Le résultat

La latence P99 a été divisée par 12, et le moteur sert désormais toute l’organisation analytique depuis un seul cluster. Le planificateur à base de coûts a éliminé toute une classe de vues matérialisées réglées à la main.