对流式计算技术的一些简单理解
在大数据出现的早期，当时企业或者开发者所注重的都是批量计算，当时对于开发者来说，对于一定量数据的处理，利用普通的程序就可以解决，然而当数据量或者计算量到达一定数量之后，应用程序的计算需要的时间也和数据量一样飞速增长，这个时候仅仅依靠传统的应用程序就遇到的很大的瓶颈，这个时候，一方面通过优化程序内部算法和一些机制等各种底层优化来提高系统性能和处理效率，另一方面是提高硬件的质量，也就是提高服务器的配置，从而提升计算速度和I/O，但是这样应对数据量的急速增长，显然会出现问题，开发成本和部署成本也在不断的提高，所以很多公司在具体的业务场景上都想到了一个共同的方法，那就是把一个复杂的任务放到多台计算机上执行，这样服务器配置不用太高，一般机器也可以，并且效率大大提升，当数据量继续增大时，那么继续增加服务器分担任务即可，这样就形成的初期的分布式计算系统。
对于前面所说的分布式计算系统，如果一个公司开发出来，另外公司想要拿过来用，根本是不可能的，因为这涉及到不同的硬件配置，通信方式，处理的业务等等都不相同，所以根本不能通用，当时也有开发者试着抽象出来一种通用的大数据处理框架，但是效果不太理想，比如会有使用难度太大，应用到实际场景限制过多等问题，这样的话也限制了大数据技术的发展，当时最流行的计算方式就是高性能分布式计算和网格计算，，直到2003、2004、2006年Google分别发表了3篇论文，分别是Google File System(简称GFS)、BigTable、Google MapReduce；发表这三篇论文才使大数据技术有了第一次飞跃，开启了真正的大数据时代，GFS使文件存储系统，BigTable是数据存储系统，MapReduce是计算模型，这样将大数据技术进行了一般性抽象，开启了后来大数据技术的大门，谷歌虽然没有将他的成果开源，但是后来有人根据谷歌的计算模型开发出来，最后就形成了Apache开源基金会的一个项目，就是Hadoop，Hadoop的主要组成是HDFS和MapReduce，其中HDFS是GFS的开源实现，MapReduce是Google MapReduce的开源实现，Hadoop在处理大批量数据时表现非常好，后来围绕这一中心形成了Hadoop生态系统，比如：
Hbase，相当于BigTable的分布式NoSQL系列的数据库
Hive数据仓库工具，由Facebook贡献，
Zookeeper 分布式锁，提供类似Google Chubby的功能，有Facebook贡献
Avro 数据序列化与传输工具，将逐步取代Hadoop原有的IPC机制
Pig 大数据分析平台，
Ambari Hadoop的管理工具，可以快捷的监控、部署、管理集群
Sqoop 支持Hadoop与传统数据库之间进行数据的传递
Mahout 用于数据挖掘和机器学习实现，实现文档聚类、做出推荐和组织内容等，创始人是Grant Ingersoll
以上这些等等，形成了Hadoop的生态系统，一下是在网上找到的一张经典的Hadoop生态系统图：
HDFS存储模型：
MapReduce计算模型：
以上这些Hadoop生态圈对批量处理TB、PB级的大数据是可靠的，不过在生产过程中逐步出现一些不足之处，仔细想想我们也可以发现，批量数据处理中，有以下的特点：
1、计算开始之前，数据必须提前准备好，然后才可以开始计算
2、当大量数据计算完成之后，会输出最后计算结果，完成计算
3、时效性比较低，不适用于实时的计算
针对以上这些问题，才慢慢形成了流式计算的这样一种概念，流式计算主要应用场景就是在线海量数据处理，处理大量用户的在线请求，可以理解为一台服务器，这个服务是一直开着的，只要用户有请求它都会去实时处理并输出结果或者响应，可以看成一个数据流源源不断的流进计算系统，计算系统作为后台服务源源不断的进行计算，最终将结果源源不断的输出，这就是对流式计算最基本一层的认识
在实际应用中，可以处理用户线上实时的请求，在线系统产生的日志，记录用户行为的数据库，新闻热点，电商促销，微博热词推荐，实时用户在线查询等
目前流式计算最著名的框架就是：Spark、Twitter的Storm、Yahoo的S4
流式计算的共同特征是：
1、和前面Hadoop生态系统作对比主要是：计算中数据持续到来、实时系统会作为后台服务持续运行、适用于时效性较高的场景
2、非常方便的编写自己的计算逻辑，而不用关心底层的实现方式，比如Map和Reduce，我们只需要编写两个方法，和单机的计算方式一样，框架自己完成分布式协调计算的功能，所以对于用户使用非常方便
3、数据可靠性，系统需要保证数据不被丢失，也就是系统的高可用性
4、容错性 用户不必关心错误处理，系统应该提供高容错性并且有效的调度和管理资源
5、超时设置 超时时间的大小一定要被重视，时间太短会误杀正常运算，时间太长不能快速的检测错误，系统应该有延时自动学习的功能，即根据多个计算任务找出出错的任务，然后重新将任务调度到系统中的其他节点，这样保证整个系统的性能
Spark的设计思想是将流式计算分解成一系列短小的批处理作业，也就是把Spark Streaming的输入数据按照时间分成一段一段的数据，每一段数据都转换成Spark中的RDD，然后在Spark内部对RDD进行处理操作，结果可以放到内存中继续处理或者存储到外部设备
Storm将计算逻辑抽象为拓扑Topology，Spout是Topology的数据源，数据源可以是日志或者消息队列，也可以是数据库中的表等等数据，Bolt负责数据的整个传递方向，也叫消息处理者，Bolt可能由另外2个Bolt进行join得到，在Storm中数据流的单位就是Tuple(元组)，这个Tuple可能是由多个Fields字段构成，每个字段都由Bolt定义，Storm中工作进程叫做worker，一个Topology实际上实在多个worker中运行的，在集群中每个Spout和Bolt都是由多个Tasks(任务)组成的，对于宏观的节点，分为Nimbus主节点和Supervisor从节点，Nimbus通过Zookeeper管理集群所有的Supervisor，Storm提供很多配置来调整Nimbus、Supervisor进程和正在运行的Topology的行为
所以，总结一下Storm的计算流程，首先是用户使用Storm提供的API编写Topology计算逻辑，然后使用Storm提供的Client将Topology提交给Nimbus，然后Nimbus将Task作业指派给Supervisor，Supervisor在得到Task后，为Task启动Worker由Worker执行具体的Task，最后完成计算任务
Storm实际性能上比Spark还要高，总体上来说，Spark和Storm是流式计算中最著名使用也最广泛的2个框架
另外Google为了应对并发数据流水线和以及实时数据，将MapReduce分布式计算模型进行了全新尝试，推出Cloud Dataflow，可以构建、管理、优化复杂流水线，构建云应用，并且提供了基于Java的统一API，开发者只需要使用简单的API即可掌握Cloud Dataflow的使用，Google Cloud Platform还为开发者提供了一系列工具：云保存、云调试、云追踪和云监控，BigQuery为Dataflow提供存储，数据流经过Dataflow的清洗，可以放到BigQuery中存储；同时Dataflow还可以连接BigQuery进行数据的读取，因此如果想在Dataflow中使用一些开源资源是非常方便的，Dataflow的生态系统如下图所示：
以上就是简单的说了大数据处理技术的发展历程和流式计算框架的产生，从最初的网格计算到Hadoop生态系统是一次巨大的飞跃，从大数据批量计算到Spark、Storm、YahooS4和Google Cloud Dataflow这些大数据流式计算技术的产生又是一次巨大的飞跃，文中有很多地方也许理解的不够到位，欢迎指正，相信在未来DT时代，大数据计算技术将为各行各业注入新的生命力...
