海量数据-大数据是什么专业？

mysql海量数据的存储和访问解决方案

第1章 引言

随着互联网应用的广泛普及，海量数据的存储和访问成为了系统设计的瓶颈问题。对于一个大型的互联网应用，每天几十亿的PV无疑对数据库造成了相当高的负载。对于系统的稳定性和扩展性造成了极大的问题。通过数据切分来提高网站性能，横向扩展数据层已经成为架构研发人员首选的方式。水平切分数据库，可以降低单台机器的负载，同时最大限度的降低了了宕机造成的损失。通过负载均衡策略，有效的降低了单台机器的访问负载，降低了宕机的可能性；通过集群方案，解决了数据库宕机带来的单点数据库不能访问的问题；通过读写分离策略更是最大限度了提高了应用中读取（Read）数据的速度和并发量。目前国内的大型互联网应用中，大量的采用了这样的数据切分方案，Taobao,Alibaba,Tencent，它们大都实现了自己的分布式数据访问层（DDAL）。以实现方式和实现的层次来划分，大概分为两个层次（Java应用为例）：JDBC层的封装，ORM框架层的实现。就JDBC层的直接封装而言，现在国内发展较好的一个项目是被称作“变形虫”(Amoeba)的项目，由阿里集团的研究院开发，现在仍然处于测试阶段（beta版），其运行效率和生产时效性有待考究。就ORM框架层的实现而言，比如Taobao的基于ibatis和Spring的的分布式数据访问层，已有多年的应用，运行效率和生产实效性得到了开发人员和用户的肯定。本文就是以ORM框架层为基础而实现的分布式数据访问层。本课题的难点在于分库后，路由规则的制定和选择以及后期的扩展性，比如：如何做到用最少的数据迁移量，达到扩充数据库容量（增加机器节点）的目的。核心问题将围绕数据库分库分表的路由规则和负载均衡策略展开。

第2章 基本原理和概念

2.1基本原理：

人类认知问题的过程总是这样的：what（什么）-?why(为什么)-?how(怎么

做)，接下来，本文将就这三个问题展开讨论和研究：

2.1.1什么是数据切分

"Shard" 这个词英文的意思是"碎片"，而作为数据库相关的技术用语，似乎最早见于大型多人在线角色扮演游戏中。"Sharding" 姑且称之为"分片"。Sharding 不是一门新技术，而是一个相对简朴的软件理念。众所周知，MySQL 5 之后才有了数据表分区功能，那么在此之前，很多 MySQL 的潜在用户都对 MySQL 的扩展性有所顾虑，而是否具备分区功能就成了衡量一个数据库可扩展性与否的一个关键指标(当然不是唯一指标)。数据库扩展性是一个永恒的话题，MySQL 的推广者经常会被问到：如在单一数据库上处理应用数据捉襟见肘而需要进行分区化之类的处理，是如何办到的呢? 答案是：Sharding。 Sharding 不是一个某个特定数据库软件附属的功能，而是在具体技术细节之上的抽象处理，是水平扩展(Scale Out，亦或横向扩展、向外扩展)的解决方案，其主要目的是为突破单节点数据库服务器的 I/O 能力限制，解决数据库扩展性问题。

通过一系列的切分规则将数据水平分布到不同的DB或table中，在通过相应的DB路由 或者 table路由规则找到需要查询的具体的DB或者table，以进行Query操作。这里所说的“sharding”通常是指“水平切分”， 这也是本文讨论的重点。具体将有什么样的切分方式呢和路由方式呢？行文至此，读者难免有所疑问，接下来举个简单的例子：我们针对一个Blog应用中的日志来说明，比如日志文章（article）表有如下字段：

article_id(int),title(varchar(128)),content(varchar(1024)),user_id(int)

面对这样的一个表，我们怎样切分呢？怎样将这样的数据分布到不同的数据库中的表中去呢？其实分析blog的应用，我们不难得出这样的结论：blog的应用中，用户分为两种：浏览者和blog的主人。浏览者浏览某个blog，实际上是在一个特定的用户的blog下进行浏览的，而blog的主人管理自己的blog，也同样是在特定的用户blog下进行操作的（在自己的空间下）。所谓的特定的用户，用数据库的字段表示就是“user_id”。就是这个“user_id”，它就是我们需要的分库的依据和规则的基础。我们可以这样做，将user_id为 1～10000的所有的文章信息放入DB1中的article表中，将user_id为10001～20000的所有文章信息放入DB2中的 article表中，以此类推，一直到DBn。 这样一来，文章数据就很自然的被分到了各个数据库中，达到了数据切分的目的。接下来要解决的问题就是怎样找到具体的数据库呢？其实问题也是简单明显的，既然分库的时候我们用到了区分字段user_id，那么很自然，数据库路由的过程当然还是少不了 user_id的。考虑一下我们刚才呈现的blog应用，不管是访问别人的blog还是管理自己的blog，总之我都要知道这个blog的用户是谁吧，也就是我们知道了这个blog的user_id，就利用这个user_id，利用分库时候的规则，反过来定位具体的数据库，比如user_id是234，利用该才的规则，就应该定位到DB1，假如user_id是12343，利用该才的规则，就应该定位到DB2。以此类推，利用分库的规则，反向的路由到具体的DB，这个过程我们称之为“DB路由”。

当然考虑到数据切分的DB设计必然是非常规，不正统的DB设计。那么什么样的DB设计是正统的DB设计呢？

