【精品】海量数据处理分析

【精品】海量数据处理分析
【精品】海量数据处理分析

海量数据处理分析

北京迈思奇科技有限公司戴子良

笔者在实际工作中,有幸接触到海量的数据处理问题,对其进行处理是一项艰巨而复杂的任务。原因有以下几个方面:

一、数据量过大,数据中什么情况都可能存在。如果说有10条数据,那么大不了每条去逐一检查,人为处理,如果有上百条数据,也可以考虑,如果数据上到千万级别,甚至过亿,那不是手工能解决的了,必须通过工具或者程序进行处理,尤其海量的数据中,什么情况都可能存在,例如,数据中某处格式出了问题,尤其在程序处理时,前面还能正常处理,突然到了某个地方问题出现了,程序终止了。

二、软硬件要求高,系统资源占用率高。对海量的数据进行处理,除了好的方法,最重要的就是合理使用工具,合理分配系统资源。一般情况,如果处理的数据过TB级,小型机是要考虑的,普通的机子如果有好的方法可以考虑,不过也必须加大CPU和内存,就象面对着千军万马,光有勇气没有一兵一卒是很难取胜的。

三、要求很高的处理方法和技巧。这也是本文的写作目的所在,好的处理方法是一位工程师长期工作经验的积累,也是个人的经验的总结。没有通用的处理方法,但有通用的原理和规则。

那么处理海量数据有哪些经验和技巧呢,我把我所知道的罗列一下,以供大家参考:

一、选用优秀的数据库工具

现在的数据库工具厂家比较多,对海量数据的处理对所使用的数据库工具要求比较高,一般使用Oracle或者DB2,微软公司最近发布的SQL Server 2005性能也不错。另外在BI领域:数据库,数据仓库,多维数据库,数据挖掘等相关工具也要进行选择,象好的ETL工具和好的OLAP工具都十分必要,例如Informatic,Eassbase等。笔者在实际数据分析项目中,对每天6000万条的日志数据进行处理,使用SQL Server 2000需要花费6小时,而使用SQL Server 2005则只需要花费3小时。

二、编写优良的程序代码

处理数据离不开优秀的程序代码,尤其在进行复杂数据处理时,必须使用程序。好的程序代码对数据的处理至关重要,这不仅仅是数据处理准确度的问题,更是数据处理效率的问题。良好的程序代码应该包含好的算法,包含好的处理流程,包含好的效率,包含好的异常处理机制等。

三、对海量数据进行分区操作

对海量数据进行分区操作十分必要,例如针对按年份存取的数据,我们可以按年进行分区,不同的数据库有不同的分区方式,不过处理机制大体相同。例如SQL Server的数据库分区是将不同的数据存于不同的文件组下,而不同的文件组存于不同的磁盘分区下,这样将数据分散开,减小磁盘I/O,减小了系统负荷,而且还可以将日志,索引等放于不同的分区下。

四、建立广泛的索引

对海量的数据处理,对大表建立索引是必行的,建立索引要考虑到具体情况,例如针对大表的分组、排序等字段,都要建立相应索引,一般还可以建立复合索引,对经常插入的表则建立索引时要小心,笔者在处理数据时,曾经在一个ETL流程中,当插入表时,首先删除索引,然后插入完毕,建立索引,并实施聚合操作,聚合完成后,再次插入前还是删除索引,所以索引要用到好的时机,索引的填充因子和聚集、非聚集索引都要考虑。

五、建立缓存机制

当数据量增加时,一般的处理工具都要考虑到缓存问题。缓存大小设置的好差也关系到数据处理的成败,例如,笔者在处理2亿条数据聚合操作时,缓存设置为100000条/Buffer,这对于这个级别的数据量是可行的。

六、加大虚拟内存

如果系统资源有限,内存提示不足,则可以靠增加虚拟内存来解决。笔者在实际项目中曾经遇到针对18亿条的数据进行处理,内存为1GB,1个P4 2.4G的CPU,对这么大的数据量进行聚合操作是有问题的,提示内存不足,那么采用了加大虚拟内存的方法来解决,在6块磁盘分区上分别建立了6个4096M的磁盘分区,用于虚拟内存,这样虚拟的内存则增加为4096*6 + 1024 = 25600 M,解决了数据处理中的内存不足问题。

七、分批处理

海量数据处理难因为数据量大,那么解决海量数据处理难的问题其中一个技巧是减少数据量。可以对海量数据分批处理,然后处理后的数据再进行合并操作,这样逐个击破,有利于小数据量的处理,不至于面对大数据量带来的问题,不过这种方法也要因时因势进行,如果不允许拆分数据,还需要另想办法。不过一般的数据按天、按月、按年等存储的,都可以采用先分后合的方法,对数据进行分开处理。

八、使用临时表和中间表

数据量增加时,处理中要考虑提前汇总。这样做的目的是化整为零,大表变小表,分块处理完成后,再利用一定的规则进行合并,处理过程中的临时表的使用和中间结果的保存都非常重要,如果对于超海量的数据,大表处理不了,只能拆分为多个小表。如果处理过程中需要多步汇总操作,可按汇总步骤一步步来,不要一条语句完成,一口气吃掉一个胖子。

九、优化查询SQL语句

在对海量数据进行查询处理过程中,查询的SQL语句的性能对查询效率的影响是非常大的,编写高效优良的SQL脚本和存储过程是数据库工作人员的职责,也是检验数据库工作人员水平的一个标准,在对SQL语句的编写过程中,例如减少关联,少用或不用游标,设计好高效的数据库表结构等都十分必要。笔者在工作中试着对1亿行的数据使用游标,运行3个小时没有出结果,这是一定要改用程序处理了。

十、使用文本格式进行处理

对一般的数据处理可以使用数据库,如果对复杂的数据处理,必须借助程序,那么在程序操作数据库和程序操作文本之间选择,是一定要选择程序操作文本的,原因为:程序操作文本速度快;对文本进行处理不容易出错;文本的存储不受限制等。例如一般的海量的网络日志都是文本格式或者csv格式(文本格式),对它进行处理牵扯到数据清洗,是要利用程序进行处理的,而不建议导入数据库再做清洗。

十一、定制强大的清洗规则和出错处理机制

海量数据中存在着不一致性,极有可能出现某处的瑕疵。例如,同样的数据中的时间字段,有的可能为非标准的时间,出现的原因可能为应用程序的错误,系统的错误等,这是在进行数据处理时,必须制定强大的数据清洗规则和出错处理机制。

十二、建立视图或者物化视图

视图中的数据来源于基表,对海量数据的处理,可以将数据按一定的规则分散到各个基表中,查询或处理过程中可以基于视图进行,这样分散了磁盘I/O,正如10根绳子吊着一根柱子和一根吊着一根柱子的区别。

十三、避免使用32位机子(极端情况)

目前的计算机很多都是32位的,那么编写的程序对内存的需要便受限制,而很多的海量数据处理是必须大量消耗内存的,这便要求更好性能的机子,其中对位数的限制也十分重要。十四、考虑操作系统问题

