数据流图

数据流图

数据流图描述数据从哪来、经何处理、落到哪，适合支付与 ETL 链路。构图AI 可生成可编辑手绘数据流图。

登录可免费体验 1 次；VIP 期内不限制日常画图；导出 PNG / SVG / .excalidraw。

什么时候用

• 数据管道设计：埋点 SDK → 采集 → 清洗 → 数仓 → BI，需要全链路可见。
• 实时链路：应用日志 → Kafka → Flink → ES → Kibana，便于容量与延迟讨论。
• 跨团队对齐：业务、数据工程、分析师对「口径从哪来」达成一致。
• 合规与血缘：说明敏感字段经过哪些系统，便于审计与权限设计。

不适合替代表结构细节（ER 图），也不适合替代接口时序（时序图）。纯业务审批步骤用流程图更合适。支付资金流、推荐特征流也可按数据流视角绘制，只要强调的是「数据对象如何移动」。

核心元素

元素	说明
外部实体	用户端、第三方、源业务库，常用椭圆区分
处理节点	采集、清洗、聚合、写入等变换步骤
数据存储	主题库、数仓层、缓存、对象存储
数据流箭头	方向明确，旁注格式/协议与数据名
阶段分组	采集→处理→存储→消费分区框

阅读目标：一分钟内看懂源头、主干管道、最终消费方。箭头上尽量写「订单明细」「行为事件」这类数据名，而不是只写「调用」。

排版规则（数据流专用）

1. 从左到右或从上到下按阶段推进：采集→处理→存储→消费，符合阅读惯性。
2. 实时与批处理分框：两套链路不要箭头缠在一起，延迟预期才会一致。
3. 存储节点用不同形状或底色：与处理节点区分，血缘讨论时更快定位落点。
4. 外部系统放边缘：源业务库、第三方支付靠外，内部管道居中。

反例：把推荐系统画成「用户点赞吗？→是→更新分数」一堆菱形判断——那是业务流程图。数据流应写清「行为事件 → Kafka → 特征计算 → 特征库 → 召回/排序」，判断细节留给算法流程或时序。

Prompt 好坏对比

	示例	为什么
差	画数据流	无阶段无组件，无法落地
差	把数仓所有表都连上	失去管道焦点，变成 ER
好	画用户行为数据流：埋点 SDK→采集→清洗→数仓→BI，箭头标注事件 JSON	阶段完整、载荷清楚
好	画支付资金流：商户→支付渠道→清算→对账库，区分实时通知与日终批处理	实时/批处理边界明确

若涉及实时与离线两套链路，建议拆成两张数据流图，或在同一图用分组框标明「实时 / 批处理」。

常见错误

1. 画成业务流程图：充满「审批通过吗」类判断，却看不出数据落点与存储。
2. 箭头无载荷说明：读者不知道传的是日志、明细还是指标，联调与口径容易跑偏。
3. 阶段边界模糊：采集与数仓混在同一框，职责不清，排障时互相甩锅。
4. 与 ER 混画：一边是管道一边是几十张表字段，两败俱伤，应拆成两张图。
5. 忽略消费方：只画到数仓写入，不写 BI/风控/推荐谁在用，血缘不完整。

与相邻图类型的区别

维度	数据流图	流程图	时序图
主角	数据	活动步骤	参与者消息
判断菱形	少用	核心	偶发条件旁注
时间	流向阶段	执行顺序	严格自上而下
典型	ETL、埋点	下单履约	支付回调链

口径与延迟检查清单

数据流图评审时，建议逐箭头问三句话：传的是什么、多久到达、谁负责修口径。

1. 载荷：明细 / 日志 / 指标三者不要混称「数据」；箭头旁写清名字。
2. 时效：秒级、分钟级还是 T+1？实时框与批处理框必须分开标注。
3. 责任人：采集失败找谁、清洗规则谁定、数仓主题域谁维护。
4. 敏感字段：手机号、证件号经过哪些节点，是否脱敏或落权限表。
5. 回溯：从 BI 指标能否沿箭头回到源事件？画不出血缘就还没画完。

支付资金流特别容易把「回调通知」和「日终对账」画成一条线——二者延迟与一致性完全不同，务必分框。可对照 支付资金流示例 与 推荐 Feed 示例 看阶段切法。

画推荐或增长管道时，记得标出「特征」与「样本」是否同源：训练链路与在线推理链路不一致是常见事故。可在图上用两条并行管道表示离线训练与在线服务，比单线来回箭头更清楚。

用构图AI怎么画

选择「数据流图」，按阶段描述，例如：「画用户行为数据流：埋点 SDK → 采集 → 清洗 → 数仓 → BI」。或「日志：应用 → Kafka → Flink → ES → Kibana」。生成后补格式标注与外部系统，再导出。可对照支付资金流、推荐相关示例看阶段切分。

构图AI 共 12 种技能，可与 ER 图、架构图配合：ER 定模型，架构定组件，数据流定管道。

相关：支付资金流示例 · 推荐 Feed 示例 · 示例库 · 使用此技能画图