方案中常用的大数据相关的关键技术与技术路线Word文件下载.docx
《方案中常用的大数据相关的关键技术与技术路线Word文件下载.docx》由会员分享，可在线阅读，更多相关《方案中常用的大数据相关的关键技术与技术路线Word文件下载.docx（5页珍藏版）》请在冰豆网上搜索。
集群中的Datanode一般是一个节点一个，负责管理它所在节点上的存储。
HDFS暴露了文件系统的名字空间，用户能够以文件的形式在上面存储数据。
从内部看，一个文件其实被分成一个或多个数据块，这些块存储在一组Datanode上。
Namenode执行文件系统的名字空间操作，比如打开、关闭、重命名文件或目录。
它也负责确定数据块到具体Datanode节点的映射。
Datanode负责处理文件系统客户端的读写请求。
在Namenode的统一调度下进行数据块的创建、删除和复制。
Namenode和Datanode被设计成可以在普通的商用机器上运行。
这些机器一般运行着GNU/Linux操作系统（OS）。
HDFS采用Java语言开发，因此任何支持Java的机器都可以部署Namenode或Datanode。
由于采用了可移植性极强的Java语言，使得HDFS可以部署到多种类型的机器上。
集群中单一Namenode的结构大大简化了系统的架构。
Namenode是所有HDFS元数据的仲裁者和管理者，这样，用户数据永远不会流过Namenode。
Hadoop分布式文件系统设计的主要目标：
①硬件错误是常态而不是异常。
HDFS可能由成百上千的服务器所构成，每个服务器上存储着文件系统的部分数据。
构成系统的组件数目是巨大的，而且任一组件都有可能失效，这意味着总是有一部分HDFS的组件是不工作的。
因此错误检测和快速、自动的恢复是HDFS最核心的架构目标。
②运行在HDFS上的应用和普通的应用不同，需要流式访问它们的数据集。
HDFS的设计中更多的考虑到了数据批处理，而不是用户交互处理。
比之数据访问的低延迟问题，更关键的在于数据访问的高吞吐量。
POSIX标准设置的很多硬性约束对HDFS应用系统不是必需的。
为了提高数据的吞吐量，在一些关键方面对POSIX的语义做了一些修改。
③运行在HDFS上的应用具有很大的数据集。
HDFS上的一个典型文件大小一般都在G字节至T字节。
因此，HDFS被调节以支持大文件存储。
它应该能提供整体上高的数据传输带宽，能在一个集群里扩展到数百个节点。
一个单一的HDFS实例应该能支撑数以千万计的文件。
④HDFS应用需要一个“一次写入多次读取”的文件访问模型。
一个文件经过创建、写入和关闭之后就不需要改变。
这一假设简化了数据一致性问题，并且使高吞吐量的数据访问成为可能。
Map/Reduce应用或者网络爬虫应用都非常适合这个模型。
目前还有计划在将来扩充这个模型，使之支持文件的附加写操作。
⑤一个应用请求的计算，离它操作的数据越近就越高效，在数据达到海量级别的时候更是如此。
因为这样就能降低网络阻塞的影响，提高系统数据的吞吐量。
将计算移动到数据附近，比之将数据移动到应用所在显然更好。
HDFS为应用提供了将它们自己移动到数据附近的接口。
⑥HDFS在设计的时候就考虑到平台的可移植性。
这种特性方便了HDFS作为大规模数据应用平台的推广。
2.实时数据处理技术
针对具有实时性、易失性、突发性、无序性、无限性等特征的流式大数据,理想的大数据流式计算系统应该表现出低延迟、高吞吐、持续稳定运行和弹性可伸缩等特性,这其中离不开系统架构、数据传输、编程接口、高可用技术等关键技术的合理规划和良好设计。
Storm是Twitter支持开发的一款分布式的、开源的、实时的、主从式大数据流式计算系统，使用的协议为EclipsePublicLicense1.0，其核心部分使用了高效流式计算的函数式语言Clojure编写，极大地提高了系统性能。
但为了方便用户使用，支持用户使用任意编程语言进行课题的开发。
（1）任务拓扑
任务拓扑（topology）是Storm的逻辑单元，一个实时应用的计算任务将被打包为任务拓扑后发布，任务拓扑一旦提交后将会一直运行着，除非显式地去中止。
一个任务拓扑是由一系列Spout和Bolt构成的有向无环图，通过数据流（stream）实现Spout和Bolt之间的关联。
其中，Spout负责从外部数据源不间断地读取数据，并以Tuple元组的形式发送给相应的Bolt；
Bolt负责对接收到的数据流进行计算，实现过滤、聚合、查询等具体功能，可以级联，也可以向外发送数据流。
数据流是Storm对数据进行的抽象，它是时间上无穷的Tuple元组序列，数据流是通过流分组（streamgrouping）所提供的不同策略实现在任务拓扑中流动。
此外，为了满足确保消息能且仅能被计算1次的需求，Storm还提供了事务任务拓扑。
（2）作业级容错机制
用户可以为一个或多个数据流作业进行编号，分配一个唯一的ID，Storm可以保障每个编号的数据流在任务拓扑中被完全执行。
所谓的完全执行，是指由该ID绑定的源数据流以及由该源数据流后续生成的新数据流经过任务拓扑中每一个应该到达的Bolt，并被完全执行。
Storm通过系统级组件Acker实现对数据流的全局计算路径的跟踪，并保证该数据流被完全执行。
其基本原理是为数据流中的每个分组进行编号，并通过异或运算来实现对其计算路径的跟踪。
作业级容错的基本原理是:
A
xor
A=0。
B
…xor
A=0，当且仅当每个编号仅出现2次。
作业级容错的基本流程：
在Spout中，系统会为数据流的每个分组生成一个唯一的64位整数，作为该分组的根ID。
根ID会被传递给Acker及后续的Bolt作为该分组单元的唯一标识符。
同时，无论是Spout还是Bolt，每次新生成一个分组的时候，都会重新赋予该分组一个新的64位的整数的ID。
Spout发送完某个数据流对应的源分组后，并告知Acker自己所发射分组的根ID及生成的那些分组的新ID，而Bolt每次接受到一个输入分组并计算完之后，也将告知Acker自己计算的输入分组的ID及新生成的那些分组的ID，Acker只需要对这些ID做一个简单的异或运算，就能判断出该根ID对应的消息单元是否计算完成。
（3）总体架构
Storm采用主从系统架构，在一个Storm系统中有两类节点（一个主节点Nimbus、多个从节点Supervisor）及3种运行环境（master，cluster和slaves）构成。
其中，主节点Nimbus运行在master环境中，是无状态的，负责全局的资源分配、任务调度、状态监控和故障检测：
一方面，主节点Nimbus接收客户端提交来的任务，验证后分配任务到从节点Supervisor上，同时把该任务的元信息写入Zookeeper目录中；
另一方面，主节点Nimbus需要通过Zookeeper实时监控任务的执行情况，当出现故障时进行故障检测，并重启失败的从节点Supervisor和工作进程Worker。
从节点Supervisor运行在slaves环境中，也是无状态的，负责监听并接受来自于主节点Nimbus所分配的任务，并启动或停止自己所管理的工作进程Worker，其中，工作进程Worker负责具体任务的执行。
一个完整的任务拓扑往往由分布在多个从节点Supervisor上的Worker进程来协调执行，每个Worker都执行且仅执行任务拓扑中的一个子集。
在每个Worker内部，会有多个Executor，每个Executor对应一个线程。
Task负责具体数据的计算，即用户所实现的Spout/Blot实例。
每个Executor会对应一个或多个Task，因此，系统中Executor的数量总是小于等于Task的数量。
Zookeeper是一个针对大型分布式系统的可靠协调服务和元数据存储系统，通过配置Zookeeper集群，可以使用Zookeeper系统所提供的高可靠性服务。
Storm系统引入Zookeeper，极大地简化了Nimbus，Supervisor，Worker之间的设计，保障了系统的稳定性。
Zookeeper在Storm系统中具体实现了以下功能：
①存储客户端提交的任务拓扑信息、任务分配信息、任务的执行状态信息等，便于主节点Nimbus监控任务的执行情况；
②存储从节点Supervisor、工作进程Worker的状态和心跳信息，便于主节点Nimbus监控系统各节点运行状态；
③存储整个集群的所有状态信息和配置信息，便于主节点Nimbus监控Zookeeper集群的状态，在出现主Zookeeper节点挂掉后可以重新选取一个节点作为主Zookeeper节点，并进行恢复。
Storm系统的主要特征为：
①简单编程模型，用户只需编写Spout和Bolt部分的实现，极大地降低了实时大数据流式计算的复杂性；
②支持多种编程语言，默认支持Clojure，Java，Ruby和Python，也可以通过添加相关协议实现对新增语言的支持；
③作业级容错性，可以保证每个数据流作业被完全执行；
④水平可扩展，计算可以在多个线程、进程和服务器之间并发执行；
⑤快速消息计算，通过ZeroMQ作为其底层消息队列，保证了消息能得到快速的计算。
3.数据仓库技术
数据仓库是决策支持系统（dss）和联机分析应用数据源的结构化数据环境。
数据仓库研究和解决从数据库中获取信息的问题。
数据仓库的特征在于面向主题、集成性、稳定性和时变性。
Hive是建立在Hadoop上的数据仓库基础构架。
它提供了一系列的工具，可以用来进行数据提取转化加载（ETL），这是一种可以存储、查询和分析存储在Hadoop中的大规模数据的机制。
Hive定义了简单的类SQL查询语言，称为HQL，它允许熟悉SQL的用户查询数据。
同时，这个语言也允许熟悉MapReduce开发者的开发自定义的mapper和reducer来处理内建的mapper和reducer无法完成的复杂的分析工作。
Hive没有专门的数据格式。
Hive可以很好的工作在Thrift之上，控制分隔符，也允许用户指定数据格式。
Hive构建在基于静态批处理的Hadoop之上，Hadoop通常都有较高的延迟并且在作业提交和调度的时候需要大量的开销。
因此，Hive并不能够在大规模数据集上实现低延迟快速的查询，例如Hive在几百MB的数据集上执行查询一般有分钟级的时间延迟，因此，Hive并不适合那些需要低延迟的应用，例如联机事务处理（OLTP）。
Hive查询操作过程严格遵守HadoopMapReduce的作业执行模型，Hive将用户的HiveQL语句通过解释器转换为MapReduce作业提交到Hadoop集群上，Hadoop监控作业执行过程，然后返回作业执行结果给用户。
Hive并非为联机事务处理而设计，Hive并不提供实时的查询和基于行级的数据更新操作。
Hive是一种底层封装了Hadoop的数据仓库处理工具，使用类SQL的HiveQL语言实现数据查询，所有Hive的数据都存储在Hadoop兼容的文件系统（例如，AmazonS3、HDFS）中。
Hive在加载数据过程中不会对数据进行任何的修改，只是将数据移动到HDFS中Hive设定的目录下，因此，Hive不支持对数据的改写和添加，所有的数据都是在加载的时候确定的。
Hive的设计特点如下：
①支持索引，加快数据查询；
②不同的存储类型，例如，纯文本文件、HBase中的文件；
③将元数据保存在关系数据库中，大大减少了在查询过程中执行语义检查的时间；
④可以直接使用存储在Hadoop文件系统中的数据；
⑤内置大量用户函数UDF来操作时间、字符串和其他的数据挖掘工具，支持用户扩展UDF函数来完成内置函数无法实现的操作；
⑥类SQL的查询方式，将SQL查询转换为MapReduce的job在Hadoop集群上执行。
4.人工智能技术
人工智能（ArtificialIntelligence，AI）是能够和人一样进行感知、认知、决策、执行的人工程序或系统。
当前，人工智能进入了加速发展的新阶段，并将深刻改变人类社会生活。
人工智能在农业领域可实现土壤探测、病虫害防护、产量预测、畜禽患病预警等功能。
将人工智能识别技术与智能机器人技术相结合,可广泛应用于农业中的播种、耕作、采摘等场景,极大提升农业生产效率,同时降低农药和化肥消耗。
通过对卫星拍摄图片、航拍图片以及农业物联网感知数据进行智能识别和大数据分析，人工智能能够获得精确的天气预报和气候灾害预警，使用人工智能和深度学习技术来分析上述数据，寻找其跟农作物生长之间的关系，就能进行农作物产量的精准预测。
深度学习的概念源于人工神经网络的研究。
含多隐层的多层感知器就是一种深度学习结构。
深度学习通过组合低层特征形成更加抽象的高层表示属性类别或特征，以发现数据的分布式特征表示。
神经网络是一组大致模仿人类大脑构造设计的算法，用于识别模式。
神经网络通过机器感知系统解释传感器数据，对原始输入进行标记或聚类。
神经网络所能识别的模式是包含在向量中的数值形式，因此图像、声音、文本、时间序列等一切现实世界的数据必须转换为数值。
深度学习系统指一系列由多个层堆叠组成的特定神经网络。
每一层则由节点构成。
运算在节点中进行，节点的运作模式与人类的神经元大致相似，遇到足够的刺激信息时就会激活并释放信号。
节点将输入数据与一组系数（或称权重）结合，通过放大或抑制输入来指定其在算法学习任务中的重要性。
输入数据与权重的乘积之和将进入节点的激活函数，判定信号是否继续在网络中传递，以及传递的距离，从而决定信号如何影响网络的最终结果，例如分类动作。
节点层是一行类似神经元的开关，在输入数据通过网络时开启或关闭。
从最初接收数据的第一个输入层开始，每一层的输出同时也是下一层的输入。
我们将输入特征与可调整的权重匹配，由此指定这些特征的重要性，即它们对网络的输入分类和聚类方式有多大程度的影响。
深度学习擅长识别非结构化数据中的模式，而大多数人熟知的图像、声音、视频、文本等媒体均属于此类数据。
由创业公司Skymind于2014年6月发布的Deeplearning4j是首个商用级别的深度学习开源库。
使用Deeplearning4j的不乏埃森哲、雪弗兰、博斯咨询和IBM等明星企业。
DeepLearning4j是一个面向生产环境和商业应用的高成熟度深度学习开源库，可与Hadoop和Spark集成，即插即用，方便开发者在应用中快速集成深度学习功能，可应用于以图像识别、语音搜索、语音转文字（Speechtotext）等。
升级会员 