海量数据处理过程中,除了对数据库,处理程序等要求比较高以外,对操作系统的要求也放到了重要的位置,一般是必须使用服务器的,而且对系统的安全性和稳定性等要求也比较高。尤其对操作系统自身的缓存机制,临时空间的处理等问题都需要综合考虑。

十五、使用数据仓库和多维数据库存储

数据量加大是一定要考虑OLAP的,传统的报表可能5、6个小时出来结果,而基于Cube 的查询可能只需要几分钟,因此处理海量数据的利器是OLAP多维分析,即建立数据仓库,建立多维数据集,基于多维数据集进行报表展现和数据挖掘等。

十六、使用采样数据,进行数据挖掘

基于海量数据的数据挖掘正在逐步兴起,面对着超海量的数据,一般的挖掘软件或算法往往采用数据抽样的方式进行处理,这样的误差不会很高,大大提高了处理效率和处理的成功率。一般采样时要注意数据的完整性和,防止过大的偏差。笔者曾经对1亿2千万行的表数据进行采样,抽取出400万行,经测试软件测试处理的误差为千分之五,客户可以接受。

还有一些方法,需要在不同的情况和场合下运用,例如使用代理键等操作,这样的好处是加快了聚合时间,因为对数值型的聚合比对字符型的聚合快得多。类似的情况需要针对不同的需求进行处理。

海量数据是发展趋势,对数据分析和挖掘也越来越重要,从海量数据中提取有用信息重要而紧迫,这便要求处理要准确,精度要高,而且处理时间要短,得到有价值信息要快,所以,对海量数据的研究很有前途,也很值得进行广泛深入的研究。

本文来自CSDN博客,转载请标明出处:https://www.360docs.net/doc/3f19015824.html,/DaiZiLiang/archive/2006/12/06/1432193.aspx

政务信息共享数据库建设方案

图1 政务信息共享库总体框架

一、政务信息共享库建设的背景和意义

政务信息共享数据库是指结合政府各类决策支持系统、相关应用系统的接入和政务信息资源共享交换的需求而构建的共享数据库,它是政务信息交换共享平台的重要组成部分,用于实现各类电子政务共享交换数据的有机管理,并为应用提供相应服务。

在经过基础设施建设、政府上网、政务公开、网上行政等发展阶段之后,随着电子政务工程的深化,单一的政府机构业务系统建设已经达到了一定的水平,积累的政务信息资源已经具有相当规模。但与实际需求相比,仍存在较大差距:数据标准规范不统一,信息共享程度较低;各委办局之间互联互通不足,业务协同困难,难以发挥整体优势;缺乏统一的政务信息管理和服务机制。这些问题的症结之一是缺乏统一规划、规范建设的政务信息共享库。

中办发[2002]17号文件的发布,标志着国家信息化以信息资源交换共享为主要建设思路的导向正在逐渐形成。建设政务信息资源共享库,不仅符合电子政务工程整体发展规律,抓住了当前政府最关键的信息化建设需求,为电子政务工程的深化与开展,做出了大胆的尝试,而且对推动政府改革、提升政府工作效率、提升领导的科学决策能力,都有着重要意义。

二、政务信息共享库建设的需求分析

随着电子政务各个业务系统的建立和使用,政府、企业和社会公众不但对基础地理空间信息、人口信息、法人信息和宏观经济信息等公共信息的需要越来越迫切,而且各个业务部门对其他部门专题数据的需求也非常强烈。因此,要在统一的数据标准下建立起信息资源

基础库,建立起对这个基础库的管理、维护、更新和使用的长效管理机制,使数据库能够不断的扩展、完善,保证数据的一致性、鲜活性和准确性,为整个信息资源的规划和建设奠定一个良好的基础。

1、共享库基础功能需求

1)对数据访问下载的支持

共享库系统要为政府用户及各级电子政务业务应用系统提供访问和下载信息资源的支撑服务。政府终端用户和各级电子政务业务应用系统通过用户身份认证和目录系统授权验证,将数据查询条件及查询要求提交到共享库系统,共享库系统分析查询条件及查询要求,对信息资源进行查找、定位、获取、打包返回给服务调用方。

2)数据检查比对

共享库系统要为政府用户及业务应用系统提供数据检查比对支撑服务。政府用户及业务应用系统通过用户身份认证和目录系统授权验证,将需要比对的数据提交到共享库系统,共享库系统将用户提交的数据和共享库中数据进行一致比对。

3)数据同步

为保持共享库数据良好的鲜活性,需要建立委办局到共享库系统之间的数据双向同步更新机制。为确保共享利用的信息资源准确有效,各委办局需要及时将更新的业务信息同步到共享库系统,同时共享库系统还要将得到更新的业务信息及时同步给其他委办局,从而实现数据双向同步互动。

4)数据规则约束检查

共享库数据要满足一致性、完整性、正确性要求。共享库系统需要提供数据规则约束检查手段,对入库数据按照业务逻辑规则进行完整性、一致性、正确性的数据清洗整理,保证共享库数据干净、准确、可靠。

5)目录服务需求

按照信息资源管理体系框架结构,建立信息资源目录标准服务及元数据描述服务。

2、共享库安全需求

从三个方面提出共享库建设的安全需求:

1)用户的安全性

系统提供和交换平台中用户认证层的接口连接,来保证用户的身份安全和访问安全。

2)数据自身的安全性

系统要提供对数据库自身内容的安全备份和恢复功能,保证数据的准确性、可恢复性。

3)应用程序的安全性

通过用户认证系统、信息资源目录系统对共享库系统的数据访问进行安全保护。

3、共享库管理需求

1)共享库的管理

信息资源管理中心进行统一的数据管理和授权使用。共享库逻辑上建立在信息资源管理中心,对共享库进行管理、维护。

2)数据的更新维护

结合共享数据的分布情况、应用需求及数据逻辑集中管理要求,本着“谁拥有数据谁更新”的原则,制定合理的数据更新维护方案。

3)数据的标准化

包括数据内容的标准化、元数据的标准化等方面。

4)数据的扩展

要结合多层电子政务业务应用对共享数据的扩展需求,制定合理的共享库扩展框架。

5)信息资源的安全保密

制定科学合理的信息资源安全保障体系,采取各种有效的措施,加强对信息资源的访问控制、授权管理,从而在源头上保证信息资源的安全。

6)数据展现

通过应用开发,提供对数据内容和数据描述的浏览展现、查询、统计等功能。

三、政务信息共享库总体设计

1、政务信息共享方案选择

通过对不同建设方案的分析比较、取长补短,“逻辑集中适度分布建设”方案兼有“集中建设”方案和“分散建设”方案的优点,又弥补了各自的缺点,是构建政务信息资源共享库的理想建设方案。

具体而言,各共建部门按照统一标准规范,整合本部门业务系统数据,形成共享数据库。根据具体情况,共享数据库一部分部署在各部门,自行维护;另一部分由信息资源管理中心管理运行。共建部门将共享数据库存放在信息资源管理中心,共用中心的网络资源、周边设备和专业化的运行维护人员及服务,可以充分保证共享数据库的运行更加安全、稳定和高效。

