海量数据

海量数据处理问题 海量数据处理问题的解题关键 分而治之，通过hash函数将大任务分流到机器，或分流为小文件 常用hashMap或bitmap 1.海量日志数据，提取出某日访问百度次数最多的那个IP. 访问百度的日志中取出IP，逐个写入一个大文件中，采用映射的方法，比如说模1000，将大文件映射成1000个小文件，再找出每个小文件中出现频率最大的IP,以及相应的频率(构建IP为key,出现频率为value的Hash Map)。然后在这1000个最大的IP,然后找出频率最大的IP(通过内排序算法)。 2.搜索引擎会通过日志文件把用户每次检索使用的所有检索串都记录下来，每个查询串的长度为1-255个字节，假设目前有1000W个记录(其中有大量的重复，去重后大约还剩300W个， 一个查询的重复度越高，该记录越热门)，请统计当前最热门的10个查询串，要求使用内存不能超过1G. Top K算法: 1.对这些海量数据进行批处理，在O(n)的时间内使用hash表完成统计()。 2.借助于堆，找出Top K，时间复杂度为N LogK (此时N为300W)。 3.有一个1G大小的文件，里面的每一行是一个词，词的大小不超过16个字节，内存限制大小事1M,返回频度最高的100个词。 顺序读取文件，对于每个词x，取hash(x)%5000存到500个小文件当中，每个小文件大概是200K左右

下面的方法是我对海量数据的处理方法进行了一个一般性的总结，当然这些方法可能并不能完全覆盖所有的问题，但是这样的一些方法也基本可以处理绝大多数遇到的问题。下面的一些问题基本直接来源于公司的面试笔试题目，方法不一定最优，如果你有更好的处理方法，欢迎与我讨论。 1.Bloom filter 适用范围：可以用来实现数据字典，进行数据的判重，或者集合求交集 基本原理及要点： 对 于原理来说很简单，位数组+k个独立hash函数。将hash函数对应的值的位数组置1，查找时如果发现所有hash函数对应位都是1说明存在，很明显这 个过程并不保证查找的结果是100%正确的。同时也不支持删除一个已经插入的关键字，因为该关键字对应的位会牵动到其他的关键字。所以一个简单的改进就是 counting Bloom filter，用一个counter数组代替位数组，就可以支持删除了。 还有一个比较重要的问题，如 何根据输入元素个数n，确定位数组m的大小及hash函数个数。当hash函数个数k=(ln2)*(m/n)时错误率最小。在错误率不大于E的情况 下，m至少要等于n*lg(1/E)才能表示任意n个元素的集合。但m还应该更大些，因为还要保证bit数组里至少一半为 0，则m 应该>=nlg(1/E)*lge 大概就是nlg(1/E)1.44倍(lg表示以2为底的对数)。 举个例子我们假设错误率为0.01

转载自：http://blog.csdn.net/cyjch/article/details/51569377 一、数据量过大，数据中什么情况都可能存在。如果说有10条数据，那么大不了每条去逐一检查，人为处理，如果有上百条数据，也可以考虑，如果数据上到千万级别，甚至过亿，那不是手工能解决的了，必须通过工具或者程序进行处理，尤其海量的数据中，什么情况都可能存在，例如，数据中某处格式出了问题，尤其在程序处理时，前面还能正常处理，突然到了某个地方问题出现了，程序终止了。 二、软硬件要求高，系统资源占用率高。对海量的数据进行处理，除了好的方法，最重要的就是合理使用工具，合理分配系统资源。一般情况，如果处理的数据过TB级，小型机是要考虑的，普通的机子如果有好的方法可以考虑，不过也必须加大CPU和内存，就象面对着千军万马，光有勇气没有一兵一卒是很难取胜的。 三、要求很高的处理方法和技巧。这也是本文的写作目的所在，好的处理方法是一位工程师长期工作经验的积累，也是个人的经验的总结。没有通用的处理方法，但有通用的原理和规则。 那么处理海量数据有哪些经验和技巧呢，我把我所知道的罗列一下，以供大家参考： 一、选用优秀的数据库工具 现在的数据库工具厂家比较多，对海量数据的处理对所使用的数据库工具要求比较高，一般使用Oracle或者DB2，微软公司最近发布的SQL Server 2005性能也不错