我们平常规规矩矩用的基本都是。平常我们会自觉的按照范式来设计我们的数据库，负载高点可能考虑使用相关的Replication机制来提高读写的吞吐和性能，这可能已经可以满足很多需求，但这套机制自身的缺陷还是比较显而易见的（下文会提及）。上面提到的“自觉的按照范式设计”。考虑到数据切分的DB设计，将违背这个通常的规矩和约束，为了切分，我们不得不在数据库的表中出现冗余字段，用作区分字段或者叫做分库的标记字段，比如上面的article的例子中的user_id这样的字段（当然，刚才的例子并没有很好的体现出user_id的冗余性，因为user_id这个字段即使就是不分库，也是要出现的，算是我们捡了便宜吧）。当然冗余字段的出现并不只是在分库的场景下才出现的，在很多大型应用中，冗余也是必须的，这个涉及到高效DB的设计，本文不再赘述。

2.1.2为什么要数据切分

上面对什么是数据切分做了个概要的描述和解释，读者可能会疑问，为什么需要数据切分呢？像 Oracle这样成熟稳定的数据库，足以支撑海量数据的存储与查询了？为什么还需要数据切片呢？的确，Oracle的DB确实很成熟很稳定，但是高昂的使用费用和高端的硬件支撑不是每一个公司能支付的起的。试想一下一年几千万的使用费用和动辄上千万元的小型机作为硬件支撑，这是一般公司能支付的起的吗？即使就是能支付的起，假如有更好的方案，有更廉价且水平扩展性能更好的方案，我们为什么不选择呢？

但是，事情总是不尽人意。平常我们会自觉的按照范式来设计我们的数据库，负载高点可能考虑使用相关的Replication机制来提高读写的吞吐和性能，这可能已经可以满足很多需求，但这套机制自身的缺陷还是比较显而易见的。首先它的有效很依赖于读操作的比例，Master往往会成为瓶颈所在，写操作需要顺序排队来执行，过载的话Master首先扛不住，Slaves的数据同步的延迟也可能比较大，而且会大大耗费CPU的计算能力，因为write操作在Master上执行以后还是需要在每台slave机器上都跑一次。这时候 Sharding可能会成为鸡肋了。 Replication搞不定，那么为什么Sharding可以工作呢？道理很简单，因为它可以很好的扩展。我们知道每台机器无论配置多么好它都有自身的物理上限，所以当我们应用已经能触及或远远超出单台机器的某个上限的时候，我们惟有寻找别的机器的帮助或者继续升级的我们的硬件，但常见的方案还是横向扩展, 通过添加更多的机器来共同承担压力。我们还得考虑当我们的业务逻辑不断增长，我们的机器能不能通过线性增长就能满足需求？Sharding可以轻松的将计算，存储，I/O并行分发到多台机器上，这样可以充分利用多台机器各种处理能力，同时可以避免单点失败，提供系统的可用性，进行很好的错误隔离。

综合以上因素，数据切分是很有必要的，且我们在此讨论的数据切分也是将MySql作为背景的。基于成本的考虑，很多公司也选择了Free且Open的MySql。对MySql有所了解的开发人员可能会知道，MySQL 5 之后才有了数据表分区功能，那么在此之前，很多 MySQL 的潜在用户都对 MySQL 的扩展性有所顾虑，而是否具备分区功能就成了衡量一个数据库可扩展性与否的一个关键指标(当然不是唯一指标)。数据库扩展性是一个永恒的话题，MySQL 的推广者经常会被问到：如在单一数据库上处理应用数据捉襟见肘而需要进行分区化之类的处理，是如何办到的呢? 答案也是Sharding，也就是我们所说的数据切分方案。

我们用免费的MySQL和廉价的Server甚至是PC做集群，达到小型机+大型商业DB的效果，减少大量的资金投入，降低运营成本，何乐而不为呢？所以，我们选择Sharding，拥抱Sharding。

2.1.3怎么做到数据切分

说到数据切分，再次我们讲对数据切分的方法和形式进行比较详细的阐述和说明。

数据切分可以是物理 上的，对数据通过一系列的切分规则将数据分布到不同的DB服务器上，通过路由规则路由访问特定的数据库，这样一来每次访问面对的就不是单台服务器了，而是N台服务器，这样就可以降低单台机器的负载压力。

数 据切分也可以是数据库内的 ，对数据通过一系列的切分规则，将数据分布到一个数据库的不同表中，比如将article分为article_001,article_002等子表，若干个子表水平拼合有组成了逻辑上一个完整的article表，这样做的目的其实也是很简单的。 举个例子说明，比如article表中现在有5000w条数据，此时我们需要在这个表中增加（insert）一条新的数据，insert完毕后，数据库会针对这张表重新建立索引，5000w行数据建立索引的系统开销还是不容忽视的。但是反过来，假如我们将这个表分成100 个table呢，从article_001一直到article_100，5000w行数据平均下来，每个子表里边就只有50万行数据，这时候我们向一张只有50w行数据的table中insert数据后建立索引的时间就会呈数量级的下降，极大了提高了DB的运行时效率，提高了DB的并发量。当然分表的好处还不知这些，还有诸如写操作的锁操作等，都会带来很多显然的好处。

综上，分库降低了单点机器的负载；分表，提高了数据操作的效率，尤其是Write操作的效率。 行文至此我们依然没有涉及到如何切分的问题。接下来，我们将对切分规则进行详尽的阐述和说明。

上文中提到，要想做到数据的水平切分，在每一个表中都要有相冗余字符 作为切分依据和标记字段，通常的应用中我们选用user_id作为区分字段，基于此就有如下三种分库的方式和规则： （当然还可以有其他的方式）

按号段分：

(1) user_id为区分，1～1000的对应DB1，1001～2000的对应DB2，以此类推；

优点：可部分迁移

缺点：数据分布不均

(2)hash取模分：

