共计 4171 个字符，预计需要花费 11 分钟才能阅读完成。
锁屏面试题百日百刷，每个工作日保持更新面试题。请看到最初就能获取你想要的, 接下来的是今日的面试题：
1.解释一下布隆过滤器原理**
在日常生活中，包含在设计计算机软件时，咱们常常要判断一个元素是否在一个汇合中。比方在字处理软件中，须要查看一个英语单词是否拼写正确（也就是要判断它是否在已知的字典中）；在 FBI，一个嫌疑人的名字是否曾经在嫌疑名单上；在网络爬虫里，一个网址是否被拜访过等等。最间接的办法就是将汇合中全副的元素存在计算机中，遇到一个新元素时，将它和汇合中的元素间接比拟即可。一般来讲，计算机中的汇合是用哈希表（hash table）来存储的。它的益处是疾速精确，毛病是费存储空间。当汇合比拟小时，这个问题不显著，然而当汇合微小时，哈希表存储效率低的问题就显现出来了。比如说，一个象 Yahoo,Hotmail 和 Gmai 那样的公众电子邮件（email）提供商，总是须要过滤来自发送垃圾邮件的人（spamer）的垃圾邮件。一个方法就是记录下那些发垃圾邮件的 email 地址。因为那些发送者不停地在注册新的地址，全世界少说也有几十亿个发垃圾邮件的地址，将他们都存起来则须要大量的网络服务器。如果用哈希表，每存储一亿个 email 地址，就须要 1.6GB 的内存（用哈希表实现的具体办法是将每一个 email 地址对应成一个八字节的信息指纹 googlechinablog.com/2006/08/blog-post.html，而后将这些信息指纹存入哈希表，因为哈希表的存储效率个别只有 50%，因而一个 email 地址须要占用十六个字节。
一亿个地址大概要 1.6GB，即十六亿字节的内存）。因而存贮几十亿个邮件地址可能须要上百 GB 的内存。除非是超级计算机，个别服务器是无奈存储的。
布隆过滤器只须要哈希表 1/8 到 1/4 的大小就能解决同样的问题。
Bloom Filter 是一种空间效率很高的随机数据结构，它利用位数组很简洁地示意一个汇合，并能判断一个元素是否属于这个汇合。Bloom Filter 的这种高效是有肯定代价的：在判断一个元素是否属于某个汇合时，有可能会把不属于这个汇合的元素误认为属于这个汇合（false positive）。因而，Bloom Filter 不适宜那些“零谬误”的利用场合。
而在能容忍低错误率的利用场合下，Bloom Filter 通过极少的谬误换取了存储空间的极大节俭。
上面咱们具体来看 Bloom Filter 是如何用位数组示意汇合的。初始状态时，Bloom Filter 是一个蕴含 m 位的位数组，每一位都置为 0。
为了表白 S ={x1, x2,…,xn}这样一个 n 个元素的汇合，Bloom Filter 应用 k 个互相独立的哈希函数（Hash Function），它们别离将汇合中的每个元素映射到 {1,…,m} 的范畴中。对任意一个元素 x，第 i 个哈希函数映射的地位 hi(x)就会被置 为 1（1≤i≤k）。留神，如果一个地位屡次被置为 1，那么只有第一次会起作用，前面几次将没有任何成果。在下图中，k=3，且有两个哈希函数选中同一个地位（从右边数第五位）。
在判断 y 是否属于这个汇合时，咱们对 y 利用 k 次哈希函数，如果所有 hi(y)的地位都是 1（1≤i≤k），那么咱们就认为 y 是汇合中的元素，否则就认为 y 不是汇合中的元素。下图中 y1 就不是汇合中的元素。y2 或者属于这个汇合，或者刚好是一个 false positive。
· 为了 add 一个元素，用 k 个 hash function 将它 hash 失去 bloom filter 中 k 个 bit 位，将这 k 个 bit 地位 1。
· 为了 query 一个元素，即判断它是否在汇合中，用 k 个 hash function 将它 hash 失去 k 个 bit 位。若这 k bits 全为 1，则此元素在汇合中；若其中任一位不为 1，则此元素比不在汇合中（因为如果在，则在 add 时曾经把对应的 k 个 bits 地位为 1）。
· 不容许 remove 元素，因为那样的话会把相应的 k 个 bits 地位为 0，而其中很有可能有其余元素对应的位。因而 remove 会引入 false negative，这是相对不被容许的。
布隆过滤器决不会漏掉任何一个在黑名单中的可疑地址。然而，它有一条不足之处，也就是它有极小的可能将一个不在黑名单中的电子邮件地址断定为在黑名单中，因为有可能某个好的邮件地址刚巧对应个八个都被设置成一的二进制位。好在这种可能性很小，咱们把它称为误识概率。
布隆过滤器的益处在于疾速，省空间，然而有肯定的误识别率，常见的补救方法是在建设一个小的白名单，存储那些可能别误判的邮件地址。
2.如何实现 HBase 的二级索引?**
计划一: 通常状况下, 较原生形式, 咱们能够采纳 ES 或者 Solr 来实现 hbase 的二级索引的操作, 当用户要写入数据时候, 基于 hbase 的 observer 协处理器拦挡下来, 应用 es 或者 Solr 来构建 hbase 的索引数据, 这样当查问 hbase 中数据时候, 能够先去 ES 中查问到对应的数据, 而后依据后果, 在从 hbase 中获取最终的残缺的后果
计划二: 基于 Phoenix 实现, Phoenix 是一款基于 hbase 的 SQL 客户端, 能够应用 SQL 的形式来操作 hbase, 同时为了晋升整体的查问性能, Phoenix 中提供了各种索引 (全局索引, 本地索引, 笼罩索引以及函数索引), 这些索引都是基于 Hbase 的协处理器(次要是 ObServer 协处理器) 而实现的, 二基于索引的查问计划, 也是 Phoenix 实现 hbase 二级索引的形式
3.Hbase 的 storeFile(compact)合并机制是什么?**
compact 合并机制:
指的 memStore 中一直进行 flush 刷新操作, 就会产生多个 storeFile 的文件, 当 storeFile 的文
件达到肯定阈值后, 就会触发 compact 的合并机制, 将多个 storeFile 合并为一个大的 HFile 文件
阈值: 达到 3 个及以上
整个合并过程分为两大阶段:
minor :
作用: 将多个小的 storeFile 合并为一个较大的 Hfile 操作
阈值: 达到 3 个及以上
留神: 此合并过程, 仅仅将多个合并为一个, 对数据进行排序操作, 如果此时数据有过期, 或者有标记为删除数据, 此时不做任何的解决 (相似于 内存合并中根底型)
所以说, 此合并操作, 效率比拟高
major:
作用: 将较大的 HFile 和 之前的大的 Hfile 进行合并造成一个更大的 Hfile 文件 (全局合并)
阈值: 默认 7 天
留神: 此合并过程, 会将那些过期的数据, 或者曾经标记删除的数据, 在这次合并中, 全副
都革除掉，因为这是一种全局合并操作, 对性能影响比拟大, 在理论生产中, 倡议 敞开掉主动合并, 采纳手动触发的计划
4.Hbase 的 flush 刷新机制?**
flush 刷新机制(溢写合并机制):
流程: 客户端一直将数据写入到 memStore 内存中, 当内存中数据达到肯定阈值后, 须要
将数据溢写刷新的 HDFS 中 造成一个 storeFile 文件
阈值: 128M 或者 1 小时 满足了那个都会触发 flush 机制
外部具体流程: hbase 2.0 架构 以上流程
1) 客户端一直向 memStore 中写入数据, 当 memStore 只数据达到阈值后, 就会启动 flush 操作
2) 首先 hbase 会先敞开掉以后这个曾经达到阈值的内存空间, 而后开启一个新的 memStore 的空间, 用于持续写入工作
3) 将这个达到阈值的内存空间数据放入到 内存队列中, 此队列的个性是只读, 在 hbase 2.0 架构中, 能够设置此队列的数据尽可能晚的刷新到 HDFS 中, 当这个队列中数据达到某个阈值后(内存不足), 这个时候触发 flush 刷新操作 (队列中可能存储了多个 memStore 的数据)
4) flush 线程会将队列中所有的数据全副读取进去, 而后对数据进行排序合并操作, 将合并后数据存储到 HDFS 中, 造成一个 storeFile 的文件
留神: 在 hbase2.0 以下的架构中, 不存在推延刷新性能, 同样也不存在 合并数据的
操作当 memStore 数据达到阈值后, 放入到队列中, 专门有一个 flush 刷新监控队列, 一旦有数据间接刷新到 HDFS 上
留神阐明:
hbase 2.0 只是提供了基于内存的合并性能, 然而默认状况下 不开启的, 所以 在默认状况
下 整个 flush 机制根本和 2.0 以下的版本是统一的, 然而一旦开启了, 就是刚刚形容流程
合并计划: 三种根底型(basic): 间接将多个 memStore 数据合并在一起间接刷新到 HDFS 上, 如果数据存在过期的数据, 或者是曾经标记为删除的数据, 根底型不做任何解决
饥渴型(eager): 在将多个 memStore 合并的过程中, 踊跃判断数据是否存在过期, 或者是否曾经标记删除, 如果有, 间接过滤掉这些标记删除和过期的数据即可
适应性(adaptive): 检查数据是否有过期数据, 如果过期数据量达到肯定阈值后, 就会主动使
用饥渴型, 否则就应用根底型
5.如何解决 hbase 中数据热点问题?**
所谓数据热点, 指的是大量的数据写到 hbase 的某一个或者某几个 region 中, 导致其余的 region 没有数据, 其余 region 对应 regionServer 的节点接受了大量的并发申请, 此时就呈现了热点问题
解决方案: 通过预分区和设计良好的 rowkey 来解决
1)加盐解决(加随机数) : 能够在 rowkey 后面动静增加一些随机数, 从而保证数据能够平均落在不同 region 中
n 根本保证数据落在不同 region
n 将相关性比拟强的数据扩散在不同的额 region 中, 导致查问的效率有肯定升高
2)hash 解决: 依据 rowkey 计算其 hash 值, 在 rowkey 后面 hash 计算值即可 (MD5 HASH)
n 让相关性比拟强的数据能够被搁置到同一个 region 中
n 如果相干数据比拟多, 仍然会导致热点问题
3)反转策略: 比如说手机号反转 或者 工夫戳的反转
n 益处: 根本保证数据落在不同 region
n 弊病: 将相关性比拟强的数据扩散在不同的 region 中, 导致查问的效率有肯定升高
全部内容在 git 上, 理解更多请点我头像或到我的主页去取得，谢谢**
