以下是根据自己的总结和梳理,建议入过门大数据的人看.写的很片面,没有图片,我仅仅想把握学的东西梳理下.
Hadoop篇
数据仓库
数据仓库,简写DW,是为企业级所有级别的决策制定过程,提供所有类型数据支持的战略集合.是单个数据存储,处于分析性报告和决策支持的而创建.
HDFS原理
客户端将数据上传到DateNode,然后通过硬盘(数据节点)的水平复制功能,达到冗余度的要求.而主节点NameNode管理维护HDFS,接受客户端的请求和维护文件的元信息(fsimage)和日志(edits),SecondaryNameNode进行日志信息合并.SNN不是NN热备,没有关系
HDFS写数据流程
- 向NameNode请求上传文件
- NameNode相应可以上传文件
- 请求上传第一个block,请返回DataNode
- 返回DataNode节点,
- 客户端和DataNode奖励block通道,且响应成功
最后数据传输
HDFS读数据的过程
- 客户端那个NameNode 请求下载文件
- NameNode返回目标中的元数据
- 客户端请求DataNode读取数据
- 客户端与DataNode之间传输数据
- 然后客户端请求DataNode读取数据
最后DataNode传输数据
NamNode工作机制
- NamNode加载吧编辑日志和镜像文件到内存
- 客户端向NameNode请求元数据的增删改查
- 记录日志,更新滚动日志
内存数据的增删改查
DataNode工作机制
DataNode启动后向NameNode注册
扫描二维码关注公众号，回复： 160567 查看本文章
- 当注册成功后,没周期上报所有块信息
- 心跳没3秒一次,心跳返回结果带有NameNode给DataNode的命令
- 超狗30分钟没有收到DataNode的星跳则认为该节点不可用
MapReduce程序运行图
- 开始有待处理的文本
- 客户端submit()前获取带处理的数据信息,然后根据参数配置,形成一个任务分配规则
- 客户端提交切片信息,计算map task的数量
- 然后开始读取数据,map阶段开始逻辑运算
- 输出到reduce以Key value的形式
- 按照分区排序写入reduce
- 所有map tas任务完成后,启动相应reduce task.并告知reduce task处理数据范围
- reduce获取数据,并进行运算
- 输出结构到HDFS
MapReduce的处理过程
首先由客户端Client,提交MapReduce任务Job
然后JobTracker协调整个job的运行,其中一个Java进程,其main class为JobTracker
TaskTracker：运行此job的task，处理input split，其为一个Java进程，其main class为TaskTracker
最后写入到HDFS：hadoop分布式文件系统，用于在各个进程间共享Job相关的文件
MapReduce原理
MapReduce的过程首先是由客户端提交一个任务开始的,提交任务主要通过JobClient.runJob(JobConf)静态函数实现的
读取数据文件内容,对内容解析成键值对,每个键值对调用一次map函数,编写映射函数处理逻辑,建输入的键值对输出新的键值对
将新的键值对进行分区,排序,分组
对多个Map的输出，按不同分区通过网络将copy到不同的reduce节点
对多个map的输出进行排序，合并，编写reduce函数处理逻辑，将接收到的数据转化成新的键值对
最后将reduce节点输出的数据保存到HDFS上
MR任务在Yarn调度的工程
由客户端的jar包提交任务请求到DFSClent.java,然后创建任务ID,在将任务文件保存到HDFS,获取到元信息,在提交任务(ID,数据元信息,任务元信息)到Yarn的ResourceManager(作用:接受客户端请求,分配资源和任务),然后ResourceManager对任务进行初始化:资源,分配资源和任务,最根据元信息到HDFS上获取数据和任务
HDFS的启动过程
第一步:读取fsimage文件,
第二步:读取edits日志
第三步:保存检查点
第四步:HDFS进入安全模式—->作用:检查数据块的副本率(冗余)
HDFS底层原理
底层原理采用的是:RPC和动态代理
RPC:
Remote Procedure Call,远程过程调用,也就是说,调用过程代码并不是在调用本地运行,而是实现调用者与被调用者二地之间的连接与通信
什么事shuffle?
当有一个数据块传过来是,首先会切片,然后送到map处理,输出数据到环形缓存区(内存:100M;超过80%时写成一个文件),然后在输出多个分区文件(可能排好序),在进行合并,形成更大的文件(可能更大的文件),当有多个大的文件,会进行Combiner合并更大的文件,在输出到对应的Reduce,最后输出.
HBase篇
什么事HBase
HBase的原型是Google的BigTable论文,从基因上讲,HBase已经是Hadoop生态系统化不可或缺的一部分 .HBase是一个分布式的,面向列的开源数据库,其字Hadoop之上提供了类型BigTable的能力,其特点海量存储,列式存储,极易扩展,高并发,稀疏
HBase的架构
HBase主要有Client, Zookeeper, Master, RegionServer, HDFS等几个组建而成.
Client包含了访问的HBase的接口,另外Client还维护了对应的cache来加速HBase的访问
Base通过Zookeeper来做master的高可用,RegionServer的监控,元数据的入口以及集群配置的维护等工作
Master主要是做一些管理操作；如region的分配，手动管理操作下发等等，一般数据的读写操作并不需要经过Master集群，所以Master一般不需要很高的配置即可
RegionServer :管理master为其分配Region
处理来自客户端请求
负责与底层HDFS交互,存储数据到HDFS
负责Region变大以后拆分
负责Storefile的合并工作
HDFS为Hbase提供最终的底层数据存储服务，同时为Hbase提供高可用（Hlog存储在HDFS）的支持，具体功能概括如下：
提供元数据和表数据的底层分布式存储服务
数据多副本，保证的高可靠和高可用性
HBase 原理
HBase中 ROO表和META表
HBase的所有HRegion元数据被保存在.META,随着HRegion的增多，.META.表中的数据也会增大，并分裂成多个新的HRegion。会把元数据保存到-ROOT-表中. -ROOT-表永远不会被分割,-ROOT-只有一个 region,.META.可以有多个 regoin
-ROOT-表永远不会被分割，它只有一个HRegion，这样可以保证最多只需要三次跳转就可以定位任意一个HRegion。为了加快访问速度，.META.表的所有HRegion全部保存在内存中。客户端会将查询过的位置信息缓存起来，且缓存不会主动失效。如果客户端根据缓存信息还访问不到数据，则询问相关.META.表的Region服务器，试图获取数据的位置，如果还是失败，则询问-ROOT-表相关的.META.表在哪里。最后，如果前面的信息全部失效，则通过ZooKeeper重新定位HRegion的信息。所以如果客户端上的缓存全部是失效，则需要进行6次网络来回，才能定位到正确的HRegion。
Client 访问用户数据之前需要首先访问 zookeeper，然后访问-ROOT-表，接着访
问.META.表，最后才能找到用户数据的位置去访问。
HBase的读写操作流程
写操作:
步骤1：Client通过Zookeeper的调度，向HRegionServer发出写数据请求，在HRegion中写数据。
步骤2：数据被写入HRegion的MemStore，直到MemStore达到预设阈值。
步骤3：MemStore中的数据被Flush成一个StoreFile。
步骤4：随着StoreFile文件的不断增多，当其数量增长到一定阈值后，触发Compact合并操作，将多个StoreFile合并成一个StoreFile，同时进行版本合并和数据删除。
步骤5：StoreFiles通过不断的Compact合并操作，逐步形成越来越大的StoreFile。
步骤6：最后的文件StoreFile会刷盘就会相应生成一个存储文件HFile,数据量的持续写入，造成memstore的频繁flush，每次flush都会产生一个HFile，这样底层存储设备上的HFile文件数量将会越 来越多。(磁盘)最好通过HDFS接口写到HDFS中
1. Client客户端写入数据后 -> 数据存入MemStore，一直到MemStore满之后 Flush成一个StoreFile，直至增长到一定阈值 -> 触发Compact合并操作 -> 多个StoreFile合并成一个StoreFile。
读操作:
步骤1：client访问Zookeeper，查找-ROOT-表，获取.META.表信息。
步骤2：从.META.表查找，获取存放目标数据的HRegion信息，从而找到对应的HRegionServer。
步骤3：通过HRegionServer获取需要查找的数据。
步骤4：HRegionserver的内存分为MemStore和BlockCache两部分，MemStore主要用于写数据，BlockCache主要用于读数据。读请求先到MemStore中查数据，查不到就到BlockCache中查，再查不到就会到StoreFile上读，并把读的结果放入BlockCache。
Hive的架构
由客户端(client),原数据(Metastore),Drive(驱动器),驱动器的执行程序先解析SQL语句,在使用编译器编译,在优化,后执行器执行.
流程:
Hive 通过给用户提供的一系列交互接口，接收到用户的指令(SQL)，使用
自己的 Driver，结合元数据(MetaStore)，将这些指令翻译成 MapReduce，提交到 Hadoop 中
执行，最后，将执行返回的结果输出到用户交互接口。
Hive的工作原理
流程大致步骤为：
1. 用户提交查询等任务给Driver。
2. 编译器获得该用户的任务Plan。
3. 编译器Compiler根据用户任务去MetaStore中获取需要的Hive的元数据信息。
4. 编译器Compiler得到元数据信息，对任务进行编译，先将HiveQL转换为抽象语法树，然后将抽象语法树转换成查询块，将查询块转化为逻辑的查询计划，重写逻辑查询计划，将逻辑计划转化为物理的计划（MapReduce）, 最后选择最佳的策略。
5. 将最终的计划提交给Driver。
6. Driver将计划Plan转交给ExecutionEngine去执行，获取元数据信息，提交给JobTracker或者SourceManager执行该任务，任务会直接读取HDFS中文件进行相应的操作。
7. 获取执行的结果。
8. 取得并返回执行结果。
Hive编译过程
基本流程为：将HiveQL转化为抽象语法树再转为查询块然后转为逻辑查询计划再转为物理查询计划最终选择最佳决策的过程。
Hive数据分析引擎:
1.最先由FaceBook开发,用于海量结构化日志的数据统计
Hive 是基于 Hadoop 的一个数据仓库工具，可以将结构化的数据文件映射为一张表，并
提供类 SQL 查询功能
本质是：将 HQL 转化成 MapReduce 程序
1）Hive 处理的数据存储在 HDFS
2）Hive 分析数据底层的实现是 MapReduce
3）执行程序运行在 Yarn 上
Hive与数据库的比较
- Hive类SQL查询语言,Hive与数据库除了拥有查询语言,再无类似之处,数据库可以在Online的应用中,,Hive是为数据仓库
- Hive是建立在Hadoop上,所以Hive数据都是存储在HDFS中的.而数据局保存早块设备或本地文件系统中
- Hive不支持数据的改写或添加,所有的数据都是加载时确定好,而数据库通常需要经常修改.
- Hive在加载时,不会对数据处理.所以数据中,在引入MapReduce,Hive可以并行访问数据,没有索引,可以对大量数据量的访问,数据库通常会建立索引.由于数据的访问延迟较高，决定了 Hive 不适合在线数据查询
- Hive是通过MapReduce来执行查询.数据库有自己的执行引擎
- Hive延迟,较高(没有索引,需扫描整个表)
- Hive建立大规模数据.数据较少
Kafka篇
消息队列内部实现原理
客户端A 发送消息给队列,客户端B接收消息(消费者)
模式:
点对点模式(一对一),消费者主动拉取数据消息收到消息后消息消除
发布/订阅消息(一对多),数据产生后,推送给订阅者[push]
相同的消息放到主题中(topic)
zookeeper:
(1)kafka集群节点的状态信息 消费者正在消费消息的状态信息,没有生产者信息
a. consumer消费消息是以一个partition为单位,所以partition会和consumer以socket链接
b. 同一个消费组,同一时间只能有一个consumer消费消息
c. 同一个消费组里面的消费者不会重复消费消费
d. 消息必须放到topic,且topic中里面有多个分区,消息一定落到分区中
e. Kafka可以有多个生产者,可有有多个不同主题,只能有一个相同的主题,一个主题有多个分区,同一个分区是有序的,不同的分区不能保证有序
f. Kafka不是永久保存,默认保存7天,所以数据不是全部保存在内存中,保存磁盘
g. Kafka的生产者和消费者相对于服务器端而言都是客户端。
Sqoop篇
Sqoop采集关系型数据库,基于MR进行数据采集
数据交换引擎： RDBMS <—-> Sqoop <—-> HDFS（HBase、Hive）
sqoop1 import原理：
从传统数据库获取元数据信息(schema、table、field、field type)，把导入功能转换为只有Map的Mapreduce作业，在mapreduce中有很多map，每个map读一片数据，进而并行的完成数据的拷贝。
sqoop1 export原理：
获取导出表的schema、meta信息，和Hadoop中的字段match；多个map only作业同时运行，完成hdfs中数据导出到关系型数据库中。
Flume 篇
什么是Flume
Flume 是 Cloudera 提供的一个高可用的，高可靠的，分布式的海量日志采集、聚合
和传输的系统，Flume 支持在日志系统中定制各类数据发送方，用于收集数据；同时，
Flume 提供对数据进行简单处理，并写到各种数据接受方（可定制）的能力。
Flume的架构主要有以下几个核心概念
Flume的基本架构
Flume的体系结构的核心: agent = source + channel + sink
source 组件采集日志源到Channel缓存,然后输送到sink组件,将日志信息写到目的地保存到HDFS/HBase
Flume的架构主要的有以下几个核心概念
Event: 一个数据单元,带有一个颗选的消息头
Flow:Event从源点到达目的点的迁移的抽象
Client：操作位于源点处的Event，将其发送到Flume Agent
Agent：一个独立的Flume进程，包含组件Source、Channel、Sink
Source：用来消费传递到该组件的Event(采集日志)
Channel：中转Event的一个临时存储，保存有Source组件传递过来的Event
Sink：从Channel中读取并移除Event，将Event传递到Flow Pipeline中的下一个Agent（如果有的话）
Zookeeper篇
1)半数机制（Paxos 协议）：集群中半数以上机器存活，集群可用。所以 zookeeper
适合装在奇数台机器上。
2）Zookeeper 虽然在配置文件中并没有指定 master 和 slave。但是，zookeeper 工作时，
是有一个节点为 leader，其他则为 follower，Leader 是通过内部的选举机制临时产生的。
例如:
（1）服务器 1 启动，此时只有它一台服务器启动了，它发出去的报没有任何响应，所
以它的选举状态一直是 LOOKING 状态。
（2）服务器 2 启动，它与最开始启动的服务器 1 进行通信，互相交换自己的选举结果，
由于两者都没有历史数据，所以 id 值较大的服务器 2 胜出，但是由于没有达到超过半数以
上的服务器都同意选举它(这个例子中的半数以上是 3)，所以服务器 1、2 还是继续保持
LOOKING 状态。
（3）服务器 3 启动，根据前面的理论分析，服务器 3 成为服务器 1、2、3 中的老大，
而与上面不同的是，此时有三台服务器选举了它，所以它成为了这次选举的 leader。
（4）服务器 4 启动，根据前面的分析，理论上服务器 4 应该是服务器 1、2、3、4 中最
大的，但是由于前面已经有半数以上的服务器选举了服务器 3，所以它只能接收当小弟的命
了。
（5）服务器 5 启动，同 4 一样当小弟。
什么事Zookeeper
ZooKeeper 是一个分布式的，开放源码的分布式应用程序协调服务，是 Google
的 Chubby 一个开源的实现，是 Hadoop 和 Hbase 的重要组件。它是一个为分布式
应用提供一致性服务的软件，提供的功能包括：配置维护、域名服务、分布式同步、
组服务等。(相当于一个数据库,保存信息)两种角色: leader foller(ZK具备选举机制–> 当leader死了，从follower选一个新的作为leader)
会自动在zookeeper集群中的各个节点上进行数据的同步
重要部分
ZooKeeper集群由一组Server节点组成，这一组Server节点中存在一个角色为Leader的节点，其他节点都为Follower。当客户端Client连接到ZooKeeper集群，并且执行写请求时，这些请求会被发送到Leader节点上，然后Leader节点上数据变更会同步到集群中其他的Follower节点。
Leader节点在接收到数据变更请求后，首先将变更写入本地磁盘，以作恢复之用。当所有的写请求持久化到磁盘以后，才会将变更应用到内存中。
ZooKeeper使用了一种自定义的原子消息协议，在消息层的这种原子特性，保证了整个协调系统中的节点数据或状态的一致性。Follower基于这种消息协议能够保证本地的ZooKeeper数据与Leader节点同步，然后基于本地的存储来独立地对外提供服务。
当一个Leader节点发生故障失效时，失败故障是快速响应的，消息层负责重新选择一个Leader，继续作为协调服务集群的中心，处理客户端写请求，并将ZooKeeper协调系统的数据变更同步（广播）到其他的Follower节点。
Zookeeper能做什么
Hadoop 2.0 使用Zookeeper的时间处理确保整个集群只有一个活跃的NameNode,存储配置信息等
HBase,使用Zookeeper的事件处理确保整个集群只有一个HMaster,察觉HRegionServer联机和宕机,存储访问控制列表等
Zookeeper的选举机制
1）半数机制（Paxos 协议）：集群中半数以上机器存活，集群可用。所以 zookeeper
适合装在奇数台机器上。
2）Zookeeper 虽然在配置文件中并没有指定 master 和 slave。但是，zookeeper 工作时，
是有一个节点为 leader，其他则为 follower，Leader 是通过内部的选举机制临时产生的。
例子:
（1）服务器 1 启动，此时只有它一台服务器启动了，它发出去的报没有任何响应，所
以它的选举状态一直是 LOOKING 状态。
（2）服务器 2 启动，它与最开始启动的服务器 1 进行通信，互相交换自己的选举结果，
由于两者都没有历史数据，所以 id 值较大的服务器 2 胜出，但是由于没有达到超过半数以
上的服务器都同意选举它(这个例子中的半数以上是 3)，所以服务器 1、2 还是继续保持
LOOKING 状态。
（3）服务器 3 启动，根据前面的理论分析，服务器 3 成为服务器 1、2、3 中的老大，
而与上面不同的是，此时有三台服务器选举了它，所以它成为了这次选举的 leader。
（4）服务器 4 启动，根据前面的分析，理论上服务器 4 应该是服务器 1、2、3、4 中最
大的，但是由于前面已经有半数以上的服务器选举了服务器 3，所以它只能接收当小弟的命
了。
（5）服务器 5 启动，同 4 一样当小弟。
Kafka篇
kafka中的topic为什么要进行分区?
若没有分区，一个topic对应的消息集在分布式集群服务组中，就会分布不均匀，即可能导致某台服务器A记录当前topic的消息集很多，若此topic的消息压力很大的情况下，服务器A就可能导致压力很大，吞吐也容易导致瓶颈。
一个Topic可以认为是一类消息，每个topic将被分成多个partition(区),每个partition在存储层面是append log文件
MemCached篇*
什么事MeMCached
Memcache 是一套开源,高性能的分布式的内存对象缓存系统，目前
被许多网站使用以提升网站的访问速度，尤其对于一些大型的、需要频
繁访问数据库的网站访问速度提升效果十分显著 。
Memcache 将所有数据存储在内存中，并在内存里维护一个统一的巨
大的 Hash 表，它能存储任意类型的数据，包括图像、视频、文件以及数
据库检索的结果等。简单的说就是将数据调用到内存中，然后从内存中
读取，从而大大提高读取速度。
(只能缓存,不能持久化)
MemCached的体系结构与原理
memcached 就是在内存中维护一张巨大的 hash 表,通过自
己的一套 路由算法来维护数据的操作。
memcached缓存特点
(1)协议简单
(2)基于libevent的事件存储
(3)内置内存存储方式
(4)memcached不相互通信的分布式
Redis篇
Redis是一个key-value存储系统。和Memcached类似，它支持存储的value
类型相对更多，包括 string(字符串)、list(链表)、set(集合)、zset(sorted set –
有序集合)和 hash（哈希类型）。与 Memcached 一样，为了保证效率，数据
都是缓存在内存中。区别的是 redis 会周期性的把更新的数据写入磁盘或者
把修改操作写入追加的记录文件，并且在此基础上实现了 master-slave(主从)
同步。
Redis 是一个高性能的 key-value 数据库。Redis 的出现，很大程度补偿了
memcached 这类 key/value 存储的不足，在部分场合可以对关系数据库起到
很好的补充作用。它提供了 Java，C/C++，C#，PHP，JavaScript，Perl，Object-C，
Python，Ruby，Erlang 等客户端，使用很方便。
Redis 支持主从同步。数据可以从主服务器向任意数量的从服务器上同
步，从服务器可以是关联其他从服务器的主服务器。
Redis与Memcached的区别
MemCached只能缓存数据,而不能持久化,redis都可以,Redis 可以用来做缓存，也可以做存储；支持 ADF 和 RDB 两种持
Redis 有丰富的数据类型：字符串、链表，Hash、集合，有序集
合
Memcached 一般就是字符串和对象
Redis特点
基于内存
两种持久化方式: RDB(快照) AOF日志
支持消息机制,支持String,只支持Topic(主题,广播)的消息类型
丰富的数据类型
有简单的事物
支持主从复制
油腻HA(哨兵机制)
Storm篇
什么是storm
Storm 为分布式实时计算提供了一组通用原语，可被用于“流处理”之中，实时处理消息并更新数据库。这是管理队列及工作者集群的另一种方式。 Storm 也可被用于“连续计算”（continuous computation），对数据流做连续查询，在计算时就将结果以流的形式输出给用户。它还可被用于“分布式 RPC”，以并行方式运行昂贵的运算。
Storm 可以方便地在一个计算机集群中编写与扩展复杂的实时计算，Storm 用于实
时处理，就好比 Hadoop 用于批处理。Storm 保证每个消息都会得到处理，而且它很快
——在一个小集群中，每秒可以处理数以百万计的消息。更棒的是你可以使用任意编程
语言来做开发。
离线计算和流式计算
离线计算:
离线计算：批量获取数据、批量传输数据、周期性批量计算数据、数据展示
代表技术：Sqoop 批量导入数据、HDFS 批量存储数据、MapReduce 批量计算、Hive
流式计算:
数据实时产生、数据实时传输、数据实时计算、实时展示
代表技术：Flume 实时获取数据、Kafka/metaq 实时数据存储、Storm/JStorm 实
时数据计算、Redis 实时结果缓存、持久化存储(mysql)。
一句话总结：将源源不断产生的数据实时收集并实时计算，尽可能快的得到计
算结果
Storm的体系结构
Nimbus:负责资源分配和任务的调度
Supervisor:负责接受 nimbus 分配的任务，启动和停止属于自己管理的 worker 进程。通过配置文件设置当前 supervisor 上启动多少个 worker。
Worker:运行具体处理组件和逻辑进程. Worker运行的任务有两种一种是Spout任务,一种是Bolt任务
Executor: Executor为Worker进程中的具体物理线程,同一个Spout/Bolt的Task可能会共享一个物理线程,一个Executor中只能运行隶属同一个Spout/Bolt 的 Task。
Task：worker 中每一个 spout/bolt 的线程称为一个 task. 在 storm0.8 之后，task 不
再与物理线程对应，不同 spout/bolt 的 task 可能会共享一个物理线程，该线程称为
executor
Storm的编程模型
Topology:Storm中运行的一个实时应用的引用的程序的名称(拓扑)其功能 analogous to a MapReducejob，但唯一不同的是它是循环执行的——无数据流等待，有数据流执行，直到被kill progress。
Spout:在一个topology中获取源数据的组件
通常情况下 spout 会从外部数据源中读取数据，然后转换为 topology 内部的源
数据
Bolt: 接受后执行处理的组件,用户可以在其中执行自己的想要的操作.
Tuple：一次消息传递的基本单元，理解为一组消息就是一个 Tuple。
Stream：表示数据的流向。
StreamGroup：数据分组策略
Shuffle Grouping ：随机分组，尽量均匀分布到下游 Bolt 中
Fields Grouping ：按字段分组，按数据中 field 值进行分组；相同 field 值的 Tuple被发送到相同的 Task
All grouping ：广播
Global grouping ：全局分组，Tuple 被分配到一个 Bolt 中的一个 Task，实现事务性的 Topology。
None grouping ：不分组
Direct grouping ：直接分组 指定分组
Storm集群任务提交流程(原理)
Storm的主节点nimbus接收客户端的请求的Jar文件,然后把任务信息和资源发布到Zookeeper集群上,从节点supervisor从Zookeeper上获取分配给自己的task任务,启动对应的Worker进程.由Worker执行具体任务的task,Spout或者Bolt
Storm完成单词计数
首先由spout组件采集源源不断的数据(相当于MR的Mapper),
然后spout发送Tuple(结构schema+数据data)
组件Bolt将数据分割或者分解,
在发送Tuple,此时有Bolt组件进行计数
任何reportbolt将结果保存到hashmap中,打印结果
Spark篇
什么是Spark
Spark是一种快速的,通用的,可扩展的大数据分析引擎,Spark系统已经发展包含多个子项目的集合,包含SparkSQL,Spark Streaming, GraphX, Mulib等子项目,Spark基于内存计算的大数据并行计算框架,提高了在大数据环境下数据处理的实时性,同时保证了高容错性和伸缩的性
用Spark,且Hadoop的MapReduce计算模型存在的问题
MapReduce的核心是shuffle(洗牌),在整个 Shuffle 的过程中，至少会产生 6 次的 I/O。
中间间结果输出:基于MapReduce的计算引擎通常会将结果输出到次盘上,进行存储和容错.另外,当一些查询翻译到MapReduce任务时,往往会产生多个Stage,而这些串联的Stage又依赖底层的文件系统来存储每一个Stage的输出结果,而I/O的效率往往比较低,从而影响了MapReduce的运行速度.
而spark兼容HDFS,Hive可以融入Hadoop的生态系统,弥补MapReduce的不足
Spark架构与生态
Spark Core: 内核,相当于Hadoop的MapReduce的程序,二者都是进行离线计算,包含Spark的基本的功能,尤其是定义RDD的API,操作以及这两者上的动作.其他Spark的库都是构建咋RDD和Spark Core上的.
Spark SQL: 提供通过Apache Hive的SQL变体查询语言(HiveQL)与Spark进行交互的API.每个数据库表被当做一个RDD,Spark SQL查询被转换Spark操作,
Spark Streaming: 对实时数据流进行处理和控制.Spark Steaming允许程序像普通的RDD一样处理实时数据.
MLlib: 一个常用机器学习算法库，算法被实现为对RDD的Spark操作。这个库包含可扩展的学习算法，比如分类、回归等需要对大量数据集进行迭代的操作。
GraphX：控制图、并行图操作和计算的一组算法和工具的集合。GraphX扩展了RDD API，包含控制图、创建子图、访问路径上所有顶点的操作
Spark的架构
ClusterManager: 在standlone模式中加入Master(主节点),控制整个集群,监控Worker.在Yarn模式中为资源管理器;
Work:从节点,负责控制计算节点启动Executor运行或Driver
Executor: 执行器,在worker node上执行任务组件,用于启动线程执行任务.每个Application拥有独立的一组Executors
Spark架构采用了分布式计算中的Masterd-Slave模型.Master是对应集群中含有Maser进程的节点,Slave是集群中含有Worker进程的节点.Master作为整个集群的控制器的正常运行.Worker相当于计算节点,接收主节点命令和警醒状态汇报;Executor负责任务的执行；Client作为用户的客户端负责提交应用，Driver负责控制一个应用的执行.
Spark的执行过程:
client提交应用,Master找到一个Worker启动Driver,Driver向Master或者向资源管理器申请资源,之后将应用转化为RDD Graph，再由DAGScheduler将RDD Graph转化为Stage的有向无环图提交给TaskScheduler，由TaskScheduler提交任务给Executor执行。在任务执行的过程中，其他组件协同工作，确保整个应用顺利执行。
Spark集群部署后,需要在主节点和从节点分别启动Master进程和Worker进程,对整个集群进行控制,在一个Spark应用的执行程序中.Driver和Worker是两个重要的角色.Driver程序是应用逻辑执行的起点，负责作业的调度,即Task任务的发布,而多个Worker用来管理计算节点和创建Executor并行处理任务.在执行阶段,Driver会将Task和Task所依赖的file和jar序列化后传递给对应的Worker机器.同时Executor对相应数据分区的任务进行处理.
Spark的HA
ZooKeeper 提供了一个 Leader Election 机制，利用这个机制可以保证虽然集群
存在多个 Master，但是只有一个是 Active 的，其他的都是 Standby。当 Active 的
Master 出现故障时，另外的一个 Standby Master 会被选举出来。由于集群的信息，
包括 Worker， Driver 和 Application 的信息都已经持久化到 ZooKeeper，因此在切
换的过程中只会影响新 Job 的提交，对于正在进行的 Job 没有任何的影响。加入
ZooKeeper 的集群整体架构如下图所示。
第二种基于文件系统的单点恢复
主要用于开发或测试环境。当 spark 提供目录保存 spark Application 和 worker 的
注册信息，并将他们的恢复状态写入该目录中，这时，一旦 Master 发生故障，就可以
通过重新启动 Master 进程（sbin/start-master.sh），恢复已运行的 spark Application 和worker 的注册信息。
Spark的集群运行流程图
构建SparkApplication的运行环境,客户端启动Driver,提交任务.
通过SparkContext对象提交任务请求(只是申请执行任务)给Master(接收客户端的请求,根据客户端请求,分配资源给Worker),然后分配资源给Worker.从节点上启动对应的Executor,Executor向SparkContext申请Task,SparkContext将任务程序分发给Executor,SparkContext构建DAG图,将DAG图分解成Stage,将Tasket发送Task Scheduler,最后由Task Scheduler将Task发送给Executor运行.
Task在Executor上运行,运行完释放资源
Spark的执行流程：
Spark在进行transformation计算的时候，不会触发Job ，只有执行action操作的时候，才会触发Job，在Driver中SparkContext根据RDD之间的依赖关系创建出DAG有向无环图，DAGScheduler负责解析这个图，解析时是以Shuffle为边界，反向解析，构建stage。将多个任务根据依赖关系划分为不同的Stage，将每个Stage的Taste Set 提交给TaskScheduler去执行，任务会在Executor进程的多个Task线程上执行，完成Task任务后 将结果信息提交到ExecutorBackend中 他会将信息提交给TaskScheduler。
TaskScheduler接到消息后通知TaskManager，移除该Task任务，开始执行下一个任务。TaskScheduler同时会将信息同步到TaskSet Manager中一份，全部任务执行完毕后TaskSet Manager将结果反馈给DAGScheduler，如果属于ResultTask 会交给JobListener。否则话全部任务执行完毕后写入数据。
Spark中WordCount的数据处理流程
从HDFS中取出数据由textFile()方法产生两个RDD,然后flatMap(,split(“”))方法进行压缩分割数据,在由map进行分组或者分区,最后reduceByKey(+_)进行分割或者聚合操作
Spark算子
什么是RDD?
叫做弹性分布式数据集,是Spark中最基本的数据抽象,它代表一个不可变,可分区,里面的元素可并行计算的集合.RDD具有数据流模型的特点:自动容错,位置感知性调度的可伸缩性.RDD 允许用户在执行多个查询时显式地将工作集缓存在内存中，后续的查询能够重用工作集，这极大地提升了查询速度。
RDD的属性:
一组分片,及数据的基本单位.对于RDD来说,每个分片都会被一个计算任务处理,并决定并行计算的粒度.
一个计算每个分区的函数。Spark 中 RDD 的计算是以分片为单位的，每个 RDD
都会实现 compute 函数以达到这个目的。compute 函数会对迭代器进行复合，
不需要保存每次计算的结果。
RDD 之间的依赖关系。RDD 的每次转换都会生成一个新的 RDD，所以 RDD 之
间就会形成类似于流水线一样的前后依赖关系。在部分分区数据丢失时，
Spark 可以通过这个依赖关系重新计算丢失的分区数据，而不是对 RDD 的所
有分区进行重新计算。
一个 Partitioner ，即 RDD 的分片函数。当前 Spark 中实现了两种类型的分片
函 数 ， 一 个 是 基 于 哈 希 的 HashPartitioner ， 另 外 一 个 是 基 于 范 围 的
RangePartitioner。只有对于于key-value的RDD，才会有Partitioner，非key-value
的 RDD 的 Parititioner 的值是 None。Partitioner 函数不但决定了 RDD 本身的
分片数量，也决定了 parent RDD Shuffle 输出时的分片数量。
一个列表，存储存取每个 Partition 的优先位置（preferred location）。对于一
个 HDFS 文件来说，这个列表保存的就是每个 Partition 所在的块的位置。按
照“移动数据不如移动计算”的理念，Spark 在进行任务调度的时候，会尽可
能地将计算任务分配到其所要处理数据块的存储位置。
RDD的创建方式: 两种方式
通过外部的数据源: 如HDFS
val rdd1 = sc.textFile(“hdfs://………”);
使用sc.pareallelized
val rdd2 = sc.parallelized(Array(1,2,3,4,5,6))
Tansformation算子: 不会触发计算,延时加载(lazy值)
map(func)：该操作是对原来的RDD进行操作后，返回一个新的RDD
filter: 过滤操作、返回一个新的RDD
flatMap：类似map
mapPartitions：对每个分区进行操作
mapPartitionsWithIndex: 对每个分区进行操作，带分区的下标
union 并集
intersection 交集
distinct 去重
groupByKey: 都是按照Key进行分组
reduceByKey: 都是按照Key进行分组、会有一个本地操作（相当于：Combiner操作）
action算子:会触发计算
collect: 触发计算、打印屏幕上。以数组形式返回
count: 求个数
first: 第一个元素（take(1)）
take(n)
saveAsTextFile: 会转成String的形式，会调用toString()方法
foreach: 在RDD的每个元素上进行某个操作
RDD的缓冲机制
RDD通过persist()方法或者cache()方法可以将前面的计算结果缓冲,但是并不是这两
个方法被调用时立即缓存，而是触发后面的 action 时，该 RDD 将会被缓存在计算节点
的内存中，并供后面重用。
RDD的容错机制
设置checkpoint(本质是通过将RDD写入Disk做检查点)是为了通过line阿哥(血统)做容错的辅助,lineage过长会造成容错成本过高
RDD的依赖关系
宽依赖
是多个子RDD的Partition会依赖同一个父RDD的Partition
窄依赖
每一个父RDD的Partition最多被子RDD的一个Partition使用
Spark的 SQL
Spark SQL是Spark用来处理结构化数据的一个模块,它提供了一个编程抽象讲座DataFrame并且分布式SQL查询引擎的作用
DataFrame 就是表, 是Spark SQL对结构化数据的一个抽象数据集合
表 = 表结构 + 结构
Spark Streaming
Spark Streaming 是核心 Spark API 的扩展，可实现可扩展、高吞吐量、可容错的实
时数据流处理。数据可以从诸如 Kafka，Flume，Kinesis 或 TCP 套接字等众多来源获取，并且可以使用由高级函数（如 map，reduce，join 和 window）开发的复杂算法进行流数据处理。最后，处理后的数据可以被推送到文件系统，数据库和实时仪表板。而且，您还可以在数据流上应用 Spark 提供的机器学习和图处理算法。
Spark Streaming的内部结构
在内部,它的工作原理,Spark Streaming接收实时输入数据流,并将数据切分成批,然后由Spark引擎对其进行处理,最好生成”批”形式的结构流.