对user_id进行hash（或者如果user_id是数值型的话直接使用user_id 的值也可），然后用一个特定的数字，比如应用中需要将一个数据库切分成4个数据库的话，我们就用4这个数字对user_id的hash值进行取模运算，也就是user_id%4,这样的话每次运算就有四种可能：结果为1的时候对应DB1；结果为2的时候对应DB2；结果为3的时候对应DB3；结果为0的时候对应DB4，这样一来就非常均匀的将数据分配到4个DB中。

优点：数据分布均匀

缺点：数据迁移的时候麻烦，不能按照机器性能分摊数据

(3)在认证库中保存数据库配置

就是建立一个DB，这个DB单独保存user_id到DB的映射关系，每次访问数据库的时候都要先查询一次这个数据库，以得到具体的DB信息，然后才能进行我们需要的查询操作。

优点：灵活性强，一对一关系

缺点：每次查询之前都要多一次查询，性能大打折扣

以上就是通常的开发中我们选择的三种方式，有些复杂的项目中可能会混合使用这三种方式。 通过上面的描述，我们对分库的规则也有了简单的认识和了解。当然还会有更好更完善的分库方式，还需要我们不断的探索和发现。

第3章 本课题研究的基本轮廓

上面的文字，我们按照人类认知事物的规律，what?why?how这样的方式阐述了数据库切分的一些概念和意义以及对一些常规的切分规则做了概要的介绍。本课题所讨论的分布数据层并不仅仅如此，它是一个完整的数据层解决方案，它到底是什么样的呢？接下来的文字，我将详细阐述本研究课题的完整思想和实现方式。

分布式数据方案提供功能如下：

（1）提供分库规则和路由规则（RouteRule简称RR），将上面的说明中提到的三中切分规则直接内嵌入本系统，具体的嵌入方式在接下来的内容中进行详细的说明和论述；

（2）引入集群（Group）的概念，保证数据的高可用性；

（3）引入负载均衡策略（LoadBalancePolicy简称LB）；

（4）引入集群节点可用性探测机制，对单点机器的可用性进行定时的侦测，以保证LB策略的正确实施，以确保系统的高度稳定性；

（5）引入读/写分离，提高数据的查询速度；

仅仅是分库分表的数据层设计也是不够完善的，当某个节点上的DB服务器出现了宕机的情况的时候，会是什么样的呢？是的，我们采用了数据库切分方案，也就是说有N太机器组成了一个完整的DB ，如果有一台机器宕机的话，也仅仅是一个DB的N分之一的数据不能访问而已，这是我们能接受的，起码比切分之前的情况好很多了，总不至于整个DB都不能访问。一般的应用中，这样的机器故障导致的数据无法访问是可以接受的，假设我们的系统是一个高并发的电子商务网站呢？单节点机器宕机带来的经济损失是非常严重的。也就是说，现在我们这样的方案还是存在问题的，容错性能是经不起考验的。当然了，问题总是有解决方案的。我们引入集群的概念，在此我称之为Group，也就是每一个分库的节点我们引入多台机器，每台机器保存的数据是一样的，一般情况下这多台机器分摊负载，当出现宕机情况，负载均衡器将分配负载给这台宕机的机器。这样一来，

就解决了容错性的问题。所以我们引入了集群的概念，并将其内嵌入我们的框架中，成为框架的一部分。

如上图所示，整个数据层有Group1，Group2，Group3三个集群组成，这三个集群就是数据水平切分的结果，当然这三个集群也就组成了一个包含完整数据的DB。每一个Group包括1个Master（当然Master也可以是多个）和 N个Slave，这些Master和Slave的数据是一致的。比如Group1中的一个slave发生了宕机现象，那么还有两个slave是可以用的，这样的模型总是不会造成某部分数据不能访问的问题，除非整个 Group里的机器全部宕掉，但是考虑到这样的事情发生的概率非常小（除非是断电了，否则不易发生吧）。

在没有引入集群以前，我们的一次查询的过程大致如下：请求数据层，并传递必要的分库区分字段（通常情况下是user_id）?数据层根据区分字段Route到具体的DB?在这个确定的DB内进行数据操作。 这是没有引入集群的情况，当时引入集群会是什么样子的呢？看图一即可得知，我们的路由器上规则和策略其实只能路由到具体的Group，也就是只能路由到一个虚拟的Group，这个Group并不是某个特定的物理服务器。接下来需要做的工作就是找到具体的物理的DB服务器，以进行具体的数据操作。基于这个环节的需求，我们引入了负载均衡器的概念（LB）。负载均衡器的职责就是定位到一台具体的DB服务器。具体的规则如下：负载均衡器会分析当前sql的读写特性，如果是写操作或者是要求实时性很强的操作的话，直接将查询负载分到Master，如果是读操作则通过负载均衡策略分配一个Slave。我们的负载均衡器的主要研究放向也就是负载分发策略，通常情况下负载均衡包括随机负载均衡和加权负载均衡 。 随机负载均衡很好理解，就是从N个Slave中随机选取一个Slave。这样的随机负载均衡是不考虑机器性能的，它默认为每台机器的性能是一样的。假如真实的情况是这样的，这样做也是无可厚非的。假如实际情况并非如此呢？每个Slave的机器物理性能和配置不一样的情况，再使用随机的不考虑性能的负载均衡，是非常不科学的，这样一来会给机器性能差的机器带来不必要的高负载，甚至带来宕机的危险， 同时高性能的数据库服务器也不能充分发挥其物理性能。基于此考虑从，我们引入了加权负载均衡，也就是在我们的系统内部通过一定的接口，可以给每台DB服务器分配一个权值，然后再运行时LB根据权值在集群中的比重，分配一定比例的负载给该DB服务器。当然这样的概念的引入，无疑增大了系统的复杂性和可维护性。有得必有失，我们也没有办法逃过的。

