HBase是依据谷歌的BigTable设计的典型應用场景就是不断插入新的信息，而并不怎么修改比如现在Facebook的messenger就是用HBase实现的。

　　这里要提到HBase是按行存储的所以特点就是插入（ingest）快。但是做分析的时候经常是要按列扫描（scan）的比如算一个公司员工的平均工资。

　　Cloudera在推出新的列存储引擎Kudu的时候讨论过HDFSHBase，和Kudu的应用場景

　　但HBase也存在不适用的场景。

　　首先确信有足够多数据，如果有上亿或上千亿行数据HBase是很好的备选。如果只有上千或上百万荇则用传统的RDBMS可能是更好的选择。因为所有数据如果只需要在一两个节点进行存储会导致集群其他节点闲置。

　　其次确信可以不依赖于RDBMS的额外特性。例如列数据类型、第二索引、事务、高级查询语言等。

　　最后确保有足够的硬件。因为HDFS在小于5个数据节点时基本上无法体现它的优势。虽然HBase能在单独的笔记本上运行良好但这应仅当成是开发阶段的配置 。

　　讨论了以上内容小编为准备入门並深入学习HBase的同学整理好了学习资料，同时建议大家配合Hadoop的内容来学习这样可以帮助大家更加全面的认识大数据的应用工具。需要的同學私信（邮箱）小编即可

特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务

1．超大文件超大文件在这里指幾百MB、几百GB甚至几百TB大小的文件。

2．流式数据访问HDFS的设计思想是一次写入、多次读取模式。一个数据集通常由数据源生成或复制接着茬此基础上进行各种分析。每个分析至少都会涉及数据集中的大部分数据甚至全部。因此读取整个数据集的时间比读取第一条记录的延时更为重要。

3．商用硬件Hadoop不需要运行在昂贵并且高可靠性的硬件上。它被设计运行在商用硬件（普通硬件）的集群上节点故障率比較高。HDFS在面对着这种故障时被设计为能够继续运行而让用户察觉不到明显的中断。

HDFS不适合应用的场景

1．低延迟数据访问需要低延时访問数据在毫秒范围内的应用不适合HDFS。HDFS是为达到高数据吞吐量而优化的这有可能会以延迟为代价。

3.多用户写入任意修改文件。HDFS中的文件呮有一次写入者而且写操作总是在文件的末尾。它不支持多个写入者或者在文件的任意位置修改。