企业官网建设流程全解析

很多企业一说“数据架构”，第一反应就是建数仓。

• ODS、DWD、DWS、ADS怎么分？

• 用Hive还是Doris？

• 实时链路要不要上Kafka、Flink？

这些都属于架构设计，但如果一开始就讨论技术组件，其实已经把顺序搞反了。

因为数据并不会凭空产生。

一笔订单为什么会出现？客户、商品、库存为什么会发生变化？利润指标为什么要这样计算？这些问题的源头都在业务。

所以完整的数据架构设计，实际上要把三层串起来：

业务架构决定企业在做什么，数据架构决定这些业务如何被数据表达，技术架构决定这些数据能力如何真正运行。

三层只要断掉一层，就容易出现“系统很多、数据很多、报表很多，但真正要分析问题时还是找不到可信答案”的情况。

正式展开之前，我整理了一份《数据仓库建设解决方案》，里面有数仓建设、数据治理、数据集成等内容，做数据相关工作的可以先收藏。

需要自取：https://s.fanruan.com/7igmg（复制到浏览器）

一、设计数据架构之前，先搞清楚企业到底在经营什么

很多数据项目第一步就是盘数据库：

ERP 300张表，CRM 200张表，MES 500张表……

然后按照系统结构开始建数仓。

问题在于：

系统结构并不等于业务结构。

以零售企业为例，可能同时存在商城、POS、CRM、ERP、WMS和财务系统。

从IT视角看，这是六套系统。

但站在业务视角，真正关心的其实是：

谁买了什么商品，通过什么渠道成交，库存发生了什么变化，这笔交易最后赚了多少钱。

所以数据架构真正的起点，应该按照：

业务域 → 业务流程 → 业务对象 → 业务事件

一层层拆。

例如销售域里有：

客户 → 下单 → 支付 → 出库 → 发货 → 签收 → 退款。

继续往下看，会发现客户、商品、订单、支付、仓库、物流这些都是核心业务对象；下单、付款、退款、出库则属于不断发生的业务事件。

这一步非常关键，因为后面的事实表、维度表、主数据甚至指标，本质上都来自这些对象和事件。

到了系统落地环节，还要继续把这些业务对象和真实的数据源一一对应起来：客户到底来自CRM还是ERP，订单落在哪套数据库，库存又由谁提供。

通过FineDataLink 5.0把数据库、接口、文件等不同来源接入同一套数据集成环境后，业务对象与实际数据来源之间的映射才能进一步落到具体的数据链路上，后续也不用每接一个系统就重新维护一套独立取数程序。

架构设计做到这里，关注点就已经从“企业有哪些数据库”变成了：

企业有哪些稳定的业务事实，这些事实分别记录在哪里。

二、业务架构解决的，是“企业到底怎么运转”

业务架构经常被误认为组织架构。

两者其实关注的事情完全不同。

组织架构回答：

谁负责？

业务架构回答：

业务如何发生？

部门可能一年调整几次，但一家企业真正稳定的业务能力不会频繁变化。

制造企业长期都有采购、生产、库存、销售、交付；

零售企业长期都有商品、会员、交易、营销、履约。

所以做业务架构时，至少要梳理四件事。

业务域

先划清企业有哪些相对独立的业务领域。

例如：

客户域、商品域、交易域、供应链域、财务域。

核心业务对象

每个域里真正被管理的对象是什么？

客户域可能有客户、会员、等级；

交易域可能有订单、订单明细、支付、退款。

对象关系

• 一个客户可以产生多少订单？

• 订单和退款是什么关系？

• 商品和SKU是什么关系？

这些问题最终都会影响数据模型。

关键业务事件

下单、付款、退货、入库、出库、结算……

每发生一次事件，实际上都在制造新的数据事实。

所以业务架构真正应该交付给数据团队的，并不是一张漂亮的流程图，而是一套能够继续向下建模的：

业务边界 + 核心对象 + 对象关系 + 业务事件。

三、数据架构解决的，是“业务怎样变成可信的数据”

