海量数据处理算法

① 如何在海量数据中寻找和分析信息

如何在海量数据中寻找和分析信息
虽然大数据这个概念炒的非常火，但是大数据内部运作的逻辑，其实和我们传统行业是比较类似的。比如如果传统行业做实业的话，首先要有地基，你要有厂房，要有原材料，然后做加工，接下来设计成独立的产品，给客户带来独特的体验。我们刚才讲的开放云就是大数据的地基和厂房，原材料就是在线上和线下产生的海量数据。这个是我们现在网络目前每天数据规模，2013年是25PB，这个数字在快速的变化，我们现在处理的能力已经提高一倍，数据上目前是50PB，增长了一倍，这个就是我们目前大数据库要处理的数据的原材料。那么有了原材料接下来该怎么办？
数据存储
稍微看一下我们目前的大数据处理能力的三层架构。首先我们有海量的数据储存能力，然后在这个基础上，我们会做很多智能的分析，在这个基础上我们做很多大数据的产品，我们会逐步的开放这三个方面的能力。先说一下海量数据，做实业的各位领导和专家们，如果你有原材料，最关键的下一步要做两件事，一件事情是物流，第二件事情是原材料的标准化，要把原材料制成毛坯，在这个基础上才能实现你的产能。
在海量数据的处理上是这样的，网络三年前我们的架构是左边这样一个模式，在这个时候我们的数据传输，我们数据的储存都是每个产品线有自己的方式，我们大概用了两年的时间构建现在的数据储存方式，解决两个问题，一是数据的传输。现在网络很多产品线要实时产生大量海量的数据，这些数据都需要被实时的储存一个地方。
但是这些产品线的数据格式都是异构的。我们做了非常多的标准化的工作，在基础上形成了第一个海量数据储存的产品，叫通用的数据仓库。在使用这个通用的数据仓库，我们第一个构建了实时的海量数据的传输平台，那么任何一个产品线产生的数据都能够实时的传送到这个数据仓库里面。另外我们做了实时的数据标准化的工作，无论你的数据是什么样的格式，到我们数据仓库里面都以同样的格式来储存，有了这个物流，有了这个标准化，我们能够在这个基础上对数据进行更多的分析和加工。
那么从这开始，网络的数据就开始在大数据部门进行各种各样的处理过程。
数据分析
这个图有点复杂，这是数据在网络的一个生命周期，这边涉及到很多的技术细节，我会详细一一介绍。这里我想强调的是整个数据的流程是全自动化的，从数据的生成，数据的传输，数据的标准化，到最后数据的归类，数据的分析，都是全自动化的。这里面我是很高兴跟大家宣布，我们这套全自动化的流程，并形成了我们自己的产品。
这个产品我们现在有一个英文名字叫Query Engine，是一套标准的海量数据储存方案，首先无论你的数据是什么样的，经过我们的处理会把它做成数据标准化，当你的数据实时生成，我们有非常好的数据传输框架，保证你的数据上传到网络的开放云，在上面进行建模，进行各种各样可视化分析和决策的过程。我们已经成功了上传分析一家合作企业将近10T的关于新能源方面的一些数据。网络非常欢迎传统企业，如果你有海量的数据，你需要各种各样的分析和操作的话，来接洽我们，来使用我们这款产品。
当这个数据已经被结构化储存以后，我们希望在这个基础上能够进行各种各样的智能化分析。就像传统行业有自己的产品设计中心一样，会对产品进行各种各样的分析、排列组合，做各种各样的实验。在这个实验的基础上能够产生出比较好的产品，能够满足用户的需求。那么在大数据部门也有这样的需求，也需要有大数据产品的设计中心，在这个设计中心需要做很多实验，做出适用于网络，适用于客户的数据产品。所以这个产品经过四个月的努力，我们也已经对外开放。就是之前高级总监朱永忠介绍的，大家可以通过这个域名去访问。
在这上面，我们大数据新产品的设计中心，可以进行很多实时的智能分析，做很多的实验，对产品进行很多排列组合，看哪一种产品能够最适合行业，满足网络的需求。
大数据产品
那么有了这样的开放能力，下面给大家介绍在这个基础上大数据部研发出来的三个大数据产品，希望能够对在座的做实业的朋友有帮助。
第一个产品叫网络司南，专门针对于当企业发展到一定的阶段，有了一定的品牌影响力的企业，能够让企业对自身的品牌有更客观的了解，一共是三个方面。第一个是品牌分析，实际上你应该很想知道你的品牌在那个同行业里它的定位怎么样，周边的人是如何看待你这个品牌的，对你这个品牌的口碑怎么样。而且我们把它做到基本上是实时的，你可以此时此刻知道大家对你品牌的口碑到底怎么样。
另外一方面，关注你的品牌，应该一定有一批已经比较忠实的用户了，那么这些人除了关注你的品牌，像刚才陈总讲的一样，除了关注你的品牌，他还关心什么别的，他还对什么样的东西感兴趣。这些我们通过基于统计的用户画像也能够告诉你。
另外一个这些人是通过什么渠道来了解到你的品牌，他是通过IPAD，是通过手机，通过看电视，还是通过PC、还是移动互联网的浏览，这样以后做营销行为，就知道如何很快的影响到你的受众，什么样的渠道是最有效的。那么通过这几个方式，我们都能够告诉大家你的品牌到底处在什么样的状态。
给大家看两个司南在品牌上的应用。第一个叫代言人。很多品牌到了后期推广的时候，都有找代言人的需求。什么样的代言人在你最想影响的受众是最有号召力。之前是一些拍脑袋的决策，但是通过我们司南，通过海量的数据，通过海量的用户行为分析，可以帮助你做一个决策的科学。实际上我们已经通过大数据的分析，可以产生出超过一千家的企业，他们最合适的代言人到底是哪一位。如果哪位老总也想尝试自己品牌的话，可以和我们合作，我们可以告诉你，通过我们的数据，什么样的代言人，对于你的受众会产生最大的品牌号召力。
另外一个是舆情分析，实际是跟品牌的口碑最像。你的企业里有一系列的产品，每一个产品可能有轻微的差异化，就像我们的化妆品一样，每一款产品在用户中的口碑到底怎么样，用户喜欢这些产品什么样的功能，不喜欢这些产品什么样的功能。在之前，很多公司通过调研公司到各个城市，通过实时的访谈获得一些统计数据。整个过程要耗费一个月左右。通过我们的舆情分析，几乎可以实时告诉你这个答案，到底有多少用户是喜欢这个功能，有多少用户不喜欢这个功能。一个是通过一个月，一个是通过实时，这样的话就有时间差了。这个时间差就是网络大数据能给传统行业带来的竞争力。
这是我们第一款基于大数据的工具，叫网络司南。
另外就是我们的预测平台产品。预测这个产品说的已经比较多了，这次想跟大家说的是，当我们发布了预测产品，并且取得了比较好的效果，很多公司，或者是一些政府部门会跟我们接洽，能不能帮我们也分析一下数据。比如景点希望我们帮他预测下一步七天的人流到底多还是不多。有的企业希望让我们帮他预测下一步季度营业额是否能跟上一个季度匹配。
我们现在非常高兴的把我们的预测平台能力开放出来，你不需要再去接洽网络的产品经理做这样的事情，只要你使用我们的开放平台上传你的数据，我们后面就会基于一系列各种各样的数据分析，智能的算法和网络后台自己的数据帮你做一些决策和分析。希望能够帮助传统企业做决策分析的时候能够多一些科学的决策依据。
另外一个是我们的推荐。我们现在非常高兴把我们这个能力也开放出来，非常可惜我们目前只面对互联网的站长，站长可以定定制到底想用我们推荐的哪一方面的技术和性能、功能，非常灵活的为他的网站做推荐。但实际上我们最想做到的是把我们这套推荐引擎，和传统行业结合起来，和很多实时推荐结合起来，在这块也非常希望传统的行业能跟我们接洽，把我们这种非常先进的线上推荐的技术和线下的场景结合起来，在线下发挥更大的功能。
三个产品只是揭开了冰山一角，在大数据这个方面，产品设计的想象力其实是很多很多的，我们在这方面也非常兴奋，后面我们也会陆续推出一系列的大数据产品，请大家期待。网络愿意与更多的人一起合作，在大数据这个方向上给网络，给行业、给用户带来更多的价值。

