hbase应用场景,hbase和hive的差别是什么，各自适用在什么场景中

hbase应用场景,hbase和hive的差别是什么，各自适用在什么场景中详细介绍

本文目录一览： Hbase知识点总结？

hbase概念:
非结构化的分布式的面向列存储非关系型的开源的数据库，根据谷歌的三大论文之一的bigtable
高宽厚表
作用:
为了解决大规模数据集合多重数据种类带来的挑战，尤其是大数据应用难题。
能干什么:
存储大量结果集数据，低延迟的随机查询。
sql:
结构化查询语言
nosql:
非关系型数据库，列存储和文档存储(查询低延迟),hbase是nosql的一个种类，其特点是列式存储。
非关系型数据库--列存储(hbase)
非关系型数据库--文档存储(MongoDB)
非关系型数据库--内存式存储(redis)
非关系型数据库--图形模型(graph)
hive和hbase区别?
Hive的定位是数据仓库，虽然也有增删改查，但其删改查对应的是整张表而不是单行数据，查询的延迟较高。其本质是更加方便的使用mr的威力来进行离线分析的一个数据分析工具。
HBase的定位是hadoop的数据库，电脑培训发现是一个典型的Nosql，所以HBase是用来在大量数据中进行低延迟的随机查询的。
hbase运行方式:
standalonedistrubited
单节点和伪分布式?
单节点:单独的进程运行在同一台机器上
hbase应用场景:
存储海量数据低延迟查询数据
hbase表由多行组成
hbase行一行在hbase中由行健和一个或多个列的值组成，按行健字母顺序排序的存储。

hbase适用于哪些场景

1. 交通方面：
船舶GPS信息，全长江的船舶GPS信息，每天有1千万左右的数据存储。
2. 金融方面：
消费信息，贷款信息，信用卡还款信息等
3. 电商：
淘宝的交易信息等，物流信息，浏览信息等
4. 移动：
通话信息等，都是基于HBase的存储。

hbase不适合哪些应用场景

数据量较小、数据结构复杂、需要高度事务性、需要高度事务性等场景。1、如果数据量较小，使用HBase可能会增加系统的复杂性和成本，不如使用传统的关系型数据库或其他轻量级的NoSQL数据库。2、HBase适合存储结构化数据，但是如果数据结构非常复杂，例如包含大量的嵌套数据结构或非常深的层次结构，使用HBase可能会增加数据处理的复杂性和难度。3、HBase虽然支持ACID事务，但是相比传统的关系型数据库，HBase的事务性能和可靠性可能会有所降低。4、HBase虽然支持基本的查询操作，但是相比传统的关系型数据库，HBase的查询灵活性可能会有所降低。

如何使用HBase构建NewSQL

目前主流的数据库或者NoSQL要么在CAP里面选择AP，比较典型的例子是Cassandra，要么选择CP比如HBase，这两个是目前用得非
常多的NoSQL的实现。我们的价值观一定认为未来是分布式的，一定是尽量倾向于全部都拥有，大部分情况下取舍都是HA，主流的比较顶级的数据库都会选择
C，分布式系统一定逃不过P，所以A就只能选择HA。现在主要领域是数据库的开发，完全分布式，主要方向和谷歌的F1方向非常类似。
目前看NewSQL代表未来(GoogleSpanner、F1、)，HBase在国内有六个Committer，在目
前主流的开源数据库里面几乎是最强的阵容。大家选型的时候会有一个犹豫，到底应该选择HBase还是选Cassandra。根据应用场景，如果需要一致
性，HBase一定是你最好的选择，我推荐HBase。它始终保持强一致，我们非常喜欢一致性，丧失一致性的时候有些错误会特别诡异，很难查。对于
Push-down特性的设计其实比较好，全局上是一个巨大的分布式数据库，但是逻辑上是分成了一个个Region，Region在哪台机器上是明确的。
比如要统计记录的条数，假设数据分布在整个系统里面，对数十亿记录做一个求和操作，就是说不同的机器上都要做一个sum，把条件告诉他要完成哪些任务，他给你任务你再汇总，这是典型的分布式的MPP，做加速的时候是非常有效的。
2015年HBaseConf上面有一句总结:“NothingishotterthanSQL-on-
Hadoop,andnowSQL-
on-HBaseisfastapproachingequalhotnessstatus”，实际上SQL-on-HBase也是非
常火。因为SchemaLess没有约束其实是很吓人的一件事情，当然没有约束也比较爽，就是后期维护十分痛苦，规模进一步扩大了之后又需要迁移
到SQL。
现在无论从品质还是速度上要求已经越来越高，拥有SQL的同时还希望有ACID的东西(OLAP一般不追求一致性)。所以TiDB在设计时就强调这
样的特点：始终保持分布式事务的支持，兼容MySQL协议。无数公司在SQL遇到Scale问题的时候很痛苦地做出了选择，比如迁移到
HBase，Cassandra
MongoDB已经看过太多的公司做这种无比痛苦的事情，现在不用痛苦了，直接迁过来，直接把数据导进来就OK了。TiDB最重要的是关注OLTP，对于
互联网业务来说通常是在毫秒级内就需要返回一个结果。
我们到目前为止开发了六个月，开源了两个月。昨天晚上TiDB达到了第一个Alpha的阶段，现在可以拥有一个强大的数据库：支持分布式事务，始终
保持同步的复制，强大的按需Scale能力，无阻塞的Schema变更。发布第一个Alpha版本的时候以前的质疑都会淡定下来，因为你可以阅读每一行代
码，体验每个功能。选择这个领域也是非常艰难的决定，实在太Hardcore了，当初GoogleSpanner也做了5年。不过我们是真爱，我们就是
技术狂，就是要解决问题，就是要挑大家最头痛的问题去解决。好在目前阿里的OceanBase给我们服了颗定心丸，大家也不会质疑分布式关系型数据库是否
可行。