从广义上来讲,在信息资源组织建设中,“逻辑集中、适度分布”的建设原则可以体现在以下三个方面:

一是集中建设统一的信息资源目录体系、元数据库、专题应用数据库,形成信息共享的基础;二是构建星型结构的网络应用系统架构,实现共建部门通过访问中心就可透明访问共享信息资源的机制;三是在共享数据库的建设中具体情况具体分析,按照“逻辑集中适度分布建设”方案进行具体的分级部署和实施。

2、政务信息共享库设计

政务信息共享库总体框架如图1所示。信息资源管理中心中的数据库按所服务的业务功能,可以大致分为元数据库、业务规则库、业务信息库、基础信息库、交换信息库、主题数据库、决策支持库和其他数据库。

分布在各委办局的数据包括信息资源库和交换信息库两类。

四、政务信息共享库建设的关键要素

东方通科技公司主持规划设计了北京市政务信息交换共享库、石景山区电子政务试点“医疗行业监管专题数据库”等项目,在项目实施过程中,总结出政务信息共享库建设的关键要素如下:

1、信息资源的采集管理机制

对政务信息采集的监控管理主要从管理手段上进行,规定有些资源必须共享,落实责任到领导人。政务信息资源更新也需要通过管理制度来确定更新流程,建立“零更新上报”制度,确定责任到人,制定相应的考核制度。

2、信息资源的采集技术机制

政务信息采集有多种方式,包括文件填报、邮件、数据交换、公文传输等。对于存在数据交换共享平台的政务系统中主要采用两级数据库同步和文件传输的方式采集数据。主要步骤有:业务申请、审批、原系统调查、接口设计、资源定义、用户定义、服务配置、系统联调、试运行等步骤,对于每一个应用都要分别进行。

3、信息资源的统一存储管理机制

政务信息的合理存储是有效利用的前提。数据安全、备份与恢复机制、历史数据管理规则、失效数据清理机制、存储人员工作制度等构成了一套完整的存储管理机制。

4、信息资源的统一存储技术机制

信息资源对统一存储技术机制涉及到政务信息共享库的逻辑设计、物理设计、命名规则、接口设计等内容。

5、信息资源的统一利用管理机制

信息资源的有效利用是政务信息共享库建设的根本目的。合理的信息资源的统一利用管理机制能够保障信息资源安全、充分、有效利用。

6、信息资源的统一利用技术机制

这涉及信息资源的展示、访问权限的控制和对外服务的提供方式等内容。

政务信息共享库建设,最终要形成信息资源的统一采集管理、统一存储管理、统一利用管理和基于共享信息资源的应用系统管理,形成相应的技术和管理规范,保障政务信息资源的有效共享。

如何处理数据库中海量数据,以及处理数据库海量数据的经验和技巧

如何处理数据库中海量数据,以及处理数据库海量数据的经验和技巧 疯狂代码 https://www.360docs.net/doc/3f19015824.html,/ ?:http:/https://www.360docs.net/doc/3f19015824.html,/DataBase/Article11068.html 海量数据是发展趋势,对数据分析和挖掘也越来越重要,从海量数据中提取有用信息重要而紧迫,这便要求处理要准确,精度要高,而且处理时间要短,得到有价值信息要快,所以,对海量数据的研究很有前途,也很值得进行广泛深入的研究。 基于海量数据的数据挖掘正在逐步兴起,面对着超海量的数据,一般的挖掘软件或算法往往采用数据抽样的方式进行处理,这样的误差不会很高,大大提 高了处理效率和处理的成功率。在实际的工作环境下,许多人会遇到海量数据这个复杂而艰巨的问题,它的主要难点有以下几个方面:一、数据量过大,数据中什么情况都可能存在。 ;如果说有10条数据,那么大不了每条去逐一检查,人为处理,如果有上百条数据,也可以考虑,如果数据上到千万级别,甚至过亿,那不是手解决的了,必须通过工具或者程序进行处理,尤其海量的数据中,什么情况都可能存在,例如,数据中某处格式出了问题,尤其在程序处理时,前面还能正常处理,突然到了某个地方问题出现了,程序终止了。二、软硬件要求高,系统资源占用过高 对海量的数据进行处理,除了好的方法,最重要的就是合理使用工具,合理分配系统资源。一般情况,如果处理的数据过TB级,小型机是要考虑的,普通的机子如果有好的方法可以考虑,不过也必须加大CPU和内存,就象面对着千军万马,光有勇气没有一兵一卒是很难取胜的。三、要求很高的处理方法和技巧。 这也是本文的写作目的所在,好的处理方法是一位工程师长期工作经验的积累,也是个人的经验的总结。没有通用的处理方法,但有通用的原理和规则。下面我们来详细介绍一下处理海量数据的经验和技巧:一、选用优秀的数据库工具 现在的数据库工具厂家比较多,对海量数据的处理对所使用的数据库工具要求比较高,一般使用 Oracle或者DB2,微软公 司最近发布的SQL Server 2005性能也不错。另外在BI领域:数据库,数据仓库,多维数据库,数据挖掘,傲博知识库等相关工具也要进行选择,象好的ETL工具和好的OLAP工具都十分必要, 例如Informatic,Eassbase等。笔者在实际数据分析项目中,对每天6000万条的日志数据进行处理,使用SQL Server 2000需要花费6小时,而使用SQL Server 2005则只需要花费3小时。二、编写优良的程序代码 处理数据离不开优秀的程序代码,尤其在进行复杂数据处理时,必须使用程序。好的程序代码对数据的处理至关重要,这不仅仅是数据处理准确度的问题,更是数据处理效率的问题。良好的程序代码应该包含好的算法,包含好的处理流程,包含好的效率,包含好的异常处理机制等。三、对海量数据进行分区操作 对海量数据进行分区操作十分必要,例如针对按年份存取的数据,我们可以按年进行分区,不同的数据库有不同的分区方式 ,不过处理机制大体相同。例 如SQL Server的数据库分区是将不同的数据存于不同的文件组下,而不同的文件组存于不同的磁盘分区下,这样将数据分散开,减小磁盘I/O,减小了系统负荷, 而且还可以将日志,索引等放于不同的分区下。四、建立广泛的索引 对海量的数据处理,对大表建立索引是必行的,建立索引要考虑到具体情况,例如针对大表的分组、排序等字段,都要建立相应索引,一般还可以建立复 合索引,对经常插入的表则建立索引时要小心,笔者在处理数据时,曾经在一个ETL流程中,当插入表时,首先删除索引,然后插入完毕,建立索引,并实施聚合 操作,聚合完成后,再次插入前还是删除索引,所以索引要用到好的时机,索引的填充因子和聚集、非聚集索引都要考虑。五、建立缓存机制 当数据量增加时,一般的处理工具都要考虑到缓存问题。缓存大小设置的好差也关系到数据处理的成败,例如,笔者在处理2亿条数据聚合操作时,缓存设置为100000条/Buffer,这对于这个级别的数据量是可行的。六、加大虚拟内存 如果系统资源有 限,内存提示不足,则可以靠增加虚拟内存来解决。笔者在实际项目中曾经遇到针对18亿条的数据进行处理,内存为

