数据亲和架构-流式计算

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

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

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

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

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

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