1)实时性。流式大数据不仅是实时产生的，也是要求实时给出反馈结果。系统要有快速响应能力，在短时间内体现出数据的价值，超过有效时间后数据的价值就会迅速降低。
2)突发性。数据的流入速率和顺序并不确定，甚至会有较大的差异。这要求系统要有较高的吞吐量，能快速处理大数据流量。
3)易失性。由于数据量的巨大和其价值随时间推移的降低，大部分数据并不会持久保存下来，而是在到达后就立刻被使用并丢弃。系统对这些数据有且仅有一次计算机会。
4)无限性。数据会持续不断产生并流入系统。在实际的应用场景中，暂停服务来更新大数据分析系统是不可行的，系统要能够持久、稳定地运行下去，并随时进行自我更新，以便适应分析需求。
流式计算的典型范式之一是不确定数据速率的事件流流入系统，系统处理能力必须与事件流量匹配，或者通过近似算法等方法优雅降级，通常称为负载分流（load-shedding）。当然，除了负载分流，流式计算的容错处理等机制也和批处理计算不尽相同。
有人会说，MR也有自己的实时计算方案，比如说HOP。
但是，这类基于MapReduce进行流式处理的方案有三个主要缺点。
-
将输入数据分隔成固定大小的片段，再由MapReduce平台处理，缺点在于处理延迟与数据片段的长度、初始化处理任务的开销成正比。小的分段会降低延迟，增加附加开销，并且分段之间的依赖管理更加复杂（例如一个分段可能会需要前一个分段的信息）；反之，大的分段会增加延迟。最优的分段大小取决于具体应用。
-
为了支持流式处理，MapReduce需要被改造成Pipeline的模式，而不是Reduce直接输出；考虑到效率，中间结果最好只保存在内存中等。这些改动使得原有的MapReduce框架的复杂度大大增加，不利于系统的维护和扩展。
-
用户被迫使用MapReduce的接口来定义流式作业，这使得用户程序的可伸缩性降低。
综上所述，流式处理的模式决定了要和批处理使用非常不同的架构，试图搭建一个既适合流式计算又适合批处理计算的通用平台，结果可能会是一个高度复杂的系统，并且最终系统可能对两种计算都不理想。
目前流式计算是业界研究的一个热点，最近Twitter、LinkedIn等公司相继开源了流式计算系统Storm、Kafka等，加上Yahoo!之前开源的S4，流式计算研究在互联网领域持续升温。不过流式计算并非最近几年才开始研究，传统行业像金融领域等很早就已经在使用流式计算系统，比较知名的有StreamBase、Borealis等。
参考链接：
来源：CSDN
作者：wenyuenpu
链接：https://blog.csdn.net/wenyuenpu/article/details/104167689