② 云计算的海量数据挖掘工作是怎样实现的

云计算属于新兴技术领域，群英云计算转一篇关于问题的学术报告吧。对您应该有所帮助。

1引言

目前，人们正处于一个“无处不网、无时不网，人人上网、时时在线”的时代，图灵奖获得者吉姆·格雷（Jim Gray）认为，网络环境下每18个月产生的数据量等于过去几千年的数据量之和。目前互联网的数据具有海量增长、用户广泛、动态变化等特征。2010年，QQ同时在线的用户超过1亿人，淘宝一年交易次数比上年增长150%，视频服务Animoto在3天内通过Amazon将其服务能力迅速扩展至75万用户。

数据挖掘能够发现隐含在大规模数据中的知识，提高信息服务的质量。如伊朗事件中twitter快速传播假消息的识别、Amazon和淘宝网中商品关联关系分析，以及优酷网中视频个性化推荐等。海量数据挖掘在国家安全、国民经济和现代服务业中具有广泛应用，有助于提升网络环境下信息服务的质量，实现以人为本的信息服务。

从数据挖掘技术的发展历史看，随着互联网的蓬勃发展，数据的规模越来越大，从KB级发展到TB甚至PB级海量数据；数据挖掘的对象也变得越来越复杂，从数据库、到多媒体数据和复杂社会网络；数据挖掘的需求也从分类、聚类和关联到复杂的演化和预测分析；挖掘过程中的交互方式从单机的人机交互发展到现在社会网络群体的交互。这种发展给数据挖掘带来了巨大的挑战：对于网络环境下产生的TB级和PB级的复杂数据，需要有高效的海量数据挖掘算法；网络环境下大众的广泛参与，需要在数据挖掘算法中能够融入群体智慧；同时社会网络的迅速发展使得信息服务的个性化成为必然，要求能够满足即时组合的个性化挖掘服务。

云计算是一种基于互联网的、大众参与的计算模式，其计算资源（包括计算能力、存储能力、交互能力等）是动态、可伸缩、被虚拟化的，并以服务的方式提供 [1] 。具体表现在：云计算的动态和可伸缩的计算能力为高效海量数据挖掘带来可能性；云计算环境下大众参与的群体智能为研究集群体智慧的新的数据挖掘方法研究提供了环境；云计算的服务化特征使面向大众的数据挖掘成为可能。同时，云计算发展也离不开数据挖掘的支持，以搜索为例，基于云计算的搜索包括网页存储、搜索处理和前端交互三大部分。数据挖掘在这几部分中都有广泛应用，例如网页存储中网页去重、搜索处理中网页排序和前端交互中的查询建议，其中每部分都需要数据挖掘技术的支持。

因此，云计算为海量和复杂数据对象的数据挖掘提供了基础设施，为网络环境下面向大众的数据挖掘服务带来了机遇，同时也为数据挖掘研究提出了新的挑战性课题。

下面将对并行编程模型、基于并行编程模型高效海量数据挖掘算法，以及基于云计算的海量数据挖掘服务相关研究进行综述。

2并行编程模型相关方法

为了使用户能够通过简单的开发来方便地达到并行计算的效果，研究人员提出了一系列的并行计算模型。并行计算模型在用户需求和底层的硬件系统之间搭建桥梁使得并行算法的表示变得更加直观，对大规模数据的处理更加便捷。根据用户使用硬件环境的不同，并行编程模型又可以分为在多核机器、GPU计算、大型计算机以及计算机集群上的多种类型。目前比较常用的并行编程接口和模型包括：

pThread接口[2]。pThread是在类Unix系统上进行多线程编程的通用API，为用户提供了一系列对线程进行创建、管理和各类操作的函数，使用户能够方便地编写多线程程序。

MPI模型[3]。MPI的全称为消息传递接口（Message Passing Interface），它为用户提供了一系列的接口，使用户利用消息传递的方式来建立进程间的通信机制，从而方便地对各种算法进行并行实现。

MapRece模型[4]。MapRece模型是由谷歌公司提出的并行编程框架，它首先为用户提供分布式的文件系统，使用户能方便地处理大规模数据；然后将所有的程序运算抽象为Map和Rece两个基本操作，在Map阶段模型将问题分解为更小规模的问题，并在集群的不同节点上执行，在Rece阶段将结果归并汇总。MapRece是一个简单，但是非常有效的并行编程模型。

Pregel模型[5]。Pregel同样是由谷歌公司提出的专门针对图算法的编程模型，能够为大规模数据的图算法提供并行支持。一个典型的Pregel计算过程将在图上进行一系列的超级步骤（SuperSteps），在每个超级步骤中，所有顶点的计算都并行地执行用户定义的同一个函数，并通过一个“投票”机制来决定程序是否停止。

CUDA模型①。CUDA是由NVIDIA公司提出的一个基于GPU的并行计算模型。由于GPU在设计需求上与普通CPU不同，GPU通常被设计为能较慢地执行许多并发的线程，而不是较快的连续执行多个线程，这使得GPU在并行计算上有先天的优势。CUDA为用户提供了利用GPU计算的各种接口，使程序员能够像在普通电脑上进行CPU编程那样进行GPU程序的编写。

此外还有OpenMP、PVM、OpenCL等各种并行编程模型和方法。这些并行编程和方法一般都提供了主流编程语言的实现，从而使得用户能根据自身编程习惯来选用。

另一方面，随着云计算的不断推广，还出现了各种商用的并行计算/云计算平台，为用户提供并行计算服务。这其中比较着名的包括微软的Azure平台、Amazon公司的EC2平台、IBM公司的蓝云平台、谷歌公司的Google App Engine等。各大IT公司也纷纷开发自己的并行计算模型/框架作为自身技术服务的基本平台，这使得并行计算技术得到了更加快速的发展。

3基于并行编程模型高效海量数据挖掘算法研究

为了实现海量数据上的数据挖掘，大量分布式并行数据挖掘算法被提出。Bhari et al[6]整理了一个十分详尽的并行数据挖掘算法文献目录，包含了关联规则学习、分类、聚类、流数据挖掘四大类分布式数据挖掘算法，同时还包括分布式系统、隐私保护等相关的研究工作。

MapRece并行编程模型具有强大的处理大规模数据的能力，因而是海量数据挖掘的理想编程平台。数据挖掘算法通常需要遍历训练数据获得相关的统计信息，用于求解或优化模型参数。在大规模数据上进行频繁的数据访问需要耗费大量运算时间。为了提高算法效率，斯坦福大学Chu et al[7]提出了一种适用于大量机器学习算法的通用并行编程方法。通过对经典的机器学习算法进行分析可以发现，算法学习过程中的运算都能转化为若干在训练数据集上的求和操作；求和操作可以独立地在不同数据子集上进行，因此很容易在MapRece编程平台上实现并行化执行。将大规模的数据集分割为若干子集分配给多个Mapper节点，在Mapper节点上分别执行各种求和操作得到中间结果，最后通过Rece节点将求和结果合并，实现学习算法的并行执行。在该框架下，Chu et al实现了十种经典的数据挖掘算法，包括线性回归、朴素贝叶斯、神经网络、主成分分析和支持向量机等，相关成果在NIPS 2006会议上发表。

