1. HDFS

HDFS是Hadoop应用程序中主要的分布式储存系统， HDFS集群包含了一个NameNode（主节点），这个节点负责管理所有文件系统的元数据及存储了真实数据的DataNode（数据节点，可以有很多）。HDFS针对海量数据所设计，所以相比传统文件系统在大批量小文件上的优化，HDFS优化的则是对小批量大型文件的访问和存储。

2. MapReduce

Hadoop MapReduce是一个软件框架，用以轻松编写处理海量（TB级）数据的并行应用程序，以可靠和容错的方式连接大型集群中上万个节点（商用硬件）。

3. HBase

Apache HBase是Hadoop数据库，一个分布式、可扩展的大数据存储。它提供了大数据集上随机和实时的读/写访问，并针对了商用服务器集群上的大型表格做出优化——上百亿行，上千万列。其核心是Google Bigtable论文的开源实现，分布式列式存储。就像Bigtable利用GFS（Google File System）提供的分布式数据存储一样，它是Apache Hadoop在HDFS基础上提供的一个类Bigatable。

4. Cassandra

Apache Cassandra是一个高性能、可线性扩展、高有效性数据库，可以运行在商用硬件或云基础设施上打造完美的任务关键性数据平台。在横跨数据中心的复制中，Cassandra同类最佳，为用户提供更低的延时以及更可靠的灾难备份。通过log-structured update、反规范化和物化视图的强支持以及强大的内置缓存，Cassandra的数据模型提供了方便的二级索引（column indexe）。

5. Hive

Apache Hive是Hadoop的一个数据仓库系统，促进了数据的综述（将结构化的数据文件映射为一张数据库表）、即席查询以及存储在Hadoop兼容系统中的大型数据集分析。Hive提供完整的SQL查询功能——HiveQL语言，同时当使用这个语言表达一个逻辑变得低效和繁琐时，HiveQL还允许传统的Map/Reduce程序员使用自己定制的Mapper和Reducer。

6. Pig

Apache Pig是一个用于大型数据集分析的平台，它包含了一个用于数据分析应用的高级语言以及评估这些应用的基础设施。Pig应用的闪光特性在于它们的结构经得起大量的并行，也就是说让它们支撑起非常大的数据集。Pig的基础设施层包含了产生Map-Reduce任务的编译器。Pig的语言层当前包含了一个原生语言——Pig Latin，开发的初衷是易于编程和保证可扩展性。

7. Chukwa

Apache Chukwa是个开源的数据收集系统，用以监视大型分布系统。建立于HDFS和Map/Reduce框架之上，继承了Hadoop的可扩展性和稳定性。Chukwa同样包含了一个灵活和强大的工具包，用以显示、监视和分析结果，以保证数据的使用达到最佳效果。

8. Ambari

Apache Ambari是一个基于web的工具，用于配置、管理和监视Apache Hadoop集群，支持Hadoop HDFS,、Hadoop MapReduce、Hive、HCatalog,、HBase、ZooKeeper、Oozie、Pig和Sqoop。Ambari同样还提供了集群状况仪表盘，比如heatmaps和查看MapReduce、Pig、Hive应用程序的能力，以友好的用户界面对它们的性能特性进行诊断。

9. ZooKeeper

Apache ZooKeeper是一个针对大型分布式系统的可靠协调系统，提供的功能包括：配置维护、命名服务、分布式同步、组服务等。ZooKeeper的目标就是封装好复杂易出错的关键服务，将简单易用的接口和性能高效、功能稳定的系统提供给用户。

10. Sqoop

Sqoop是一个用来将Hadoop和关系型数据库中的数据相互转移的工具，可以将一个关系型数据库中数据导入Hadoop的HDFS中，也可以将HDFS中数据导入关系型数据库中。

11. Oozie

