用过HBase的Restful服务吗

HBase 要开启 Restful 服务也是很容易的。

1. 启动: hbase rest start start -p <port>
2. 后台启动: ./hbase-daemon.sh start rest -p <port>

用过HBase的协处理器吗

协处理器类似 Linux 内核模块。提供了本地存储的数据上执行服务器端代码的方式，是非常有用的功能。每个 RegionServer 都会有一个协处理器进程。所有的 region 都包含对协处理器实现的引用。可以通过 RegionServer 的类路径加载，也可以通过 HDFS 的类加载器。协处理器的设计是为了方便开发者向 HBase 添加额外的功能。可以用来做服务端的操作，比如 region 分列、合并以及客户端的操作，如创建、读取、更新、删除操作，可以满足用户定制的需求，实现用户自定义的功能。

协处理器的类型如下:

1. Coprocessor: 提供 region 声明周期的管理，如打开、关闭、分列、合并等操作
2. RegionObserver: 提供对表的修改操作的监控，如客户端 get, put, scan, delete 等操作
3. EndPoint: 提供在 region 端执行任意函数的功能，如 RegionServer 的列聚集函数

知道HBase Java客户端是怎么查找数据的吗

首先 HTable Api 用于查找数据 rowkey 所在的 ReginServer，通过查找元数据表 hbase:meta 这个 kv 表获取信息。

获得 RegionServer 信息之后，客户端可以直接与所需 region 的 RegionServer 进行通信，进行读写，不需要访问 master。所以不担心 HMaster 挂掉。

而为了后面加速，获得的元信息会缓存在客户端，期间有 region 挂掉，客户端会重新访问元数据表，以获得最新的信息，更新缓存。因此即使没有 master 客户端也可以正常工作。

在HBase中遇到大数据字段怎么办

HBase 每个单元格有限制，不能超过 20MB（推荐系统应该没有这种场景），因此可以把数据转换并存储在 HBase 单元格中，对于较大的数据，可以存储在 HDFS 文件系统中，把文件名存储在 HBase 单元格中，这样可以避免超长时间的读取操作。

HBase过滤器的使用

HBase的备份和恢复经验

https://yq.aliyun.com/articles/581666 http://wangneng-168.iteye.com/blog/2154669

1. 离线distcp不提倡
2. HBase快照: 针对表生成快照，不与 RegionServer 打交道。

设计过行键吗

http://blog.chedushi.com/archives/9720

HBase 按单个 rowkey 检索的效率是很高的，耗时在1毫秒以下，每秒钟可获取1000~2000条记录，不过非 key 列的查询很慢。行键的设计关乎到读取和写入的速度。

解释一下HBase的Minor合并和Major合并

数据写入 HBase 中，它写一个不可变的文件到 store，每个 store 都由单一列族构成，region 组成了这些以 rowkey 排序的不可变的文件。由于多个文件的原因，I/O 操作会慢下来，读写也会延时，导致慢操作。HBase 会通过合并（多路归并）的方式来解决这个问题。

合并之后使得文件更加紧凑，因此读文件会更有效率，当新数据写入 HBase 的时候，生成了 HFile，HFile 的数量会增加 I/O 负载，所以为了把影响降到最低，HFile 会被周期性的合并，当 Memstore 填满到阈值之后，会创建一个新的 HFile。合并其实就是用多路归并排序算法合并两个或者多个 HFile，因为 HFile 本身是排序了的。一旦文件被合并之后，新文件会被加载，旧文件会被释放或者删除。

Minor 合并在 HStore 中发生在多个 HFile 上。这类型的合并，几个相邻的 HFile 被取出，合并，然后重新写入到大的 HFile 中。完成的时候删除或者过期的文件没有被移除，它们依然会出现在 HFile 中，对需要进行 Minor 合并的文件的选择是自动触发式的，Minor 合并会影响 HBase 的性能，所以合并文件的数目是有限制的，默认是10个。