Ranger et al[8]提出了一个基于MapRece的应用程序编程接口Phoenix，支持多核和多处理器系统环境下的并行程序设计。Phoenix能够进行缓存管理、错误恢复和并发管理。他们使用Phoenix实现了K-Means、主成分分析和线性回归三种数据挖掘算法。

Gillick et al[9]对单程学习（Single-pass）、迭代学习（Iterative Learning）和基于查询的学习（Query-based Learning）三类机器学习算法在MapRece框架下的性能分别做了评测。他们对并行学习算法涉及到的如何在计算节点之间的共享数据、如何处理分布式存储数据等问题进行了研究。

Mahout①是APS（Apache Software Foundation）旗下的一个开源数据挖掘项目，通过使用Apache Hadoop库，可以实现大规模数据上的并行数据挖掘，包括分类、聚类、频繁模式挖掘、回归、降维等算法，目前已经发布了四个版本。

4基于云计算的海量数据挖掘服务研究

云计算除了给用户提供通用的并行编程模型和大规模数据处理能力之外，另一个重要的特点是为用户提供开放的计算服务平台。在数据挖掘方向，现在也有一系列的系统被开发出来，面向公众提供数据挖掘服务云计算平台。

Talia et al[10]提出可以从四个层次提供云计算数据挖掘服务：底层为组成数据挖掘算法的基本步骤；第二层为单独的数据挖掘服务，例如分类、聚类等；第三层为分布式的数据挖掘模式，例如并行分类、聚合式机器学习等；第四层为之前三层元素构成的完整的数据挖掘应用。在此设计基础上，他们设计了基于云计算的数据挖掘开放服务框架，并开发了一系列的数据挖掘服务系统，例如Weka4WS、Knowledge Grid、Mobile Data Mining Services、Mining@home等，用户可以利用图形界面定义自己的数据挖掘工作流，然后在平台上执行。

PDMiner[11]是由中国科学院计算技术研究所开发的基于Hadoop的并行分布式数据挖掘平台，该系统现在已经用于中国移动通信企业TB级实际数据的挖掘。PDMiner提供了一系列并行挖掘算法和ETL操作组件，开发的ETL算法绝大多数达到了线性加速比，同时具有很好的容错性。PDMiner的开放式架构可以使用户将算法组件经过简单配置方便地封装加载到系统中。

此外，商业智能领域的各大公司也提供面向企业的大规模数据挖掘服务，例如微策略、IBM、Oracle等公司都拥有自己的基于云计算的数据挖掘服务平台。

5总结和展望

通过云计算的海量数据存储和分布计算，为云计算环境下的海量数据挖掘提供了新方法和手段，有效解决了海量数据挖掘的分布存储和高效计算问题。开展基于云计算特点的数据挖掘方法的研究，可以为更多、更复杂的海量数据挖掘问题提供新的理论与支撑工具。而作为传统数据挖掘向云计算的延伸和丰富，基于云计算的海量数据挖掘将推动互联网先进技术成果服务于大众，是促进信息资源的深度分享和可持续利用的新方法、新途径。

③ 大数据算法有哪些

大数据是一个很广的概念，并没有大数据算法这种东西，您估计想问的是大数据挖掘的算法：
1.朴素贝叶斯
超级简单，就像做一些数数的工作。如果条件独立假设成立的话，NB将比鉴别模型收敛的更快，所以你只需要少量的训练数据。即使条件独立假设不成立，NB在实际中仍然表现出惊人的好。
2. 回归
LR有很多方法来对模型正则化。比起NB的条件独立性假设，LR不需要考虑样本是否是相关的。与决策树与支持向量机不同，NB有很好的概率解释，且很容易利用新的训练数据来更新模型（使用在线梯度下降法）。
3.决策树
DT容易理解与解释。DT是非参数的，所以你不需要担心野点和数据是否线性可分的问题，此外，RF在很多分类问题中经常表现得最好，且速度快可扩展，也不像SVM那样需要调整大量的参数，所以最近RF是一个非常流行的算法。
4.支持向量机
很高的分类正确率，对过拟合有很好的理论保证，选取合适的核函数，面对特征线性不可分的问题也可以表现得很好。SVM在维数通常很高的文本分类中非常的流行。

想要了解更多有关数据挖掘的信息，可以了解一下CDA数据分析师的课程。大数据分析师现在有专业的国际认证证书了， “CDA 数据分析师”具体指在互联网、金融、零售、咨询、电信、医疗、旅游等行业专门从事数据的采集、清洗、处理、分析并能制作业务报告、 提供决策的新型数据分析人才。全球 CDA 持证者秉承着先进商业数据分析的新理念，遵循着《CDA 数据分析师职业道德和行为准则》新规范，发 挥着自身数据科学专业能力，推动科技创新进步，助力经济持续发展。点击预约免费试听课。

④ 海量移动互联网数据 怎么做数据分析

一、数据量过大，数据中什么情况都可能存在。
如果说有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个P42.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万行，经测试软件测试处理的误差为千分之五，客户可以接受。
还有一些方法，需要在不同的情况和场合下运用，例如使用代理键等操作，这样的好处是加快了聚合时间，因为对数值型的聚合比对字符型的聚合快得多。类似的情况需要针对不同的需求进行处理。
海量数据是发展趋势，对数据分析和挖掘也越来越重要，从海量数据中提取有用信息重要而紧迫，这便要求处理要准确，精度要高，而且处理时间要短，得到有价值信息要快，所以，对海量数据的研究很有前途，也很值得进行广泛深入的研究。
海量数据处理专题（一）——开篇
大数据量的问题是很多面试笔试中经常出现的问题，比如 google 腾讯 这样的一些涉及到海量数据的公司经常会问到。
下面的方法是我对海量数据的处理方法进行了一个一般性的总结，当然这些方法可能并不能完全覆盖所有的问题，但是这样 的一些方法也基本可以处理绝大多数遇到的问题。下面的一些问题基本直接来源于公司的面试笔试题目，方法不一定最优，如果你有更好的处理方法，欢迎与我讨 论。
本贴从解决这类问题的方法入手，开辟一系列专题来解决海量数据问题。拟包含 以下几个方面。
Bloom Filter
Hash
Bit-Map
堆(Heap)
双层桶划分
数据库索引
倒排索引（Inverted Index）
外排序
Trie树
MapRece
在这些解决方案之上，再借助一定的例子来剖析海量数据处理问题的解决方案。
最简单的一点专业的事情让专业的人去做吧 招聘懂的人来做才王道

⑤ 海量数据的数据结构和算法，该怎么处理

业务建模、模式、松耦合，高内聚 对付海量并发、存储和运算就需要优秀的算法和数据结构了 还有数据散列阿等等

⑥ 五种大数据处理架构

