1. 离线计算VS实时计算

离线计算

离线计算，通常也称为“批处理”，表示那些离线批量、延时较高的静态数据处理过程。
离线计算适用于实时性要求不高的场景，比如离线报表、数据分析等，延时一般在分钟级或小时级，多数场景是定时周期性执行一个Job任务，任务周期可以小到分钟级，比如每五分钟做一次统计分析，大到月级别、年级别，比如每月执行一次任务。我们最熟悉的MapReduce就是一个离线计算框架，Spark SQL也通常用于离线计算任务。

实时计算

实时计算，通常也称为“实时流计算”、“流式计算”，表示那些实时或者低延时的动态流数据处理过程。
实时计算通常应用在实时性要求高的场景，比如实时ETL、实时监控等，延时一般都在毫秒级甚至更低。目前比较流行的实时框架有Spark Streaming与Flink。其中，Spark Streaming属于微批处理，是一种把流当作一种批的设计思想，具有非常高的吞吐量但延时也较高，这使得Streaming的场景也得到了一定的限制；Flink则是事件驱动的流处理引擎，是一种把批当作一种有限的流的设计思想，具有高吞吐，低延时，高性能的特点

离线和实时应该指的是：数据处理的延迟；
批量和流式指的是：数据处理的方式。

首先先说下批量计算和流式计算：

图中显示了一个计算的基本流程，receiver处负责从数据源接收数据，并发送给下游的task，数据由task处理后由sink端输出。

以图为例，批量和流式处理数据粒度不一样，批量每次处理一定大小的数据块（输入一般采用文件系统），一个task处理完一个数据块之后，才将处理好的中间数据发送给下游。流式计算则是以record为单位，task在处理完一条记录之后，立马发送给下游。

假如我们是对一些固定大小的数据做统计，那么采用批量和流式效果基本相同，但是流式有一个好处就是可以实时得到计算中的结果，这对某些应用很有帮助，比如每1分钟统计一下请求server的request次数。

那问题来了，既然流式系统也可以做批量系统的事情，而且还提供了更多的功能，那为什么还需要批量系统呢？因为早期的流式系统并不成熟，存在如下问题：

1.流式系统的吞吐不如批量系统

2.流式系统无法提供精准的计算

后面的介绍Storm、Spark streaming、Flink主要根据这两点来进行介绍。

批量和流式的区别：

1.数据处理单位：

批量计算按数据块来处理数据，每一个task接收一定大小的数据块，比如MR，map任务在处理完一个完整的数据块后（比如128M），然后将中间数据发送给reduce任务。

流式计算的上游算子处理完一条数据后，会立马发送给下游算子，所以一条数据从进入流式系统到输出结果的时间间隔较短（当然有的流式系统为了保证吞吐，也会对数据做buffer）。

这样的结果就是：批量计算往往得等任务全部跑完之后才能得到结果，而流式计算则可以实时获取最新的计算结果。

2.数据源：

批量计算通常处理的是有限数据（bound data），数据源一般采用文件系统，而流式计算通常处理无限数据（unbound data），一般采用消息队列作为数据源。

3.任务类型：

批量计算中的每个任务都是短任务，任务在处理完其负责的数据后关闭，而流式计算往往是长任务，每个work一直运行，持续接受数据源传过来的数据。

离线=批量？实时=流式？

习惯上我们认为离线和批量等价；实时和流式等价，但其实这种观点并不完全正确。

假设一种情况：当我们拥有一个非常强大的硬件系统，可以毫秒级的处理Gb级别的数据，那么批量计算也可以毫秒级得到统计结果（当然这种情况非常极端，目前不可能），那我们还能说它是离线计算吗？

*所以说离线和实时应该指的是：数据处理的延迟；批量和流式指的是：数据处理的方式。两者并没有必然的关系。事实上Spark streaming就是采用小批量（batch）的方式来实现实时计算。*

可以参考下面链接：https://www.oreilly.com/ideas/the-world-beyond-batch-streaming-101。作者是Google实时计算的负责人，里面阐述了他对批量和实时的理解，并且作者认为批量计算只是流式计算的子集，一个设计良好的流式系统完全可以替代批量系统。本人也从中受到了很多启发。

2. 实时查询 Vs 即席查询

实时查询

实时查询，通常也称为在线查询，是对不断变化的数据进行实时的查询，要求数据修改后能够快速被查询到。通常我们见到的实时查询多是API的方式，少数以SQL方式。在线查询场景中最常见的生态组件大概就是HBase了，HBase能够提供强一致性的低延时数据访问，非常适合一般的在线业务。

即席查询

即席查询，英文名称为Ad hoc query，起初是在数据仓库领域中用户根据特定需求定义的一种实时查询方式。通常情况下，即席查询的表现是借助于大数据SQL查询组件进行交互式查询，比如Hive、Impala、Presto等SQL查询组件。因此严格意义上说，即席查询和上述中的实时查询还是有一定区别的。

3. OLTP Vs OLAP

OLTP

OLTP（On-Line Transaction Processing），可称为在线事务处理，一般应用于在线业务交易系统，比如银行交易、订单交易等。OLTP的主要特点是能够支持频繁的在线操作（增删改），以及快速的访问查询。因为要用于在线交易，所以一般要求支持事务特性。

OLAP

OLAP（On-Line Analytical Processing），可称为在线分析处理，较多的应用在数据仓库领域，支持复杂查询的数据分析，侧重于为业务提供决策支持。目前常见是的实时OLAP场景，比如Druid（Apache Druid，不同于阿里Druid）、ClickHouse等存储组件能够较好的满足需求。

4. 行式存储 Vs 列式存储

行式存储

行式存储（Row-based），简称“行存”，我们常见的关系型数据库比如MySQL、Oracle、DB2、SQL Server等都是采用行存的方式。总的来说，行存有利于写，但缺不利于读，因为行存是把同一条数据存放在相同位置，这样增删改比较高效，但是查询时会增加io的消耗。从上面举例我们也能看出，行存一般应用于OLTP场景。

列式存储

列式存储（Column-based），简称“列存”，这里是相对于行式存储的一种数据存储方式，一般应用于分布式存储/数据库中。总的来说，列存有利于读，但不利于写，这就意味着写路径上的增删改有一定的性能损耗。常见的列存包括Parquet、Arrow等，其最大特点是能够减少不必要的io消耗，主要表现在列裁剪与列压缩方面。与行存相反，列存更适应于OLAP场景。