Major 合并把所有 HFile 合并成一个 HFile，被删除或者过期的记录会被 丢弃，活动的以及没有被删除的文件会保留下来。一般在大型集群中都是手动去触发的。Major 合并不是 region 的合并，它发生在 HStore 里。在这里，同一个列族的所有 HFile 会被合并起来。这种合并也可以在一整张表上触发。这是一个耗时耗资源的操作，会影响性能，必须在集群查询请求小的时候触发。

说说什么是Region分裂和Region分配还有Region的合并

分裂是由 RegionServer 来做的，在一个 RS 中，一旦一个 region 的负载过大或者超过阈值256MB，会被分裂成新的 region。整个过程是这样的，首先需要分裂的 region 被 RS 下线，然后一个 region 分裂成两个，在 hbase:meta 中更新新的子 region 的信息，新的子 region 结构被打开并标记可用，region 的分裂信息更新到 HMaster。

说说HBase上如何删除数据

标记一下，等待 compact 的时候才真正删除底层存储的数据。

一句话HBase的读写

写请求发生会先写入 WAL，即 HLOG，然后是 MemStore，当两者达到阈值，才会刷写 flush 到磁盘实现持久化。

读请求先访问 hbase:meta 表获得并连接 RegionServer，按顺序访问 WAL ???, MemStore，最后到 HFile，此过程中只要读到所需要的数据，就会直接返回给客户端，因此会有可能读磁盘的。

RegionServer故障转移

RS 出现故障，其上的 Region 会被下线，不提供读写访问，一旦 HMaster 检测到故障发生，就会让分配的 Region 无效，Region 会被分配到另外一个 RegionServer 上。

说说WAL

每个 RS 都有一个 WAL，路径是 /.logs/.RegionServer/HLogs。

介绍一下HBase的特点

1. 水平可扩展、分布式开源的有序映射数据库
2. 运行在 HDFS 上
3. NoSQL 非关系数据库，不要求预定义的模式，弹性扩展，动态添加列
4. 自动的故障转移，自动分区以及模式自由这些特性
5. 一个主从数据库，HMaster 是主，用来协调客户端应用程序和 HRegionServer 之间的关系，同时监控和记录元数据的变化和管理
6. 通常 HMaster 跟 NameNode 运行在同一台主机

Rowkey不能太长的原因

rowkey 是一个二进制码流，rowkey 的长度被很多开发者建议说设计在10~100个字节，不过建议是越短越好，不要超过16个字节。

原因如下:

1. 数据的持久化文件 HFile 中是按照 KeyValue 存储的，如果 rowkey 过长比如100个字节，1000万列数据光 rowkey 就要占用100*1000万=10亿个字节，将近1G数据，这会极大影响 HFile 的存储效率；
2. MemStore 将缓存部分数据到内存，如果 rowkey 字段过长内存的有效利用率会降低，系统将无法缓存更多的数据，这会降低检索效率。因此 rowkey 的字节长度越短越好。
3. 目前操作系统是都是64位系统，内存8字节对齐。控制在16个字节，8字节的整数倍利用操作系统的最佳特性。

推荐系统初期为何考虑HBase

1. KV结构的存储，schema 灵活，方便扩展字段
2. 数据量大，不允许丢失，数据量增加速度快，扩展成本低
3. 吞吐量大，并发能力强，随机读取延迟比较低（毫秒级）
4. 高可用，自动故障隔离以及恢复

需要对 HBase 配置进行调优，目前存储的是数据量接近 200 G，支持每天千万次请求，需要保证多少次的百分比可以在 50ms 内返回。统计一下吞吐量。

比如通过以下命令:

1
2
3

# hdfs dfs -du -h /hbase/data/al_v1
6.9 G   20.8 G  /hbase/data/al_v1/al_rec_item_profile
21.9 G  65.6 G  /hbase/data/al_v1/al_rec_user_profile

总结一下HBase写的过程

可以画一下HBase简单的架构图吗

HBase和Hadoop混合部署的时候特征

一般 RegionServer 和 DataNode 混合部署，HMaster 和 NameNode 混合部署。

说说HBase的表是什么组成的