五种大数据处理架构
大数据是收集、整理、处理大容量数据集，并从中获得见解所需的非传统战略和技术的总称。虽然处理数据所需的计算能力或存储容量早已超过一台计算机的上限，但这种计算类型的普遍性、规模，以及价值在最近几年才经历了大规模扩展。
本文将介绍大数据系统一个最基本的组件：处理框架。处理框架负责对系统中的数据进行计算，例如处理从非易失存储中读取的数据，或处理刚刚摄入到系统中的数据。数据的计算则是指从大量单一数据点中提取信息和见解的过程。
下文将介绍这些框架：
· 仅批处理框架：
Apache Hadoop
· 仅流处理框架：
Apache Storm
Apache Samza
· 混合框架：
Apache Spark
Apache Flink
大数据处理框架是什么？
处理框架和处理引擎负责对数据系统中的数据进行计算。虽然“引擎”和“框架”之间的区别没有什么权威的定义，但大部分时候可以将前者定义为实际负责处理数据操作的组件，后者则可定义为承担类似作用的一系列组件。
例如Apache Hadoop可以看作一种以MapRece作为默认处理引擎的处理框架。引擎和框架通常可以相互替换或同时使用。例如另一个框架Apache Spark可以纳入Hadoop并取代MapRece。组件之间的这种互操作性是大数据系统灵活性如此之高的原因之一。
虽然负责处理生命周期内这一阶段数据的系统通常都很复杂，但从广义层面来看它们的目标是非常一致的：通过对数据执行操作提高理解能力，揭示出数据蕴含的模式，并针对复杂互动获得见解。
为了简化这些组件的讨论，我们会通过不同处理框架的设计意图，按照所处理的数据状态对其进行分类。一些系统可以用批处理方式处理数据，一些系统可以用流方式处理连续不断流入系统的数据。此外还有一些系统可以同时处理这两类数据。
在深入介绍不同实现的指标和结论之前，首先需要对不同处理类型的概念进行一个简单的介绍。
批处理系统
批处理在大数据世界有着悠久的历史。批处理主要操作大容量静态数据集，并在计算过程完成后返回结果。
批处理模式中使用的数据集通常符合下列特征…
· 有界：批处理数据集代表数据的有限集合
· 持久：数据通常始终存储在某种类型的持久存储位置中
· 大量：批处理操作通常是处理极为海量数据集的唯一方法
批处理非常适合需要访问全套记录才能完成的计算工作。例如在计算总数和平均数时，必须将数据集作为一个整体加以处理，而不能将其视作多条记录的集合。这些操作要求在计算进行过程中数据维持自己的状态。
需要处理大量数据的任务通常最适合用批处理操作进行处理。无论直接从持久存储设备处理数据集，或首先将数据集载入内存，批处理系统在设计过程中就充分考虑了数据的量，可提供充足的处理资源。由于批处理在应对大量持久数据方面的表现极为出色，因此经常被用于对历史数据进行分析。
大量数据的处理需要付出大量时间，因此批处理不适合对处理时间要求较高的场合。
Apache Hadoop
Apache Hadoop是一种专用于批处理的处理框架。Hadoop是首个在开源社区获得极大关注的大数据框架。基于谷歌有关海量数据处理所发表的多篇论文与经验的Hadoop重新实现了相关算法和组件堆栈，让大规模批处理技术变得更易用。
新版Hadoop包含多个组件，即多个层，通过配合使用可处理批数据：
· HDFS：HDFS是一种分布式文件系统层，可对集群节点间的存储和复制进行协调。HDFS确保了无法避免的节点故障发生后数据依然可用，可将其用作数据来源，可用于存储中间态的处理结果，并可存储计算的最终结果。
· YARN：YARN是Yet Another Resource Negotiator（另一个资源管理器）的缩写，可充当Hadoop堆栈的集群协调组件。该组件负责协调并管理底层资源和调度作业的运行。通过充当集群资源的接口，YARN使得用户能在Hadoop集群中使用比以往的迭代方式运行更多类型的工作负载。
· MapRece：MapRece是Hadoop的原生批处理引擎。
批处理模式
Hadoop的处理功能来自MapRece引擎。MapRece的处理技术符合使用键值对的map、shuffle、rece算法要求。基本处理过程包括：
· 从HDFS文件系统读取数据集
· 将数据集拆分成小块并分配给所有可用节点
· 针对每个节点上的数据子集进行计算（计算的中间态结果会重新写入HDFS）
· 重新分配中间态结果并按照键进行分组
· 通过对每个节点计算的结果进行汇总和组合对每个键的值进行“Recing”
· 将计算而来的最终结果重新写入 HDFS
优势和局限
由于这种方法严重依赖持久存储，每个任务需要多次执行读取和写入操作，因此速度相对较慢。但另一方面由于磁盘空间通常是服务器上最丰富的资源，这意味着MapRece可以处理非常海量的数据集。同时也意味着相比其他类似技术，Hadoop的MapRece通常可以在廉价硬件上运行，因为该技术并不需要将一切都存储在内存中。MapRece具备极高的缩放潜力，生产环境中曾经出现过包含数万个节点的应用。
MapRece的学习曲线较为陡峭，虽然Hadoop生态系统的其他周边技术可以大幅降低这一问题的影响，但通过Hadoop集群快速实现某些应用时依然需要注意这个问题。
围绕Hadoop已经形成了辽阔的生态系统，Hadoop集群本身也经常被用作其他软件的组成部件。很多其他处理框架和引擎通过与Hadoop集成也可以使用HDFS和YARN资源管理器。
总结
Apache Hadoop及其MapRece处理引擎提供了一套久经考验的批处理模型，最适合处理对时间要求不高的非常大规模数据集。通过非常低成本的组件即可搭建完整功能的Hadoop集群，使得这一廉价且高效的处理技术可以灵活应用在很多案例中。与其他框架和引擎的兼容与集成能力使得Hadoop可以成为使用不同技术的多种工作负载处理平台的底层基础。
流处理系统
流处理系统会对随时进入系统的数据进行计算。相比批处理模式，这是一种截然不同的处理方式。流处理方式无需针对整个数据集执行操作，而是对通过系统传输的每个数据项执行操作。
· 流处理中的数据集是“无边界”的，这就产生了几个重要的影响：
· 完整数据集只能代表截至目前已经进入到系统中的数据总量。
· 工作数据集也许更相关，在特定时间只能代表某个单一数据项。
处理工作是基于事件的，除非明确停止否则没有“尽头”。处理结果立刻可用，并会随着新数据的抵达继续更新。
流处理系统可以处理几乎无限量的数据，但同一时间只能处理一条（真正的流处理）或很少量（微批处理，Micro-batch Processing）数据，不同记录间只维持最少量的状态。虽然大部分系统提供了用于维持某些状态的方法，但流处理主要针对副作用更少，更加功能性的处理（Functional processing）进行优化。
功能性操作主要侧重于状态或副作用有限的离散步骤。针对同一个数据执行同一个操作会或略其他因素产生相同的结果，此类处理非常适合流处理，因为不同项的状态通常是某些困难、限制，以及某些情况下不需要的结果的结合体。因此虽然某些类型的状态管理通常是可行的，但这些框架通常在不具备状态管理机制时更简单也更高效。
此类处理非常适合某些类型的工作负载。有近实时处理需求的任务很适合使用流处理模式。分析、服务器或应用程序错误日志，以及其他基于时间的衡量指标是最适合的类型，因为对这些领域的数据变化做出响应对于业务职能来说是极为关键的。流处理很适合用来处理必须对变动或峰值做出响应，并且关注一段时间内变化趋势的数据。
Apache Storm
Apache Storm是一种侧重于极低延迟的流处理框架，也许是要求近实时处理的工作负载的最佳选择。该技术可处理非常大量的数据，通过比其他解决方案更低的延迟提供结果。
流处理模式
Storm的流处理可对框架中名为Topology（拓扑）的DAG（Directed Acyclic Graph，有向无环图）进行编排。这些拓扑描述了当数据片段进入系统后，需要对每个传入的片段执行的不同转换或步骤。
拓扑包含：
· Stream：普通的数据流，这是一种会持续抵达系统的无边界数据。
· Spout：位于拓扑边缘的数据流来源，例如可以是API或查询等，从这里可以产生待处理的数据。
· Bolt：Bolt代表需要消耗流数据，对其应用操作，并将结果以流的形式进行输出的处理步骤。Bolt需要与每个Spout建立连接，随后相互连接以组成所有必要的处理。在拓扑的尾部，可以使用最终的Bolt输出作为相互连接的其他系统的输入。
Storm背后的想法是使用上述组件定义大量小型的离散操作，随后将多个组件组成所需拓扑。默认情况下Storm提供了“至少一次”的处理保证，这意味着可以确保每条消息至少可以被处理一次，但某些情况下如果遇到失败可能会处理多次。Storm无法确保可以按照特定顺序处理消息。
为了实现严格的一次处理，即有状态处理，可以使用一种名为Trident的抽象。严格来说不使用Trident的Storm通常可称之为Core Storm。Trident会对Storm的处理能力产生极大影响，会增加延迟，为处理提供状态，使用微批模式代替逐项处理的纯粹流处理模式。
为避免这些问题，通常建议Storm用户尽可能使用Core Storm。然而也要注意，Trident对内容严格的一次处理保证在某些情况下也比较有用，例如系统无法智能地处理重复消息时。如果需要在项之间维持状态，例如想要计算一个小时内有多少用户点击了某个链接，此时Trident将是你唯一的选择。尽管不能充分发挥框架与生俱来的优势，但Trident提高了Storm的灵活性。
Trident拓扑包含：
· 流批（Stream batch）：这是指流数据的微批，可通过分块提供批处理语义。
· 操作（Operation）：是指可以对数据执行的批处理过程。
优势和局限
目前来说Storm可能是近实时处理领域的最佳解决方案。该技术可以用极低延迟处理数据，可用于希望获得最低延迟的工作负载。如果处理速度直接影响用户体验，例如需要将处理结果直接提供给访客打开的网站页面，此时Storm将会是一个很好的选择。
Storm与Trident配合使得用户可以用微批代替纯粹的流处理。虽然借此用户可以获得更大灵活性打造更符合要求的工具，但同时这种做法会削弱该技术相比其他解决方案最大的优势。话虽如此，但多一种流处理方式总是好的。
Core Storm无法保证消息的处理顺序。Core Storm为消息提供了“至少一次”的处理保证，这意味着可以保证每条消息都能被处理，但也可能发生重复。Trident提供了严格的一次处理保证，可以在不同批之间提供顺序处理，但无法在一个批内部实现顺序处理。
在互操作性方面，Storm可与Hadoop的YARN资源管理器进行集成，因此可以很方便地融入现有Hadoop部署。除了支持大部分处理框架，Storm还可支持多种语言，为用户的拓扑定义提供了更多选择。
总结
对于延迟需求很高的纯粹的流处理工作负载，Storm可能是最适合的技术。该技术可以保证每条消息都被处理，可配合多种编程语言使用。由于Storm无法进行批处理，如果需要这些能力可能还需要使用其他软件。如果对严格的一次处理保证有比较高的要求，此时可考虑使用Trident。不过这种情况下其他流处理框架也许更适合。
Apache Samza
Apache Samza是一种与Apache Kafka消息系统紧密绑定的流处理框架。虽然Kafka可用于很多流处理系统，但按照设计，Samza可以更好地发挥Kafka独特的架构优势和保障。该技术可通过Kafka提供容错、缓冲，以及状态存储。
Samza可使用YARN作为资源管理器。这意味着默认情况下需要具备Hadoop集群（至少具备HDFS和YARN），但同时也意味着Samza可以直接使用YARN丰富的内建功能。
流处理模式
Samza依赖Kafka的语义定义流的处理方式。Kafka在处理数据时涉及下列概念：
· Topic（话题）：进入Kafka系统的每个数据流可称之为一个话题。话题基本上是一种可供消耗方订阅的，由相关信息组成的数据流。
· Partition（分区）：为了将一个话题分散至多个节点，Kafka会将传入的消息划分为多个分区。分区的划分将基于键（Key）进行，这样可以保证包含同一个键的每条消息可以划分至同一个分区。分区的顺序可获得保证。
· Broker（代理）：组成Kafka集群的每个节点也叫做代理。
· Procer（生成方）：任何向Kafka话题写入数据的组件可以叫做生成方。生成方可提供将话题划分为分区所需的键。
· Consumer（消耗方）：任何从Kafka读取话题的组件可叫做消耗方。消耗方需要负责维持有关自己分支的信息，这样即可在失败后知道哪些记录已经被处理过了。
由于Kafka相当于永恒不变的日志，Samza也需要处理永恒不变的数据流。这意味着任何转换创建的新数据流都可被其他组件所使用，而不会对最初的数据流产生影响。
优势和局限
乍看之下，Samza对Kafka类查询系统的依赖似乎是一种限制，然而这也可以为系统提供一些独特的保证和功能，这些内容也是其他流处理系统不具备的。
例如Kafka已经提供了可以通过低延迟方式访问的数据存储副本，此外还可以为每个数据分区提供非常易用且低成本的多订阅者模型。所有输出内容，包括中间态的结果都可写入到Kafka，并可被下游步骤独立使用。
这种对Kafka的紧密依赖在很多方面类似于MapRece引擎对HDFS的依赖。虽然在批处理的每个计算之间对HDFS的依赖导致了一些严重的性能问题，但也避免了流处理遇到的很多其他问题。
Samza与Kafka之间紧密的关系使得处理步骤本身可以非常松散地耦合在一起。无需事先协调，即可在输出的任何步骤中增加任意数量的订阅者，对于有多个团队需要访问类似数据的组织，这一特性非常有用。多个团队可以全部订阅进入系统的数据话题，或任意订阅其他团队对数据进行过某些处理后创建的话题。这一切并不会对数据库等负载密集型基础架构造成额外的压力。
直接写入Kafka还可避免回压（Backpressure）问题。回压是指当负载峰值导致数据流入速度超过组件实时处理能力的情况，这种情况可能导致处理工作停顿并可能丢失数据。按照设计，Kafka可以将数据保存很长时间，这意味着组件可以在方便的时候继续进行处理，并可直接重启动而无需担心造成任何后果。
Samza可以使用以本地键值存储方式实现的容错检查点系统存储数据。这样Samza即可获得“至少一次”的交付保障，但面对由于数据可能多次交付造成的失败，该技术无法对汇总后状态（例如计数）提供精确恢复。
Samza提供的高级抽象使其在很多方面比Storm等系统提供的基元（Primitive）更易于配合使用。目前Samza只支持JVM语言，这意味着它在语言支持方面不如Storm灵活。
总结
对于已经具备或易于实现Hadoop和Kafka的环境，Apache Samza是流处理工作负载一个很好的选择。Samza本身很适合有多个团队需要使用（但相互之间并不一定紧密协调）不同处理阶段的多个数据流的组织。Samza可大幅简化很多流处理工作，可实现低延迟的性能。如果部署需求与当前系统不兼容，也许并不适合使用，但如果需要极低延迟的处理，或对严格的一次处理语义有较高需求，此时依然适合考虑。
混合处理系统：批处理和流处理
一些处理框架可同时处理批处理和流处理工作负载。这些框架可以用相同或相关的组件和API处理两种类型的数据，借此让不同的处理需求得以简化。
如你所见，这一特性主要是由Spark和Flink实现的，下文将介绍这两种框架。实现这样的功能重点在于两种不同处理模式如何进行统一，以及要对固定和不固定数据集之间的关系进行何种假设。
虽然侧重于某一种处理类型的项目会更好地满足具体用例的要求，但混合框架意在提供一种数据处理的通用解决方案。这种框架不仅可以提供处理数据所需的方法，而且提供了自己的集成项、库、工具，可胜任图形分析、机器学习、交互式查询等多种任务。
Apache Spark
Apache Spark是一种包含流处理能力的下一代批处理框架。与Hadoop的MapRece引擎基于各种相同原则开发而来的Spark主要侧重于通过完善的内存计算和处理优化机制加快批处理工作负载的运行速度。
Spark可作为独立集群部署（需要相应存储层的配合），或可与Hadoop集成并取代MapRece引擎。
批处理模式
与MapRece不同，Spark的数据处理工作全部在内存中进行，只在一开始将数据读入内存，以及将最终结果持久存储时需要与存储层交互。所有中间态的处理结果均存储在内存中。
虽然内存中处理方式可大幅改善性能，Spark在处理与磁盘有关的任务时速度也有很大提升，因为通过提前对整个任务集进行分析可以实现更完善的整体式优化。为此Spark可创建代表所需执行的全部操作，需要操作的数据，以及操作和数据之间关系的Directed Acyclic Graph（有向无环图），即DAG，借此处理器可以对任务进行更智能的协调。
为了实现内存中批计算，Spark会使用一种名为Resilient Distributed Dataset（弹性分布式数据集），即RDD的模型来处理数据。这是一种代表数据集，只位于内存中，永恒不变的结构。针对RDD执行的操作可生成新的RDD。每个RDD可通过世系（Lineage）回溯至父级RDD，并最终回溯至磁盘上的数据。Spark可通过RDD在无需将每个操作的结果写回磁盘的前提下实现容错。
流处理模式
流处理能力是由Spark Streaming实现的。Spark本身在设计上主要面向批处理工作负载，为了弥补引擎设计和流处理工作负载特征方面的差异，Spark实现了一种叫做微批（Micro-batch）*的概念。在具体策略方面该技术可以将数据流视作一系列非常小的“批”，借此即可通过批处理引擎的原生语义进行处理。
Spark Streaming会以亚秒级增量对流进行缓冲，随后这些缓冲会作为小规模的固定数据集进行批处理。这种方式的实际效果非常好，但相比真正的流处理框架在性能方面依然存在不足。
优势和局限
使用Spark而非Hadoop MapRece的主要原因是速度。在内存计算策略和先进的DAG调度等机制的帮助下，Spark可以用更快速度处理相同的数据集。
Spark的另一个重要优势在于多样性。该产品可作为独立集群部署，或与现有Hadoop集群集成。该产品可运行批处理和流处理，运行一个集群即可处理不同类型的任务。
除了引擎自身的能力外，围绕Spark还建立了包含各种库的生态系统，可为机器学习、交互式查询等任务提供更好的支持。相比MapRece，Spark任务更是“众所周知”地易于编写，因此可大幅提高生产力。
为流处理系统采用批处理的方法，需要对进入系统的数据进行缓冲。缓冲机制使得该技术可以处理非常大量的传入数据，提高整体吞吐率，但等待缓冲区清空也会导致延迟增高。这意味着Spark Streaming可能不适合处理对延迟有较高要求的工作负载。
由于内存通常比磁盘空间更贵，因此相比基于磁盘的系统，Spark成本更高。然而处理速度的提升意味着可以更快速完成任务，在需要按照小时数为资源付费的环境中，这一特性通常可以抵消增加的成本。
Spark内存计算这一设计的另一个后果是，如果部署在共享的集群中可能会遇到资源不足的问题。相比HadoopMapRece，Spark的资源消耗更大，可能会对需要在同一时间使用集群的其他任务产生影响。从本质来看，Spark更不适合与Hadoop堆栈的其他组件共存一处。
总结
Spark是多样化工作负载处理任务的最佳选择。Spark批处理能力以更高内存占用为代价提供了无与伦比的速度优势。对于重视吞吐率而非延迟的工作负载，则比较适合使用Spark Streaming作为流处理解决方案。
Apache Flink
Apache Flink是一种可以处理批处理任务的流处理框架。该技术可将批处理数据视作具备有限边界的数据流，借此将批处理任务作为流处理的子集加以处理。为所有处理任务采取流处理为先的方法会产生一系列有趣的副作用。
这种流处理为先的方法也叫做Kappa架构，与之相对的是更加被广为人知的Lambda架构（该架构中使用批处理作为主要处理方法，使用流作为补充并提供早期未经提炼的结果）。Kappa架构中会对一切进行流处理，借此对模型进行简化，而这一切是在最近流处理引擎逐渐成熟后才可行的。
流处理模型
Flink的流处理模型在处理传入数据时会将每一项视作真正的数据流。Flink提供的DataStream API可用于处理无尽的数据流。Flink可配合使用的基本组件包括：
· Stream（流）是指在系统中流转的，永恒不变的无边界数据集
· Operator（操作方）是指针对数据流执行操作以产生其他数据流的功能
· Source（源）是指数据流进入系统的入口点
· Sink（槽）是指数据流离开Flink系统后进入到的位置，槽可以是数据库或到其他系统的连接器
为了在计算过程中遇到问题后能够恢复，流处理任务会在预定时间点创建快照。为了实现状态存储，Flink可配合多种状态后端系统使用，具体取决于所需实现的复杂度和持久性级别。
此外Flink的流处理能力还可以理解“事件时间”这一概念，这是指事件实际发生的时间，此外该功能还可以处理会话。这意味着可以通过某种有趣的方式确保执行顺序和分组。
批处理模型
Flink的批处理模型在很大程度上仅仅是对流处理模型的扩展。此时模型不再从持续流中读取数据，而是从持久存储中以流的形式读取有边界的数据集。Flink会对这些处理模型使用完全相同的运行时。
Flink可以对批处理工作负载实现一定的优化。例如由于批处理操作可通过持久存储加以支持，Flink可以不对批处理工作负载创建快照。数据依然可以恢复，但常规处理操作可以执行得更快。
另一个优化是对批处理任务进行分解，这样即可在需要的时候调用不同阶段和组件。借此Flink可以与集群的其他用户更好地共存。对任务提前进行分析使得Flink可以查看需要执行的所有操作、数据集的大小，以及下游需要执行的操作步骤，借此实现进一步的优化。
优势和局限
Flink目前是处理框架领域一个独特的技术。虽然Spark也可以执行批处理和流处理，但Spark的流处理采取的微批架构使其无法适用于很多用例。Flink流处理为先的方法可提供低延迟，高吞吐率，近乎逐项处理的能力。
Flink的很多组件是自行管理的。虽然这种做法较为罕见，但出于性能方面的原因，该技术可自行管理内存，无需依赖原生的Java垃圾回收机制。与Spark不同，待处理数据的特征发生变化后Flink无需手工优化和调整，并且该技术也可以自行处理数据分区和自动缓存等操作。
Flink会通过多种方式对工作进行分许进而优化任务。这种分析在部分程度上类似于SQL查询规划器对关系型数据库所做的优化，可针对特定任务确定最高效的实现方法。该技术还支持多阶段并行执行，同时可将受阻任务的数据集合在一起。对于迭代式任务，出于性能方面的考虑，Flink会尝试在存储数据的节点上执行相应的计算任务。此外还可进行“增量迭代”，或仅对数据中有改动的部分进行迭代。
在用户工具方面，Flink提供了基于Web的调度视图，借此可轻松管理任务并查看系统状态。用户也可以查看已提交任务的优化方案，借此了解任务最终是如何在集群中实现的。对于分析类任务，Flink提供了类似SQL的查询，图形化处理，以及机器学习库，此外还支持内存计算。
Flink能很好地与其他组件配合使用。如果配合Hadoop 堆栈使用，该技术可以很好地融入整个环境，在任何时候都只占用必要的资源。该技术可轻松地与YARN、HDFS和Kafka 集成。在兼容包的帮助下，Flink还可以运行为其他处理框架，例如Hadoop和Storm编写的任务。
目前Flink最大的局限之一在于这依然是一个非常“年幼”的项目。现实环境中该项目的大规模部署尚不如其他处理框架那么常见，对于Flink在缩放能力方面的局限目前也没有较为深入的研究。随着快速开发周期的推进和兼容包等功能的完善，当越来越多的组织开始尝试时，可能会出现越来越多的Flink部署
总结
Flink提供了低延迟流处理，同时可支持传统的批处理任务。Flink也许最适合有极高流处理需求，并有少量批处理任务的组织。该技术可兼容原生Storm和Hadoop程序，可在YARN管理的集群上运行，因此可以很方便地进行评估。快速进展的开发工作使其值得被大家关注。
结论
大数据系统可使用多种处理技术。
对于仅需要批处理的工作负载，如果对时间不敏感，比其他解决方案实现成本更低的Hadoop将会是一个好选择。
对于仅需要流处理的工作负载，Storm可支持更广泛的语言并实现极低延迟的处理，但默认配置可能产生重复结果并且无法保证顺序。Samza与YARN和Kafka紧密集成可提供更大灵活性，更易用的多团队使用，以及更简单的复制和状态管理。
对于混合型工作负载，Spark可提供高速批处理和微批处理模式的流处理。该技术的支持更完善，具备各种集成库和工具，可实现灵活的集成。Flink提供了真正的流处理并具备批处理能力，通过深度优化可运行针对其他平台编写的任务，提供低延迟的处理，但实际应用方面还为时过早。
最适合的解决方案主要取决于待处理数据的状态，对处理所需时间的需求，以及希望得到的结果。具体是使用全功能解决方案或主要侧重于某种项目的解决方案，这个问题需要慎重权衡。随着逐渐成熟并被广泛接受，在评估任何新出现的创新型解决方案时都需要考虑类似的问题。

