HDFS Hive HBase MongoDB Redis elasticsearch

HDFS：   Hadoop 的分布式文件系统称为 HDFS，它是为以流式数据访问模式存储超大文件而设计的文件系统。 HDFS适合： 存储并管理PB级数据 处理非结构化数据 注重数据处理的吞吐量 应用模式为：一次写多次读 不适合： 存储小文件 大量的随机度 需要修改文件 总结： HDFS 是设计成适应一次写入，多次读出的场景，且不支持文件的修改。 正因为如此，HDFS 适合用来做大数据分析的底层存储服务，并不适合用来做.网盘等应用，因为，修改不方便，延迟大，网络开销大，成本太高。 一次写入，多次读出的场景。支持数据在文件尾追加。不支持在文件中间追加或修改。   Hive：        Hive是建立在Hadoop之上为了减少MapReduce jobs编写工作的批处理系统，HBase是为了支持弥补Hadoop对实时操作的缺陷的项目 。 它建立在Hadoop之上的数据仓库软件工具，它提供了一系列的工具，帮助用户对大规模的数据进行提取、转换和加载，即通常所称的ETL(Extraction，Transformation，and Loading)操作。Hive可以直接访问存储在HDFS或者其他存储系统(如Hase)中的数据，然后将这些数据组织成表的形式，在其上执行ETL操作。 　　Hive定义了简单的类SQL查询语言，称为HiveSQL，它允许熟悉SQL的用户使用HiveSQL在大规模数据集上进行数据查询、数据分析等操作。从本质上讲，Hive就是一SQL解释器，它能够将用户输入的HiveSQL语句转换成MapReduce作业在Hadoop集群上执行，以达到快速查询的目的。Hive通过内置的Mapper和Reducer来执行数据分析操作，同时Hive也允许熟悉MapReduce编程框架的用户使用Hive提供的编程接口实现自己的Mapper和Reducer来处理内置的Mapper和Reducer无法完成的复杂数据分析工作。 　　Hive的设计目标是，通过类SQL的语言实现在大规模数据集上快速的数据查询等操作，而不需要开发相应的MapReduce程序，所以Hive特别适合数据仓库的统计分析。Hive最初由Facebook开发实现，Facebook使用Hive来分析日益增长的日志数据。后来Facebook将Hive作为开源项目贡献给Apache基金会，如今Hive已经是Apache下的顶级开源项目，而且在很多大型企业得大了广泛使用，包括淘宝、腾讯等。 　　Hive构建在基于静态批处理的Hadoop之上，Hadoop通常都有较高的延迟并且在作业提交和调度的时候需要大量的开销。因此，Hive并不能够在大规模数据集上实现低延迟快速的查询，例如，Hive在几百MB的数据集上执行查询一般有分钟级的时间延迟。因此，Hive并不适合那些需要低延迟的应用，例如，联机事务处理(OLTP)。 　　Hive查询操作过程严格遵守Hadoop MapReduce的作业执行模型，Hive将用户的HiveSQL语句通过解释器转换为MapReduce作业提交到Hadoop集群上，Hadoop监控作业执行过程，然后，返回作业执行结果给用户。Hive并非为联机事务处理而设计，Hive并不提供实时的查询和基于行级的数据更新操作。Hive的最佳使用场合是大数据集的批处理作业，例如，网络日志分析。　   HBase：   HBase是一个分布式、面向列的开源非关系型数据库（NoSQL），基于HDFS文件系统之上，支持记录级别的高效读写，不适合离线分析场景。 适合结构简单，但数据量非常大的的数据（通常在TB/PB），查询条件简单，列与列之间联系不大的轻查询应用场景，如历史订单记录，日志数据，监控数据等。每一行数据定义一个key，提供了简单的基于key值的快速查询能力，查询灵活性较弱。 数据会按照列进行分组和存储，同一列的数据存储在同一个地方，若干列又构成一个列族，一个列族的所有列存储在同一个底层的存储文件里，这个存储文件叫做HFile。列族需要在表创建的时候定义好，并且不能修改的太频繁，数量也不能太多。   MongoDB：   MongoDB 是由C++语言编写的，是一个基于分布式文件存储的开源数据库系统。将数据存储为一个文档，数据结构由键值(key->value)对组成。MongoDB 文档类似于 JSON 对象。字段值可以包含其他文档，数组及文档数组。 模式自由，表结构灵活可变，字段类型可以随时修改。修改很方便，不适合多表查询、复杂事务等高级操作。 很适合那些表结构经常改变，数据的逻辑结构没那么复杂不需要多表查询操作，数据量又比较大的应用场景。   Redis： Redis 是完全开源免费的，遵守BSD协议，是一个高性能的key-value数据库。 速度快，读写性能优异；支持数据持久化；数据结构丰富，如list，set；支持主从复制备份；支持事务，操作都是原子性；数据存储在内存中，不能用作海量数据的高性能读写，主要局限在较小数据量的高性能操作和运算上；查询依赖key，不能进行复杂的查询。 适合那些对读写性能要求极高，且数据表结构简单（key-value、list、set之类）、查询条件也同样简单的应用场景。 1、会话缓存（Session Cache）        最常用的一种使用 Redis 的情景是会话缓存（session cache）。用 Redis 缓存会 话比其他存储（如 Memcached）的优势在于：Redis 提供持久化。当维护一个不 是严格要求一致性的缓存时，如果用户的购物车信息全部丢失，大部分人都会不 高兴的，现在，他们还会这样吗？ 幸运的是，随着 Redis 这些年的改进，很容 易找到怎么恰当的使用 Redis 来缓存会话的文档。甚至广为人知的商业平台 Magento 也提供 Redis 的插件。 2、全页缓存（FPC）         除基本的会话 token 之外，Redis 还提供很简便的 FPC 平台。回到一致性问题， 即使重启了 Redis 实例，因为有磁盘的持久化，用户也不会看到页面加载速度的 下降，这是一个极大改进，类似 PHP 本地 FPC。 再次以 Magento 为例，Magento 提供一个插件来使用 Redis 作为全页缓存后端。 此外，对 WordPress 的用户来 说，Pantheon 有一个非常好的插件 wp-redis，这个插件能帮助你以最快速度加 载你曾浏览过的页面。 3、队列         Reids 在内存存储引擎领域的一大优点是提供 list 和 set 操作，这使得 Redis 能作为一个很好的消息队列平台来使用。Redis 作为队列使用的操作，就类似于本 地程序语言（如 Python）对 list 的 push/pop 操作。 如果你快速的在 Google 中搜索“Redis queues”，你马上就能找到大量的开源项目，这些项目的目的就 是利用 Redis 创建非常好的后端工具，以满足各种队列需求。例如，Celery 有一 个后台就是使用 Redis 作为 broker，你可以从这里去查看。 4，排行榜/计数器          Redis 在内存中对数字进行递增或递减的操作实现的非常好。集合（Set）和有序 集合（Sorted Set）也使得我们在执行这些操作的时候变的非常简单，Redis 只是 正好提供了这两种数据结构。所以，我们要从排序集合中获取到排名最靠前的 10 个用户–我们称之为“user_scores”，我们只需要像下面一样执行即可： 当然， 这是假定你是根据你用户的分数做递增的排序。如果你想返回用户及用户的分数， 你需要这样执行： ZRANGE user_scores 0 10 WITHSCORES Agora Games 就 是一个很好的例子，用 Ruby 实现的，它的排行榜就是使用 Redis 来存储数据的， 你可以在这里看到。 5、发布/订阅          最后（但肯定不是最不重要的）是 Redis 的发布/订阅功能。发布/订阅的使用场景 确实非常多。我已看见人们在社交网络连接中使用，还可作为基于发布/订阅的脚 本触发器，甚至用 Redis 的发布/订阅功能来建立聊天系统！   ES：   Elasticsearch是一个开源的高扩展的分布式全文检索引擎，它可以近乎实时的存储、检索数据；本身扩展性很好，可以扩展到上百台服务器，处理PB级别的数据。 自动对字段建立索引，支持高性能的复杂聚合查询，适合数据分析；字段类型无法修改，写入性能较低，高硬件资源消耗。 （1）分布式的搜索引擎和数据分析引擎 搜索：百度，网站的站内搜索，IT系统的检索 数据分析：电商网站，最近7天牙膏这种商品销量排名前10的商家有哪些；新闻网站，最近1个月访问量排名前3的新闻版块是哪些 分布式，搜索，数据分析 （2）全文检索，结构化检索，数据分析 全文检索：我想搜索商品名称包含牙膏的商品，select * from products where product_name like "%牙膏%" 结构化检索：我想搜索商品分类为日化用品的商品都有哪些，select * from products where category_id='日化用品' 部分匹配、自动完成、搜索纠错、搜索推荐 数据分析：我们分析每一个商品分类下有多少个商品，select category_id,count(*) from products group by category_id （3）对海量数据进行近实时的处理 分布式：ES自动可以将海量数据分散到多台服务器上去存储和检索 海联数据的处理：分布式以后，就可以采用大量的服务器去存储和检索数据，自然而然就可以实现海量数据的处理了 近实时：检索个数据要花费1小时（这就不要近实时，离线批处理，batch-processing）；在秒级别对数据进行搜索和分析 跟分布式/海量数据相反的：lucene，单机应用，只能在单台服务器上使用，最多只能处理单台服务器可以处理的数据量