data-analytics

data-analytics 技能概览

data-analytics 技能可以帮助你生成分析系统的 PlantUML 图：ETL 流程、数据湖、数据仓库、流式管道、日志分析和 BI 仪表板。它适合你需要一份 data-analytics 指南，把粗略架构转成一张清晰图表，并使用 AWS 分析与数据库 stencil，而不是只给出一个点名组件的泛化提示词的时候。

如果你想为数据分析工作流快速生成易读的图，而且管道顺序很重要——来源、采集、转换、存储、可视化——就该用这个 data-analytics 技能。它尤其适合展示治理、分层暂存、目录编目，或跨系统的近实时流转。

最适合管道图和数据仓库图的场景

这个技能最强的地方，是能把数据如何流动讲清楚，而不只是列出有哪些工具。它适用于 ETL/ELT、CDC、lakehouse 风格布局、以 Redshift 为中心的数据仓库，以及从业务系统到分析系统的交接。如果你的目标是做一张 data-analytics for Data Analysis 图，让利益相关者一眼扫过去就能看懂，这个技能很合适。

这个技能与众不同的地方

这个仓库对图表结构和语法有明确偏好：它要求使用 PlantUML 代码块、@startuml / @enduml、从左到右的流向，以及 mxgraph.aws4.* stencil 图标。这样生成的图比自由发挥的提示词更统一，也减少了在图标选择和布局上的猜测成本。

什么时候不该用它

不要把 data-analytics 用在通用软件架构、UML 类图，或者大而全的云基础设施图上。如果主线是应用组件而不是数据流动，那么别的技能会产出更好的结果，也更少需要返工。

如何使用 data-analytics 技能

安装并验证技能上下文

对于常规的 data-analytics install，先从仓库安装技能，然后优先检查顶层说明文件：

1. 使用 npx skills add markdown-viewer/skills --skill data-analytics 安装。
2. 打开 SKILL.md，确认图表规则。
3. 在开始自己写提示词之前，先查看 examples/ 里的示例文件。

这个技能很精简，所以示例比长篇规则说明更重要。它们展示了模型应当遵循的实际语法模式。

先从工作流出发，不要先列工具清单

一个优秀的 data-analytics usage 请求，应该按阶段描述数据故事，而不是把一堆 AWS 服务堆在一起。比如，不要只说“画一个包含 Redshift 和 Glue 的数据仓库图”，而要用下面这种方式来说明：

• 来源：RDS、S3、Kafka、DynamoDB
• 采集路径：批处理、流式、CDC 或定时 ETL
• 转换：校验、模式映射、增强
• 目标：S3 lake、Redshift、Athena 或 OpenSearch
• 使用方：仪表板、分析师、ML 特征或告警

这种结构能帮助技能选对 stencil 和箭头。

先读最相关的示例

想最快上手，建议按下面顺序预览这些文件：

• SKILL.md
• examples/etl-pipeline.md
• examples/data-lake.md
• examples/data-warehouse.md
• examples/real-time-streaming.md
• examples/multi-source-bi.md

如果你的场景比较特殊，还可以继续查看 examples/cdc-pipeline.md、examples/log-analytics.md 或 examples/ml-feature-pipeline.md。这些示例展示了 data-analytics 技能如何处理异步流、仓库加载和特征工程等边界情况。

能明显提升输出质量的提示技巧

这个技能的好提示词，会提供足够的领域细节来避免图表过于泛化。要包含源系统、流转方式是批处理还是流式，以及数据“完成”时的状态。例如，“展示 PostgreSQL 中的每日订单进入 S3 Parquet，再通过 Glue ETL 进入 Redshift 用于 QuickSight 报表”，就比“画一条分析管道”好得多。

如果你想要更紧凑的结果，可以明确指定哪些阶段需要显示，哪些阶段要省略。这样能让图表更聚焦，也避免不必要的方框。

data-analytics 技能 FAQ

这只适合 AWS 图吗？

基本上是的。data-analytics 技能是围绕 mxgraph.aws4.* stencil 构建的，所以当架构里本身就包含 AWS 服务，或者你想使用 AWS 风格的分析符号时，它最合适。如果你的技术栈大多不是 AWS，它仍然可能可用，但输出会显得不那么自然。

它和普通提示词有什么不同？

普通提示词也能描述管道，但 data-analytics 技能把图表语法、流向和图标约定都编码进去了。当你想要稳定的 PlantUML 输出，而不是一次性的草图时，这一点很重要。对于 data-analytics usage 来说，这个技能更可复用，因为它会把模型往一致的结构上引导。

对新手友好吗？

友好，只要你能用自然语言描述自己的数据流。你不需要精通 PlantUML，但必须把主要阶段和端点说清楚。新手通常最容易拿到好结果的方法，是先复制一个示例模式，再把里面的系统替换成自己的。

什么时候该换别的技能？

如果你需要通用 UML、应用服务拓扑，或者厂商中立的云基础设施图，就应该用别的技能。data-analytics 最擅长的是数据的流动与转换，而不是应用部署本身。

如何改进 data-analytics 技能

先把业务目标交代清楚

最好的 data-analytics 结果，来自能说明图表用途的提示词。要写明受众是工程师、分析师还是管理层，以及这张图需要突出延迟、治理、成本还是报表。这会影响哪些阶段应该在视觉上更突出。

补充会影响设计的约束条件

如果管道里有 schema drift、迟到事件、合规边界或多个消费方，一定要提前说明。这些约束能帮助技能选择更有意义的元素，比如 crawler、catalog、staging bucket 或异步箭头，而不是简单的一条直线。

用具体输入和期望形态来描述

更强的输入通常长这样：

• “来自 Salesforce 和 PostgreSQL 的批处理 ETL 进入 S3，再进入 Redshift，带 Glue crawler 和数据质量门禁”
• “来自 Kinesis 的实时点击流先经 Lambda enrichment，再进入 OpenSearch 和 S3 archive”
• “来自 Aurora 和 DynamoDB 的 CDC 进入数据仓库，包含暂存和回放处理”

这些都比模糊请求更有效，因为它们定义的是路径，而不只是终点。

先检查最薄弱的阶段，再迭代

生成第一版图之后，优先检查最容易破坏可信度的部分：来源标注、转换命名，或 sink 选择。如果流程对了但范围太大，就把提示词收窄到单条管道。如果图是对的，但信息太少，就补上一个真正影响运维的阶段，例如目录编目、校验步骤，或 BI 消费方。