别再把业务规则写死在SQL里了！换种更优雅的数仓设计

前段时间做数仓项目时，业务方提了一个看起来很小的需求：

“新增一条映射规则。”

开发同学看了一眼，说：

“简单，改下 SQL 就行。”

于是他打开任务，找到那段几百行的 CASE WHEN，新增一行，提交、发布、调度。

短期看解决了，但其实埋下了一个更大的坑。

因为过了一段时间，你会发现：

• SQL 变得越来越长

• 规则越来越多

• 谁也不知道规则写在哪

• 修改规则必须重新发布任务

很多数仓项目，最后都会变成这样：

SQL越来越复杂，而真正复杂的不是 SQL，而是“规则”。

那么，能不能把规则从 SQL 里拆出来，形成可管理、可维护、可复用的规则资产？

答案是：可以。

大多数数仓项目都是这样设计的：

ODS→ DWD → DWS → ADS

看起来很标准。

但问题是：业务规则通常直接写在 SQL 里。

例如

• 映射关系

• 替换逻辑

• 条件判断

• 标准化规则

例如

CASE WHENIFJOIN mapping_table

当规则数量很少时，这没有问题。

但随着业务增长，规则会越来越多。

于是 SQL 会慢慢变成这样：

 500行SQL +200行CASEWHEN +10个JOIN

而最麻烦的是：

规则无法管理。

常见问题包括：

业务新增一条规则，开发必须：

• 改 SQL

• 发布任务

• 重跑数据

其实只是加了一条映射。

很多业务规则其实是有版本的，例如：

2023规则2024规则2025规则

但如果规则写在 SQL 里：历史规则几乎无法回溯。

如果一个规则在多个任务中使用：

通常会出现：

同一段逻辑复制 N 次

最终带来的结果就是：

• 改一处，漏三处

• 逻辑不一致

• 维护成本越来越高

后来我们做了一个很简单的改造：把规则从 SQL 里拿出来。

增加一层：

ODS ↓规则资产层 ↓DWD

这层也可以理解为：Rule Layer（规则层）

它不负责存业务事实，而是专门负责：存储规则。

也就是说，原来写在 SQL 里的规则，统一搬到表里管理。

在这种设计里，规则不再是代码，而是数据。

例如一条映射规则：

e_name_A → f_name_Be_name_C → f_name_D

这些关系不再写在 SQL 中，而是存储在一张规则映射表里，例如：

dim_rule_mapping

表结构类似：

这样一来，规则就从“代码逻辑”变成了“数据资产”。

这一步非常关键。

因为从这一刻开始，规则具备了被管理的可能性。

当规则被抽出来之后，SQL 的职责就会发生变化。

它不再负责“定义规则”，而只负责“执行规则”。

原来的模式是：

SQL = 数据逻辑 + 业务规则

改造后的模式是：

SQL = 执行引擎规则 = 数据资产

整体计算逻辑就变成了：

数据 + 规则 → 计算结果

举个最简单的例子：

e_name   ↓rule_mapping   ↓f_name

在这个链路里：

• 数据负责提供原始对象

• 规则负责提供映射关系

• SQL 只负责把两者连起来

这就是“规则驱动”的核心思想。

为了让规则真正可管理，规则资产层通常至少包含 4 类表。

用于定义系统中有哪些规则。

例如：

• 规则编码

• 规则名称

• 规则类型

• 规则状态

它回答的问题是：

系统里有哪些规则？

用于管理规则版本。

例如：

• release_id

• rule_code

• version

• 生效时间

它回答的问题是：

这条规则现在使用的是哪个版本？

用于定义规则作用于哪些数据范围。

例如：

• 来源系统

• 目标系统

• 适用范围

• 是否启用

它回答的问题是：

这条规则作用于哪些数据？

这是最核心的一张表。

用于存储具体的映射关系，例如：

• PROPERTY 映射

• CATEGORY 映射

• NAME 映射

它回答的问题是：这条规则到底怎么转换？

传统数仓更像是：SQL 驱动。

因为所有规则都写在 SQL 里，SQL 既负责处理数据，也负责定义业务规则。

这样做的问题是：

• 规则和计算耦合过深

• SQL 变更频繁

• 系统越来越难维护

而引入规则资产层之后，数仓会发生一个本质上的变化：

从 SQL 驱动，走向规则驱动。

这带来了几个非常明显的收益。

1）规则可配置

新增一条规则时，不再需要改 SQL，而只需要新增一条规则数据。

2）规则可版本化

同一条规则可以有多个版本，历史版本也可以回溯。

3）规则与计算解耦

SQL 不再关心规则是什么，只负责执行规则，整体结构会清晰很多。

4）规则可以复用

同一套规则可以在多个任务中共享，避免逻辑复制。

本质上，这是一种范式转换：

从 SQL 驱动      ↓到 规则驱动

规则变成了：

可管理、可配置、可版本化、可复用的数据资产。

而 SQL，只是规则执行引擎。

很多复杂的数据平台，真正难维护的地方，不是数据量，也不是 SQL 能力。

而是：规则没有被管理起来。

一旦业务规则越来越多，而这些规则又散落在几十个 SQL 任务里，系统就会越来越脆弱：

• 一改就怕

• 一查就乱

• 一复用就复制

• 一回溯就失效

从表面看，这是 SQL 复杂度问题。

但本质上，这是：规则管理问题。

所以，真正有价值的改造，不一定是把 SQL 写得更复杂，而是把规则从 SQL 里解耦出来。

如果你正在做数仓，建议认真想一个问题：

你的规则，是写在 SQL 里，还是沉淀在数据里？

这两种方式，决定了你的数仓最终会走向两种完全不同的维护状态：

一种是：规则越来越散，SQL 越来越重。

另一种是：规则被资产化，计算被标准化。

说到底，复杂系统要长期可维护，不是靠把 SQL 写得更长。

而是靠：把规则管理得更清楚。

当你把规则从 SQL 里拿出来，变成一层可配置、可版本化、可复用的规则资产，数仓才真正开始具备“工程化能力”。

很多复杂的数据平台，其实只差这一层：规则资产层。