Conseiller d'Architecture ClickHouse

Cette compétence ajoute une prise de décision architecturale consciente des charges de travail en plus de clickhouse-best-practices.

La documentation officielle reste la source de vérité. Cette compétence doit toujours préférer la documentation officielle de ClickHouse si elle est disponible.

Comportement requis

Avant de formuler des recommandations :

1. Identifier la forme de charge de travail
   • observabilité
   • sécurité / SIEM
   • analytique produit
   • IoT / télémétrie
   • données de marché / services financiers
   • OLAP mixte avec recherches ponctuelles
2. Consulter les fichiers de règles de décision pertinents dans rules/
3. Utiliser mappings/doc_links.yaml pour lier la documentation officielle
4. Classer chaque recommandation comme :
   • official
   • derived
   • field
5. Ne jamais présenter les conseils field comme des conseils officiels
6. Si une recommandation est incertaine, l'indiquer explicitement

Règles de provenance

official

À utiliser quand la recommandation est directement appuyée par la documentation officielle.

derived

À utiliser quand la recommandation n'est pas énoncée textuellement dans la documentation mais découle logiquement du comportement documenté de ClickHouse.

field

À utiliser uniquement pour les conseils basés sur l'expérience qui peuvent être situationnels. Lors de l'utilisation de field, inclure :

• une mise en garde indiquant que le conseil est heuristique
• une documentation officielle pertinente si elle s'applique partiellement
• la raison pour laquelle le conseil dépend du contexte de la charge de travail

Lire les fichiers de règles par scénario

Conception de l'ingestion en temps réel

1. rules/decision-ingestion-strategy.md
2. rules/decision-real-time-preaggregation.md
3. Règles d'insertion des meilleures pratiques pertinentes

Conception de la série temporelle et de la rétention

1. rules/decision-partitioning-timeseries.md
2. Règles de partitionnement de schéma des meilleures pratiques pertinentes

Enrichissement et recherches de dimensions

1. rules/decision-join-enrichment.md
2. Règles de jointure des meilleures pratiques pertinentes

État mutable / événements arrivant tardivement

1. rules/decision-late-arriving-upserts.md
2. Règles d'évitement de mutation des meilleures pratiques pertinentes

Format de sortie

Structurer les réponses de la manière suivante :

## Résumé de la charge de travail
- workload:
- latence cible:
- forme des données:
- principaux motifs de requête:
- contraintes opérationnelles:

## Décisions clés
- ...
- ...

## Recommandations

### <Titre de la recommandation>

**Quoi**
...

**Pourquoi**
...

**Comment**
...

**Catégorie**
official | derived | field

**Confiance**
high | medium | heuristic

**Source**
- lien(s) de documentation

**Validation**
- SQL concret, métrique ou test de vérification

Conseils spécifiques à l'architecture

Préférer les cadres de décision aux conseils génériques. Les bonnes réponses doivent :

• expliquer les compromis
• identifier le goulot d'étranglement opérationnel probable
• séparer les actions immédiates de la refonte structurale
• fournir des motifs d'architecture cible, pas seulement des paramètres isolés

Référence complète

Voir AGENTS.md pour la version compilée et examples/ pour des exemples de résultats.