数据架构怎么设计？业务架构、数据架构、技术架构一次讲透

假设一家工厂，同一天有三张日报。

同一种成品，生产报工1000件，质检合格940件，仓库入库920件。老板看着三张表，问了一句：昨天到底做出了多少件？

先别急着判定哪套系统的数据有问题。假定这家工厂的规则是完工后先检验，合格品再办理入库，而且三张报表统计的是同一批产品。那么这三个数字可能同时成立：1000件完成了生产工序，其中940件通过检验；合格品里还有20件尚未办完入库。另有60件需要返工或按不合格品处理。

生产经理要看产线完成量，质量经理要看合格量，销售要确认能否安排发货。大家说的都是“产量”，问的却是三件事。

数据架构的设计，往往就从这种分歧开始。它要让一项业务事实从产生、记录、加工直到被使用，每一步都说得清楚。要做到这一点，得把业务架构、数据架构和技术架构接在一起。

一、先分清三种架构各管什么

还是这1000、940、920件。

业务架构先回答：这家工厂怎样完成“生产到交付”？工单由谁下达，车间何时算完工，谁判定合格，仓库在什么条件下接收，销售又能依据哪一个状态承诺客户。

它关注的对象是工单、产品、批次和库存，关注的动作是报工、检验、返工、入库、发货。部门名称可以调整，但这些业务动作之间的关系不能靠换一张组织架构图来说明。

数据架构接着回答：每个动作留下什么记录，记录之间靠什么关联，哪条记录可以用来回答哪一个问题。完工记录能说明车间做完了多少；检验结果说明其中多少合格；入库记录说明仓库接收了多少。把三种记录都命名为“成品数量”，后面的报表必然吵起来。

技术架构负责让这些记录按要求持续流转。MES中的完工数据怎样到分析平台，质量结果更新后怎样补进来，仓库重复推送一笔入库单时怎样避免重复计算，链路中断后怎样恢复。

这三层的关系可以用一句话记住：业务定义事实何时发生，数据定义事实怎样表达，技术保证表达能够按时、可靠地交到需要它的人手里。

顺序上，先弄清业务问题，再建数据模型，最后决定实现方式。但它不是一条只能向前走的流水线。如果业务要求五分钟内看到可发货数量，而源系统一天才汇总一次，就得回到业务侧讨论是改采集方式，还是调整时效要求。

二、业务架构，先把“算完成”的时点讲清楚

做业务架构，很多团队习惯先列系统：ERP管计划，MES管生产，QMS管质量，WMS管仓库。系统清单有用，却还回答不了老板那句话。

更有效的办法，是顺着一批产品往前走。

生产工单下达后，车间按工序生产；末道工序完成，人员报工；质量部门按规定检验；不合格品进入返工或处置；合格品交仓库办理入库。至于企业是先入待检库存再检验，还是先检验再入库，必须以本企业的实际流程为准。两种做法对应的数据状态并不相同。

业务负责人至少要把四件事定下来。

第一，哪些事件会改变业务状态。在这家工厂，末道工序完成并确认报工后叫“已完工”，检验通过后叫“合格”，办理入库后叫“已入库”。状态不能因为某张报表需要一个数，就临时改定义。

第二，谁对事件负责。报工数量由车间确认，检验结论由质量部门确认，入库数量由仓库确认。发现差异时，才知道该找哪一环核实，而不是让数据团队在三张表里猜。

第三，例外怎么走。部分合格、返工后再次合格、跨天入库、撤销错误报工，都会改变最终统计。只画“完工→合格→入库”的直线流程，碰到第一笔返工就得靠人工改报表。

第四，哪个动作允许下一步发生。检验合格不等于已经能发货；即使入库，也可能被预留、冻结或占用。销售若要答复客户“明天能发多少”，还得看可用库存的规则。

做到这里，业务架构交出的就不止是一张流程图，而是一套可供数据团队建模的业务约定：对象、事件、状态、责任和例外。

三、数据架构，要让每个数字都能找回出处

有了业务约定，才轮到设计数据怎样记录和使用。

先确定一条记录代表什么。一张工单可能分多次报工，一次报工对应的产品可能分批检验，一批合格品也可能分两次入库。这就是建模时要说清的“记录粒度”。如果只用工单号把三类明细直接关联后求和，同一笔报工就可能被多条检验或入库记录重复计算。

所以完工、检验、入库应分别保存各自的业务明细，再通过工单号、产品编码、批次等经过核对的关联键串起来。报表要统计“当日合格产量”，就从合格判定对应的记录及规则计算，不能拿完工量乘一个经验合格率。

再确定按哪个时间统计。晚上完成工序，次日上午检验通过，下午才入库。如果都按工单创建日期归到昨天，三张日报看似一致，却掩盖了真实的等待时间。完工时间、判定时间、入库时间应各自保留；数据到达分析平台的时间也要另记，方便排查延迟。