海量数据处理面试题

1. 给定a、b两个文件,各存放50亿个url,每个url各占64字节,内存限制是4G,让你找出a、b文件共同的url? 方案1:可以估计每个文件安的大小为5G×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,每个文件的每一行存放的都是用户的query,每个文件的query都可能重复。要求你按照query的频度排序。 方案1: s 顺序读取10个文件,按照hash(query)%10的结果将query写入到另外10个文件(记为 )中。这样新生成的文件每个的大小大约也1G(假设hash函数是随机的)。

海量数据处理笔试面试题4

海量数据处理专题(一)——开篇 2010-10-08 13:03 转载自08到北京 最终编辑08到北京 大数据量的问题是很多面试笔试中经常出现的问题,比如baidu google 腾讯这样的一些涉及到海量数据的公司经常会问到。 下面的方法是我对海量数据的处理方法进行了一个一般性的总结,当然这些方法可能并不能完全覆盖所有的问题,但是这样的一些方法也基本可以处理绝大多数遇到的问题。下面的一些问题基本直接来源于公司的面试笔试题目,方法不一定最优,如果你有更好的处理方法,欢迎与我讨论。 本贴从解决这类问题的方法入手,开辟一系列专题来解决海量数据问题。拟包含以下几个方面。 1.Bloom Filter 2.Hash 3.】 4.Bit-Map 5.堆(Heap) 6.双层桶划分 7.数据库索引 8.倒排索引(Inverted Index) 9.外排序 10.Trie树 11.MapReduce 海量数据处理专题(二)——Bloom Filter 2010-10-08 13:04 【 转载自08到北京 最终编辑08到北京 【什么是Bloom Filter】 Bloom Filter是一种空间效率很高的随机数据结构,它利用位数组很简洁地表示一个集合,并能判断一个元素是否属于这个集合。Bloom Filter的这种高效是有一定代价的:在判断一个元素是否属于某个集合时,有可能会把不属于这个集合的元素误认为属于这个集合(false positive)。因此,Bloom Filter不适合那些“零错误”的应用场合。而在能容忍低错误率的应用场合下,Bloom Filter通过极少的错误换取了存储空间的极大节省。这里有一篇关于Bloom Filter的详细介绍,不太懂的博友可以看看。 【适用范围】

海量数据处理小结

海量的数据处理问题,对其进行处理是一项艰巨而复杂的任务。原因有以下几个方面: 一、数据量过大,数据中什么情况都可能存在。如果说有10条数据,那么大不了每条去逐一检查,人为处理,如果有上百条数据,也可以考虑,如果数据上到千万级别,甚至过亿,那不是手工能解决的了,必须通过工具或者程序进行处理,尤其海量的数据中,什么情况都可能存在,例如,数据中某处格式出了问题,尤其在程序处理时,前面还能正常处理,突然到了某个地方问题出现了,程序终止了。 二、软硬件要求高,系统资源占用率高。对海量的数据进行处理,除了好的方法,最重要的就是合理使用工具,合理分配系统资源。一般情况,如果处理的数据过TB级,小型机是要考虑的,普通的机子如果有好的方法可以考虑,不过也必须加大CPU和内存,就象面对着千军万马,光有勇气没有一兵一卒是很难取胜的。 三、要求很高的处理方法和技巧。这也是本文的写作目的所在,好的处理方法是一位工程师长期工作经验的积累,也是个人的经验的总结。没有通用的处理方法,但有通用的原理和规则。那么处理海量数据有哪些经验和技巧呢,我把我所知道的罗列一下,以供大家参考: 一、选用优秀的数据库工具现在的数据库工具厂家比较多,对海量数据的处理对所使用的数据库工具要求比较高,一般使用Oracle或者DB2,微软公司最近发布的SQL Server 2005性能也不错。另外在BI领域:数据库,数据仓库,多维数据库,数据挖掘等相关工具也要进行选择,象好的ETL工具和好的OLAP工具都十分必要,例如Informatic,Eassbase等。笔者在实际数据分析项目中,对每天6000万条的日志数据进行处理,使用SQL Server 2000需要花费6小时,而使用SQL Server 2005则只需要花费3小时。 二、编写优良的程序代码处理数据离不开优秀的程序代码,尤其在进行复杂数据处理时,必须使用程序。好的程序代码对数据的处理至关重要,这不仅仅是数据处理准确度的问题,更是数据处理效率的问题。良好的程序代码应该包含好的算法,包含好的处理流程,包含好的效率,包含好的异常处理机制等。 三、对海量数据进行分区操作对海量数据进行分区操作十分必要,例如针对按年份存取的数据,我们可以按年进行分区,不同的数据库有不同的分区方式,不过处理机制大体相同。例如SQL Server的数据库分区是将不同的数据存于不同的文件组下,而不同的文件组存于不同的磁盘分区下,这样将数据分散开,减小磁盘I/O,减小了系统负荷,而且还可以将日志,索引等放于不同的分区下。 四、建立广泛的索引对海量的数据处理,对大表建立索引是必行的,建立索引要考虑到具体情况,例如针对大表的分组、排序等字段,都要建立相应索引,一般还可以建立复合索引,对经常插入的表则建立索引时要小心,笔者在处理数据时,曾经在一个ETL流程中,当插入表时,首先删除索引,然后插入完毕,建立索引,并实施聚合操作,聚合完成后,再次插入前还是删除索引,所以索引要用到好的时机,索引的填充因子和聚集、非聚集索引都要考虑。 五、建立缓存机制当数据量增加时,一般的处理工具都要考虑到缓存问题。缓存大小设置的好差也关系到数据处理的成败,例如,笔者在处理2亿条数据聚合操作时,缓存设置为100000条/Buffer,这对于这个级别的数据量是可行的。 六、加大虚拟内存如果系统资源有限,内存提示不足,则可以靠增加虚拟内存来解决。笔者在实际项目中曾经遇到针对18亿条的数据进行处理,内存为1GB,1个P4 2.4G的CPU,对这么大的数据量进行聚合操作是有问题的,提示内存不足,那么采用了加大虚拟内存的方法来解决,在6块磁盘分区上分别建立了6个4096M的磁盘分区,用于虚拟内存,这样虚拟的内存则增加为4096*6 + 1024 = 25600 M,解决了数据处理中的内存不足问题。 七、分批处理海量数据处理难因为数据量大,那么解决海量数据处理难的问题其中一个技巧是减少数据量。可以对海量数据分批处理,然后处理后的数据再进行合并操作,这样逐个击破,有利于小数据量的处理,不至于面对大数据量带来的问题,不过这种方法也要因时因势进行,如果不允许拆分数据,还需要另想办法。不过一般的数据按天、按月、按年等存储的,都可以采用先分后合的方法,对数据进行分开处理。八、使用临时表和中间表数据量增加时,处理中要考虑提前汇总。这样做的目的是化整为零,大表变小表,分块处理完成后,再利用一定的规则进行合并,处理过程中的临时表的使用和中间结果的保存都非常重要,如果对于超海量的数据,大表处理不了,只能拆分为多个小表。如果处理过程中需要多步汇总操作,可按

