分布式数据存储HBase的定位是分布式NoSQL数据库，在多台机器上实现了独特的NoSQL数据库功能，因此HBase的定位是分布式NoSQL。
HBase群集下有许多计算机，每台计算机都称为RegionServer，在处理RegionServer基础数据时与HDFS进行交互
如果在HBase中创建一个表，然后将数据填充到表中，实际上这些数据分布在很多region (数据片)中，每个region其实都是数据的片。
这些region作为数据的片，最下层的数据实际上存在于HDFS上的DataNode上。
不同的Region (数据分片)实际上交给不同的RegionServer管理。
HBase为什么称为分布式数据存储，是指HBase使用多台计算机，多个RegionServer分布式存储和管理这些Region。
这些Region的数据本身也以分散的形式保存在HDFS集群上的多个DataNode中。
你在HBase中建立表，在表中制作10TB的数据，这些数据其实分成很多Region数据片，不同的Region数据片其实在不同的RegionServer上。 每个RegionServer管理一部分Region。
自动数据切片这一功能非常强大。 例如，制作HBase的表，在表中制作很多数据。 此时，表分为很多Region。 每个Region都有一个数据片。 然后，这些Region数据片分布在多台计算机上。
假设表里的数据太多。 此时，Region会自动分裂，分裂成更多的Region，自动分布在更多的机器上。 这样可以确保每个区域的数据量不会太大。 另外，如果表中的数据过多，则有很多Region；如果有很多Region，则实际上只需要在以后对HBase进行线性扩展；通过向HBase添加机器(添加RegionServer )，就会有更多的机器
HBase基本体系结构
首先，理解一贯性就一贯性而言，可以分为客户端和服务器两个不同的视点。
从客户端来看，一致性主要是指如何获取多个同时访问时更新的数据。 从服务方面看，更新复制如何分布在整个系统上，以确保数据最终是一致的。 一致性是同时读写引起的问题，所以在理解一致性问题时，必须注意同时读写的情况。
从客户端角度看，当多个进程同时访问时，更新的数据是如何检索每个进程的决定着不同的一致性。 关系数据库要求更新的数据可在后续访问中引用。 这是强一致性如果允许部分或全部后续不可访问，如果要求在弱一致性小时后可以访问更新的数据，则为http://www.
从最终一致性的角度来看，如何快速将更新的数据分布到整个系统中，缩短时间窗口以达到最终的一致性，是提高系统可用性和用户体验的一个非常重要的方面。 对于分布式数据系统：
更新n -数据复制的份数w -数据时，写入完成的节点数r -读取数据时需要读取的节点数W RN如果写入节点与读取节点重叠，则需要保持较强的一致性。 例如，在典型的主准备同步复制关系数据库中，如果N=2、W=2、R=1，则无论您正在读取的是主库还是备用库的数据都是一致的。
如果W R=N，则是弱的一致性。 例如，在N=2、W=1和R=1的关系数据库中，如果正在读取备件，则可能无法读取主库中更新的数据，因此是弱一致性。
对于分布式系统，为了确保高可用性，通常设置N=3。 不同的n、w、r组合在可用性和一致性之间取得平衡，以适应不同的APP应用场景。
如果N=W，R=1，则禁用其中一个写入节点会导致写入失败，从而降低可用性，但会同时写入n个分布数据的节点，从而确保较强的一致性。 N=R、W=1时，只有一个节点可以正常写入即可，写入性能和可用性较高。 然而，读取其他节点的过程是弱一致性的，因为该过程可能无法获取更新的数据。 在这种情况下，如果w(n1 )/2且写入节点不重叠，则存在写入冲突的HBase，具有强一致性的系统HBase具有以下特征
每个值只分配给一个REGION且一个REGION只分配给一个REGION服务器行的所有操作都是原子的。 原子操作是指如果可以将事务视为程序，它是完全执行还是完全不执行。 上传操作可以成功，也可以完全失败。 结合上述一致性特征，可以得出HBase是一个强一致性系统。
如果一个区域服务器被禁用，并且其管理的区域移动到另一个区域服务器，则必须基于写读取日志(wall og )重新开始。 此时，进行重做的region应该不可用，因此hbase降低了可用性并提高了一致性。 想象一下，如果重新运行的region现在可以响应请求并提高了可用性，则会返回不一致的数据(
成)，那么hbase就降低一致性来提高可用性了。 HBase的强一致性和HDFS的多副本一开始非常迷惑于HBase的强一致性和HDFS的多副本是怎么协同的。
这一块儿就需要对HBase和HDFS的读写数据流有个比较透彻的理解。
先假设HDFS的副本存储策略，也就是dfs.replication的值为3（默认值就是3）
这样所有存储在HDFS上的文件都有3个副本。那么，HBase的存储实例，也就是HFile也有3个副本。那么当某一个RegionServer崩溃时，并不用担心数据的丢失，因为数据是存储在HDFS上，哪怕崩溃的RegionServer所在的DataNode上有一个副本，在其他DataNode上也还有2个副本。
那么也许你要问，既然有3个副本，如何保证HBase的强一致性呢？
HFile是已经持久化在磁盘上了，而HFile是不能改变的（这个时候暂时把删除数据这个操作放到一边，相关内容请看下面的Note），一旦在某一个DataNode上生成一个HFile后就会异步更新到其他两个DataNode上，这3个HFile是一模一样的。
那也许你又要问，那我的数据是不断更新当中啊！
更新的数据是放在Memstore，只有当Memstore里的数据达到阈值，或者时间达到阈值，就会flush到磁盘上，生成HFile，而一旦生成HFile就是不可改变的（compaction，split就是后话啦）。
这里再提一下WAL的一致性
WAL是Write-Ahead logging，这个是Memstore里的数据在RegionServer崩溃时得以恢复的保证。WAL的实现是HLog，HLog也是存储在HDFS上的，所以HRegionServer崩溃了也不会导致HLog的丢失，它也有备份。
每一次更新都会调用写日志的sync()方法，这个调用强迫写入日志的更新都会被文件系统确认。
当前的sync()的实现是管道写，也就是HDFS写数据、生成副本的默认方式，这意味着当修改被写入时，它会被发送到第一个DataNode进行存储。一旦成功，第一个DataNode就会把修改发送到另一个DataNode来进行相同的工作。只有3个DataNode都已经确认了写操作，客户端才被允许继续进行；另一种存储修改的方法是多路写，也就是写入被同时送到3台机器上。当所有主机确认了写操作后，客户端才可以继续。**两种方法的优缺点：**管道写需要时间去完成，所以它有很高的延迟，但是它能更好地利用网络带宽；多路写有着比较低的延迟，因为客户端只需要等待最慢的DataNode确认（假设其余都已成功确认）。但是写入需要共享发送服务器的网络带宽，这对于有着很高负载的系统来说是一个瓶颈。目前有正在进行的工作能让HDFS支持上面两种方式。
Note：当客户端提交删除操作的时候，数据不是真正的删除，只是做了一个删除标记（delete marker，又称母被标记），表明给定航已经被伤处了，在检索过程中，这些删除标记掩盖了实际值，客户端读不到实际值。直到发生compaction的时候数据才会真正被删除。
HBase支持MapReduce和Spark离线分布式计算对HBase李的数据进行分布式存储,可以从HBase里面分布式抽数据去计算,也可以把计算后的结果写入HBase分布式存储.
参考https://www.cnblogs.com/captainlucky/p/4720986.html