基于 StarRocks 的风控实时特征探索和实践

背景

金融风控特征是在金融领域中用于评估和管理风险的关键指标。它们帮助金融机构识别潜在风险，降低损失，并采取措施规避风险。例如，用户最后一次授信提交时间就是一个重要的金融风控特征。

金融风控实时特征场景是一个典型的大数据实时业务场景。为了应对这一挑战，风控团队采用了业界常用的 Lambda 架构和 Kappa 架构。对于7天内的实时特征，使用 Kappa 架构；而对于超过7天的特征，则采用 Lambda 架构。

实时特征的 Lambda 架构

在 Lambda 架构中，所有原始数据都来自同一个数据源（如日志、业务 Binlog等），然后分为两条链路进行处理。第一条是实时链路，通过流计算处理，将数据写入实时存储系统。第二条是离线链路，将数据处理并归档至 Hive。最后，在查询层根据特定逻辑合并离线数据和实时数据，然后将结果输出给应用方。为了提高吞吐量和并发性能，通常会在中间加入一层缓存。

然而，Lambda 架构也存在一些问题。首先，由于数据需要在多个系统中存储，因此会增加冗余存储的成本。其次，计算逻辑需要在流处理和批处理两个框架中分别实现和运行，导致开发成本较高。最后，由于计算逻辑分布在不同的框架中，因此在进行调试和问题排查时可能会比较复杂，从而增加了维护成本。

实时特征的 Kappa  架构

Kappa 架构可以被视为Lambda架构的简化版本，它去除了 Lambda 架构中的批处理部分。在 Kappa 架构中，消息队列被用作一种存储机制。当需要对数据进行修改或重新处理历史数据时，只需从消息队列中重新读取数据即可。这使得开发者只需维护一套流计算逻辑，从而降低了开发和运维成本。

然而，Kappa 架构也存在一些明显的问题。首先，其能够回溯的数据量受到消息队列存储能力的限制。其次，流处理的重新计算吞吐量较低，可能导致回溯时间过长，特别是当需要回溯的数据量较大时。

在金融风控部门，离线和实时特征的开发由两个不同的团队负责。这进一步放大了 Lambda 架构存在的问题。对于同时包含实时和离线特征的需求，业务人员需要向两个团队提出需求，这不仅增加了沟通成本，而且更难保证逻辑的一致性。特征产出的时间取决于两个团队中最后一个完成任务的时间，如果其中一个团队的任务出现延迟，那么整个特征产出的时间也会相应延长，即使所需的逻辑非常简单。在金融业务快速发展的背景下，这是一个亟待解决的问题。

尽管 Kappa 架构为解决这一问题提供了一种可能的解决方案，但由于其受到消息队列存储能力和数据回溯时间长度的限制，它仅适用于短期状态的场景。

Lambda 架构所引发问题的根本原因在于实时（流）和离线（批）处理是分开进行的。目前，业界普遍认为将流处理和批处理合并为一种统一的处理方式是解决问题的有效方法，即所谓的“流批一体”。因此，我们的研究目标是以尽可能低的成本找到实现流批一体的方案，以提高在实时和离线场景下特征开发的效率。

调研过程

在流批一体的研究方面，各大公司都有各自的探索方向。这些研究方向主要可以分为两类：计算统一和存储统一。计算统一旨在解决计算口径的统一问题，希望通过一套逻辑既能执行批处理又能执行流处理。而存储统一则旨在解决数据孤岛问题，防止同一份数据被分散存储在不同的存储引擎中。

计算统一方案

数据开发平台计算统一核心设计思路

上图展示了公司数据开发平台以计算统一实现流批一体的核心设计思路。该平台利用 Flink 同时支持流处理和批处理的能力，并与数梦平台的离线调度和实时运维相结合，使得一套 Flink SQL 既可以执行周期性的批处理任务，也可以持续地进行实时计算。

然而，这种方案实际上仍然依赖于流批分离的基础架构。虽然我们的流逻辑也是基于 Flink 实现的，但我们并没有使用 Flink 的内置窗口逻辑，而是实现了一个与管理系统紧密集成的更为灵活的窗口架构。此外，我们的批处理任务是基于 Spark 执行的。考虑到这种方案的修改成本较高，可能不适合解决当前风控面临的问题，因此我们最终没有选择使用这种方案。

存储统一方案

数据湖