hbase和hive的差别是什么，各自适用在什么场景中

对于hbase当前noSql数据库的一种，最常见的应用场景就是采集的网页数据的存储，由于是key-value型数据库，可以再扩展到各种key-
value应用场景，如日志信息的存储，对于内容信息不需要完全结构化出来的类CMS应用等。注意hbase针对的仍然是OLTP应用为主。
对
于hive主要针对的是OLAP应用，注意其底层不是hbase，而是hdfs分布式文件系统，重点是基于一个统一的查询分析层，支撑OLAP应用中的各
种关联，分组，聚合类SQL语句。hive一般只用于查询分析统计，而不能是常见的CUD操作，要知道HIVE是需要从已有的数据库或日志进行同步最终入
到hdfs文件系统中，当前要做到增量实时同步都相当困难。
和mysql,oracle完全不是相同的应用场景。这个是结构化数据库，针
对的更多的是结构化，事务一致性要求高，业务规则逻辑复杂，数据模型复杂的企业信息化类应用等。包括互联网应用中的很多业务系统也需要通过结构化数据库来
实现。所以和hbase,hive不是一个层面的东西，不比较。

HBase为什么火？它适用于那些业务场景

hbase和hive的主要区别是：他们对于其内部的数据的存储和管理方式是不同的，hbase其主要特点是仿照bigtable的列势存储，对于大型的数据的存储，查询比传统数据库有巨大的优势，而hive其产生主要应对的数据仓库问题，其将存在在hdfs上的文件目录结构映射成表。主要关注的是对数据的统计等方面。
适合的场景：
hbase：适合大型数据存储，其作用可以类比于传统数据库的作用，主要关注的数据的存取。
hive：适合大数据的管理，统计，处理，其作用类比于传统的数据仓库，主要关注的数据的处理。
总结：应对大数据的时候，如果你偏重于数据存储查询hbase无疑是更加适合，而你关注的是对大数据的处理结果查询，比如你查询的时候有类似于count，sum等函数操作 hive就能满足你的需求，一般有些项目都输在hive里面进行数据处理，然后将结果导入mysql等数据库或者hbase中进行查询，至于mysql与hbase的选择 比较倾向于你的处理之后的数据量

hbase和hive的差别是什么，各自适用在什么场景中

