hbase存储数据结构
A. 做一个网站，把数据保存在xml文件中，跟把数据保存在数据库中，区别有多大
实话实说，个人接触到使用Xml文件方式来保存数据的场景少之又少。除去求学期间根据课堂要求做静态网站时用于存储一些展示性数据，还有就是在WPF开发中保存一些常用但又不经常变化的离线数据。反而常使用Xml来做配置文件（例如SpringMvc、MyBatis和LogBack）网络数据传输和交互标准（例如WebService）、工作流设计（例如Activiti6）等情况较为常见。
Xml用于单设备数据存储的情况还说得过去，例如离线数据同步可以放在Xml数据文件中。在传统行业电商平台的规格，材质，产区等属性相对固定，Xml文件能很好胜任。再比如做一个内部使用的抽奖程序，将潜在用户群体以Xml方式保存也是不错的选择吧。所以Xml文件充当小型离线数据库还行。
而数据库的范围就比较宽泛，大致可以分为关系型数据库和非关系型数据库两大类。
关系型数据库以Oracle和Mysql最为流困念渣行，学过编程的朋友应该耳熟能详，也是职场面试经久不衰的考察重点。
而NoSql算是后起之秀。在业务繁多复杂的当下，一些场景下关系型数据库应付起来相当吃力，有着更为复杂分类的非关系型数据库孕育而生。NoSql在搜索引擎（ElasticSearch）、键值（redis）、面向文档（Mongodb）和列存储（Hbase）等方面都能做高拆到得心应手。这些就让其有着更强的业务针对性，相比传统关系型数据库有着质的提升。下面简单列举几个应用场景。
Redis可用于计数、分布式锁实现、单点登录、限流和缓存数据等；
在复杂页面的数据不便以表数据结构保存时，使用Mongodb整页存储方便又简单；
Elasticsearch就是以空间换时间典型代表，在做搜索引擎和日志记录（ELK）等方面有很大优势；
Hbase不必再像关系型数据库那样以行为存储单元，而是以列为基准，非常便于数据结构拓展。
当下流行徽服务和各种解耦，连关系型数据库都不再设计外键关系，非关系型数据库大行其道，Xml文件用来汪悄保存数据显然已经不合时宜，当然也不能否认关系型数据库的地位和Xml的作用。重要数据或某些行业的特殊性还是要以关系型数据库为根基，毕竟事务、稳定性、安全性和技术恢复支持等方面需要考虑的重点。
B. HBase是什么为什么要使用HBase
HBase在产品中还包含了Jetty，在HBase启动时采用嵌入式的方式来启动Jetty，因此可以通过web界面对HBase进行管理和查看当前运行的一些状态，非常轻巧。为什么采用HBase？HBase 不同于一般的关系数据库,它是一个适合于非结构化数据存储的数据库.所谓非结构化数据存储就是说HBase是基于列的而不是基于行的模式，这样方面读写你的大数据内容。 HBase是介于Map Entry(key & value)和DB Row之间的一种数据存储方式。就点有点类似于现在流行的Memcache，但不仅仅是简单的一个key对应一个 value，你很可能需要存储多个属性的数据结构，但没有传统数据库表中那么多的关联关系，这就是所谓的松散数据。 简单来说，你在HBase中的表创建的可以看做是一张很大的表，而这个表的属性可以根据需求去动态增加，在HBase中没有表与表之间关联查询。你只需要 告诉你的数据存储到Hbase的那个column families 就可以了，不需要指定它的具体类型：char,varchar,int,tinyint,text等等。但是你需要注意HBase中不包含事务此类的功 能。 Apache HBase 和Google Bigtable 有非常相似的地方，一个数据行拥有一个可选择的键和任意数量的列。表是疏松的存储的，因此用户可以给行定义各种不同的列，对于这样的功能在大项目中非常实用，可以简化设计和升级的成本。
C. hbase的核心数据结构是什么
hbase的核心数据结构为LSM树。
LSM树分为内存部分和磁盘部分。
内存部分是一个维护有序数据集合的数据结构。一般来讲，内存数据结构可以选择平衡二叉树、红黑树、跳跃表（SkipList）等维护有序集的数据结构，由于考虑并发性能，HBase选择了表现更优秀的跳跃表。
磁盘部渣扒分是由一个个独立的文件组成败梁困，每一个文件又是由一个个数据块组成。对于数据存储在磁盘上的数据库系统来说，磁盘寻道以及数据读取都是非常耗时的操作（简称IO耗时）。为了避免不必要的IO耗时，可以在磁盘中存储一些额外的二进制数据，这些数据用来判断对于给定的key是否有可能存储在这个数据块中，这个数据结构称为布隆过滤器（察念BloomFilter）。
LSM树介绍：
LSM树是一种磁盘数据的索引结构。LSM树的索引对写入请求更友好。因为无论是何种写入请求，LSM树都会将写入操作处理为一次顺序写，而HDFS擅长的正是顺序写（且HDFS不支持随机写）。
一个LSM树的索引内存部分是一个ConcurrentSkipListMap，Key是rowkey、column family、qualifier、type以及timestamp， Value是字节数组。随着数据不断写入MemStore，一旦内存超过阈值会将数据flush到磁盘，生产HFile；多个小HFile文件会compact成一个大HFile。
D. 为什么hbase当中不要索引
实际上，HBase中也有索引机制，比如可以通过建立二级索引来提高数据的查询效率。但是，HBase中的索引机制与传统的关系型数据库的索引机制有所不同。
传统的关系型数据库索引机制通常使用B树等数据结构来实现，姿数这种索引机制的优点是查询效率较高，缺点是索引数据量大时，维护索引的开销也会随之增加。而HBase中的数据存储是友察基于列族（column family）和行键（row key）的，HBase的数据存储结构是按行键排序的有序映射表，可以通过行键的前缀匹配来检索数据。因此，在HBase中，使用行键来查询数据的效率很高，而使用列来查询数据的效率相对较低。因此，为了提高查询效率，通常需要在设计HBase数据模型时，合理设置行键和列族，而迹告首不是使用传统关系型数据库中常用的各种索引。
另外，如果在HBase中使用过多的索引，会增加存储和维护的成本，可能会对HBase的性能和可伸缩性产生负面影响。因此，在使用HBase时，需要根据实际情况合理使用索引，权衡索引的优劣和使用成本。
E. 怎么形象的理解Hbase数据结构
联系：视图（view）是在基本表之上建立的表，它的结构（即所定义的列）和内容（即所有数据行）都来自基本表，它依据基本表存在而存在。一个视图可以对应一个基本表，也可以对应多个基本表。视图是基本表的抽象和在逻辑意义上建立的新关系区别：1、视图是已经编译好的扮旦sql语句。而表不是2、视图没有实际的物理记录。而表有。3、表是内容，视图是窗口4、表只用物理空间而视图不占用物理空间雹基，视图只是逻辑概念的存在，表可以及时四对它进行修改，但视图只能有创建的语句来修改5、表是内模式，视图是外模式6、视图是查看数据表的一种方法，可以查询数据表中某些字段构成的数据，只是一些SQL语句的集合。从安全的角厅肆扰度说，视图可以不给用户接触数据表，从而不知道表结构。7、表属于全局模式中的表，是实表；视图属于局部模式的表，是虚表。8、视图的建立和删除只影响视图本身，不影响对应的基本表。
F. hbase不适合哪些应用场景
数据量较小、数据结构复杂、需要高度事务性、需要高度事务性等场景。
1、如果数据谨旁贺量较小，使用HBase可能会增加系统的复杂性和成本，不如使用传统的关系型数据库或其他轻量级的NoSQL数据库。
2、祥派HBase适合存储结构化数据，但是如果数据结构非常复杂，例如包含大量的嵌套数据结构或非常深的层次结构，使用HBase可能会增加数据处理启态的复杂性和难度。
3、HBase虽然支持ACID事务，但是相比传统的关系型数据库，HBase的事务性能和可靠性可能会有所降低。
4、HBase虽然支持基本的查询操作，但是相比传统的关系型数据库，HBase的查询灵活性可能会有所降低。
G. HBase数据结构是什么
RowKey
与nosql数据库们一样,RowKey是用来检索记录的主键。访问HBASE table中的行，只有三种方式：
通过单个RowKey访问(get)
通过RowKey的range（正则）(like)
全表扫描(scan)
RowKey行键 (RowKey)可以是任意字符串(最大长度是64KB，实际应用中长度一般为 10-100bytes)，在HBASE内部，RowKey保存为字节数组。存储时，数据按照RowKey的字典序(byte order)排序存储。设计RowKey时，要充分排序存储这个特性，将经常一起读取的行存储放到一起。(位置相关性)Table：表，所有的表都是命名空间的成员，即表必属于某个命名空间，如果没有指定，则在default默认的命名空间中。
RegionServer group：一个命名空间包含了默认的RegionServer Group。
Permission：权限，命名空间能够让我们来定义访问控制列表ACL（Access Control List）。例如，创建表，读取表，删除，更新等等操作。
Quota：限额，可以强制一个命名空间可包含的region的数量。
Column Family
列族：HBASE表中的每个列，都归属于某个列族。列族是表的schema的一部 分(而列不是)，必须在使用表之前定义。列名都以列族作为前缀。例如 courses:history，courses:math都属于courses 这个列族。
Cell
由{rowkey, column Family:columu, version} 唯一确定的单元。cell中的数据是没有类型的，全部是字节码形式存贮。
关键字：无类型、字节码
Time Stamp
HBASE 中通过rowkey和columns确定的为一个存贮单元称为cell。每个 cell都保存 着同一份数据的多个版本。版本通过时间戳来索引。时间戳的类型是 64位整型。时间戳可以由HBASE(在数据写入时自动 )赋值，此时时间戳是精确到毫秒 的当前系统时间。时间戳也可以由客户显式赋值。如果应用程序要避免数据版 本冲突，就必须自己生成具有唯一性的时间戳。每个 cell中，不同版本的数据按照时间倒序排序，即最新的数据排在最前面。
为了避免数据存在过多版本造成的的管理 (包括存贮和索引)负担，HBASE提供 了两种数据版本回收方式。一是保存数据的最后n个版本，二是保存最近一段 时间内的版本（比如最近七天）。用户可以针对每个列族进行设置。
命名空间
命名空间的结构:
H. hbase的核心数据结构
hbase的核心数据结构如下：
Hadoop是大数据开发的重要框架，其核心是HDFS和MapRece，HDFS为海量的数据提供了存陪备段储，MapRece为海量的数据提供了计算，因此，需要重点掌握，除此之外，还需要掌握Hadoop集群、Hadoop集群管理、YARN以及Hadoop高级管理等相关技术与操作!
其他数据结构：
1、Java编程技术
Java编程技术是大数据学习的基础，Java是一种强类型语言，拥有极高的跨平台滚租能力，可以编写桌面应用程序、Web应用程序、分布式系统和嵌入式系统应用程序等，是大数据工程师最喜欢的编程工具，因此，想学好大数据，掌握Java基础是必不可少的!
2、Linux命令
对于大数据开发通常是在Linux环境下进行的，相比Linux操作系统，Windows操作系统是封闭的操作系统，开源的大数据软件很受限制，因此，想从事大数据开发相关工作，还需掌握Linux基础操作命令芦誉。
I. HBase数据结构运行原理是什么
HBase是一个高可靠、高性能、面枝余向列、可伸缩的分布式猛瞎滚数据库，主要用来储神大存非结构化和半结构化的松散数据。
J. 深入理解HBASE（3.4）RegionServer-Memstore
Region内每个ColumnFamily的数据组成一个Store。每个Store内包括一个MemStore和若干个StoreFile(HFile)组成。
HBase为了方便按照RowKey进行检索，要求HFile中数据都按照RowKey进行排序，Memstore数据在flush为HFile之前会进行一次排序
为了减少flush过程对读写的影响，HBase采用了类似于两阶段提交的方式，将整个flush过程分为三个阶段：
要避免“写阻塞”，貌似让Flush操作尽量的早于达到触发“写操作”的阈值为宜。但是，这将导致频繁的Flush操作，而由此带来的后果便是读性能下降以及额外的负载。
每次的Memstore Flush都会为每个CF创建一个HFile。频繁的Flush就会创建大量的HFile。这样HBase在检索的时候，就不得不读取大量的HFile，读性能会受很大影响。
为预防打开过多HFile及避免读性能恶化，HBase有专门的HFile合并处理(HFile Compaction Process)。HBase会周期性的合并数个小HFile为一个大的HFile。明显的，有Memstore Flush产生的HFile越多，集群系统就要做更多的合并操作(额外负载)。更糟糕的是：Compaction处理是跟集群腊搏上的其他请求并行进行的。当HBase不能够跟上Compaction的时候(同样有阈值设置项)，会在RS上出现“写阻塞”。像上面说到的，这是最最不希望的。
提示 ：严重关切RS上Compaction Queue 的size。要在其引起问题前，阻止其持续增大。
想了解更多HFile 创建和合并，可参看 Visualizing HBase Flushes And Compactions 。
理想情况下，在不超过hbase.regionserver.global.memstore.upperLimit的情况下，Memstore应该尽可能多的使用内存(配置给Memstore部分的，而不是真个Heap的)。下图展示了一张“较好”的情况：
hbase使用的是jdk提供的ConcurrentSkipListMap，并对其进行了的封装，Map结构是<KeyValue,KeyValue>的形式。Concurrent表示线程安全。
SkipList是一种高效的数据结构，之前专门写过文章，这里就不表了
写入MemStore中的KV，被记录在kvset中。根据JVM内存的垃圾回收策略，在如下条件会触发Full GC。 1、内存满或者触发阈值。 2、内存碎片过多，造成新的分配找不到合适的内存敬好空间。 RS上服务多个Region，如果不对KV的分配空间进行控制的话，由于访问的无序性以及KV长度的不同，每个Region上的KV会无规律地分散在内存上。Region执行了MemStore的Flush操作，再经过JVM GC之后就会出现零散的内存碎片现象，而进一步数据大量写入，就会触发Full-GC。
为了解决因为内存碎片造成的Full-GC的现象，RegionServer引入了MSLAB（HBASE-3455）。MSLAB全称是MemStore-Local Allocation Buffers。它通过预先分配连续的内轮稿祥存块，把零散的内存申请合并，有效改善了过多内存碎片导致的Full GC问题。 MSLAB的工作原理如下： 1、在MemStore初始化时，创建MemStoreLAB对象allocator。 2、创建一个2M大小的Chunk数组，偏移量起始设置为0。Chunk的大小可以通过参数hbase.hregion.memstore.mslab.chunksize调整。 3、 当MemStore有KeyValue加入时，maybeCloneWithAllocator(KeyValue)函数调用allocator为其查找KeyValue.getBuffer()大小的空间，若KeyValue的大小低于默认的256K，会尝试在当前Chunk下查找空间，如果空间不够，MemStoreLAB重新申请新的Chunk。选中Chunk之后，会修改offset=原偏移量+KeyValue.getBuffer().length。chunk内控制每个KeyValue大小由hbase.hregion.memstore.mslab.max.allocation配置。 4、 空间检查通过的KeyValue，会拷贝到Chunk的数据块中。此时，原KeyValue由于不再被MemStore引用，会在接下来的JVM的Minor GC被清理。
MSLAB解决了因为碎片造成Full GC的问题，然而在MemStore被Flush到文件系统时，没有reference的chunk，需要GC来进行回收，因此，在更新操作频繁发生时，会造成较多的Young GC。 针对该问题，HBASE-8163提出了MemStoreChunkPool的解决方案，方案已经被HBase-0.95版本接收。它的实现思路： 1、 创建chunk池来管理没有被引用的chunk，不再依靠JVM的GC回收。 2、 当一个chunk没有引用时，会被放入chunk池。 3、chunk池设置阈值，如果超过了，则会放弃放入新的chunk到chunk池。 4、 如果当需要新的chunk时，首先从chunk池中获取。 根据patch的测试显示，配置MemStoreChunkPool之后，YGC降低了40%，写性能有5%的提升。如果是0.95以下版本的用户，可以参考HBASE-8163给出patch。