海量数据

常见的海量数据处理、操作的题目： 1.给定a、b两个文件，各存放50亿个url，每个url各占64字节，内存限制是4G，让你找出a、b文件共同的url？ 2.有10个文件，每个文件1G，每个文件的每一行存放的都是用户的query，每个文件的query都可能重复。要求你按照query的频度排序。 3.有一个1G大小的一个文件，里面每一行是一个词，词的大小不超过16字节，内存限制大小是1M。返回频数最高的100个词。 4.海量日志数据，提取出某日访问百度次数最多的那个IP。 5.在2.5亿个整数中找出不重复的整数，内存不足以容纳这2.5亿个整数。 6.海量数据分布在100台电脑中，想个办法高效统计出这批数据的TOP10。 7.怎么在海量数据中找出重复次数最多的一个？ 8.上千万或上亿数据（有重复），统计其中出现次数最多的钱N个数据。 9.1000万字符串，其中有些是重复的，需要把重复的全部去掉，保留没有重复的字符串。请怎么设计和实现？ 10.一个文本文件，大约有一万行，每行一个词，要求统计出其中最频繁出现的前10个词，请给出思想，给出时间复杂度分析。 11.一个文本文件，找出前10个经常出现的词，但这次文件比较长，说是上亿行或十亿行，总之无法一次读入内存，问最优解。 12. 100w个数中找出最大的100个数。 13.寻找热门查询：

最近在笔试和面试中遇到了很多关于海量数据的问题，在此进行简单的记录， 写一篇方便自己下次学习的处理海量数据的文章及 在线笔记，同时也希望对你有所帮助。当然，海量数据最出名的还是 七月July ，但这里我是想直接从实际题目出发，并参考及摘抄了他们那些大牛的文章及自己的想法进行简单总结记录。 一. 原题重现 2015年9月27日百度笔试论述题二选一，其中第一道是关于MapReduce相关的；第二道是搜索引擎中url去重，海量数据集url如何在爬取过程中避免重复爬取过的url。 PS：通常搜索引擎网页去重是通过文档特征提取，再计算相似性或集合Hash实现。 下面是常见的题型： 1.Hash算法处理海量数据部分 【题目1】(安卓越 2012) 给定a、b两个文件，各存放50亿个url，每个url各占64字节，内存限制是4G，让你找出a、b文件共同的url？ 【题目2】海量日志数据，提取出某日访问百度次数最多的那个IP。 【题目3】有10个文件，每个文件1G，每个文件的每一行存放的都是用户的query，每个文件的query都可能重复。要求你按照query的频度排序。 【题目4】有一个1G大小的一个文件，里面每一行是一个词，词的大小不超过16字节，内存限制大小是1M。返回频数最高的100个词。 2.Top-K海量数据部分 【题目1】(360公司 2012) 100万条记录的文本文件

面试笔记–海量数据题目处理总结 何谓海量数据处理？ 所谓海量数据处理，无非就是基于海量数据上的存储、处理、操作。何谓海量，就是数据量太大，所以导致要么是无法在较短时间内迅速解决，要么是数据太大，导致无法一次性装入内存。 那解决办法呢?针对时间，我们可以采用巧妙的算法搭配合适的数据结构，如Bloom filter/Hash/bit-map/堆/数据库或倒排索引/trie树，针对空间，无非就一个办法：大而化小，分而治之（hash映射），你不是说规模太大嘛，那简单啊，就把规模大化为规模小的，各个击破不就完了嘛。 至于所谓的单机及集群问题，通俗点来讲，单机就是处理装载数据的机器有限(只要考虑cpu，内存，硬盘的数据交互)，而集群，机器有多辆，适合分布式处理，并行计算(更多考虑节点和节点间的数据交互)。 海量数据处理的方法 处理海量数据问题，无非就是 6 种方法： 分而治之/hash映射 + hash统计 + 堆/快速/归并排序； 分而治之/hash映射：针对数据太大，内存受限，只能把大文件化成(取模映射)小文件 hash_map统计：当大文件转化了小文件，那么我们便可以采用常规的hash_map(key，value)来进行频率统计。 堆/快速排序：统计完了之后，便进行排序(可采取堆排序)，得到次数最多的key。 多层划分 多层划分—-其实本质上还是分而治之的思想，重在“分”的技巧上！

