hbase日志存储
⑴ hbase里的hlog存在哪regionserver里还是zookeeper里
看一下下图就知道了吧。
对于用户的一个表比如Blog，可能包括数据多达亿级
该表的数据可以分布在多个HRegion
而每个HRegion保存表的某一段数据
UserTable(1)------HRegion(*)
对于多个的HRegion则有HRegionServer来维护
每个HRegion唯一对应一个HRegionServer
通过HRegionServer才能够访问对应的HRegion
而一个HRegion从物理上分为如下几个部分
HMemCache(内存缓存),HLog(日志),HStore(持久化存储)
三：HBase的数据操作流程
a:读数据
优先从HMemcache中读取，如果没有读到从HStore中读取
当然这里需要关注：读、写同步的问题，HBase如何解决，还有第一个客户端读取数据从HStore读取后，是否会加载到HMemCache中；后续的客户端，读取时直接从HMemCache中读取，以及MemCache中数据的过期化算法
b:写数据
HBase写入数据会写到HMemcache和Hlog中，HMemcache建立缓存，Hlog同步Hmemcache和Hstore的事务日志，发起FlushCache时，数据持久化到Hstore中，并清空HMemecache。
此处需要关注：
HBase写数据，首先写入Memcache，并计入Log中，最后写入HStore中，如果在写入HStore是发生系统异常，就可以从Log中恢复数据，重新写入HStore中。【该机制跟BigTable中的SSTabl,MemTable和CommitLog的作用一样】
c:客户端操作数据流程
客户端访问这些数据的时候通过Hmaster，每个Hregion服务器都会和Hmaster服务器保持一个长连接，Hmaster是HBase分布式系统中的管理者，他的主要任务就是要告诉每个Hregion服务器它要维护哪些Hregion。用户的这些都数据可以保存在Hadoop分布式文件系统上
如果一个HMaster挂了，SecondaryNameNode会自动替代HMaster
但是对应的失效转发的效率还需要进一步尝试，可能依赖ZooKeeper的相关配置项
⑵ Hbase安全基线中日志存储最少保留多少人
10人
WAL意为write ahead log，HBase中的预写日志，用来做灾难恢复使用，底层实现是HLog，HLog记录数据的所有变更。使用WAL的原因：因为MemStore存储的数据是驻留在内存中的，是不稳定的(比如宕机时)，所以采用了WAL预写日志来解决这个问题。(运行MApRece作业时，可以通过关闭WAL功能来获得性能的提升——setWriteToWAL(boolean))。其实HLog文件就是一个普通的Hadoop Sequence File，Sequence File的key是HLogKey对象，其中记录了写入数据的归属信息，除了table和region名字外，还同时包括sequence number和timestamp，timestamp是写入时间，sequence number的起始值为0，或者是最近一次存入文件系统中的sequence number。Sequence File的value是HBase的KeyValue对象，即对应HFile中的KeyValue。
随着用户的增多，网站功能势必增加，业务功能都会使用sql语句进行查询，而表数据过多会导致join操作变慢，所以会不得不采用一些逆范式的方式来设计数据库，这样导致无法使用存储过程。而且，数据过大时，索引的效果也没那么强了。因为索引也会变得很大。
⑶ hbase和hive的差别是什么，各自适用在什么场景中
1. Hive中的表是纯逻辑表，就只是表的定义等，即表的元数据。Hive本身不存储数据，它完全依赖HDFS和MapRece。这样就可以将结构化的数据文件映射为为一张数据库表，并提供完整的SQL查询功能，并将SQL语句最终转换为MapRece任务进行运行。 而HBase表是物理表，适合存放非结构化的数据。
2. Hive是基于MapRece来处理数据,而MapRece处理数据是基于行的模式；HBase处理数据是基于列的而不是基于行的模式，适合海量数据的随机访问。
3. HBase的表是疏松的存储的，因此用户可以给行定义各种不同的列；而Hive表是稠密型，即定义多少列，每一行有存储固定列数的数据。
4. Hive使用Hadoop来分析处理数据，而Hadoop系统是批处理系统，因此不能保证处理的低迟延问题；而HBase是近实时系统，支持实时查询。
5. Hive不提供row-level的更新，它适用于大量append-only数据集（如日志）的批任务处理。而基于HBase的查询，支持和row-level的更新。
6. Hive提供完整的SQL实现，通常被用来做一些基于历史数据的挖掘、分析。而HBase不适用与有join，多级索引，表关系复杂的应用场景。
⑷ 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安全提现中日志存储最少保留多少天
7天，
日志默认保留7 天，对于 SSD 作为存储介质，随着业务增长，存储成本过于高昂。
⑹ 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对日志存储要求最少保留两个人，只保留一个人时不能够完成日常存储，力量过于单薄，安全基线要求高追求品质第一。
⑻ hbase写日志为什么比写hfile快
在HBase的根目录下面，有两个跟日志相关的目录，.logs和.oldlogs。.logs保存的是所有Regionserver上当前在写入的HLog，可以看到每个RegionServer对应一个文件，所以HLog是对应RegionServer的。
HLog默认情况下每个小时会滚动，这是通过参数hbase.regionserver.logroll.period控制的，这个参数的默认值是1小时。
此外，hbase.regionserver.hlog.blocksize和fs_local.block.size控制当HLog的大小超过32M的时候，会滚动。
Hbase.regionserver.logroll.multiplier，默认值是95%，表示日志达到95%的时候，也会进行滚动。
日志文件的滚动操作，就是检查HFile中的序列号，确认日志中所有的序列号都小于HFile的序列号，确保所有的日志内容都已经固化到HFile中，确认后将当前的日志挪到.oldlog目录下。
这里有个问题还有些疑惑，书里写的是检查写入存储文件中最大的序列号是多少，小于这个序列号的所有修改都已经固化了，只要确保日志中的最大序列号比这个序列号小，就可以确认这个日志已经固化，可以挪到.oldlog下。
但是memstore刷新到HFile是对HStore的，对表的，可能有的表更新比较多，刷新的快，已经固化到HFile，但有的表修改少，还没有刷新到HFile，这和序列号的顺序应该是没有必然的关系的，后续应该可以做个测试来验证一下。
当前日志的文件，在写满一个块之前，都显示的是0字节，但实际上可能已经有数据，只是显示的问题而已。
现在插入几条记录，做些修改的操作，查看日志的内容：
hbase(main):001:0> put't_lisa','lisa5','cf_1:w1','10d2'
0 row(s) in 0.4590 seconds
hbase(main):002:0> put't_lisa','lisa6','cf_1:w1','1032'
0 row(s) in 0.0050 seconds
hbase(main):003:0> put't_lisa','lisa7','cf_1:w1','10z2'
0 row(s) in 0.0040 seconds
hbase(main):004:0> put't_lisa','lisa8','cf_1:w1','10e2'
0 row(s) in 0.0040 seconds
hbase(main):002:0> delete 't_lisa','lisa5','cf_1'
0 row(s) in 0.4270 seconds
查看日志文件，虽然大小为0，但是实际上写操作是先写了WAL，才写memstore的，这里只是文件大小显示的问题。
每个regionserver最初都会有一个HLog，不管是不是有更新操作。
[root@a01 hbase]# hadoop fs -ls /hbase_root/.logs
查看日志文件的内容，-p表示查看对应的value：
[root@a01 hbase]# bin/hbase hlog /hbase_root/.logs/*,60020,1385442023669/*%2C60020%2C1385442023669.1385449225598 -p
Sequence 2316016 from region in table t_lisa
Action:
row: lisa5
column: cf_1:w1
at time: Tue Nov 26 15:17:04 CST 2013
value: 10d2
Sequence 2316017 from region in table t_lisa
Action:
row: lisa6
column: cf_1:w1
at time: Tue Nov 26 15:17:04 CST 2013
value: 1032
Sequence 2316018 from region in table t_lisa
Action:
row: lisa7
column: cf_1:w1
at time: Tue Nov 26 15:17:04 CST 2013
value: 10z2
Sequence 2316019 from region in table t_lisa
Action:
row: lisa8
column: cf_1:w1
at time: Tue Nov 26 15:17:04 CST 2013
value: 10e2
Sequence 2316020 from region in table t_lisa
Action:
row: lisa5
column: cf_1:
at time: Tue Nov 26 15:31:49 CST 2013
value:
截取其中的一小段进行分析：
Sequence 2316016 from region in table t_lisa
Action:
row: lisa5
column: cf_1:w1
at time: Tue Nov 26 15:17:04 CST 2013
value: 10d2
Sequence 2316016 ：序列号，在恢复的时候，会判断这个id和HFile中序列ID的大小，小于HFile序列ID（MAX_SEQ_ID_KEY）的操作不用再重做，因为已经固化到数据文件中了。
region ：region name中按照前面部分的MD5散列值
table t_lisa： 表名
row: lisa5：行键
column: cf_1:w1：列族和列标识符
value: 10d2：值
Delete 和 insert操作的日志并没有明显写明action
查看HFile的信息，这里可以看到HFile中的kv数据、压缩、起始rowkey等非常详细的信息：
[root@a01 ~]# cd /home/hbase
[root@a01 hbase]# bin/hbase org.apache.hadoop.hbase.io.hfile.HFile -f /hbase_root/t_lisa1//cf_1/ -v -m -p
K: lisa1/cf_1:a/1384389531130/Put/vlen=1/ts=0 V: 1
K: lisa1/cf_1:b/1384390435899/Put/vlen=1/ts=0 V: 6
K: lisa1/cf_1:b/1384389531157/Put/vlen=1/ts=0 V: 5
K: lisa1/cf_1:b1/1384390714903/Put/vlen=2/ts=0 V: 61
firstKey=lisa1/cf_1:a/1384389531130/Put,
lastKey=lisa1/cf_1:b1/1384390714903/Put,
MAX_SEQ_ID_KEY = 2309244