有了分库，有了集群，有了负载均衡器，是不是就万事大吉了呢？ 事情远没有我们想象的那么简单。虽然有了这些东西，基本上能保证我们的数据层可以承受很大的压力 ，但是这样的设计并不能完全规避数据库宕机的危害。假如Group1中的slave2 宕机了，那么系统的LB并不能得知，这样的话其实是很危险的，因为LB不知道，它还会以为slave2为可用状态，所以还是会给slave2分配负载。这样一来，问题就出来了，客户端很自然的就会发生数据操作失败的错误或者异常。这样是非常不友好的！怎样解决这样的问题呢？ 我们引入集群节点的可用性探测机制 ，或者是可用性的数据推送机制 。这两种机制有什么不同呢？首先说探测机制吧，顾名思义，探测即使，就是我的数据层客户端，不定时对集群中各个数据库进行可用性的尝试，实现原理就是尝试性链接，或者数据库端口的尝试性访问，都可以做到，当然也可以用JDBC尝试性链接，利用Java的Exception机制进行可用性的判断，具体的会在后面的文字中提到。那数据推送机制又是什么呢？其实这个就要放在现实的应用场景中来讨论这个问题了，一般情况下应用的DB 数据库宕机的话我相信DBA肯定是知道的，这个时候DBA手动的将数据库的当前状态通过程序的方式推送到客户端，也就是分布式数据层的应用端，这个时候在更新一个本地的DB状态的列表。并告知LB，这个数据库节点不能使用，请不要给它分配负载。一个是主动的监听机制，一个是被动的被告知的机制。两者各有所长。但是都可以达到同样的效果。这样一来刚才假设的问题就不会发生了，即使就是发生了，那么发生的概率也会降到最低。

上面的文字中提到的Master和Slave ，我们并没有做太多深入的讲解。如图一所示，一个Group由1个Master和N个Slave组成。为什么这么做呢？其中Master负责写操作的负载，也就是说一切写的操作都在Master上进行，而读的操作则分摊到Slave上进行。这样一来的可以大大提高读取的效率。在一般的互联网应用中，经过一些数据调查得出结论，读/写的比例大概在 10：1左右 ，也就是说大量的数据操作是集中在读的操作，这也就是为什么我们会有多个Slave的原因。但是为什么要分离读和写呢？熟悉DB的研发人员都知道，写操作涉及到锁的问题，不管是行锁还是表锁还是块锁，都是比较降低系统执行效率的事情。我们这样的分离是把写操作集中在一个节点上，而读操作其其他的N个节点上进行，从另一个方面有效的提高了读的效率，保证了系统的高可用性。读写分离也会引入新的问题，比如我的Master上的数据怎样和集群中其他的Slave机器保持数据的同步和一致呢?这个是我们不需要过多的关注的问题，MySql的Proxy机制可以帮助我们做到这点，由于Proxy机制与本课题相关性不是太强，

在这里不做详细介绍。

综上所述，本课题中所研究的分布式数据层的大体功能就是如此。以上是对基本原理的一些讨论和阐述。接下来就系统设计层面，进行深入的剖析和研究。

第4章 系统设计

4.1系统实现层面的选择

在引言部分中提到，该系统的实现层面有两种选择，一种是基于JDBC层面上的选择，一种是基于现有数据持久层框架层面上的选择，比如Hibernate，ibatis。两种层面各有长处，也各有不足之处。基于JDBC层面上的系统实现，系统开发难度和后期的使用难度都将大大提高。大大增加了系统的开发费用和维护费用。本课题的定位是在成型的ibatis持久层框架的基础上进行上层的封装，而不是对ibatis源码的直接修改，这样一来使本系统不会对现有框架有太多的侵入性，从而也增加了使用的灵活性。之所以选择ibatis，原因如下：

（1）ibatis的学习成本非常低，熟练的Java Programmer可在非常的短时间内熟练使用ibatis；

（2）ibatis是轻量级的ORM，只是简单的完成了RO，OR的映射，其查询语句也是通过配置文件sql-map.xml文件在原生sql的层面进行简单的配置，也就是说我们没有引入诸如Hibernate那样的HQL的概念，从而增强了 sql的可控性，优秀的DBA可以很好的从sql的层面对sql进行优化，使数据层的应用有很强的可控性。Hibernate虽然很强大，但是由于 Hibernate是OR的一个重型封装，且引入HQL的概念，不便于DBA团队对sql语句的控制和性能的调优。

基于以上两点理由，本课题在ORM的产品的选择上选择了易学易用且轻量级的持久层框架ibatis。下面的讨论也都是特定于ibatis的基础上的讨论。

4.2其他开源框架的选择

在一些大型的Java应用中，我们通常会采用Spring这样的开源框架，尤其是 IoC（DI）这部分，有效的帮助开发人员管理对象的依赖关系和层次，降低系统各层次之间的实体耦合。Spring的优点和用处我相信这是开发人员众所周知的，在此不再赘述。本课题的数据层也将采用Spring做为IoC（DI）的框架。

4.3系统开发技术和工具介绍

开发语言：Java JDK1.5

集成开发环境：Eclipse 3.3.4

Web环境下测试服务器：JBoss 4.2

构建工具：淘宝自行研发的构建工具Antx（类似于Maven），当然也可以用Maven

依赖的开源Jar：Spring2.0，ibaits，commons-configuration(读取配置文件)，log4j，junit等

什么是大数据,通俗的讲