原文链接： BAT直通车-海量数据专题 更多精彩内容(BAT招聘、笔试、面试、技术)，请访问 BAT直通车 题目 问题一：现有海量日志数据，要提取出某日访问百度次数最多的那个IP(可以将题干简化，假设日志中仅包含IP数据，也就是说待处理的文件中包含且仅包含全部的访问IP，但内存空间有限，不能全部加载，假设只有512MB) 解决方案： 这是一道典型的分治思想的题目，这种问题处理起来套路比较固定，对于大部分的数据量比较大的前提的问题而言，分治都是一个可选的解决方案，但不一定是最优的，解决方法基本划分为三步走： 第一：如何有效的划分数据 第二：如何在子集上解决问题 第三：如何合并结果 那么对于本问题就显得比较明显了： 首先解决如何划分，由于IP地地址范围从000.000.000.000~255.255.255.255共有2^32个大约4GB，那么我们可以通过取模的方式进行划分，直接将四段数据相连就得到一个IP对应的数字A，再对A模1024(模数取多少可以自己指定，保证每个小文件能被放到内存就好)，这样大文件被划分成小文件了，并且相同的IP一定被划分到相同的文件中。 其次解决每个小文件中TOP1的问题： 这里可以用很多方式进行处理，比如你可以构造自己的HashMap,key为IP，value为当前出现次数，最后找到value最大的Key即为当前文件中出现次数最多的IP。

哈希切割top K问题 给一个超过100G大小的log file, log中存着IP地址, 设计算法找到出现次数最多的IP地址？ 与上题条件相同，如何找到top K的IP？ （1）文件太大，100g，肯定不可能一次加载到内存进行处理，这里就必须将文件进行切割了，可是依据哪种方法进行切割呢？假设只是从前到后等份切割的话，将文件切割n份(切割的份数依据所给的内存大小)，第一份中假设IP地址为a出现次数最多，第二份中b出现的次数最多，这样比较出来，假设a比b大，那得出的结果就是IP地址为a的出现次数多，可是？假设第一份中也有地址为b的IP呢？这样分割出来的文件，不能保证相同IP地址被分到同一个文件当中，这样算出的结果就肯定不正确了。这里我们应该想到使用哈希的思想，我们可以给出n个文件，(n的取值取决于给定的内存大小)，将点分十进制的IP地址转化为整数，利于哈希函数(哈希函数采用直接定址法)，求出IP地址所对应文件的编号，这样将所有地址分派到不同编号的文件中，相同的地址一定在同一个文件当中，依次遍历每个文件，统计出每个IP地址出现的次数，这样就可以找到出现次数最多的IP地址。 （2）top K问题的解决办法我们很容易想到用堆，首先，搞清楚是要出现次数最多的K个IP还是出现次数最少的K个IP，如果是最多的，可以给小堆，如果最少的，给的就是大堆；假设这里我们要的是出现次数最多的K个IP

from: http://kenby.iteye.com/blog/1031124 一 给定a、b两个文件，各存放50亿个url，每个url各占用64字节，内存限制是4G，如何找出a、b文件共同的url？ 两个50亿个url的文件，大概有50 0000 0000 * 64 B = 640G的大小，肯定不能全部读入内存，可以分组解决.准备1030个桶，读取两个文件的url，对每个url，通过hash(url)%1031， 把url映射到其中一个桶，然后把每个桶的url都写入一个文件，得到1030个文件，每个文件大约640M大，可以断定，相同的url只可能出现在一个文件中。所以接下来只需依次把1030个文件读入内存，再次通过hash表找出相同的url，当然这次的hash函数不要跟上次用一样的，不然每个url都会出现冲突。最后汇总到一个文件，即得到了结果。算法中之所以取1031的模，是因为1031是素数，且接近1024。 二 有10个文件，每个文件1G，每个文件的每一行都存放的是用户的query，每个文件的query都可能重复。如何按照query的频度排序？ 总共要处理10G的数据，想办法分割成512份，每份大小为20M.准备520个桶，读取10个文件的query，对每一个query，通过hash(query)%521，把query映射到其中一个桶，然后把每个桶的query写入一个文件

目标 Ø 掌握数据库的大数据处理方案和HA Ø 掌握为什么需要数据库中间件，何为数据库中间件 Ø 掌握不同场景所需的数据库中间件特性 Ø 掌握数据库中间件设计要点 Sharding-JDBC用途、使用场景、架构 认识ShardingSphere ShardingSphere是一套开源的分布式数据库中间件解决方案组成的生态圈，它由Sharding-JDBC、 Sharding-Proxy和Sharding-Sidecar（计划中）这3款相互独立的产品组成。 他们均提供标准化 的数据分片、分布式事务和数据库治理功能，可适用于如Java同构、异构语言、容器、云原生等 各种多样化的应用场景。 当前版本：3.0 官网地址：https://shardingsphere.apache.org/index_zh.html 官方文档：https://shardingsphere.apache.org/document/current/cn/overview/ Sharding-JDBC： 定位为轻量级Java框架，在Java的JDBC层提供的额外服务。 它使用客户端直 连数据库，以jar包形式提供服务，无需额外部署和依赖，可理解为增强版的JDBC驱动，完全 兼容JDBC和各种ORM框架。 Ø 适用于任何基于Java的ORM框架，如：JPA, Hibernate, Mybatis, Spring