1 设计阶段的优化 1.1 表设计 1.1.1 范式化 数据库设计三范式定义： 1. 第一范式：每个字段只包含最小的信息属性。 例如常见的学号：入学年份+班级+编号，是不符合第一范式的，需要将其拆解为：入学年份、班级、编号。 2. 第二范式：（在满足第一范式基础上） 模型含有主键，非主键字段依赖主键。 3. 第三范式：（在满足第二范式基础上） 模型非主键字段不能相互依赖 。 例如订单表，一般来说订单表的主键是订单号。在此表中，字段下单时间、客户ID是符合第二范式的，而客户姓名这个字段就不满足第二范式，应当放入客户表内，组成客户ID客户姓名。 范式化的设计能有效降低数据冗余，更新方便快速，降低了数据不一致的风险。故常见于联机交易型的数据库。 1.1.2 反范式化 有意不符合范式化的设计，常见于反第二第三范式。 符合三范式的设计在降低冗余的同时也带来了问题。如果需要对数据进行加工处理（例如具有订单表、客户表，需要统计某个年龄的客户的订单总金额）的时候，需要不断进行关联操作。当订单数量极为庞大的时候，这个关联操作所需要消耗的资源将会相当巨大，导致查询性能低下。因此在数据仓库的海量数据的处理中，常使用反范式化的方式进行设计来提高性能，用空间换取时间。例如在订单表内添加上下订单的客户的生日，则只需直接执行筛选即可。 反范式化的设计并没有定势，需要视具体的业务而定

在实际的工作环境下，许多人会遇到海量数据这个复杂而艰巨的问题，它的主要难点有以下几个方面： 一、数据量过大，数据中什么情况都可能存在。 如果说有10条数据，那么大不了每条去逐一检查，人为处理，如果有上百条数据，也可以考虑，如果数据上到千万级别，甚至 过亿，那不是手工能解决的了，必须通过工具或者程序进行处理，尤其海量的数据中，什么情况都可能存在，例如，数据中某处格式出了问题，尤其在程序处理时， 前面还能正常处理，突然到了某个地方问题出现了，程序终止了。 二、软硬件要求高，系统资源占用率高。 对海量的数据进行处理，除了好的方法，最重要的就是合理使用工具，合理分配系统资源。一般情况，如果处理的数据过TB级，小型机是要考虑的，普通的机子如果有好的方法可以考虑，不过也必须加大CPU和内存，就象面对着千军万马，光有勇气没有一兵一卒是很难取胜的。 三、要求很高的处理方法和技巧。 这也是本文的写作目的所在，好的处理方法是一位工程师长期工作经验的积累，也是个人的经验的总结。没有通用的处理方法，但有通用的原理和规则。 下面我们来详细介绍一下处理海量数据的经验和技巧： 一、选用优秀的数据库工具 现在的数据库工具厂家比较多，对海量数据的处理对所使用的数据库工具要求比较高，一般使用Oracle或者DB2，微软 公司最近发布的SQL Server 2005性能也不错。另外在BI领域：数据库，数据仓库

海量信息即大规模数据，随着互联网技术的发展，互联网上的信息越来越多，如何从海量信息中提取有用信息成为当前互联网技术发展必须面对的问题。 在海量数据中提取信息，不同于常规量级数据中提取信息，在海量信息中提取有用数据，会存在以下几个方面的问题： （1）数据量过大，数据中什么情况都可能存在，如果信息数量只有20条，人工可以逐条进行查找、比对，可是当数据规模扩展到上百条、数千条、数亿条，甚至更多时，仅仅只通过手工已经无法解决存在的问题，必须通过工具或者程序进行处理。 （2）对海量数据信息处理，还需要有良好的软硬件配置，合理使用工具，合理分配系统资源。通常情况下，如果需要处理的数据量非常大，超过了TB级，小型机、大型工作站是要考虑的，普通计算机如果有好的方法也可以考虑，如通过联机做成工作集群。 （3）对海量信息处理时，要求很高的处理方法和技巧，如何进行数据挖掘算法的设计以及如何进行数据的存储访问等都是研究的难点。 针对海量数据的处理，可以使用的方法非常多，常见的方法有Hash法、Bit-map法、Bloom filter法、数据库优化法、倒排索引法、外排序法、Trie树、堆、双层桶法以及MapReduce法。 Hash法 哈希函数的特点 哈希函数的构建方法 解决冲突的方法 Bit-map法 Bloom filter法 数据库优化法 倒排索引法 外排序法 Trie树 堆 双层桶法