⑦ 大数据常用的各种算法

我们经常谈到的所谓的​​ 数据挖掘 是通过大量的数据集进行排序，自动化识别趋势和模式并且建立相关性的过程。那现在市面的数据公司都是通过各种各样的途径来收集海量的信息，这些信息来自于网站、公司应用、社交媒体、移动设备和不断增长的物联网。

比如我们现在每天都在使用的搜索引擎。在自然语言处理领域，有一种非常流行的算法模型，叫做词袋模型，即把一段文字看成一袋水果，这个模型就是要算出这袋水果里，有几个苹果、几个香蕉和几个梨。搜索引擎会把这些数字记下来，如果你想要苹果，它就会把有苹果的这些袋子给你。

当我们在网上买东西或是看电影时，网站会推荐一些可能符合我们偏好的商品或是电影，这个推荐有时候还挺准。事实上，这背后的算法，是在数你喜欢的电影和其他人喜欢的电影有多少个是一样的，如果你们同时喜欢的电影超过一定个数，就把其他人喜欢、但你还没看过的电影推荐给你。 搜索引擎和推荐系统 在实际生产环境中还要做很多额外的工作，但是从本质上来说，它们都是在数数。

当数据量比较小的时候，可以通过人工查阅数据。而到了大数据时代，几百TB甚至上PB的数据在分析师或者老板的报告中，就只是几个数字结论而已。 在数数的过程中，数据中存在的信息也随之被丢弃，留下的那几个数字所能代表的信息价值，不抵其真实价值之万一。 过去十年，许多公司花了大价钱，用上了物联网和云计算，收集了大量的数据，但是到头来却发现得到的收益并没有想象中那么多。