Apache Oozie是一个可扩展、可靠及可扩充的工作流调度系统，用以管理Hadoop作业。Oozie Workflow作业是活动的Directed Acyclical Graphs（DAGs）。Oozie Coordinator作业是由周期性的Oozie Workflow作业触发，周期一般决定于时间（频率）和数据可用性。Oozie与余下的Hadoop堆栈结合使用，开箱即用的支持多种类型Hadoop作业（比如：Java map-reduce、Streaming map-reduce、Pig、 Hive、Sqoop和Distcp）以及其它系统作业（比如Java程序和Shell脚本）。

12. Mahout

Apache Mahout是个可扩展的机器学习和数据挖掘库，当前Mahout支持主要的4个用例：

• 推荐挖掘：搜集用户动作并以此给用户推荐可能喜欢的事物。
• 聚集：收集文件并进行相关文件分组。
• 分类：从现有的分类文档中学习，寻找文档中的相似特征，并为无标签的文档进行正确的归类。
• 频繁项集挖掘：将一组项分组，并识别哪些个别项会经常一起出现。

13. HCatalog

Apache HCatalog是Hadoop建立数据的映射表和存储管理服务，它包括：

• 提供一个共享模式和数据类型机制。
• 提供一个抽象表，这样用户就不需要关注数据存储的方式和地址。
• 为类似Pig、MapReduce及Hive这些数据处理工具提供互操作性。

1. 集群配置文件conf/master中添加secondarynamenode的机器
2. 修改/添加 hdfs-site.xml中如下属性：
   
   

摘取了一部分，全文请查看

http://blog.sina.com.cn/s/blog_633f4ab20100r9nm.html

背景

“这是最好的时代，也是最坏的时代。” 

每个时代的人都在这么形容自己所处的时代。在一次次IT浪潮下面，有人觉得当下乏味无聊，有人却能锐意进取，找到突破。数据存储这个话题自从有了计算机之后，就一直是一个有趣或者无聊的主题。上世纪七十年代，关系数据库理论的出现，造就了一批又一批传奇，并推动整个世界信息化到了一个新的高度。而进入新千年以来，随着SNS等应用的出现，传统的SQL数据库已经越来越不适应海量数据的处理了。于是，这几年NoSQL数据库的呼声也越来越高。

在NoSQL数据库当中，呼声最高的是HBase和Cassandra两个。虽然严格意义上来说，两者服务的目的有所不同，侧重点也不尽相同，但是作为当前开源NoSQL数据库的佼佼者，两者经常被用来做各种比较。

去年十月，Facebook推出了他的新的Message系统。Facebook宣布他们采用HBase作为后台存储系统。这引起了一片喧哗声。因为Cassandra恰恰是Facebook开发，并且于2008年开源。这让很多人惊呼，是否是Cassandra已经被Facebook放弃了？HBase在这场NoSQL数据库的角力当中取得了决定性的胜利？本文打算主要从技术角度分析，HBase和Cassandra的异同，并非要给出任何结论，只是共享自己研究的一些结果。

选手简介

HBase

HBase是一个开源的分布式存储系统。他可以看作是Google的Bigtable的开源实现。如同Google的Bigtable使用Google File System一样，HBase构建于和Google File System类似的Hadoop HDFS之上。

Cassandra

Cassandra可以看作是Amazon Dynamo的开源实现。和Dynamo不同之处在于，Cassandra结合了Google Bigtable的ColumnFamily的数据模型。可以简单地认为，Cassandra是一个P2P的，高可靠性并具有丰富的数据模型的分布式文件系统。

分布式文件系统的指标

根据UC Berkeley的教授Eric Brewer于2000年提出猜测- CAP定理，一个分布式计算机系统，不可能同时满足以下三个指标：

Brewer教授推测，任何一个系统，同时只能满足以上两个指标。

在2002年，MIT的Seth Gilbert和Nancy Lynch发表正式论文论证了CAP定理。

而HBase和Cassandra两者都属于分布式计算机系统。但是其设计的侧重点则有所不同。HBase继承于Bigtable的设计，侧重于CA。而Cassandra则继承于Dynamo的设计，侧重于AP。

