海量问题算法剖析
1.海量日志数据,提取出某日访问阿里次数最多的那个IP。
首先是这一天,并且是访问百度的日志中的IP取出来,逐个写入到一个大文件中。注意到ip是32位的,最多有个2^32个ip。同样可以采用映射的方法,比如模1000,把整个大文件映射为1000个小文件,在找出每个小文件中出现频率最大的ip(可以采用hash_map进行频率统计,然后再找出频率最大的几个)及相应的频率。然后再在这1000个最大的ip中,找出那个频率最大的ip,即为所求。
算法思想:分而治之+Hash
- IP地址最多有2^32=4G种取值情况,所以不能完全加载到内存中处理;
- 可以考虑采用“分而治之”的思想,按照IP地址的hash(ip)%1024,把海量IP日志分别存储到1024个小文件中。这样,每个小文件最多包含4MB个IP地址;
- 对于每个小文件,可以构建一个ip为key,出现次数为value的Hash map,同时记录当前出现次数最多的那个ip地址;
- 可以得到1024个小文件中的出现次数最多的ip,再依据常规的排序算法得到总体上出现次数最多的ip;
- 搜索引擎会通过日志文件把用户每次检索使用的所有的检索串都记录下来,每个查询串的长度是1-255字节;
2.假设目前有一千万个记录(这些查询串的重复读比较高,虽然总数是一千万,但如果出去重复后,不超过3百万个。一个查询串的重复度越高,说明查询它的用户越多,也就是越热门。)请你统计最热门的10个查询串,要求使用的内存不能超过1g。
第1步:先对这批海量数据预处理,在O(N)的时间内用Hash表完成统计。
第2步:借助堆这个数据结构,找出Top K,时间复杂度为Nlogk。
借助堆结构,我么可以在log量级的时间内查找和调整/移动。因此,维护一个K(该题目中是10)大小的小根堆,然后遍历300万的query,分别和根元素进行对比所以,我们最终的时间复杂度是:o(N)+n`*o(logk),(N为1000万,N·为300万)。
或者,采用trie树,关键字域存该查询串出现的次数,没有出现为0.最后用10个元素的最大堆来对出现的频率进行排序。
3.有一个1G大小的一个文件,里面每一行是一个词,词的大小不超过16字节,内存限制大小是1M,返回频数最高的100个词。
顺序读文件中,对于每个词X,取hash(X)%5000,然后按照该值存到5000个小文件(记为x0,x1,x2...x4999)中.这样每个文件大概是200k左右。如果其中的有的文件超过了1M大小,还可以按照类似的方法继续往下分,直到分解得到的小文件的大小都不超过1M。
对每个小文件,统计每个文件中出现的词以及相应的频率(可以采用trie树/hash_map等),并取出出现频率最大的100个词(可以用含100个结点的最小堆),并把100个词及相应的频率存入文件,这样又得到了5000个文件,下一步就是把这5000个文件进行归并(类似于归并排序)的过程了。
4.有10个文件,每个文件1G,每个文件的每一行存放的都是用户的query,每个文件的query都可能重复。要求你按照query的频度排序。
还是典型的TOP K算法,解决方案如下:
方案1:顺序读取10个文件,按照hash(query)%10的结果将query写入到另外10个文件(记为)中。这样新生成的文件每个的大小大约也1G(假设hash函数是随机的)。
找一台内存在2G左右的机器,依次对用hash_map(query,query_count)来统计每个query出现的次数。利用快速/堆/归并排序按照出现次数进行排序。将排序好的query和对应的query_count输出到文件中。这样得到了10个排序好的文件(记为)。对这10个文件进行归并排序(内排序与外排序相结合)。
方案2:
一般query的总量是有限的,只是重复的次数比较多而已,可以对于所有的query,一次性就可以加入到内存了。这样,我们就可以采用trie树/hash_map等直接来统计每个query出现的次数,然后按出现次数做快速/堆/归并排序就可以了。
方案3:
与方案1类似,但在昨晚hash,分成多个文件后,可以交给多个文件来处理,采用分布式的架构来处理(比如mapreduce),最后在进行合并。
5.给定a、b两个文件,各存放50亿个url,每个url各占64字节,内存限制是4G,让你找出a、b文件共同的url?
方案1:可以估计每个文件的大小为5G*64=320G,远远大于内存限制的4G。所以不可能将其完全加载到内存中处理,考虑采取分而治之的方法。
遍历文件A,对每个url求取hash(url)%1000,然后根据所取得的值将url分别存储到1000个小文件(记为a0,a1,...,a999)中,这样每个小文件大约为300M。
遍历文件b,采取和a相同的方式将url分别存储到1000小文件(记为a0vsb0,a1vsb1,...,a999vsb999)中,不对应的小文件不可能相同的url.然后我们只要求出1000对小文件中相同的url即可。
求每队小文件中相同的url时,可以把其中一个小文件的url存储到hash_set中。然后遍历另一个小文件的每个url,看其是否在刚才构建的hash_set中,如果是,那么就是共同的url,存到文件里面就可以了。
方案2:如果允许有一定的错误率,可以使用Bloom filter,4G内存大概可以表示340亿bit。将其中一个文件中的url使用bloom filter映射为这340亿bit,然后挨个读取另外一个文件的url,检查是否与Bloom filter,如果是,那么该url应该是共同的url(注意会有一定的错误率)。
Bloom filter日后会在本BLOG内详细阐述。
6.在2.5亿个整数中找到不重复的整数,注,内存不足以容纳这2.5亿个整数。
方案1:采用2-Bitmap(每个数分配2bit,00表示不存在,01表示出现一次,10表示多次,11无意义)进行,共需内存2^32*2bit=1GB内存,还可以接受。然后扫描这2.5亿个整数,查看Bitmap中相对应位,如果是00变01,01变10,10保持不变。扫描完事后,查看bitmap,把对应位是01的整数输出即可。
方案2:也可以用与第1题类似的方法,进行划分小文件的方法,然后在小文件中找出不重复的整数,并排序,然后再进行归并,注意去除重复的元素。
7.腾讯面试题:给40亿个不重复的unsigned int的整数,没排过序的,然后再给一个整数,如何快速判断这个数是否在那40亿个数中?
方法1:申请512M的内存,一个bit位代表一个unsigned int 值。读入40亿个数,设置相应的bit位,读入要查询的数,查看相应的bit是否为1,为1表示存在,为0表示不存在。
方法2:参考思路:
又因为2^32为40亿多,所以给定一个数可能在,也可能不在其中;
这里我们把40亿个数中的每一个用32位的二进制来表示
假设这40亿个数开始放在一个文件中。
然后将这40亿个数分成二类:
1.最高位为0
2.最高位为1
并将这两类分别写入到两个文件中,其中一个文件中数的个数《=20亿,而另一个》=20亿(这相当于折半了);
与要查找的数的最高位比较并接着进入相应的文件再查找
再然后把这个文件为又分成两类:
1.次最高位为0
2.次最高位为1
并将这两类分别写入到两个文件中,其中一个文件中数的个数《=10亿,而另一个》=10亿(这相当于折半了)
与要查找的数的次最高位比较并接着进入相应的文件再查找。
8.怎么在海量数据中找出重复次数最多的一个?
方案1:先做hash,然后求模映射为小文件,求出每个小文件中重复次数最多的一个,并记录重复次数,然后找出上一步求出的数据中重复次数最多的一个就是所求。
9.上千万或上亿数据(有重复),统计其中出现次数最多的前n个数据。
上千万或上亿的数据,现在的机器的内存应该能存下,所以考虑采用hash_map/搜索二叉树/红黑树等来进行统计次数。然后就是去出前N个出现次数最多的数据了。可以使用堆机制。
10.一个文本文件,大约有一万行,每行一个词,要求统计出其中最频繁出现的前10个词,请给出思想,给出实践复杂度分析。
这题是考虑时间效率,用trie树统计每个词出现的次数,时间复杂度是O(n*le)(le表示单词的平均长度)。然后是找出出现最频繁的前10个词,可以用堆实现,时间复杂度是O(n*lg10),所以总的时间复杂度是O(n*le)与O(n*lg10)中较大的哪一个。
五、双层桶划分---其实本质上就是分而治之的思想,重在“分”的技巧上!
适用范围:第K大,中位数,不重复或重复的数字
基本原理及要点:因为元素范围很大,不能利用直接寻址表,所以通过多次划分,逐步确定范围,然后最后在一个可以接受的范围内进行。可以通过多次缩小,双层只是一个例子。
扩展问题实例:
1)2.5亿个整数中找出不重复的个数,内存空间不足以容纳这2.5亿个整数
有点像鸽巢原理,整数个数为2^32,也就是,我们可以将这2^32个数, 划分为2^8个区域(比如用单个文件代表一个区域),然后将数据分离到不同的区域,然后不同的区域在利用bitmap就可以解决了,也就是说只要有足够的磁盘空间,就可以方便的解决问题。
2).5亿个int找它们的中位数
这个例子比上面的那个更明显。首先我们把int划分为2^16个区域,然后读取数据统计落到各个区域中的数的个数,之后我们根据统计结果就可以判断中位数落在那个区域,同时知道这个区域的第几大数刚好是中位数。然后第二次扫描我们只统计落在这个区域中的那些数就可以了。
六、数据库索引
使用范围:大数据量的增删改查
基本原理及要点:利用数据的设计实现方法,对于海量的增删改查进行处理。
七、倒排索引(Inverted index)
使用范围:搜索引擎、关键字查询
基本原理及要点:为何叫倒排索引?一种索引方法,被用来存储在全本搜索下某个单词在一个文档或者一组文档中的存储位置的映射。
以英文为例,下面是要被索引的文本:
T0="it is what it is"
T1="what is it"
T2="it is a banana"
我们就是得到下面的反向文件索引
"a":{2}
"banana":{2}
"is":{0,1,2}
"it":{0,1,2}
"what":{0,1}
检索的条件"what","is","it"将对应集合的交集
正向索引开发出来用来存储每个文档的单词的列表,正向索引的查询往往满足每个文档有序频繁的全文查询和每个单词在检验文档中的验证这样的查询。在正向索引中,文档占据了中心的位置,每个文档指向了一个它所包含的索引项的序列。也就是说文档指向了它包含的那些单词,而反向索引则是单词指向了包含它的文档,很容易看到这个反向的关系。
扩展问题实例:文档检索系统,查询那些文件包含了某个单词,比如常见的学术论文的关键词检索。
八、外排序
使用范围:大数据的排序,去重
基本原理及要点:外排序的归并方法,置换选择败者树原理,最有归并树
扩展问题实例:
1).有一个1G大小的一个文件,里面每一行是一个词,词的大小不超过16个字节,内存限制大小是1M。返回频数最高的100个词。
这个数据具有很明显的特点,词的大小为16个字节,但是内存只有1m做hash有些不够,所以可以用来排序,内存可以当输入缓冲区使用。
九、trie树
使用范围:数据量大,重复多,但是数据种类小可以放入内存
基本原理及要点:实现方式,节点孩子的表示方式
扩展问题实例:
1)有10个文件,每个文件1G,每个文件的每一行都存放的是用户的query,每个文件的query都是可能重复,要你按照query的频度排序
2)1000万字符串,其中有些是相同的(重复),需要把重复的全部去掉,保留没有重复的字符串。请问怎么设计和实现?
3)寻找热门查询:查询串的重复读比较高,虽然总数是1千万,但如果去除重复后,不超过3百万个,每个不超过255字节。
十、分布式处理mapreduce
使用范围:数据量大,但是数据类小可以放入内存
基本原理及要点:将数据交给不同的机器去处理,数据划分,结果归约
扩展问题实例:
1).海量数据分布在100台电脑中,想个办法高效统计出这批数据的TOP10.
2).一共有N个机器,每个机器上有N个数。每个机器最多存O(n)个数并对它们操作。如何找到N^2个数的中数(median)?
经典问题分析
上千万or亿数据(有重复),统计其中出现次数最多的前N个数据,分两种情况:可一次读入内存,不可一次读入。
可用思路:trie树+堆,数据库索引,划分子集分别统计,hash,分布式计算,近似统计,外排序
所谓的是否能一次读入内存,实际上应该指取出重复的数据量。如果取出重复的数据量可以放入内存,我们可以为数据创建字典,比如通过map,hashmap,trie,然后直接进行统计即可。当然在更新每天数据出现次数的时候,我们可以利用一个堆来维护出现次数最多的前N个数据,当然这样导致维护次数增加,不如完全统计后再求前N大效率高。
如果数据无法放入内存,一方面我们可以考虑上面的字典方法能否被改进以适应这种情形,可以做的改变就是把字典存放到硬盘上,而不是内存,这可以参考数据库的存储方法。
当然还有更好的方法,就是可以采用分布式计算,基本上就是map-reduce过程,首先可以根据数据值或者把数据hash(md5)后的值,将数据按照范围划分到不同的机子,最好可以让数据划分后可以一次读入内存,这样不同的机子负责处理各种的数值范围,实际就是map。得到结果后,各个机子只需拿出各自的出现次数最多的前N个数据,然后汇总,选出所有的数据中出现次数最多的前N个数据,这实际就是reduce过程。
实际上可能想直接将数据均分到不同的机子上进行处理,这样是无法得到正确的解的。因为一个数据可能被均分到不同的机子上,而另一个则可能 完全聚集到一个机子上,同时还可能存在具有相同数目的数据。比如,我们要找出次数最多的前100个,我们将1000万的数据分布到10台机器上,找到每台出现次数最多的前100个,归并之后这样不能保证找到真正的第100个,因为比如出现次数最多的第100个可能有1万个,但是它被分到了10台机器上,这样在每台上只有1千个,假设这些机子排名在1000个之前的那些都是单独分布在一台机器上的,比如有1001个,这样本来具1万个的这个就会被淘汰,即使我们让每台机器选出出现次数最多的1000个再归并,仍然会出错,因为可能存在大量个数为1001个的发生聚集。因此不能将数据随便均分到不同机器上,而是要根据hash后的值将它们映射到不同的机子上处理,让不同的机器处理一个数值范围。
- 点赞
- 收藏
- 关注作者
评论(0)