数据天生就是流式的
现在依然很多人使用Azkaban/Oozie等工具衔接各个系统，通过外力让数据进行流转。而随着流式计算慢慢成熟与稳定，数据必然如河水一般，天生就是流式的。
题外话
好久没写文章，发现写长文太辛苦了，所以慢慢往短文开始靠。这次算是第一个实践。
完全由流式计算构建的体系
部门目前核心其实就是流式计算，从根部开始(一个超大的Kafka集群)开始，延伸出一个超级庞大的树形结构。整个过程都是数据自我驱动进行流转，没有使用类似Azkaban/Oozie 等外部工具去让数据从一个系统流转到另外一个系统。 而我之前提出 Transformer架构 本质就是一个流式数据架构。
这个架构的核心概念是：
你开发的任何一个应用，本质上都是将两个或者多个节点连接起来，从而使得数据可以在不同节点之间流转
数据的流转必然由批量到流式
如果说在大数据领域，批量处理是第一次数据革命，那么流式处理则必然是第二次数据革命。
从某种角度而言，批量是流式处理的一个特例，譬如隔天处理数据，本质就是时间窗口为一天的流式计算。当然我们也可以实现以数量为窗口的计算。
当你需要借助外力的时候，事情往往就变得并不美好了。你需要额外的维护譬如Oozie等系统里的工作流，并且你需要考虑各个系统能够完成的时间，从而协调好组件。
数据流转的理想状态应该就如同河水一样，当源头水量变大后，水压会自动迫使数据流转速度加快。当我们需要灌溉新的农田时，我们只要接上一个蓄水池(比如Kafka,)在蓄水池延伸出新的河道(由流式引擎比如Spark Streaming完成)，就可以很方便的将水引入。整个过程是水压驱动水的流转。
假设我们有河道A, 蓄水池C,河道B。水流方向是 A -> C ->B。 A 内部是典型的依赖于重力的将水压力蓄水池C。 而B 则因为地势可能更高些，需要靠消费额外的资源(CPU资源)将水抽取到B自己的河道里(pull 模式)。 当然，B也可能是地势低，这样C可以利用重力将水引入C （典型的push模式）。
批量与流式的微妙关系
批处理和流式本来就存在某种微妙的关系，我中有你，你中有我。Spark Streaming则充分利用了这种微妙关系，将其发挥到极致。批量处理是Spark Streaming流式处理的一个窗口特别大的特例，但是如果细加观察,Spark Streaming 的每个batch 又都是一个批处理，只是因为这个批处理可以足够小，看起来就像数据在真实流动一样，所以我们也称之为流式处理。
这里有个值得提出的东西是，当处理时间等于调度周期，那么spark streaming就是一个永不干涸的河道。而如果处理时间大于调度周期，则有两种情况需要阐述：
- 限制抽水泵的功率(也就是背压，backpressure)
- 限制抽水泵的工作时间。因为延时，抽水泵需要一个或者多个调度周期才会开始真的工作。（Direct Approach模式）
如果抽水泵不限制功率也不推延工作时间(Receiver模式容易出现)，那么就让河道溢出了(OOM)了。
从某种角度而言，Spark Streaming 这种将批处理和流处理巧妙融合的方式可以保证自己可以充分利用流式和批处理的优势。
Storm这种流式引擎则能实现最细粒度的流转，但是这种细粒度的流转在很多场景并不足够高效，因为在流转的过程中，往往下游无法接受来一条就处理一条的情况，需要通过小窗口的batch来完成更加高效的入库操作。而获取数据，Storm从某种角度而言也是批处理。因为消费者每次从kafka 抽取数据的时候，也是一次抽取到足够的量，然后交给后端一条一条处理。
所以Storm 和Spark Streaming的本质区别在于抽水泵的工作机制。
几句话
- 从另外一个角度而言，流式不过是一个具有无限数据的批处理过程。
- 流式处理则是我们通向实时的一条必经之路
- 实时是我们永不言弃的目标
总结
从宏观角度而言，批处理pipeline 一般而言借住一个协调组件，又该协调组件产生动力，调用各个系统完成某种功能。通常而言，批处理pipeline的数据处理周期都较长，符合离线的定义，譬如隔天，并且各个系统作为管道，只有在需要的时候才会被创建。
流式处理pipeline 则不需要借助外部协调组件，每个系统通过主动拉取或者推送的方式，完成数据在不同系统中的流转。通常而言，流式pipeline的数据处理周期都很短，符合准实时的定义，并且各个系统作为管道，都是一直存在的。