供应链知识图谱

当供应链风险在暗处传导我们需要一张看得见的图谱项目地址Supply Chain Graph一个真实场景你的核心企业启明智造依赖一级供应商华芯精密供应主控芯片而华芯精密的某条产线突然贴出了停产预警。这条风险信号什么时候能传到你的采购总监桌上传统答案是等供应商主动通知你。更现实的情况是——你根本不知道华芯精密和这条产线有关因为你和它之间隔了两层物料编码和三张采购订单。风险是沿着供应链的关系网络传导的但你看到的只是一张扁平的供应商清单。这就是 Supply Chain Graph 要解决的问题把供应链的关系结构画出来让风险的传导路径一目了然。它是什么一句话定义Supply Chain Graph 是一个面向采购供应链风控场景的可视化工作台以知识图谱的方式呈现供应商、物料、订单和风险事件之间的关系网络。它覆盖的核心场景包括场景解决什么问题供应商准入多级供应关系的可视化审查识别隐性依赖风险穿透一个节点出事后沿关系链自动追溯影响范围税务风险管控标记异常供应商关联下游受影响订单断供预警单一来源物料识别交付延期风险量化技术上它是一个零构建依赖的静态单页应用——HTML5 CSS3 原生 JavaScript SVG 图谱渲染浏览器打开即用没有 Node.js、没有 Webpack、没有node_modules黑洞。为什么不用传统方案关系型数据库的困境大多数供应链系统的数据模型长这样SELECT*FROMsuppliersWHEREidIN(SELECTsupplier_idFROMsupply_recordsWHEREmaterial_idIN(SELECTmaterial_idFROMbomWHEREproduct_id主控芯片));查一层还行查三层就开始写嵌套子查询了。如果你想回答华芯精密停产下游哪些订单受影响、影响经过了几跳、中间经过了哪些物料和供应商——SQL 会变成一团不可维护的怪物。这就是经典的多跳关系查询问题。关系型数据库为行和列优化天然不擅长沿着关系链做递归遍历。图数据库的优势知识图谱的思维方式完全不同// 从风险事件出发沿供应关系向外扩散 3 跳找到所有受影响实体 MATCH path (r:Risk)-[:AFFECTS*1..3]-(affected) WHERE r.type 停产预警 RETURN path节点是实体边是关系查询语言直接表达沿着某种关系走几步。这种思维方式天然适合供应链场景。Supply Chain Graph 的前端实现虽然不依赖图数据库演示阶段用内存数据结构但它的数据模型和交互逻辑完全是图思维的——节点、边、遍历、路径。技术架构解读零依赖 SPA 的设计哲学打开项目目录你会看到├── index.html # 应用骨架 一级导航 ├── css/ # 24 个独立 CSS 文件按功能模块拆分 ├── js/ │ └── app.js # 597 行图谱数据 渲染逻辑 五个页面视图 └── .monkeycode/ ├── docs/ # 技术文档 └── specs/ # 需求与设计规格3 个 feature spec没有package.json没有构建脚本。index.html直接引入app.js浏览器加载后由 JS 完成所有视图切换和图谱渲染。这不是技术能力不足的选择而是一种刻意的架构决策部署简单Python 起一个http.server就能跑任何静态托管服务都支持加载极快没有框架运行时开销首屏只需解析一个 HTML 一个 JS可审计性强597 行 JS一个下午就能读完整个应用逻辑嵌入友好可以作为一个 iframe 模块嵌入现有 ERP 或 OA 系统为什么选择原生 JS SVG图谱渲染有两条路线Canvas 和 SVG。Canvas 是像素级的适合大量粒子动画SVG 是 DOM 级的每个节点和边都是独立的 DOM 元素。对于供应链图谱这个场景SVG 的优势很明显可交互性每个节点天然支持 click、hover、拖拽不需要自己实现命中检测可访问性节点可以绑定title、aria-label屏幕阅读器能读取样式控制通过 CSS 类切换风险等级颜色不需要重绘逻辑DOM 集成节点弹层、tooltip 可以直接用 HTML不需要额外的图层管理节点拖拽的实现采用了Pointer EventsrequestAnimationFrame的组合// 拖拽时通过 rAF 节流重绘避免高频 DOM 操作node.addEventListener(pointermove,(e){if(!dragging)return;requestAnimationFrame((){updateNodePosition(node,e.clientX,e.clientY);redrawEdges(node);});});这保证了即使图谱上有上百个节点拖拽交互依然流畅。核心功能走读图谱总览三种视图同一份数据图谱总览提供三种视图模式网络视图经典的力导向布局节点之间通过关系边连接适合观察局部聚类层级视图按供应商层级核心企业 → 一级供应商 → 物料 → 订单分层排列适合审查 BOM 结构地图视图将 1000 条供应链实体聚合到全国 27 个供应链城市按风险密度着色三种视图共享同一份数据模型切换视图只是改变了布局算法不需要重新加载数据。地图视图的实现值得关注——它以城市为聚合单位每个城市节点的颜色取该城市当前可见实体中的最高风险等级。这意味着如果深圳有 50 个实体其中 1 个是高风险深圳节点就显示为红色。这种聚合策略在信息密度和视觉清晰度之间取得了不错的平衡。风险穿透BFS 沿边追溯这是整个项目最有价值的功能。当一个风险事件如停产预警被标记后系统会沿关系边做广度优先遍历找出所有可能受影响的下游实体风险事件(停产预警) → 一级供应商(华芯精密) → 物料(主控芯片) → 订单(SO-240315) → 物料(功率模组) → 订单(PO-240862)算法的核心约束是每个节点最多进入结果集合一次。这避免了环状关系导致的无限循环——现实中A 供应 B、B 又供应 A 的情况并不罕见尤其是集团内部关联交易。具体的遍历逻辑functionriskPropagation(startNodeId,edges){constvisitednewSet([startNodeId]);constqueue[startNodeId];constaffected[];while(queue.length0){constcurrentqueue.shift();// 沿边的起点到终点方向遍历constoutgoingedges.filter(ee.sourcecurrent);for(constedgeofoutgoing){if(!visited.has(edge.target)){visited.add(edge.target);queue.push(edge.target);affected.push({node:edge.target,depth:visited.size,via:edge.label});}}}returnaffected;}这个实现简洁但有效——visited集合既防止了环状死循环又天然记录了遍历深度可以用于评估风险传导的距离。风险中心不只是看还要处置风险中心不只是展示风险列表它提供了一个完整的处置工作流待处置风险队列按 SLA 时效排列超期自动升级风险分类停产、税务异常、单一来源、交付延期区域聚集分析条形图展示各区域风险密度辅助判断是否存在区域性系统风险处置任务创建从风险事件直接生成处置工单进入闭环跟踪这种发现 → 分析 → 处置 → 闭环的链路设计是风控系统的核心骨架。很多工具只做到了发现但风控的价值最终要靠处置来兑现。分析报告用数据说话报告模块的核心是一组量化指标稳定指数供应链整体健康度的综合评分风险处置效果评估处置前后的评分对比、恢复金额量化近 7 日趋势风险信号数、SLA 达成率、数据质量评分、闭环率的时序变化统一数据导出CSV 格式覆盖风险队列、SLA 任务、评分规则、质量治理清单特别值得注意的是数据导出功能——它不是简单的导出当前视图而是按业务维度组织风险队列、SLA 任务、评分规则、质量治理清单这说明设计者考虑了数据在企业内部流转的需求。权限审计RBAC 不是可选项在供应链风控场景下权限审计不是 nice to have而是合规刚需。项目实现了标准的 RBAC 模型角色权限范围风险管理员风险处置、报告生成、数据源配置供应商协同组供应商信息查看、协同任务处理审计只读全部数据只读访问、操作日志查看、审计记录导出操作日志记录了每个用户的操作行为支持按时间、角色、操作类型筛选并监控数据访问合规率。审计记录可导出——这意味着系统可以直接对接企业内部的审计流程。数据模型设计Supply Chain Graph 的数据模型分为两层核心演示数据和模拟扩展数据。核心节点与边constprimaryNodes[{id:n1,type:company,label:启明智造,risk:medium},{id:n2,type:company,label:华芯精密,risk:high},{id:n3,type:company,label:东昇电子,risk:low},{id:n4,type:material,label:主控芯片,risk:high},{id:n5,type:material,label:功率模组,risk:medium},{id:n6,type:order,label:SO-240315,risk:high},{id:n7,type:order,label:PO-240862,risk:medium},{id:n8,type:risk,label:停产预警,risk:high},{id:n9,type:risk,label:税务异常,risk:high}];constedges[{source:n1,target:n2,label:一级供应,isRisk:false},{source:n1,target:n3,label:一级供应,isRisk:false},{source:n2,target:n4,label:生产物料,isRisk:false},{source:n4,target:n6,label:订单关联,isRisk:false},{source:n8,target:n2,label:风险影响,isRisk:true},{source:n8,target:n4,label:风险传导,isRisk:true}];节点类型覆盖四种company企业、material物料、order订单、risk风险事件。每条边携带关系标签和风险标记isRisk风险边在图谱中以不同样式渲染直观区分正常供应关系和风险传导路径。1000 条模拟实体为了驱动地图视图和层级视图项目通过一个确定性实体生成器生成了 1000 条模拟数据类别数量说明企业400 家覆盖一、二、三级供应商物料250 项芯片、模组、结构件等订单230 张含正常交付和延期交付风险事件120 个停产、税务异常、交付延期等这些实体分布在 27 个供应链城市覆盖华东、华南、华中、华北、西南、西北、东北七大区域。生成器是确定性的——同样的种子永远产生同样的数据这保证了演示的可复现性。从演示到生产API 设计建议当前的演示版本用内存数据驱动但项目文档中已经给出了清晰的生产接入路径。以下是建议的 RESTful API 设计图谱数据接口GET /api/graph?typecompany,riskriskLevelhighkeyword华芯返回按筛选条件过滤后的节点和关系集合。前端拿到数据后直接灌入现有的 SVG 渲染引擎不需要改动视图层逻辑。风险队列接口GET /api/risks?statuspendingregion华东返回风险队列和聚集统计。支持按状态和区域过滤对应风险中心的待处置列表和区域聚集条形图。数据源管理接口GET /api/data-sources # 获取数据源列表和同步状态 POST /api/data-sources/:id/sync # 发起数据源同步任务数据接入模块已经定义了三种数据源类型ERP 系统、电子发票解析、外部风险数据。这些接口让数据源的配置和同步可以被前端直接管理。报告接口GET /api/reports # 获取报告列表 POST /api/reports # 创建报告生成任务报告的生成通常是异步的涉及大量数据聚合计算POST 接口返回任务 ID前端轮询或 WebSocket 接收完成通知。图数据库接入路径从内存数据结构迁移到真正的图数据库推荐路径Neo4j最成熟的图数据库Cypher 查询语言与现有的 BFS 遍历逻辑高度吻合NebulaGraph国产开源图数据库性能优异适合大规模供应链图谱TigerGraph内置并行图算法适合实时风险穿透分析迁移的核心工作是将primaryNodes和edges映射为图数据库的节点和关系将 BFS 遍历逻辑替换为图数据库的原生查询。前端的渲染层和交互层几乎不需要改动。几个值得借鉴的设计思考1. 零依赖不是简陋是克制在一个 npm 包动辄几百 MB 的时代一个 597 行 JS 24 个 CSS 文件的项目实现了完整的五页应用——图谱总览、风险中心、数据接入、分析报告、权限审计——这本身就是一个声明复杂性不是技术能力的证明控制复杂性才是。2. 图谱的三种视图是产品思维很多图谱项目只提供一种力导向布局然后告诉用户自己拖拽探索。Supply Chain Graph 提供了网络、层级和地图三种视图对应三种不同的认知需求看关系结构、看供应层级、看地理分布。同一份数据三种理解方式——这是产品思维不只是技术实现。3. 风险穿透 SLA 处置 闭环只做风险发现不做处置跟踪的系统是半成品。Supply Chain Graph 从风险发现、穿透分析、处置任务创建到 SLA 时效管理形成了一条完整的闭环。这种发现-分析-处置-度量的链路设计才是风控系统真正产生业务价值的地方。4. 确定性模拟数据1000 条模拟数据用确定性生成器而非随机数这是一个容易被忽视但很重要的设计决策。它意味着演示可复现、截图可对比、问题可调试。在 toB 产品的演示场景中这个特性远比看起来更真实重要。效果图展示管理驾驶舱图谱总览风险中心数据接入分析报告权限审计写在最后供应链风控的核心难题不是如何检测风险而是如何理解风险的传导路径。一个供应商出了问题不可怕可怕的是你不知道它会影响哪些订单、哪些客户、哪些产线。Supply Chain Graph 用一种轻量但完整的方式回答了这个问题用知识图谱建模供应链关系用 BFS 算法追溯风险传导路径用 SVG 可视化让路径看得见用 RBAC 和审计日志让操作可追溯。它现在还是一个前端演示项目但数据模型、交互逻辑和 API 设计已经为生产环境做好了准备。如果你正在思考如何为供应链系统增加风控可视化能力这个项目的架构思路和实现方式值得一看。仓库地址https://gitee.com/zuoyidk/supply_chain_graph