所以说我们现在正处于“ 数字化一切 ”的时代。人们的所有行为，都将以某种数字化手段转换成数据并保存下来。每到新年，各大网站、App就会给用户推送上一年的回顾报告，比如支付宝会告诉用户在过去一年里花了多少钱、在淘宝上买了多少东西、去什么地方吃过饭、花费金额超过了百分之多少的小伙伴；航旅纵横会告诉用户去年做了多少次飞机、总飞行里程是多少、去的最多的城市是哪里；同样的，最后让用户知道他的行程超过了多少小伙伴。 这些报告看起来非常酷炫，又冠以“大数据”之名，让用户以为是多么了不起的技术。

实际上，企业对于数据的使用和分析，并不比我们每年收到的年度报告更复杂。已经有30多年历史的商业智能，看起来非常酷炫，其本质依然是数数，并把数出来的结果画成图给管理者看。只是在不同的行业、场景下，同样的数字和图表会有不同的名字。即使是最近几年炙手可热的大数据处理技术，也不过是可以数更多的数，并且数的更快一些而已。

在大数据处理过程中会用到那些算法呢？

1、A* 搜索算法——图形搜索算法，从给定起点到给定终点计算出路径。其中使用了一种启发式的估算，为每个节点估算通过该节点的较佳路径，并以之为各个地点排定次序。算法以得到的次序访问这些节点。因此，A*搜索算法是较佳优先搜索的范例。