(重点学习)海量数据处理方法总结

海量数据处理方法总结 大数据量的问题是很多面试笔试中经常出现的问题,比如baidu,google,腾讯这样的一些涉及到海量数据的公司经常会问到。 下面的方法是我对海量数据的处理方法进行了一个一般性的总结,当然这些方法可能并不能完全覆盖所有的问题,但是这样的一些方法也基本可以处理绝大多数遇到的问题。下面的一些问题基本直接来源于公司的面试笔试题目,方法不一定最优,如果你有更好的处理方法,欢迎与我讨论。 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,则此时m应大概是n的13倍。这样k大概是8个。 注意这里m与n的单位不同,m是bit为单位,而n则是以元素个数为单位(准确的说是不同元素的个数)。通常单个元素的长度都是有很多bit的。所以使用bloom filter内存上通常都是节省的。 扩展: Bloom filter将集合中的元素映射到位数组中,用k(k为哈希函数个数)个映射位是否全1表示元素在不在这个集合中。Counting bloom filter(CBF)将位数组中的每一位扩展为

数据分析师常见的7道笔试题目及答案

数据分析师常见的7道笔试题目及答案 导读:探索性数据分析侧重于在数据之中发现新的特征,而验证性数据分析则侧 重于已有假设的证实或证伪。以下是由小编J.L为您整理推荐的实用的应聘笔试题目和经验,欢迎参考阅读。 1、海量日志数据,提取出某日访问百度次数最多的那个IP。 首先是这一天,并且是访问百度的日志中的IP取出来,逐个写入到一个大文件中。注意到IP是32位的,最多有个2^32个IP。同样可以采用映射的方法,比如模1000,把 整个大文件映射为1000个小文件,再找出每个小文中出现频率最大的IP(可以采用 hash_map进行频率统计,然后再找出频率最大的几个)及相应的频率。然后再在这1000 个最大的IP中,找出那个频率最大的IP,即为所求。 或者如下阐述: 算法思想:分而治之+Hash 1.IP地址最多有2^32=4G种取值情况,所以不能完全加载到内存中处理; 2.可以考虑采用“分而治之”的思想,按照IP地址的Hash(IP)24值,把海量IP日 志分别存储到1024个小文件中。这样,每个小文件最多包含4MB个IP地址; 3.对于每一个小文件,可以构建一个IP为key,出现次数为value的Hash map,同时记录当前出现次数最多的那个IP地址; 4.可以得到1024个小文件中的出现次数最多的IP,再依据常规的排序算法得到总体上出现次数最多的IP; 2、搜索引擎会通过日志文件把用户每次检索使用的所有检索串都记录下来,每个查询串的长度为1-255字节。 假设目前有一千万个记录(这些查询串的重复度比较高,虽然总数是1千万,但如果除去重复后,不超过3百万个。一个查询串的重复度越高,说明查询它的用户越多,也 就是越热门。),请你统计最热门的10个查询串,要求使用的内存不能超过1G。 典型的Top K算法,还是在这篇文章里头有所阐述, 文中,给出的最终算法是: 第一步、先对这批海量数据预处理,在O(N)的时间内用Hash表完成统计(之前写成了排序,特此订正。July、2011.04.27); 第二步、借助堆这个数据结构,找出Top K,时间复杂度为N…logK。 即,借助堆结构,我们可以在log量级的时间内查找和调整/移动。因此,维护一 个K(该题目中是10)大小的小根堆,然后遍历300万的Query,分别和根元素进行对比所以,我们最终的时间复杂度是:O(N) + N?*O(logK),(N为1000万,N?为300万)。ok,更多,详情,请参考原文。 或者:采用trie树,关键字域存该查询串出现的次数,没有出现为0。最后用10 个元素的最小推来对出现频率进行排序。 3、有一个1G大小的一个文件,里面每一行是一个词,词的大小不超过16字节,内存限制大小是1M。返回频数最高的100个词。 方案:顺序读文件中,对于每个词x,取hash(x)P00,然后按照该值存到5000 个小文件(记为x0,x1,…x4999)中。这样每个文件大概是200k左右。 如果其中的有的文件超过了1M大小,还可以按照类似的方法继续往下分,直到 分解得到的小文件的大小都不超过1M。 对每个小文件,统计每个文件中出现的词以及相应的频率(可以采用trie树 /hash_map等),并取出出现频率最大的100个词(可以用含100 个结点的最小堆),并把

常用 大数据量、海量数据处理 方法 算法总结

大数据量的问题是很多面试笔试中经常出现的问题,比如baidu google 腾讯这样的一些涉及到海量数据的公司经常会问到。 下面的方法是我对海量数据的处理方法进行了一个一般性的总结,当然这些方法可能并不能完全覆盖所有的问题,但是这样的一些方法也基本可以处理绝大多数遇到的问题。下面的一些问题基本直接来源于公司的面试笔试题目,方法不一定最优,如果你有更好的处理方法,欢迎与我讨论。 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,则此时m应大概是n的13倍。这样k大概是8个。 注意这里m与n的单位不同,m是bit为单位,而n则是以元素个数为单位(准确的说是不同元素的个数)。通常单个元素的长度都是有很多bit的。所以使用bloom filter内存上通常都是节省的。 扩展: Bloom filter将集合中的元素映射到位数组中,用k(k为哈希函数个数)个映射位是否全1表示元素在不在这个集合中。Counting bloom filter(CBF)将位数组中的每一位扩展为一个counter,从而支持了元素的删除操作。Spectral Bloom Filter(SBF)将其与集合元素的出现次数关联。SBF采用counter中的最小值来近似表示元素的出现频率。 问题实例:给你A,B两个文件,各存放50亿条URL,每条URL占用64字节,内存限制是4G,让你找出A,B文件共同的URL。如果是三个乃至n个文件呢? 根据这个问题我们来计算下内存的占用,4G=2^32大概是40亿*8大概是340亿,n=50亿,如果按出错率0.01算需要的大概是650亿个bit。现在可用的是340亿,相差并不多,这样可能会使出错率上升些。另外如果这些urlip是一一对应的,就可以转换成ip,则大大简单了。

【精品】海量数据处理分析

