数据亲和架构-流式计算

关于计算有很多名词,比如实时计算、分布式计算,以及这里提到流式计算等等。他们是从计算形势的不同维度来描述,不必争议孰优孰劣。流式计算主要从数据的形态来定义的一种计算方式,顾名思义,这种数据如流水一般,没有终点。一个有争议的特征的是,流式数据之间是否具有时序性,我赞同流式数据之间应该假定为具有时序性,并由此引申出,计算是有状态的,具有上下文关系。虽然可以通过各种手段,将状态依赖降到零,或者某些场景下,数据之间就没有关联系;但假定流式数据是有状态的,更具普适性,因为无状态实际上可以视为状态为零的一种特例。

和流式计算相对应的,是数据库。我们将数据库的处理流程分解一下,可以发现,每个数据库连接持续发送SQL语句到DBMS,DBMS执行SQL语句,再到存储引擎,并最终持久化到硬盘。SQL语句包含了增删改和查询。连接和连接之间可以没有相关性,但一个连接内部是有时序性,比如事务,甚至SQL语句前后之间也是有依赖的。

流式计算和数据库在流程上相似度很高,除了流式计算不要求最终如何存储。但是追溯流式计算概念的提出,本身是为了解决大数据场景下,数据处理的实时性问题。换句话说,是为了解决数据库无法达到的时效问题,因此,两者之间有很高的相似度,也不足为奇。在发展之初,流式计算框架主要是在Hadoop等大数据批处理系统的基础上,通过缩短批处理的窗口,来提高响应速度。和批处理的大数据分析系统相比,响应速度是有提高,但还是离不开批处理的基因,应用场景还是在秒级范畴,但因为加上大数据分析的加持,比如推荐系统中,已经足够好的。因此,流式计算的拥护者众多。

如果我们重新审视下流式计算,我们会发现流式计算主要包含了四个部分,其一是流式数据本身;其二是计算逻辑;其三是计算过程中需要引用的数据;其四是计算结果,计算结果可能会成为一个新的流式数据来源。对流式计算实时性影响最大的是引用数据需要的时间,因为引用可能涉及到外部存储,显然这块的速度是无法和直接在内存中计算相比的。在理想情况下,如果没有引用数据,那么就能够大幅度提高响应速度。但毕竟是特殊场景,与业务有关,不具备普适性。在有些场景下,即使有引用数据,但是能够被预处理,或者转换为无引用数据,那也是一个很好的解决方案。

对实时性还有一个隐藏的影响因素,是流数据的时序性,他有计算结果的依赖性,也就是上下文相关。比如常用来作例子的存款余额,以及每年都要挨骂的12306网站的余票问题。究其根本,是后续的计算结果依赖于前一个数据的计算结果,不能并行处理,因此就增加了等待时间。

在一个数据规模大,实时性要求高的业务场景下,光依赖于硬件条件是有上限的。而且我们上面也说到过,数据引用和时序依赖是计算时延的关键因素。因此,分而划之,提高整体的计算并行度是一个合理的策略,这样将上下文关联降到最低;同时,将需要引用的数据置于内存中,或者将计算所需要引用的数据和流数据预处理合并在一起,就不需要在计算时在去等待外部数据,降低引用数据所需要的时间。

  • 发表于:
  • 原文链接:https://kuaibao.qq.com/s/20181204G0GPLB00?refer=cp_1026
  • 腾讯「云+社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。

扫码关注云+社区

领取腾讯云代金券