特性比较

由于HBase和Cassandra的数据模型比较接近，所以这里就不再比较两者之间数据模型的异同了。接下来主要比较双方在数据一致性、多拷贝复制的特性。

HBase

HBase保证写入的一致性。当一份数据被要求复制N份的时候，只有N份数据都被真正复制到N台服务器上之后，客户端才会成功返回。如果在复制过程中出现失败，所有的复制都将失败。连接上任何一台服务器的客户端都无法看到被复制的数据。HBase提供行锁，但是不提供多行锁和事务。HBase基于HDFS，因此数据的多份复制功能和可靠性将由HDFS提供。HBase和MapReduce天然集成。

Cassandra

写入的时候，有多种模式可以选择。当一份数据模式被要求复制N份的时候，可以立即返回，可以成功复制到一个服务器之后返回，可以等到全部复制到N份服务器之后返回，还可以设定一个复制到quorum份服务器之后返回。Quorum后面会有具体解释。复制不会失败。最终所有节点数据都将被写入。而在未被完全写入的时间间隙，连接到不同服务器的客户端有可能读到不同的数据。在集群里面，所有的服务器都是等价的。不存在任何一个单点故障。节点和节点之间通过Gossip协议互相通信。写入顺序按照timestamp排序，不提供行锁。新版本的Cassandra已经集成了MapReduce了。

相对于配置Cassandra，配置HBase是一个艰辛、复杂充满陷阱的工作。Facebook关于为何采取HBase，里面有一句，大意是，Facebook长期以来一直关注HBase的开发并且有一只专门的经验丰富的HBase维护的team来负责HBase的安装和维护。可以想象，Facebook内部关于使用HBase和Cassandra有过激烈的斗争，最终人数更多的HBase team占据了上风。对于大公司来说，养一只相对庞大的类似DBA的team来维护HBase不算什么大的开销，但是对于小公司，这实在不是一个可以负担的起的开销。

另外HBase在高可靠性上有一个很大的缺陷，就是HBase依赖HDFS。HDFS是Google File System的复制品，NameNode是HDFS的单点故障点。而到目前为止，HDFS还没有加入NameNode的自我恢复功能。不过我相信，Facebook在内部一定有恢复NameNode的手段，只是没有开源出来而已。

相反，Cassandra的P2P和去中心化设计，没有可能出现单点故障。从设计上来看，Cassandra比HBase更加可靠。

关于数据一致性，实际上，Cassandra也可以以牺牲响应时间的代价来获得和HBase一样的一致性。而且，通过对Quorum的合适的设置，可以在响应时间和数据一致性得到一个很好的折衷值。

主要表现在：

配置简单，不需要多模块协同操作。功能灵活性强，数据一致性和性能之间，可以根据应用不同而做不同的设置。 可靠性更强，没有单点故障。

尽管如此，Cassandra就没有弱点吗？当然不是，Cassandra有一个致命的弱点。

这就是存储大文件。虽然说，Cassandra的设计初衷就不是存储大文件，但是Amazon的S3实际上就是基于Dynamo构建的，总是会让人想入非非地让Cassandra去存储超大文件。而和Cassandra不同，HBase基于HDFS，HDFS的设计初衷就是存储超大规模文件并且提供最大吞吐量和最可靠的可访问性。因此，从这一点来说，Cassandra由于背后不是一个类似HDFS的超大文件存储的文件系统，对于存储那种巨大的（几百T甚至P）的超大文件目前是无能为力的。而且就算由Client手工去分割，这实际上是非常不明智和消耗Client CPU的工作的。

因此，如果我们要构建一个类似Google的搜索引擎，最少，HDFS是我们所必不可少的。虽然目前HDFS的NameNode还是一个单点故障点，但是相应的Hack可以让NameNode变得更皮实。基于HDFS的HBase相应地，也更适合做搜索引擎的背后倒排索引数据库。事实上，Lucene和HBase的结合，远比Lucene结合Cassandra的项目Lucandra要顺畅和高效的多。（Lucandra要求Cassandra使用OrderPreservingPartitioner,这将可能导致Key的分布不均匀，而无法做负载均衡，产生访问热点机器）。

