数据分析设计模式

在我们日常的架构设计中，除了在线的交易处理之外，往往还有一类异步的数据分析能力需求。对于这类的需求，我们有几种设计模式可以选择。

这类需求具备如下几个特点：

• 首先，数据分析需求往往不会是核心链路的需求。也就是这类数据分析功能不会影响核心交易链路的执行。

• 其次，数据分析需求的实效性一般不高，根据 case 的不同，可以接受从 1 分钟到 1 天不等的延迟。

• 第三，数据分析需求可以分成单笔和聚合分析两类。对于聚合分析，往往数据处理量比较大。

• 最后，数据分析需求往往需要具备重试的能力。

对于数据分析类的需求，我们根据实效性和数据量的不同，可以用不同的设计模式来应对。

• 实效性要求高、数据量小：这种一般是单笔的数据分析。

• 对于准实时的需求我们可以采用 Event Trigger 的模式实现，实时发送消息，应用监听消息进行实时分析。

• 对于可以有分钟级延迟的需求，我们可以采用高频定时任务的模式实现。

• 实效性要求高、数据量大：这种一般是实时小批量的聚合，我们可以引入流计算引擎来实现。比如 spark、flink 等。

• 实效性要求低、数据量小：这种一般是定时的数据分析需求，可以采用两种设计模式：

• 如果数据量极小，对于正常的交易几乎无影响，可以采用定时任务的模式来实现。

• 如果数据量对于正常交易还是会产生影响，可以采用数据同步+定时任务的模式来实现。就是通过 binlog、ETL 等将需要处理的数据抽取到离线库后，对离线库进行定时任务处理。

• 实效性要求低、数据量大：这种一般是 dashboard、报表类的需求，可以采用离线数仓+BI 报表的模式来实现。

在我们正在进行的「系统风险处置」项目中，有大量的数据分析工作：

• 首先，对于指标的分析。这类的分析分为两类，一类是对于交易的分析，另一类是对于用户数据的分析。

• 对于交易数据，实时性要求高，数据量不大，我们采用高频（分钟）定时任务的方式进行处理。

• 对于聚合类的用户数据，我们根据聚合频率的不同，对于小时/分钟级别的聚合，基于流计算引擎实现。对于天/月级的聚合，基于数仓实现。

• 其次，对于分析后产生的风险事件，需要对风险事件进行定级和分析。风险事件需要尽快被分析和处置。所以对于这部分，我们采用 Event Trigger 的方式，用风险事件 Event 触发相应的处理。

• 最后，对于风险事件的处理情况，我们需要有事后的统计报表。这类报表的目的主要是对风险事件的处理效率进行分析和跟踪，实效性要求不高。我们采用离线数仓+BI 报表的模式实现。

对于不同的实现模式，我们采用不同的方式保证处理的完整性：

• Event Trigger：消息持久化和保证送到机制。

• 定时任务：依据数据的状态进行重试处理。

• 流计算：多轮计算保证数据处理的完整性。

• 离线数仓：多次抽取保证数据的完整性。