由分布在多个 RegionServer 中的 Region 组成，这些 RegionServer 又分布在不同的 DataNode 上。如果一个 Region 增长到一定阈值，为了降低 IO 时间和负载，HBase 可以自动或者手动把这些 Region 切为小 Region。

简单说说Hadoop的核心进程

1. NameNode: 存储和管理整个集群所有数据的元数据，跟 Hadoop 的联系是单点的，在新版本的 Hadoop 中通过拥有多个 NameNode 来实现高可用。
2. JobTracker: 运行在 NameNode 上，负责处理提交给集群的 MapReduce 任务。
3. SecondaryNameNode: 保存了 NameNode 的元数据的备份，以及文件系统的变化记录。Hadoop2 是 CheckPoint node?
4. DataNode: 实际存储数据。
5. TaskTracker: 在本地执行 JobTracker 分配来的任务。

简单说说HBase的内部存储架构

https://www.cnblogs.com/yanghuahui/p/3483754.html

使用 LSM 树存储文件，LSM 树把数据存储为两个独立的部分，并对底层存储进行优化，这种类型的数据结构依赖两种结构体，一个是当前使用的，比较小，存在内存中；另一个比较大，在持久化磁盘中。当内存中的数据不断增大并超出一定阈值，就会在磁盘中的大的结构体中进行合并，使用的是一种有序的合并算法（多路归并）。同时一个新的在内存中的结构体树被创建，以便实现新的插入需求。这样的做法，把随机数据访问转化为了顺序数据访问，提高了数据读的性能，并且数据合并是在后台进行的，不影响近端进程。

说说HBase的目录表

在 HBase 集群中，有两个表 –ROOT–（存储了 .META. 表的位置信息）和 .META. 存储了所有 Region 信息和它们的位置。

程序启动的时候，.Meta 的位置会写入到 root 中，实际的表的元数据会从这个位置读并且不断地读写。所以在任何时候如果一个客户端要连接到 HBase 进行表的读写操作做，这两个目录表都要被访问，并从中返回信息以便客户端能够直接读写要访问表的 RegionServer 和 Region。

如果HMaster宕机会发生什么

如果 Master 节点宕机，由于客户端是直接跟 RegionServer 交互的，整个集群是可以正常工作。但是 HMaster 负责比如 RegionServer 的故障转移，Region 的切分，如果 HMaster 宕机没有处理，这些功能就没法正常运作了。

分清楚Store

Region 组成表，Region 中的每个 Store 存储了一个 HBase 表的一个列族，在表的 Region 中每个 Store 有一个 Memstore ，Store 文件对应于表的每个 Region 或者每个 Memstore，Block 是 Store 文件的基本存储块。

HBase在HDFS的存储架构介绍一下

1
2
3
4
5

/hbase
/table
/Region
/ColumnFamily
/StoreFile

介绍一下WAL在HDFS上的存储架构

1
2
3

/.logs
/Regionserver
/HLogs: 保存所有修改日志的文件，存储在 HStore 中，就是所谓的 WAL 的位置了。每个 RegionServer 有一个 HLog 文件，对其中的 region 都会在这个日志文件上执行预写。

说说HBase的RPC机制

https://www.cnblogs.com/superhedantou/p/6476421.html

这篇博客图文并茂，写的非常精彩。

HBase什么时候才叫写数据写成功了

只有当数据成功写入 WAL 和 MemStore 之后，写操作才算是成功的。

说说HFile和列族的关系

每个列族可能有多个 HFile，但是每个 HFile 一定只有一个列族的数据。

Region什么时候会分裂

Region 分裂是由 RegionServer 来做的，一个 RegionServer 中，一旦一个 region 的负载过大或者超过阈值256MB，它就会分裂成新的 region。

Region是如何分配的

HMaster 调用 AssignmentManager 来进行 region 分配，AM 在 .META. 表中查看当前 region 分配的情况，如果 region 分配正确和有效，就会保持此 region，否则就会通过 LoadBalanceFactory 来创建 DefaultLoadBalancer。然后 DB 会分配一个新的 region 给 RegionServer，分配过程更新到 .META. 中。被分配的 region 就会被 RegionServer 打开并置为可用。