所以我的结论是，在这个需求多样化的年代，没有赢者通吃的事情。而且我也越来越不相信在工程界存在一劳永逸和一成不变的解决方案。当你仅仅是存储海量增长的消息数据，存储海量增长的图片，小视频的时候，你要求数据不能丢失，你要求人工维护尽可能少，你要求能迅速通过添加机器扩充存储，那么毫无疑问，Cassandra现在是占据上风的。

但是如果你希望构建一个超大规模的搜索引擎，产生超大规模的倒排索引文件（当然是逻辑上的文件，真实文件实际上被切分存储于不同的节点上），那么目前HDFS+HBase是你的首选。

就让这个看起来永远正确的结论结尾吧，上帝的归上帝，凯撒的归凯撒。大家都有自己的地盘，野百合也会有春天的！

1.       移动设备战争

移动设备多样化，Windows仅仅是IT需要支持的多种环境之一,IT需要支持多样化环境。

2.       移动应用与HTML5

HTML5将变得愈发重要，以满足多元化的需求，以满足对安全性非常看重的企业级应用。

3.       个人云

个人云将把重心从客户端设备向跨设备交付基于云的服务转移。

4.       企业应用商店

有了企业应用商店，IT的角色将从集权式规划者转变为市场管理者，并为用户提供监管和经纪服务，甚至可能为应用程序专家提供生态系统支持。

5.       物联网

物联网是一个概念，描述了互联网将如何作为物理实物扩展，如消费电子设备和实物资产都连接到互联网上。

6.       混合型IT和云计算

打造私有云并搭建相应的管理平台，再利用该平台来管理内外部服务

7.       战略性大数据

企业应当将大数据看成变革性的构架，用多元化数据库代替基于同质划分的关系数据库。

8.       可行性分析

大数据的核心在于为企业提供可行的创意。受移动网络、社交网络、海量数据等因素的驱动，企业需要改变分析方式以应对新观点

9.       内存计算

内存计算以云服务的形式提供给内部或外部用户,数以百万的事件能在几十毫秒内被扫描以检测相关性和规律。

10.    整合生态系统

市场正在经历从松散耦合的异构系统向更为整合的系统和生态系统转移，应用程序与硬件、软件、软件及服务打包形成整合生态系统。

结合应用实践及客户需求，可以有以下结论：

1.       大数据时代已经到来

       物联网发展及非结构化、半结构化数据的剧增推动了大数据应用需求发展。大数据高效应用是挖掘企业数据资源价值的趋势与发展方向。

2.       云计算依旧是主题，云将更加关注个体

       云计算是改变IT现状的核心技术之一，云计算将是大数据、应用商店交付的基础。个人云的发展将促使云端服务更关注个体。

3.       移动趋势，企业应用商店将改变传统软件交付模式

       Windows将逐步不再是客户端主流平台，IT技术需要逐步转向支持多平台服务。在云平台上构建企业应用商店，逐步促成IT的角色将从集权式规划者转变为应用市场管理者

4.       物联网将持续改变工作及生活方式

       物联网将改变生活及工作方式，物联网将是一种革新的力量。在物联网方向，IPV6将是值得研究的一个技术。

未来企业IT架构图如下：

架构说明：

1.应用将被拆分，客户端将变得极简，用户只需要关注极小部分和自己有关的内容，打开系统后不再是上百个业务菜单。

2.企业后端架构将以分布式架构为主，大数据服务能力将成为企业核心竞争力的集中体现。

3.非结构化数据处理及分析相关技术将会得到前所未有的重视。

受个人水平有限，仅供参考，不当之处，欢迎拍砖！

http://blog.csdn.net/sdhustyh/article/details/8484780