有人说大数据技术是第四次技术革命，这个说法其实不为过。很多人只是听过大数据这个词或者是简单知道它是什么，那么它是什么呢，在这里就通俗点来说一下个人对大数据的理解。大数据，很明显从字面上理解就是大量的数据，海量的数据。大，意思就是数据的量级很大，不上TB都不好意思说是大数据。数据，狭义上理解就是12345那么些数据，毕竟计算机底层是二进制来存的，那么在大数据领域，数据就不仅仅包括数字这些，它可以是所有格式的东西，比如日志，音频视频，文件等等。所以，大数据从字面上理解就是海量的数据，技术上它包括这些海量数据的采集，过滤，清洗，存储，处理，查看等等部分，每一个部分包括一些大数据的相关技术框架来支持。举个例子，淘宝双十一的总交易额的显示，后面就是大数据技术的支持，全国那么多淘宝用户的交易记录汇聚到一起，数据量很大，而且要做到实时的展现，就需要强有力的大数据技术来处理了。数据量一大，那么得找地方来存，一个服务器硬盘可以挂多少，肯定满足不了这么大的数据量存储啊，所以，分布式的存储系统应运而生，那就是HDFS分布式文件系统。简单的说，就是把这么大的数据分开存在甚至几百甚至几千台服务器上，那么管理他们的系统就是HDFS文件系统，也是大数据技术的最基本的组件。有地方存了，需要一些分布式的数据库来管理查询啊，那就有了Hbase等，还需要一些组件来计算分析这些数据啊，mapreduce是最基本的计算框架，其他的计算框架Spark和Storm可以完成实时的处理，其中HDFS和MapReduce组成了Hadoop1.总之，一切都是数据。我们的历史，是不是都是大量的数据保存下来的，现在我们也是大数据的生活，天天有没有接到骚扰电话还知道你姓什么，你查话费什么的从几亿人的数据中查到你的信息，大数据生活。未来，大数据将更深刻的渗透到生活中。 1、大数据又称巨量资料，是海量具有高增长率和多样化特性的有价值的信息资产的集合。它不仅仅包括数字，还包括图片、文本、视频、交互记录等等。大数据无法在可承受时间范围内用常规软件工具进行捕捉、处理和管理。具有大亮、高速、多样、价值这四个特点，主要应用于计算机，它的最小单位是bit。2、大数据可以说是云计算不断发展下的一个产物，同时也必须依托于云计算的分布式处理、分布式数据库、和云存储、虚拟化技术对海量数据进行分布式处理。3、大数据中的信息资料大都 大数据的特点。数据量大、数据种类多、 要求实时性强、数据所蕴藏的价值大。在各行各业均存在大数据，但是众多的信息和咨询是纷繁复杂的，我们需要搜索、处理、分析、归纳、总结其深层次的规律。 笼统点讲吧！顾名思义大数据就是信息量大的数据！比如说一瞬间需要处理上亿条指令的动作，这个也算大数据，或者需要长时间演算的数据，甚至是包含无数条记录的信息，反正就是信息量大！

大数据=海量交易数据+海量交易数据对吗？

”大数据”包含了”海量数据”的含义，而且在内容上超越了海量数据，简而言之，”大数据”是”海量数据”+复杂类型的数据。大数据包括交易和交互数据集在内的所有数据集，其规模或复杂程度超出了常用技术按照合理的成本和时限捕捉、管理及处理这些数据集的能力。

海量数据，如何高效分析？

数据分析的几点要素:

一、数据分析的背景；

二、数据分析的目的；

三、数据初加工；

四、运用数据分析方法得出结论，要多维度、小颗粒度的深入分析。

大数据的一定是海量数据吗?实时的源源不断的产生的数据是不是大数据?

就一定是海量数据吗？实时的源源不断地产生数据他。是大数据的。

大数据是什么专业？

大数据是指无法在一定时间内用常规软件工具对其内容进行抓取、管理和处理的数据集合。大数据技术是指从各种各样类型的数据中，快速获得有价值信息的能力。 、大数据专业将从大数据应用的三个主要层面（即数据管理、系统开发、海量数据分析与挖掘）系统地帮助企业掌握大数据应用中的各种典型问题的解决办法，包括实现和分析协同过滤算法、运行和学习分类算法、分布式Hadoop集群的搭建和基准测试、分布式Hbase集群的搭建和基准测试、实现一个基于、Mapreduce的并行算法、部署Hive并实现一个的数据操作等等，实际提升企业解决实际问题的能力。大数据领域对于人才的需求总量大、层次多、范围广，产业对于人才的需求呈井喷式增长，相关行业拥有海量的岗位需求。大数据领域的人才成为大家趋之若鹜的“香饽饽”。大数据领域的职位薪资，比相同级别的其它职位高出20%以上。以Hadoop开发工程师为例，入门月薪已经达到了八千元以上，有工作经验的人更是动辄上万元。东时教育打造大数据人才，助推大数据产业发展，理论与实践并重，满足企业对于大数据人才培养教学的需求。 大数据属于数学一类的专业。相关专业名称有：“信息与计算科学”、“数学与应用数学”、“统计学”等。1、大数据专业将从大数据应用的三个主要层面（即数据管理、系统开发、海量数据分析与挖掘）系统地帮助企业掌握大数据应用中的各种典型问题的解决办法。2、大数据包括实现和分析协同过滤算法、运行和学习分类算法、分布式hadoop集群的搭建和基准测试、分布式hbase集群的搭建和基准测试、实现一个基于、mapreduce的并行算法、部署hive并实现一个的数据操作等等，实际提升企业解决实际问题的能力。3、大数据领域对于人才的需求总量大、层次多、范围广，产业对于人才的需求呈井喷式增长，相关行业拥有海量的岗位需求。大数据领域的人才成为大家趋之若鹜的“香饽饽”。大数据领域的职位薪资，比相同级别的其它职位高出20%以上。 就是一门海量数据统计，分析 开发的专业，可以在学校里学，有目标，师傅领进门

