搜索
伪分布式Hadoop+Hive+HBase搭建概念HadoopHDFS分布式存储Hadoop分布式文件系统(HDFS)被设计成适合运行在通用硬件(commodityhardware)上的分布式文件系统。它和现有的分布式文件系统有很多共同点。但同时，它和其他的分布式文件系统的区别也是很明显的。HDFS是一个高度容错性的系统，适合部署在廉价的机器上。HDFS能提供高吞吐量的数据访问，非常适合大规模数据集上的应用。HDFS放宽了一部分POSIX约束，来实现流式读取文件系统数据的目的。HDFS在最开始是作为ApacheNutch搜索引擎项目的基础架构而开发的。HDFS是ApacheHadoopCore项目的一部分。HDFS有着高容错性（fault-tolerant）的特点，并且设计用来部署在低廉的（low-cost）硬件上。而且它提供高吞吐量（highthroughput）来访问应用程序的数据，适合那些有着超大数据集（largedataset）的应用程序。HDFS放宽了（relax）POSIX的要求（requirements）这样可以实现流的形式访问（streamingaccess）文件系统中的数据。mapReduceMapReduce是一种编程模型，用于大规模数据集（大于1TB）的并行运算。概念Map（映射）和Reduce（归约），和它们的主要思想，都是从函数式编程语言里借来的，还有从矢量编程语言里借来的特性。它极大地方便了编程人员在不会分布式并行编程的情况下，将自己的程序运行在分布式系统上。当前的软件实现是指定一个Map（映射）函数，用来把一组键值对映射成一组新的键值对，指定并发的Reduce（归约）函数，用来保证所有映射的键值对中的每一个共享相同的键组。hbaseHbase是运行在Hadoop上的NoSQL数据库，它是一个分布式的和可扩展的大数据仓库，也就是说HBase能够利用HDFS的分布式处理模式，并从Hadoop的MapReduce程序模型中获益。这意味着在一组商业硬件上存储许多具有数十亿行和上百万列的大表。除去Hadoop的优势，HBase本身就是十分强大的数据库，它能够融合key/value存储模式带来实时查询的能力，以及通过MapReduce进行离线处理或者批处理的能力。总的来说，Hbase能够让你在大量的数据中查询记录，也可以从中获得综合分析报告。StormTwitter将Storm正式开源了，这是一个分布式的、容错的实时计算系统，它被托管在GitHub上，遵循EclipsePublicLicense1.0。Storm是由BackType开发的实时处理系统，BackType现在已在Twitter麾下。GitHub上的最新版本是Storm0.8.0，基本是用Clojure写的。Storm为分布式实时计算提供了一组通用原语，可被用于“流处理”之中，实时处理消息并更新数据库。这是管理队列及工作者集群的另一种方式。Storm也可被用于“连续计算”（continuouscomputation），对数据流做连续查询，在计算时就将结果以流的形式输出给用户。它还可被用于“分布式RPC”，以并行的方式运行昂贵的运算。Storm的主工程师NathanMarz表示：Storm可以方便地在一个计算机集群中编写与扩展复杂的实时计算，Storm用于实时处理，就好比Hadoop用于批处理。Storm保证每个消息都会得到处理，而且它很快——在一个小集群中，每秒可以处理数以百万计的消息。更棒的是你可以使用任意编程语言来做开发。Storm的主要特点如下：简单的编程模型。类似于MapReduce降低了并行批处理复杂性，Storm降低了进行实时处理的复杂性。可以使用各种编程语言。你可以在Storm之上使用各种编程语言。默认支持Clojure、Java、Ruby和Python。要增加对其他语言的支持，只需实现一个简单的Storm通信协议即可。容错性。Storm会管理工作进程和节点的故障。水平扩展。计算是在多个线程、进程和服务器之间并行进行的。可靠的消息处理。Storm保证每个消息至少能得到一次完整处理。任务失败时，它会负责从消息源重试消息。快速。系统的设计保证了消息能得到快速的处理，使用ØMQ作为其底层消息队列。本地模式。Storm有一个“本地模式”，可以在处理过程中完全模拟Storm集群。这让你可以快速进行开发和单元测试。Storm集群由一个主节点和多个工作节点组成。主节点运行了一个名为“Nimbus”的守护进程，用于分配代码、布置任务及故障检测。每个工作节点都运行了一个名为“Supervisor”的守护进程，用于监听工作，开始并终止工作进程。Nimbus和Supervisor都能快速失败，而且是无状态的，这样一来它们就变得十分健壮，两者的协调工作是由ApacheZooKeeper来完成的。Storm的术语包括Stream、Spout、Bolt、Task、Worker、StreamGrouping和Topology。Stream是被处理的数据。Spout是数据源。Bolt处理数据。Task是运行于Spout或Bolt中的线程。Worker是运行这些线程的进程。StreamGrouping规定了Bolt接收什么东西作为输入数据。数据可以随机分配（术语为Shuffle），或者根据字段值分配（术语为Fields），或者广播（术语为All），或者总是发给一个Task（术语为Global），也可以不关心该数据（术语为None），或者由自定义逻辑来决定（术语为Direct）。Topology是由StreamGrouping连接起来的Spout和Bolt节点网络。在StormConcepts页面里对这些术语有更详细的描述。可以和Storm相提并论的系统有Esper、Streambase、HStreaming和YahooS4。其中和Storm最接近的就是S4。两者最大的区别在于Storm会保证消息得到处理。Storm，如果需要持久化，可以使用一个类似于Cassandra或Riak这样的外部数据库。Storm是分布式数据处理的框架，本身几乎不提供复杂事件计算，而Esper、Streambase属于CEP系统。入门的最佳途径是阅读GitHub上的官方《StormTutorial》。其中讨论了多种Storm概念和抽象，提供了范例代码以便你可以运行一个StormTopology。开发过程中，可以用本地模式来运行Storm，这样就能在本地开发，在进程中测试Topology。一切就绪后，以远程模式运行Storm，提交用于在集群中运行的Topology。要运行Storm集群，你需要ApacheZookeeper、ØMQ、JZMQ、Java6和Python2.6.6。ZooKeeper用于管理集群中的不同组件，ØMQ是内部消息系统，JZMQ是ØMQ的JavaBinding。有个名为storm-deploy的子项目，可以在AWS上一键部署Storm集群。关于详细的步骤，可以阅读StormWiki上的《SettingupaStormcluster》。出现的背景在过去10年中，随着互联网应用的高速发展，企业积累的数据量越来越大，越来越多。随着GoogleMapReduce、Hadoop等相关技术的出现，处理大规模数据变得简单起来，但是这些数据处理技术都不是实时的系统，它们的设计目标也不是实时计算。毕竟实时的计算系统和基于批处理模型的系统（如Hadoop）有着本质的区别。但是随着大数据业务的快速增长，针对大规模数据处理的实时计算变成了一种业务上的需求，缺少“实时的Hadoop系统”已经成为整个大数据生态系统中的一个巨大缺失。Storm正是在这样的需求背景下出现的，Storm很好地满足了这一需求。在Storm出现之前，对于需要实现计算的任务，开发者需要手动维护一个消息队列和消息处理者所组成的实时处理网络，消息处理者从消息队列中取出消息进行处理，然后更新数据库，发送消息给其他队列。所有这些操作都需要开发者自己实现。这种编程实现的模式存在以下缺陷。●单调乏味性：开发者需要花费大部分时间去配置消息如何发送，消息发送到哪里，如何部署消息的处理者，如何部署消息的中间处理节点等。如果使用Storm进行处理，那么开发者只需要很少的消息处理逻辑代码，这样开发者就可以专注于业务逻辑的开发，从而大大提高了开发实时计算系统的效率。●脆弱性：程序不够健壮，开发者需要自己编写代码以保证所有的消息处理者和消息队列的正确运行。●可伸缩性差：当一个消息处理者能处理的消息达到自己能处理的峰值时，就需要对消息流进行分流，这时需要配置新的消息处理者，以让它们处理分流消息。对于需要处理大量消息流的实时系统来说，消息处理始终是实时计算的基础，消息处理的最后就是对消息队列和消息处理者之间的组合。消息处理的核心是如何在消息处理的过程中不丢失数据，而且可以使整个处理系统具有很好的扩展性，以便能够处理更大的消息流。而Storm正好可以满足这些要求。应用领域Storm有许多应用领域，包括实时分析、在线机器学习、信息流处理（例如，可以使用Storm处理新的数据和快速更新数据库）、连续性的计算（例如，使用Storm连续查询，然后将结果返回给客户端，如将微博上的热门话题转发给用户）、分布式RPC（远过程调用协议，通过网络从远程计算机程序上请求服务）、ETL（ExtractionTransformationLoading，数据抽取、转换和加载）等。Storm的处理速度惊人，经测试，每个节点每秒可以处理100万个数据元组。Storm可扩展且具有容错功能，很容易设置和操作。Storm集成了队列和数据库技术，Storm拓扑网络通过综合的方法，将数据流在每个数据平台间进行重新分配。图1所示为Storm处理消息流的示意图。图1Storm数据流图在Storm消息处理模型中，消息源就像图1中所示的水龙头，它可以源源不断地将消息发送到消息处理者那里，消息处理者接收消息，进行处理，然后消息处理者既可以将消息发送到其他消息处理者那里，或者不发送消息，表示消息处理结束。Kafkakafka是一种高吞吐量的分布式发布订阅消息系统，它可以处理消费者规模的网站中的所有动作流数据。这种动作（网页浏览，搜索和其他用户的行动）是在现代网络上的许多社会功能的一个关键因素。这些数据通常是由于吞吐量的要求而通过处理日志和日志聚合来解决。对于像Hadoop的一样的日志数据和离线分析系统，但又要求实时处理的限制，这是一个可行的解决方案。kafka的目的是通过Hadoop的并行加载机制来统一线上和离线的消息处理，也是为了通过集群机来提供实时的消费。kafka是一种高吞吐量的分布式发布订阅消息系统，有如下特性：通过O(1)的磁盘数据结构提供消息的持久化，这种结构对于即使数以TB的消息存储也能够保持长时间的稳定性能。高吞吐量：即使是非常普通的硬件kafka也可以支持每秒数十万的消息。支持通过kafka服务器和消费机集群来分区消息。支持Hadoop并行数据加载。Elasticsearch相似solrElasticSearch是一个基于Lucene的搜索服务器。它提供了一个分布式多用户能力的全文搜索引擎，基于RESTfulweb接口。Elasticsearch是用Java开发的，并作为Apache许可条款下的开放源码发布，是第二流行的企业搜索引擎。设计用于云计算中，能够达到实时搜索，稳定，可靠，快速，安装使用方便。我们建立一个网站或应用程序，并要添加搜索功能，令我们受打击的是：搜索工作是很难的。我们希望我们的搜索解决方案要快，我们希望有一个零配置和一个完全免费的搜索模式，我们希望能够简单地使用JSON通过HTTP的索引数据，我们希望我们的搜索服务器始终可用，我们希望能够一台开始并扩展到数百，我们要实时搜索，我们要简单的多租户，我们希望建立一个云的解决方案。Elasticsearch旨在解决所有这些问题和更多的问题。SolrSolr是一个独立的企业级搜索应用服务器，它对外提供类似于Web-s