面试--- 关于海量数据问题的处理具体解释
问题:
微博有11亿的用户,当中大约50万是蓝V用户,用户用uid标示,试设计一套架构,推断一个用户是否是蓝V,画出架构图,并给出关键算法。要求消耗的内存最小。效率最高。同一时候可以适应蓝V用户的动态增减。
海量数据问题的处理
个人感觉:这个题不仅考察了基础,同一时候又有project上的引申
思路:
(1)发现这是个类似redis的架构,KV(key-value)的结构:key是uid,(uid应是内部系统中用来表示用户的user id,是一个字符 串);value用一个位表示就可以。0或1,1表示是蓝V用户
(2)索引与hash,在涉及到查找的时候。能够使用一些数据结构中的知识,如红黑树。字典树。跳表,hash之类的,在这里。我考虑了一下,hash的效率是最高的,尽管它有大量的key是无法命中的,也会浪费一些存指针的空间,可是在瞬间性推断是否是该key的性能上是高的
(3)多机的可扩展性,因为数据量太大,单机的话内存可能无法hold住,这时候能够利用多机的可扩展性来解决,貌似涉及到分布式中的一致性哈希问题,这个不太熟悉,查阅后发现能够进行数据的动态处理的。
算法:
1、内存消耗最小
(1) 能够将全部的蓝V的uid通过hash变成一个key来表示,其余的非蓝V数据不存。这种话在查找的时候直接就来推断是否命中 key。命中了那么就是蓝V;
(2) 对于key,能够採用Bit-map和Bloom Filter来优化内存空间的消耗。因为採用了Bit为单位来存储数据。因此在存储空间方面。 能够大大节省。
2、效率最高
(1) 涉及到效率,就非常easy想到hash和查找树,所以这个key非常关键。在这里我採用了hash,尽管它有大量的key是无法命中的。 也会浪费一些存指针的空间。可是在瞬间性推断是否是该key的性能上是高的
(2) 关于uid。这是内部系统中用来表示用户的user id,是一个字符串,应该存在分级或者分布式存储的规律,比方省市级的数据分布区域划分,这种话就能够降低查找的范围,优化效率
3、适应性增减
(1)这里因为数据量太大,单机下内存无法hold住。所以涉及到了多机的可扩展性,这里关于添加,能够採用一致性哈希来进行机器的平缓的加入,降低的话貌似须要依据数据量来先分配内存。详细的细节待思考。
涉及知识点:
一、Bloom Filter
基础操作
位数组+k个独立hash函数。
将hash函数相应的值的位数组置1,查找时假设发现全部hash函数相应位都是1说明存在,非常明显这个过程并不保证查找的结果是100%正确的。同一时候也不支持删除一个已经插入的keyword,由于该keyword相应的位会牵动到其它的keyword。
所以一个简单的改进就是 counting Bloom filter,用一个counter数组取代位数组。就能够支持删除了。
扩展性问题
Bloom filter将集合中的元素映射到位数组中,用k(k为哈希函数个数)个映射位是否全1表示元素在不在这个集合中。
Counting bloom filter(CBF)将位数组中的每一位扩展为一个counter,从而支持了元素的删除操作。Spectral Bloom Filter(SBF)将其与集合元素的出现次数关联。SBF採用counter中的最小值来近似表示元素的出现频率
二、hash索引
哈希查找是通过计算数据元素的存储地址进行查找的一种方法。哈希查找的操作步骤:
⑴用给定的哈希函数构造哈希表;⑵依据选择的冲突处理方法解决地址冲突;⑶在哈希表的基础上运行哈希查找。 哈希查找步骤为:设哈希表为HST[0~M-1],哈希函数取H(key)。解决冲突的方法为R(x);Step1 对给定k值,计算哈希地址 Di=H(k);若HST为空,则查找失败。若HST=k,则查找成功;否则。运行step2(处理冲突)。Step2 反复计算处理冲突的下一个存储地址 Dk=R(Dk-1)。直到HST[Dk]为空,或HST[Dk]=k为止。
若HST[Dk]=K,则查找成功,否则查找失败。
三、redis
基于redis分布式缓存兑现