1 大数据概述
大数据特性：4v volume velocity variety value 即大量化、快速化、多样化、价值密度低
数据量大：大数据摩尔定律
快速化：从数据的生成到消耗，时间窗口小，可用于生成决策的时间非常少；1秒定律，这和传统的数据挖掘技术有着本质区别（谷歌的dremel可以在1秒内调动上千台服务器处理PB级数据）
价值密度低，商业价值高
大数据影响：
对科学研究影响：出现科学研究第四方式数据（前三个分别是实验、理论、计算）
对思维方式影响：全样而非抽样、效率而非准确、相关而非因果
大数据应用：无人驾驶、智能医疗…
大数据一般指数据和大数据技术的综合
大数据技术，是指伴随着大数据的采集、存储、分析和应用的相关技术，是一系列使用非传统的工具来对大量的非结构化、半结构化、结构化数据进行处理，从而获得分析和预测结果的一系列数据处理和分析技术
大数据两大核心关键技术：分布式存储+分布式处理
云计算：通过网络以服务的方式为用户提供廉价IT资源
云计算典型特征：虚拟化和多租户
三种：IaaS、PaaS、SaaS
2 大数据处理架构Hadoop
2.1 Hadoop简介
Hadoop是Apache软件基金会旗下的*项目，开源分布式计算平台
为普通用户屏蔽大数据底层实现细节
是java开发的，但是支持多种编程语言写应用
不是单一技术，是一整套解决方案的统称，是一个项目
Hadoop两大核心：分布式文件系统HDFS+分布式并行框架MapReduce
Hadoop创始人：Doug Cutting
谷歌发布多种大数据技术：
2003年，谷歌发布了分布式文件系统GFS（Google File System），2004年Hadoop就把它纳入自己名下进行开源实现，HDFS是GFS的开源实现
2004年，谷歌发布了分布式并行编程框架MapReduce，2005年Hadoop也把它纳入自己的平台
随着Hadoop发展，各种相关项目独立脱离出来，成为独立子项目，2008年1月Hadoop正式成为Apache*项目
2008年4月，Hadoop用910节点构成集群去做计算，对1T数据做排序只用了209秒，由此而火
特性:
高可靠性，整个Hadoop平台采用冗余副本机制，当某些机器故障剩余机器仍可提供服务
高效性
高可扩展性
成本低
Hadoop不同版本，Apache Hadoop版本分为两代
Hadoop1.0到2.0变化：
将资源调度管理部分单独抽离出来成为YARN框架（Yet Another Resource Negotiator)，2.0由HDFS、MapReduce和YARN三个分支构成，MapReduce只做数据处理工作效率提高，MapReduce是架构在YARN之上的第一个计算框架,YARN也可以支持其他计算框架比如流计算框架Storm批处理计算Spark(Spark采用和MapReduce一样逻辑但是是采用内存计算）等等；
HDFS1.0的可扩展性不好，2.0提出NN Federation技术，是名称节点，做数据目录服务，外界访问都是访问这个服务再去取数据，1.0只有一个名称节点扩展性不好，2.0设置多个名称节点进行分区管理；2.0还增加HA，对NameNode做了个热备份；
知名的其他Hadoop开源版本：Hortonworks企业版，CDH（Cloudera Distribution Hadoop）、MapR、星环 等等
推荐企业来讲用CDH,个人学习就用Apache Hadoop
2.2 Hadoop项目结构
从最初的两大核心项目演化出非常多子项目成为一个生态圈
HDFS负责分布式文件存储
YARN框架负责资源管理和调度
MapReduce是做离线计算和批处理，不能做实时计算
Tez负责DAG计算，把很多MapReduce作业进行分析优化，构建成一个有向无环图，可以保证最好的处理效率，分清有些先做有些后做有些不要重复做
Spark的逻辑和MapReduce一样，但是是基于内存计算，而MapReduce是基于磁盘的计算，所以Spark的性能比MapReduce高一个数量级
Hive是数据仓库，是架构在MapReduce之上，SQL会被转化为一堆的MapReduce作业再去执行
Pig是帮你实现流数据处理的，属于轻量级的分析，提供类似sql的语法叫Pig Latin
Oozie是作业流调度系统
Zookeeper是做分布式协调一致性服务的，负责分布式锁、集群管理等等
HBase 列式数据库，非关系型分布式数据库，支持随机读写和实时应用,HDFS是做顺序读写的，但在实际应用中很多需要随机读写，就由HBase完成
Flume专门做日志收集的
Sqoop是在Hadoop和关系数据库做数据导入导出的
Ambari是个安装部署工具，帮你在一个集群上面非常智能化的部署和管理监控一整套Hadoop平台各种套件
2.3 Hadoop的安装与使用
Hadoop的安装模式：单机模式(默认)、伪分布式模式、分布式模式
HDFS节点：NameNode、DataNode
MapReduce节点：JobTracker、TaskTracker
NameNode管理各种元数据，里面很多数据都是直接保存在内存中，内存要大并且通道优化，带宽需求更大
SecondaryNameNode，是HDFS中的组件，是冷备份，小的集群直接和NameNode放同一台机器即可，大的集群要独立出来
Hadoop集群基准测试：
自带基准测试程序；
用TestDFSIO基准测试，来测试HDFS的IO性能；
用排序测试MapReduce:Hadoop自带一个部分排序的程序，测试过程都会通过Shuffle传输至Reduce，可以充分测试MapReduce各个组件的性能
3 分布式文件系统HDFS
块：不同于文件系统中的块，大很多，默认64M，也可以更大，但是如果太大也会影响MapReduce的性能，是为了降低寻址开销
支持大规模文件存储，突破单机存储容量上限
简化系统设计，使元数据设计非常简单
适合数据备份
NameNode：负责元数据，整个HDFS的管家，相当于数据目录
DataNode：具体负责存储实际数据
元数据包含文件是什么、文件被分成多少块、块与文件的映射关系、块被存在哪个服务器等信息
NameNode两大数据结构FsImage、Editlog
FsImage保存系统文件树以及文件树中所有文件和文件夹的元数据（包括文件的复制等级、修改访问时间、块大小以及组成文件的块），FsImage中没有具体记录块在哪个数据节点存储的，这个信息是单独在内存中维护的，至于块到底被放到哪个节点中去，这个信息是DataNode汇报而来实时维护的
Editlog记录对数据的操作如创建、删除、重命名等
每次启动时候从磁盘加载FsImage和Editlog到内存中，得到最新的元数据FsImage，旧的删除，同时创建新的空的Editlog，这个模式能够提高系统效率
当系统运行一段时间后，Editlog变得非常大的时候，系统效率又变慢了，此时第二名称节点Secondera NameNode开始作用帮助解决Editlog不断增大的问题，先请求NameNode停止使用Editlog并生成edits.new,然后SeconderaNamenode通过HTTP Get方式把Editlog和FsImage下载到本地进行合并操作得到新的FsImage，再发送给NameNode，然后NameNode把edits.new改为Editlog
HDFS的数据冗余保存，冗余因子默认3，当用伪分布式的时候冗余因子只能是1，能够加快数据传输速度，互为备份能够方便检查数据错误，高可靠
写策略：如果是集群内部机器的请求，就把第一个块放到本节点，如果来自集群外部请求，就会挑选一个磁盘不太慢cpu不太忙的节点来存放，第二个块就放到与第一个块不同机架的节点，第三个块会放到与第一个块相同机架的不同节点上，如果4、5、6.等块就会随机算法计算
读策略：一个基本原则是就近读取，HDFS提供一个API可以确定数据节点所属的机架id，客户端也可以调取API获取自己所属机架ID，确定远近关系，当客户端读取数据时，从NameNode获得数据块不同副本的存放位置列表，列表中包含了副本所在的数据节点，可以调用API来确定客户端和这些数据节点所属机架id，当发现同机架id时候优先读取该副本，否则随机选择
容错：
如果NameNode出错整个HDFS实例将失效，会暂停服务一段时间，从SeconderaNameNode恢复过来后再提供服务，1.0是这样,2.0有热备HA
如果DataNode出错，运行期间DataNode会发送心跳给NameNode，如果故障，把故障机的块冗余因子恢复，除了故障可以改变冗余副本位置，负载不均衡时候也可以Rebalance
如果数据出错，校验码机制，块创建的时候同时创建校验码保存在同个目录，读取时候重新计算校验码和保存的校验码对比，不一致说明数据出错，即进行冗余副本的再次复制
HDFS读写数据过程
hadoop fs 命令：-ls -mkdir –cat
把本地文件复制到hdfs中hadoop fs –cp 本地路径 hdfs路径
50070端口可以web方式看到hdfs信息，用的比较少
java API方式与HDFS交互
Hadoop为HDFS和MapReduce提供基础JAR包，叫hadoop common
4 分布式数据库HBase
4.1 简介
HBase是BigTable的一个开源实现,BigTable最初是为解决谷歌公司内部大规模网页搜索问题的，BigTable是架构在GFS之上，具有非常好的性能(可以支持PB级别的数据),具有非常好的扩展性
HBase是一个高性能 高可靠列式可伸缩的分布式数据库，特长是用来存储非结构化和半结构化的松散数据，目标是通过水平扩展存储海量数据
这个架构之上的pig hive等都是可以访问HBase的数据
为啥有了关系数据库 HDFS等等还要搞个HBase呢，原因： 虽然已经有了HDFS和MapReduce，但Hadoop主要解决大规模数据离线批量处理，Hadoop没办法满足大数据实时处理需求，而传统关系数据库扩展能力没法应对爆炸式数据增长，即使是读写分离分库分表等操作也有不便利效率低等缺陷，只有HBase能够满足不断增长的数据存储需求
和传统关系数据库区别：
不是使用关系模型设置各种字段类型，而是直接存储未经解释的二进制数据，由应用程序开发人员来对数据做解释
传统数据库对数据增删改等多种操作在HBase中避免了，比如连接操作，这是非常低效的操作
存储模式方面基于列
只支持对行键的简单索引
在关系数据库中更新数据时候旧数据删除掉，HBase中旧的版本还在，每新加的版本会生成新的时间戳标识
可伸缩性方面，关系数据库很难水平扩展，最多实现纵向扩展
HBase访问接口：Java API：Shell、Thrift Gateway（异构系统在线访问HBase）、REST Gateway（REST风格的HTTP API）；SQL类型接口：Pig、Hive
4.2 HBase数据模型
HBase是一个稀疏的多维度的排序的映射表，是列式数据库
通过行键、列族、列限定符、时间戳四个元素表示，HBase中每个值都是未经解释的字符串也就是Byte数组，由程序员自行对列类型解析
和关系数据库不同，和关系数据库不同的地方，列族支持动态扩展，且更新数据时候保留旧版本（与HDFS只允许追加不允许修改的特性相关）
以大表的形式来组织，不同于关系数据库遵循第一范式第二范式第三范式等规范化分解来降低数据的冗余存储，查询的时候不需要多表关联，追求的是分析的效率，用空间来换取表连接的时间
数据坐标：关系数据库通过行列定位，HBase是通过四维坐标定位，如果把四维坐标联合来看也可以当成键值数据库
概念试图：是一个稀疏表，很多地方是空
物理视图：底层是按照列族方式存储
列式数据库优点：每列数据类型相似可以带来很高的数据压缩率、分析效率高
4.3 HBase实现原理
HBase功能组件：
库函数：用于链接每个客户端
Master服务器：管家，实现对表的分区信息维护和管理；维护了一个Region服务器列表；整个集群当中有哪些Region服务器在工作；负责对Region进行分配；负载均衡
Region服务器：负责存取Region
客户端并不依赖于Master去获取信息
表会分多个Region，大Region会不断分裂，分裂的过程不设计底层物理数据，只是修改了它的指向信息而已非常快速，访问的还是旧的Region，后台会有合并过程把拆分的数据进行重新操作最终写到新的文件中得到新的Region，2006以前推荐一个Region大小100到200MB，现在一般最佳是1G到2G，实际取决于单台服务器的有效处理能力
同一个Region是不会拆分到不同的Region服务器上的，实际中每个Region服务器能存储10-1000个Region
HBase寻址：三层结构，首先构建一个元数据表称.META.表，当.META.表增大后分区由-ROOT-表来维护（-ROOT-表不允许分裂只有1个Region，-ROOT-表的地址写死在ZooKeeper文件中），为了加快数据存储速率，元数据表都是放在内存中，所以内存大小限制了Region个数从而限制了整个HBase的数据大小，但是是满足企业需求的
为了加速，客户端会缓存，第一次需要三级寻址，后面就不依赖于Master了实现更快的访问，同时要解决缓存失效问题，HBase采用惰性解决机制，每次都按照缓存信息找，当无法找到数据时候才去更新缓存再次经历三级寻址过程
4.4 HBase运行机制
客户端：访问HBase的接口，为了加快访问，将已经访问过的信息缓存
ZooKeeper服务器：实现协同管理服务，实现分布式协调一致性，被大量用于分布式文件系统，提供配置维护、域名服务、分布式同步服务等等，在HBase中就是提供管家功能维护和管理整个HBase集群，动物园管理员，可以确保任何时候只有一个HMaster在运行
Master（主服务器）：负责HBase中表和Region的管理工作，比如对表的增删改查都是通过Master进行管理的，同时对不同Region服务器负载均衡，负责调整分裂、合并后Region的分布，负责重新分配故障、失效的Region服务器
Region服务器：负责用户数据的存储和管理
每个Region服务器可以存储10-1000个region，共用一个日志文件HLog，每个列族单独构成一个Store，Store数据不是直接写到底层，要先写到MemStore缓存中，缓存满后刷写到磁盘文件StoreFile，StoreFile是HBase中的表现形式底层是借助于HDFS来存储的是通过HFile文件存储的
用户读写数据过程：写数据时候先到Region服务器，先写缓存写MemStore，为了保护数据，必须先写日志HLog，只有HLog完整写入磁盘才允许调用返回给客户端；读数据也是先访问MemStore再找StoreFile，因为最新数据都在MemStore而不是磁盘StoreFile中
缓存刷新：系统会周期性把MemStrore缓存中的内容写入磁盘StoreFile中，清空缓存，并在HLog写入个标记，每次刷写都会生成一个StoreFile，所以一个Store会包含多个StoreFile文件；每个Region服务器启动都检查HLog文件确认最近一次执行缓存刷新操作之后是否有新的写入操作，如果发现更新则先写入MemStore再刷写到StoreFile最后删除旧的HLog文件，开始为用户提供服务
StoreFile合并：当StoreFile数量多的时候索引数据变慢，达到一定阈值执行合并为大的StoreFile，这个合并操作相当占用资源；当StoreFile合并大到一定程度后又会引发分裂操作
HLog工作原理：就是通过日志来保护数据，ZooKeeper负责监视整个集群，检测到故障，会告诉Master服务器，Master会处理故障，Master服务器会把故障机器的遗留的HLog拉去过来，然后把各个Region的操作分拆出来，再分配给各个Region日志重做
4.5 HBase应用方案
性能优化方法：
时间靠近的数据都存在一起 时间戳(升序排序、越到后时间戳越大，长整型64位)，可以用系统最大的整型值减去时间戳long.MAX_VALUE-timestamp作为行键，排序就反过来了从而改变排序顺序，保证最新写的数据读的时候很快命中
如果对实时性较高，将相关数据放到服务器缓存来提升读写性能，可以在创建表的时候设置HColumnDescriptor.setInMemory选项为true，这样可以把相关表放入region服务器缓存中加快io
设置HColumnDescriptor.setMaxVersions可以设置最大版本数，设置1，就不会保存过期版本，可以节省空间
没有达到最大版本数的数据想清理掉咋办，设置TimeToLive参数，一旦超过生命周期就称为过期数据，就自动被系统删除掉，如果只需要最近两天的数据设置setTimeToLive(2*24*60*60)，超过2天的数据自动清空
检测性能：
Master-status是HBase自带工具通过web方式可以查询HBase运行状态
Ganglia是UC Berkeley发起的一个开源集群监视项目用于监控系统性能也支持对HBase进行性能监控
OpenTSDB可以从大规模集群中获取相关的性能参数，然后存储索引并可视化的方式提供给管理员
Ambari是Hadoop架构上的产品，作用是创建管理，监视整个集群，HBase也是集群一部分，所以也可以对HBase进行监视
sql引擎Hive去整合HBase，另外一个产品叫Phoenix
Hive0.6.0版本开始已经具备和HBase的整合功能，它们的接口互相通信即可实现对HBase的访问
Phoenix是致命SaaS提供商Salesforce的产品，开源，是构建在Apache Hadoop之上的一个SQL中间层，通过它允许开发者在HBase上执行SQL查询
构建HBase二级索引（辅助索引）
原生HBase是不支持二级索引的，默认索引只有行键，HBase原生产品只有通过单个行键或者行键起始结束点或者全表扫描三种方式来访问
HBase0.92版本以后的新特性叫Coprocessor，充分利用这个特性帮助建立二级索引，比如华为的Hindex、Redis Solr等等
怎么利用特性构建二级索引Coprocessor提供2个实现：endpoint、observe(endpoint相当于关系数据库的存储过程，observe相当于触发器),在更新表的同时触发器或者存储过程去维护索引表即二级索引，这不是HBase数据库自身的索引，优点是非侵入性，既没有对HBase做任何改动也不需要对上层应用做任何妥协，缺点是同时维护索引对集群压力倍增耗时也是倍增
华为的Hindex是java编写的支持多个表索引也支持多个列索引，而且也支持基于部分列值的索引
HBase+Redis，Redis是键值数据库，能高效管理键值对，在Redis数据库中管理索引，再定期把索引更新到HBase底层数据中，效率更高
HBase+Solr，Solr是高性能基于Lucene的全文搜索服务器，Solr构建的是其他列和行键之间的对应关系，这种方式也是很高效的
4.6 HBase的安装配置和常用Shell命令
下载HBase安装文件，然后解压到/usr/local，如果是单机版本解压即可用，如果是伪分布式需要配置，bin目录加入到path中
HBase配置有三种：单机（解压即可用）、伪分布式（让HBase通过HDFS存取数据）、分布式（用多台机器存取）
伪分布式：要配置JAVA_HOME；要配置Hadoop，实现无密码SSH登录；要先启动hadoop再启动HBase，关闭也是；修改配置文件时候有个选项hbase.managers.zk，这是配置ZooKeeper的，可以单独安装ZooKeeper组件服务来支撑HBase，也可以用HBase自带的ZooKeeper组件来提供服务
SHELL命令：create、list、put、get、drop
4.7 常用Java API
HBase是java开发的，有原生java api，也支持其他语言的编程
首先要导入jar包，到hbase安装目录中lib目录所有jar包导入（注意不要导入上节课的hadoop的jar包，会发生版本冲突）
Java 和shell的功能是一样的
5 NoSQL数据库
5.1 概述
NoSQL：not only sql 是关系数据库的有益补充，有灵活的可扩展性、灵活的数据模型、和云计算紧密结合
传统数据库缺陷：
无法满足web2.0的需求：没有办法满足海量数据需求、没有满足高并发需求、无法满足高可扩展性和高可用性
数据模型的局限性：用一个模型适应所有业务场景是不行的，hadoop针对离线分析、mongoDB和Redis都是针对在线业务，这些都是抛弃了关系模型
web2.0关系数据库许多特性无法发挥，事务机制和高效的查询机制这两个关系数据库的突出特性在web2.0时代成为鸡肋，
web2.0通常是不要求严格数据库事务的，比如发个微博失败与否关系不大，不像银行这些，事务机制需要很高额外开销，
web2.0一般不要求严格的读写实时性
web2.0不包含大量复杂sql查询，web2.0设计时候就避免了多表连接，连接操作是代价很高的，去结构化非规范化，宁可适当冗余来换来更好的性能
5.2 NoSQL数据库和关系数据库比较
关系数据库有完备的关系代数理论作为基础，NoSQL数据库缺乏统一理论基础
RDBMS是很难横向扩展，纵向扩展也有限，NoSQL有很强的水平扩展性能
关系数据库要事先定义严格的数据模式，NoSQL数据模型灵活
关系数据库在适当数据量的时候查询效率高，数据量级增大后查询效率下降，NoSQL未构建面向复杂查询的索引，查询性能差
事务一致性方面，关系数据库遵循ACID事务模型可以保证事务强一致性，NoSQL在设计时候放松一致性要求，采用BASE模型，BASE模型也是NoSQL数据库三大理论之一(CAP、BASE、最终一致性)
数据完整性，关系数据库具有保证完整性的完备机制来实现实体完整性参照完整性用户自定义完整性等，NoSQL不能实现完整性约束
可扩展性，关系数据库很差，NoSQL很好
可用性，关系数据库在小规模数据时候可用性还可以，数据量级大后可用性削弱，因为关系数据库设计之初优先保证严格的一致性，NoSQL有非常好的可用性，能够迅速返回所需结果
标准化方面，关系数据库遵循SQL标准，标准化完善，NoSQL未形成通用的行业标准，2015图领奖获得者迈克尔·斯通布雷克就认为NoSQL缺乏统一标准会在后面发展受到拖累
技术支持方面，关系数据库很多是商业数据库，能够获得强大的技术支持和后续服务支持，NoSQL很多是开源产品处于起步阶段，技术支持不如rdbms
可维护性，关系数据库需要dba维护，NoSQL维护更加复杂，因为它没有成熟的基础和实践操作规范，维护较为复杂
RDBMS：理论完备、有严格标准、支持事务一致性、可以借助索引机制实现高效查询，可扩展性差，尤其不具备水平可扩展性，无法支持海量数据存储，数据模型定义严格无法满足web2.0应用需求；用于电信银行的关键业务系统
NoSQL：支持超大规模的数据存储、数据模型灵活，缺乏底层基础理论支撑，不支持事务强一致性，导致无法用于关键业务；用于互联网企业以及传统企业的非关键性业务
无法互相取代，甚至有时候需要混合架构
5.3 NoSQL数据库的四大类型
键值数据库、文档数据库、列数据库、图数据库
键值数据库：
代表产品Redis、Memcached(Redis之前比较火的是Memcached，现在越来越多企业转向Redis)、SimpleDB（亚马逊在云中产品提供的键值数据库）
数据模型：键是一个字符串对象，值是任意类型数据，比如整型字符数组列表集合等等
典型应用：涉及频繁读写、拥有简单数据模型的应用；内容缓存，如会话、配置文件、参数、购物车等；存储配置和用户数据信息等移动应用
优点是扩展性好理论上有无上限的扩展空间，灵活性好，大量读写操作性能高
缺点是无法存储结构化信息，条件查询效率低，键值数据库根本不允许对它的值索引，值是对用户透明的，只能一个个找到key后访问value，也无法键与键之间关联，实现不了复杂查询
不适用：键值数据库根本没有通过值查询的路径，如果不是通过键而是通过值来查询，就不要用；不能通过两个或以上的键关联数据；一些键值数据库中，产生故障时不能回滚
使用者：百度云数据库(Redis)
实际生产中，键值数据库是理想的缓存层解决方案
列族数据库：
代表产品：BigTable、HBase(master slave结构)、Cassandra (不同于HBase，是对等结构，是p2p结构)
数据模型：简单，就是列族
典型应用：分布式数据存储和管理；数据在地理上分布于多个数据中心的应用；可以容忍副本中存在短期不一致情况的应用；拥有动态字段的应用
优点：可扩展性强，查询速度快，复杂性低
缺点：功能少，缺乏事务一致性支持，HBase有些人说是支持一致性，但是Cassandra就不支持
不适用：需要ACID事务特性的情形Cassandra就不适用
使用者：Facebook(HBase),Yahoo(HBase)
5.4 NoSQL三大理论基石 CAP理论、BASE、最终一致性
CAP理论：C consistency 一致性，A availability 可用性，P partition tolerance 分区容忍性（当出现网络分区的情况时，即系统中的一部分节点无法和其他节点通信，分离的系统也能正常运行）
理想的分布式系统是同时满足CAP特性，但是理论研究和实践证明这是做不到的，不能鱼和熊掌兼得，只能三者取其二，必须牺牲一个性质成就另外两个性质
BASE：Basically Available Soft state 和Eventual consistency的简写
Basically Available 基本可用：指一个分布式系统的一部分发生问题变得不可用时其他部分仍然可以使用，也就是允许分区失败的情形出现
Soft state：硬状态是数据库一直保持一致性，软状态指可以有一定的滞后性
Eventual consistency最终一致性：一致性包含强一致性和弱一致性，二者区别在于高并发的数据访问操作下，后续操作能否获取最新的数据，最终一致性是弱一致性的一个特例
对于HBase而言，底层是借助HDFS的，而HDFS采用强一致性，在数据没有同步到N个节点前是不会返回的，而对于Cassandra而言都可以设置三者的值，来选择最终一致性，这些数据库产品还会提供最终一致性的支持
5.5 从NoSQL到NewSQL数据库
和NewSQL对应的是OldSQL，传统数据库设计都期望One Size Fits All，但是这种理想状态被证明是不可实现的
转而对改变为对不同应用场景使用不同数据库，事务性应用用OldSQL，互联网应用用NoSQL，分析型应用用NewSQL
NewSQL充分吸收了OldSQL和NoSQL的各自优点，仍然采用关系模型提供强事务一致性，同时借鉴NoSQL有非常好的水平扩展支持海量数据存储
典型产品：亚马逊的RDS、微软SQL Azure(底层还是sql server相关技术)
5.6 文档数据库MongoDB
文档数据库是介于关系数据库和NoSQL之间的产品，最像关系数据库，是当前最热门的产品
MongoDB是C++编写的基于分布式文件存储的开源数据库系统
高负载情况添加更多节点保证数据服务性能，水平扩展能力强
MongoDB旨在为WEB应用提供可扩展的高性能数据存储解决方案
MongoDB将数据存储为一个文档，数据结构由键值对组成MongoDB文档类似JSON对象，字段值可以包含其他文档、数组及文档数组，文档格式叫BSON，是Binary类型的JSON文档
特点是：
提供面向文档的存储，操作简单容易；
相对于键值数据库有个很好的特性，它可以针对不同的任何的属性索引，实现更快的排序；
较好的水平扩展能力；
有丰富的查询表达式可查询文档中内嵌的对象和数组；
可替换已完成文档的某个指定的数据字段；
MongoDB中MapReduce主要是用来对数据进行批量处理和聚合操作
安装简单
术语和关系数据库差不多
关系数据库中一般遵循范式设计，查询时候需要多表查询，MongoDB不需要跨表连接，一个文档即可完整表述，提供并发性易用性
一个MongoDB可以建立多个数据库，默认数据库“DB”，存储在data目录，MongoDB的单个实例可以容纳多个数据库，每个都有自己的集合和权限和自己的文件
MongoDB不需要设置相同的字段，并且相同字段不需要相同数据类型
提供shell和java api访问方式
6 云数据库
6.1 概述
云计算是通过网络以服务的方式为用户提供非常廉价的IT资源
云计算优势：按需服务、随时服务、通用性、高可靠性、极其廉价、规模庞大
IaaS、PaaS、SaaS
云数据库是部署和虚拟化在云计算环境当中的数据
云数据库继承了云计算的特点：动态可扩展、高可用、廉价、易用性、免维护、高性能、安全
云数据库只是关系数据库NoSQL数据库在云端的实现，并不是新的数据库，也没有全新的数据模型
6.2 云数据库产品
最知名的是亚马逊Amazon的云数据服务，主要是键值数据库Dynamo和简单的数据库存储服务SimpleDB以及关系数据库RDS，也有分布式缓存服务的Amazon ElastiCache，也提供云中数据仓库服务Redshift
谷歌也有云数据库产品叫Google Cloud SQL，是基于MySQL的，支持云中事务，提供带JDBC和DB-API支持的传统MySQL环境，对开发者而言，Google Cloud SQL有个优势是和Google APP Engine（PaaS层）集成的
微软SQL Azure，基于SQL server，在推出之前很多云数据库都是NoSQL，所以微软推出云关系数据库是很有贡献的，很多企业需要事务支持，同时它也支持存储过程，SQL Server的产品无需更改可以直接部署到SQL Azure了，但是SQL Azure的事务是局部事务而不是分布式事务
oracle也有Oracle Cloud
雅虎的PNUTS
国内的阿里腾讯百度都有自己的云数据库，但是底层都是国外的这些数据库，百度提供了以键值模型为基础的云数据库采用的就是Redis
6.3 云数据库系统架构
云数据库架构多样，选取一种介绍，就是阿里巴巴开发的通用MySQL集群，就是UMP（Unified MySQL Platform），在阿里内部得到广泛使用，突出特点是低成本高性能
UMP在设计时原则：
整个系统保持单一的对外访问入口
消除单点故障，保证服务的高可用
具有良好的可伸缩性，可以根据外部负载动态的增加减少计算资源
可以实现资源之间的相互隔离
多租户共享资料库，可能出现某个用户消耗的资源过多影响其他租户导致整个系统不稳定，UMP在设计时候就有资源之间隔离限制避免此种情况发生
Mnesia：
UMP本质上就是个分布式数据库，分布式数据库不需要团队从0开发，Mnesia就是基于Erlang语言开发的分布式数据库管理系统，专门针对电信领域开发的数据库管理系统
具有非常好的特性，支持事务，支持透明的数据分片，利用两阶段锁实现分布式事务，可以线性扩展到至少50节点
Schema可在运行时动态配置
RabbitMQ：
是一个工业级的消息队列产品，比较常见的商业的消息队列产品如IBM WEBSPHERE MQ，消息队列是用来传递不同组件之间的消息，一个大的分布式系统有各种组件，组件之间的消息传递肯定不能是面向连接的，面向连接的资源消耗大效率低，一般都是异步，面向连接的是是同步传输，分布式系统为了提高效率都是采用异步传输，采用消息队列来保证消息生产者到消息消费者
ZooKeeper：
HBase中提过，典型功能是高效可靠的协调服务包括统一命名服务、状态同步服务、集群管理、分布式锁等等，在UMP系统中ZooKeeper发挥三个作用：
作为全局的配置服务器，一旦某个服务器的配置更改，ZooKeeper监听到，就通知其他服务器把最新的配置取走，减少许多人工干预，实现多个服务器配置一致性
提供分布式锁（选出一个集群的“总管”），UMP系统设计收有Controller（管家角色），为了避免单点故障，有多个管家，但是某个时候只有一个管家能起作用
监控所有MySQL实例，发生故障后及时探测到并报告给管家
LVS：将一组服务器构建为高性能高可用的虚拟服务器，对用户在看只有一个ip一个服务器，但是后面是整个集群，只不过通过负载均衡技术把请求引导到集群各个节点
Linux Virtual Server，是一个虚拟机的服务器集群系统，是一个通用的集群负载均衡框架， UMP系统借助LVS实现集群内部的负载均衡，有故障机也能屏蔽掉
LVS集群采用IP负载均衡技术和基于内容请求分发技术
调度器是LVS集群系统的唯一入口
整个集群结构对用户来讲是透明的
Controller服务器：UMP集群的总管，实现各种管理服务，集群成员的管理、元数据的存储、MySQL实例管理、故障恢复、备份迁移扩容等等功能，上面运行了一组Mnesia分布式数据库服务，这里面有些元数据，包括集群成员、用户的配置和状态信息，“路由表”(记录了用户名到后端MySQL的映射关系)，其他的组件就可能找管家要这些元数据，同时为了避免单点故障，整个系统设置了多个Controller服务器，在某个时刻有且只有一个管家提供服务，由ZooKeeper服务器来帮你选定唯一管家
WEB控制台：允许用户通过web方式管理访问平台
Proxy服务器：向用户提供访问MySQL数据库的服务，实现了MySQL协议，用户的认证信息、资源的配额信息（QPS、IOPS、最大连接数等等）、后台MySQL实例的地址，具有这样的路由功能
Agent服务器：也是个代理，部署在各个MySQL服务器上管理MySQL，由该组件负责管理这个服务器并和其他服务器通信
日志分析服务器：对整个日志分析，慢日志分析
信息统计服务器：统计到系统运营数据，包括用户连接数，每秒查询数QPS，MySQL实例的进程状态，这些都可以通过web界面可视化实时展现，这些信息不仅可以给用户和管理员看，也可作为系统后期弹性资源分配的依据和自动化的MySQL实例迁移的依据
愚公系统：功能简单也很强大，就是做数据迁移的，允许系统不停机的情况下实现动态扩容、缩容、迁移
6.4 UMP系统功能
容灾、读写分离、分库分表、资源管理、资源调度、资源隔离、数据安全
容灾：UMP系统会为每个用户创建2个MySQL实例一主一从，主库从库状态也是由ZooKeeper服务器维护，一旦发生故障启动主从切换，首先Controller服务器要修改路由表，然后把主库标记不可用，通过消息中间件RabbitMQ告知所有Proxy服务器，整个过程对用户透明，切换完成后主库恢复，主库追到和从库一致，Controller服务器命令从库锁定，然后再次追到一致，再次切换回来，整个过程有少许故障时间
读写分离：利用主从实例完成读写分离，写操作发到主库，读操作被均衡的发送到主库和从库
分库分表：UMP系统支持对用户透明的分库分表，指的是系统运行过程中动态自动的分库分表，但是在之前需要人工定义分库分表规则，当采用分库分表时，系统查询过程是，Proxy服务器解析SQL语句，提取出重写和分发SQL语句需要的信息，对SQL语句进行重写，得到针对像一个的MySQL实例的子语句，分发到各个MYSQL实例执行，最后接受各个mysql实例执行结果合并最终结果给用户
资源管理：整个UMP系统采用资源池机制对所有资源进行管理
负载均衡：负载较轻的服务器来创建MySQL实例
资源调度：UMP系统三种用户，数据量流量都很小、中等规模、大规模需要分片分表的用户，对于小规模用户，一般多个用户共享一个MySQL实例，中等规模用户独占一个MySQL实例，大规模的用户占用多个MySQL实例
资源隔离：2中方式隔离
安全机制：SSL数据库连接；提供数据访问IP白名单；记录用户操作日志；SQL拦截
6.5 Amazon AWS和云数据库
很多云计算相关的概念和服务都源于亚马逊，别看他是电子商务，但是为云计算的发展具有里程碑意义的开拓性的贡献
亚马逊开创的云计算的服务模式：把IT资源作为一种服务出租给美国中小企业，他高峰期和低峰期不一样，低峰期的时候把资源通过云计算的方式出租给中小企业，2006年推出这种方式的时候获得非常好的市场认可，06年还没有云计算的概念，他的业务量相当于谷歌微软这些的总和，每年带来几十亿美金收入，成为亚马逊主营收入，全球用了12个区域性的数据中心，拥有非常多的用户，在数据库方面也如火如荼，和oracle也产生了全面竞争，Amazon RDS已经有了10万多活跃用户，近期推出的自己开发的关系数据库Aurora，成长速度非常快
亚马逊在IaaS、PaaS、SaaS三层都提供服务
区域region 12个 每个区域自成体系
可用区Availability Zone 在region之下，类似一个个数据中心机房
边缘节点Edge Locations，负责内容分发网络CDN，CDN服务是为了加快用户访问速度
网络层提供直连服务，也提供VPN方式连接，Route 53（提供高可用高可伸缩的云域名解析系统）
计算层：EC2，Elastic Compute Cloud，弹性计算云；ELB，提供负载均衡器
存储：S3：简单对象存储服务；EBS，Elastic Block Storage，弹性块存储服务专门针对EC2虚拟机设置；Glacier，用于较少使用的文档存储和备份，价格便宜；
数据库：SimpleDB：基于云端的键值数据存储服务；DynamoDB：性能高，容错性强，支持分布式；RDS：支持MySQL，SQL Server和Oracle等数据库；Amazon ElastiCache，数据库缓存服务
应用程序层：企业搜索服务；队列服务；工作流服务；内容分发服务；弹性MapReduce
部署和管理服务：可以进行自动化一键式的相关部署
产品分类：
计算类：弹性计算云EC2，EC2提供了云端的虚拟机；弹性MapReduce，在云环境中部署Hadoop MapReduce环境，通过EC2虚拟机动态执行MapReduce计算任务
存储类：弹性块存储EBS；简单消息存储SQS；Blob对象存储S3；NoSQl数据库；关系数据库RDS
EC2最大特点：允许用户根据需求动态调整运行实例的类型和数量，实现按需付费
EC2平台主要几大部分：EC2实例（AMI），弹性块存储，弹性负载均衡
如何部署到虚拟机：需要把自己的应用程序和配置文件制成亚马逊机器镜像文件AMI，Amazon machine Image，然后复制到EC2实例，EC2实例是弹性伸缩的组；数据存到EBS，要加备份的话可以存到S3
EC2本地存储是实例自带的磁盘空间，不是持久化的，下面情况会清空：本地磁盘里的相关服务已不用了；服务故障；
为了解决本地存储不可靠的问题，必须用EBS；
EBS通过卷来组织数据，每个EBS卷只能挂在到一个EC2实例
EBS卷不是与实例绑定而是与账号绑定
SimpleDB：AWS上第一个NoSQL数据库服务，键值数据库，性能不是很好，现在很少用了，支持数据多副本存储，支持高并发读取，比较适合小型的碎片化的零散数据
由于它涉及上的很多缺陷它有很多限制，明显限制是单表限制，每个域最多存储10G，没办法满足大规模数据存储需求，
性能不稳定,可以辅助索引，更新操作由于索引开销更大，
它采用最终一致性，更新操作只能针对主副本进行，但可以快速传播到其他副本，也没有办法满足一些用户需求
DynamoDB：因为SimpleDB这么多缺陷，亚马逊推出另外的产品DynamoDB，
吸收优点并改进，尤其提供一致性读功能，而不是最终一致性
根据主键去操作记录不允许进行批量更新，不是SimpleDB那样可以设置多列所以降低性能，这个时候它可以取得更好的性能
全部采用固态盘进行存储
RDS：关系数据服务，目前支持MySQL，Oracle，SQL Server，PG，MariaDB，Aurora，其中Aurora是最近几年推出来的
RDS建立3T数据，带3万个DB实例
6.5 微软云数据库SQL Azure
针对行组实现事务，分区，但是不支持跨分区事务，跨了行组事务就不支持了
每个分区都是冗余副本，一般是3，一个主副本2个从副本
通常一个数据库被分散存到3-5个实例中
6.6 云数据库实践
阿里云RDS：安全稳定、数据可靠、自动备份、管理透明
RDS实例是用户购买的基本单位
7 MapReduce
7.1 概述
MapReduce是一种分布式并行编程框架
摩尔定律05年后逐渐失效，因为cpu制作工艺是有上限天花板的，单位面积能够集成的晶体管数量实际上有上限，集成到一定程度后，布线过密会导致互相之间收到热效应磁场效应干扰，cpu不再像以前一样每18月性能翻倍
虽然cpu摩尔定律失效，但是数据增长却依然遵循摩尔定律，所以一个增长一个停止增长，所以在数据处理计算能力方面的矛盾实际上就很突出，业界学术界都开始寻求其他方式提升数据处理能力，有两条路线：一种是单核cpu到双核到四核到8核，另外一种就是分布式并行编程
Hadoop MapReduce对谷歌的MapReduce做了开源实现，并优化
实际上谷歌MapReduce之前也有其他的并行编程框架，比如MPI，消息传递接口，一种非常典型的并行编程框架，再比如OpenCL或者CUDA
MapReduce模型把整个系统复杂的计算任务高度抽象为两个函数Map和Reduce，屏蔽所有底层细节，极大降低分布式编程难度
策略：分而治之
理念：计算向数据靠拢而不是数据向计算靠拢
架构上 采用Master/Slave架构
7.2 MapReduce体系结构
client：通过客户端提交用户程序给JobTracker；客户端也可以通过它提供的一些接口查看作业运行状态
JobTracker作业跟踪器：负责资源的监控和作业的调度；监控底层其他的TaskTracker以及当前运行的Job的健康状况；一旦探测到失败就把这个任务转移到其他节点继续执行；它还会跟踪作业执行进度和资源使用量，它会把这些信息发送给任务调度器Task Scheduler，Task Scheduler负责具体任务调度，是个可插拔模块，就是允许用户自己编写调度模块，就是采用自己的任务调度策略去实现
TaskTracker：执行具体任务，一般接受JobTracker的命令；把自己的资源使用情况以及任务的执行进度通过心跳方式heartbeat发送给JobTracker
在MapReduce设计中，TaskTracker以槽的概念slot，slot是一种资源调度的单位，把整个机器上面所有cpu内存资源打包，然后等分为很多slot，slot分为两种，一种是map类型的slot，就是专门给map任务用的slot，一种是reduce类型的slot，就是专门给reduce任务用的slot，两种slot是不通用的，这个不通用性也是设计缺陷，这个缺陷在hadoop2.0中有修复
Task任务：一种是map任务，专门执行map函数，另外一种是reduce任务，专门执行reduce函数
7.3 MapReduce工作流程
大概流程：在hdfs中数据集是各种分片split，为每个split单独启动一个map任务，这些map任务输入是很多key和value，输出也是很多key和value，然后map的结果分成很多区发送到不同的reduce上后续处理，分多少区一般取决于reduce机器，这个把map输出结果进行排序归并合并，这个过程叫做shuffle，这个中间包含数据分发的过程，最后reduce处理后保存到hdfs中
不同的map任务是不会互相通信的，不同的reduce任务之间也不会发生信息交换，用户也不能显式的从一台机器发送消息给另外机器，所有的都是由MapReduce框架自身实现的，不需要用户参与，大大降低应用程序开发难度
假设就2个节点，来分析下MapReduce各个阶段
注意InputFormat模块的Split是逻辑的，并不是实际物理上分片
RR：Record Reader 记录阅读器，根据分片的长度信息起始位置去底层HDFS找到各个块，并读出来为Key value形式
map由用户自己编写
shuffle洗牌：分区 排序 归并 合并，之后才能发给相对应的reduce处理
reduce也是由用户编写的 完成分析
OutFormat模块对输出检查并写入到HDFS
逻辑分片不是越大越好或越小越好，肯定有个理想值，越小，导致启动map任务过多，map任务切换等等都会占用过多管理资源导致效率低下，如果分片过小也会影响并行度，一般实际应用中用一个块的大小作为一个split大小64M或者128M
map数量就是分片数量决定
最优的reduce任务个数取决于集群可用的reduce slot数量，但是一般略少些，可以预留些给可能发生的错误
7.4 shuffle过程原理
shuffle过程是理解MapReduce过程的核心
map结果先写到缓存，缓存满的时候发生溢写，溢写中有分区、排序和可能发生的合并操作之后保存到磁盘文件，溢写是多次，生成多个磁盘文件，多个磁盘文件要归并为大的磁盘文件，那么这个磁盘文件就是包含键值对，而且是分区排序后的，然后通知相关的reduce任务取走
reduce从不同的map机器上找到对应分区的数据拉过来，归并合并得到键值对列表给reduce函数处理
完整的shuffle包含map端的shuffle和reduce端的shuffle
map端的shuffle过程
map缓存一般是100M，如果满了再去溢写，溢写过程会影响后续map，所以不能等满了才溢写，要设置溢写比，再没满的时候就开始溢写，一般是0.8
溢写要分区排序和可能的合并操作，分区默认是哈希函数，也可以用户自定义，排序是默认操作不用用户干预，排序后做可能发生的操作合并combine，和后面的归并merge是不同的，合并是为了减少溢写到磁盘的数据量，合并是啥呢，比如2个(a,1)键值对合并为(a,2),很显然这种合并操作就能减少很多的键值对，合并操作不是必须的，如果是用户定义了合并操作，这个时候会启动，如果用户没定义就不启动，但是用户不能乱定义，注意要保证用了combine函数不能改变最终结果
生成多个溢写文件，在整个map任务结束前，系统会自动对它们进行归并merge，归并为大的文件放到本地磁盘，大的文件里面的键值对都是分区的而且是排序的，当等待归并的文件很多的时候就可以启动归并了，一般可以实现设置一个门槛值，默认是3，大于3时候还可以执行combine操作，但是小于3的时候combine不会启动，因为数量很小不值得，combine也是要耗费资源，JobTracker会跟踪任务，一旦探测map结束就会通知reduce任务拉走属于它的分区数据去处理，完成map端shuffle过程
reduce端的shuffle过程
reduce任务也会向JobTracker询问我要的数据是否可以拿了，map结束后JobTracker探测到就通知reduce，reduce任务到相依的map机器上把数据拉倒本机，再归并合并，如果map没有combine结果是（key,value-list)，如果合并了就是(a,2)形式，拉来数据后可以合并combine操作，最终溢写到磁盘的文件还需要归并为一个文件，也可能不是一个大的文件，比如50个磁盘文件，每次归并10个，那就得到5个大的文件，这5个就不会再归并，这是数量比较大的时候，如果数量很少，缓存就够了，就不发生磁盘溢写，直接在缓存中归并操作，然后给reduce函数处理，完成reduce端shuffle过程
7.5 MapReduce应用程序执行过程
大概分为6个过程
程序部署：把执行的用户程序逻辑分发到各个机器
选出一部分worker作为map机器，选出另外一部分worker作为reduce机器，
读数据，键值对，map机器选出部分空闲机器执行分片，然后给map机器执行，结果给缓存
本地写数据，map端shuffle
远端读数据，reduce端shuffle
写数据，输出保存到hdfs
5个阶段：输入文件、Map阶段、中间文件（位于本地磁盘）、Reduce阶段、输出文件
输入输出都是HDFS，但是中间数据不是HDFS，就是磁盘
7.6 实例分析：WordCount
词频统计
首先看是否能用MapReduce，只有满足分而治之的策略和数据集可以，并行执行彼此不会依赖对方
如有combine
7.7 MapReduce具体应用
关系代数运算：（选择、投影、并、交、差、连接）、矩阵运算、矩阵乘法、分组聚合运算
用MapReduce实现关系的自然连接
7.8 MapReduce编程实践
hadoop执行MapReduce任务的方式： hadoop jar；Pig；Hive；Python；SHell
8 数据仓库Hive
8.1 概述
OLAP分析：多维数据分析
8.2 Hive简介
传统的数据仓库即是负责存储也负责分析
Hive本身不支持存储也不支持分析，它只相当于给了用户一个编程接口，一个编程的语言，让用户通过类sql语言HiveQL去编写分析需求，
它是架构在Hadoop核心组件HDFS和MapReduce之上的
Hive两个特性：采用批处理方式处理海量数据；Hive提供了一系列ETL工具；
Pig类似Hive，但是区别是它是轻量级的，做实时轻量级分析而不是大规模海量数据的批处理，Pig主要用于数据仓库的ETL环节
HBase是可以支持实时交互式查询的数据库，弥补HDFS只能追加不能修改，不支持随机读写的缺陷
Mahout，很多机器学习算法，Mahout都帮你实现了，你自己不用编写基础算法代码了，能够帮助企业分析人员快速构建BI应用
Facebook是Hive数据仓库的开发者,开源贡献给Apache
Hive对外访问接口：CLI，一种命令行工具；HWI，Hive Web Interface，是hive的web接口；JDBC和ODBC；Thrift Server，基于THrift架构开发的接口，允许外界通过这个接口实现对Hive的RPC调用
驱动模块Driver：包含编译器，优化器，执行器，负责把用户输入的HQL转换为MapReduce作业
元数据存储模块Metastore：就是来存储元数据的，是一个独立的关系数据库，这个关系数据库可以是hive自带的derby，也可以是其他数据库比如MySQL
Karmasphere、Hue、Qubole等都能访问Hive，尤其是Qubole提供了一种数据仓库即服务的功能，可以通过Quble的方式把数据仓库部署到AWS云计算平台上，直接以服务的方式提供给你，你企业本身不需部署
Hive HA基本原理：Hive很多时候表现不稳定，HA来解决，用多个Hive实例构建资源池，把资源池通过HAProxy提供给用户
8.3 HQL转换MapReduce的工作原理
连接操作在前章已经讲过了如何用MapReduce实现
当启动MapReduce程序时，Hive本身是不会生成MapReduce程序的
需要通过一个标识“Job执行计划”的xml文件驱动执行内置的、原生的Mapper模块和Reducer模块
Hive也不用和JobTracker部署在同一节点，这要互相可以通信就可以初始化MapReduce任务
通常在大型集群，会有专门的网关机来部署Hive
8.4 Impala
类似Hive的数据分析，性能高3-30倍，是帮你实时交互性查询功能
Impala是Cloudera开发新型查询系统，可以支持PB级数据，数据可以存在HDFS或HBase，都可以通过Impala查询
Impala运行依赖于Hive元数据，Impala不是独立运行的
Impala最初设计是参考谷歌公司的Dremel系统并做了很多改进
Impala采用了与商业并行关系数据库类似的分布式查询引擎，可以直接与HDFS和HBase进行交互查询
虚线部分是Impala组件，但是Impala不是单独部署的，实线部分是其他的组件HDFS HBase Hive
Impala主要3个组件：
Impalad负责查询任务：三个模块，Query Planner查询计划器、Query Coordinator查询协调器、Query Exec Engine查询执行引擎；任务是负责协调客户端提交的查询请求的执行；与HDFS ND运行在同一节点，大数据分析一定要遵循计算向数据靠拢，所以肯定是注入到数据节点上就近分析数据；给其他Impalad分配任务以及收集其他Impalad的执行结果汇总；Impalad也会执行其他Impalad分配的任务对本地hdfs和hbase里面的数据进行操作；
State Store负责维护元信息和状态信息：每个查询提交，系统会创建个Statestored进程，来跟踪各个节点执行进度以及健康状况；负责收集分布在集群各个Impalad进程的资源信息用于查询调度
CLI命令行接口，同时也提供其他接口包括Hue、JDBC及ODBC
Impala的元数据是直接存储在Hive中的，它借助Hive来存储Impala的元数据
Impala采用和Hive采用相同元数据、SQL语法，ODBS驱动和用户接口
在一个Hadoop平台上可以统一部署Hive和Impala等分析工具，实现在一个平台上可以同时满足批处理和实时查询
Impala查询执行过程
00 当用户提交查询前，Impala先创建一个负责协调客户端提交查询的Impalad进程，该进程会向Impala State Store提交注册订阅信息，State Store会创建一个statestored进程，statestored进程通过创建多个线程来处理Impalad的注册订阅信息
01 用户通过CLI客户端提交查询到Impalad进程，Impalad的Query Planner对SQL语句解析，生成解析树，Planner把这个查询的解析树编程若干PlanFragment，发送到Query Coordinator
02 Query Coordinator查询MySQL元数据库中获取元数据，从HDFS的名称节点中获取数据地址，以得到存储这个查询相关数据的所有数据节点
03 Coordinator初始化相应Impalad上的任务执行，即把查询任务分配给所有存储这个查询相关数据的数据节点
04 Query Executor通过流式交换中间输出，并由Query Coordinator汇聚来自各个impalad的结果
05 Coordinator把汇总后的结果返回给CLI客户端
Impala和Hive比较
1. Hive适合长时间的批处理查询分析，而Impala适合实时交互式SQL查询
2. Hive依赖MapReduce计算框架，Impala把执行计划表现为一颗完整的执行计划树，直接分发执行计划到各个Impalad执行查询
3. Hive执行时候如果内存放不下数据就使用外存，以保证查询能顺序执行完成；Impala在遇到内存放不下数据时，不会利用外存所以impala目前处理查询会受到一定限制
1.Hive和Impala使用相同的存储池，都支持把数据存在HDFS和HBase中
2.Hive和Impala都使用相同元数据
3.Hive和Impala对sql的解释处理比较类似，都是通过词法分析生成执行计划
总结下， Impala的目的不是替换现有的MapReduce工具，实际生产中，可以组合使用，用hive来处理数据，处理结果用impala查询
8.5 Hive编程实践
hadoop安装好了之后就有了HDFS和MapReduce，此外Hive Hbase等等都要额外安装
然后针对单机模式、伪分布式、分布式模式不同配置hive即可，修改hive-site.xml实现，如果不存在，可以参考$HIVE_HOME/conf目录下的hive-default.xml.template创建
用HQL完成wordcount
9 Hadoop再探讨
9.1 Hadoop的优化和发展
Hadoop刚推出的时候的局限和不足：
抽象层次低，需人工编码
表达能力有限
开发者自己管理job间的依赖关系
难以看到程序的整体逻辑
执行迭代操作效率低
资源比较浪费
实时性差
之后业界学界进行改进，
一方面，两大核心组件的架构设计改进，演进为MapReduce2.0和HDFS2.0
另一方面，不断丰富Hadoop生态系统，包括Pig、Tez、Spark和Kafka等
9.2 HDFS2.0的新特性
HDFS HA 解决单点故障
HDFS Federation 解决3个问题：水平扩展问题，系统整体性能受限于单个名称节点的吞吐量，难以资源隔离
多个名称节点之间互相独立，且向后兼容，单名称节点的架构可以无缝迁移过来，共享块池，构建全局命名空间，一般采用客户端挂在表的方式对各个命名空间相关数据进行共享和访问，通过访问不同的挂载点访问不同的子命名空间
9.3 新一代资源管理器YARN
MapReduce1.0缺陷：
存在单点故障：只有一个JobTracker负责整个作业的调度、管理、监控
JobTracker“大包大揽”导致任务过重
容易出现内存溢出：MapReduce1.0在分配资源的时候只考虑MapReduce任务数，而不考虑内存cpu等资源，就是按照人头划分，不管高矮胖瘦，一旦有个很耗内存的任务，马上导致内存溢出
资源划分不合理：把cpu内存打包强行划分slot再划分2部分为map slot和reduce slot，两种slot不通用，导致资源浪费
YARN设计思路：
MapReduce1.0即是计算框架也是资源管理调度框架
Hadoop2.0以后把MapReduce1.0中资源调度的部分单独抽离出来形成YARN
YARN是一个纯粹的资源管理调度框架
被剥离资源管理调度功能的MapReduce框架成为MapReduce2.0，它是运行在YARN之上的纯粹的计算框架，不再负责资源调度
YARN体系结构
ResourceManager：处理客户端请求；启动/监控ApplicationMaster；监控NodeManager；资源分配和调度
ApplicationMaster：为应用程序申请资源，并分配给内部任务；任务调度、监控与容错
NodeManager：单个节点上的资源管理；处理来自ResourceManager的命令；处理来自ApplicationMaster的命令
ResourceManager（RM）：是一个全局的资源管理器，负责整个系统的资源管理和分配，主要包含两个组件，即调度器（Scheduler）和应用程序管理器（Applications Manager）
调度器接收来自ApplicationMaster的应用程序资源请求，把集群中的资源以“容器”的形式分配给提出申请的应用程序，容器的选择通常会考虑应用程序所要处理数据的位置，进行就近选择实现“计算向数据靠拢”
容器（Container）作为动态资源分配单位，每个容器中都封装了一定数量的cpu内存磁盘等资源，从而限定每个应用程序可以使用的资源量
调度器被设计成是一个可插拔的组件，YARN不仅自身提供了很多直接可用的调度器，也允许用户自定义调度器
应用程序管理器负责系统中所有应用程序的管理工作，主要包括应用程序提交、与调度器协商资源以启动ApplicationMaster、监控ApplicationMaster运行状态并在失败时重新启动等
ApplicationMaster：ResourceManager接收用户提交的作业，按照作业的上下文信息及从NodeManager收集来的容器状态信息，启动调度过程，为用户作业启动一个ApplicationMaster， ApplicationMaster也是运行在容器当中的
当用户作业提交时，ApplicationMaster和ResourceManager协商获取资源，ResourceManager会以容器的形式为ApplicationMaster分配资源
把获得的资源二次分配给内部的各个任务（Map或Reduce任务）
与NodeManager保持交互通信，进行应用程序的启动、运行、监控或停止，监控申请到的资源使用情况，对所有任务的执行进度和状态进行监控，并在任务发生失败时执行失败恢复即重新申请资源重启任务
定时与ResourceManager发送心跳信息，报告资源的使用情况和应用的进度信息
当作业完成时，ApplicationMaster向ResourceManager注销容器执行周期完成
NodeManager：是驻留在一个YARN集群中的每个节点上的代理，主要负责如下工作：
容器生命周期管理
监控每个容器资源使用情况
以心跳方式向ResourceManager保持通信
向ResourceManager汇报作业的资源使用情况和每个容器的运行状态
跟踪节点健康状况
接收来自ApplicationMaster的启动/停止容器的各种请求
NodeManager主要负责管理抽象的容器，只处理与容器相关的事情，不具体负责每个任务（Map任务、Reduce任务或其他计算框架的任务）自身状态的管理，因为这些工作由ApplicationMaster完成的，ApplicationMaster会不断与NodeManager通信来掌握各个任务的执行状态
YARN的组件实际上不是独立的，是和Hadoop组件统一部署的
YARN工作流程
1 用户编写客户端应用程序向YARN提交应用程序
2 YARN中的ResourceManager负责接收和处理来自客户端的请求，为应用程序分配一个容器，在该容器中启动一个ApplicationMaster
3 ApplicationMaster被创建后会首先向ResourceManager注册
4 ApplicationMaster采用轮询的方式向ResourceManager申请资源
5 ResourceManager会以“容器”的形式向提出申请的ApplicationMaster分配资源
6 在容器中启动任务（运行环境、脚本）
7 各个任务向ApplicationMaster汇报自己的状态和进度
8 应用程序运行完成后ApplicationMaster向ResourceManager的应用程序管理器注销并关闭自己，释放自己获取到的资源
YARN框架和MapReduce1.0框架比对
从MapReduce1.0框架发展到YARN框架，客户端并没有发生变化，其大部分调用API及接口都保持兼容，因此，原来针对Hadoop1.0开发的代码不用太大改动就可以放到Hadoop2.0上执行
优势：
大大减少了承担中心服务功能ResourceManager的资源消耗
ApplicationMaster来完成需要大量消耗资源的任务调度和监控
多个作业对应多个ApplicationMaster实现了监控分布化
MapReduce1.0既是一个计算框架也是个资源调度框架，但是只支持MapReduce编程模型
YARN是一个纯粹的资源调度框架，在它上面可以运行包括MapReduce在内的不同类型的计算框架，只要编程实现相应的ApplicationMaster，比如可以在YARN上运行Storm框架，为什么YARN可以为不同框架提供资源调度呢，核心是因为ApplicationMaster是可替换模块
YARN的发展目标
要实现一个集群多个框架：在一个YARM框架之上搭建同一个集群，可以同时运行各种计算框架比如MapReduce、Spark、Storm、Tez、Graph等等，由YARN框架为上层框架提供统一的资源调度管理功能，并且根据负载，调整各自占用资源，实现集群资源共享和资源弹性伸缩，实现在一个集群上不同应用负载混搭，有效提高了集群的利用率，不同计算框架可以共享底层存储，避免数据集跨集群移动
为什么：
一个企业当中存在不同的业务应用场景，需要采用不同的计算框架
MapReduce实现离线批处理
用Impala实现实时交互式查询分析
使用Storm框架实现流失数据实时分析
使用Spark实现迭代计算
为了避免不同类型应用之间互相干扰，企业把内部集群切分为多个集群，分别安装不同计算框架，即一个框架一个集群，这样带来新问题，集群资源利用率低数据无法共享维护代价高
10 Spark
10.1 Spark概述
Spark最初由伯克利大学的AMP实验室于2009年开发，是基于内存计算的大数据并行计算框架，可用于构建大型的低延迟的数据分析应用程序
和Hadoop不同，Hadoop是基于磁盘的大数据计算框架，Spark是基于内存的大数据计算框架
2013年Spark加入Apache孵化器项目后发展迅速，如今已成为Apache软件基金会最重要的三大分布式计算系统开源项目之一（Spark、Storm、Hadoop）
Spark的成名之路和Hadoop差不多，2014年时候打破hadoop的基准排序记录，用206个节点花了23分钟100T数据排序，hadoop是2000节点72分钟100TB，Spark用了十分之一的计算资源获得了3倍的速度
Spark特点：
运行速度快：使用DAG执行引擎以支持循环数据流与内存计算，与MapReduce不一样，MapReduce是代用一轮又一轮的迭代方式去执行，而Spark是采用有向无环图DAG的方式
容易使用：支持Java、Scala、Python和R语言，也支持Spark Shell进行交互式编程
通用性：整个Spark作为一个完整的生态系统，它提供了完整而强大的技术软件栈，包括SQL查询、流式计算、机器学习和图算法组件，提供了非常多的软件套装，包括支持内存计算的Spark Core，包括可以完成sql查询的Spark SQL，以及可以完成流式计算的Spark Streaming还有完成机器学习的组件Spark MLib，另外一个是完成图计算的软件GraphX
运行模式多样：可运行于独立的集群模式，可运行于Hadoop中，也可以运行于Amazon EC2等云环境中，并且可以访问HDFS、Cassandra、HBase、Hive等多种数据源
Scala是一门现代的多范式编程语言，平滑的集成面向对象和面向函数式编程这两种风格，,运行于java平台，兼容现有java程序
Scala特性：
Scala具有强大的并发性，支持函数式编程，可以更好的支持分布式系统
Scala语法简洁能够提供优雅的API
Scala兼容Java，运行速度快，且能融合到Hadoop生态圈
Scala是Spark主要编程语言，但Spark还支持Java、Python、R作为编程语言
Scala的优势是提供REPL（Read-Eval-Print-Loop，交互式解释器），提高开发效率
Spark和Hadoop对比
Hadoop缺陷：
表达能力有限
磁盘IO开销大
延迟高
任务之间衔接需要IO开销
在前一个任务执行完成之前，其他任务就无法开始，难以胜任复杂、多阶段的计算任务，尤其是机器学习数据挖掘等需要反复迭代的计算
Spark相比于Hadoop MapReduce的优势：
Spark的计算模式也属于MapReduce，但不局限于Map和Reduce操作，还提供了了多种数据集操作类型，编程模式更加灵活
Spark基于内存计算，将中间结果放入内存，迭代计算效率更高
Spark是基于DAG有向无环图的任务调度执行机制，要由于Hadoop MapReduce的迭代执行机制（Tez框架也是基于DAG）
10.2 Spark生态系统
对3种场景，可以用MapReduce+Impala+Storm满足需求
但是带来问题：
不同场景的输入输出数据无法做到无缝共享，通常需要进行数据格式的转换
不同的软件需要不同的维护团队，使用成本大
难以对同一个集群的各个软件统一资源调度，YARN可以，但是YARN支持计算框架也是有限
Spark设计：遵循“一个软件栈满足不同应用场景”的理念，逐渐形成一套完整的生态系统
Spark可以部署在YARN上，为企业提供一站式的大数据解决方案
Spark生态系统足以应对上述3中场景，即同时支持批处理、交互式查询和流数据处理
Spark生态系统已经成为伯克利技术软件栈BDAS（Berkeley Data Analytics Stack）的重要组成部分
10.2 Spark运行架构
基本概念和架构设计
RDD，Resillient Distributed Dataset,弹性数据集，是分布式内存的一个抽象概念，提供了一种高度受限的共享内存模型。把数据从磁盘读出来后被封装成RDD，然后可以对RDD里面的数据进行分区，RDD里面相关的分析数据可以放到不同的数据节点来并行计算
DAG，Directed Acyclic Graph，有向无环图，反应RDDD之间的依赖关系
Executor，是运行在工作节点（workernode）的一个进程，负责运行task
Application：用户编写的Spark程序
Task：运行在Executor上的工作单元
Job：一个job包含多个RDD以及作用于RDD上面的各种操作
Stage：是job的基本调度单位，一个Job会分为多组Task，每组Task被成为Stage，或者被成为TaskSet，代表了一组关联的，相互之间没有shuffle依赖关系的任务组成的任务集
集群资源管理器可以用它自带的，也可以用Mesos和YARN框架，是Spark最核心的组件
与Hadoop MapReduce相比，Spark采用的executor有2个优点：
利用多线程来执行具体任务减少任务的启动开销
Executor中有一个BlockManager存储模块，会将内存和磁盘视共同作为统一存储设备，有效减少IO开销，如果内存空间足够大的时候，优先写内存，写满后才会溢写到磁盘Spark运行基本流程
01 为应用构建起基本运行环境，即由Driver创建一个SparkContext进行资源申请、任务的分配和监控
02 资源管理器为Executor分配资源，并启动Executor进程
03 SparkContext根据RDD的依赖关系构建DAG图，DAG图提交DAGScheduler解析为Stage，然后把一个个TaskSet提交给底层调度器TaskScheduler处理
Executor向SparkContext申请Task，Task Scheduler将Task发放给Executor运行并提供应用程序代码
04 Task在Executor上运行把执行结果反馈给TaskScheduler，然后反馈给DAGScheduler,运行完毕后写入数据并释放所有资源
Spark运行架构特点：
每个Application都要自己专属的Executor进程，并且该进程在Application运行期间一直驻留。Executor以多线程的方式运行Task
Spark运行过程与资源管理器无关，只要能获取Executor并能保持通信即可
Task采用了数据本地性和推测数据执行等优化机制
RDD概念
设计背景：许多迭代计算（比如机器学习、图计算等）和交互式数据挖掘工具，共同之处是不同计算阶段之间会重用中间结果；目前MapReduce框架都是把中间结果写磁盘，带来大量的数据复制、磁盘io和序列化开销
RDD就是满足这种需求而出现的，它提供了一个抽象的数据结构
我们不必担心底层数据的分布式特性，只需将具体的应用逻辑表达为一系列转换处理
不同RDD之间的转换操作形成依赖，可以实现管道化，避免中间数据存储
一个RDD就是一个分布式对象集合，本质上是一个只读的分区记录集合，每个RDD可分为多个区，每个分区就是一个数据集片段，并且一个RDD的不同分区可以被保存到集群的不同节点上，从而可以在集群中的不同节点间进行并行计算
RDD提供了一种高度受限的共享内存模型，即RDD是只读的记录分区的集合，不能直接修改，只能基于稳定的物理存储中的数据集创建RDD，或者通过在其他RDD上执行确定的转换操作（如map、join和group by）而创建得到新的RDD
RDD提供了一组丰富的常见的数据运算，分为“动作”（Action）和“转换”（Transformation)两种类型
RDD提供的转换接口都非常简单，都是类似map,filter,groupby,join等粗粒度的数据转换操作，而不是针对某个数据项的细粒度修改（不适合网页爬虫）
表面上RDD的功能很受限、不够强大，实际上RDD已经被实践证明可以高效地表达许多框架的编程模型（比如MapReduce、SQL、Pregel）
Spark用Scala语言实现了RDD的API，程序员可以通过调用API实现对RDD的各种操作
这一些列处理成为一个Lineage（血缘关系），即DAG拓扑排序的结果，反应了不同RDD之间相互依赖关系，完全可以实现管道化处理
优点：惰性调用、管道化、避免同步等待、不需要保存中间结果、每次操作变得简单
RDD特性
RDD是整个Spark的核心
Spark采用RDD以后能够实现高效计算的原因：
高效的容错性：
现有容错机制：数据复制或记录日志 代价昂贵
RDD具有天生的容错性：血缘关系、重新计算丢失分区、无需回滚系统、重算过程在不同节点间并行、只记录粗粒度的操作
中间结果持久化到内存，数据在内存中的多个RDD之间传递，避免了不必要的磁盘开销
存放的数据可以是Java对象，避免了不必要的序列化和反序列化开销
RDD的依赖关系和运行过程
RDD之间的依赖关系（宽依赖、窄依赖）是划分Stage的依据
窄依赖：表现为一个或多个父亲RDD的分区对应于一个子RDD的分区
宽依赖：表现为一个父RDD的一个分区对应一个子RDD的多个分区
Spark通过分析各个RDD的依赖关系生成DAG再通过分析各个RDD中分区之间的依赖关系来决定如何划分Stage
具体方法是，在DAG中进行反向解析，遇到宽依赖就断开，宽依赖一般都是存在shuffle的情况，遇到窄依赖就把当前RDD加到stage中，将窄依赖尽量划分在同一个Stage，可以实现流水线计算，从而使得数据可以直接在内存中进行交换，避免磁盘io开销
划分完的stage有2中类型：ShuffleMapStage、ResultStage
ShuffleMapStage，不是最终stage，在它之后还有其他stage，所以他的输出一定需要经过Shuffle过程，并作为后续Stage的输入；这种Stage以Shuffle为输出边界，其输入边界可以从外部获取数据，也可以是另外一个ShuffleMapStage的输出，其输出可以是另一个stage的开始;一个job中可能有也可能没有该类型stage
ResultStage,最终stage，没有输出，而是直接产生结果或者存储，这种stage是直接输出结果，其输入边界可以是从外部获取数据也可以是另一个ShuffleMapStage；每个job必定至少含有一个这个类型stage
RDD运行过程：首先第一步是创建RDD对象，从数据源去读取相关数据生成RDD对象；SparkContext负责计算RDD之间的依赖关系，构建DAG;DAGScheduler负责把DAG图分解成多个Stage，每个Stage中包含了多个Task，每个Task会被TaskScheduler分发给各个WorkderNode上的Executor去执行
10.4 Spark SQL
Shark即Hive on Spark，为了实现和Hive兼容，Shark在HiveQL方面重用了Hive中HiveQL的解析、逻辑执行计划翻译、执行计划优化等逻辑，可以近似认为仅将物理执行计划从MapReduce作业替换为Spark作业，通过Hive的HiveQL解析，把HiveQL翻译成Spark上的RDD操作
为了兼容hive，导致问题：执行计划完全依赖于hive，不方便添加新的优化策略；因为Spark是线程级并行，而Hive是进程级并行，因此Spark在兼容Hive的实现上存在线程安全问题，导致Shark不得不用另外一套独立维护的打了补丁的Hive源码分支
所以放弃Shark转而Spark SQL
Spark SQL基本上继承了Shark的功能并做了相当多的改进，Spark SQl在Hive兼容层面仅依赖HiveQL解析、Hive元数据，也就是，从HQL被解析成抽象语法树（AST）起，就全部由Spark SQL接管了。Spark SQL执行计划生成和优化都由Gatalyst（函数式关系查询优化框架）负责
Spark SQL增加了SchemaRDD（即带有Schema信息的RDD）使用户可以在Spark SQL中执行SQL语句 SchemaRDD允许封装更多数据源数据，可以RDD、Hive、HDFS、Cassandra、JSON 数据类型更多，可以完成更强大的分析功能
备注：SchemaRDD在后来的Spark SQL演化为DataFrame；
10.5 Spark的部署和应用方式
Spark三种部署方式：Standalone 类似MapReduce1.0，自带资源管理框架，slot为资源分配单位，不同的是不区分map slot和reduce slot；Spark on Mesos，Mesos和Spark有一定亲缘关系；Spark on YARN
之前很多企业是采用Hadoop+storm部署的，这种部署比较繁琐用Spark架构的
注意，这种部署的架构，Spark Streaming无法实现毫秒级的流计算,只是秒级，因此，对于需要毫秒级实时响应的企业应用而言，仍需要采用专业流计算框架如Storm
最后就是混合部署，由于Hadoop生态中一些组件所实现的功能，Spark无法替代，比如Storm；而且现有企业很多基于Hadoop开发，完全转移到Spark上需要一定成本
不同框架统一部署在YARN上，可以实现资源按需伸缩；不同负载应用混搭，集群利用率高，可以削峰填谷；共享数据存储，避免数据跨集群迁移
10.6 Spark编程实践
Spark的安装和启动
Spark需要java环境和hadoop环境，然后进入官网下载，解压下来设置环境变量就好了
运行模式：单机模式、伪分布式、分布式
Spark Shell仅支持Scala、Python两种
在Spark程序中必须创建个SparkContext对象，该对象是Spark程序的入口，负责创建RDD、启动任务等，但是在SparkShell中，默认是自动创建了，可以通过sc变量进行访问在一条代码中同时使用多个API，连续进行计算，称为链式操作，不仅可以使Spark代码更加简洁，也优化了计算过程
Spark应用程序
对代码打包调试运行，支持Scala、python、R、Java，不同工具打包不一样
11 流计算
11.1 流计算概述
静态数据 ：数据仓库的数据就是典型的静态数据
流数据：近年来，在web应用、网络监控、传感检测等领域，兴起了一种新的数据密集型应用-流数据，即数据以大量、快速、时变的流形式持续到达
比如PM2.5检测、电子商务网站用户点击流，这些数据必须要马上立刻实时分析才能够捕获它的商业价值，要迅速的给出相关的分析结果，这两种类型都是非常典型的流式数据产生方式，都是实时产生，数据像流水一样实时不断的到达，叫做流式数据，简称流数据
流数据特征：
数据快速持续到达，潜在大小也许是无穷尽的
数据来源众多，格式复杂
数据量大，但是不十分关注存储，一旦被处理，要么被丢弃，要么被归档存储
注重数据整体价值，不过分关注个别数据
数据顺序颠倒，或者不完整，系统无法控制将要处理的新到达的数据元素的顺序
流计算概念以及典型框架
流计算：实时获取不同数据源的海量数据经过实时分析处理，获得有价值的信息
流计算基本理念：数据的价值随着时间的流逝而降低，如用户点击流；因此，当事件出现就应该立即进行处理，而不是缓存起来进行批量处理；就需要一个低延迟、可扩展、高可靠的处理引擎，被成为流计算系统
流计算系统要求：高性能、海量式、实时性、分布式、易用性、可靠性
业界为满足需求开发的框架分为三类：
商业级：IBM InfoSphere Streams；IBM StreamBase；
开源框架：Twitter Storm；Yahoo！S4（Simple Scalable Streaming System）；Samza；Spark Streaming
公司为支持自身业务开发的流计算框架：Facebook、百度、淘宝
11.2 流计算处理流程
开源分布式日志采集系统：facebook scribe；领英 kafka；hadoop flume；hadoop chukwa
11.3 流计算的应用
11.4 开源流计算框架Storm
开源框架Storm
Storm是推特公司开发的一个框架，是开源免费的
Storm对于实时计算的意义，就相当于hadoop对于批处理的意义
可以简单高效可靠的处理流数据，支持多种编程语言，处理非常灵活
可以非常方便的和现有的数据库产品还要一些队列产品进行融合，从而开发出非常强大的流计算系统
推特公司分层数据处理架构采用Storm和Hadoop结合，实时部分借助Storm和Cassandra，批处理部分借助hadoop和ElephantDB，对实时处理结果和批处理结果进行了无缝的融合
storm应用领域非常多包括：实时分析、在线机器学习、持续计算、远程RPC、数据提取、转换加载等等
特点： 整合性、简易API、可扩展、可靠消息处理、支持各种编程语言、快速部署、免费开源
Storm设计思想
Storm主要术语：
还没有全文机构定义，不翻译
tuple是一堆值，每个值有一个名字，并且每个值可以是任意类型
tuple本来应该是Key-Value的Map，由于各个组件间传递的tuple的字段名称已经事先定义好了，所以tuple只需要按序填入各个value，所以就是个value list
Spout：Storm认为每个Stream都有一个源头，并把这个源头抽象为Spout，中文是自来水龙头
通常Spout会从外部数据源（队列、数据库等）读数据，然后封装为Tuple形式，发送到Stream中
Spout是一个主动角色，在接口内有个nextTuple函数，Storm框架会不停的调用该函数Bolt是一个被动角色，其接口有一个execute（tuple input）方法，在接收到消息之后就会调用该函数，用户可以在此方法中执行自己的处理逻辑
Topology相当于MapReduce的job，包含用户的处理逻辑，Topology里面每个组件都是并行运行的
Storm运行方式与hadoop类似，hadoop运行的是MapReduce作业，而storm运行的是Topology
不同的是mapreduce处理完就结束，topology是持续不断处理除非人工结束
Storm集群采用“Master-Worker”的节点方式，Master节点运行名为Nimbus的后台程序负责在集群范围内分发代码、为Worker分配任务和监测故障，Worker节点运行名为Supervisor的后台程序，负责监听分配给它所在机器的工作，即根据Nimbus分配的任务来决定启动或停止worker进程，一个worker节点上运行多个worker进程
中间加入zookeeper是为了保证高可用和快速故障恢复，借助zookeeper，使得Nimbus进程或者Supervisor进程意外终止，重启也能读取、恢复之前的状态并继续工作，使得storm极其稳定
每个worker进程都属于一个特定Topology，每个Supervisor节点的worker可以是多个，每个worker对Topology中的每个组件（Spout或Bolt）运行一个或者多个executor线程来提供task的运行服务
实际的数据处理由task完成
所有的Topology任务的提交必须在storm客户端节点上进行，提交后，由Nimbus节点分配给其他Supervisor节点进行处理
Nimbus节点首先将提交的Topology进行分片，分成一个个task，分配给相应的Supervisor，并将Task和Supervisor相关信息提交给zookeeper集群
Supervisor会去zookeeper集群上认领自己的task，通知自己的worker进程进行tak的处理
11.5 Spark Streaming、Samza以及三种流计算框架的比较
Spark是面向批处理的实时计算框架，基于内存的计算，实时性好
如何将面向批处理的框架来处理流数据？基本原理是将实时数据流以时间片（秒级）为单位进行拆分，然后经spark引擎以类似批处理的方式处理每个时间片数据
Spark Streaming可以整合多种数据源如Kafka、Flume、HDFS、甚至是普通的TCP套接字经过处理后的数据可存储至文件系统、数据库，或显示在仪表盘里
Spark Streaming是把数据流抽象为DStream（Discretized Stream，离散化数据流），表示连续不断的数据流，每段数据流转换为RDD处理，对Dstream的操作最终都转变为RDD的操作
Spark Streaming VS Storm
Spark Streaming无法实现毫秒级流计算
相比于Storm，RDD数据集更容易做搞笑的容错处理
Spark Streaming采用的小批量处理的方式使得它可以同时兼容批量和实时数据处理的逻辑和算法，因此，方便了一些需要历史数据和实时数据联合分析的特定应用场合
Samza：一个作业（job）是对一组输入流进行处理转换为输出流的程序；分区，它既不是Tuple也不是Dstream而是一条条消息；任务，一个作业会被进一步分割成多个任务（Task）来执行，其中，每个任务处理作业中的一个分区，分区之间没有定义顺序，从而允许每个任务独立运行；YARN调度器负责把任务分发给各个机器，最终，一个工作中的多个任务会被分发到各个机器进行分布式并行处理
数据流图
Samza架构：
流数据层：负责数据流的收集分发，流处理层和执行层都被设计为可插拔的，开发人员可以使用其他框架代替YARN和Kafka
执行层
处理层
处理分析过程
Samza客户端需要执行一个Samza作业时，它会向YARN的ResouceManager提交作业请求
ResourceManager通过与NodeManager沟通为该作业分配容器来运行Samza ApplicationMaster
Samza ApplicationMaster进一步向ResouceManager申请运行任务的容器
获得容器后，Samza ApplicationMaster与容器所在的NodeManager沟通启动该容器并运行samza task runner
samza task runner负责执行具体的samza任务，完成流数据处理分析
Stom、Spark Streaming和Samza
编程灵活性来讲Storm是比较灵活的选择
当需要在一个集群中把流计算、图计算、机器学习、SQL查询分析等进行结合时候选用Spark Streaming
当有大量的状态需要处理时，比如每个分区都有数十亿个元组，则可以选择Samza
11.6 Storm编程实践
storm需要的环境：ceontos、storm、jdk1.7、zookeeper、python
安装过程：安装JAVA、安装zookeeper、安装storm、关闭storm
具体过程略
12 图计算
12.1 图计算简介
图计算是专门针对图结构的数据的处理：
现实世界中，许多大数据都是以大规模图或网络的形式呈现，比如社交网络数据、传染病传播途径、交通事故对路况影响
许多非图的大数据，也常常被转换为图模型后进行分析
图数据结构能非常好的表达数据之间的关联性
关联性计算是大数据计算的核心–通过获得数据的关联性，可以从噪音很多的海量数据中抽取有用的信息
典型应用，相似用户商品推荐、热门话题追根溯源
传统图计算算法存在的典型问题：
常常表现出非常差的内存访问局限性
针对单个顶点的处理工作过少
计算过程伴随者并行度的改变
针对这些问题，后来专门开发的软件就可以解决：
为特定的图应用定制相应的分布式实现，但是通用性不好
基于现有的分布式计算平台进行图计算，比如mapreduce这种针对批处理的用来进行图计算，性能和易用性都没法达到最优，这种单输入两阶段粗粒度的计算框架面对图结构力不从心，图计算特征是多次迭代稀疏结构和细粒度数据
使用单机的图算法库BGL、LEAD、NetworkX、JDSL、Standford GraphBase和FGL等，但是这些都是单机的，面对大规模计算问题表现出局限性
使用已有的并行图计算系统，比如，Parallel BGL和CGM Graph，实现了很多并行图算法，但是这些在有些机制方面并没有完善的设计，比如尤其是没有很好的容错
正因为如此才诞生图计算通用软件 ：
基于遍历算法的、实时的图数据库，比如Neo4j、OrientDB、DEX、Infinite Graph
以图顶点为中心的、基于消息传递批处理的并行引擎，比如GoldenOrb、Giraph、Pregel、Hama
BSP（Bulk Synchronous Parallel Computing Model）模型叫整体同步并行计算模型或者简称为大同步模型，通过网络连接起来的处理器，一系列的全局超步
三个组件：
局部计算，每个处理器只读取本地内存中的值，各个处理器之间都是异步并行执行
通讯，不同的处理器计算完成之后需要通过消息的方式交换数据，为了更好的完成下次迭代计算，put操作get操作
栅栏同步，处理器计算有快慢，设置路障类似的，等待所有执行完毕才执行下次迭代
12.2 Pregel简介
Pregel是谷歌公司发布的一款商业图计算产品
发布Pregel之前，03 04年谷歌发布了GFS、MapReduce、BigTable，hadoop都是对这三个的开源实现，这三个产品成为云计算和大数据的基石
谷歌在后hadoop时代的新“三驾马车”，Caffeine、Dremel、Pregel，Caffeine帮助谷歌快速实现大规模网页索引的构建，Dremel，实时的交互式分析产品，采用只读嵌套型的独特数据结构，支持PB级别的数据分析只要2到3秒钟响应，Pregel，基于BSP模型实现的并行图处系统
12.3 Pregel图计算模型
01 Pregel计算模型以有向图作为输入
02 有向图的每个顶点都有一个String类型的顶点ID
03 每个顶点都有一个可修改的用户自定义值与之关联
04 每条有向边都和其源顶点关联，并记录了其目标顶点id
05 边上有一个用户可修改的自定义值与之关联
在每个超步S中，图中的所有顶点都会并行执行相同的用户自定义函数
每个顶点可以接收前一个超步（S-1）中发送给它的消息，修改其自身及射边的状态，并发送消息给其他顶点，甚至是修改整个图的拓扑结构
边并不是核心对象，在边上不会运行相应的计算，只有顶点才会执行用户自定义函数进行相应计算
传递消息的基本方法：远程读取、共享内存
而Pregel都没有采用，而是采用消息传递模型，原因：
消息传递有足够的表达能力
有助于提升系统整体性能，Pregel不需要远程读取，避免远程读取带来的高延迟，消息传递是异步批量的方式，而共享内存方式高耦合制约扩展性
Pregel计算过程：
01 Pregel的计算过程是由被成为“超步”的迭代组成的
02 在每个超步中，每个顶点都会并行执行用户自定义函数
在Pregel计算过程中，一个算法什么时候结束是由所有顶点状态决定
在第0个超步，所有顶点活跃
一个顶点不需要继续执行进一步计算时就会把自己的状态设置为“停机”
Pregel计算框架必须根据条件判断来决定是否将其显式唤醒进入活跃状态
Pregel实例
12.4 Pregel的C++ API
Pregel已经预先定义好了一个基类–Vertex类
在Vertex类中，定义了三个值类型参数，分别表示顶点、边和消息。每个顶点都有一个给定类型的值与之对应
编写Pregel程序时候，compute是虚函数，要用户自己定义处理逻辑
消息传递机制和Compiler
Pregel的消息传递机制：顶点之间的通讯是借助于消息传递机制来实现的，每条消息都包含消息值和需要到达的目标顶点id，注意目标顶点不一定是相连的，有可能经过多个边才到达
在某个超步S中，一个顶点可以发送任意数量的消息，这些消息将在下个超步S+1中被其他顶点接收
Combiner：Pregel计算框架在消息发出去之前，Combiner可以将发送到同一个顶点的多个消息合并，大大减少了传输和缓存的开销
默认情况下是不开启Combiner的
只有在对计算结果无影响的情况下才能启用Combiner，并不适用所有场景
当用户打算开启Combiner时候，可以继承Combiner类并覆写虚函数Combine()
通常只对那些满足交换律和结合律的操作才可以开启Combiner
Aggregator：提供了一种全局通信监控和数据查看的机制
在一个超步S中，每个顶点都可以向Aggregator发送一个数据，Pregel计算框架会对这些值进行聚合操作产生一个值，在下一个超步(S+1)中每个顶点都可以看到这个值
拓扑改变：
对全局拓扑改变，Pregel采用了惰性协调机制
对于本地的局部拓扑改变，是不会引发冲突的，顶点或边的本地增减能够立即生效，很大程度上简化了分布式编程
输入输出都是灵活多变的
12.5 Pregel的体系结构
执行过程：在Pregel计算框架中，一个大型图会被划分成多个分区，每个分区都包含一部分顶点以及其为起点的边，即子图；一个顶点应该被分配到哪个分区上，是由一个函数决定的，系统默认是hash(D) mod N其中N为所有分区总数，id是顶点标识符，当然用户也可以改写不用哈希函数，采用固定分区函数后，可以根据顶点id快速判断顶点属于哪个分区
01 选择集群中的多台机器执行图计算任务，有一台机器会被选为Master其他机器作为Workder
02 Master会把一个图分成多个区，并把分区分配到多个Worker。一个Worker会领到一个或多个分区，每个worker知道所有其他worker所分配到的分区情况
03 Master会把用户输入划分成多个部分，然后，Master会为每个Worker分配用户输入的一部分。如果一个Worker从输入内容加载到的顶点，刚好是自己所分配的分区中的顶点，就会立刻更新相应的数据结构，否则，该worker会根据加载到的顶点的id，把它发送到其所属的分区所在的worker上，当所有的输入被加载后，图中所有的顶点被标记活跃状态
04 Master向每个Worker发送指令，Worker收到指令后，开始运行一个超步，当一个超步中的所有工作都完成，Worker会通知Master并报告自己在下一步超步还处于活跃状态的顶点的数量，每个分区worker都启一个线程
05 计算过程结束后，Master会给所有的Worker发送指令，通知每个Workder对自己的计算结果进行持久化存储
容错性：
Pregel采用检查点机制实现容错。在每个超步开始，Master会通知所有的Worker把自己管辖的分区的状态写入到持久化设备，状态包括顶点值边的值和接收的消息，一旦发生错误，从这个地方恢复
Master会周期性的向每个Worker发送ping消息，Worker收到ping消息后会给Master一个反馈消息，每个worker上都保存了一个或多个分区的状态信息
当worker发生故障，它所维护的分区的当前状态就会丢失
master一旦检测到workder故障失效后，会把失效worker的分区重新分配到其他worker上
Master、Worker和Aggregator
Worker，一般在执行过程中它的信息是保存在内存中，只有在超步开始时候才利用检查点机制把分区状态持久化，分区中每个顶点的状态信息包括顶点当前值、出射边列表、消息队列、标志位；worker会对自己管辖的分区中的每个顶点进行遍历，并调用顶点上的compute()函数，调用时候会把三个参数传送给compute函数，顶点当前值、消息迭代器、出射边迭代器；Pregel中，为了获得更好的性能，“标志位”和输入消息队列是分开保存的，保存一份顶点值和边的值，但是保存2份标志位和消息队列，这两份分别用于当前超步和下一个超步；如果一个顶点V在超步S接收消息表示V在下一个超步S+1中处于活跃状态；发送消息，如果是自己机器，直接把消息放入到与目标顶点U对应的消息队列中，远程机器，不是马上发过去，暂时缓存本地，当缓存中的消息数达到一个事先设置好的阈值，这些缓存消息会被批量异步发送出去，传输到目标顶点所在的Worker上，可以减少启动开销，也可以在缓存中combine，减少开销
Master，扮演管家的角色，主要协调各Worker执行各个任务；Master维护着关于当前处于”有效“状态的Worker信息，包括每个Worker的id和地址以及worker被分配到的分区信息；Master中保存这些信息的大小只与分区数量有关而与顶点和边 的数量无关；Master向所有处于有效状态的worker发送相同指令，然后等待worker回复，在指定时间没有回应说明该worker失效，master会进入恢复模式；在每个超步中，图计算的各种工作，会在”路障barrier“之前结束，包括输入输出、计算保存、检查点恢复；Master在内部运行了一个http服务器来显示图计算过程的各种信息，比如图大小、出度分布的柱状图、处于活跃的顶点数量、在当前超步的时间信息和消息数量、所有用户自定义Aggregator的值；
Aggregator，聚合函数，在执行图计算过程的某个超步S中，每个Worker会利用一个Aggregator对当前本地分区中包含的所有顶点值进行归约，得到一个本地的局部归约值；在超步S结束时，所有Worker会将所有包含局部归约值的Aggregator的值最后汇总得到全局值，然后提交给Master；在S+1开始时，Master会将Aggregator的值发送给每个Worker
12.6 Pregel的应用实例——单源最短路径
Dijkstra算法是解决单源最短路径的贪婪算法
12.7 Hama的安装和使用
Hama是google pregel的开源实现，pregel是个商业软件
与hadoop适合于分布式大数据处理不同，Hama主要用于分布式的矩阵、图、网格的计算
Hama是在HDFS上实现的BSP（Bulk Synchronous Parallel）计算框架，弥补Hadoop在图计算能力上的不足
安装过程是jdk环境，下载解压缩配置环境即可
第13讲 大数据在不同领域的应用
13.1 大数据应用概览
互联网：推荐系统
生物医学：流行病预测、智慧医疗、生物信息学
物流：智能物流、中国智能物流骨干网-菜鸟
城市管理：智能交通、环保检测、城市规划、安防领域
金融：高频交易、市场情绪分析、信贷风险分析
汽车领域：无人驾驶骑车
零售行业：发现关联购买行为、客户群体细分
餐饮行业：餐饮O2O
电信行业：电信客户离网分析
能源行业：智能电网
体育娱乐：投拍影视作品、训练球队、预测比赛结果
安全领域：防御网络攻击、预防犯罪
*领域：选举
13.2 推荐系统
搜索引擎只能帮助我们查询明确的需求
为了让用户从海量信息中高效的获得自己所需信息，推荐系统应运而生。推荐系统是大数据在互联网领域的典型应用.，他可以分析用户的历史记录来了解用户的喜好从而主动的为用户推荐其感兴趣的信息，满足用户的个性化推荐需求
推荐系统是自动联系用户和物品的一种工具，和搜索引擎相比，推荐系统通过研究用户的兴趣偏好，进行个性化计算，推荐系统可发现用户的兴趣点帮助用户从海量信息中去发掘自己潜在的需求
推荐系统可以创造全新的商业和经济模式，（例子：帮助实现长尾商品的销售）
长尾理论：电子商务网站销售种类繁多，虽然绝大多数商品都不热门，但这些不热门的商品总数量极其庞大，所累计的总销售额将是一个可观的数字，也许会超过热门商品所带来的销售额
专家推荐和热门推荐无法推荐长尾产品
个性化推荐可通过推荐系统来实现，推荐系统通过发掘用户的行为记录找到用户的个性化需求，发现用户潜在的消费倾向，从而将长尾商品准确的推荐给需要它的用户，进而提升销量，实现用户与商家的双赢
基于用户的协同过滤UserCF
最知名的推荐算法
协同过滤分为基于用户的协同过滤、基于物品的协同过滤
cf：Collaboration Filter
1992年提出，是推荐系统中最古老的算法，最基本的思想是趣味相投
UserCF算法实现的2个步骤：找到和目标用户兴趣相似的用户集合；找到该集合中的用户所喜欢的且目标用户没听说过的物品推荐给目标用户
主要是衡量用户相似度的算法：比较多比如泊松相关系数、余弦相似度、调整余弦相似度
余弦相似度算法：
很多用户并没有对同样的物品产生交集，相似度0，没有必要浪费计算，设计一个物品到用户的倒排表，最大程度的减少计算量
得到用户间的相似度后，再使用如下公式
基于物品的协同推荐ItemCF
ItemCF是目前业界应用最多的算法，无论是亚马逊还是Netflix，其推荐系统的基础都是ItemCF算法，是给目标用户推荐那些和他们喜欢的物品相似的物品。ItemCF算法主要分析用户的行为记录来计算物品之间的相似度
ItemCF算法基于的假设是物品A和物品B具有很大的相似度是因为喜欢物品A的用户大多也喜欢物品B
计算物品之间的相似度；根据物品的相似度和用户的历史行为，给用户生成推荐列表
UserCF和ItemCF比较：
UserCF适合新闻推荐、微博话题推荐等场景，其推荐结果在新颖性方面有优势，缺点是随着用户数增大，计算复杂性越来越高，而且UserCF推荐结果相关性较弱，难以对推荐结果作出解释容易受大众影响而推荐热门物品
ItemCF适合电子商务、图书、电影等场景，可以利用用户的历史行为给推荐结果，更容易解释推荐结果，让用户更信服，但是倾向于推荐与用户已购买物品相似的物品，往往会出现多样性不足、推荐新颖性较低的问题
13.3 大数据在智能医疗和智能物流领域运用
基于大数据的综合健康服务平台 目标：覆盖全生命周期、丰富内涵、结构合理的以人为本全面连续的综合健康服务体系，利用大数据技术和智能设备技术，提供线上线下相结合的公众健康服务，实现“未病先防、已病早治、愈后防复”，满足社会公众多层次、多方位的健康服务需求，提升人民群众的身心健康水平
智能物流：典型的是阿里巴巴构建的中国物流骨干网，简称菜鸟网
菜鸟网采用天网+地网的模式
天网：天猫牵头负责与各大物流快递公司对接的数据平台
地网：中国智能物流骨干网CSN
天网指导地网运行
天网提前计算并布货
大数据系统对物流系统优化的作用