整个平台的基本实现原理很简单，就是将我们的审核对象（目前支持四种），通过规则集进行筛选。符合规则的审核对象，都是疑似有问题的。平台会将这些问题及关联信息提供出来，供人工甄别使用。由此可见，平台的功能强大与否，主要取决于规则集的丰富程度。平台也提供了部分扩展能力，方便扩展规则集。
4、平台设计审核对象
在开始介绍平台实现之前，再来熟悉下“审核对象”这个概念。目前我们支持的有四类对象，分别说明一下。
对象级。这里所说的对象就是指数据库对象，常见的表、分区、索引、视图、触发器等等。典型规则，例如大表未分区等。
语句级。这里所说的语句级，实际是指SQL语句文本本身。典型规则，例如多表关联。
执行计划级。这里是指数据库中SQL的执行计划。典型规则，例如大表全表扫描。
执行特征级。这里是指语句在数据库上的真实执行情况。典型规则，例如扫描块数与返回记录比例过低。
需要说明一下，这四类审核对象中，后三种必须在系统上线运行后才会抓取到，第一种可以在只有数据结构的情况下运行(个别规则还需要有数据)。
此外，上述规则中，除了第二类为通用规则外，其他都与具体数据库相关。即每种的数据库，都有自己不同的规则。
架构简图
这里画出是系统架构框架简图，我简单说明一下。
图中的方框部分，为平台的主要模块。底色不同的模块，表示当前的进度状态不同。虚线代表数据流，实线代表控制流。其核心为这几个模块：
数据采集模块。它是负责从数据源抓取审核需要的基础数据。目前支持从Oracle、MySQL抓取。
OBJ/SQL存储库。这是系统的共同存储部分，采集的数据和处理过程中的中间数据、结果数据都保存在这里。其核心数据分为对象类和SQL类。物理是采用的MongoDB。
核心管理模块。图中右侧虚线部分包含的两个模块：SQL管理和OBJ管理就是这部分。它主要是完成对象的全生命周期管理。目前只做了简单的对象过滤功能，因此还是白色底色，核心的功能尚未完成。
审核规则和审核引擎模块。这部分是平台一期的核心组件。审核规则模块是完成规则的定义、配置工作。审核引擎模块是完成具体规则的审核执行部分。
优化规则和优化引擎模块。这部分是平台二期的核心组件。目前尚未开发，因此为白色底色。
系统管理模块。这部分是完成平台基础功能，例如任务调度、空间管理、审核报告生成、导出等功能。
流程图
让我们从处理流程的角度，看看平台的整体处理过程。
1) “规则管理”部分，这部分主要完成以下一些功能。
初始化规则。平台本身内置了很多规则，在这一过程中到导入到配置库中。
新增规则。平台本身提供了一定的扩展能力，可以依据规范新增一条规则。
修改规则。可以根据自身情况开启或关闭规则。对于每条规则，还内置了一些参数，也可在此处修改。此外，针对违反规则的情况，还可以设置扣分方法（例如违反一次扣几分、最多可扣几分）等。
规则本身及相关参数、配置信息等都会存储在配置库中。
2) “任务管理”部分，这是后台管理的一个部分，主要完成与任务相关的工作。系统中的大多数交互都是通过作业异步完成的。其后台是通过celery+flower实现的。
3) “数据采集”部分，这部分是通过任务调度定时出发采集作业完成，也有少量部分是实时查询线上库完成的。采集的结果保存在数据库中，供后续分析部分调用。
4) “规则解析”部分，这部分是由用户通过界面触发，任务调度模块会启动一个后台异步任务完成解析工作。之所以设计为异步完成，主要是审核工作可能时间较长（特别是选择审核类别较多、审核对象很多、开启的审核规则较多）的情况。审核结果会保存在数据库中。