在日常业务中，我们经常需要根据一系列规则给数据“打标签”。比如，找出“过去30天销售额超过3000元的北京地区商家”。当数据量不大时，这很简单，一句SQL就能搞定。但当数据量达到亿级，任何宽泛的规则查询都可能成为数据库的不可承受之重，导致服务雪崩。

最近，我们正好做了这么一个功能，让用户可以自由组合各种规则来给海量数据打标。核心目标就一个： 既满足需求，又保证数据库不崩 。它并非用了什么高深莫测的技术，而是通过对现有技术组件的合理组合与职责划分，实现了性能与稳定性的平衡。

核心思路：把“繁重”的活儿搬个家

这个设计的核心思想很简单： 别在生产线（生产数据库）上做大数据分析 。

想象一下，超市的收银台（生产数据库）负责处理顾客的实时交易。如果要求收银员同时分析所有商品的销售趋势来计算应该给哪些顾客发优惠券（规则打标），那结账队伍早就排到门外了。

正确的做法是：把每天的销售数据同步到后台办公室（数据仓库），由专门的分析员（计算引擎）来慢慢计算优惠券名单。我们的系统架构正是遵循了这一逻辑。

系统架构：四层协作，各司其职

整个系统的数据流转和处理过程，可以用下面这张图来清晰地展示：

步骤一：数据同步 (离线，提前干)

• 我们有个定时任务，在凌晨业务不忙的时候，把生产数据库的数据同步一份到大数据平台。这样，所有需要计算的数据都已经提前准备好了。

步骤二：规则计算 (在“后厨”进行)

• 用户在页面选好条件（比如“销售额>3000且城市=北京”），系统会生成一条SQL。
• 这条SQL被发往大数据平台执行，找出所有符合条件的商家ID。
• 输出结果很简单 ：规则A -> [商家ID1, 商家ID2, ...]

步骤三：建立索引 (更新“索引簿”)

• 把上一步计算出的“规则-商家ID”对应关系，同步到图数据库。这里非常适合存储和查询这种“谁和谁有关”的信息。

步骤四：前端查询 (高效协作)
当用户在前端查看打标结果时：

1. 前端传过来：“我要看规则A的第2页”。
2. 应用服务先问图数据库：“规则A的第2页，有哪些商家ID？”
3. 图数据库瞬间返回一页ID，比如[101, 102, 103 ... 120]。
4. 应用服务再拿着这20个ID，去生产数据库里一次性拉取它们的详细信息（名称、地址等）。用主键ID批量查询，对生产数据库来说是小菜一碟。

总结一下

这个架构并没有发明什么新技术，它的高明之处在于 “分解” 和 “分工” 。

通过将“规则匹配”这个复杂任务分解为“数据准备”、“离线计算”、“建立索引”、“查询详情”几个步骤，并为每个步骤分配合适的“专家”（ODPS、Geabase、MySQL）来处理，系统作为一个整体就变得既强壮又高效。