1、流式计算
流式计算时相对于批量计算提出的概念，一般认为，批量计算的处理数据集是有界的，也就是说，批量计算开始时，计算数据的范围是已经确定的，计算时总是成批的计算某一周期内的数据，或者是截止到某一时间点的数据。批计算时，也能够批量使用源数据，并批量地得出周期性的计算结果，因而所需要的的计算资源和计算时间是比较长的。
流计算则更强调流式输入和更低的计算延时，以达到近似实时地得到计算结果的目的。数据流式的产生和输入计算系统，以为着数据不需要跟批处理系统一样必须要等待一个周期才能被同步到计算系统，而是每产生一条数据（或者是每一条的数据变化）都会被直接同步到计算系统，参与到实时的计算中来。流计算系统面对的输入数据，是连续不断的数据流。如果将数据流进行周期性的截断，可以理解为批处理的模型；但是大部分情况下，流计算会将数据流按照极短的周期进行小批量处理（SPARK平台的计算方案），或者是针对每一条到来的数据都进行计算（STORM和FLINK的计算方案）。
2、流计算与批处理的区别
与传统的数据处理一样，流计算的整体流程也可以分为数据集成同步、数据处理计算、数据结果输出几个步骤。
数据集成同步，是将业务源系统的数据同步到计算平台的过程。对于最原始的数据仓库（即数仓与业务数据库在同一数据库的方案），数据是不需要进行同步就可以利用数据库资源进行计算的，但是这样的弊端是数仓逻辑计算时会占用业务系统的计算资源，而且数仓只能建设成为一个个孤立的数据集合，无法达到数据打通的目的。当出现中央式的批处理数仓时，数据集成靠的是五花八门的集成工具，比如说datastage、powercenter、kettle，这一类是通过往业务数据库发起一个select请求进行数据同步的；另外一种同步的方案则是采用数据库自带的主从同步功能，比如说MySQL的binlog同步，Oracle的dataguard、goldengate同步等，不过这种方案总是有这样那样的缺陷，比如说你需要准备一个结构和源库一样的数据库作为数仓，有可能就达不到把多种异构数据源集成到一个平台的目的。流计算的数据同步，则是出于减少每次同步的数据量的目的，采用的是捕获数据变化记录流失化的方案，落到实处，就是监听数据库的同步日志，将其写入到消息系统中，生成消息流。对于MySQL，可以监听binlog日志，将数据库里面每行数据的增删更新动作都捕获起来，形成信息流。
数据处理计算，就是数仓的关键部分，一般称之为计算引擎，包括了进行数据计算所需要的的临时存储、CPU资源和内存资源。批处理平台的计算引擎一般都是分布式处理框架，比如说hive；流计算的计算引擎则是集群安装的spark、storm、flink平台。流计算的计算引擎主要结局的问题是将数据流结构化，并使用一系列流程化算子化技术，合理的规范计算资源，将数据进行正确的计算和输出。
数据结果输出，就是在计算过程或者计算完成时，需要将计算结果输出到数据展现依赖的数据库，或者是中间存储组件。批处理计算的结果，一般会输出到MySQL数据库进行数据展现。而流计算系统则会将中间结果输出到信息系统中，给下游的计算做输入；对于最终计算结果，则会输出到分析型数据库，进行数据实时汇总展现。
3、框架上的升级
旧的批处理框架如下：
新的流式处理框架如下：