海量数据处理分析 北京迈思奇科技有限公司戴子良 笔者在实际工作中,有幸接触到海量的数据处理问题,对其进行处理是一项艰巨而复杂的任务。原因有以下几个方面: 一、数据量过大,数据中什么情况都可能存在。如果说有10条数据,那么大不了每条去逐一检查,人为处理,如果有上百条数据,也可以考虑,如果数据上到千万级别,甚至过亿,那不是手工能解决的了,必须通过工具或者程序进行处理,尤其海量的数据中,什么情况都可能存在,例如,数据中某处格式出了问题,尤其在程序处理时,前面还能正常处理,突然到了某个地方问题出现了,程序终止了。 二、软硬件要求高,系统资源占用率高。对海量的数据进行处理,除了好的方法,最重要的就是合理使用工具,合理分配系统资源。一般情况,如果处理的数据过TB级,小型机是要考虑的,普通的机子如果有好的方法可以考虑,不过也必须加大CPU和内存,就象面对着千军万马,光有勇气没有一兵一卒是很难取胜的。 三、要求很高的处理方法和技巧。这也是本文的写作目的所在,好的处理方法是一位工程师长期工作经验的积累,也是个人的经验的总结。没有通用的处理方法,但有通用的原理和规则。 那么处理海量数据有哪些经验和技巧呢,我把我所知道的罗列一下,以供大家参考: 一、选用优秀的数据库工具 现在的数据库工具厂家比较多,对海量数据的处理对所使用的数据库工具要求比较高,一般使用Oracle或者DB2,微软公司最近发布的SQL Server 2005性能也不错。另外在BI领域:数据库,数据仓库,多维数据库,数据挖掘等相关工具也要进行选择,象好的ETL工具和好的OLAP工具都十分必要,例如Informatic,Eassbase等。笔者在实际数据分析项目中,对每天6000万条的日志数据进行处理,使用SQL Server 2000需要花费6小时,而使用SQL Server 2005则只需要花费3小时。 二、编写优良的程序代码 处理数据离不开优秀的程序代码,尤其在进行复杂数据处理时,必须使用程序。好的程序代码对数据的处理至关重要,这不仅仅是数据处理准确度的问题,更是数据处理效率的问题。良好的程序代码应该包含好的算法,包含好的处理流程,包含好的效率,包含好的异常处理机制等。 三、对海量数据进行分区操作 对海量数据进行分区操作十分必要,例如针对按年份存取的数据,我们可以按年进行分区,不同的数据库有不同的分区方式,不过处理机制大体相同。例如SQL Server的数据库分区是将不同的数据存于不同的文件组下,而不同的文件组存于不同的磁盘分区下,这样将数据分散开,减小磁盘I/O,减小了系统负荷,而且还可以将日志,索引等放于不同的分区下。 四、建立广泛的索引 对海量的数据处理,对大表建立索引是必行的,建立索引要考虑到具体情况,例如针对大表的分组、排序等字段,都要建立相应索引,一般还可以建立复合索引,对经常插入的表则建立索引时要小心,笔者在处理数据时,曾经在一个ETL流程中,当插入表时,首先删除索引,然后插入完毕,建立索引,并实施聚合操作,聚合完成后,再次插入前还是删除索引,所以索引要用到好的时机,索引的填充因子和聚集、非聚集索引都要考虑。

基于一种海量数据处理分析系统设计文档

中科基于一种海量数据处理分析 系统的设计文档 一、海量数据处理的背景分析 在当前这个信息量飞速增长的时代,业的成功已经越来越多地与其海量数据处理能力相关联。高效、迅速地从海量数据中挖掘出潜在价值并转化为决策依据的能力,将成为企业的核心竞争力。数据的重要性毋庸置疑,但随着数据的产生速度越来越快,数据量越来越大,数据处理技术的挑战自然也越来越大。如何从海量数据中挖掘出价值所在,分析出深层含义,进而转化为可操作的信息,已经成为各互联网企业不得不研究的课题。数据量的增长,以及分析需求的越来越复杂,将会对互联网公司的数据处理能力提出越来越高的要求、越来越大的挑战。但每一个场景都有其特点与功能,充分分析其数据特性,将合适的软件用在合适的场景下,才能更好地解决实际问题。 二、海量数据处理分析的特点 (一)、数据量大,情况多变 现在的数据量比以前任何时期更多,生成的速度更快,以前如果说有10条数据,繁琐的操作时每条去逐一检查,人为处理,如果有上百条数据,也可以考虑,如果数据上到千万级别,甚至过亿,那不是手工能解决的了,必须通过工具或者程序进行处理,尤其海量的数据中,情况多变,手工操作是完不成任务的。例如,数据中某处格式出了问题,尤其在程序处理时,前面还能正常处理,突然到了某个地方问题出现了,程序将会终止。海量数据处理系统的诞生是输入层每个神经元的输入是同一个向量的一个分量,产生的输出作

为隐藏层的输入,输出层每一个神经元都会产生一个标量结果,所以整个输出层所有神经元的输出构成一个向量,向量的维数等于输出层神经元的数目在人工神经网络模型中,各个神经元通过获取输入和反馈,相对独立地进行训练和参数计算。其拓扑结构的重要特点便是每一层内部的神经元之间相互独立,各个层次间的神经元相互依赖。 由于各个层次内部神经元相互独立,使得各个层次内部的神经元的训练可以并行化。但由于不同层之间的神经元具有相互依赖关系,因此各个层次之间仍然是串行处理的。可以将划分出的每一层内部的不同神经元通过map操作分布到不同的计算机上。各个神经元在不同的计算终端上进行训练,在统一的调度和精度控制下进行多个层次的神经元的训练,这样神经网络算法的训练就可以实现并行化。训练结束后,同样可以通过每层内节点的并行化处理快速地得到输出结果。在神经网络算法中,每层内的节点都可以进行并行化处理,并行化程度非常高。 (二)、软硬件要求高,系统资源占用率高 各种应用对存储系统提出了更多的需求,数据访问需要更高的带宽,不仅要保证数据的高可用性,还要保证服务的高可用性;可扩展性:应用在不断变化,系统规模也在不断变化,这就要求系统提供很好的扩展性,并在容量、性能、管理等方面都能适应应用的变化;对海量的数据进行处理,除了好的方法,最重要的就是合理使用工具,合理分配系统资源。一般情况,如果处理的数据过TB级,小型机是要考虑的,普通的机子如果有好的方法可以考虑,不过也必须加大CPU和内存,对电脑的内存、显卡、硬盘及网络都要求相对较高!其中对网络要求高的原因是因为其引入目前最前沿的“云端计算”好多东西都要从网络上调用;对硬盘要求是最高的,用SATA6.0的固态硬盘,对整机性能限制比较大的就是高速系统总线对低速硬盘传输,32位的系统,最大只能认到3.5G内存,就是说,不论你装几根内存条,装多大容量的内存条,你装8G的,它也只能用到3.5G,64位的系统就可以突破了这个限制。如果你的电脑配置不是特别高的话,XP是比较好的选择。32位的XP是最低要求。基于23G互操作测试生成23G互操作测试报告测试起始点时间、测试终止点时间、 3G网络驻留时间(秒)、2G网络驻留时间(秒)、3G覆盖总采样点、3G覆盖总采样点不同区间数量统计、3G覆盖总采样点不同门限范围内数量统计、2G覆盖总采样点、2G覆盖总采样点不同区间数量统计、2G覆盖总采样点不同门限范围内数量统计、3G到2G重选成功次数、2G到3G重选成功次数、3G到2G切换尝试次数、3G到2G切换成功次数、切换掉话次数和其它掉话次数。

2016年数据分析面试常见问题

