题外话
好久没写文章，发现写长文太辛苦了，所以慢慢往短文开始靠。这次算是第一个实践。
完全由流式计算构建的体系
部门目前核心其实就是流式计算，从根部开始(一个超大的Kafka集群)开始，延伸出一个超级庞大的树形结构。整个过程都是数据自我驱动进行流转，没有使用类似Azkaban/Oozie 等外部工具去让数据从一个系统流转到另外一个系统。 而我之前提出 Transformer架构 本质就是一个流式数据架构。
这个架构的核心概念是：
你开发的任何一个应用，本质上都是将两个或者多个节点连接起来，从而使得数据可以在不同节点之间流转
数据的流转必然由批量到流式
如果说在大数据领域，批量处理是第一次数据革命，那么流式处理则必然是第二次数据革命。
从某种角度而言，批量是流式处理的一个特例，譬如隔天处理数据，本质就是时间窗口为一天的流式计算。当然我们也可以实现以数量为窗口的计算。
当你需要借助外力的时候，事情往往就变得并不美好了。你需要额外的维护譬如Oozie等系统里的工作流，并且你需要考虑各个系统能够完成的时间，从而协调好组件。
数据流转的理想状态应该就如同河水一样，当源头水量变大后，水压会自动迫使数据自动流转速度加快。当我们需要灌溉新的农田时，我们只要接上某个河道（比如Kafka）,通过创建新的支流(由流式引擎比如Spark Streaming完成)，就可以很方便的将水引入。整个过程是水压驱动水的流转。
批量与流式的微妙关系
Spark Streaming的实现则让流式和批量之间的关系愈加微妙。批量处理是Spark Streaming流式处理的一个窗口特别大的特例，但是如果细加观察,Spark Streaming 的每个batch 又都是一个批处理，只是因为这个批处理可以足够小，看起来就像数据在真实流动一样，所以我们也称之为流式处理。
而Storm这种流式引擎则能实现最细粒度的流转，但是这种细粒度的流转在很多场景并不足够高效，因为在流转的过程中，往往下游无法接受来一条就处理一条的情况，需要通过小窗口的batch来完成更加高效的入库操作。
所以从某种角度而言，Spark Streaming 这种将批处理和流处理巧妙融合的方式可以保证自己可以充分利用流式和批处理的优势。
从另外一个角度而言，流式不过是一个具有无限数据的批处理过程。