还要确定数值变化时保留什么历史。如果前述940件是首检合格，那60件里又有30件返工后通过，质量团队要看首检合格率，就不能用最新状态覆盖第一次检验结果；仓库要看当前可入库数量，又需要知道返工后的最终结论。同一批产品可以有多次事件，不能只留一个不断被改写的“状态”字段。

最后才谈权威来源。没有一套系统能替所有事实作证：车间完工看经确认的报工记录，质量结论看检验记录，实物接收看入库记录。主数据也要定归属，例如产品编码和计量单位由谁维护，MES、QMS、WMS怎样使用同一套标识。否则1000“件”和940“套”连比较的基础都没有。

数仓分层可以帮团队组织这些数据。原始接入层保留可追溯的源记录，明细层统一编码、时间和状态，汇总层形成可复用的产量与质量指标，应用层服务具体报表。业内常用ODS、DWD、DWS、ADS称呼这些层，但不必为了凑齐四个缩写，把同一张表原样复制四遍。每多一层，都应说得出它解决了哪类口径、粒度或复用问题。

检验数据架构有没有设计好，可以问一个很朴素的问题：老板看到“合格产量940件”，能否一路查回哪些工单、哪些批次、哪些检验结论构成了这个数？查不回去，数字再整齐也难以让人放心。

四、技术架构，重点看出错以后怎么办

到了技术层，数据库、消息队列、实时计算和BI工具才该上桌。选哪一种，先看业务要求。

生产日报通常可以按约定时间汇总；销售在接单前核查可用库存，可能需要更及时的数据；质量异常通知可能要在结果判定后尽快送达。三种用途不一定共用一条“全实时”链路。

真正要问的还有：数据漏了、重了、晚了，系统怎样处理？

比如一笔入库记录因网络中断被重复发送。技术架构若只保证“消息送到了”，报表就可能把920件再加上一遍这笔入库数量。链路应能根据单据和明细标识识别重复记录；失败后重试或补数，也不能把同一笔业务再加一遍。

再比如质检结果第二天才补录。日报已经发出，历史统计要不要重算？如果重算，要留下哪一次发布了旧数、哪一次完成了修正。这个决定涉及业务口径，技术团队负责实现和留痕，两边要一起定。

系统加字段、改编码或调整检验规则时，也不能只盯任务是否显示“运行成功”。要核对下游字段有没有接住、关键数量是否对得上、报表受影响的范围在哪里。权限同样如此：车间主管可以看本车间产量，质量人员可以追溯检验明细，跨部门共享时敏感字段按职责开放。

所以技术架构图除了组件，还应该标明数据从哪里来、多久更新一次、失败由谁发现、怎样补数、谁能使用。只贴工具Logo，无法判断这套系统能否长期运行。

五、拿一张“数据约定卡”，把三层真正接起来

如果企业准备启动数据项目，可以先选一个反复被问、但目前答不一致的问题，不必一开始就盘点全公司上千张表。

仍以“昨天合格成品有多少，今天能发多少”为例。开会时把下面几项写在同一张纸上：

业务问题：是考核生产合格量，还是答复客户可发货数量？这两个问题要分别命名。

业务时点：“昨天”按生产完工、质检判定还是仓库入库时间截取？跨天补录怎样处理？

记录粒度：一条记录是一笔报工、一次检验判定，还是一笔入库明细？工单、产品、批次用什么键关联？

责任来源：各项事实由哪个岗位确认、由哪套系统留存？编码或单位不一致时由谁修正？

使用要求：哪些岗位要看，最晚什么时候看到，出现重复、延迟或失败时通知谁、怎样重算？

验收办法：选几张包含部分合格、返工、跨天入库的工单，让业务人员从明细重新算出报表数字；再故意中断和重试一次链路，确认结果不会丢也不会重复。

这一张卡，前两项主要由业务负责人决定，中间两项由业务和数据团队共同确认，后两项把要求交给技术团队实现并一起验收。它把“业务架构→数据架构→技术架构”从一句口号变成了一组能检查的交付物。

三层也并非做完一层就永远封存。试运行时发现源系统没有记录返工的首次检验结果，就得补业务记录；发现批次编码关联不上，就得修数据模型；发现补数要等两天，便要调整链路或重新约定报表时效。

回到开头，1000、940、920这三个数字不必被强行改成同一个数。它们分别说明生产完成、质量通过和仓库接收到了哪一步。能解释清楚差了哪60件、哪20件，以及今天哪些货真正可以发，数据架构才算帮企业回答了问题。

设计数据架构，可以先从一次这样的追问开始：这个数字代表哪件业务事实，由谁确认，怎样记录，又能否在需要时重新算出来？