1、海量日志数据,提取出某日访问百度次数最多的那个IP。 首先是这一天,并且是访问百度的日志中的IP取出来,逐个写入到一个大文件中。注意到IP是32位的,最多有个2^32个IP。同样可以采用映射的方法,比如模1000,把整个大文件映射为1000个小文件,再找出每个小文中出现频率最大的IP(可以采用hash_map进行频率统计,然后再找出频率最大的几个)及相应的频率。然后再在这1000个最大的IP中,找出那个频率最大的IP,即为所求。 或者如下阐述: 算法思想:分而治之+Hash 1.IP地址最多有2^32=4G种取值情况,所以不能完全加载到内存中处理; 2.可以考虑采用“分而治之”的思想,按照IP地址的Hash(IP)24值,把海量IP日志分别存储到1024个小文件中。这样,每个小文件最多包含4MB个IP地址; 3.对于每一个小文件,可以构建一个IP为key,出现次数为value的Hash map,同时记录当前出现次数最多的那个IP地址; 4.可以得到1024个小文件中的出现次数最多的IP,再依据常规的排序算法得到总体上出现次数最多的IP; 2、搜索引擎会通过日志文件把用户每次检索使用的所有检索串都记录下来,每个查询串的长度为1-255字节。 假设目前有一千万个记录(这些查询串的重复度比较高,虽然总数是1千万,但如果除去重复后,不超过3百万个。一个查询串的重复度越高,说明查询它的用户越多,也就是越热门。),请你统计最热门的10个查询串,要求使用的内存不能超过1G。 典型的Top K算法,还是在这篇文章里头有所阐述, 文中,给出的最终算法是:

第一步、先对这批海量数据预处理,在O(N)的时间内用Hash表完成统计(之前写成了排序,特此订正。July、2011.04.27); 第二步、借助堆这个数据结构,找出Top K,时间复杂度为N‘logK。 即,借助堆结构,我们可以在log量级的时间内查找和调整/移动。因此,维护一个K(该题目中是10)大小的小根堆,然后遍历300万的Query,分别和根元素进行对比所以,我们最终的时间复杂度是:O(N)+ N’*O(logK),(N为1000万,N’为300万)。ok,更多,详情,请参考原文。 或者:采用trie树,关键字域存该查询串出现的次数,没有出现为0。最后用10个元素的最小推来对出现频率进行排序。 3、有一个1G大小的一个文件,里面每一行是一个词,词的大小不超过16字节,内存限制大小是1M。返回频数最高的100个词。 方案:顺序读文件中,对于每个词x,取hash(x)P00,然后按照该值存到5000个小文件(记为x0,x1,…x4999)中。这样每个文件大概是200k左右。 如果其中的有的文件超过了1M大小,还可以按照类似的方法继续往下分,直到分解得到的小文件的大小都不超过1M。 对每个小文件,统计每个文件中出现的词以及相应的频率(可以采用trie树/hash_map 等),并取出出现频率最大的100个词(可以用含100个结点的最小堆),并把100个词及相应的频率存入文件,这样又得到了5000个文件。下一步就是把这5000个文件进行归并(类似与归并排序)的过程了。 4、有10个文件,每个文件1G,每个文件的每一行存放的都是用户的query,每个

大数据量,海量数据 处理方法总结

大数据量,海量数据处理方法总结 从目前大公司用的比较多的数据处理系统角度,你可以去看看关于Hadoop,Hbase,Hive的书,纯粹讲海量数据处理的没见过, https://www.360docs.net/doc/3f19015824.html,/~ullman/mmds.html,这个是关于海量数据挖掘的 大数据量的问题是很多面试笔试中经常出现的问题,比如baidu google 腾讯这样的一些涉及到海量数据的公司经常会问到。 下面的方法是我对海量数据的处理方法进行了一个一般性的总结,当然这些方法可能并不能完全覆盖所有的问题,但是这样的一些方法也基本可以处理绝大多数遇到的问题。下面的一些问题基本直接来源于公司的面试笔试题目,方法不一定最优,如果你有更好的处理方法,欢迎与我讨论。 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,则此时m应大概是n的13倍。这样k大概是8个。 注意这里m与n的单位不同,m是bit为单位,而n则是以元素个数为单位(准确的说是不同元素的个数)。通常单个元素的长度都是有很多bit的。所以使用bloom filter内存上通常都是节省的。 扩展: Bloom filter将集合中的元素映射到位数组中,用k(k为哈希函数个数)个映射位是否全1表示元素在不在这个集合中。Counting bloom filter(CBF)将位数组中的每一位扩展为一个counter,从而支持了元素的删除操作。Spectral Bloom Filter(SBF)将其与集

基于海量数据的数据分析方案设计

基于海量数据的数据分析方案设计 data analysis program design based on mass data 摘要:随着互联网,移动互联网和物联网的发展,谁也无法否认,我们来到了一个海量数据的时代。随着数据积累的越来越多,现在许多行业大多面临基于海量数据的分析问题,该文从基于海量数据挖掘的分析方法出发,利用河南省2005到2009年交通事故的数据,设计了一个数据分析方案。 关键词:海量数据,数据挖掘,回归模型,方案 Abstract: with the development of Internet, mobile Internet and development of Internet of things, nobody can deny that we come to a massive data era. As data accumulate more and more, many industries are facing problems based on large amounts of data analysis . This paper ibased on the analysis of mass data mining method of Henan province from 2005 to 2009, using the data of traffic accidents, designes a data analysis program. Key words: mass data, data mining, regression model, scheme 一、引言 随着信息技术的发展,人们积累的数据越来越多。事实上,数据本身是没有意义的,只有用以进行分析处理才真正起到作用。因此,可以说激增的数据背后更重要的是隐含的信息,人们希望能够对这些数据进行更高层次的分析,以便更好地利用这些数据。 海量数据是发展趋势,对数据分析和挖掘也越来越重要,从海量数据中提取有用信息重要而紧迫,这便要求处理要准确,精度要高,而且处理时间要短,得到有价值信息要快,所以,对海量数据的研究很有前途,也很值得进行广泛深入的研究。 在实际的工作环境下,许多人会遇到海量数据这个复杂而艰巨的问题,它的主要难点有以下几个方面:数据量过大,数据中什么情况都可能存在;软硬件要求高,系统资源占用过高;要求很高的处理方法和技巧。 基于海量数据的数据挖掘正在逐步兴起,面对着超海量的数据,一般的挖掘软件或算法往往采用数据抽样的方式进行处理,这样的误差不会很高,大大提高了处

十七道海量数据处理面试题与Bit-map详解