业务架构解决“发生了什么”，数据架构则要解决：

这些业务事实怎样被组织起来，并长期保持可用。

至少要考虑五层。

第一层：数据源

先回答：

• 客户数据到底谁是权威源？

• 商品编码以哪个系统为准？

• 订单状态发生冲突时相信谁？

• 库存到底取ERP、WMS还是门店系统？

这一层解决的是：

Source of Truth——谁代表企业最终事实。

第二层：数据集成

知道数据在哪，还要决定怎么拿。

这里千万不能一刀切。

5000行地区编码表，一个月变化几次，每天全量覆盖一次完全没问题。

几十亿行交易表，每天只有几百万条变化，再做全表扫描就会造成大量无效IO。

于是不同数据会对应不同策略：

全量、增量、CDC、API接入、文件采集、消息数据。

当这些方式同时存在时，最怕的就是每个系统各写一套脚本：这一套Python抽MySQL，那一套Shell导Oracle，另一套接口程序接SaaS，几年以后没人敢改。

在FineDataLink 5.0里，这些链路可以按照数据变化方式分别处理：

稳定的小表走定时任务，持续变化的数据进入实时任务或管道，需要实时捕获的数据库变化则沿CDC链路进入下游。重点并不是强行把所有数据做成实时，而是让同步策略真正匹配数据自身的变化频率。

第三层：数据分层

数据进入平台以后，还要确定每一层承担什么职责。

典型结构可能是：

ODS → DWD → DWS → ADS

• ODS保留源端事实；

• DWD完成清洗、标准化和明细建模；

• DWS沉淀跨业务复用的主题数据；

• ADS服务具体分析场景。

这里最重要的并不是有没有“四层”。

如果一张表只是从ODS复制到DWD，再复制到DWS，字段几乎没有变化，那只是复制了三遍数据。

真正的分层应该伴随着：

口径收敛、粒度变化、业务语义增强和复用范围扩大。

第四层：数据模型

到了这一层，要开始回答更难的问题。

• 一笔订单的粒度是什么？

• 订单头和订单明细要不要拆开？

• 客户等级变化以后，历史订单按当时等级还是当前等级统计？

• 商品价格修改以后，历史价格需不需要保留？

这些问题看似是表结构设计，背后其实都对应业务规则。

第五层：指标和数据服务

模型最终还要转化为业务能使用的东西：

收入、毛利、库存周转率、复购率、客单价……

再通过报表、API、数据服务或分析平台提供给业务。

到这里，数据架构才真正闭环：

源系统 → 数据集成 → 数据分层 → 数据模型 → 指标 → 数据服务。

四、技术架构解决的，是“这套东西能不能长期跑”

很多所谓“技术架构图”，最大的特点就是Logo特别多。

MySQL、Kafka、Flink、Redis、Hive、Doris全部放进去，看起来很复杂。

但技术架构真正应该回答的不是“用了多少技术”，而是：

这套数据体系怎样稳定运行。

至少要考虑四个问题。

第一，时效性

业务到底需要T+1、小时级、分钟级还是秒级？

财务月结数据没必要秒级更新；

库存预警可能需要分钟级；

风控和设备状态可能进一步要求实时。

时效要求不同，技术成本可能完全不是一个量级。

第二，可恢复性

• 数据库突然断开怎么办？

• 任务跑到80%失败，是全部重跑还是从中断位置继续？

• 一条链路挂掉，会不会影响其他任务？

第三，Schema Change

这个问题尤其容易被忽略。

业务系统今天新增一个coupon_amount字段，明天把INT改成BIGINT，下游数据链路怎么办？

如果源表结构发生变化以后没人感知，就可能出现一种更危险的情况：

任务一直显示成功，新字段却根本没有进入数仓。

FineDataLink的实时管道已经把这类变化纳入链路管理，部分来源和目标可以针对源表增删字段、字段类型等结构变化进行处理；对于持续运行的实时链路，还可以进一步做源端与目标端的数据一致性检测。这样架构关注的就不只剩“任务有没有跑完”，还能够继续检查最终数据有没有真正对上。