如何处理海量数据

在实际的工作环境下，许多人会遇到海量数据这个复杂而艰巨的问题，它的主要难点有以下几个方面：一、数据量过大，数据中什么情况都可能存在。如果说有10条数据，那么大不了每条去逐一检查，人为处理，如果有上百条数据，也可以考虑，如果数据上到千万级别，甚至过亿，那不是手工能解决的了，必须通过工具或者程序进行处理，尤其海量的数据中，什么情况都可能存在，例如，数据中某处格式出了问题，尤其在程序处理时，前面还能正常处理，突然到了某个地方问题出现了，程序终止了。二、软硬件要求高，系统资源占用率高。对海量的数据进行处理，除了好的方法，最重要的就是合理使用工具，合理分配系统资源。一般情况，如果处理的数据过TB级，小型机是要考虑的，普通的机子如果有好的方法可以考虑，不过也必须加大CPU和内存，就象面对着千军万马，光有勇气没有一兵一卒是很难取胜的。三、要求很高的处理方法和技巧。这也是本文的写作目的所在，好的处理方法是一位工程师长期工作经验的积累，也是个人的经验的总结。没有通用的处理方法，但有通用的原理和规则。下面我们来详细介绍一下处理海量数据的经验和技巧：一、选用优秀的数据库工具现在的数据库工具厂家比较多，对海量数据的处理对所使用的数据库工具要求比较高，一般使用Oracle或者DB2，微软公司最近发布的SQLServer2005性能也不错。另外在BI领域：数据库，数据仓库，多维数据库，数据挖掘等相关工具也要进行选择，象好的ETL工具和好的OLAP工具都十分必要，例如Informatic，Eassbase等。笔者在实际数据分析项目中，对每天6000万条的日志数据进行处理，使用SQLServer2000需要花费6小时，而使用SQLServer2005则只需要花费3小时。二、编写优良的程序代码处理数据离不开优秀的程序代码，尤其在进行复杂数据处理时，必须使用程序。好的程序代码对数据的处理至关重要，这不仅仅是数据处理准确度的问题，更是数据处理效率的问题。良好的程序代码应该包含好的算法，包含好的处理流程，包含好的效率，包含好的异常处理机制等。三、对海量数据进行分区操作对海量数据进行分区操作十分必要，例如针对按年份存取的数据，我们可以按年进行分区，不同的数据库有不同的分区方式，不过处理机制大体相同。例如SQLServer的数据库分区是将不同的数据存于不同的文件组下，而不同的文件组存于不同的磁盘分区下，这样将数据分散开，减小磁盘I/O，减小了系统负荷，而且还可以将日志，索引等放于不同的分区下。四、建立广泛的索引对海量的数据处理，对大表建立索引是必行的，建立索引要考虑到具体情况，例如针对大表的分组、排序等字段，都要建立相应索引，一般还可以建立复合索引，对经常插入的表则建立索引时要小心，笔者在处理数据时，曾经在一个ETL流程中，当插入表时，首先删除索引，然后插入完毕，建立索引，并实施聚合操作，聚合完成后，再次插入前还是删除索引，所以索引要用到好的时机，索引的填充因子和聚集、非聚集索引都要考虑。五、建立缓存机制当数据量增加时，一般的处理工具都要考虑到缓存问题。缓存大小设置的好差也关系到数据处理的成败，例如，笔者在处理2亿条数据聚合操作时，缓存设置为100000条/Buffer，这对于这个级别的数据量是可行的。六、加大虚拟内存如果系统资源有限，内存提示不足，则可以靠增加虚拟内存来解决。笔者在实际项目中曾经遇到针对18亿条的数据进行处理，内存为1GB，1个P42.4G的CPU，对这么大的数据量进行聚合操作是有问题的，提示内存不足，那么采用了加大虚拟内存的方法来解决，在6块磁盘分区上分别建立了6个4096M的磁盘分区，用于虚拟内存，这样虚拟的内存则增加为4096*6+1024=25600M，解决了数据处理中的内存不足问题。七、分批处理海量数据处理难因为数据量大，那么解决海量数据处理难的问题其中一个技巧是减少数据量。可以对海量数据分批处理，然后处理后的数据再进行合并操作，这样逐个击破，有利于小数据量的处理，不至于面对大数据量带来的问题，不过这种方法也要因时因势进行，如果不允许拆分数据，还需要另想办法。不过一般的数据按天、按月、按年等存储的，都可以采用先分后合的方法，对数据进行分开处理。八、使用临时表和中间表数据量增加时，处理中要考虑提前汇总。这样做的目的是化整为零，大表变小表，分块处理完成后，再利用一定的规则进行合并，处理过程中的临时表的使用和中间结果的保存都非常重要，如果对于超海量的数据，大表处理不了，只能拆分为多个小表。如果处理过程中需要多步汇总操作，可按汇总步骤一步步来，不要一条语句完成，一口气吃掉一个胖子。九、优化查询SQL语句在对海量数据进行查询处理过程中，查询的SQL语句的性能对查询效率的影响是非常大的，编写高效优良的SQL脚本和存储过程是数据库工作人员的职责，也是检验数据库工作人员水平的一个标准，在对SQL语句的编写过程中，例如减少关联，少用或不用游标，设计好高效的数据库表结构等都十分必要。笔者在工作中试着对1亿行的数据使用游标，运行3个小时没有出结果，这是一定要改用程序处理了。十、使用文本格式进行处理对一般的数据处理可以使用数据库，如果对复杂的数据处理，必须借助程序，那么在程序操作数据库和程序操作文本之间选择，是一定要选择程序操作文本的，原因为：程序操作文本速度快；对文本进行处理不容易出错；文本的存储不受限制等。例如一般的海量的网络日志都是文本格式或者csv格式（文本格式），对它进行处理牵扯到数据清洗，是要利用程序进行处理的，而不建议导入数据库再做清洗。十一、定制强大的清洗规则和出错处理机制海量数据中存在着不一致性，极有可能出现某处的瑕疵。例如，同样的数据中的时间字段，有的可能为非标准的时间，出现的原因可能为应用程序的错误，系统的错误等，这是在进行数据处理时，必须制定强大的数据清洗规则和出错处理机制。十二、建立视图或者物化视图视图中的数据来源于基表，对海量数据的处理，可以将数据按一定的规则分散到各个基表中，查询或处理过程中可以基于视图进行，这样分散了磁盘I/O，正如10根绳子吊着一根柱子和一根吊着一根柱子的区别。十三、避免使用32位机子（极端情况）目前的计算机很多都是32位的，那么编写的程序对内存的需要便受限制，而很多的海量数据处理是必须大量消耗内存的，这便要求更好性能的机子，其中对位数的限制也十分重要。十四、考虑操作系统问题海量数据处理过程中，除了对数据库，处理程序等要求比较高以外，对操作系统的要求也放到了重要的位置，一般是必须使用服务器的，而且对系统的安全性和稳定性等要求也比较高。尤其对操作系统自身的缓存机制，临时空间的处理等问题都需要综合考虑。十五、使用数据仓库和多维数据库存储数据量加大是一定要考虑OLAP的，传统的报表可能5、6个小时出来结果，而基于Cube的查询可能只需要几分钟，因此处理海量数据的利器是OLAP多维分析，即建立数据仓库，建立多维数据集，基于多维数据集进行报表展现和数据挖掘等。十六、使用采样数据，进行数据挖掘基于海量数据的数据挖掘正在逐步兴起，面对着超海量的数据，一般的挖掘软件或算法往往采用数据抽样的方式进行处理，这样的误差不会很高，大大提高了处理效率和处理的成功率。一般采样时要注意数据的完整性和，防止过大的偏差。笔者曾经对1亿2千万行的表数据进行采样，抽取出400万行，经测试软件测试处理的误差为千分之五，客户可以接受。还有一些方法，需要在不同的情况和场合下运用，例如使用代理键等操作，这样的好处是加快了聚合时间，因为对数值型的聚合比对字符型的聚合快得多。类似的情况需要针对不同的需求进行处理。海量数据是发展趋势，对数据分析和挖掘也越来越重要，从海量数据中提取有用信息重要而紧迫，这便要求处理要准确，精度要高，而且处理时间要短，得到有价值信息要快，所以，对海量数据的研究很有前途，也很值得进行广泛深入的研究。

