Indexation des référentiels analytiques
1) Pourquoi indexer iGaming-platform
Taux d'analyse : les rapports sur les expériences GGR/NET, les conversions, RG/AML et A/B sont empilés dans le SLA.
Coût : moins d'octets scannables → moins de factures de calcul/entrepôt.
Fiabilité : Stabilité p95/p99 latence dashboard et métriques API.
Échelle : des dizaines de marques/marchés/PSP/fournisseurs sans coût infernal « full scan ».
2) Modèle de charge (avant d'indexer)
Факты: `payments`, `game_rounds`, `sessions`, `bonus_events`.
Dimensions : 'bou _ user' (sans PII), 'bou _ provider', 'bou _ psp', 'bou _ country'.
Requêtes : « derniers N jours », agrégations par 'brand/country/provider/psp', filtres par champ d'état, join's par surrogate-keys, recherche par attributs JSON (mode de paiement, périphérique), top-K/percentile.
Nous choisissons les indices en fonction de la sélectivité, de la cardinalité et de la fréquence d'utilisation.
3) Types d'index et quand les prendre
3. 1 Classique
B-tree : égalité/plages sur des colonnes hautement sélectives ('user _ surrogate _ id', 'occurred _ at', 'amount').
Hash : égalité pure ; moins souvent en analyse (contre les fourchettes faibles).
Bitmap : faible cardinalité et filtres connectés fréquents ('country', 'kyc _ level', 'rg _ state', 'brand'). Excellent pour résumer les masques.
3. 2 Spécificités Columnar
Min-max (data skipping) : les statistiques automatiques « minimum/maximum » dans le parquet/les parties du moteur → laissent passer les blocs. Fonctionne mieux lorsque vous triez par champs filtrables.
Bloom index : tests probabilistes rapides d'appartenance de valeur dans un bloc (utiles pour 'user _ id', 'transaction _ id', 'psp').
BRIN (Block Range Index) : « pointeurs » bon marché sur les plages de blocs si les données sont naturellement ordonnées (temps). Bon marché, mais efficace pour la série time.
3. 3 Avancé/Spécialisé
GiST/GIN (inversé) : JSON/arrays/texte, filtres par attributs imbriqués ('metadata. method = 'Papara'`, `device. os in [...]`).
Join/Projection (ClickHouse/MPP) : matériaux pour accélérer join/agg (clé pré-join stockée à côté du fait, pré-agrégation).
Vecteur (ANN) : recherche d'embeddings similaires (recommandations/comportement antifrod) - IVF/HNSW/Flat comme « indice des voisins immédiats ».
Z-order/Z-order (lakehouse/Databricks )/Cluster keys (Snowflake )/ORDER BY (ClickHouse) : clustering de données multidimensionnel sur disque pour un meilleur skipping de données.
4) Lot, tri, clustering
Lots (date/pays/marque) : gros (jour/semaine) pour éviter la « malédiction des petits fichiers ». Nous sélectionnons les champs avec une sélectivité élevée dans WHERE/droits d'accès.
Trier à l'intérieur du lot : 'ORDER BY (occurred_at, brand, psp)' ou Z-order par '(brand, country, provider)' - c'est ainsi que min-max et bloom sont mieux travaillés.
Cluster/Recluster : reclamation périodique pour maintenir la localité.
TTL et rétention : suppression automatique des anciens lots/segments.
5) Représentations et projections matérialisées
MV pour les tranches chaudes : 'payments _ 7d _ by _ brand _ psp', 'rounds _ 1d _ by _ provider'. Prise en charge incrémentale (streaming upserts).
Projections (ClickHouse )/Aggregate tables : groupes préliminaires, niveaux roll-up (chas→den→nedelya).
Cache des résultats : query result cache/warehouse result cache pour les dashboards répétables (validons par le jeton de requête et la fraîcheur des données).
6) Données semi-structurées (JSON/VARIANT)
Index par chemin : index inversé/GIN sur json ('$ .device. os`, `$.psp. details. method`).
Matérialisation des attributs importants dans les colonnes : pour les filtres stables (méthode de paiement, appareil, version de l'application).
Statistiques par clé : collecte de distributions pour un plan sélectif.
7) Lacs de données : Iceberg/Delta/Hudi
Index manifest : métadonnées sur les fichiers de parquet (min-max, null-count, bloom) → partition pruning + file skipping.
Compaction/fusion de fichiers : merge régulier de petits fichiers en taille « optimale » (128-1024 Mo).
Clustering/Z-order : réemballage des fichiers pour les champs corrélés (par exemple, 'brand, country, occurred _ at').
Delete/Update Index : division de position et bloom pour accélérer merge-on-read.
8) Comment choisir les indices : chèque pratique
1. Rassemblez le top N des requêtes (90 % de la charge) → les champs filtres/join/group.
2. Pour chaque champ, estimer la sélectivité 'sel = 1 - distinct (value )/rows'et la cardinalité.
3. Lot temporel + 1-2 mesures avec filtres/accès stables.
4. Trier/cluster keys avec filtres et clés join.
5. Ajoutez bloom pour les points id, bitmap pour une faible cardinalité.
6. Agrégations chaudes → MV/projection.
7. Chemins JSON → index inversés + matérialisation.
8. Sur les lacs, compaction et clustering selon les horaires.
9. Entrez SLO : latence p95, octets scannables/requête, proportion de données skippées.
9) Support et entretien
ANALYZE/Statistiques : mettre à jour les cardinalités et histogrammes ; sinon, l'optimiseur est « aveugle ».
VACUUM/OPTIMIZE/RECLUSTER : défragmentation et reclastérisation.
Surveillance de l'utilisation des index : « taux de covering », « liste d'index unused », « bytes scanned/bytes skipped ».
Auto-conseillers : conseils périodiques sur les clés de cluster et le tri basé sur query log.
Tests de régression : avant de déployer de nouvelles clés, comparez le profil de requête et le coût.
10) Métriques et SLO d'indexation
Technique : p95/p99 latency, scanned bytes/query, skipped bytes %, files touched, cache hit-rate.
Économie : $/demande, $/dashboard, $/TB scan.
Opérations : temps de compaction, file de translatération, proportion de « petits fichiers ».
Qualité des plans : proportion de demandes utilisant des indices/projections, précision des cardinalités.
11) Case iGaming (recettes prêtes à l'emploi)
11. 1 Paiements/PSP : chutes/refus
Lot : « par jour ». Tri : '(marque, pays, occurred_at)'.
Bloom: `transaction_id`, `user_id`. Bitmap: `psp`, `status`.
MV: `payments_7d_by_brand_psp(status, declines)`.
Résultat : p95 ↓ avec 8. 2s jusqu'à 1. 1s, scanned bytes ↓ на 87%.
11. 2 tours de jeu : fournisseur/jeu
Z-order / ORDER BY: `(provider, game_id, occurred_at)`.
Projection/agg: `rounds_1d_by_provider_game`.
BRIN (si un magasin comme Postgres) : par 'occurred _ at'.
Résultat : top K jeux/heure - sous-second sur cache chaud.
11. 3 RG/AML : événements de restriction/auto-exclusion
Bitmap: `rg_state`, `kyc_level`. JSON-path GIN: `$.reason`.
MV : « restrictions actives en 30 jours » + matérialisation du niveau user sans PII.
Le résultat : des échantillons rapides pour un complaens sans un milliard d'événements.
11. 4 Antifrod : itinéraires et dispositifs
Matérialisation JSON→kolonki : 'device. os`, `device. model`, `payment. method`.
Bloom: `graph_device_id`. Cluster: `(brand, country, device. os)`.
Indice vectoriel : embeddings « comportement des dépôts à 7d » → rapide k-NN pour des anomalies similaires.
12) Sécurité et vie privée
Zero-PII dans les champs indexés et les logs de plan.
Chiffrement sur disque : les index/statistiques sont chiffrés de la même manière que les données.
K-anonymat des agrégats : MV/projections ne sont publiés que par des groupes de ≥N.
Géo/tenant-isolation : les lots/clés incluent 'brand/country/license'.
Legal Hold : les indices/manivelles tombent aussi dans le « gel ».
13) Anti-modèles
Indexer « tout » de suite → explosion de volume et write-amplification.
Petits lots (heure/minute) → tempête de barres et « petits fichiers ».
Clés de tri qui ne correspondent pas aux filtres → zéro data skipping.
L'absence de statisticien → de mauvais plans, plein scan.
JSON sans index de chemin et sans matérialisation des attributs « chauds ».
Ignorer la compaction et recluster → dégradation en 2 à 4 semaines.
14) Modèles (prêts à l'emploi)
14. 1 Politique de regroupement/indexation (YAML)
yaml dataset: gold. payments partition_by: ["date"]
order_by: ["brand","country","occurred_at"]
indexes:
bloom: ["transaction_id","user_surrogate_id"]
bitmap: ["psp","status","rg_state"]
materialized_views:
- name: mv_payments_7d_brand_psp group_by: ["brand","psp","status"]
window: "7d"
slo:
p95_latency_ms: 1200 scanned_bytes_per_query_max_mb: 256 maintenance:
compact_small_files: true recluster_cron: "0 /6 "
privacy:
pii_in_index: false14. 2 Plan de compaction du lac (Iceberg/Delta)
yaml compaction:
target_file_size_mb: 512 small_file_threshold_mb: 64 zorder_by: ["brand","country","occurred_at"]
run_every: "PT6H"
max_concurrency: 414. 3 Index pour les champs JSON
sql
-- GIN/inverted index on device attributes
CREATE INDEX idx_device_json ON gold. sessions
USING GIN ((device_json));
-- Materialization of critical pathways
ALTER TABLE gold. sessions ADD COLUMN device_os TEXT;
UPDATE gold. sessions SET device_os = device_json->>'os';
CREATE BITMAP INDEX idx_device_os ON gold. sessions(device_os);14. 4 SLO de surveillance des indices
yaml monitoring:
skipped_bytes_share_min: 0. 70 index_usage_rate_min: 0. 85 stats_freshness_max_hours: 24 small_files_share_max: 0. 1015) Feuille de route pour la mise en œuvre
0-30 jours (MVP)
1. Collecte des meilleures N demandes et profils de scan.
2. Lot par date + tri convenu avec les filtres.
3. Activer data skipping (min-max) et bloom pour les champs id.
4. Un MV pour la métrique « hot » (payments 7d).
5. Dashboard SLI : p95, bytes scannés, skipped share, petits fichiers.
30-90 jours
1. Chemins JSON : indices inversés + matérialisation.
2. Lac : compaction et Z-order/clustering avec 2-3 clés.
3. Conseiller automatique de clés/projections ; ANALYSE RÉGULIÈRE.
4. Révision des lots (day→week) lorsqu'il s'agit de « petits dossiers ».
3-6 mois
1. Catalogue MV/projections avec versioning et SLA.
2. Index vectoriel pour recommandations/antifrod.
3. Une seule politique SLO et budgets $/demande ; les alertes des dégradations.
4. Audit de la vie privée des indices, géo/tenant-isolation.
16) RACI
Data Platform (R) : lots/index/compacts, auto-conseillers, surveillance.
Analytics/BI (R) : MV/projections sous dashboards, profilage des requêtes.
Domain Owners (C) : critères des tranches et filtres « chauds ».
Sécurité/DPO (A/R) : vie privée, politiques PII, clés geo/tenant.
SRE/Observability (C) : SLO/alerting, capaciti pour compaction.
Finances (C) : budgets $/demande et économies sur les indices.
17) Sections connexes
Schémas de données et leur évolution, Validation de données, Pratiques DataOps, Analyse des anomalies et corrélations, API analytiques et métriques, Clustering de données, Réduction de dimension, MLOps : exploitation de modèles.
Résultat
L'indexation du stockage analytique est une stratégie, pas « créer un index pour tout ». Les bons lots et triages, le data skipping et le bloom, les MV/projections réfléchies et la compaction régulière fournissent des demandes rapides et prévisibles à un coût contrôlé et sans risque pour la vie privée. Pour iGaming, cela signifie des solutions opérationnelles pour les paiements, les fournisseurs et RG/AML - dans les limites du SLA et du budget.