第四，可扩展性

今天每天100万条数据，明年可能就是1亿条。

今天10个系统，收购两家公司以后可能变成30个。

所以技术架构不能只满足“现在跑得动”，还要给未来的数据规模、系统数量和业务变化留下扩展空间。

五、业务架构、数据架构、技术架构到底怎么接起来？

理解三种架构最简单的方法，就是顺着一个业务问题往下走。

假设业务问：

为什么最近某些商品经常缺货？

第一层是业务架构。

先确认涉及：

商品、门店、仓库、采购、销售、调拨。

还要理解整个补货流程：

销售消耗库存 → 库存下降 → 触发补货 → 生成采购或调拨 → 商品重新入库。

第二层进入数据架构。

为了分析缺货，需要找到：

销售订单、库存流水、采购订单、商品主数据、仓库数据。

然后继续定义：

什么叫缺货？

库存等于0就算，还是可售库存低于安全库存就算？

一天缺货三次算一次还是三次？

这些都是数据口径。

第三层才轮到技术架构。

• 库存多久同步一次？

• 每天同步显然太慢，那么是五分钟增量，还是直接捕获数据库变化？

• 数据写到哪里？

• 异常以后怎么恢复？

一条业务问题，就这样一路从业务进入数据，再进入技术。

到了真正执行的位置，FineDataLink 5.0连接的恰恰是中间这段：

上游面对ERP、CRM、WMS等业务系统产生的数据，下游连接数仓、数据库和实时分析链路。业务架构确定“哪些数据重要”，数据架构确定“这些数据怎么组织”，随后再把全量、增量、实时以及不同去向配置成实际运行的数据流。对于数仓场景，同一条实时数据流还可以分发到不同处理结果或不同数仓层。

所以三种架构真正的关系可以概括成：

业务提出问题 → 数据表达问题 → 技术实现数据能力。

六、真正做架构时，建议按照这个顺序推进

很多企业的数据建设之所以越来越重，往往是顺序反了。

• 先买技术平台；

• 再开始搬数据；

• 数据搬完以后才去问业务想看什么。

最后数仓里几千张表，真正稳定使用的却没有多少。

更合理的顺序应该是：

第一步：找到核心业务问题

先确定企业真正想解决什么。

• 库存高？

• 毛利下降？

• 客户流失？

• 供应链效率低？

第二步：拆业务对象和流程

确认问题背后涉及哪些业务对象，以及这些对象如何发生关系。

第三步：确定数据来源

找到每个业务对象对应的系统和权威数据源。

第四步：设计数据流

• 哪些需要全量？

• 哪些可以增量？

• 哪些必须实时？

• 数据最终进入哪里？

第五步：设计模型和指标

统一粒度、维度、事实、主数据和指标口径。

第六步：最后确定技术方案

再决定用什么数据库、什么计算引擎、什么同步方式、什么部署架构。

这个顺序最大的好处是：

每一个技术组件，都能找到对应的业务理由。

而不是因为市场上某项技术很热门，就先塞进自己的架构图。

结语

真正成熟的数据架构，从来不只是画一张系统拓扑图。

它应该能够从任何一个经营指标，一直向下解释：

• 这个指标代表什么业务？

• 由哪些业务事实组成？

• 数据来自哪些系统？

• 经过了哪些加工？

• 为什么采用这样的时效和同步方式？

• 最后又由什么技术保证它稳定运行？

如果这些问题能够一路回答清楚，业务架构、数据架构和技术架构才真正连成了一套体系。

所以设计数据架构时，可以始终抓住一条主线：

先理解业务，再组织数据，最后选择技术。

工具和技术会持续变化，但企业的核心业务对象、数据关系以及管理问题相对稳定。

一套好的数据架构，最终也不是让架构图看起来有多复杂。

而是当业务提出一个问题时，你能够清楚知道：

这项业务事实从哪里产生，经过哪里，又怎样一步一步变成可以被分析和决策使用的数据。