hbase小文件存储
特点：（1）大：一个表可以有数十亿行，上百万列；
（2）无模式：每行都有一个可排序的主键和任意多的列，列可以根据需要动态的增加，同一张表中不同的行可以有截然不同的列；
（3）面向列：面向列（族）的存储和权限控制，列（族）独立检索；？
（4）稀疏：空（null）列并不占用存储空间，表可以设计的非常稀疏；
（5）数据多版本：每个单元中的数据可以有多个版本，默认情况下版本号自动分配，是单元格插入时的时间戳；
（6）数据类型单一：Hbase中的数据都是字符串，没有类型。
㈡ HBase应用场景
1、用户画像
比如大型的视频网站，电商平台产生的用户点击行为、浏览行为等等存储在HBase中为后续的智能推荐做数据支撑。
2、消息/订单存储
这个场景主要应用在电商平台，因为HBase提供了一个低延时、高并发的访问能力
3、对象存储
这里的对象存储实际是中等对象存储，是对HDFS存储文件的一个缓冲过度，因为如果我们大量的1M或2M这种小文件直接存储在HDFS上，会对NAMENODE造成元数据维护的压力，所以在HBase中可以很好的做过度合并后在持久化到HDFS上。HBase提供了中等对现象的存储能力，中等对象的大小范围在100k至10M之间。
4、时序数据
这里的时序数据是指随着时间而变化的数据，比如速度的展示，天气、温度、风速、车流量等等
5、Cube分析（KyLin）
通过KyLin将Hive或kafka中的数据，来构建Cube，这些Cube会存储在HBase中，以供其他的应用或其他的系统做实时查询或实时展示。
6、Feeds流
这个场景主要是应用在抖音、或其他小视频系统中，可以把Feeds流理解为一种内容聚合器，它可以帮助用户实时的获取最新的订阅源内容。
㈢ Hbase扩容原理
Hbase是Hadoop的一个存储组件可以提供低延迟的读写操作，它一般构建在HDFS之上，可以处理海量的数据。Hbase有个很好的特性是可以自动分片，也就是意味着当表的数据量变得很大的时候，系统可以自动的分配这些数据。
Hbase的基本存储单位是Region，Region是表数据的子集，多个Region的数据集合可以组成一张完成的表数据。Region本质上存储的一些排好序的，连续的行数据。最初的时候一张表只有一个Region，当Region变得非常大的时候，Region就会从中间分裂成两个基本等大的Region。
在Hbase中，slave也被称作RegionServer，每个RegionServer负责管理一些Region，同时一个Region只能属于一个RegionServer。
一个RegionServer可以服务一个或多个Region，每个Region在Region Server启动的时候被分配。Master可以决定将一些Region从一个RegionServer中移动到令一个RegionServer里面，以便更好的负载均衡。当某个RegionServer故障的时候，Master也可以将它的Region分配给其他的RegionServer。
Region与RegionServer之间的映射关系存储在Zookeeper中的META表中，通过读取META表，你就可以知道那个Region可以负责处理你的rowkey操作，其实这也代表着在HBase读写操作的时候是不用经过Master节点的，你可以之间联系RegionServer。
如图，在客户端进行scan的时候，它可以之间联系多个RegionServer处理当前的操作。
Meta表是用来跟踪Region的，它包含服务器的名称，Region的名称，表名，还有Region的startkey。通过startkey的范围，客户端就可以定位到当前的key要去哪一个Region了。
客户端在请求过META表之后，一般会将表缓存起来，防止每次操作都去获取。在Region进行分裂的时候，客户端去RegionServer操作Region的时候回返回异常，然后客户端会重新获取最新的META表信息。
Hbase的java客户端API有两个主要的接口：
通过上面介绍，可以知道HBase虽然是Master/Slave架构的，但是并不是每次操作都经过Master的，读写数据的时候HBase只需要直接联系RegionServer即可。这也是HBase可以“无限扩容”的原因。在吞吐量不够的时候，通过增加RegionServer节点，可以增加吞吐量。
㈣ HBase存储架构
上图是HBase的存储架构图。
由上图可以知道，客户端是通过Zookeeper找到HMaster，然后再与具体的Hregionserver进行沟通读写数据的。
具体到物理实现，细节包括以下这些：
首先要清楚HBase在hdfs中的存储路径，以及各个目录的作用。在hbase-site.xml 文件中，配置项 <name> hbase.rootdir</name> 默认 “/hbase”，就是hbase在hdfs中的存储根路径。以下是hbase0.96版本的个路径作用。1.0以后的版本请参考这里: https://blog.bcmeng.com/post/hbase-hdfs.html
1、 /hbase/.archive
HBase 在做 Split或者 compact 操作完成之后，会将 HFile 移到.archive 目录中，然后将之前的 hfile 删除掉，该目录由 HMaster 上的一个定时任务定期去清理。
2、 /hbase/.corrupt
存储HBase损坏的日志文件，一般都是为空的。
3、 /hbase/.hbck
HBase 运维过程中偶尔会遇到元数据不一致的情况，这时候会用到提供的 hbck 工具去修复，修复过程中会使用该目录作为临时过度缓冲。
4、 /hbase/logs
HBase 是支持 WAL（Write Ahead Log） 的，HBase 会在第一次启动之初会给每一台 RegionServer 在.log 下创建一个目录，若客户端如果开启WAL 模式，会先将数据写入一份到.log 下，当 RegionServer crash 或者目录达到一定大小，会开启 replay 模式，类似 MySQL 的 binlog。
5、 /hbase/oldlogs
当.logs 文件夹中的 HLog 没用之后会 move 到.oldlogs 中，HMaster 会定期去清理。
6、 /hbase/.snapshot
hbase若开启了 snapshot 功能之后，对某一个用户表建立一个 snapshot 之后，snapshot 都存储在该目录下，如对表test 做了一个 名为sp_test 的snapshot，就会在/hbase/.snapshot/目录下创建一个sp_test 文件夹，snapshot 之后的所有写入都是记录在这个 snapshot 之上。
7、 /hbase/.tmp
当对表做创建或者删除操作的时候，会将表move 到该 tmp 目录下，然后再去做处理操作。
8、 /hbase/hbase.id
它是一个文件，存储集群唯一的 cluster id 号，是一个 uuid。
9、 /hbase/hbase.version
同样也是一个文件，存储集群的版本号，貌似是加密的，看不到，只能通过web-ui 才能正确显示出来
10、 -ROOT-
该表是一张的HBase表，只是它存储的是.META.表的信息。通过HFile文件的解析脚本 hbase org.apache.hadoop.hbase.io.hfile.HFile -e -p -f 可以查看其存储的内容，如下所示：
以上可以看出，-ROOT-表记录的.META.表的所在机器是dchbase2，与web界面看到的一致：
11、 .META.
通过以上表能找到.META.表的信息，该表也是一张hbase表，通过以上命令，解析其中一个region：
以上可以看出，adt_app_channel表的数据记录在dchbase3这台reginserver上，也与界面一致，如果有多个region，则会在表名后面加上rowkey的范围：
通过以上描述，只要找到-ROOT-表的信息，就能根据rowkey找到对应的数据，那-ROOT-在哪里找呢？从本文一开始的图中可以知道，就是在zookeeper中找的。进入zookeeper命令行界面：
可以看出-ROOT-表存储在 dchbase3 机器中，对应界面如下：
以上就是HBase客户端根据指定的rowkey从zookeeper开始找到对应的数据的过程。
那在Region下HBase是如何存储数据的呢？
以下就具体操作一张表，查询对应的HFile文件，看HBase的数据存储过程。
在HBase创建一张表 test7，并插入一些数据，如下命令：
查看wal日志，通过 hbase org.apache.hadoop.hbase.regionserver.wal.HLog --mp -p 命令可以解析HLog文件，内容如下：
查看HFile文件，内容如下：
由此可见，HFile文件就是存储HBase的KV对，其中Key的各个字段包含了的信息如下：
由于hbase把cf和column都存储在HFile中，所以在设计的时候，这两个字段应该尽量短，以减少存储空间。
但删除一条记录的时候，HBase会怎么操作呢？执行以下命令：
删除了rowkey为200的记录，查看hdfs，原来的HFile并没有改变，而是生成了一个新的HFile，内容如下：
所以在HBase中，删除一条记录并不是修改HFile里面的内容，而是写新的文件，待HBase做合并的时候，把这些文件合并成一个HFile，用时间比较新的文件覆盖旧的文件。HBase这样做的根本原因是，HDFS不支持修改文件。
㈤ 在哪些场景下不能使用HBase作为存储系统( )
选择D，HBase适合小文件的存储
㈥ hbase的作用
HBase 是典型的 NoSQL 数据库，通常被描述成稀疏的、分布式的、持久化的，由行键、列键和时间戳进行索引的多维有序映射数据库，主要用来存储非结构化和半结构化的数据。因为 HBase 基于 Hadoop 的 HDFS 完成分布式存储，以及 MapRece 完成分布式并行计算，所以它的一些特点与 Hadoop 相同，依靠横向扩展，通过不断增加性价比高的商业服务器来增加计算和存储能力。
HBase 虽然基于 Bigtable 的开源实现，但它们之间还是有很多差别的，Bigtable 经常被描述成键值数据库，而 HBase 则是面向列存储的分布式数据库。
下面介绍 HBase 具备的显着特性，这些特性让 HBase 成为当前和未来最实用的数据库之一。
容量巨大
HBase 的单表可以有百亿行、百万列，可以在横向和纵向两个维度插入数据，具有很大的弹性。
当关系型数据库的单个表的记录在亿级时，查询和写入的性能都会呈现指数级下降，这种庞大的数据量对传统数据库来说是一种灾难，而 HBase 在限定某个列的情况下对于单表存储百亿甚至更多的数据都没有性能问题。
HBase 采用 LSM 树作为内部数据存储结构，这种结构会周期性地将较小文件合并成大文件，以减少对磁盘的访问。
扩展性强
HBase 工作在 HDFS 之上，理所当然地支持分布式表，也继承了 HDFS 的可扩展性。HBase 的扩展是横向的，横向扩展是指在扩展时不需要提升服务器本身的性能，只需添加服务器到现有集群即可。
HBase 表根据 Region 大小进行分区，分别存在集群中不同的节点上，当添加新的节点时，集群就重新调整，在新的节点启动 HBase 服务器，动态地实现扩展。这里需要指出，HBase 的扩展是热扩展，即在不停止现有服务的前提下，可以随时添加或者减少节点。
高可靠性
HBase 运行在 HDFS 上，HDFS 的多副本存储可以让它在岀现故障时自动恢复，同时 HBase 内部也提供 WAL 和 Replication 机制。
WAL（Write-Ahead-Log）预写日志是在 HBase 服务器处理数据插入和删除的过程中用来记录操作内容的日志，保证了数据写入时不会因集群异常而导致写入数据的丢失；而 Replication 机制是基于日志操作来做数据同步的。
㈦ 小文件存储
小文件存储对hbase不太合适。会产生太多小块。hbase是按照rowkey来分片的。所以太多小文件了
https://zhuanlan.hu.com/p/136705670
fb的haystack。
思路是：把目录做成单独的service，
文件合并成大文件，这样在物理存储层上，metadata的存储压力就小。
㈧ hbase存储信息怎么展示
hbase存储的信息一般是这样展示的。首先打开电子设备，找到设置里面的我的存储，然后查看存储信息就可以看到了。
㈨ HBase是什么呢，都有哪些特点呢
Hbase是一种NoSQL数据库，这意味着它不像传统的RDBMS数据库那样支持SQL作为查询语言。Hbase是一种分布式存储的数据库，技术上来讲，它更像是分布式存储而不是分布式数据库，它缺少很多RDBMS系统的特性，比如列类型，辅助索引，触发器，和高级查询语言等待
那Hbase有什么特性呢？如下：
强读写一致，但是不是“最终一致性”的数据存储，这使得它非常适合高速的计算聚合
自动分片，通过Region分散在集群中，当行数增长的时候，Region也会自动的切分和再分配
自动的故障转移
Hadoop/HDFS集成，和HDFS开箱即用，不用太麻烦的衔接
丰富的“简洁，高效”API，Thrift/REST API，Java API
块缓存，布隆过滤器，可以高效的列查询优化
操作管理，Hbase提供了内置的web界面来操作，还可以监控JMX指标
首先数据库量要足够多，如果有十亿及百亿行数据，那么Hbase是一个很好的选项，如果只有几百万行甚至不到的数据量，RDBMS是一个很好的选择。因为数据量小的话，真正能工作的机器量少，剩余的机器都处于空闲的状态
其次，如果你不需要辅助索引，静态类型的列，事务等特性，一个已经用RDBMS的系统想要切换到Hbase，则需要重新设计系统。
最后，保证硬件资源足够，每个HDFS集群在少于5个节点的时候，都不能表现的很好。因为HDFS默认的复制数量是3，再加上一个NameNode。
存储业务数据:车辆GPS信息，司机点位信息，用户操作信息，设备访问信息。。。
存储日志数据:架构监控数据（登录日志，中间件访问日志，推送日志，短信邮件发送记录。。。），业务操作日志信息
存储业务附件：UDFS系统存储图像，视频，文档等附件信息
什么时候用Hbase？
Hbase不适合解决所有的问题：
Hbase在单机环境也能运行，但是请在开发环境的时候使用。
内部应用
不过在公司使用的时候，一般不使用原生的Hbase API，使用原生的API会导致访问不可监控，影响系统稳定性，以致于版本升级的不可控。
HFile
HFile是Hbase在HDFS中存储数据的格式，它包含多层的索引，这样在Hbase检索数据的时候就不用完全的加载整个文件。索引的大小(keys的大小，数据量的大小)影响block的大小，在大数据集的情况下，block的大小设置为每个RegionServer 1GB也是常见的。
探讨数据库的数据存储方式，其实就是探讨数据如何在磁盘上进行有效的组织。因为我们通常以如何高效读取和消费数据为目的，而不是数据存储本身。
Hfile生成方式
起初，HFile中并没有任何Block，数据还存在于MemStore中。
Flush发生时，创建HFile Writer，第一个空的Data Block出现，初始化后的Data Block中为Header部分预留了空间，Header部分用来存放一个Data Block的元数据信息。
而后，位于MemStore中的KeyValues被一个个append到位于内存中的第一个Data Block中：
注：如果配置了Data Block Encoding，则会在Append KeyValue的时候进行同步编码，编码后的数据不再是单纯的KeyValue模式。Data Block Encoding是HBase为了降低KeyValue结构性膨胀而提供的内部编码机制。
㈩ hbase 的数据存储及Region变化（flush compaction spilt）和性能调优
1. 对表做预分区处理（即在建表时指定Region数量和拆分边界）；
2.配置hbase.hregion.max.filesize为50GB
以fileServer为例，在使用默认的split策略-- 的情况下，16个预分区Region, 则单个Resion容量达到 min(32,50),即32GB时分裂。
3.修改Linux最大文件句柄数
因为hbase是以文件的形式存储数据，最大文件句柄数影响着hbase的并发量。
用root权限修改/etc/security/limits.conf文件，增加以下内容（前面的*不能忽略）：
* soft nproc 10240
* hard nproc 10240
* soft nofile 10240
* hard nofile 10240
编辑/etc/pam.d/common-session，加入一行
session required pam_limits.so
编辑/etc/profile，加入
ulimit -SHn 51200
重新登陆，生效
4.HRegionServer挂掉异常和解决：
is not online on......
常规解决方案：
删除zk中hbase的缓存
重启hbase
使用上述解决方案后本次异常依旧存在，并且HMaster和HRegionServer都不断的自动挂掉。
HMaster报错：
解决方案：
新增配置（看情况决定使用不使用，建议在HMaster不能启动时排除错误使用）（让启动hbase时只让HMaster去进行日志split，缺点是恢复数据时候速度慢）：
<property>
<name>hbase.master.distributed.log.splitting</name>
<value>false</value>
</property>
删除WAL文件（会丢数据）：
6. RPC请求的最大线程数
hbase.regionserver.handler.count 默认是10，在服务器测试时建议设置到50（经测试在单个Region Server时无用，单个RegionServer 最多在6个线程put时保持稳定）
7.日志分割（hbase出错后恢复数据）
MemStore中大量更新丢失时，对数据进行恢复时会做日志分割
hbase.regionserver.hlog.splitlog.writer.threads 日志分割的线程数， 默认为3 ，建议设定为10
8.Region Server频繁掉线
出现Hbase Region Server频繁掉线的情况，表现为在多线程put的情况下，忽然Hbase Region Server掉线
猜测是GC或者split过程中没有及时和ZK通信，导致与ZK连接时间超时，zk返回dead region到master，当Hbase Region恢复正常后，找不到wal,产生如下报错。
zookeeper.session.timeout ：默认值是3分钟
但是 hbase regionserver和zookeeper的timeout不是单方面决定的，是取决于hbase的zookeeper.session.timeout和zookeeper的MaxSessionTimeout中的最小值
配置hbase:
zookeeper.session.timeout
600000
配置zookeeper:
tickTime=30000
9.内存及GC优化
在测试的过程中依旧出现Hbase Region Server掉线的情况，报错如下
2021-02-0318:49:14,091INFO[sync.0]wal.FSHLog: Slow sync cost:1955ms, current pipeline: []
2021-02-0318:49:14,091WARN[regionserver/botsc/192.168.0.107:16020.append-pool5-t1]wal.MetricsWAL: regionserver/botsc/192.168.0.107:16020.append-pool5-t1 took1953ms appending an edit to wal; len~=109
2021-02-0318:49:14,106ERROR[sync.3]wal.FSHLog:Errorsyncing, request close of WAL
java.io .IOException:io.grpc.StatusRuntimeException: CANCELLED: Failed to stream message
at seaweed.hdfs.SeaweedOutputStream.(SeaweedOutputStream.java:78)
at seaweed.hdfs.SeaweedOutputStream.(SeaweedOutputStream.java:263)
at seaweed.hdfs.SeaweedOutputStream.flushInternalAsync(SeaweedOutputStream.java:243)
at seaweed.hdfs.SeaweedOutputStream.flush(SeaweedOutputStream.java:129)
at java.io .FilterOutputStream.flush(FilterOutputStream.java:140)
at java.io .DataOutputStream.flush(DataOutputStream.java:123)
at org.apache.hadoop.hbase.regionserver.wal.ProtobufLogWriter.sync(ProtobufLogWriter.java:170)
at org.apache.hadoop.hbase.regionserver.wal.FSHLog$SyncRunner.run(FSHLog.java:1286)
at java.lang.Thread.run(Thread.java:748)
修改hbase的配置文件hbase-env.sh，GC优化如下：
export HBASE_HEAPSIZE=21384
export master_heapsize=8292
export regionserver_heapsize=21384
export HBASE_OPTS="$HBASE_OPTS -XX:+UseConcMarkSweepGC -XX:=60 -XX:+UseParNewGC -XX:ParallelGCThreads=6"
export HBASE_MASTER_OPTS="$HBASE_MASTER_OPTS $HBASE_JMX_BASE -Xmx8g -Xms8g -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:=70"
export HBASE_REGIONSERVER_OPTS="$HBASE_REGIONSERVER_OPTS $HBASE_JMX_BASE -Xmx20g -Xms20g -Xmn1g -XX:+UseParNewGC
-XX:+UseConcMarkSweepGC -XX:=70"