一、流式计算的背景

在日常生活中，我们通常会先把数据存储在一张表中，然后再进行加工、分析，这里就涉及到一个时效性的问题。如果我们处理以年、月为单位的级别的数据，那么多数据的实时性要求并不高；但如果我们处理的是以天、小时，甚至分钟为单位的数据，那么对数据的时效性要求就比较高。在第二种场景下，如果我们仍旧采用传统的数据处理方式，统一收集数据，存储到数据库中，之后在进行分析，就可能无法满足时效性的要求。

二、流式计算与批量计算

大数据的计算模式主要分为批量计算(batch computing)、流式计算(stream computing)、交互计算(interactive computing)、图计算(graph computing)等。其中，流式计算和批量计算是两种主要的大数据计算模式，分别适用于不同的大数据应用场景。

流数据（或数据流）是指在时间分布和数量上无限的一系列动态数据集合体，数据的价值随着时间的流逝而降低，因此必须实时计算给出秒级响应。流式计算，顾名思义，就是对数据流进行处理，是实时计算。批量计算则统一收集数据，存储到数据库中，然后对数据进行批量处理的数据计算方式。主要体现在以下几个方面：

1、数据时效性不同：流式计算实时、低延迟， 批量计算非实时、高延迟。

2、数据特征不同：流式计算的数据一般是动态的、没有边界的，而批处理的数据一般则是静态数据。

3、应用场景不同：流式计算应用在实时场景，时效性要求比较高的场景，如实时推荐、业务监控…批量计算一般说批处理，应用在实时性要求不高、离线计算的场景下，数据分析、离线报表等。

4、运行方式不同，流式计算的任务持续进行的，批量计算的任务则一次性完成。

三、流式计算框架、平台与相关产品

第一类，商业级流式计算平台（IBM InfoSphere Streams、IBM StreamBase等）；

第二类，开源流式计算框架（Twitter Storm、S4等）；

第三类，公司为支持自身业务开发的流式计算框架。

Strom：Twitter 开发的第一代流处理系统。

Heron：Twitter 开发的第二代流处理系统。

Spark streaming：是Spark核心API的一个扩展，可以实现高吞吐量的、具备容错机制的实时流数据的处理。

Flink：是一个针对流数据和批数据的分布式处理引擎。

Apache Kafka：由Scala写成。该项目的目标是为处理实时数据提供一个统一、高通量、低等待的平台。

四、流式计算主要应用场景

流式处理可以用于两种不同场景： 事件流和持续计算。

1、事件流

事件流具能够持续产生大量的数据，这类数据最早出现与传统的银行和股票交易领域，也在互联网监控、无线通信网等领域出现、需要以近实时的方式对更新数据流进行复杂分析如趋势分析、预测、监控等。简单来说，事件流采用的是查询保持静态，语句是固定的，数据不断变化的方式。

2、持续计算

比如对于大型网站的流式数据：网站的访问PV/UV、用户访问了什么内容、搜索了什么内容等，实时的数据计算和分析可以动态实时地刷新用户访问数据，展示网站实时流量的变化情况，分析每天各小时的流量和用户分布情况；

比如金融行业，毫秒级延迟的需求至关重要。一些需要实时处理数据的场景也可以应用Storm，比如根据用户行为产生的日志文件进行实时分析，对用户进行商品的实时推荐等。

五、流式计算的价值

通过大数据处理我们获取了数据的价值，但是数据的价值是恒定不变的吗？显然不是，一些数据在事情发生后不久就有了更高的价值，而且这种价值会随着时间的推移而迅速减少。流处理的关键优势在于它能够更快地提供洞察力，通常在毫秒到秒之间。

流式计算的价值在于业务方可在更短的时间内挖掘业务数据中的价值，并将这种低延迟转化为竞争优势。比方说，在使用流式计算的推荐引擎中，用户的行为偏好可以在更短的时间内反映在推荐模型中，推荐模型能够以更低的延迟捕捉用户的行为偏好以提供更精准、及时的推荐。

流式计算能做到这一点的原因在于，传统的批量计算需要进行数据积累，在积累到一定量的数据后再进行批量处理；而流式计算能做到数据随到随处理，有效降低了处理延时。

先荐是一款赋能媒体的AI产品，是集内容上传、内容管理、内容分发、推荐干预、前端渲染于一体的一站式推荐服务可视化平台，支持PC、WAP、APP全平台接入，帮助媒体从0到1搭建推荐系统，显著提升用户活跃、留存、观看时长等重要业务指标，在减少技术成本投入的同时，大幅提高媒体运营效率，从而实现业务智能化转型。目前已服务人民日报、环球网、花瓣网、果壳网、段友、36氪、简书等三百余家内容平台，其中在环球网web端的兴趣推荐项目上，实现了点击率58%的提升，同时访问量和营收分别增长了69%、20%。想要了解更多产品详情，请添加先荐小助手（recsysfc）。