大数据是个什么鬼啦

什么是大数据?　　关于大数据的概念，至今似乎也没有一个公认的说法。同样，对于大数据的理解和认识，也同样产生了各种各样的判断。　　“大数据”(Big Data)是需要新处理模式才能具有更强的决策力、洞察发现力和流程优化能力的海量、高增长率和多样化的信息资产。从数据的类别上看，“大数据”指的是无法使用传统流程或工具处理或分析的信息。它定义了那些超出正常处理范围和大小、迫使用户采用非传统处理方法的数据集。　　一提到大数据，人们通常用3个V来定义它，即Volume(数量)、Variety(种类)和速度(Velocity)。随着业界对大数据理解的深入，第四个V也浮出水面，Veracity(真实性)正在成为大数据的基本特征之一。在前不久IBM召开的2013年大数据发布会上，重点解析了IBM与牛津大学共同的大数据研究成果——《分析：大数据在现实世界中的应用》白皮书中也提出了，重新定义和完善大数据“4V”理论的方向。　　研究表明，包含结构化和非结构化的大数据正在以每年60% 的增长率持续增长，到了2020年全球数据总量将增长44倍，达到35.2ZB。国内知名大数据学者，电子科技大学计算机互联网中心主任周涛博士表示：‘大数据’一词已经无处不在，其被用于承载所有类型的概念，包括海量数据、实时数据、社交媒体分析、下一代数据管理能力等。对于企业来说，对大数据的理解不应仅仅局限于技术领域，而应成为一项业务上需要优先考虑的任务，因为它能够带来全球整合经济时代商业模式的巨大变革。业界已经从对大数据重要性的认识阶段，发展到实践大数据的必要性的战略实施阶段。（ 大数据（big data），是指无法在可承受的时间范围内用常规软件工具进行捕捉、管理和处理的数据集合。 在维克托·迈尔-舍恩伯格及肯尼斯·库克耶编写的《大数据时代》 中大数据指不用随机分析法（抽样调查）这样的捷径，而采用所有数据进行分析处理。大数据的4v特点：volume（大量）、velocity（高速）、variety（多样）、value（价值）。 对于“大数据”（big data）研究机构gartner给出了这样的定义。“大数据”是需要新处理模式才能具有更强的决策力、洞察发现力和流程优化能力的海量、高增长率和多样化的信息资产。 根据维基百科的定义，大数据是指无法在可承受的时间范围内用常规软件工具进行捕捉、管理和处理的数据集合。 大数据技术的战略意义不在于掌握庞大的数据信息，而在于对这些含有意义的数据进行专业化处理。换言之，如果把大数据比作一种产业，那么这种产业实现盈利的关键，在于提高对数据的“加工能力”，通过“加工”实现数据的“增值”。