NameNode使用SSD的原因是什么

https://blog.csdn.net/Androidlushangderen/article/details/51105876

Hadoop 在2.6.0版本中引入了一个新特性异构存储。异构存储关键在于异构2个字。异构存储可以根据各个存储介质读写特性的不同发挥各自的优势。一个很适用的场景就是上篇文章提到的冷热数据的存储。针对冷数据。采用容量大的，读写性能不高的存储介质存储，比如最普通的Disk磁盘。而对于热数据而言，可以采用SSD的方式进行存储，这样就能保证高效的读性能，在速率上甚至能做到十倍于或百倍于普通磁盘读写的速度。换句话说，HDFS的异构存储特性的出现使得我们不需要搭建2套独立的集群来存放冷热2类数据，在一套集群内就能完成。所以这个功能特性还是有非常大的实用意义的。

知道HBase的JVM上的一些调优点吗

JVM 方面，开启并行 GC，-XX:+UseParallelGC，增加 GC Thread，-XX:ParallelGCThreads=<4，禁用内存自适应，设置对的 MAX 和 MIN 一样的值。禁用显示的 GC，防止开发人员主动 GC，-XX:+DisableExplicitGC

HBase支持Join操作吗

HBase 不支持任何形式的 join 操作，但它提供了行键的单一索引策略。仅在行级保证原子性。而且没有原子性保证跨行，这意味着没有多行事务。

表类型的设计

一般表分为两种类型

1. 短而宽: 这种设计模式可以被认为是以下情景，大量的列，很少的行
2. 高而瘦: 很少的列，大量的行

复合键是什么玩意

复合键是通过不同字段结合在一起形成行键，这里符合建也可以设计为 UserId + DateString + UserSessionId。

HBase开始键和结束键是指什么意思

表示一个 Region 的开始和结束的连续位置，也即 rowkey。

说说HBase region管理

压缩是为了减少 StoreFiles 的数量，一旦降低了数量，将可以得到更高的效率和性能，压缩是一个高资源消耗的过程。运行他会将每个 store 合并成一个 StoreFile。合并可以使用 merge 命令将同一个表的相邻区域合并来提高性能。

说说HBase在线备份的一些工作

不需要停止整个集群，也不会阻塞集群的操作，因此没有宕机时间。

1. HBase 快照: 可以针对表生成快照，而不用于 RegionServer 打交道。快照就是一系列元数据的集合，允许管理员将表恢复至生成快照的状态。快照不是针对表的复制，而是指集群中数据的分布，最简单的方式就是把它想象成追踪元数据和数据的一系列操作者偶读集合，生成快照的操作追踪没有执行任何复制数据的动作。
2. HBase 复制方法
3. 其他工具

HBase的一些总结

1. 努力保证每个region大小在 10~50 GB
2. 努力保证每个cell大小不超过10 MB，如果你使用 MOB, 那么不能超过50MB。 否则，就要考虑把数据存储在HDFS 中，而在HBase中存储数据的指针
3. 典型的模式每个表有1到3个列族。HBase表不应模仿RDBMS表设计
4. 对于具有1或2列族的表，大约50-100个区域是一个很好的数字。请记住，区域是列族的连续段，保持列族名称尽可能短。为每个值存储列族名称（忽略前缀编码）。它们不应该像典型的RDBMS那样自我记录和描述
5. 如果要存储基于时间的机器数据或日志记录信息，并且行键基于设备ID或服务ID加上时间，则最终可能会出现一种模式，即较旧的数据区域永远不会有超过特定年龄的额外写入。 在这种情况下，最终会出现少量活动区域和大量没有新写入的旧区域。对于这些情况，您可以容忍更多区域，因为您的资源消耗仅由活动区域驱动
6. 如果只有一个列族忙于写入，则只有该列族会使用内存。分配资源时，要注意写模式

💡赞赏支持

微信打赏 支付宝打赏