大数据常用各组件优势特点及应用场景
1 Hadoop生态圈各常用组件介绍
Hadoop是一个由Apache基金会所开发的分布式系统基础架构。用户可以在不了解分布式底层细节的情况下，开发分布式程序。充分利用集群的威力进行高速运算和存储。具有可靠、高效、可伸缩的特点。
Hadoop的核心是YARN,HDFS和MapReduce。Hdfs是分布式文件存储系统，用于存储海量数据；MapReduce是并行处理框架，实现任务分解和调度。Hadoop可以用来搭建大型数据仓库，对海量数据进行存储、分析、处理和统计等。
1.1 HDFS
Hdfs是hadoop的核心组件，hdfs上的文件被分成块进行存储，默认块的大小是64M，块是文件存储处理的逻辑单元。
HDFS是Master和Slave的结构。分NameNode、SecondaryNameNode、DataNode这几个角色。
NameNode：是Master节点，管理数据块映射，处理客户端的读写请求，配置副本策略，管理HDFS的名称空间；
SecondaryNameNode：是NameNode的冷备份，分担NameNode的工作量，合并fsimage和fsedits然后再发给NameNode，定期同步元数据映像文件和修改日志，当NameNode发生故障时，备份转正。
DataNode：是Slave节点，负责存储client发来的数据块block，执行数据块的读写操作，定期向NameNode发送心跳信息。
1.1.1 Hdfs的特点
a) 数据冗余，硬件容错，每个数据块有三个备份；
b) 流式的数据访问，数据写入不易修改；
c) 适合存储大文件，小文件会增加NameNode的压力。
1.1.2 Hdfs的适用性与局限性
a) 适合数据批量读写，吞吐量高；
b) 不适合做交互式应用，低延迟很难满足；
c) 适合一次写入多次读取，顺序读写；
d) 不支持多用户并发写相同文件。
1.1.3 使用场景
数据存储分析
HDFS有完善的生态，可快速的导入数据到HDFS存储起来，在HDFS的基础上进行分析处理。
历史数据备份
HDFS可轻松扩展到PB、EB级别的大容量，高吞吐量，容错性保证数据安全。
1.2 MapReduce
MapReduce的工作原理用一句话概括就是，分而治之，然后归约，即将一个大任务分解为多个小任务（map），并行执行后，合并结果（reduce）。
整个MapReduce的过程大致分为Map–>Shuffle（排序）–>Combine（组合）–>Reduce。
a) 将文件拆分成splits(片)，并将每个split按行分割形成
b) 将分割好的
c) 得到map方法输出的
d) Reducer先对从Mapper接收的数据进行排序，再交由用户自定义的reduce方法进行处理，得到新的
1.3 YARN
YARN是Hadoop 2.0中的资源管理系统，它的基本设计思想是将MRv1中的JobTracker拆分成了两个独立的服务：一个全局的资源管理器ResourceManager和每个应用程序特有的ApplicationMaster。其中ResourceManager负责整个系统的资源管理和分配，而ApplicationMaster负责单个应用程序的管理。
YARN总体上仍然是Master/Slave结构，在整个资源管理框架中，ResourceManager为Master，NodeManager为Slave，ResourceManager负责对各个NodeManager上的资源进行统一管理和调度。当用户提交一个应用程序时，需要提供一个用以跟踪和管理这个程序的ApplicationMaster，它负责向ResourceManager申请资源，并要求NodeManger启动可以占用一定资源的任务。由于不同的ApplicationMaster被分布到不同的节点上，因此它们之间不会相互影响。
1.3.1 ResourceManager（RM）
RM是一个全局的资源管理器，负责整个系统的资源管理和分配。它主要由两个组件构成：调度器（Scheduler）和应用程序管理器（Applications Manager，ASM）。
（1）调度器
调度器根据容量、队列等限制条件（如每个队列分配一定的资源，最多执行一定数量的作业等），将系统中的资源分配给各个正在运行的应用程序。
需要注意的是，该调度器是一个“纯调度器”，它不再从事任何与具体应用程序相关的工作，比如不负责监控或者跟踪应用的执行状态等，也不负责重新启动因应用执行失败或者硬件故障而产生的失败任务，这些均交由应用程序相关的ApplicationMaster完成。调度器仅根据各个应用程序的资源需求进行资源分配，而资源分配单位用一个抽象概念“资源容器”（ResourceContainer，简称Container）表示，Container是一个动态资源分配单位，它将内存、CPU、磁盘、网络等资源封装在一起，从而限定每个任务使用的资源量。此外，该调度器是一个可插拔的组件，用户可根据自己的需要设计新的调度器，YARN提供了多种直接可用的调度器，比如Fair Scheduler和Capacity Scheduler等。
（2） 应用程序管理器
应用程序管理器负责管理整个系统中所有应用程序，包括应用程序提交、与调度器协商资源以启动ApplicationMaster、监控ApplicationMaster运行状态并在失败时重新启动它等。
1.3.2 ApplicationMaster（AM）
用户提交的每个应用程序均包含1个AM，主要功能包括：
a) 与RM调度器协商以获取资源（用Container表示）；
b) 将得到的任务进一步分配给内部的任务；
c) 与NM通信以启动/停止任务；
d) 监控所有任务运行状态，并在任务运行失败时重新为任务申请资源以重启任务。
1.3.3 NodeManager（NM）
NM是每个节点上的资源和任务管理器，一方面，它会定时地向RM汇报本节点上的资源使用情况和各个Container的运行状态；另一方面，它接收并处理来自AM的Container启动/停止等各种请求。
1.3.4 Container
Container是YARN中的资源抽象，它封装了某个节点上的多维度资源，如内存、CPU、磁盘、网络等，当AM向RM申请资源时，RM为AM返回的资源便是用Container表示的。YARN会为每个任务分配一个Container，且该任务只能使用该Container中描述的资源。
1.3.5 YARN工作流程
当用户向YARN中提交一个应用程序后，YARN将分两个阶段运行该应用程序：
第一个阶段是启动ApplicationMaster；
第二个阶段是由ApplicationMaster创建应用程序，为它申请资源，并监控它的整个运行过程，直到运行完成。
Step1：用户向YARN中提交应用程序，其中包括ApplicationMaster程序、启动ApplicationMaster的命令、用户程序等；
Step2：ResourceManager为该应用程序分配第一个Container，并与对应的Node-Manager通信，要求它在这个Container中启动应用程序的ApplicationMaster；
Step3：ApplicationMaster首先向ResourceManager注册，这样用户可以直接通过ResourceManager查看应用程序的运行状态，然后它将为各个任务申请资源，并监控它的运行状态，直到运行结束，即重复步骤4~7；
Step4：ApplicationMaster采用轮询的方式通过RPC协议向ResourceManager申请和领取资源；
Step5：一旦ApplicationMaster申请到资源后，便与对应的NodeManager通信，要求它启动任务；
Step6：NodeManager为任务设置运行环境（包括环境变量、JAR包、二进制程序等）后，将任务启动命令写到一个脚本中，并通过运行该脚本启动任务；
Step7：各个任务通过某个RPC协议向ApplicationMaster汇报自己的状态和进度，以让ApplicationMaster随时掌握各个任务的运行状态，从而可以在任务失败时重新启动任务。 在应用程序运行过程中，用户可随时通过RPC向ApplicationMaster查询应用程序的当前运行状态；
Step8：应用程序运行完成后，ApplicationMaster向ResourceManager注销并关闭自己。
1.3.6 应用场景
运行各类分布式计算，MapReduce、Spark、Tez、Flink 等分布式计算程序均可以运行在YARN集群中，YARN会为它们提供统一的资源分配及调度。
1.4 Hive
Hive是构建在Hadoop HDFS上的一个数据仓库，可以将结构化的数据文件映射为一张数据库表，并提供类SQL查询功能，其本质是将SQL转换为MapReduce程序。
数据仓库是一个面向主题的、集成的、不可更新的、随时间变化的数据集合，它用于支持企业或组织的决策分析处理。
Hive的表其实就是HDFS的目录/文件。
1.4.1 Hive的体系结构
Hive默认采用的是Derby数据库进行元数据的存储（metastore），也支持mysql数据库。Hive中的元数据包括表的名字，表的列和分区及其属性，表的属性，表的数据所在目录等。
1.4.2 HQL的执行过程
解释器、编译器、优化器完成HQL查询语句从词语分析、语法分析、编译、优化以及查询计划的生成。生成的查询计划存储在HDFS中，并在随后的MapReduce调用执行。
1.4.3 Hive安装的三种模式
a) 嵌入模式，数据存储在hive自带的derby数据库，只允许一个连接，多用于本地演示demo；
b) 本地模式，一般是mysql，与hive位于同一台服务器，允许多连接，但实际生产环境并不用这种模式；
c) 远程模式，mysql安装在远程服务器上，允许多连接，多用于实际生产环境。
1.4.4 Hive的数据类型
a) 基本数据类型
整型：tinyint/smallint/int/bigint
浮点型：float/double
布尔型：Boolean
字符串：string
b) 复杂数据类型
数组类型：Array，有一系列相同数据类型的元素组成
集合类型：Map，包括key->value键值对，可以通过key值访问元素
结构类型：struct，可以包含不同数据类型的元素，可以通过“点语法”的方式获得这些元素
c) 时间类型
Date、Timestamp
1.4.5 hive与关系型数据库的不同
a) hive和关系数据库存储文件的系统不同，hive使用的是hadoop的HDFS（hadoop的分布式文件系统），关系数据库则是服务器本地的文件系统；
b) hive使用的计算模型是mapreduce，而关系数据库则是自己设计的计算模型；
c) 关系数据库都是为实时查询的业务进行设计的，而hive则是为海量数据做数据挖掘设计的，实时性很差；实时性的区别导致hive的应用场景和关系数据库有很大的不同；
d) Hive很容易扩展自己的存储能力和计算能力，这个是继承hadoop的，而关系数据库在这个方面要比数据库差很多。
1.4.6 Hive的优势
a) 面向超大规模数据集：基于Hadoop生态，Hive具有存储和计算的扩展能力，可支持高可达千亿级的数据集查询。。
b) 支持多种数据格式：Hive支持多种格式数据，如纯文本、RCFile、Parquet、ORC等格式，以及HBase中的数据、ES中的数据等。Hive表一般使用ORC和Parquet格式，二者都是列式存储，压缩率很低，查询效率较高。
c) 易于上手：Hive采用HiveSql的查询方式，将HiveSql查询转换为job在Hadoop集群上执行，使用非常方便。
d) 内置大量UDF：Hive内置了大量用户函数UDF来操作时间、字符串和其他的数据挖掘工具，UDF种类非常丰富。
1.4.7 应用场景
大数据集的批处理作业：如网络日志分析，统计网站某一时间段内的pv、uv，多维度的数据分析。
1.5 Zookeeper
ZooKeeper是一个分布式的，开放源码的分布式应用程序协调服务，是Google的Chubby一个开源的实现，是Hadoop和Hbase的重要组件。它是一个为分布式应用提供一致性服务的软件，提供的功能包括：配置维护、域名服务、分布式同步、组服务等。
ZooKeeper的目标就是封装好复杂易出错的关键服务，将简单易用的接口和性能高效、功能稳定的系统提供给用户。
ZooKeeper本质上是一个分布式的小文件存储系统。原本是Apache Hadoop的一个组件，现在被拆分为一个Hadoop的独立子项目，在Hbase（Hadoop的另外一个被拆分出来的子项目，用于分布式环境下的超大数据量的DBMS）中也用到了ZooKeeper集群。
Hadoop，使用Zookeeper的事件处理确保整个集群只有一个NameNode，存储配置信息等.
HBase，使用Zookeeper的事件处理确保整个集群只有一个HMaster，察觉HRegionServer联机和宕机，存储访问控制列表等。
a) 启动ZK服务: sh bin/zkServer.sh start
b) 查看ZK服务状态: sh bin/zkServer.sh status
c) 停止ZK服务: sh bin/zkServer.sh stop
d) 重启ZK服务: sh bin/zkServer.sh restart
1.6 Hbase
1.6.1 HBase简介
HBase – Hadoop Database，是一个高可靠性、高性能、面向列、可伸缩的分布式存储系统，利用HBase技术可在廉价PC Server上搭建起大规模结构化存储集群。
HBase是Google Bigtable的开源实现，类似Google Bigtable利用GFS作为其文件存储系统，HBase利用Hadoop HDFS作为其文件存储系统；Google运行MapReduce来处理Bigtable中的海量数据，HBase同样利用Hadoop MapReduce来处理HBase中的海量数据；Google Bigtable利用 Chubby作为协同服务，HBase利用Zookeeper作为对应。
在hadoop 的各层系统中，HBase位于结构化存储层，Hadoop HDFS为HBase提供了高可靠性的底层存储支持；Hadoop MapReduce为HBase提供了高性能的计算能力；Zookeeper为HBase提供了稳定服务和failover机制（failover 又称故障切换，指系统中其中一项设备或服务失效而无法运作时，另一项设备或服务即可自动接手原失效系统所执行的工作）；Pig和Hive为HBase提供了高层语言支持，使得在HBase上进行数据统计处理变的非常简单； Sqoop则为HBase提供了方便的RDBMS数据导入功能，使得传统数据库数据向HBase中迁移变的非常方便。
Row Key: 行键，Table的主键，Table中的记录按照Row Key排序；
Timestamp: 时间戳，每次数据操作对应的时间戳，可以看作是数据的version number；
Column Family：列簇，Table在水平方向有一个或者多个Column Family组成，一个Column Family中可以由任意多个Column组成，即Column Family支持动态扩展，无需预先定义Column的数量以及类型，所有Column均以二进制格式存储，用户需要自行进行类型转换。
1.6.2 Hbase的特点
a) 易用性：HBase 采用 JAVA 语言编写, 并提供了易于使用的 JAVA API 供客户端访问, 基本能满足开发者的需求。
b) 强一致性：不论是从客户端还是服务端的视角, HBase 都可以确保并发读写情况下的强一致性, WAL机制为此提供了可靠的保证。
c) 可扩展性强：HBase 作为一款分布式数据库, 具有良好的可扩展性, 扩展方便, 可通过集群扩展不断增强集群的存储能力和请求处理能力。
1.6.3 使用场景
a) 要求写操作吞吐量高：HBase 单台 Regionserver 的写 QPS 可以稳定在 2K~3K , 并且可以通过集群扩展不断增强集群的扩展性, 理论上不存在上限。
b) 海量数据持久化：HBase 是分布式数据库, 可以真正存储海量的数据, 真正解决传统关系型数据库的痛点。
c) 大规模数据集中进行随机访问：HBase 是列式存储, 可以保证在大规模数据集情况下依然具有很好的随机访问性能。
d) 无需全部的关系型数据库特性：HBase 不适用于具有join, 多级索引, 表关系复杂的数据模型场景中。
1.7 Sqoop
Hadoop正成为企业用于大数据分析的最热门选择，但想将你的数据移植过去并不容易。Apache Sqoop正在加紧帮助客户将重要数据从数据库移到Hadoop。随着Hadoop和关系型数据库之间的数据移动渐渐变成一个标准的流程，云管理员们能够利用Sqoop的并行批量数据加载能力来简化这一流程，降低编写自定义数据加载脚本的需求。
Apache Sqoop（SQL-to-Hadoop）项目旨在协助 RDBMS 与 Hadoop 之间进行高效的大数据交流。用户可以在 Sqoop 的帮助下，轻松地把关系型数据库的数据导入到 Hadoop 与其相关的系统 (如HBase和Hive)中；同时也可以把数据从 Hadoop 系统里抽取并导出到关系型数据库里。因此，可以说Sqoop就是一个桥梁，连接了关系型数据库与Hadoop。
sqoop中一大亮点就是可以通过hadoop的mapreduce把数据从关系型数据库中导入数据到HDFS。Sqoop架构非常简单，其整合了Hive、Hbase和Oozie，通过map-reduce任务来传输数据，从而提供并发特性和容错。
Sqoop工作机制:Sqoop在import时，需要制定split-by参数。Sqoop根据不同的split-by参数值来进行切分，然后将切分出来的区域分配到不同map中。每个map中再处理数据库中获取的一行一行的值，写入到HDFS中(由此也可知，导入导出的事务是以Mapper任务为单位)。同时split-by根据不同的参数类型有不同的切分方法，如比较简单的int型，Sqoop会取最大和最小split-by字段值，然后根据传入的num-mappers来确定划分几个区域。
2 Flume
Flume 作为cloudera 开发的实时日志收集系统，受到了业界的认可与广泛应用。Flume 初始的发行版本目前被统称为Flume OG（original generation），属于 cloudera。重构后的版本统称为 Flume NG（next generation）,属于Apache。
2.1 OG与NG比较
架构方面：
Flume OG有三种角色的节点：代理节点agent、收集节点collector、主节点master；
agent负责从各个数据源收集日志数据、将收集到的数据集中到collector,再由collector节点汇总存入到HDFS.而master负责管理agent\collector的活动；
agent、collector都称为node,node的角色根据配置的不同分为逻辑节点和物理节点,对于逻辑节点的区分、配置、使用非常复杂.
agent、collector由source、sink组成,表示当前节点的数据从source传送到sink
以上相对于Flume NG来说:
Flume NG只有一种角色节点：代理节点agent没有collector、master节点,这是最核心的变化.
去除逻辑节点和物理节点的概念和内容
agent节点的组成发生变化,由source、sink、channel三个组件组成。
Zookeeper方面：
Flume OG的稳定性依赖zookeeper,它需要zookeeper对其多类节点的工作进行管理,虽然OG可以使用内存的方式对各类节点进行管理,但需要用户忍受机器出现故障时信息丢失的出现.
Flume NG的节点角色数量由原来的3个缩减为1个,不存在多类角色的问题,所以不再需要zookeeper对各类节点协调的作用,由此脱离了对zookeeper的依赖.
2.2 flume中核心概念
a) Agent
使用JVM 运行Flume。每台机器运行一个agent，但是可以在一个agent中包含多个sources和sinks。
b) Client
生产数据，运行在一个独立的线程。
c) Source
从Client收集数据，传递给Channel。
d) Sink
Channel收集数据，运行在一个独立线程。
e) Channel
连接 sources 和 sinks ，这个有点像一个队列。
f) Events
可以是日志记录、 avro 对象等。
2.3 数据流模型
Flume(水道)以agent为最小的独立运行单位。一个agent就是一个JVM。单agent由Source、Sink和Channel三大组件构成。
Flume的数据流由事件(Event)贯穿始终。事件是Flume的基本数据单位，它携带日志数据(字节数组形式)并且携带有头信息，这些Event由Agent外部的Source，比如上图中的Web Server生成。当Source捕获事件后会进行特定的格式化，然后Source会把事件推入(单个或多个)Channel中。你可以把Channel看作是一个缓冲区，它将保存事件直到Sink处理完该事件。Sink负责持久化日志或者把事件推向另一个Source。很直白的设计，其中值得注意的是，Flume提供了大量内置的Source、Channel和Sink类型。不同类型的Source,Channel和Sink可以自由组合。组合方式基于用户设置的配置文件，非常灵活。比如：Channel可以把事件暂存在内存里，也可以持久化到本地硬盘上。Sink可以把日志写入HDFS, Hbase，甚至是另外一个Source等等。
3 Kafka
3.1 简介和特点
KAFKA是一个分布式的流式平台。特点如下：
a) 弹性扩展：当服务器资源达到限制时候，Kafka 支持在不停服情况下弹性扩容/缩容节点。
b) 大吞吐量：Kafka 支持以增加 partition 个数的方式，来增加整个 topic 的吞吐量。
3.2 使用场景
a) 消息队列：通过 Kafka 作为消息队列，解耦了收消息和发消息的服务，收发过程在毫秒级完成。
b) 海量日志：记录各类访问日志，后端通过顺序读写等技术，增加吞吐量。
4 Presto
Presto是一种分布式SQL查询引擎，用于查询分布在一个或多个异构数据源上的大型数据集。
4.1 Presto的特点
a) 不是数据库：Presto不是传统意义上的数据库，也不是MySQL、PostgreSQL或者Oracle的代替品，它并不存储数据，是一款OLAP分析工具。
b) 多数据源：Presto不仅可以访问HDFS，也可以操作不同的数据源，包括：RDBMS和其他的数据源（例如：Hive、Cassandra）等。一条Presto查询可以将多个数据源的数据进行合并，可以跨越整个组织进行分析。
c) 海量数据：擅长对海量数据(TB或者PB级别)进行复杂的计算分析。
d) 支持SQL：Presto 已经可以完全支持 ANSI SQL，并提供了一个 SQL Shell 给用户，用户可以直接使用ANSI SQL 进行数据查询和计算。
e) 速度快：低延迟高并发的全内存流水线式计算，比Hive快一个数量级。
4.2 使用场景
a) 准实时计算：基准数据若实时更新，Presto可快速完成计算，实现准实时计算的场景。
b) 交互式查询：以SQL语言作为接口的分布式实时查询引擎，可以对PB级的数据进行快速的交互式查询。
5 ClickHouse
ClickHouse 是俄罗斯的Yandex于2016年开源的列式存储数据库（DBMS），主要用于在线分析处理查询（OLAP），能够使用SQL查询实时生成分析数据报告。
5.1 优势特点
a) 快速的明细数据查询：数据按列存储，查询时，将列向量化处并行处理，高效利用cpu，来使用当前服务器上可用的所有资源，充分压榨机器性能，达到亿级数据查询毫秒级返回。
b) 多服务器分布式处理：数据可以保存在不同的shard上，每一个shard都由一组用于容错的replica组成，查询可以并行的在所有shard上进行处理。这些对用户来说是透明的。
5.2 使用场景
a) 高实时性要求
ClickHouse支持在表中定义主键。为了使查询能够快速在主键中进行范围查找，数据总是以增量的方式有序的存储在MergeTree中。因此，数据可以持续不断高效的写入到表中，并且写入的过程中不会存在任何加锁的行为，可达到每秒写入数十万的写入性能；
b) 大规模事件和日志快速分析
clickhouse支持万亿级数据的数据分析需求，达到每秒处理几亿行的吞吐能力，快速返回查询结果；
c) 漏斗分析
clickhouse提供了专用漏斗函数windowFunnel(window)(timestamp, cond1, cond2, cond3, …)，可快速进行漏斗型数据分析；
d) 适合在线查询
没有对数据做任何预处理的情况下以极低的延迟处理查询并将结果加载到用户的页面中。
6 Kudu
Kudu 是一个列式存储管理系统。支持水平可扩展，并具有高可用性特性。
6.1 优势特点
a) 快速的明细数据查询：数据存储在kudu，kudu与Impala紧密集成, impala将谓词下推到kudu，尽可能的接近底层kudu的底层，提高整体查询性能；
b) 高实时性要求：数据可直接低延迟的落入kudu中存储，通过impala进行查询，经内部测试，kudu实时写入性能达到每秒几万条数据。同时数据写入后首先存储在内存，可立即提供查询服务，实时性高；
c) 数据频繁更新：Kudu将底层数据分为base数据文件和delta数据文件，有更新的数据写入delta文件，后期自动做数据的merge，所以支持数据的频繁更新操作。
6.2 使用场景
a) 实时更新的应用：Kudu 通过高效的列式扫描提供了快速插入和更新的强大组合，从而在单个存储层上实现了实时分析用例，刚刚到达的数据就马上能被被终端用户使用访问到；
b) 时间序列应用：kudu可以对某几列数据进行hash分区，将数据均匀的打散在不同节点，对于访问时序数据，不存在热点数据问题，充分利用集群性能。
7 Kylin
Kylin是一个开源的分布式分析引擎，通过预计算构建cube实现快速查询分析。
7.1 优势特点
a) 交互式查询能力：通过Kylin，用户可以在kylin查询页面上与数据进行亚秒级交互，在同样的数据集上提供比Hive更好的性能；
b) kylin Cube多维数据的计算：Cube由多个Cuboid组合而成，Cuboid上的数据是原始数据聚合的数据，因此创建Cube可以看作是在原始数据导入时做的一个预计算预处理的过程。Kylin的强大之处在于充分利用了Hadoop的MapReduce并行处理的能力，高效处理导入的数据。
7.2 应用场景
查询类型比较固定的数据分析：通过固定的查询类型构建cube，将所有的维度组合事先计算，存储于HBase中，以空间换时间，提供快速查询
数据与hadoop紧密结合：数据存于HDFS，利用Hive将HDFS数据以关系数据方式存取，通过构建cube存储于Hbase。
8 Spark
Apache Spark是专为大规模数据处理而设计的快速通用的计算引擎。
8.1 优势特点
a) 快速
Spark使用最先进的DAG调度程序，查询优化器和物理执行引擎，实现批处理和流的高性能。与Hadoop的MapReduce相比，Spark基于内存的运算要快100倍以上，而基于磁盘的运算也要快10倍以上；
b) 易用
Spark支持Java、Python和Scala的API，还支持超过80种高级算子，可以轻松构建并行应用程序；
c) 通用
Spark提供了统一的解决方案。Spark可以用于批处理、交互式查询（通用Spark SQL）、流处理（通过Spark Streaming）、机器学习（通过Spark MLlib）和图计算（通过Spark GraphX）。这些不同类型的处理都可以在同一应用中无缝使用；
d) 到处运行
Spark可以使用自带的集群模式运行，也可以在EC2、在Hadoop Yarn上、Mesos上或Kubernetes上运行，同时可以访问HDFS、Alluxio、Cassandra、HBase、Hive及其它上百种数据源中的数据。
8.2 应用场景
a) 批处理
Spark的核心提供了分布式任务调度和基本的I/O功能，提供了基本的程序抽象RDD（弹性分布式数据集）。RDD是一个可以并行操作并有容错机制的数据集合，简化了编程复杂性，操纵RDD的方法类似于操纵本地数据集合。另外Spark SQL提供了领域特定语言，可使用Scala、Java或Python来操纵DataFrame/DataSet。这些都可用于批处理；
b) 交互式查询或执行代码
Spark Thriftserver支持使用命令行界面和ODBC/JDBC服务器执行SQL。而交互式的Python和Scala的Shell可以使用Spark集群来验证解决问题的方法，而不是像以前一样，需要打包、上传集群、验证等；
c) 流式计算
Spark Streaming充分利用Spark核心的快速调度能力来运行流分析。它截取小批量的数据并对之运行RDD转换。这种设计使流分析可在同一个引擎内使用同一组为批量分析编写而撰写的应用程序代码；
d) 机器学习
MLlib是Spark上分布式机器学习框架，可使用许多常见的机器学习和统计算法，简化大规模机器学习时间；
e) 图形处理
GraphX是Spark上的分布式图形处理框架。它提供了一组API，可用于表达图表计算并可以模拟Pregel抽象化。GraphX还对这种抽象化提供了优化运行。
9 Flink
Flink 是一个面向分布式数据流处理和批量数据处理的开源计算平台，在流式处理方面具有高吞吐、低延迟、高性能的特点，支持Exactly-once语义、高度灵活的窗口操作、event time等等。
9.1 优势特点
a) 快速
快，是Flink的主要特点。利用基于内存的数据流，并将迭代处理算法深度集成到系统的运行时中，这样，Flink使得系统能够以极快的速度处理数据密集型和迭代任务；
b) 可靠
轻量级分布式快照（Snapshot）实现的容错，在流处理失败时，通过这些Snapshot可以恢复数据流处理，支持Exactly-once语义；
c) 强大
灵活的窗口，丰富的表达能力，基于事件时间处理机制配合水位线功能可以有效地处理乱序流、解决消息延迟的问题；
d) 易用
面向用户提供了简单的DataStream和table sql API，在无需进行任何配置的情况下，Flink就可以运行在Yarn上。
9.2 应用场景
a) 实时ETL
对事实表的每一条新增记录进行转化计算，同时join维度表来扩充记录字段，将数据清洗延迟控制在秒以内；
b) 实时监控报警
对重要的事件做实时处理统计，动态获取报警规则，针对报警事件进行自定义处理；
c) 统计网站PV，UV
在大数据量下，传统数据库或者HADOOP（hbase…）的count效率都不高。使用flink对用户访问记录增量做实时的窗口计算，提供更高的吞吐和更低的延时；
d) 风控安全管理
使用CEP自定义匹配规则用来检测无尽数据流中的复杂事件。例如在安全应用中侦测异常行为；在金融应用中查找价格、交易量和其他行为的模式。