Hive和Hbase是两种基于Hadoop的不同技术--Hive是一种类SQL的引擎，并且运行MapReduce任务，Hbase是一种在Hadoop之上的NoSQL 的Key/vale数据库。当然，这两种工具是可以同时使用的。就像用Google来搜索，用FaceBook进行社交一样，Hive可以用来进行统计查询，HBase可以用来进行实时查询，数据也可以从Hive写到Hbase，设置再从Hbase写回Hive
共同点：
1.hbase与hive都是架构在hadoop之上的。都是用hadoop作为底层存储
区别：
1.Hive是建立在Hadoop之上为了减少MapReduce jobs编写工作的批处理系统，HBase是为了支持弥补Hadoop对实时操作的缺陷的项目 。
2.想象你在操作RMDB数据库，如果是全表扫描，就用Hive+Hadoop,如果是索引访问，就用HBase+Hadoop 。
3.Hive query就是MapReduce jobs可以从5分钟到数小时不止，HBase是非常高效的，肯定比Hive高效的多。
4.Hive本身不存储和计算数据，它完全依赖于HDFS和MapReduce，Hive中的表纯逻辑，就只是表的定义等，即表的元数据。这样就可以将结构化的数据文件映射为一张数据库表，并提供完整的SQL查询功能，并将SQL语句最终转换为MapReduce任务进行运行。
5.hive借用hadoop的MapReduce来完成一些hive中的命令的执行
6.hbase是物理表，不是逻辑表，提供一个超大的内存hash表，搜索引擎通过它来存储索引，方便查询操作。
7.hbase是列存储。
8.hdfs作为底层存储，hdfs是存放文件的系统，而Hbase负责组织文件。
9.hive需要用到hdfs存储文件，需要用到MapReduce计算框架。

以下哪些场景比较适合hbase

HBase适用的场景：大量数据下的实时随机查询，所以以上最适合的答案：A；
当我们对于数据结构字段不够确定或杂乱无章很难按一个概念去进行抽取的数据适合用使用什么数据库？答案是什么，如果我们使用的传统数据库，肯定留有多余的字段，10个不行，20个，但是这个严重影响了质量。并且如果面对大数据库，pt级别的数据，这种浪费更是严重的，那么我们该使用是什么数据库？hbase数个不错的选择，那么我们对于hbase还存在下列问题：
1.Column Family代表什么？
2.HBase通过row和column确定一份数据，这份数据的值可能有多个版本，为什么会存在多个版本？3.查询的时候会显示那个版本？4.它们的存储类型是什么？5.tableName是什么类型？6.RowKey 和 ColumnName是什么类型？7.Timestamp 是什么类型？
8.value 是什么类型？
带着以上几个问题去读下面内容：
引言
团队中使用HBase的项目多了起来，对于业务人员而言，通常并不需要从头搭建、维护一套HBase的集群环境，对于其架构细节也不一定要深刻理解（交由HBase集群维护团队负责），迫切需要的是快速理解基本技术来解决业务问题。最近在XX项目轮岗过程中，尝试着从业务人员视角去看HBase，将一些过程记录下来，期望对快速了解HBase、掌握相关技术来开展工作的业务人员有点帮助。我觉得作为一个初次接触HBase的业务开发测试人员，他需要迫切掌握的至少包含以下几点：深入理解HTable，掌握如何结合业务设计高性能的HTable掌握与HBase的交互，反正是离不开数据的增删改查，通过HBase Shell命令及Java Api都是需要的掌握如何用MapReduce分析HBase里的数据，HBase里的数据总要分析的，用MapReduce是其中一种方式掌握如何测试HBase MapReduce，总不能光写不管正确性吧，debug是需要的吧，看看如何在本机单测debug吧本系列将围绕以上几点展开，篇幅较长，如果是HBase初学者建议边读边练，对于HBase比较熟练的，可以选读下，比如关注下HBase的MapReduce及其测试方法。从一个示例说起传统的关系型数据库想必大家都不陌生，我们将以一个简单的例子来说明使用RDBMS和HBase各自的解决方式及优缺点。以博文为例，RDBMS的表设计如下： 为了方便理解，我们以一些数据示例下 上面的例子，我们用HBase可以按以下方式设计 同样为了方便理解，我们以一些数据示例下，同时用红色标出了一些关键概念，后面会解释 HTable一些基本概念Row key行主键， HBase不支持条件查询和Order by等查询，读取记录只能按Row key（及其range）或全表扫描，因此Row key需要根据业务来设计以利用其存储排序特性（Table按Row key字典序排序如1,10,100,11,2）提高性能。Column Family（列族）在表创建时声明，每个Column Family为一个存储单元。在上例中设计了一个HBase表blog，该表有两个列族：article和author。Column（列）HBase的每个列都属于一个列族，以列族名为前缀，如列article:title和article:content属于article列族，author:name和author:nickname属于author列族。Column不用创建表时定义即可以动态新增，同一Column Family的Columns会群聚在一个存储单元上，并依Column key排序，因此设计时应将具有相同I/O特性的Column设计在一个Column Family上以提高性能。同时这里需要注意的是：这个列是可以增加和删除的，这和我们的传统数据库很大的区别。所以他适合非结构化数据。TimestampHBase通过row和column确定一份数据，这份数据的值可能有多个版本，不同版本的值按照时间倒序排序，即最新的数据排在最前面，查询时默认返回最新版本。如上例中row key=1的author:nickname值有两个版本，分别为1380011对应的“一叶渡江”和1380030对应的“yedu”（对应到实际业务可以理解为在某时刻修改了nickname为yedu，但旧值仍然存在）。Timestamp默认为系统当前时间（精确到毫秒），也可以在写入数据时指定该值。Value每个值通过4个键唯一索引，tableName+RowKey+ColumnKey+Timestamp=>value，例如上例中{tableName=’blog’,RowKey=’1’,ColumnName=’author:nickname’,Timestamp=’ 1380030’}索引到的唯一值是“yedu”。存储类型TableName 是字符串RowKey 和 ColumnName 是二进制值（Java 类型 byte[]）Timestamp 是一个 64 位整数（Java 类型 long）value 是一个字节数组（Java类型 byte[]）。存储结构可以简单的将HTable的存储结构理解为 即HTable按Row key自动排序，每个Row包含任意数量个Columns，Columns之间按Column key自动排序，每个Column包含任意数量个Values。理解该存储结构将有助于查询结果的迭代。话说什么情况需要HBase半结构化或非结构化数据对于数据结构字段不够确定或杂乱无章很难按一个概念去进行抽取的数据适合用HBase。以上面的例子为例，当业务发展需要存储author的email，phone，address信息时RDBMS需要停机维护，而HBase支持动态增加.记录非常稀疏RDBMS的行有多少列是固定的，为null的列浪费了存储空间。而如上文提到的，HBase为null的Column不会被存储，这样既节省了空间又提高了读性能。多版本数据如上文提到的根据Row key和Column key定位到的Value可以有任意数量的版本值，因此对于需要存储变动历史记录的数据，用HBase就非常方便了。比如上例中的author的Address是会变动的，业务上一般只需要最新的值，但有时可能需要查询到历史值。超大数据量当数据量越来越大，RDBMS数据库撑不住了，就出现了读写分离策略，通过一个Master专门负责写操作，多个Slave负责读操作，服务器成本倍增。随着压力增加，Master撑不住了，这时就要分库了，把关联不大的数据分开部署，一些join查询不能用了，需要借助中间层。随着数据量的进一步增加，一个表的记录越来越大，查询就变得很慢，于是又得搞分表，比如按ID取模分成多个表以减少单个表的记录数。经历过这些事的人都知道过程是多么的折腾。采用HBase就简单了，只需要加机器即可，HBase会自动水平切分扩展，跟Hadoop的无缝集成保障了其数据可靠性（HDFS）和海量数据分析的高性能（MapReduce）。