十七道海量数据处理面试题与Bit-map详解 第一部分、十七道海量数据处理面试题 1. 给定a、b两个文件,各存放50亿个url,每个url各占64字节,内存限制是4G,让你找出a、b文 件共同的url? 方案1:可以估计每个文件安的大小为50G×64=320G,远远大于内存限制的4G。所以不可能将其完全加载到内存中处理。考虑采取分而治之的方法。 1. 遍历文件a,对每个url求取,然后根据所取得的值将url分别存储到1000个 小文件(记为,这里漏写个了a1)中。这样每个小文件的大约为300M。 2. 遍历文件b,采取和a相同的方式将url分别存储到1000小文件中(记为)。这样 处理后,所有可能相同的url都在对应的小文件()中,不对应的小文件不可能有相同的url。然后我们只要求出1000对小文件中相同的url即可。 3. 求每对小文件中相同的url时,可以把其中一个小文件的url存储到hash_set中。然后遍历另一个小文件的每个url,看其是否在刚才构建的hash_set中,如果是,那么就是共同的url,存到文件里面就可以了。 方案2:如果允许有一定的错误率,可以使用Bloom filter,4G内存大概可以表示340亿bit。将其中一个文件中的url使用Bloom filter映射为这340亿bit,然后挨个读取另外一个文件的url,检查是否与Bloom filter,如果是,那么该url应该是共同的url(注意会有一定的错误率)。 读者反馈@crowgns: 1. hash后要判断每个文件大小,如果hash分的不均衡有文件较大,还应继续hash分文件,换个hash 算法第二次再分较大的文件,一直分到没有较大的文件为止。这样文件标号可以用A1-2表示(第一次hash 编号为1,文件较大所以参加第二次hash,编号为2) 2. 由于1存在,第一次hash如果有大文件,不能用直接set的方法。建议对每个文件都先用字符串 自然顺序排序,然后具有相同hash编号的(如都是1-3,而不能a编号是1,b编号是1-1和1-2),可 以直接从头到尾比较一遍。对于层级不一致的,如a1,b有1-1,1-2-1,1-2-2,层级浅的要和层级深的每个文件都比较一次,才能确认每个相同的uri。 2. 有10个文件,每个文件1G,每个文件的每一行存放的都是用户的query,每个文件的query都可能 重复。要求你按照query的频度排序。 方案1: 1.顺序读取10个文件,按照hash(query)%10的结果将query写入到另外10个文件(记为)中。这样新生成的文件每个的大小大约也1G(假设hash函数是随机的)。 2.找一台内存在2G左右的机器,依次对用hash_map(query, query_count)来统计每个query出现的次数。利用快速/堆/归并排序按照出现次数进行排序。将排序好的query和对应的query_cout 输出到文件中。这样得到了10个排好序的文件(,此处有误,更正为b0,b1,b2,b9)。 3.对这10个文件进行归并排序(内排序与外排序相结合)。 方案2:

运营必备的 15 个数据分析方法

提起数据分析,大家往往会联想到一些密密麻麻的数字表格,或是高级的数据建模手法,再或是华丽的数据报表。其实,“分析”本身是每个人都具备的能力;比如根据股票的走势决定购买还是抛出,依照每日的时间和以往经验选择行车路线;购买机票、预订酒店时,比对多家的价格后做出最终选择。 这些小型决策,其实都是依照我们脑海中的数据点作出判断,这就是简单分析的过程。对于业务决策者而言,则需要掌握一套系统的、科学的、符合商业规律的数据分析知识。 1.数据分析的战略思维 无论是产品、市场、运营还是管理者,你必须反思:数据本质的价值,究竟在哪里?从这些数据中,你和你的团队都可以学习到什么? 数据分析的目标 对于企业来讲,数据分析的可以辅助企业优化流程,降低成本,提高营业额,往往我们把这类数据分析定义为商业数据分析。商业数据分析的目标是利用大数据为所有职场人员做出迅捷、高质、高效的决策,提供可规模化的解决方案。商业数据分析的本质在于创造商业价值,驱动企业业务增长。 数据分析的作用 我们常常讲的企业增长模式中,往往以某个业务平台为核心。这其中,数据和数据分析,是不可或缺的环节。 通过企业或者平台为目标用户群提供产品或服务,而用户在使用产品或服务过程中产生的交互、交易,都可以作为数据采集下来。根据这些数据洞察,通过分析的手段反推客户的需求,创造更多符合需求的增值产品和服务,重新投入用户的使用,从而形成形成一个完整的业务闭环。这样的完整业务逻辑,可以真正意义上驱动业务的增长。 数据分析进化论 我们常常以商业回报比来定位数据分析的不同阶段,因此我们将其分为四个阶段。 阶段 1:观察数据当前发生了什么? 首先,基本的数据展示,可以告诉我们发生了什么。例如,公司上周投放了新的搜索引擎 A 的广告,想要

大数据开发笔试

1、hdfs原理,以及各个模块的职责 答:Hadoop Distributed File System即:Hadoop分布式文件系统,就是把数据划分成不同的Block 分别存储在不同节点的设备上。它分为两个部分:NameNode和DateNode,NameNode相当于一个领导,将文件系统的Meta-data存储在内存中,这些信息主要包括了文件信息、每一个文件对应的文件块的信息和每一个文件块在DataNode的信息等。它管理集群内的DataNode,当客户发送请求过来后,NameNode 会根据Meta-data指定存储到哪些DataNode上,而其本身并不存储真实的数据。 2、mr的工作原理 答:当客户提交作业后,MapReduce库先把任务splits不同的块,然后根据“移动计算比移动数据更明智”的思想,把任务分发到各个DataNode上。在不同的DataNode上分别执行Map操作,产生键值对,然后通过shuffle重新洗牌,把键值相同的键值对传给同一个reduce,把键值不同的键值对传给不同的reduce进行处理,最后输出结果。这些按照时间顺序包括:输入分片(input split)、map阶段、combiner 阶段、shuffle阶段和reduce阶段。(5个阶段) 3、map方法是如何调用reduce方法的 答:Shuffle过程是MapReduce的核心,也被称为奇迹发生的地方,Hadoop的shuffle过程就是从map 端输出到reduce端输入之间的过程。 map过程的输出是写入本地磁盘而不是HDFS,但是一开始数据并不是直接写入磁盘而是缓冲在内存中,缓存的好处就是减少磁盘I/O的开销,提高合并和排序的速度。默认的内存缓冲大小是100M(可以配置),所以在书写map函数的时候要尽量减少内存的使用,为shuffle过程预留更多的内存,因为该过程是最耗时的过程。当缓冲的内存大小使用超过一定的阈值(默认80%),一个后台的线程就会启动把缓冲区中的数据写入(spill)到磁盘中,往内存中写入的线程继续写入知道缓冲区满,缓冲区满后线程阻塞直至缓冲区被清空。在数据spill到磁盘的过程中会有一些额外的处理,调用partition函数、combine函数(如果设置)、对数据进行排序(按key排序)。如果发生多次磁盘的溢出写,会在磁盘上形成几个溢出写文件,在map过程结束时,要将这些文件进行合并生成一个大的分区的排序的文件。 reduce端可能从n多map的结果中获取数据,而这些map的执行速度不尽相同,当其中一个map运行结束时,reduce就会从jobtractor中获取该信息。map运行结束后tasktractor会得到消息,进而将消息汇报给jobtractor,reduce定时从jobtractor获取该信息,reduce端默认有5个线程从map端拖拉数据。 4、shell如何判断文件是否存在,如果不存在该如何处理? if[!-f"$file"];then touch"$file" fi 不存在就创建一个吧。

相关文档
最新文档