对流式计算技术的一些简单理解

　　在大数据出现的早期，当时企业或者开发者所注重的都是批量计算，当时对于开发者来讲，对于必定量数据的处理，利用普通的程序就能够解决，然而当数据量或者计算量到达必定数量以后，应用程序的计算须要的时间也和数据量同样飞速增加，这个时候仅仅依靠传统的应用程序就遇到的很大的瓶颈，这个时候，一方面经过优化程序内部算法和一些机制等各类底层优化来提升系统性能和处理效率，另外一方面是提升硬件的质量，也就是提升服务器的配置，从而提高计算速度和I/O，可是这样应对数据量的急速增加，显然会出现问题，开发成本和部署成本也在不断的提升，因此不少公司在具体的业务场景上都想到了一个共同的方法，那就是把一个复杂的任务放到多台计算机上执行，这样服务器配置不用过高，通常机器也能够，而且效率大大提高，当数据量继续增大时，那么继续增长服务器分担任务便可，这样就造成的初期的分布式计算系统。

　　对于前面所说的分布式计算系统，若是一个公司开发出来，另外公司想要拿过来用，根本是不可能的，由于这涉及到不一样的硬件配置，通讯方式，处理的业务等等都不相同，因此根本不能通用，当时也有开发者试着抽象出来一种通用的大数据处理框架，可是效果不太理想，好比会有使用难度太大，应用到实际场景限制过多等问题，这样的话也限制了大数据技术的发展，当时最流行的计算方式就是高性能分布式计算和网格计算，，直到200三、200四、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级的大数据是可靠的，不过在生产过程当中逐步出现一些不足之处，仔细想一想咱们也能够发现，批量数据处理中，有如下的特色：

　　一、计算开始以前，数据必须提早准备好，而后才能够开始计算

　　二、当大量数据计算完成以后，会输出最后计算结果，完成计算

　　三、时效性比较低，不适用于实时的计算

　　针对以上这些问题，才慢慢造成了流式计算的这样一种概念，流式计算主要应用场景就是在线海量数据处理，处理大量用户的在线请求，能够理解为一台服务器，这个服务是一直开着的，只要用户有请求它都会去实时处理并输出结果或者响应，能够当作一个数据流源源不断的流进计算系统，计算系统做为后台服务源源不断的进行计算，最终将结果源源不断的输出，这就是对流式计算最基本一层的认识

　　在实际应用中，能够处理用户线上实时的请求，在线系统产生的日志，记录用户行为的数据库，新闻热点，电商促销，微博热词推荐，实时用户在线查询等

　　目前流式计算最著名的框架就是：Spark、Twitter的Storm、Yahoo的S4

　　流式计算的共同特征是：

　　一、和前面Hadoop生态系统做对比主要是：计算中数据持续到来、实时系统会做为后台服务持续运行、适用于时效性较高的场景

　　二、很是方便的编写本身的计算逻辑，而不用关心底层的实现方式，好比Map和Reduce，咱们只须要编写两个方法，和单机的计算方式同样，框架本身完成分布式协调计算的功能，因此对于用户使用很是方便

　　三、数据可靠性，系统须要保证数据不被丢失，也就是系统的高可用性

　　四、容错性 用户没必要关心错误处理，系统应该提供高容错性而且有效的调度和管理资源

　　五、超时设置 超时时间的大小必定要被重视，时间过短会误杀正常运算，时间太长不能快速的检测错误，系统应该有延时自动学习的功能，即根据多个计算任务找出出错的任务，而后从新将任务调度到系统中的其余节点，这样保证整个系统的性能

 

　　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时代，大数据计算技术将为各行各业注入新的生命力...