hbase是怎样删除和修改数据的，和oracle这类传统的rdbms有什么区别

简单来说，传统关系型数据库的修改与删除，可以快速通过主键、列或索引直接锁定到某一行或某些行，进行物理删除。
而对于Hbase来说，受到hdfs文件系统的局限（hdfs文件系统不能修改，添加也很不方便），进行CRUD的操作就会变得相对复杂。
Hbase的修改，是根据某个行键添加一行数据，并未这行数据生成一个较新的时间戳来实现，每个行键都会对应多个时间戳的数据，那么最新的时间戳就是最终修改后的内容。
而删除则是通过标记来实现，如果要删除某行记录，Hbase会添加一个带有删除标记的行，通过这个删除标记来辨认该行建的数据是否删除。
Hbase与关系型数据库的区别：
1、场景
Hbase是面向列的数据库，适合大量的插入的同时又要具备不俗的读功能，而Oracle或其他关系型数据库适合处理比较复杂的业务关系或事务处理，而且，在数据在一定量级下都会有良好的表现，并不是所有业务的数据压力都会发生比较极端的情况。
2、索引
Hbase只能做主键索引，而关系型数据库可以根据需求不同加入适合的索引机制，供用户查询。
3、瓶颈
Hbase的瓶颈是硬盘的传输速度，Oracle的瓶颈是硬盘的寻道时间（可以看做是硬盘的转数）。
4、业务
Hbase适合按照时间排序的业务，而Oracle或其他关系型数据库应用比较广泛，如OLTP或OLAP