在以前写过的一篇关于游戏策划配置检查工具设计的文章里，笔者讲述了一种表格检查工具的分层设计方法，简而言之也就是两部分：
- 配置数据源服务：管理本地策划配置
repo，通过自定义脚本解析repo中文件，提供实际的配置数据 - 配置数据处理服务：处理实际的配置测试业务，比如表格检查、
excel-diff等等
其中，配置数据源服务，在许久以前写过一个样例的版本repomaster，
实际也就是一个管理git-repo的小服务，在这篇博客里有详细阐述实现内容。
而今天的主题则是配置数据处理服务方面的内容，笔者采纳通过配置化方式声明数据处理过程的设计，编写了一个数据聚合工具：daggre，全称为DAta-AGGREgator，专门用于处理数据的联表视图、过滤检查相关的需求。
以游戏业务测试为例，daggre的使用场景，我们可以看两个例子：
第一个例子，是针对一些游戏内置的商店配置，在功能提测的过程中，游戏测试同学需要验证商店实际的配置和策划的运营配置方案是否相符。对于商店的配置，可能会涉及到很多表格的连接，包括：
- 集市配置：所有类型的集市，以及关联的商店列表
- 商店配置：所有类型的商店，以及关联的商品列表
- 商品配置：所有商品的配置，包括关联的物品、上架时间、折扣、一捆的数量、是否绑定等配置
- 物品配置：所有物品的列表
如果没有一个完整的视图去把这些配置联接在一起，仅仅是一个个表格切换着来检查的话，是非常麻烦的。通过lookup步骤，可以将两个表格的数据通过一个特定的字段映射进行联接，从而使得不同表格的数据记录可以串联在一起，这样就能够形成一个集市->商店->商品->物品的完整视图，从而测试人员能够更加清晰看到每一个商品具体配置的细节。
第二个例子，是配置规则的检查，针对不同的游戏业务模块，需要制定特定的检查规则，来验证或是监控策划配置内容是否不够合理，好比说针对带敏感词文案，或者是物品弹出按钮跳转UI的关联配置等等。通过filter步骤，可以实现字段值的筛选逻辑，从而能够满足这类需求。在daggre中，不论是lookup还是filter之类的步骤，都已经做了简单的实现，基本上是呈现了mongodb聚合里面的效果。
在数据处理的实际设计上，daggre定义了几个概念：
- 数据集
data：相当于一系列table/collection的集合，每个表格有独立的名字 - 聚合规则
aggregation：声明整个数据处理的规则，包括所有数据处理流水线，以及唯一的一个主流水线 - 流水线
pipeline：声明初始数据由哪些表格合并而来，以及具体经过哪些处理步骤
聚合规则最终输出的是主流水线的数据，而支流水线可以通过lookup步骤合并到主流水线的表格数据当中。通过声明data和aggregation，经过一系列流水线步骤，就能生成所有流水线的执行统计stats，以及最终处理后的output表格数据。
流水线步骤，除了默认的filter、lookup、unwind等常用的这些，开发者也可以按照流水线步骤的接口实现约定，自定义自己需要的流水线步骤实现。具体详情，可以参考daggre的README以及源代码。