1. 给定a、b两个文件，各存放50亿个url，每个url各占64字节，内存限制是4G，让你找出a、b文件共同的url？ 方案1：可以估计每个文件安的大小为50G×64=320G，远远大于内存限制的4G。所以不可能将其完全加载到内存中处理。考虑采取分而治之的方法。 s 遍历文件a，对每个url求取 ，然后根据所取得的值将url分别存储到1000个小文件（记为 ）中。这样每个小文件的大约为300M。 s 遍历文件b，采取和a相同的方式将url分别存储到1000各小文件（记为 ）。这样处理后，所有可能相同的url都在对应的小文件（ ）中，不对应的小文件不可能有相同的url。然后我们只要求出1000对小文件中相同的url即可。 s 求每对小文件中相同的url时，可以把其中一个小文件的url存储到hash_set中。然后遍历另一个小文件的每个url，看其是否在刚才构建的hash_set中，如果是，那么就是共同的url，存到文件里面就可以了。 方案2：如果允许有一定的错误率，可以使用Bloom filter，4G内存大概可以表示340亿bit。将其中一个文件中的url使用Bloom filter映射为这340亿bit，然后挨个读取另外一个文件的url，检查是否与Bloom filter，如果是，那么该url应该是共同的url（注意会有一定的错误率）。 2. 有10个文件，每个文件1G

1. 给定一个大小超过 100G 的文件, 其中存在 IP 地址, 找到其中出现次数最多的 IP 地址(hash文件切分) 把这个100个G的文件分成1000份左右的文件，然后把这个100个G里面相同的IP地址， 使用相同的散列 函数将所有IP地址 转换为一个整数key，再利用 index=key%1000就可将相同IP分到同一个文件 2. 给定100亿个整数, 找到其中只出现一次的整数(位图变形, 用两位来表示次数). 这100亿个数据有三种状态：不存在、 存在一次、存在多次。 故此，我们需要对传统位图进行扩展，用两位来表示一个整数的状态：00表示不存在、01表示存在一次， 10表示存在多次， 11表示无效状态。 3. 有两个文件, 分别有100亿个query(查询词, 字符串), 只有1G内存, 找到两个文件的交集(hash文件切分 + 布隆过滤器). 在32位操作系统下，一个整数有32个字节，所以100亿整数 = 100 * 4字节 = 40G，所以不能一次性查找 精确的算法：哈希文件切分 将两个文件中的query hash到N个小文件中，并标明query的来源， 在各个小文件中找到重合的query 将找到的重合query汇总，得到交集 近似算法：使用布隆过滤器 把一个文件的内容存入布隆过滤器，然后使用另一个布隆过滤器中查找是否存在，找到交集的元素，因为 可能出现哈希冲突

不得不说，Hadoop确实是处理海量离线数据的利器，当然，凡是一个东西有优点必定也有缺点，hadoop的缺点也很多，比如对 流式计算 ， 实时计算 ， DAG 具有依赖关系的计算，支持都不友好，所以，由此诞生了很多新的分布式计算框架，Storm，Spark，Tez，impala，drill，等等，他们都是 针对特定问题提出一种解决方案 ，新框架的的兴起，并不意味者他们就可以替代hadoop，一手独大，HDFS和MapReduce依旧是很优秀的，特别是对离线海量数据的处理。 hadoop在如下的几种应用场景里，用的还是非常广泛的，1，搜索引擎建索引，2，topK热关键词统计，3，海量日志的数据分析等等。 今天的这个例子的场景要对几亿的单词或短语做统计和并按词频排序，当然这些需求都是类似WordCount问题，如果你把Hadoop自带的WordCount的例子，给搞懂了，基本上做一些IP，热词的统计与分析就很很容易了，WordCount问题，确实是一个非常具有代表性的例子。 下面进入正题，先来分析下散仙这个例子的需求，总共需要二步来完成，第一步就是对短语的统计，第二步就是对结果集的排序。所以如果使用MapReduce来完成的话，就得需要2个作业来完成这件事情，第一个作业来统计词频，第二个来负责进行排序，当然这两者之间是有依赖关系的，第二个作业的执行，需要依赖第一个作业的结果

一 、Hadoop 简介： 1. 大数据略知一二： 1）大数据（big data），指无法在一定时间范围内用常规软件工具进行捕捉、管理和处理的数据集合，是需要新处理模式才能具有更强的决策力、洞察发现力和流程优化能力的海量、高增长率和多样化的信息资产，需要在合理的时间内达到提取、管理、处理、并且整理成为帮助企业运营决策更积极目的的信息； 2）在维克托·迈尔-舍恩伯格及肯尼斯·库克耶编写的《大数据时代》 中大数据指不用随机分析法（抽样调查）这样捷径，而采用所有数据进行分析处理； 3）大数据的5V特点（IBM提出）：Volume（大量）、Velocity（高速）、Variety（多样）、Value（低价值密度）、Veracity（真实性）。 图解大数据： http://www.ruanyifeng.com/blog/2017/07/iaas-paas-saas.html 3. 项目起源： Hadoop由 Apache Software Foundation 公司于 2005 年秋天作为Lucene的子项目Nutch的一部分正式引入。它受到最先由 Google Lab 开发的 Map/Reduce 和 Google File System(GFS) 的启发。2006 年 3 月份，Map/Reduce 和 Nutch Distributed File System (NDFS)