大数据资料整理
什么是大数据
大数据就是海量数据的高效处理。
数据先要通过存储层存储下来，然后根据数据需求和目标来建立相应的数据模型和数据分析指标体系对数据进行分析产生价值。而中间的时效性又通过中间数据处理层提供的强大的并行计算和分布式计算能力来完成。三层相互配合，让大数据最终产生价值。
数据存储层
数据有很多分法，有结构化，半结构化，非结构化；也有元数据，主数据，业务数据；还可以分为GIS，视频，文件，语音，业务交易类各种数据。传统的结构化数据库已经无法满足数据多样性的存储要求，因此在RDBMS基础上增加了两种类型，一种是HDFS可以直接应用于非结构化文件存储，一种是NoSQL类数据库，可以应用于结构化和半结构化数据存储。
从存储层的搭建来说，关系型数据库，NoSQL数据库和HDFS分布式文件系统三种存储方式都需要。业务应用根据实际的情况选择不同的存储模式，但是为了业务的存储和读取方便性，我们可以对存储层进一步的封装，形成一个统一的共享存储服务层，简化这种操作。从用户来讲并不关心底层存储细节，只关心数据的存储和读取的方便性，通过共享数据存储层可以实现在存储上的应用和存储基础设置的彻底解耦。
HDFS 分布式文件系统
Hadoop Distributed File System，简称HDFS，是一个分布式文件系统。HDFS有着高容错性（fault-tolerant）的特点，并且设计用来部署在低廉的（low-cost）硬件上。而且它提供高吞吐量（high throughput）来访问应用程序的数据，适合那些有着超大数据集（large data set）的应用程序。HDFS放宽了（relax）POSIX的要求（requirements）这样可以实现流的形式访问（streaming access）文件系统中的数据。HDFS开始是为开源的apache项目nutch的基础结构而创建，HDFS是hadoop项目的一部分，而hadoop又是lucene的一部分。
- 流式的数据访问
运行在HDFS之上的应用程序必须流式地访问它们的数据集，它不是运行在普通文件系统之上的普通程序。HDFS被设计成适合批量处理的，而不是用户交互式的。重点是在数据吞吐量，而不是数据访问的反应时间，POSIX的很多硬性需求对于HDFS应用都是非必须的，去掉POSIX一小部分关键语义可以获得更好的数据吞吐率。
- 大数据集
运行在HDFS之上的程序有很大量的数据集。典型的HDFS文件大小是GB到TB的级别。所以，HDFS被调整成支持大文件。它应该提供很高的聚合数据带宽，一个集群中支持数百个节点，一个集群中还应该支持千万级别的文件。
- 简单一致性模型
大部分的HDFS程序对文件操作需要的是一次写多次读取的操作模式。一个文件一旦创建、写入、关闭之后就不需要修改了。这个假定简单化了数据一致的问题和并使高吞吐量的数据访问变得可能。一个Map-Reduce程序或者网络爬虫程序都可以完美地适合这个模型。
- 移动计算比移动数据更经济
在靠近计算数据所存储的位置来进行计算是最理想的状态，尤其是在数据集特别巨大的时候。这样消除了网络的拥堵，提高了系统的整体吞吐量。一个假定就是迁移计算到离数据更近的位置比将数据移动到程序运行更近的位置要更好。HDFS提供了接口，来让程序将自己移动到离数据存储更近的位置。
- 异构软硬件平台间的可移植性
HDFS被设计成可以简便地实现平台间的迁移，这将推动需要大数据集的应用更广泛地采用HDFS作为平台。
- 名字节点和数据节点
HDFS是一个的主从结构，一个HDFS集群是由一个名字节点，它是一个管理文件命名空间和调节客户端访问文件的主服务器，当然还有一些数据节点，通常是一个节点一个机器，它来管理对应节点的存储。HDFS对外开放文件命名空间并允许用户数据以文件形式存储。
内部机制是将一个文件分割成一个或多个块，这些块被存储在一组数据节点中。名字节点用来操作文件命名空间的文件或目录操作，如打开，关闭，重命名等等。它同时确定块与数据节点的映射。数据节点来负责来自文件系统客户的读写请求。数据节点同时还要执行块的创建，删除，和来自名字节点的块复制指令。
名字节点和数据节点都是运行在普通的机器之上的软件，机器典型的都是GNU/Linux，HDFS是用java编写的，任何支持java的机器都可以运行名字节点或数据节点，利用java语言的超轻便型，很容易将HDFS部署到大范围的机器上。典型的部署是由一个专门的机器来运行名字节点软件，集群中的其他每台机器运行一个数据节点实例。体系结构不排斥在一个机器上运行多个数据节点的实例，但是实际的部署不会有这种情况。
集群中只有一个名字节点极大地简单化了系统的体系结构。名字节点是仲裁者和所有HDFS元数据的仓库，用户的实际数据不经过名字节点。
- 硬件故障
硬件故障是常态，而不是异常。整个HDFS系统将由数百或数千个存储着文件数据片断的服务器组成。实际上它里面有非常巨大的组成部分，每一个组成部分都很可能出现故障，这就意味着HDFS里的一些组成部分是总是失效的，因此，故障的检测和自动快速恢复是HDFS一个非常核心的设计目标。
NoSQL 技术
NoSQL(NoSQL = Not Only SQL )，意即“不仅仅是SQL”，相对于铺天盖地的关系型数据库运用，这一概念无疑是一种全新的思维的注入，是一项全新的数据库革命性运动。
传统关系数据库面临需解决的问题
1．High performance - 对数据库高并发读写的需求
根据用户个性化信息来实时生成动态页面和提供动态信息，所以基本上无法使用动态页面静态化技术，因此数据库并发负载非常高，往往要达到每秒上万次读写请求。关系数据库应付上万次SQL查询还勉强支持，但是应付上万次SQL写数据请求，硬盘IO就已经无法承受了。
2.Huge Storage - 对海量数据的高效率存储和访问的需求
对于大型的SNS网站，每天用户产生海量的用户动态，以国外的Friendfeed为例，一个月就达到了2.5亿条用户动态，对于关系数据库来说，在一张2.5亿条记录的表里面进行SQL查询，效率是极其低下乃至不可忍受的。
3.High Scalability & High Availability- 对数据库的高可扩展性和高可用性的需求
数据库是最难进行横向扩展的，当一个应用系统的用户量和访问量与日俱增的时候，数据库却没有办法像web server和app server那样简单的通过添加更多的硬件和服务节点来扩展性能和负载能力。对于很多需要提供24小时不间断服务的网站来说，对数据库系统进行升级和扩展是非常痛苦的事情，往往需要停机维护和数据迁移,通过添加节点实现扩展，是传统关系数据所不能完成的任务。
NoSQL 数据库的特点：
- 可以处理超大量的数据。
- 它们运行在便宜的PC服务器集群上。
- PC集群扩充起来非常方便并且成本很低，避免了传统数据库共享操作的复杂性和成本，因而冲破了性能瓶颈。
- “SQL并非适用于所有的程序代码，” 对于那些繁重的重复操作的数据，SQL值得花钱。但是当数据库结构非常简单时，SQL可能没有太大用处。
- 没有过多的操作，相对传统数据库对数据的操作性较小。
- 大数据量，高性能。NoSQL数据库都具有非常高的读写性能，尤其在大数据量下，同样表现优秀。这得益于它的无关系性，数据库的结构简单。
- 灵活的数据模型。NoSQL无需事先为要存储的数据建立字段，随时可以存储自定义的数据格式。而在关系数据库里，增删字段是一件非常麻烦的事情。如果是非常大数据量的表，增加字段简直就是一个噩梦。
- 高可用。NoSQL在不太影响性能的情况，就可以方便的实现高可用的架构。比如Cassandra，HBase模型，通过复制模型也能实现高可用。
内存数据库
内存数据库，是NoSQL技术的最终产品表现形式之一（相对应还有列存数据库），顾名思义就是将数据放在内存中直接操作的数据库。相对于磁盘，内存的数据读写速度要高出几个数量级，将数据保存在内存中相比从磁盘上访问能够极大地提高应用的性能。同时，内存数据库抛弃了磁盘数据管理的传统方式，基于全部数据都在内存中重新设计了体系结构，并且在数据缓存、快速算法、并行操作方面也进行了相应的改进，所以数据处理速度比传统数据库的数据处理速度要快很多，一般都在10倍以上。内存数据库的最大特点是其“主拷贝”或“工作版本”常驻内存，即活动事务只与实时内存数据库的内存拷贝打交道。
内存数据库所处理的数据通常是“短暂”的，即有一定的有效时间，过时则有新的数据产生，而当前的决策推导变成无效。所以，实际应用中采用内存数据库来处理实时性强的业务逻辑处理数据。而传统数据库旨在处理永久、稳定的数据，其性能目标是高的系统吞吐量和低的代价，处理数据的实时性就要考虑的相对少一些。实际应用中利用传统数据库这一特性存放相对实时性要求不高的数据。
在实际应用中这两种数据库常常结合使用，而不是以内存数据库替代传统数据库。
- 从传统数据库同步数据到内存数据库
这部分数据同步采用增量表的方式或使用工具（例OGG）将这些增量数据更新到内存数据库对应表中，从而保证了数据的完整性和实时性。由于增量数据的数据量一般很小，所以这部分操作不会影响系统的性能。
- 从内存数据同步数据到传统数据库
当最新实时数据都保存在内存数据库当中，所以传统数据对内存数据库并没有实时性的要求。内存数据库到传统关系数据库的同步可以由应用程序生成文件，或通过类似ETL应用软件、数据库过程定期向传统数据库当中同步备份。
NoSQL数据库的产品
Membase
MongoDB
Hypertable
Apache Cassandra
CouchDB
数据处理层
数据处理层核心解决问题在于数据存储出现分布式后带来的数据处理上的复杂度，海量存储后带来了数据处理上的时效性要求，这些都是数据处理层要解决的问题。
在传统的相关云技术架构上，可以将HIVE，PIG和Hadoop MapReduce框架相关的技术内容全部划入到数据处理层的能力。 HIVE重点还是在真正处理下的复杂查询的拆分，查询结果的重新聚合，而MapReduce本身又实现真正的分布式处理能力。
MapReduce只是实现了一个分布式计算的框架和逻辑，而真正的分析需求的拆分，分析结果的汇总和合并还是需要hive层的能力整合。最终的目的很简单，即支持分布式架构下的时效性要求。
Thrift
Thrift是一个软件框架，最初由facebook开发，07年四月开放源码，08年5月进入apache孵化器。用来进行可扩展且跨语言的服务的开发。它结合了功能强大的软件堆栈和代码生成引擎，以构建在 C++, Java, Python, PHP, Ruby, Erlang, Perl, Haskell, C#, Cocoa, JavaScript, Node.js, Smalltalk, and OCaml 这些编程语言间无缝结合的、高效的服务。thrift允许用户定义一个简单的定义文件中的数据类型和服务接口。以作为输入文件，编译器生成代码用来方便地生成RPC客户端和服务器通信的无缝跨编程语言。
HIVE
Hive是建立在 Hadoop 上的数据仓库基础构架。它提供了一系列的工具，可以用来进行数据提取转化加载（ETL），这是一种可以存储、查询和分析存储在 Hadoop 中的大规模数据的机制。Hive 定义了简单的类 SQL 查询语言，称为 HQL，它允许熟悉 SQL 的用户查询数据。同时，这个语言也允许熟悉 MapReduce 开发者的开发自定义的 mapper 和 reducer 来处理内建的 mapper 和 reducer 无法完成的复杂的分析工作。Hive 没有专门的数据格式。 Hive 可以很好的工作在 Thrift 之上，控制分隔符，也允许用户指定数据格式。
Hive 体系结构主要分为以下几个部分：
一、用户接口
用户接口主要有三个：CLI，Client 和 WUI。其中最常用的是 CLI，Cli 启动的时候，会同时启动一个 Hive 副本。Client 是 Hive 的客户端，用户连接至 Hive Server。在启动 Client 模式的时候，需要指出 Hive Server 所在节点，并且在该节点启动 Hive Server。 WUI 是通过浏览器访问 Hive。
二、元数据存储
Hive 将元数据存储在数据库中，如 mysql、derby。Hive 中的元数据包括表的名字，表的列和分区及其属性，表的属性（是否为外部表等），表的数据所在目录等。
三、解释器、编译器、优化器、执行器
解释器、编译器、优化器完成 HQL 查询语句从词法分析、语法分析、编译、优化以及查询计划的生成。生成的查询计划存储在 HDFS 中，并在随后有 MapReduce 调用执行。
四、Hadoop
Hive 的数据存储在 HDFS 中，大部分的查询由 MapReduce 完成（不包含 * 的查询，比如 select * from table 不会生成 MapRedcue 任务）。
五、存储
Hive 没有专门的数据存储格式，也没有为数据建立索引，用户可以非常自由的组织 Hive 中的表，只需要在创建表的时候告诉 Hive 数据中的列分隔符和行分隔符，Hive 就可以解析数据。Hive 中所有的数据都存储在 HDFS 中，Hive 中包含以下数据模型：Table，External Table，Partition，Bucket。
Hive 中的 Table 和数据库中的 Table 在概念上是类似的，每一个 Table 在 Hive 中都有一个相应的目录存储数据。
Partition 对应于数据库中的 Partition 列的密集索引，但是 Hive 中 Partition 的组织方式和数据库中的很不相同。在 Hive 中，表中的一个 Partition 对应于表下的一个目录，所有的 Partition 的数据都存储在对应的目录中。
Buckets 对指定列计算 hash，根据 hash 值切分数据，目的是为了并行，每一个 Bucket 对应一个文件。
External Table 指向已经在 HDFS 中存在的数据，可以创建 Partition。它和 Table 在元数据的组织上是相同的，而实际数据的存储则有较大的差异。
Table 的创建过程和数据加载过程（这两个过程可以在同一个语句中完成），在加载数据的过程中，实际数据会被移动到数据仓库目录中；之后对数据对访问将会直接在数据仓库目录中完成。删除表时，表中的数据和元数据将会被同时删除。
MapReduce
MapReduce是一种编程模型，用于大规模数据集（大于1TB）的并行运算。概念"Map（映射）"和"Reduce（化简）"，和他们的主要思想，都是从函数式编程语言里借来的，还有从矢量编程语言里借来的特性。他极大地方便了编程人员在不会分布式并行编程的情况下，将自己的程序运行在分布式系统上。 当前的软件实现是指定一个Map（映射）函数，用来把一组键值对映射成一组新的键值对，指定并发的Reduce（化简）函数，用来保证所有映射的键值对中的每一个共享相同的键组
Map 和Reduce
简单说来，一个映射函数就是对一些独立元素组成的概念上的列表（例如，一个测试成绩的列表）的每一个元素进行指定的操作（比如前面的例子里，有人发现所有学生的成绩都被高估了一分，他可以定义一个“减一”的映射函数，用来修正这个错误。）。事实上，每个元素都是被独立操作的，而原始列表没有被更改，因为这里创建了一个新的列表来保存新的答案。这就是说，Map操作是可以高度并行的，这对高性能要求的应用以及并行计算领域的需求非常有用。
指的是对一个列表的元素进行适当的合并（继续看前面的例子，如果有人想知道班级的平均分该怎么做？他可以定义一个化简函数，通过让列表中的元素跟自己的相邻的元素相加的方式把列表减半，如此递归运算直到列表只剩下一个元素，然后用这个元素除以人数，就得到了平均分）。虽然他不如映射函数那么并行，但是因为化简总是有一个简单的答案，大规模的运算相对独立，所以化简函数在高度并行环境下也很有用。
工作原理
数据分析层
最后回到分析层，分析层重点是真正挖掘大数据的价值所在，而价值的挖掘核心又在于数据分析和挖掘。那么数据分析层核心仍然在于传统的BI分析的内容。包括数据的维度分析，数据的切片，数据的上钻和下钻，cube等。
数据分析我只关注两个内容，一个就是传统数据仓库下的数据建模，在该数据模型下需要支持上面各种分析方法和分析策略；其次是根据业务目标和业务需求建立的KPI指标体系，对应指标体系的分析模型和分析方法。解决这两个问题基本解决数据分析的问题。
传统的BI分析通过大量的ETL数据抽取和集中化，形成一个完整的数据仓库，而基于大数据的BI分析，可能并没有一个集中化的数据仓库，或者将数据仓库本身也是分布式的了，BI分析的基本方法和思路并没有变化，但是落地到执行的数据存储和数据处理方法却发生了大变化。
MPP架构介绍
MPP (Massively Parallel Processing)，大规模并行处理系统，这样的系统是由许多松耦合的处理单元组成的，要注意的是这里指的是处理单元而不是处理器。每个单元内的CPU都有自己私有的资源，如总线，内存，硬盘等。在每个单元内都有操作系统和管理数据库的实例复本。这种结构最大的特点在于不共享资源。
SMP架构介绍
SMP (Symmetric Multi-Processing),对称多处理系统内有许多紧耦合多处理器，在这样的系统中，所有的CPU共享全部资源，如总线，内存和I/O系统等，操作系统或管理数据库的复本只有一个，这种系统有一个最大的特点就是共享所有资源。