1.分区 2.缓存 3.一主多从分离读多写少的压力 4.写的压力：分库分表 4.1分分表 水平切分： 数据库的垂直切分：按照 表功能和数据关联密切程度；表太多造成的海量数据考虑按业务逻辑划分；能缓解数据量和访问量造成的问题但不能根治； 表的垂直切分：可以分到多库中，不遵守范式 表的水平切分：解决单表数据量太大的问题、提高了稳定性和负载能力、应用端改造少 无论那种切分缺点都有分布式事务、节点join、跨节点合并排序分页、多数据源管理问题 5.中间件 1.作用：解析sql、读写分离、从库读的负载均衡、支持分库分表操作、支持垮裤关联、支持事务、主键ID生成、多数据源管理 2.类型：客户端模式(sharding-jdbc TDDL)、服务端代理模式(mycat cobar atlas heinsberge vitess kingshard) 6.分片优点 1.减少增量数据写入时的锁对查询的影响，减少长时间查询造成的表锁、锁竞争、排队时间开支 2.单表查询的基数变小、io减少、时延变短 7.实际粒度的掌控 业务紧密程度和表的数据量 7.1 表关系紧密且数据量不大、增速缓慢，则放在一起，无需水平切分； 7.2若划归到一起的表增速迅猛 则需要分库再分表 垂直分表：按照业务功能的使用频次，分成主次表 8.拆分原则 8.1能不拆就不拆 8.2提前规划好切分规则 8

目标 Ø 掌握数据库的大数据处理方案和HA Ø 掌握为什么需要数据库中间件，何为数据库中间件 Ø 掌握不同场景所需的数据库中间件特性 Ø 掌握数据库中间件设计要点 Sharding-JDBC用途、使用场景、架构 认识ShardingSphere ShardingSphere是一套开源的分布式数据库中间件解决方案组成的生态圈，它由Sharding-JDBC、 Sharding-Proxy和Sharding-Sidecar（计划中）这3款相互独立的产品组成。 他们均提供标准化 的数据分片、分布式事务和数据库治理功能，可适用于如Java同构、异构语言、容器、云原生等 各种多样化的应用场景。 当前版本：3.0 官网地址：https://shardingsphere.apache.org/index_zh.html 官方文档：https://shardingsphere.apache.org/document/current/cn/overview/ Sharding-JDBC： 定位为轻量级Java框架，在Java的JDBC层提供的额外服务。 它使用客户端直 连数据库，以jar包形式提供服务，无需额外部署和依赖，可理解为增强版的JDBC驱动，完全 兼容JDBC和各种ORM框架。 Ø 适用于任何基于Java的ORM框架，如：JPA, Hibernate, Mybatis, Spring

原创博客，转载请注明： http://my.oschina.net/BreathL/blog/75112 最近做了一个项目，要求找出二度人脉的一些关系，就好似新浪微博的“你可能感兴趣的人” 中，间接关注推荐；简单描述：即你关注的人中有N个人同时都关注了 XXX 。 在程序的实现上，其实我们要找的是：若 User1 follow了10个人 ｛User3，User4，User5，... ，User12｝记为集合UF1，那么 UF1中的这些人，他们也有follow的集合，分别是记为： UF3（User3 follow的人），UF4，UF5，...，UF12；而在这些集合肯定会有交集，而由最多集合求交产生的交集，就是我们要找的：感兴趣的人。 我在网上找了些，关于二度人脉算法的实现，大部分无非是通过广度搜索算法来查找，由于深度已经明确了2以内；这个算法其实很简单，第一步找到你关注的人；第二步找到这些人关注的人，最后找出第二步结果中出现频率最高的一个或多个人，即完成。 但如果有千万级别的用户，那在运算时，就肯定会把这些用户的follow 关系放到内存中，计算的时候依次查找；先说明下我没有明确的诊断对比，这样做的效果不一定就不如 基于hadoop实现的好；只是自己，想用hadoop实现下，最近也在学；若有不足的地方还请指点。 首先，我的初始数据是文件，每一行为一个follow 关系 ida+‘