腾讯内容千亿级实时计算和规则引擎实践优化之路( 五 ) 作者|王冬、杨浩、李文斌、王

文章图片
图3-10批量融合状态重建架构
首先计算业务历史全量累计数据存入Key-Value缓存中作为基准数据，把实时数据和基准数据进行融合计算得到最新累计值，并可根据下游系统的负载能力调整数据的输出间隔。
步骤1：初始化时或者业务口径变更后，通过离线批处理计算历史全量数据，作为每个Key的基准数据，导入到Key-Value存储系统。
步骤2：重启实时流计算应用程序后，每个Key根据是否初始化过基准数据，从Key-Value中初始化基准数据。
步骤3：将基准数据和实时数据进行合并计算，通过流量控制把数据写入到下游业务存储系统中，供业务查询使用。
3.2.5单体流量适应水平扩展
内容生态面临着内容的消费数据越来越大的情况，单个实时流计算程序在Flink状态不断增大的情况下，由于单个程序需要维护的状态越来越大，程序频繁出现反压问题，增加程序的并发度也提高不了稳定性。
通常我们会增加实时流应用来适应流量水平扩容的架构，但是增加应用后，如果把数据随机发往扩容后的程序，会有一些潜在的问题，例如在计算某个内容ID累计值的场景，需要这个内容ID对应的所有数据严格发送到同一个程序，才能保证最终结果的准确性。

文章图片
图3-11单体流量适应水平扩容
为了解决以上问题，我们设计了如下可以适应流量水平扩展的架构。步骤如下：
步骤1：记录数据首次进入系统的时间，为了防止数据丢失做高可用的持久化存储。
步骤2：维护系统扩容前后的buckets的值，当数据过来之后根据数据首次进入系统时间所处的时间段找到对应的buckets的值。
步骤3：对内容进行寻址，将内容ID哈希后分配到buckets个桶中，而下游每个App对应一个桶。
3.2.6输出小文件数自适应流量
在内容加工场景中，需要将消息队列数据同步到HDFS中。同步时，会有N个同步子任务，其中N由流量峰值决定， N在同步过程中不能调整，当数据时效性为分钟时，每分钟会有N个子文件。然而，在流量低峰期时，由于N不会改变，会产生大量的小文件。

文章图片
图3-12输出文件数自适应流量
如上图所示，我们构建了一种输出小文件数自适应流量减少的解决方案。取单个文件为目标大小S（如64MB），以控制文件数目。我们将整个过程由原来的1个阶段拆分成了2个阶段：Map阶段和Reduce阶段，其中Map任务数是M ， Reduce任务数是N 。以下两个阶段，每分钟调度一次：Map阶段：读取数据进行自适应映射。缓存数据：每个任务缓存1min的数据。计算本批次产生的目标文件数K：缓存的数据大小乘以M得到本批次所有数据输出大小total_size ，计算当前批次目标文件数K=total_size/S 。均匀映射：每条数据依次加上1到K的Key ， data转换成(k,data) ，以方便Shuffle控制。 Reduce阶段：Reduce子任务k只拉取Key为k的数据，这样，子任务1到K之间会有数据，剩下的任务无数据。因为空任务不会产生文件，这样可以保障本批次输出的文件数为K 。
3.3规则引擎
在内容生态中除了实时流信号的生产服务，往往我们还需要进一步基于实时流信号，结合规则引擎管理业务个性化的触发逻辑，以此来支持内容周期智能管理等多种应用场景。