大数据时代：大数据是什么？

大数据（big data），是指无法在可承受的时间范围内用常规软件工具进行捕捉、管理和处理的数据集合。*在维克托·迈尔-舍恩伯格及肯尼斯·库克耶编写的《大数据时代》 中大数据指不用随机分析法（抽样调查）这样的捷径，而采用所有数据进行分析处理。大数据的4V特点：Volume（大量）、Velocity（高速）、Variety（多样）、Value（价值）。*对于“大数据”（Big data）研究机构Gartner给出了这样的定义。“大数据”是需要新处理模式才能具有更强的决策力、洞察发现力和流程优化能力的海量、高增长率和多样化的信息资产。*根据维基百科的定义，大数据是指无法在可承受的时间范围内用常规软件工具进行捕捉、管理和处理的数据集合。*大数据技术的战略意义不在于掌握庞大的数据信息，而在于对这些含有意义的数据进行专业化处理。换言之，如果把大数据比作一种产业，那么这种产业实现盈利的关键，在于提高对数据的“加工能力”，通过“加工”实现数据的“增值”。*不过，“大数据”在经济发展中的巨大意义并不代表其能取代一切对于社会问题的理性思考，科学发展的逻辑不能被湮没在海量数据中。著名经济学家路德维希·冯·米塞斯曾提醒过：“就今日言，有很多人忙碌于资料之无益累积，以致对问题之说明与解决，丧失了其对特殊的经济意义的了解。”这确实是需要警惕的。 最早提出大数据概念的学科是天文学和基因学，这两个学科从诞生之日起就依赖于基于海量数据的分析方法。 大数据可以说是计算机和互联网结合的产物，计算机实现了数据的数字化;互联网实现了数据的网络化;两者结合才赋予了大数据生命力! 随着互联网如同空气、水、电一样无处不在地渗透入我们的工作和生活，加上移动互联网、物联网、可穿戴联网设备的普及，新的数据正在以指数级别的加速度产生。据说目前世界上90%的数据是互联网出现以后迅速产生的。 不过，抛开数据的海量化生产和存储这种表面现象，我们更加要关注的是由数据量变带来的质变，这种质变表现在以下3个方面： 1)数据思维 大数据时代带给我们的是一种全新的思维方式，思维方式的改变在下一代成为社会生产中流砥柱的时候就会带来产业的颠覆性变革! - 分析全面的数据而非随机抽样; - 重视数据的复杂性，弱化精确性; - 关注数据的相关性，而非因果关系。 历来的商业变革都是由思维方式的转变开始的，旧的经济体制和传统的商业理念面临新的商业思维逻辑的时候，如果大脑不能与时俱进，吸收并转变为顺应潮流的新思维，通过新思维重新组织企业组织的战略、结构、文化和各种策略，那么貌似强大的体魄反而变成了企业前进的累赘。这种新思维颠覆巨头的案例最先发生在信息技术的传统领域，然后渗透到传统的商业领域：黑莓(blackberry)、摩托罗拉、诺基亚、柯达、雅虎。。。案例比比皆是! 当然，这些企业的没落并不是因为没有数据思维，但他们都是被新互联网思维淘汰的昔日巨人。数据思维是最新的思想，其影响力还没有发展到导致巨头轰然倒塌。但是，如果不给予足够的重视，下一波没落王国的名单中，可能就会有你! 2)数据资产 大数据时代，我们需要更加全面的数据来提高分析(预测)的准确度，因此我们就需要更多廉价、便捷、自动的数据生产工具。除了我们在互联网虚拟世界使用浏览器、软件有意或者无意留下的各种个人信息数据之外，我们正在用手机、智能手表、智能手环、智能项链等各种可穿戴数码产品生产数据;我们家里的路由器、电视机、空调、冰箱、饮水机、吸尘器、智能玩具等也开始越来越智能并且具备了联网功能，这些家用电器在更好地服务我们的同时，也在生产大量的数据;甚至我们出去逛街，商户的路由器，运营商的wlan和3g，无处不在的摄像头电子眼，百货大楼的自助屏幕，银行的atm，加油站以及遍布各个便利店的刷卡机都在收集和生产数据。 在互联网领域，我们喜欢说入口这个词，入口对应的直接意义是流量，而流量在互联网领域就意味着金钱，这种流量变现可能是广告，可能是游戏，也可能是电商。在大数据时代，入口这个词还有更深刻的意义，那就是数据生产的源头，用户通过某个app或者硬件产品满足某种需求的同事，也会留下一系列相关的数据，这些数据的合理使用可以让拥有这部分数据的企业获得更大的商业利益!所以，在大数据时代，意识到数据也是资产的公司都已经开始在各个数据生产的源头进行布局，可能是一个解决刚兴需求的web网站，也可能是一个单纯的工具app，还可能是一个可穿戴的数码产品! 3)数据变现 有了数据资产，就要通过分析来挖掘资产的价值，然后变现为用户价值、股东价值甚至社会价值。 大数据分析的核心目的就是预测，在海量数据的基础上，通过机器学习相关的各种技术和数学建模来预测事情发生的可能性并采取相应措施。预测股价、预测机票价格、预测流感等等。 预测事情发生的可能性继续往下延伸，就可以通过适当的干预，来引导事情向着期望的方向发展。比如亚马逊和所有的电商一样，都会基于对用户的喜好及消费能力分析来推荐商品，引导用户提高消费金额;google等互联网巨头也会通过各种技术手段来试图向不同的用户展现不同的广告，并称之为精准营销，由此来提高点击率(公司收入);网游公司也会在运营工程中通过玩家行为数据的分析来及时调整游戏关卡及计费点等设计。