1.3.4 数据流架构

数据流架构关注的对象是数据从端（输入端）到端（输出端）的实现过程。数据流架构设计主要解决以下两个问题。

• 数据流在不同场景下如何流动，前置依赖条件、核心处理过程是什么。

• 如何在物理架构、逻辑架构和技术架构的支撑下实现数据流结果的输出。

数据流的核心逻辑与逻辑架构类似，区别在于，当涉及算法和模型时，基于不同的计算状态，数据流会呈现3类差异化实现方式：全量数据与批量计算、增量数据与增量计算、流数据与流式计算。

1.全量数据与批量计算

在算法类项目中，批量计算的数据范围是过去一段周期内的数据（如果是所有历史数据，就是全量数据），因此计算耗时长、资源需求量大，但也会得到更加准确的模型结果，更利于深度规律的挖掘。批量计算的算法模型可持久化到硬盘，后续可供增量训练和在线服务使用。因此，模型相关的批量计算一般都以天为单位进行。

在数据流架构中，批量计算是一条单独的数据流，环节包括数据源、数据同步和清洗、数据存储、数据计算、数据应用。

2.增量数据与增量计算

增量计算是对增量同步的数据做计算。在算法类项目中，增量计算对应的是模型增量训练，能基于批量计算过程中产生的持久化模型仅对增量数据做训练。这种方式的优势如下。

• 时效性。无须重复对历史数据做训练，极大地节省了模型训练时间，利于快速训练、快速部署和快速上线。

• 资源利用率。快速训练后，集群资源可释放出来供其他任务使用。

增量训练得到的模型结果与批量计算类似，也可以持久化到集群或硬盘，后续可供增量训练（增量训练可重复进行）和在线服务使用。增量计算一般以分钟或小时为单位进行。

增量计算与批量计算的流程相同，但由于其数据范围仅针对增量数据，因此要求所有数据环节都必须支持增量处理，主要环节是以算法为基础的特征工程和数据建模。

在数据流架构中，增量计算一般与批量计算分开，属于单独的数据流；而涉及的物理资源需求则可以根据实际情况复用。

• 如果批量计算的耗时短（如3小时以内），那么每天有21个小时可以用来做增量计算，此时信息的“损失”在于3个小时内不能进行增量计算。

• 如果批量计算的耗时较长（如3天），那么需要单独的资源来满足增量计算的需求。

3.流数据与流式计算

流式计算的数据源、同步过程、计算方式等内容与批量计算、增量计算都不同。流式计算面对的是流式进入的数据，该数据不经过通常意义上的数据库或具有数据存储功能的对象，而直接通过实时数据管道服务进入流式计算引擎或框架。

以在线个性化推荐系统为例，在线流式计算的核心过程如下。

（1）网站端实时产生用户行为，服务器后台产生实时日志。

（2）通过Kafka或Flume将日志实时同步到流式计算引擎Flink中。

（3）在Flink中完成数据处理，形成供后续计算所需的基础特征。

（4）基于实时在线特征，基于特定规则、方法、算法等得到Item召回集。

（5）基于实时在线特征，调用特征工程和模型对象，对召回的Item集合做粗排序。

（6）通过实时精排序或重排序逻辑，对粗排序结果进行多轮调整。

（7）返回推荐列表。

流式计算并不意味着一定需要模型服务，很多流式计算只需基于简单的数据处理规则就能满足应用需求。例如，在上述个性化推荐系统中，其中的步骤（4）可以直接基于特定的规则做简单召回和排序并返回推荐列表，而不必经过步骤（5）和（6）的复杂过程。

在数据流架构中，流式计算是一条单独的数据流。由于实时计算的持续性占用特性，流式计算必须要有单独的计算资源作为保障。