clickhouse-architecture-advisor
MUST USE when designing ClickHouse architectures, selecting between ingestion or modeling patterns, or translating best practices into workload-specific system designs. Complements clickhouse-best-practices with decision frameworks and explicit provenance labels.
适合你,如果正在为分析平台设计 ClickHouse 架构
npx oh-my-skill add clickhouse/agent-skills/clickhouse-architecture-advisorcurl -fsSL https://oh-my-skill.com/install.sh | bash -s -- clickhouse/agent-skills/clickhouse-architecture-advisornpx oh-my-skill verify clickhouse/agent-skills/clickhouse-architecture-advisor怎么用
商店整理自技能原文 · 版本 6e5458d · 表述以原文为准Claude 会先识别工作负载类型(如可观测性、SIEM),然后读取对应规则文件,为每条推荐打上 official、derived 或 field 标签,并链接官方文档。不确定时明确说明。最终输出结构化的架构决策建议,包含分组、推荐和验证。
当你询问 ClickHouse 架构设计、选择摄入或建模模式,或需要将最佳实践转为特定工作负载系统设计时触发。
技能原文 SKILL.md
ClickHouse Architecture Advisor
This skill adds workload-aware architecture decisioning on top of clickhouse-best-practices.
Official docs remain the source of truth. This skill must always prefer official ClickHouse documentation when available.
Required behavior
Before producing recommendations:
- Identify the workload shape
- observability
- security / SIEM
- product analytics
- IoT / telemetry
- market data / financial services
- mixed OLAP with point-lookups
- Read the relevant decision rule files in
rules/ - Use
mappings/doc_links.yamlto attach official documentation - Classify every recommendation as:
officialderivedfield- Never present field guidance as official guidance
- If a recommendation is uncertain, say so explicitly
Provenance rules
official
Use this when the recommendation is directly backed by official docs.
derived
Use this when the recommendation is not stated verbatim in docs but follows logically from documented ClickHouse behavior.
field
Use this only for experience-based guidance that may be situational. When using field, include:
- a disclaimer that the advice is heuristic
- a relevant official doc if one partially applies
- the reason the advice depends on workload context
Read these rule files by scenario
Real-time ingestion design
rules/decision-ingestion-strategy.mdrules/decision-real-time-preaggregation.md- Relevant best-practices insert rules
Time-series and retention design
rules/decision-partitioning-timeseries.md- Relevant best-practices schema partition rules
Enrichment and dimension lookups
rules/decision-join-enrichment.md- Relevant best-practices query join rules
Mutable state / late-arriving events
rules/decision-late-arriving-upserts.md- Relevant best-practices mutation avoidance rules
Output format
Structure responses like this:
## Workload Summary - workload: - latency target: - data shape: - primary query patterns: - operational constraints: ## Key Decisions - ... - ... ## Recommendations ### <Recommendation title> **What** ... **Why** ... **How** ... **Category** official | derived | field **Confidence** high | medium | heuristic **Source** - doc link(s) **Validation** - concrete SQL, metric, or smoke test
Architecture-specific guidance
Prefer decision frameworks over generic advice. Good responses should:
- explain tradeoffs
- identify the likely operating bottleneck
- separate immediate actions from structural redesign
- provide target architecture patterns, not just isolated settings
Full reference
See AGENTS.md for the compiled version and examples/ for sample outputs.