2、集束搜索(又名定向搜索，Beam Search)——较佳优先搜索算法的优化。使用启发式函数评估它检查的每个节点的能力。不过，集束搜索只能在每个深度中发现最前面的m个最符合条件的节点，m是固定数字——集束的宽度。

3、二分查找(Binary Search)——在线性数组中找特定值的算法，每个步骤去掉一半不符合要求的数据。

4、分支界定算法(Branch and Bound)——在多种最优化问题中寻找特定最优化解决方案的算法，特别是针对离散、组合的最优化。

5、Buchberger算法——一种数学算法，可将其视为针对单变量较大公约数求解的欧几里得算法和线性系统中高斯消元法的泛化。

6、数据压缩——采取特定编码方案，使用更少的字节数(或是其他信息承载单元)对信息编码的过程，又叫来源编码。

7、Diffie-Hellman密钥交换算法——一种加密协议，允许双方在事先不了解对方的情况下，在不安全的通信信道中，共同建立共享密钥。该密钥以后可与一个对称密码一起，加密后续通讯。

8、Dijkstra算法——针对没有负值权重边的有向图，计算其中的单一起点最短算法。

9、离散微分算法(Discrete differentiation)。

10、动态规划算法(Dynamic Programming)——展示互相覆盖的子问题和最优子架构算法

11、欧几里得算法(Euclidean algorithm)——计算两个整数的较大公约数。最古老的算法之一，出现在公元前300前欧几里得的《几何原本》。

12、期望-较大算法(Expectation-maximization algorithm，又名EM-Training)——在统计计算中，期望-较大算法在概率模型中寻找可能性较大的参数估算值，其中模型依赖于未发现的潜在变量。EM在两个步骤中交替计算，第一步是计算期望，利用对隐藏变量的现有估计值，计算其较大可能估计值;第二步是较大化，较大化在第一步上求得的较大可能值来计算参数的值。

13、快速傅里叶变换(Fast Fourier transform，FFT)——计算离散的傅里叶变换(DFT)及其反转。该算法应用范围很广，从数字信号处理到解决偏微分方程，到快速计算大整数乘积。

14、梯度下降(Gradient descent)——一种数学上的最优化算法。

15、哈希算法(Hashing)。

16、堆排序(Heaps)。

17、Karatsuba乘法——需要完成上千位整数的乘法的系统中使用，比如计算机代数系统和大数程序库，如果使用长乘法，速度太慢。该算法发现于1962年。

18、LLL算法(Lenstra-Lenstra-Lovasz lattice rection)——以格规约(lattice)基数为输入，输出短正交向量基数。LLL算法在以下公共密钥加密方法中有大量使用：背包加密系统(knapsack)、有特定设置的RSA加密等等。

19、较大流量算法(Maximum flow)——该算法试图从一个流量网络中找到较大的流。它优势被定义为找到这样一个流的值。较大流问题可以看作更复杂的网络流问题的特定情况。较大流与网络中的界面有关，这就是较大流-最小截定理(Max-flow min-cut theorem)。Ford-Fulkerson 能找到一个流网络中的较大流。

20、合并排序(Merge Sort)。

21、牛顿法(Newton's method)——求非线性方程(组)零点的一种重要的迭代法。

22、Q-learning学习算法——这是一种通过学习动作值函数(action-value function)完成的强化学习算法，函数采取在给定状态的给定动作，并计算出期望的效用价值，在此后遵循固定的策略。Q-leanring的优势是，在不需要环境模型的情况下，可以对比可采纳行动的期望效用。

23、两次筛法(Quadratic Sieve)——现代整数因子分解算法，在实践中，是目前已知第二快的此类算法(仅次于数域筛法Number Field Sieve)。对于110位以下的十位整数，它仍是最快的，而且都认为它比数域筛法更简单。

24、RANSAC——是“RANdom SAmple Consensus”的缩写。该算法根据一系列观察得到的数据，数据中包含异常值，估算一个数学模型的参数值。其基本假设是：数据包含非异化值，也就是能够通过某些模型参数解释的值，异化值就是那些不符合模型的数据点。

25、RSA——公钥加密算法。较早的适用于以签名作为加密的算法。RSA在电商行业中仍大规模使用，大家也相信它有足够安全长度的公钥。

26、Schönhage-Strassen算法——在数学中，Schönhage-Strassen算法是用来完成大整数的乘法的快速渐近算法。其算法复杂度为：O(N log(N) log(log(N)))，该算法使用了傅里叶变换。

27、单纯型算法(Simplex Algorithm)——在数学的优化理论中，单纯型算法是常用的技术，用来找到线性规划问题的数值解。线性规划问题包括在一组实变量上的一系列线性不等式组，以及一个等待较大化(或最小化)的固定线性函数。

28、奇异值分解(Singular value decomposition，简称SVD)——在线性代数中，SVD是重要的实数或复数矩阵的分解方法，在信号处理和统计中有多种应用，比如计算矩阵的伪逆矩阵(以求解最小二乘法问题)、解决超定线性系统(overdetermined linear systems)、矩阵逼近、数值天气预报等等。

29、求解线性方程组(Solving a system of linear equations)——线性方程组是数学中最古老的问题，它们有很多应用，比如在数字信号处理、线性规划中的估算和预测、数值分析中的非线性问题逼近等等。求解线性方程组，可以使用高斯—约当消去法(Gauss-Jordan elimination)，或是柯列斯基分解( Cholesky decomposition)。

30、Strukturtensor算法——应用于模式识别领域，为所有像素找出一种计算方法，看看该像素是否处于同质区域( homogenous region)，看看它是否属于边缘，还是是一个顶点。

31、合并查找算法(Union-find)——给定一组元素，该算法常常用来把这些元素分为多个分离的、彼此不重合的组。不相交集(disjoint-set)的数据结构可以跟踪这样的切分方法。合并查找算法可以在此种数据结构上完成两个有用的操作：

查找：判断某特定元素属于哪个组。

合并：联合或合并两个组为一个组。

32、维特比算法(Viterbi algorithm)——寻找隐藏状态最有可能序列的动态规划算法，这种序列被称为维特比路径，其结果是一系列可以观察到的事件，特别是在隐藏的Markov模型中。

⑧ 如何进行大数据处理

大数据处理之一：收集

大数据的收集是指运用多个数据库来接收发自客户端(Web、App或许传感器方式等)的 数据，而且用户能够经过这些数据库来进行简略的查询和处理作业，在大数据的收集进程中，其主要特色和应战是并发数高，因为同时有可能会有成千上万的用户 来进行拜访和操作

大数据处理之二：导入/预处理

虽然收集端本身会有许多数据库，但是假如要对这些海量数据进行有效的剖析，还是应该将这 些来自前端的数据导入到一个集中的大型分布式数据库，或许分布式存储集群，而且能够在导入基础上做一些简略的清洗和预处理作业。导入与预处理进程的特色和应战主要是导入的数据量大，每秒钟的导入量经常会到达百兆，甚至千兆等级。

大数据处理之三：核算/剖析

核算与剖析主要运用分布式数据库，或许分布式核算集群来对存储于其内的海量数据进行普通 的剖析和分类汇总等，以满足大多数常见的剖析需求，在这方面，一些实时性需求会用到EMC的GreenPlum、Oracle的Exadata，以及根据 MySQL的列式存储Infobright等，而一些批处理，或许根据半结构化数据的需求能够运用Hadoop。 核算与剖析这部分的主要特色和应战是剖析触及的数据量大，其对系统资源，特别是I/O会有极大的占用。

大数据处理之四：发掘

主要是在现有数据上面进行根据各种算法的核算，然后起到预测(Predict)的作用，然后实现一些高等级数据剖析的需求。主要运用的工具有Hadoop的Mahout等。该进程的特色和应战主要是用于发掘的算法很复杂，并 且核算触及的数据量和核算量都很大，常用数据发掘算法都以单线程为主。

关于如何进行大数据处理，青藤小编就和您分享到这里了。如果您对大数据工程有浓厚的兴趣，希望这篇文章可以为您提供帮助。如果您还想了解更多关于数据分析师、大数据工程师的技巧及素材等内容，可以点击本站的其他文章进行学习。

⑨ 海量数据算法:如何从超过10G的记录IP地址的日志中，较快的找出登录次数最多的一个IP

对于以上问题我们可以把ip地址看成是分布在[0, 2^32]的一批数字。然后统计出这批数字中出现最多的把[0, 2^32] 划分为32个区间，32个区间再细划分，选出最大的一个值，以此类推。虽然理论上IPv4 有42亿个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流程中，当插入表时，首先删除索引，然后插入完 毕，建立索引，并实施聚合操作，聚合完成后，再次插入前还是删除索引，所以索引要用到好的时机，索引的填充因子和聚集、非聚集索引都要考虑。
五、建立缓存机制
当数据量增加时，一般的处理工具都要考虑到缓存问题。缓存大小设置的好差也关系到数据处理的成败，例如，笔者在处理2亿条数据聚合操作时，缓存设置为100000条/Buffer，这对于这个级别的数据量是可行的。
六、加大虚拟内存
如果系统资源有限，内存提示不足，则可以靠增加虚拟内存来解决。笔者在实际项目中曾经遇到针对18亿条的数据进行处理， 内存为1GB，1个P42.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万行，经测试软件测试处理的误差为千分之五，客户可以接受。
还有一些方法，需要在不同的情况和场合下运用，例如使用代理键等操作，这样的好处是加快了聚合时间，因为对数值型的聚合比对字符型的聚合快得多。类似的情况需要针对不同的需求进行处理。
海量数据是发展趋势，对数据分析和挖掘也越来越重要，从海量数据中提取有用信息重要而紧迫，这便要求处理要准确，精度要高，而且处理时间要短，得到有价值信息要快，所以，对海量数据的研究很有前途，也很值得进行广泛深入的研究。