【大数据专题】分析对比

1 . 简述Spark和Flink的区别 ？

1、设计理念方面
Spark的技术理念是使用微批来模拟流的计算，基于Micro-batch，数据流以时间为单位被切分为一个个 批次，通过分布式数据集RDD进行批量处理，是一种伪实时。
Flink是基于事件驱动的，是面向流的处理框架，Flink基于每个事件一行一行地流式处理，是真正的流式 计算。另外它也可以基于流来模拟批进行计算实现批处理。
2、架构方面

Spark在运行时的主要角色包括：Master、Worker、Driver、Executor。
Flink 在运行时主要包含：Jobmanager、Taskmanager和Slot。
3、流处理方面
Spark基于微批量处理，把流数据看成是一个个小的批处理数据块分别处理，所以延迟性只能做到秒 级。
Flink基于每个事件处理，每当有新的数据输入都会立刻处理，是真正的流式计算，支持毫秒级计算。
由于相同的原因，Spark只支持基于时间的窗口操作（处理时间或者事件时间），而Flink支持的窗口操 作则非常灵活，不仅支持时间窗口，还支持基于数据本身的窗口（另外还支持基于time、count、session，以及data-driven的窗口操作），开发者可以自由定义想要的窗口操作。
4、任务调度方面
Spark Streaming 支持的时间机制有限，只支持处理时间。使用processing time模拟event time必然会有误差， 如果产生数据堆积的话，误差则更明显。
Flink支持三种时间机制：事件时间，注入时间，处理时间，同时支持 watermark 机制处理迟到的数据, 说明Flink在处理乱序大实时数据的时候,更有优势。
5、容错机制方面
Spark Streaming的容错机制是基于RDD的容错机制，会将经常用的RDD或者对宽依赖加Checkpoint。利用Spark Streaming的direct方式与Kafka可以保证数据输入源的，处理过程，输出过程符合exactly once。
Flink 则使用两阶段提交协议来保证exactly once。
6、吞吐量与延迟方面
Spark是基于微批的，而且流水线优化做的很好，所以说他的吞入量是最大的，但是付出了延迟的代 价，它的延迟是秒级;
Flink是基于事件的，消息逐条处理，而且他的容错机制很轻量级，所以他能在兼顾高吞吐量的同时又有 很低的延迟，它的延迟能够达到毫秒级;
7、迭代计算方面
Spark对机器学习的支持很好，因为可以在内存中缓存中间计算结果来加速机器学习算法的运行。但是 大部分机器学习算法其实是一个有环的数据流，在Spark中，却是用无环图来表示。而Flink支持在运行 时间中的有环数据流，从而可以更有效的对机器学习算法进行运算。
8、时间机制方面
Spark Streaming 支持的时间机制有限，只支持处理时间。
Flink 支持了流处理程序在时间上的三个定义：处理时间、事件时间、注入时间。同时也支持 watermark
机制来处理滞后数据。

2 . 简述Flink和Spark Streaming处理数据的时候，分别怎么做？各自优势点 ？

Spark的技术理念是使用微批来模拟流的计算，基于Micro-batch，数据流以时间为单位被切分为一个个 批次，通过分布式数据集RDD进行批量处理，是一种伪实时。

Flink是基于事件驱动的，是面向流的处理框架，Flink基于每个事件一行一行地流式处理，是真正的流式 计算。另外它也可以基于流来模拟批进行计算实现批处理。
Spark基于微批量处理，把流数据看成是一个个小的批处理数据块分别处理，所以延迟性只能做到秒 级。
Flink基于每个事件处理，每当有新的数据输入都会立刻处理，是真正的流式计算，支持毫秒级计算。
由于相同的原因，Spark只支持基于时间的窗口操作（处理时间或者事件时间），而Flink支持的窗口操 作则非常灵活，不仅支持时间窗口，还支持基于数据本身的窗口（另外还支持基于time、count、session，以及data-driven的窗口操作），开发者可以自由定义想要的窗口操作

3 . 简述为什么你觉得Flink比Spark Streaming好 ？

1、反压机制
Flink 在数据传输过程中使用了分布式阻塞队列，一个阻塞队列中，当队列满了以后发送者会被天然阻塞住，这种阻塞功能相当于给这个阻塞队列提供了反压的能力。
Spark Streaming 为了实现反压这个功能，在原来的架构基础上构造了一个“速率控制器”，这个“速率控制器”会根据几个属性，如任务的结束时间、处理时长、处理消息的条数等计算一个速率。在实现控制 数据的接收速率中用到了一个经典的算法，即“PID 算法”。
2、延迟方面
Spark Streaming是秒级别的Structured Streaming是毫秒级别的
Flink是亚秒级别的
3、状态存储方面
Spark的状态管理目前做的比较简单,只有两个对应的算子（UpdateStateByKey和mapWithState）。
Flink 提供文件、内存、RocksDB 三种状态存储，五种类型的状态，（ValueState，ListState，
ReducingState，AggregatingState，FoldingState，MapState）。
4、灵活的窗口
Spark只能根据处理时间窗口批量处理。
Flink可以基于处理时间，数据时间，没有记录等的窗口。
5、实时方面
Flink是真正的实时计算，在状态数据和Checkpoint容错上做的比较好，能够做到exactly once

4 . 简述Spark Streaming相比Flink有什么优点 ？

Spark中分布式RDD缓存是一个非常强大的功能，在这一点上比Flink好用很多。比如在实时计算过程中需 要一些离线大数据与之关联，Spark相比占有比较大的优势。
Saprk比Flink还有占优的地方就是Spark的executor死了之后不会导致整个job挂掉，而是会创建新的executor再重新执行失败的任务。而Flink的某个task manager死了会导致整个job就失败了，必须设置
checkpoint来进行容错。在机器迁移过程中Spark要比Flink方便许多

5 . 简述Flink和Spark对于批处理的区别 ？

Flink是流处理，用流的思想做批处理。
Spark是微批处理，用批的思想做流处理。
Spark基于微批量处理，把流数据看成是一个个小的批处理数据块分别处理，所以延迟性只能做到秒
级。而Flink基于每个事件处理，每当有新的数据输入都会立刻处理，是真正的流式计算，支持毫秒级计 算。由于相同的原因，Spark只支持基于时间的窗口操作（处理时间或者事件时间），而Flink支持的窗 口操作则非常灵活，不仅支持时间窗口，还支持基于数据本身的窗口(另外还支持基于time、count、session，以及data-driven的窗口操作)，开发者可以自由定义想要的窗口操作。

6 . 简述Flink+Kafka怎么保证精准一次性消费 ？

两阶段提交+checkpoint+barriy+ouset回拨

7 . 简述Hive和MySQL不同 ？

1）查询语言不同：hive是hql语言，mysql是sql语句；
2）数据存储位置不同：hive是把数据存储在hdfs上，而mysql数据是存储在自己的系统中；
3）数据格式：hive数据格式可以用户自定义，mysql有自己的系统定义格式；
4）数据更新：hive不支持数据更新，只可以读，不可以写，而sql支持数据更新；
5）索引：hive没有索引，因此查询数据的时候是通过mapreduce很暴力的把数据都查询一遍，也造成了
hive查询数据速度很慢的原因，而mysql有索引；
6）延迟性：hive延迟性高，原因就是上边一点所说的，而mysql延迟性低；
7）数据规模：hive存储的数据量超级大，而mysql只是存储一些少量的业务数据；
8）底层执行原理：hive底层是用的mapreduce，而mysql是excutor执行器；
9）使用环境：mysql使用环境几乎没有限制，hive是基于hadoop的；
10）mysql的handle的数据量较小，而hive的能handle数据量较大；
11）可扩展性：mysql的可扩展性较低，而hive的扩展性较高；
12）mysql可以允许局部数据插入、更新、删除等，而hive不支持局部数据的操作

8 . 简述Hive与HBase的区别 ？

Hive是基于Hadoop的一个数据仓库工具，可以将结构化的数据文件映射为一张数据库表，并提供简单 的sql查询功能，可以将sql语句转换为MapReduce任务进行运行。
HBase是Hadoop的数据库，一个分布式、可扩展、大数据的存储。
1、两者的特点
Hive帮助熟悉SQL的人运行MapReduce任务。因为它是JDBC兼容的，同时，它也能够和现存的SQL工具 整合在一起。运行Hive查询会花费很长时间，因为它会默认遍历表中所有的数据。虽然有这样的缺点， 一次遍历的数据量可以通过Hive的分区机制来控制。分区允许在数据集上运行过滤查询，这些数据集存 储在不同的文件夹内，查询的时候只遍历指定文件夹(分区)中的数据。这种机制可以用来，例如，只处 理在某一个时间范围内的文件，只要这些文件名中包括了时间格式。
HBase通过存储key/value来工作。它支持四种主要的操作：增加或者更新行，查看一个范围内的cell，获 取指定的行，删除指定的行、列或者是列的版本。版本信息用来获取历史数据(每一行的历史数据可以被 删除，然后通过Hbase compactions就可以释放出空间)。虽然HBase包括表格，但是schema仅仅被表格和列簇所要求，列不需要schema。Hbase的表格包括增加/计数功能。
2、限制
Hive目前不支持更新操作。另外，由于hive在hadoop上运行批量操作，它需要花费很长的时间，通常是 几分钟到几个小时才可以获取到查询的结果。Hive必须提供预先定义好的schema将文件和目录映射到 列，并且Hive与ACID不兼容。
HBase查询是通过特定的语言来编写的，这种语言需要重新学习。类SQL的功能可以通过Apache Phonenix实现，但这是以必须提供schema为代价的。另外，Hbase也并不是兼容所有的ACID特性，虽然 它支持某些特性。最后但不是最重要的–为了运行Hbase，Zookeeper是必须的，zookeeper是一个用来进 行分布式协调的服务，这些服务包括配置服务，维护元信息和命名空间服务。
3、应用场景
Hive适合用来对一段时间内的数据进行分析查询，例如，用来计算趋势或者网站的日志。Hive不应该用 来进行实时的查询。因为它需要很长时间才可以返回结果。
Hbase非常适合用来进行大数据的实时查询。Facebook用Hbase进行消息和实时的分析。它也可以用来统 计Facebook的连接数。
4、小总
Hive和Hbase是两种基于Hadoop的不同技术。Hive是一种类SQL的引擎，并且运行MapReduce任务，
Hbase是一种在Hadoop之上的NoSQL的Key/vale数据库。当然，这两种工具是可以同时使用的。就像用
Google来搜索，用FaceBook进行社交一样，Hive可以用来进行统计查询，HBase可以用来进行实时查 询，数据也可以从Hive写到Hbase，设置再从Hbase写回Hive。

9 . 简述Hive与HDFS的关系与区别 ？

HDFS：Hadoop Distributed File System，Hadoop分布式文件系统，主要用来解决海量数据的存储问题。
Hive 是基于 Hadoop 的一个数据仓库工具，可以将结构化的数据文件映射为一张数据库表，并提供完整的 sql 查询功能，可以将 sql 语句转换为 MapReduce 任务进行运行。可以通过类 SQL 语句快速实现简单的 MapReduce 统计，不必开发专门的 MapReduce 应用，十分适合数据仓库的统计分析。
Hive 是建立在 Hadoop 上的数据仓库基础构架。它提供了一系列的工具，可以用来进行数据提取转化加载，这是一种可以存储、查询和分析存储在 Hadoop 中的大规模数据的机制。Hive 定义了简单的类 SQL 查询语言，称为 HQL，它允许熟悉 SQL 的用户查询数据。同时，这个语言也允许熟悉 MapReduce 开发者的开发自定义的 mapper 和 reducer 来处理内建的 mapper 和 reducer 无法完成的复杂的分析工作

10 . 简述Spark和Hive的区别 ？

1、Hive
Hive是基于Hadoop的数据仓库工具，同时又是查询引擎，Spark SQL只是取代的Hive的查询引擎这一部分，企业可以使用Hive+Spark SQL进行开发。
Hive的主要工作如下：
把HQL翻译长map-reduce的代码，并且有可能产生很多mapreduce的job
把生产的Mapreduce代码及相关资源打包成jar并发布到Hadoop的集群当中并进行运行
Hive默认情况下用derby存储元数据，所以在生产环境下一般会采用多用户的数据库进行元数据的存储， 并可以读写分离和备份，一般使用主节点写，从节点读，一般使用MySQL。
2、Spark
Spark SQL处理一切存储介质和各种格式的数据(可以扩展sparksql来读取更多类型的数据)； Spark SQL把数据仓库的计算速度推向了新的高度（Tungsten成熟之后会更厉害）；
Spark SQL推出的Dataframe可以让数据仓库直接使用机器学习，图计算等复杂算法； Hive+Spark SQL+DataFrame使用：
Hive：负责廉价的数据仓库存储Spark Sql：负责高速的计算DataFrame：负责复杂的数据挖掘
3、Hive on Spark与Spark Sql的区别
Hive on Spark大体与Spark SQL结构类似，只是SQL解析器不同，但是计算引擎都是Spark。
4、Hive on Mapreduce和Spark SQL使用场景Hive on Mapreduce场景
Hive的出现可以让那些精通SQL技能、但是不熟悉MapReduce 、编程能力较弱与不擅长Java语言的用户能够在HDFS大规模数据集上很方便地利用SQL语言查询、汇总、分析数据，毕竟精通SQL语言 的人要比精通Java语言的多得多。

Hive适合处理离线非实时数据。
Spark SQL场景
Spark既可以运行本地local模式，也可以以Standalone、cluster等多种模式运行在Yarn、Mesos上， 还可以运行在云端例如EC2。此外，Spark的数据来源非常广泛，可以处理来自HDFS、HBase、
Hive、Cassandra、Tachyon上的各种类型的数据。
实时性要求或者速度要求较高的场所。
5、Hive on Mapreduce和Spark SQL性能对比
Spark SQL和Hive on Spark时间差不多，但都比Hive on mapreduce快很多，官方数据认为Spark会被传统
mapreduce快10-100倍。

11 . 简述Spark和Hive的联系 ？

通常来说，Spark和Hive本质上是没有关系的，两者可以互不依赖。但是在企业实际应用中，经常把二者 结合起来使用。Spark和Hive结合和使用的方式，主要有以下三种：
1、Hive on Spark
在这种模式下，数据是以table的形式存储在hive中的，用户处理和分析数据，使用的是Hive语法规范的
hql。 但这些hql，在用户提交执行时，底层会经过解析编译以Spark作业的形式来运行。（事实上， Hive早期只支持一种底层计算引擎，即MapReduce，后期在Spark因其快速高效占领大量市场后，Hive社 区才主动拥抱Spark，通过改造自身代码，支持了Spark作为其底层计算引擎。目前Hive支持了三种底层 计算引擎，即mr，Tez和Spark。用户可以通过set hive.execution.engine=mr/tez/spark来指定具体使用哪个底层计算引擎。
2、Spark on Hive
Spark本身只负责数据计算处理，并不负责数据存储。其计算处理的数据源，可以以插件的形式支持很 多种数据源，这其中也包括hive。当我们使用Spark来处理分析存储在Hive中的数据时，这种模式就称 为为Spark on Hive。这种模式下，用户可以使用Spark的java/scala/pyhon/r等api，也可以使用Spark语法规范的sql ，甚至也可以使用hive语法规范的hql（之所以也能使用hql，是因为Spark 在推广面世之初， 就主动拥抱了hive，通过改造自身代码提供了原生对hql包括hive udf的支持，这也是市场推广策略的一种吧）。
3、Spark+Spark Hive catalog
这是Spark和Hive结合的一种新形势，随着数据湖相关技术的进一步发展，这种模式现在在市场上受到了 越来越多用户的青睐。其本质是，数据以orc/parquet/delta lake等格式存储在分布式文件系统如hdfs或对象存储系统如s3中，然后通过使用Spark计算引擎提供的scala/java/python等api或Spark语法规范的sql 来进行处理。由于在处理分析时针对的对象是table，而table的底层对应的才是hdfs/s3上的文件/对象， 所以我们需要维护这种table到文件/对象的映射关系，而Spark自身就提供了Spark Hive catalog来维护这种table到文件/对象的映射关系。注意这里的Spark Hive catalog，其本质是使用了Hive的metasore相关
api来读写表到文件/对象的映射关系（以及一起其他的元数据信息）到metasore db如mysql，postgresql 等数据库中。（由于Spark编译时可以把Hive metastore api等相关代码一并打包到Spark的二进制安装包中，所以使用这种模式，我们并不需要额外单独安装hive）

12 . 简述Hive和传统数据库的区别 ？

Hive 和关系数据库存储文件的系统不同，Hive 使用的是 hadoop 的 HDFS（hadoop 的分布式文件系统），关系数据库则是服务器本地的文件系统；
Hive 使用的计算模型是 mapreduce，而关系数据库则是自己设计的计算模型；
关系数据库都是为实时查询的业务进行设计的，而 Hive 则是为海量数据做数据挖掘设计的，实时性很差；实时性的区别导致 Hive 的应用场景和关系数据库有很大的不同；
Hive 很容易扩展自己的存储能力和计算能力，这个是继承 hadoop 的，而关系数据库在这个方面要比数据库差很多。

13 . 简述Spark和Hive对比，谁更好，你觉得为什么 ？

Spark和Hive谁更好，要看实际使用场景。
Hive：数据存储和清洗，处理海量数据，比如一个月、一个季度、一年的数据量，依然可以处理，虽然 很慢。
Spark SQL：数据清洗和流式计算，上述情况下Spark SQL不支持，无法处理，因为其基于内存，量级过大承受不住，并且性价比不如Hive高。
综合来看：
Hive的强项在于：1）大数据存储；2）通过sql方式进行MapReduce操作，降低大数据使用门槛。
Spark强项在于：1）基于内存操作，速度快；2）流式计算。
运用上大多两者集合，Hive负责数据仓库存储，Spark sql负责计算，并结合DataFrame进行复杂的数据挖掘（包括机器学习、图计算等复杂算法）

14 . 简述MySQL和HBase的对比 ？

Mysql：关系型数据库，主要面向OLTP，支持事务，支持二级索引，支持sql，支持主从、Group
Replication架构模型（此处以Innodb为例，不涉及别的存储引擎）。
HBase：底层使用HDFS（存储计算分离），支持海量数据读写（尤其是写），支持上亿行、上百万列 的，面向列的分布式NoSql数据库。天然分布式（数据分片、故障自恢复)，主从架构，不支持事务，不 支持二级索引，不支持sql。
1、数据存储方式
1） MySQL
MySQL采用行存储，MySQL行存储的方式比较适合OLTP业务。

MySQL优点：
体积小、速度快、总体拥有成本低，开源； 支持多种操作系统；
是开源数据库，提供的接口支持多种语言连接操作 ；
MySQL的核心程序采用完全的多线程编程。线程是轻量级的进程，它可以灵活地为用户提供服务， 而不过多的系统资源。用多线程和C语言实现的mysql能很容易充分利用CPU；
MySql有一个非常灵活而且安全的权限和口令系统。当客户与MySql服务器连接时，他们之间所有 的口令传送被加密，而且MySql支持主机认证；
支持ODBC for Windows， 支持所有的ODBC 2.5函数和其他许多函数， 可以用Access连接MySql服务器， 使得应用被扩展；
支持大型的数据库， 可以方便地支持上千万条记录的数据库。作为一个开放源代码的数据库，可以针对不同的应用进行相应的修改；
拥有一个非常快速而且稳定的基于线程的内存分配系统，可以持续使用面不必担心其稳定性；
MySQL同时提供高度多样性，能够提供很多不同的使用者介面，包括命令行客户端操作，网页浏览 器，以及各式各样的程序语言介面，例如C+，Perl，Java，PHP，以及Python。你可以使用事先包 装好的客户端，或者干脆自己写一个合适的应用程序。MySQL可用于Unix，Windows，以及OS/2等 平台，因此它可以用在个人电脑或者是服务器上。
MySQL缺点：
不支持热备份；
MySQL最大的缺点是其安全系统，主要是复杂而非标准，另外只有到调用mysqladmin来重读用户 权限时才发生改变；
没有一种存储过程(Stored Procedure)语言，这是对习惯于企业级数据库的程序员的最大限制； MySQL的价格随平台和安装方式变化。Linux的MySQL如果由用户自己或系统管理员而不是第三方 安装则是免费的，第三方案则必须付许可费。Unix或linux 自行安装 免费 、Unix或Linux 第三方安装收费。
2） HBase HBase是面向列的NoSql数据库，列存储的方式比较适合OLAP业务，而HBase采用了列族的方式平衡了
OLTP和OLAP，支持水平扩展，如果数据量比较大、对性能要求没有那么高、并且对事务没有要求的
话，HBase也是个不错的选择。
HBase优点：
列的可以动态增加，并且列为空就不存储数据，节省存储空间
HBase自动切分数据，使得数据存储自动具有水平scalability
HBase可以提供高并发读写操作的支持
HBase缺点：
不能支持条件查询，只支持按照Row key来查询
暂时不能支持Master server的故障切换，当Master宕机后，整个存储系统就会挂掉（HBase虽然本身不能故障切换，但是可以配合ZooKeeper来实现HMaster主备节点的failover）
2、适用场景

Mysql Hbase
行存储 列式存储
适用于OLTP业务 平衡了OLTP、OLAP业务
单机、可扩展性差 水平扩展
支持事务 不支持事务
强一致性 强一致性，时间线一致性
支持二级索引 不支持二级索引
支持全文索引 不支持全文索引

3、关系型数据库
优点：
数据之间有关系，进行数据的增删改查的时候是非常方便的关系型数据库是有事务操作的，保证数据的完整性和一致性
缺点：
因为数据和数据是有关系的，底层是运行了大量的算法，大量算法会降低系统的效率，会降低性能 面对海量数据的增删改查的时候会显的无能为力
海量数据对数据进行维护变得非常的无力
因此，关系型数据库适合处理一般量级的数据
4、非关系型数据库
为了处理海量数据，非关系数据库设计之初就是为了替代关系型数据库的关系优点：
海量数据的增删改查是可以的海量数据的维护和处理非常轻松
缺点：
数据和数据没有关系，他们之间就是单独存在的
非关系数据库没有关系，没有强大的事务关系，没有保证数据的完整性和安全性

15 . 简述Spark和Hadoop之间的区别 ？

1、Hadoop
Hadoop是一个由Apache基金会所开发的分布式系统基础架构。 用户可以在不了解分布式底层细节的情况下，开发分布式程序。充分利用集群的威力进行高速运算和存储。 Hadoop实现了一个分布式文件系统（Hadoop Distributed File System ，HDFS）。HDFS 有高容错性的特点，并且设计用来部署在低廉的
（low-cost）硬件上；而且它提供高吞吐量（high throughput）来访问应用程序的数据，适合那些有着

超大数据集（large data set）的应用程序。HDFS放宽了（relax）POSIX的要求，可以以流的形式访问
（streaming access）文件系统中的数据。
Hadoop的框架最核心的设计就是：HDFS 和 MapReduce。HDFS为海量的数据提供了存储，而MapReduce
为海量的数据提供了计算。
2、Spark
Apache Spark 是专为大规模数据处理而设计的快速通用的计算引擎。Spark 是UC Berkeley AMP lab (加州大学伯克利分校的AMP实验室)所开源的类Hadoop MapReduce的通用并行框架，Spark 拥有Hadoop MapReduce所具有的优点；但不同于MapReduce的是——Job中间输出结果可以保存在内存中，从而不再 需要读写HDFS，因此Spark能更好地适用于数据挖掘与机器学习等需要迭代的 MapReduce 的算法。
Spark 在某些工作负载方面表现得更加优越，换句话说，Spark 启用了内存分布数据集，除了能够提供交互式查询外，它还可以优化迭代工作负载。
Spark 是在 Scala 语言中实现的，它将 Scala 用作其应用程序框架。与 Hadoop 不同，Spark 和 Scala 能够紧密集成，其中的 Scala 可以像操作本地集合对象一样轻松地操作分布式数据集。 尽管创建 Spark 是为了支持分布式数据集上的迭代作业，但是实际上它是对 Hadoop 的补充，可以在 Hadoop 文件系统中并行运行。通过名为 Mesos 的第三方集群框架可以支持此行为。
3、数据的存储和处理区别
Hadoop实质上更多是一个分布式系统基础架构: 它将巨大的数据集分派到一个由普通计算机组成的集群中的多个节点进行存储，同时还会索引和跟踪这些数据，大幅度提升大数据处理和分析效率。Hadoop 可以独立完成数据的存储和处理工作，因为其除了提供HDFS分布式数据存储功能，还提供MapReduce 数据处理功能。
Spark 是一个专门用来对那些分布式存储的大数据进行处理的工具，没有提供文件管理系统，自身不会进行数据的存储。它必须和其他的分布式文件系统进行集成才能运作。可以选择Hadoop的HDFS,也可以 选择其他平台。
4、处理速度区别
Hadoop是磁盘级计算，计算时需要在磁盘中读取数据；其采用的是MapReduce的逻辑，把数据进行切片 计算用这种方式来处理大量的离线数据。
Spark，它会在内存中以接近“实时”的时间完成所有的数据分析。Spark的批处理速度比MapReduce快近
10倍，内存中的数据分析速度则快近100倍。比如实时的市场活动，在线产品推荐等需要对流数据进行 分析场景就要使用Spark。
5、灾难恢复
Hadoop将每次处理后的数据写入磁盘中，对应对系统错误具有天生优势。
Spark的数据对象存储在弹性分布式数据集(RDD:)中。这些数据对象既可放在内存，也可以放在磁盘，所 以RDD也提供完整的灾难恢复功能。

16 . 简述Spark为什么比MapReduce运行快？原因有哪些 ？

1、Spark是基于内存进行数据处理的，MapReduce是基于磁盘进行数据处理的
MapReduce的设计：中间结果保存在文件中，提高了可靠性，减少了内存占用，但是牺牲了性能，因为 数据没经过一次处理，都要保存到磁盘，然后再读取进行后续处理。
Spark的设计：数据在内存中进行交换，要快一些，所以性能方面比MapReduce要好。

2、Spark中具有DAG有向无环图，DAG有向无环图在此过程中减少了shuGle以及落地磁盘的次数
Spark 计算比 MapReduce 快的根本原因在于 DAG 计算模型。一般而言，DAG 相比MapReduce 在大多数情况下可以减少 shuule 次数。Spark 的 DAGScheduler 相当于一个改进版的 MapReduce，如果计算不涉及与其他节点进行数据交换，Spark 可以在内存中一次性完成这些操作，也就是中间结果无须落盘，减少了磁盘 IO 的操作。但是，如果计算过程中涉及数据交换，Spark 也是会把 shuule 的数据写磁盘的！ 有一个误区，Spark 是基于内存的计算，所以快，这不是主要原因，要对数据做计算，必然得加载到内存，Hadoop 也是如此，只不过 Spark 支持将需要反复用到的数据给 Cache 到内存中，减少数据加载耗时，所以 Spark 跑机器学习算法比较在行（需要对数据进行反复迭代）。Spark 基于磁盘的计算也是比Hadoop 快。刚刚提到了 Spark 的 DAGScheduler 是个改进版的 MapReduce，所以 Spark天生适合做批处理的任务。Hadoop 的 MapReduce 虽然不如 spark 性能好，但是 HDFS 仍然是业界的大数据存储标准。
3、Spark是粗粒度资源申请，也就是当提交spark application的时候，application会将所有的资源申请完毕，如果申请不到资源就等待，如果申请到资源才执行application，task在执行的时候就不需要自己去 申请资源，task执行快，当最后一个task执行完之后task才会被释放。优点是执行速度快，缺点是不能使 集群得到充分的利用
MapReduce是细粒度资源申请，当提交application的时候，task执行时，自己申请资源，自己释放资
源，task执行完毕之后，资源立即会被释放，task执行的慢，application执行的相对比较慢。优点是集群 资源得到充分利用，缺点是application执行的相对比较慢。
Spark是基于内存的，而MapReduce是基于磁盘的迭代。

17 . 简述Spark和MapReduce之间的区别？各自优缺点 ？

1、性能方面
Spark在内存中处理数据，而MapReduce 是通过map和reduce操作在磁盘中处理数据。因此从这个角度上讲Spark的性能应该是超过MapReduce的。
然而，既然在内存中处理，Spark就需要很大的内存容量。就像一个标准的数据库系统操作一样，Spark 每次将处理过程加载到内存之中，然后该操作作为缓存一直保持在内存中直到下一步操作。如果Spark 与其它资源需求型服务一同运行在YARN上，又或者数据块太大以至于不能完全读入内存，此时Spark的 性能就会有很大的降低。
与此相反，MapReduce会在一个工作完成的时候立即结束该进程，因此它可以很容易的和其它服务共同 运行而不会产生明显的性能降低。
当涉及需要重复读取同样的数据进行迭代式计算的时候，Spark有着自身优势。 但是当涉及单次读取、类似ETL（抽取、转换、加载）操作的任务，比如数据转化、数据整合等时，MapReduce绝对是不二之 选，因为它就是为此而生的。
小结：当数据大小适于读入内存，尤其是在专用集群上时，Spark表现更好；MapReduce适用于那些数 据不能全部读入内存的情况，同时它还可以与其它服务同时运行。
2、使用难度方面

Spark 有着灵活方便的Java，Scala和 Python 的API，同时对已经熟悉 SQL 的技术员工来说， Spark 还适用 Spark SQL（也就是之前被人熟知的 Shark）。多亏了 Spark 提供的简单易用的构造模块，我们可以很容易的编写自定义函数。它甚至还囊括了可以即时反馈的交互式命令模式。
Hadoop MapReduce是用Java编写的，但由于其难于编程而备受诟病。尽管需要一定时间去学习语法，
Pig还是在一定程度上简化了这个过程，Hive也为平台提供了SQL的兼容。一些Hadoop工具也可以无需编 程直接运行MapReduce任务。Xplenty就是一个基于Hadoop的数据整合服务，而且也不需要进行任何编 程和部署。
尽管Hive提供了命令行接口，但MapReduce并没有交互式模式。诸如Impala，Presto和Tez等项目都在尝 试希望为Hadoop提供全交互式查询模式。
安装与维护方面，Spark并不绑定在Hadoop上，虽然在Hortonworks（HDP 2.2版）和Cloudera（CDH 5
版）的产品中Spark和MapReduce都包含在其分布式系统中。（注：Cloudera，Hortonworks及MapR是
Hadoop领域三大知名的初创公司，致力于打造更好的Hadoop企业版应用）。
小结：Spark更易于编程，同时也包含交互式模式；MapReduce不易编程但是现有的很多工具使其更易 于使用。
3、成本方面
Spark 集群的内存至少要和需要处理的数据块一样大，因为只有数据块和内存大小合适才能发挥出其最优的性能。所以如果真的需要处理非常大的数据，Hadoop 绝对是合适之选，毕竟硬盘的费用要远远低于内存的费用。
考虑到 Spark 的性能标准，在执行相同的任务的时候，需要的硬件更少而运行速度却更快，因此应该是更合算的，尤其是在云端的时候，此时只需要即用即付。
在技术人员方面，即使 Hadoop 从 2005 年就开始普及，但是 MapReduce 方面的专家仍然存在着短缺。而对于从 2010 ## 年才开始普及的 Spark ，这又意味着什么呢？ 或许投身 Spark 学习的人正在快速增加， 但是相比于 Hadoop MapReduce 仍然存在着更大的技术人才的缺口。
进一步讲，现存了大量的 Hadoop 即服务的资料和基于 Hadoop 的服务（比如我们 Xplenty 的数据整合服务），这些都降低对技术人员能力和底层硬件知识的要求。相比之下，几乎没有现有可选的 Spark 服务，仅有的那些也是新产品。
小结：根据基准要求， Spark 更加合算， 尽管人工成本会很高。依靠着更多熟练的技术人员和 Hadoop
即服务的供给， Hadoop MapReduce 可能更便宜。
4、兼容性
Spark既可以单独运行，也可以在 Hadoop YARN 上，或者在预置 Mesos 上以及云端。它支持实现Hadoop 输入范式的数据源，所以可以整合所有 Hadoop 支持的数据源和文件格式。 根据 Spark 官方教程， 它还可以通过 JDBC 和 ODBC 同 BI（商业智能） 工具一起运行。 Hive 和 Pig 也在逐步实现这样的功能。
小结：Spark和Hadoop MapReduce具有相同的数据类型和数据源的兼容性。
5、数据处理
除了平常的数据处理，Spark 可以做的远不止这点：它还可以处理图和利用现有的机器学习库。高性能也使得 Spark 在实时处理上的表现和批处理上的表现一样好。这也催生了一个更好的机遇，那就是用一个平台解决所有问题而不是只能根据任务选取不同的平台，毕竟所有的平台都需要学习和维护。
Hadoop MapReduce 在批处理上表现卓越。如果需要进行实时处理，可以利用另外的平台比如 Storm 或者 Impala，而图处理则可以用 Giraph。MapReduce 过去是用 Mahout 做机器学习的，但其负责人已经将其抛弃转而支持 Spark 和 h2o（机器学习引擎）。
小结：Spark是数据处理的瑞士军刀；Hadoop MapReduce 是批处理的突击刀。

6、处理速度
Hadoop是磁盘级计算，计算时需要在磁盘中读取数据；其采用的是MapReduce的逻辑，把数据进行切片 计算用这种方式来处理大量的离线数据.
Spark会在内存中以接近“实时”的时间完成所有的数据分析。Spark的批处理速度比MapReduce快近10
倍，内存中的数据分析速度则快近100倍。
比如实时的市场活动，在线产品推荐等需要对流数据进行分析场景就要使用Spark

18 . 简述Spark相比MapReduce的优点 ？

1、Spark 把中间数据放到内存中，迭代运算效率高
MapReduce 中计算结果需要落地，保存到磁盘上，这样势必会影响整体速度，而 Spark 支持 DAG 图的分布式并行计算的编程框架，减少了迭代过程中数据的落地，提高了处理效率。
2、Spark 容错性高
Spark 引进了弹性分布式数据集 RDD (Resilient DistributedDataset) 的抽象，它是分布在一组节点中的只读对象集合，这些集合是弹性的，如果数据集一部分丢失，则可以根据“血统”（即允许基于数据衍生过 程）对它们进行重建。另外在RDD 计算时可以通过 CheckPoint 来实现容错。
3、Spark 更加通用
mapreduce 只提供了Map和Reduce两种操作，Spark提供的数据集操作类型有很多，大致分为：
Transformations和Actions两大类。Transformations包括Map、Filter、FlatMap、Sample、GroupByKey、
ReduceByKey、Union、Join、Cogroup、MapValues、Sort等多种操作类型，同时还提供Count, Actions包括Collect、Reduce、Lookup和Save等操作。

19 . 简述是不是用了Spark就不需要Hadoop ？

不是，Spark和Hadoop各有其长处。
Hadoop和Spark两者都是大数据框架，但是各自应用场景是不同的。Hadoop是一个分布式数据存储架构，它将巨大的数据集分派到一个由普通计算机组成的集群中的多个节点进行存储，降低了硬件的成 本。Spark是那么一个专门用来对那些分布式存储的大数据进行处理的工具，它要借助hdfs的数据存储。
Hadoop提供分布式数据存储功能HDFS，还提供了用于数据处理的MapReduce。MapReduce是可以不依 靠Spark数据的处理的。当然Spark也可以不依靠HDFS进行运作，它可以依靠其它的分布式文件系统。但 是两者完全可以结合在一起，Hadoop提供分布式集群和分布式文件系统，Spark可以依附在Hadoop的
HDFS，代替MapReduce弥补MapReduce计算能力不足的问题

20 . 简述Spark Streaming和Storm的区别 ？

1、处理模型以及延迟
虽然这两个框架都提供可扩展性(Scalability)和可容错性(Fault Tolerance),但是它们的处理模型从根本上说是不一样的。Storm处理的是每次传入的一个事件，而Spark Streaming是处理某个时间段窗口内的事件流。因此，Storm处理一个事件可以达到亚秒级的延迟，而Spark Streaming则有秒级的延迟。
2、容错和数据保证
在容错数据保证方面的权衡方面，Spark Streaming提供了更好的支持容错状态计算。在Storm中，当每条单独的记录通过系统时必须被跟踪，所以Storm能够至少保证每条记录将被处理一次，但是在从错误 中恢复过来时候允许出现重复记录，这意味着可变状态可能不正确地被更新两次。而Spark Streaming只需要在批处理级别对记录进行跟踪处理，因此可以有效地保证每条记录将完全被处理一次，即便一个节 点发生故障。虽然Storm的 Trident library库也提供了完全一次处理的功能。但是它依赖于事务更新状态，而这个过程是很慢的，并且通常必须由用户实现。
简而言之,如果你需要亚秒级的延迟，Storm是一个不错的选择，而且没有数据丢失。如果你需要有状态 的计算，而且要完全保证每个事件只被处理一次，Spark Streaming则更好。Spark Streaming编程逻辑也可能更容易，因为它类似于批处理程序，特别是在你使用批次(尽管是很小的)时。
3、实现和编程API
Storm主要是由Clojure语言实现，Spark Streaming是由Scala实现。如果你想看看这两个框架是如何实现的或者你想自定义一些东西你就得记住这一点。Storm是由BackType和 Twitter开发，而Spark Streaming 是在UC Berkeley开发的。
Storm提供了Java API，同时也支持其他语言的API。 Spark Streaming支持Scala和Java语言(其实也支持Python)。另外Spark Streaming的一个很棒的特性就是它是在Spark框架上运行的。这样你就可以想使用其他批处理代码一样来写Spark Streaming程序，或者是在Spark中交互查询。这就减少了单独编写流批量处理程序和历史数据处理程序。
4、生产支持
Storm已经出现好多年了，而且自从2011年开始就在Twitter内部生产环境中使用，还有其他一些公司。 而Spark Streaming是一个新的项目，并且在2013年仅仅被Sharethrough使用(据作者了解)。
Storm是 Hortonworks Hadoop数据平台中流处理的解决方案，而Spark Streaming出现在 MapR的分布式平台和Cloudera的企业数据平台中。除此之外，Databricks是为Spark提供技术支持的公司，包括了Spark
Streaming。
5、集群管理集成
尽管两个系统都运行在它们自己的集群上，Storm也能运行在Mesos，而Spark Streaming能运行在YARN
和 Mesos上。

21 . 简述Flume和Kafka的区别 ？

它们都是流式数据采集框架。
Flume一般用于日志采集，可以定制很多数据源，减少开发量，基本架构是一个Flume进程
agent（source、拦截器、选择器、channel、sink），其中传递的是原子性的event数据。

Kafka一般用于日志缓存，是一个可持久的分布式消息队列，自带存储，提供push和pull两种存储数据功 能；包括producer、kafka Cluster（broker：topic、partition）、consumer，依赖于Zookeeper（brokerid、topic、partition元数据存在ZNode，partition选举leader依赖Zookeeper）。
1、Flume和Kafka的侧重点不同
Flume追求的是数据和数据源、数据流向的多样性，适合多个生产者的场景；Flume有自己内置的多种source和sink组件，具体操作方式是编写source、channel和sink的.conf配置文件，开启flume组件的时候 用命令关联读取配置文件实现。
Kafka追求的是高吞吐，高负载，同一topic下可以有多个partition，由于是pull模式拉取数据，因此适合 多个消费者的场景；kafka没有内置的producer和consumer组件，需要自己编写代码。
2、Flume和Kafka的定位有所不同
Flume是cloudera公司研发，适合多个生产者；适合下游数据消费者不多的情况（一个消费者开一个channel）；适合数据安全性要求不高的操作（数据没有备份、没有副本）；适合与Hadoop生态圈对接 的操作（HDFS、Hbase等）；适合生产和收集数据。
Kafka是linkedin公司研发，适合多个消费者；适合数据下游消费众多的情况（kafka从磁盘读，并且只找
Leader读）；适合数据安全性要求较高的操作，支持replication（多副本）；适合消费数据。
Flume是用于将数据发送到HDFS的专用工具。
Kafka可以支持多个应用程序的数据流，而Flume专门用于Hadoop和大数据分析。
Kafka可以处理和监视分布式系统中的数据，而Flume则从分布式系统中收集数据以将数据存储在集中式 数据存储中。

22 . 简述为什么使用Flume+Kafka ？

这个我们就要从业务需求考虑，一般使用Flume+Kafka架构都是希望完成实时流式的日志处理，后面再 连接上Flink/Storm/Spark Streaming等流式实时处理技术，从而完成日志实时解析的目标。
生产环境中，往往是读取日志进行分析，而这往往是多数据源的，如果Kafka构建多个生产者使用文件 流的方式向主题写入数据再供消费者消费的话，无疑非常的不方便。
如果Flume直接对接实时计算框架，当数据采集速度大于数据处理速度，很容易发生数据堆积或者数据 丢失，而kafka可以当做一个消息缓存队列，从广义上理解，把它当做一个数据库，可以存放一段时间的 数据。
Kafka属于中间件，一个明显的优势就是使各层解耦，使得出错时不会干扰其他组件。
因此数据从数据源到Flume再到Kafka时，数据一方面可以同步到HDFS做离线计算，另一方面可以做实时 计算，可实现数据多分发。

23 . 简述Flume和Kafka是怎么配置的 ？

1、为什么要集成Flume和Kafka

一般使用Flume + Kafka来完成实时流式的日志处理，后面再连接上Spark Streaming等流式实时处理技术，从而完成日志实时解析的目标。如果Flume直接对接实时计算框架，当数据采集速度大于数据处理 速度，很容易发生数据堆积或者数据丢失，而Kafka可以当做一个消息缓存队列，当数据从数据源到
Flume再到Kafka时，数据一方面可以同步到HDFS做离线计算，另一方面可以做实时计算，可实现数据多 分发。
2、Flume对接Kafka配置
1） Kafka作为Source端
a1.sources = r1
a1.channels = c1
a1.sinks = k1
配置Kafka作为Source端
a1.sources.r1.type = org.apache.flume.source.kafka.KafkaSource
a1.sources.r1.batchSize = 5000
a1.sources.r1.batchDurationMillis = 2000
a1.sources.r1.kafka.bootstrap.servers = centos1:9092
a1.sources.r1.kafka.topics = mytopic a1.sources.r1.kafka.consumer.group.id = group1
a1.sources.r1.channels=c1
a1.channels.c1.type=memory a1.channels.c1.capacity=1000
a1.channels.c1.transactionCapacity=100
a1.sinks.k1.type=logger a1.sinks.k1.channel=c1

2） Kafka作为Sink端
a1.sources = r1
a1.sinks = k1
a1.channels = c1
netcat 监听端口a1.sources.r1.type = netcat a1.sources.r1.bind =master1 a1.sources.r1.port = 10000 a1.sources.r1.channels = c1
一行的最大字节数
a1.sources.r1.max-line-length = 1024000

channels具体配置a1.channels.c1.type = memory a1.channels.c1.capacity = 1000
a1.channels.c1.transactionCapacity = 100

配置Kafka作为Sink端
netcat 监听端口a1.sources.r1.type = netcat
a1.sources.r1.bind =master1
a1.sources.r1.port = 10000
a1.sources.r1.channels = c1
一行的最大字节数
a1.sources.r1.max-line-length = 1024000

channels具体配置a1.channels.c1.type = memory
a1.channels.c1.capacity = 1000
a1.channels.c1.transactionCapacity = 100

配置Kafka作为Sink端
a1.sinks.k1.channel = c1
a1.sinks.k1.type = org.apache.flume.sink.kafka.KafkaSink
a1.sinks.k1.topic = hello
a1.sinks.k1.brokerList = master1:9092,slave1:9092,slave2:9092
a1.sinks.k1.requiredAcks = 1
a1.sinks.k1.batchSize = 20

24 . Spark ShuGle和MapReduce ShuGle的区别？说下各自的特点和过程 ？

1、ShuGle简介
Shuule的本意是洗牌、混洗的意思，把一组有规则的数据尽量打乱成无规则的数据。而在MapReduce 中，Shuule更像是洗牌的逆过程，指的是将map端的无规则输出按指定的规则“打乱”成具有一定规则的 数据，以便reduce端接收处理。其在MapReduce中所处的工作阶段是map输出后到reduce接收前，具体 可以分为map端和reduce端前后两个部分。
在shuule之前，也就是在map阶段，MapReduce会对要处理的数据进行分片（split）操作，为每一个分 片分配一个MapTask任务。接下来map会对每一个分片中的每一行数据进行处理得到键值对
（key,value）此时得到的键值对又叫做“中间结果”。此后便进入reduce阶段，由此可以看出Shuule阶段 的作用是处理“中间结果”。
由于Shuule涉及到了磁盘的读写和网络的传输，因此Shuule性能的高低直接影响到了整个程序的运行效 率。
2、MapReduce ShuGle
Hadoop的核心思想是MapReduce，但shuule又是MapReduce的核心。shuule的主要工作是从Map结束到
Reduce开始之间的过程。shuule阶段又可以分为Map端的shuule和Reduce端的shuule。
1） Map端的Shuule
因为频繁的磁盘I/O操作会严重的降低效率，因此“中间结果”不会立马写入磁盘，而是优先存储到map节 点的“环形内存缓冲区”，在写入的过程中进行分区（partition），也就是对于每个键值对来说，都增加 了一个partition属性值，然后连同键值对一起序列化成字节数组写入到缓冲区（缓冲区采用的就是字节 数组，默认大小为100M）。
当写入的数据量达到预先设置的阙值后便会启动溢写出线程将缓冲区中的那部分数据溢出写（spill）到 磁盘的临时文件中，并在写入前根据key进行排序（sort）和合并（combine，可选操作）。
溢出写过程按轮询方式将缓冲区中的内容写到mapreduce.cluster.local.dir属性指定的本地目录中。当整 个map任务完成溢出写后，会对磁盘中这个map任务产生的所有临时文件（spill文件）进行归并
（merge）操作生成最终的正式输出文件，此时的归并是将所有spill文件中的相同partition合并到一起， 并对各个partition中的数据再进行一次排序（sort），生成key和对应的value-list，文件归并时，如果溢 写文件数量超过参数min.num.spills.for.combine的值（默认为3）时，可以再次进行合并。
至此map端的工作已经全部结束，最终生成的文件也会存储在TaskTracker能够访问的位置。每个reduce
task不间断的通过RPC从JobTracker那里获取map task是否完成的信息，如果得到的信息是map task已经完成，那么Shuule的后半段开始启动。
2） Reduce端的shuule
每个reduce task负责处理一个分区的文件，以下是reduce task的处理流程：
reduce task从每个map task的结果文件中拉取对应分区的数据。因为数据在map阶段已经是分好区了，并且会有一个额外的索引文件记录每个分区的起始偏移量。所以reduce task取数的时候直接根据偏移量去拉取数据就ok。
reduce task从每个map task拉取分区数据的时候会进行再次合并，排序，按照自定义的reducer的逻辑代码去处理。
最后就是Reduce过程了，在这个过程中产生了最终的输出结果，并将其写到HDFS上。
3）为什么要排序 key存在combine操作，排序之后相同的key放到一块显然方便做合并操作。
reduce task是按key去处理数据的。 如果没有排序那必须从所有数据中把当前相同key的所有value数据拿出来，然后进行reduce逻辑处理。显然每个key到这个逻辑都需要做一次全量数据扫描，影响性能，有了 排序很方便的得到一个key对于的value集合。
reduce task按key去处理数据时，如果key按顺序排序，那么reduce task就按key顺序去读取，显然当读到的key是文件末尾的key那么就标志数据处理完毕。如果没有排序那还得有其他逻辑来记录哪些key处理 完了，哪些key没有处理完。
虽有千万种理由需要这么做，但是很耗资源，并且像排序其实我们有些业务并不需要排序。
4）为什么要文件合并
因为内存放不下就会溢写文件，就会发生多次溢写，形成很多小文件，如果不合并，显然会小文件泛 滥，集群需要资源开销去管理这些小文件数据。
任务去读取文件的数增多，打开的文件句柄数也会增多。
mapreduce是全局有序。单个文件有序，不代表全局有序，只有把小文件合并一起排序才会全局有序。
3、Spark ShuGle
Spark的Shuule是在MapReduce Shuule基础上进行的调优。其实就是对排序、合并逻辑做了一些优化。在Spark中Shuule write相当于MapReduce 的map，Shuule read相当于MapReduce 的reduce。
Spark丰富了任务类型，有些任务之间数据流转不需要通过Shuule，但是有些任务之间还是需要通过
Shuule来传递数据，比如宽依赖的group by key以及各种by key算子。宽依赖之间会划分stage，而Stage
之间就是Shuule，如下图中的stage0，stage1和stage3之间就会产生Shuule。
在Spark的中，负责shuule过程的执行、计算和处理的组件主要就是ShuuleManager，也即shuule管理 器。ShuuleManager随着Spark的发展有两种实现的方式，分别为HashShuuleManager和
SortShuuleManager，因此spark的Shuule有Hash Shuule和Sort Shuule两种。
在Spark的版本的发展，ShuuleManager在不断迭代，变得越来越先进。
在Spark 1.2以前，默认的shuule计算引擎是HashShuuleManager。该ShuuleManager而
HashShuuleManager有着一个非常严重的弊端，就是会产生大量的中间磁盘文件，进而由大量的磁盘IO
操作影响了性能。因此在Spark 1.2以后的版本中，默认的ShuuleManager改成了SortShuuleManager。
SortShuuleManager相较于HashShuuleManager来说，有了一定的改进。主要就在于，每个Task在进行
shuule操作时，虽然也会产生较多的临时磁盘文件，但是最后会将所有的临时文件合并(merge)成一个磁 盘文件，因此每个Task就只有一个磁盘文件。在下一个stage的shuule read task拉取自己的数据时，只要根据索引读取每个磁盘文件中的部分数据即可。
1） Hash ShuGle
HashShuuleManager的运行机制主要分成两种，一种是普通运行机制，另一种是合并的运行机制。合并 机制主要是通过复用buuer来优化Shuule过程中产生的小文件的数量。Hash shuule是不具有排序的
Shuule。
普通机制的Hash ShuGle
最开始使用的Hash Based Shuule，每个Mapper会根据Reducer的数量创建对应的bucket，bucket的数量是M * R，M是map的数量，R是Reduce的数量。如下图所示：2个core 4个map task 3 个reduce task，会产生43=12个小文件。
优化后的Hash ShuGle
普通机制Hash Shuule会产生大量的小文件(M * R），对文件系统的压力也很大，也不利于IO的吞吐量， 后来做了优化（设置spark.shuule.consolidateFiles=true开启，默认false），把在同一个core上的多个
Mapper输出到同一个文件，这样文件数就变成core * R 个了。如下图所示：2个core 4个map task 3 个
reduce task，会产生23=6个小文件
Hash shuule合并机制的问题：如果 Reducer 端的并行任务或者是数据分片过多的话则 Core * Reducer
Task 依旧过大，也会产生很多小文件。进而引出了更优化的sort shuule。在Spark 1.2以后的版本中，默认的ShuuleManager改成了SortShuuleManager。
2） Sort ShuGle
SortShuuleManager的运行机制主要分成两种，一种是普通运行机制，另一种是bypass运行机制。当shuule read task的数量小于等于spark.shuule.sort.bypassMergeThreshold参数的值时(默认为200)，就会启用bypass机制。

普通机制的Sort ShuGle
这种机制和mapreduce差不多，在该模式下，数据会先写入一个内存数据结构中，此时根据不同的
shuule算子，可能选用不同的数据结构。如果是reduceByKey这种聚合类的shuule算子，那么会选用Map
数据结构，一边通过Map进行聚合，一边写入内存；如果是join这种普通的shuule算子，那么会选用
Array数据结构，直接写入内存。接着，每写一条数据进入内存数据结构之后，就会判断一下，是否达到 了某个临界阈值。如果达到临界阈值的话，那么就会尝试将内存数据结构中的数据溢写到磁盘，然后清 空内存数据结构。
在溢写到磁盘文件之前，会先根据key对内存数据结构中已有的数据进行排序。排序过后，会分批将数 据写入磁盘文件。默认的batch数量是10000条，也就是说，排序好的数据，会以每批1万条数据的形式 分批写入磁盘文件。
一个task将所有数据写入内存数据结构的过程中，会发生多次磁盘溢写操作，也会产生多个临时文件。 最后会将之前所有的临时磁盘文件都进行合并，由于一个task就只对应一个磁盘文件因此还会单独写一 份索引文件，其中标识了下游各个task的数据在文件中的start ouset与end ouset。
SortShuuleManager由于有一个磁盘文件merge的过程，因此大大减少了文件数量，由于每个task最终只 有一个磁盘文件所以文件个数等于上游shuule write个数。
bypass机制的Sort ShuGle

bypass运行机制的触发条件如下：
shuule map task数量小于spark.shuule.sort.bypassMergeThreshold参数的值，默认值200。不是聚合类的shuule算子(比如reduceByKey)。
此时task会为每个reduce端的task都创建一个临时磁盘文件，并将数据按key进行hash然后根据key的hash 值，将key写入对应的磁盘文件之中。当然，写入磁盘文件时也是先写入内存缓冲，缓冲写满之后再溢 写到磁盘文件的。最后，同样会将所有临时磁盘文件都合并成一个磁盘文件，并创建一个单独的索引文 件。
该过程的磁盘写机制其实跟未经优化的HashShuuleManager是一模一样的，因为都要创建数量惊人的磁 盘文件，只是在最后会做一个磁盘文件的合并而已。因此少量的最终磁盘文件，也让该机制相对未经优 化的HashShuuleManager来说，shuule read的性能会更好。
而该机制与普通SortShuuleManager运行机制的不同在于： 磁盘写机制不同；
不会进行排序。也就是说，启用该机制的最大好处在于，shuule write过程中，不需要进行数据的
排序操作，也就节省掉了这部分的性能开销。
3） Spark ShuGle总结
Shuule 过程本质上都是将 Map 端获得的数据使用分区器进行划分，并将数据发送给对应的 Reducer 的过程。
Shuule作为处理连接map端和reduce端的枢纽，其shuule的性能高低直接影响了整个程序的性能和吞吐 量。map端的shuule一般为shuule的Write阶段，reduce端的shuule一般为shuule的read阶段。Hadoop和spark的shuule在实现上面存在很大的不同，spark的shuule分为两种实现，分别为HashShuule和
SortShuule。
HashShuule又分为普通机制和合并机制，普通机制因为其会产生MR个数的巨量磁盘小文件而产生大量 性能低下的Io操作，从而性能较低，因为其巨量的磁盘小文件还可能导致OOM，HashShuule的合并机制 通过重复利用buuer从而将磁盘小文件的数量降低到CoreR个，但是当Reducer 端的并行任务或者是数据分片过多的时候，依然会产生大量的磁盘小文件。
SortShuule也分为普通机制和bypass机制，普通机制在内存数据结构(默认为5M)完成排序，会产生2M个 磁盘小文件。而当shuule map task数量小于spark.shuule.sort.bypassMergeThreshold参数的值。或者算子不是聚合类的shuule算子(比如reduceByKey)的时候会触发SortShuule的bypass机制，SortShuule的bypass 机制不会进行排序，极大的提高了其性能。

在Spark 1.2以前，默认的shuule计算引擎是HashShuuleManager，因为HashShuuleManager会产生大量的磁盘小文件而性能低下，在Spark 1.2以后的版本中，默认的ShuuleManager改成了SortShuuleManager。
SortShuuleManager相较于HashShuuleManager来说，有了一定的改进。主要就在于，每个Task在进行
shuule操作时，虽然也会产生较多的临时磁盘文件，但是最后会将所有的临时文件合并(merge)成一个磁 盘文件，因此每个Task就只有一个磁盘文件。在下一个stage的shuule read task拉取自己的数据时，只要根据索引读取每个磁盘文件中的部分数据即可。
4、Spark与MapReduce ShuGle的异同
从整体功能上看，两者并没有大的差别。 都是将 mapper（Spark 里是 ShuuleMapTask）的输出进行partition，不同的 partition 送到不同的 reducer（Spark 里 reducer 可能是下一个 stage 里的ShuuleMapTask，也可能是 ResultTask）。Reducer 以内存作缓冲区，边 shuule 边 aggregate 数据，等到数据 aggregate 好以后进行 reduce（Spark 里可能是后续的一系列操作）。
从流程的上看，两者差别不小。 Hadoop MapReduce 是 sort-based，进入 combine和 reduce的 records 必须先 sort。这样的好处在于 combine/reduce可以处理大规模的数据，因为其输入数据可以通过外排得到
（mapper 对每段数据先做排序，reducer 的 shuule 对排好序的每段数据做归并）。以前 Spark 默认选择的是 hash-based，通常使用 HashMap 来对 shuule 来的数据进行合并，不会对数据进行提前排序。如果用户需要经过排序的数据，那么需要自己调用类似 sortByKey的操作。在Spark 1.2之后，sort-based变为默认的Shuule实现。
从流程实现角度来看，两者也有不少差别。 Hadoop MapReduce 将处理流程划分出明显的几个阶段： map, spill, merge, shuule, sort, reduce等。每个阶段各司其职，可以按照过程式的编程思想来逐一实现每个阶段的功能。在 Spark 中，没有这样功能明确的阶段，只有不同的 stage 和一系列的 transformation， 所以 spill, merge, aggregate 等操作需要蕴含在 transformation中。

25 . 简述若Spark要保存数据到HDFS上，要用什么算子 ？

1、Hive
Hive是基于Hadoop的一个数据仓库工具，可以将结构化的数据文件映射为一张数据库表，并提供完整的
sql查询功能，可以将sql语句转换为MapReduce任务进行运行。其优点是学习成本低，可以通过类SQL语 句快速实现简单的MapReduce统计，不必开发专门的MapReduce应用，十分适合数据仓库的统计分析。
Hive是建立在 Hadoop 上的数据仓库基础构架。它提供了一系列的工具，可以用来进行数据提取转化加载(ETL)，这是一种可以存储、查询和分析存储在 Hadoop 中的大规模数据的机制。Hive 定义了简单的类
SQL 查询语言，称为 HQL，它允许熟悉 SQL 的用户查询数据。同时，这个语言也允许熟悉 MapReduce 开发者的开发自定义的 mapper 和 reducer 来处理内建的 mapper 和 reducer 无法完成的复杂的分析工作。
2、Spark SQL
Spark SQL主要用于结构化数据处理和对Spark数据执行类SQL的查询。通过Spark SQL，可以针对不同格式的数据执行ETL操作（如JSON，Parquet，数据库）然后完成特定的查询操作。一般来说，Spark每支 持一种新的应用开发，都会引入一个新的Context及相应的RDD，对于SQL这一特性来说，引入的就是
SQLContext和SchemaRDD。
注意：在Spark1.3之后，SchemaRDD已经更名为DataFrame，但它本质就类似一个RDD，因为可以将
DataFrame无缝的转换成一个RDD。
3、比对
Hive是基于Hadoop的一个数据仓库工具，同时也是查询引擎，基于Hadoop做数据清洗（ETL）、报表、 数据分析等。但是，对于实时插入、更新、删除数据，还要求强一致性和毫秒级响应，这个就不是Hive 的长处，因为MapReduce处理数据是一个个阶段进行的，每个阶段都要落盘，不能多个map串联使用。
对于Spark，有RDD，可以把map过程串起来，中间过程存在内存中，再做一些优化，官方给出的答案是 比Hadoop处理速度快乐10-100倍。
Hive适合处理离线非实时数据、数据仓库存储。Spark SQL适合实时性要求或者速度要求较高的场所

26 . 简述分布式存储系统和分布式计算框架区别 ？

分布式存储系统：
将数据分散存储在多台独立的设备上。传统的网络存储系统采用集中的存储服务器存放所有数据，存储 服务器成为系统性能的瓶颈，也是可靠性和安全性的焦点，不能满足大规模存储应用的需要。分布式网 络存储系统采用可扩展的系统结构，利用多台存储服务器分担存储负荷，利用位置服务器定位存储信 息，它不但提高了系统的可靠性、可用性和存取效率，还易于扩展。比如HDFS。

分布式计算框架：
分布式计算是利用网络把成千上万台计算机连接起来，组成一台虚拟的超级计算机，完成单台计算机无 法完成的超大规模的问题求解。开放分布式计算架构是指以分布式计算技术为基础，用于解决大规模的 问题开放式软件架构。开放分布式计算架构具有较好的可移植性和可裁剪性。比如
MapReduce（Hadoop）、Spark、Flink。
分布式存储是指将数据（副本）分散存储在多台设备上，比如HDFS默认副本数量是3个，这保证了分布 式存储的数据的稳定性。
分布式计算是指把需要进行大量计算的工程数据分区成小块，由多台计算机分别计算，再上传运算结果 后，将结果统一合并得出数据结论。

27 . 简述ETL完整执行过程 ？

ETL是英文Extract-Transform-Load 的缩写，用来描述将数据从来源端经过抽取（extract）、转换
（transform）、加载（load）至目的端的过程。
ETL过程中的主要环节就是数据抽取、数据转换和加工、数据装载。
在ETL三个部分中，花费时间最长的是“T”(Transform，清洗、转换)的部分，一般情况下这部分工作量是 整个ETL的2/3。
为了实现这些功能，各个ETL工具一般会进行一些功能上的扩充，例如工作流、调度引擎、规则引擎、 脚本支持、统计信息等。
1、抽取作业
数据抽取是从数据源中抽取数据的过程。实际应用中，数据源较多采用的是关系数据库。
1）从数据库中抽取数据的方式： 全量抽取
全量抽取类似于数据迁移或数据复制，它将数据源中的表或视图的数据原封不动的从数据库中抽取出 来，并转换成自己的ETL工具可以识别的格式。
全量抽取比较简单。
增量抽取
增量抽取只抽取自上次抽取以来数据库中要抽取的表中新增或修改的数据。
在ETL使用过程中，增量抽取较全量抽取应用更广，如何捕获变化的数据是增量抽取的关键。 对捕获方法一般有两点要求：
准确性，能够将业务系统中的变化数据按一定的频率准确地捕获到； 性能，不能对业务系统造成太大的压力，影响现有业务。

2）手工开发抽取作业时候的常用方法： 当数据源和DW为同一类数据库时
一般情况下，DBMS(SQLServer、Oracle)都会提供数据库链接功能，可以在数据源（业务系统）和DW内 建立数据库链接（如DB2的联邦数据库NICKNAME），然后在DW内直接SELECT访问。
优点是实现使用简单，逻辑简单；
缺点是容易被滥用对源数据库造成较大的负载压力。
当数据源和ODS为不同类型数据库时
将源数据库的数据导出为文本文件，利用FTP协议进行传输导入ODS区域。 优点是实现简单，对源系统压力较小。
缺点是传输步骤增加了，处理需要的时间增加。
将部分数据库间能通过ODBC建立源数据库和目标数据库链接，此时也能直接使用SELECT获取数据。 优点是实现使用简单，逻辑简单；
缺点是容易被滥用对源数据库造成较大的负载压力，且建立时较为复杂。
3）更新数据的时间和数量的问题实时抽取数据
这类抽取方式在数据仓库中很少见到，因为一般来说数据仓库对数据的实时性要求并不高。
实时抽取常见于BI中的CRM系统，比如在实时营销中，客户一旦进行了某类操作就实时触发对应的营销 行为。
1.时间戳方式
要求源表中存在一个或多个字段(时间戳),其值随着新纪录的增加而不断增加，执行数据抽取时，程序定 时循环检查通过时间戳对数据进行过滤，抽取结束后，程序记录时间戳信息。
优点是对源系统的侵入较小
缺点是抽取程序需要不断扫描源系统的表，对其 有一定压力
2.触发器方式
要求用户在源数据库中有创建触发器和临时表的权限，触发器捕获新增的数据到临时表中，执行抽取 时，程序自动从临时表中读取数据。
优点是实时性极高
缺点是对源系统的侵入性较大，同时会对源数据库造成很大的压力（行级触发器），很可能影响源 系统的正常业务
3.程序接口方式
改造源系统，在修改数据时通过程序接口同步发送数据至目标库，发送数据的动作可以跟业务修改数据 动作脱耦，独立发送。
优点是对源系统的造成压力较小，实时性较强；
缺点是需要对源系统的侵入性较强，需要源系统做较大的改造。
批量抽取数据
为了保证数据抽取时数据的准确性、完整性和唯一性，同时降低抽取作业对源数据库造成的压力，抽取 作业的加载必须避开源数据的生成时间。
这种方法一般用于实时性要求不高的数据。比如T+1或者每月1日进行抽取。
1.常用实现

日志检查
需要源数据库生成数据完毕之后，在外部生成日志。
抽取程序定时检查源系统的执行日志，发现完成标志后发起抽取作业。优点是可靠性高，对源数据库造成的压力较小。
缺点是需要源数据库配合生成可供检查的外部日志。约定时间抽取
可以直接约定一个加载完毕同时对源数据库压力较小的时间（如每日凌晨2点），抽取程序建 立定时任务，时间一到自动发起抽取作业。
优点是对源数据库的侵入性和造成的压力较小；
缺点是可靠性不高，可能会发生数据未生成完毕也直接进行抽取的情况。
2.根据下载时候对数据的筛选方式可以分为全量下载
适用：
源数据量较小，如维表。
数据变化较大，比如90%的数据都产生了变化的表。变化的数据不能预期，无法标示，如账户表。
优缺点：
优点在于下载较为简单且能容纳任何情况的数据变化；
缺点是如果数据量较大，需要抽取相当长的时间，同时会占用大量的IO和网络资源。增量下载：常用于数据只增不减的表，如交易明细表等。
感知增量的方式如下：
1）触发器
在要抽取的表上建立需要的触发器，一般要建立插入、修改、删除三个触发器，每当源表中 的数据发生变化，就被相应的触发器将变化的数据写入一个临时表，抽取线程从临时表中抽 取数据，临时表中抽取过的数据被标记或删除。
优点是数据抽取的性能较高，下载的数据较小，速度较快，占用资源少。
缺点是要求业务表建立触发器，对业务系统有一定的影响，使用限制较大，有时候需要 源系统进行改造支持。
2）时间戳
它是一种基于快照比较的变化数据捕获方式，在源表上增加一个时间戳字段，系统中更新修 改表数据的时候，同时修改时间戳字段的值。当进行数据抽取时，通过比较系统时间与时间 戳字段的值来决定抽取哪些数据。
的数据库的时间戳支持自动更新，即表的其它字段的数据发生改变时，自动更新时间戳 字段的值。
有的数据库不支持时间戳的自动更新，这就要求业务系统在更新业务数据时，手工更新 时间戳字段。
优缺点：
优点：同触发器方式一样，时间戳方式的性能也比较好，数据抽取相对清楚简单；
缺点：对业务系统也有很大的倾入性（加入额外的时间戳字段），特别是对不支持时间 戳的自动更新的数据库，还要求业务系统进行额外的更新时间戳操作。另外，无法捕获 对时间戳以前数据的delete和update操作,在数据准确性上受到了一定的限制。
3）全表比对
典型的全表比对的方式是采用MD5校验码。
ETL工具事先为要抽取的表建立一个结构类似的MD5临时表，该临时表记录源表主键以及根据 所有字段的数据计算出来的MD5校验码。

每次进行数据抽取时，对源表和MD5临时表进行MD5校验码的比对，从而决定源表中的数据是新增、修改还是删除，同时更新MD5校验码。
优点是对源系统的倾入性较小（仅需要建立一个MD5临时表）
缺点也是显而易见的，与触发器和时间戳方式中的主动通知不同，MD5方式是被动的进行全表数据的比对，性能较差。
当表中没有主键或唯一列且含有重复记录时，MD5方式的准确性较差。
4）日志对比
通过分析数据库自身的日志来判断变化的数据。
ETL处理的数据源除了关系数据库外，还可能是文件，例如txt文件、excel文件、xml文件等。
对文件数据的抽取一般是进行全量抽取，一次抽取前可保存文件的时间戳或计算文件的MD5校验码，下 次抽取时进行比对，如果相同则可忽略本次抽取。
2、转换作业
这一步包含了数据的清洗和转换。
从数据源中抽取的数据不一定完全满足目的库的要求，例如数据格式的不一致、数据输入错误、数据不 完整等等，因此有必要对抽取出的数据进行数据转换和加工。
数据的转换和加工可以在ETL引擎中进行，也可以在数据抽取过程中利用关系数据库的特性同时进行。
1）数据清洗
任务是过滤不符合条件或者错误的数据。
这一步常常出现在刚刚开始建立数据仓库或者源业务系统仍未成熟的时候，此时发现错误数据需要联系 源业务系统进行更正，部分可预期的空值或者测试用数据可以过滤掉。
2）数据转换和加工
这一步是整个ETL流程中最为占用时间和资源的一步。数据转换包含了简单的数据不一致转换，数据粒 度转换和耗时的数据关联整合或拆分动作。这里可能存在各种各样千奇百怪的需求。对于核心数据仓库 来说，里面往往是对数据进行按照主题划分合并的动作。同时，也会添加一些为了提升执行效率而进行 反范式化添加的冗余字段。数据的转换和加工可以在ETL引擎中进行，也可以在数据抽取过程中利用关 系数据库的特性同时进行。根据实现方式的不同，可以区分为使用数据库存储过程转换和使用高级语言 转换。
ETL引擎中的数据转换和加工
ETL引擎中一般以组件化的方式实现数据转换。
常用的数据转换组件有字段映射、数据过滤、数据清洗、数据替换、数据计算、数据验证、数据加解 密、数据合并、数据拆分等。这些组件如同一条流水线上的一道道工序，它们是可插拔的，且可以任意 组装，各组件之间通过数据总线共享数据。有些ETL工具还提供了脚本支持，使得用户可以以一种编程 的方式定制数据的转换和加工行为。
在数据库中进行数据加工
关系数据库本身已经提供了强大的SQL、函数来支持数据的加工，如在SQL查询语句中添加where条件进 行过滤，查询中重命名字段名与目的表进行映射，substr函数，case条件判断等等。
下面是一个SQL查询的例子。
ETL是英文Extract-Transform-Load 的缩写，用来描述将数据从来源端经过抽取（extract）、转换
（transform）、加载（load）至目的端的过程。
ETL过程中的主要环节就是数据抽取、数据转换和加工、数据装载。
在ETL三个部分中，花费时间最长的是“T”(Transform，清洗、转换)的部分，一般情况下这部分工作量是 整个ETL的2/3。
为了实现这些功能，各个ETL工具一般会进行一些功能上的扩充，例如工作流、调度引擎、规则引擎、 脚本支持、统计信息等。
1、抽取作业
数据抽取是从数据源中抽取数据的过程。实际应用中，数据源较多采用的是关系数据库。
1）从数据库中抽取数据的方式： 全量抽取
全量抽取类似于数据迁移或数据复制，它将数据源中的表或视图的数据原封不动的从数据库中抽取出 来，并转换成自己的ETL工具可以识别的格式。
全量抽取比较简单。
增量抽取
增量抽取只抽取自上次抽取以来数据库中要抽取的表中新增或修改的数据。
在ETL使用过程中，增量抽取较全量抽取应用更广，如何捕获变化的数据是增量抽取的关键。 对捕获方法一般有两点要求：
准确性，能够将业务系统中的变化数据按一定的频率准确地捕获到； 性能，不能对业务系统造成太大的压力，影响现有业务。

2）手工开发抽取作业时候的常用方法： 当数据源和DW为同一类数据库时
一般情况下，DBMS(SQLServer、Oracle)都会提供数据库链接功能，可以在数据源（业务系统）和DW内 建立数据库链接（如DB2的联邦数据库NICKNAME），然后在DW内直接SELECT访问。
优点是实现使用简单，逻辑简单；
缺点是容易被滥用对源数据库造成较大的负载压力。
当数据源和ODS为不同类型数据库时
将源数据库的数据导出为文本文件，利用FTP协议进行传输导入ODS区域。 优点是实现简单，对源系统压力较小。
缺点是传输步骤增加了，处理需要的时间增加。
将部分数据库间能通过ODBC建立源数据库和目标数据库链接，此时也能直接使用SELECT获取数据。 优点是实现使用简单，逻辑简单；
缺点是容易被滥用对源数据库造成较大的负载压力，且建立时较为复杂。
3）更新数据的时间和数量的问题实时抽取数据
这类抽取方式在数据仓库中很少见到，因为一般来说数据仓库对数据的实时性要求并不高。
实时抽取常见于BI中的CRM系统，比如在实时营销中，客户一旦进行了某类操作就实时触发对应的营销 行为。
1.时间戳方式
要求源表中存在一个或多个字段(时间戳),其值随着新纪录的增加而不断增加，执行数据抽取时，程序定 时循环检查通过时间戳对数据进行过滤，抽取结束后，程序记录时间戳信息。
优点是对源系统的侵入较小
缺点是抽取程序需要不断扫描源系统的表，对其 有一定压力
2.触发器方式
要求用户在源数据库中有创建触发器和临时表的权限，触发器捕获新增的数据到临时表中，执行抽取 时，程序自动从临时表中读取数据。
优点是实时性极高
缺点是对源系统的侵入性较大，同时会对源数据库造成很大的压力（行级触发器），很可能影响源 系统的正常业务
3.程序接口方式
改造源系统，在修改数据时通过程序接口同步发送数据至目标库，发送数据的动作可以跟业务修改数据 动作脱耦，独立发送。
优点是对源系统的造成压力较小，实时性较强；
缺点是需要对源系统的侵入性较强，需要源系统做较大的改造。
批量抽取数据
为了保证数据抽取时数据的准确性、完整性和唯一性，同时降低抽取作业对源数据库造成的压力，抽取 作业的加载必须避开源数据的生成时间。
这种方法一般用于实时性要求不高的数据。比如T+1或者每月1日进行抽取。
1.常用实现

日志检查
需要源数据库生成数据完毕之后，在外部生成日志。
抽取程序定时检查源系统的执行日志，发现完成标志后发起抽取作业。优点是可靠性高，对源数据库造成的压力较小。
缺点是需要源数据库配合生成可供检查的外部日志。约定时间抽取
可以直接约定一个加载完毕同时对源数据库压力较小的时间（如每日凌晨2点），抽取程序建 立定时任务，时间一到自动发起抽取作业。
优点是对源数据库的侵入性和造成的压力较小；
缺点是可靠性不高，可能会发生数据未生成完毕也直接进行抽取的情况。
2.根据下载时候对数据的筛选方式可以分为全量下载
适用：
源数据量较小，如维表。
数据变化较大，比如90%的数据都产生了变化的表。变化的数据不能预期，无法标示，如账户表。
优缺点：
优点在于下载较为简单且能容纳任何情况的数据变化；
缺点是如果数据量较大，需要抽取相当长的时间，同时会占用大量的IO和网络资源。增量下载：常用于数据只增不减的表，如交易明细表等。
感知增量的方式如下：
1）触发器
在要抽取的表上建立需要的触发器，一般要建立插入、修改、删除三个触发器，每当源表中 的数据发生变化，就被相应的触发器将变化的数据写入一个临时表，抽取线程从临时表中抽 取数据，临时表中抽取过的数据被标记或删除。
优点是数据抽取的性能较高，下载的数据较小，速度较快，占用资源少。
缺点是要求业务表建立触发器，对业务系统有一定的影响，使用限制较大，有时候需要 源系统进行改造支持。
2）时间戳
它是一种基于快照比较的变化数据捕获方式，在源表上增加一个时间戳字段，系统中更新修 改表数据的时候，同时修改时间戳字段的值。当进行数据抽取时，通过比较系统时间与时间 戳字段的值来决定抽取哪些数据。
的数据库的时间戳支持自动更新，即表的其它字段的数据发生改变时，自动更新时间戳 字段的值。
有的数据库不支持时间戳的自动更新，这就要求业务系统在更新业务数据时，手工更新 时间戳字段。
优缺点：
优点：同触发器方式一样，时间戳方式的性能也比较好，数据抽取相对清楚简单；
缺点：对业务系统也有很大的倾入性（加入额外的时间戳字段），特别是对不支持时间 戳的自动更新的数据库，还要求业务系统进行额外的更新时间戳操作。另外，无法捕获 对时间戳以前数据的delete和update操作,在数据准确性上受到了一定的限制。
3）全表比对
典型的全表比对的方式是采用MD5校验码。
ETL工具事先为要抽取的表建立一个结构类似的MD5临时表，该临时表记录源表主键以及根据 所有字段的数据计算出来的MD5校验码。

每次进行数据抽取时，对源表和MD5临时表进行MD5校验码的比对，从而决定源表中的数据是新增、修改还是删除，同时更新MD5校验码。
优点是对源系统的倾入性较小（仅需要建立一个MD5临时表）
缺点也是显而易见的，与触发器和时间戳方式中的主动通知不同，MD5方式是被动的进行全表数据的比对，性能较差。
当表中没有主键或唯一列且含有重复记录时，MD5方式的准确性较差。
4）日志对比
通过分析数据库自身的日志来判断变化的数据。
ETL处理的数据源除了关系数据库外，还可能是文件，例如txt文件、excel文件、xml文件等。
对文件数据的抽取一般是进行全量抽取，一次抽取前可保存文件的时间戳或计算文件的MD5校验码，下 次抽取时进行比对，如果相同则可忽略本次抽取。
2、转换作业
这一步包含了数据的清洗和转换。
从数据源中抽取的数据不一定完全满足目的库的要求，例如数据格式的不一致、数据输入错误、数据不 完整等等，因此有必要对抽取出的数据进行数据转换和加工。
数据的转换和加工可以在ETL引擎中进行，也可以在数据抽取过程中利用关系数据库的特性同时进行。
1）数据清洗
任务是过滤不符合条件或者错误的数据。
这一步常常出现在刚刚开始建立数据仓库或者源业务系统仍未成熟的时候，此时发现错误数据需要联系 源业务系统进行更正，部分可预期的空值或者测试用数据可以过滤掉。
2）数据转换和加工
这一步是整个ETL流程中最为占用时间和资源的一步。数据转换包含了简单的数据不一致转换，数据粒 度转换和耗时的数据关联整合或拆分动作。这里可能存在各种各样千奇百怪的需求。对于核心数据仓库 来说，里面往往是对数据进行按照主题划分合并的动作。同时，也会添加一些为了提升执行效率而进行 反范式化添加的冗余字段。数据的转换和加工可以在ETL引擎中进行，也可以在数据抽取过程中利用关 系数据库的特性同时进行。根据实现方式的不同，可以区分为使用数据库存储过程转换和使用高级语言 转换。
ETL引擎中的数据转换和加工
ETL引擎中一般以组件化的方式实现数据转换。
常用的数据转换组件有字段映射、数据过滤、数据清洗、数据替换、数据计算、数据验证、数据加解 密、数据合并、数据拆分等。这些组件如同一条流水线上的一道道工序，它们是可插拔的，且可以任意 组装，各组件之间通过数据总线共享数据。有些ETL工具还提供了脚本支持，使得用户可以以一种编程 的方式定制数据的转换和加工行为。
在数据库中进行数据加工
关系数据库本身已经提供了强大的SQL、函数来支持数据的加工，如在SQL查询语句中添加where条件进 行过滤，查询中重命名字段名与目的表进行映射，substr函数，case条件判断等等。
下面是一个SQL查询的例子。
ETL是英文Extract-Transform-Load 的缩写，用来描述将数据从来源端经过抽取（extract）、转换
（transform）、加载（load）至目的端的过程。
ETL过程中的主要环节就是数据抽取、数据转换和加工、数据装载。
在ETL三个部分中，花费时间最长的是“T”(Transform，清洗、转换)的部分，一般情况下这部分工作量是 整个ETL的2/3。
为了实现这些功能，各个ETL工具一般会进行一些功能上的扩充，例如工作流、调度引擎、规则引擎、 脚本支持、统计信息等。
1、抽取作业
数据抽取是从数据源中抽取数据的过程。实际应用中，数据源较多采用的是关系数据库。
1）从数据库中抽取数据的方式： 全量抽取
全量抽取类似于数据迁移或数据复制，它将数据源中的表或视图的数据原封不动的从数据库中抽取出 来，并转换成自己的ETL工具可以识别的格式。
全量抽取比较简单。
增量抽取
增量抽取只抽取自上次抽取以来数据库中要抽取的表中新增或修改的数据。
在ETL使用过程中，增量抽取较全量抽取应用更广，如何捕获变化的数据是增量抽取的关键。 对捕获方法一般有两点要求：
准确性，能够将业务系统中的变化数据按一定的频率准确地捕获到； 性能，不能对业务系统造成太大的压力，影响现有业务。

2）手工开发抽取作业时候的常用方法： 当数据源和DW为同一类数据库时
一般情况下，DBMS(SQLServer、Oracle)都会提供数据库链接功能，可以在数据源（业务系统）和DW内 建立数据库链接（如DB2的联邦数据库NICKNAME），然后在DW内直接SELECT访问。
优点是实现使用简单，逻辑简单；
缺点是容易被滥用对源数据库造成较大的负载压力。
当数据源和ODS为不同类型数据库时
将源数据库的数据导出为文本文件，利用FTP协议进行传输导入ODS区域。 优点是实现简单，对源系统压力较小。
缺点是传输步骤增加了，处理需要的时间增加。
将部分数据库间能通过ODBC建立源数据库和目标数据库链接，此时也能直接使用SELECT获取数据。 优点是实现使用简单，逻辑简单；
缺点是容易被滥用对源数据库造成较大的负载压力，且建立时较为复杂。
3）更新数据的时间和数量的问题实时抽取数据
这类抽取方式在数据仓库中很少见到，因为一般来说数据仓库对数据的实时性要求并不高。
实时抽取常见于BI中的CRM系统，比如在实时营销中，客户一旦进行了某类操作就实时触发对应的营销 行为。
1.时间戳方式
要求源表中存在一个或多个字段(时间戳),其值随着新纪录的增加而不断增加，执行数据抽取时，程序定 时循环检查通过时间戳对数据进行过滤，抽取结束后，程序记录时间戳信息。
优点是对源系统的侵入较小
缺点是抽取程序需要不断扫描源系统的表，对其 有一定压力
2.触发器方式
要求用户在源数据库中有创建触发器和临时表的权限，触发器捕获新增的数据到临时表中，执行抽取 时，程序自动从临时表中读取数据。
优点是实时性极高
缺点是对源系统的侵入性较大，同时会对源数据库造成很大的压力（行级触发器），很可能影响源 系统的正常业务
3.程序接口方式
改造源系统，在修改数据时通过程序接口同步发送数据至目标库，发送数据的动作可以跟业务修改数据 动作脱耦，独立发送。
优点是对源系统的造成压力较小，实时性较强；
缺点是需要对源系统的侵入性较强，需要源系统做较大的改造。
批量抽取数据
为了保证数据抽取时数据的准确性、完整性和唯一性，同时降低抽取作业对源数据库造成的压力，抽取 作业的加载必须避开源数据的生成时间。
这种方法一般用于实时性要求不高的数据。比如T+1或者每月1日进行抽取。
1.常用实现

日志检查
需要源数据库生成数据完毕之后，在外部生成日志。
抽取程序定时检查源系统的执行日志，发现完成标志后发起抽取作业。优点是可靠性高，对源数据库造成的压力较小。
缺点是需要源数据库配合生成可供检查的外部日志。约定时间抽取
可以直接约定一个加载完毕同时对源数据库压力较小的时间（如每日凌晨2点），抽取程序建 立定时任务，时间一到自动发起抽取作业。
优点是对源数据库的侵入性和造成的压力较小；
缺点是可靠性不高，可能会发生数据未生成完毕也直接进行抽取的情况。
2.根据下载时候对数据的筛选方式可以分为全量下载
适用：
源数据量较小，如维表。
数据变化较大，比如90%的数据都产生了变化的表。变化的数据不能预期，无法标示，如账户表。
优缺点：
优点在于下载较为简单且能容纳任何情况的数据变化；
缺点是如果数据量较大，需要抽取相当长的时间，同时会占用大量的IO和网络资源。增量下载：常用于数据只增不减的表，如交易明细表等。
感知增量的方式如下：
1）触发器
在要抽取的表上建立需要的触发器，一般要建立插入、修改、删除三个触发器，每当源表中 的数据发生变化，就被相应的触发器将变化的数据写入一个临时表，抽取线程从临时表中抽 取数据，临时表中抽取过的数据被标记或删除。
优点是数据抽取的性能较高，下载的数据较小，速度较快，占用资源少。
缺点是要求业务表建立触发器，对业务系统有一定的影响，使用限制较大，有时候需要 源系统进行改造支持。
2）时间戳
它是一种基于快照比较的变化数据捕获方式，在源表上增加一个时间戳字段，系统中更新修 改表数据的时候，同时修改时间戳字段的值。当进行数据抽取时，通过比较系统时间与时间 戳字段的值来决定抽取哪些数据。
的数据库的时间戳支持自动更新，即表的其它字段的数据发生改变时，自动更新时间戳 字段的值。
有的数据库不支持时间戳的自动更新，这就要求业务系统在更新业务数据时，手工更新 时间戳字段。
优缺点：
优点：同触发器方式一样，时间戳方式的性能也比较好，数据抽取相对清楚简单；
缺点：对业务系统也有很大的倾入性（加入额外的时间戳字段），特别是对不支持时间 戳的自动更新的数据库，还要求业务系统进行额外的更新时间戳操作。另外，无法捕获 对时间戳以前数据的delete和update操作,在数据准确性上受到了一定的限制。
3）全表比对
典型的全表比对的方式是采用MD5校验码。
ETL工具事先为要抽取的表建立一个结构类似的MD5临时表，该临时表记录源表主键以及根据 所有字段的数据计算出来的MD5校验码。

每次进行数据抽取时，对源表和MD5临时表进行MD5校验码的比对，从而决定源表中的数据是新增、修改还是删除，同时更新MD5校验码。
优点是对源系统的倾入性较小（仅需要建立一个MD5临时表）
缺点也是显而易见的，与触发器和时间戳方式中的主动通知不同，MD5方式是被动的进行全表数据的比对，性能较差。
当表中没有主键或唯一列且含有重复记录时，MD5方式的准确性较差。
4）日志对比
通过分析数据库自身的日志来判断变化的数据。
ETL处理的数据源除了关系数据库外，还可能是文件，例如txt文件、excel文件、xml文件等。
对文件数据的抽取一般是进行全量抽取，一次抽取前可保存文件的时间戳或计算文件的MD5校验码，下 次抽取时进行比对，如果相同则可忽略本次抽取。
2、转换作业
这一步包含了数据的清洗和转换。
从数据源中抽取的数据不一定完全满足目的库的要求，例如数据格式的不一致、数据输入错误、数据不 完整等等，因此有必要对抽取出的数据进行数据转换和加工。
数据的转换和加工可以在ETL引擎中进行，也可以在数据抽取过程中利用关系数据库的特性同时进行。
1）数据清洗
任务是过滤不符合条件或者错误的数据。
这一步常常出现在刚刚开始建立数据仓库或者源业务系统仍未成熟的时候，此时发现错误数据需要联系 源业务系统进行更正，部分可预期的空值或者测试用数据可以过滤掉。
2）数据转换和加工
这一步是整个ETL流程中最为占用时间和资源的一步。数据转换包含了简单的数据不一致转换，数据粒 度转换和耗时的数据关联整合或拆分动作。这里可能存在各种各样千奇百怪的需求。对于核心数据仓库 来说，里面往往是对数据进行按照主题划分合并的动作。同时，也会添加一些为了提升执行效率而进行 反范式化添加的冗余字段。数据的转换和加工可以在ETL引擎中进行，也可以在数据抽取过程中利用关 系数据库的特性同时进行。根据实现方式的不同，可以区分为使用数据库存储过程转换和使用高级语言 转换。
ETL引擎中的数据转换和加工
ETL引擎中一般以组件化的方式实现数据转换。
常用的数据转换组件有字段映射、数据过滤、数据清洗、数据替换、数据计算、数据验证、数据加解 密、数据合并、数据拆分等。这些组件如同一条流水线上的一道道工序，它们是可插拔的，且可以任意 组装，各组件之间通过数据总线共享数据。有些ETL工具还提供了脚本支持，使得用户可以以一种编程 的方式定制数据的转换和加工行为。
在数据库中进行数据加工
关系数据库本身已经提供了强大的SQL、函数来支持数据的加工，如在SQL查询语句中添加where条件进 行过滤，查询中重命名字段名与目的表进行映射，substr函数，case条件判断等等。
下面是一个SQL查询的例子。
select ID as USERID, substr(TITLE, 1, 20) as TITLE, case when REMARK is null then ’ ’ else REMARK end as CONTENT from TB_REMARK where ID > 100;

相比在ETL引擎中进行数据转换和加工，直接在SQL语句中进行转换和加工更加简单清晰，性能更高。对 于SQL语句无法处理的可以交由ETL引擎处理。

使用数据库存储过程转换
使用SQL开发存储过程完成转换作业是很多银行常用的方法。
优点是开发简单、能支持绝大部分转换场景；
缺点在于占用资源多且受制于单一数据库性能，无法做到横向扩展。
因此，除了业务的理解能力外，对SQL海量数据处理的优化能力在此也非常重要。 比如：
利用数据库的分区性，选择良好的分区键。
建表时合理选择主键和索引，关联时候必须使用主键或索引进行关联。
关注数据库对SQL的流程优化逻辑，尽量选择拆分复杂SQL，引导数据库根据你选择流程进行数据 处理
合理反范式化设计表，留出适当的冗余字段，减少关联动作。
具体的优化根据不同的数据库有着不同的处理方式，根据所选用的数据库不同而定。
使用高级语言转换
使用高级语言包含了常用的开发C/C++/JAVA等程序对抽取的数据进行预处理。
优点是运行效率较高，可以通过横向扩展服务器数量来提高系统的转换作业处理能力；
缺点是开发较为复杂，同时虽然能进行较为复杂的逻辑的开发，但是对于大数据量的关联的支持能 力较弱，特别是有复数的服务器并行处理的时候。
3、加载作业
将转换和加工后的数据装载到目的库中通常是ETL过程的最后步骤。
转换作业生成的数据有可能直接插入目标数据库，一般来说，这种情况常见于使用数据库存储过程进行 转换作业的方案。此时，ETL作业位于目标数据库上，加载作业只需要使用INSERT或者LOAD的方式导入 目标表即可。此时转换作业和加载作业往往是在同一加工中完成的。
当使用高级语言开发时，ETL作业有着专门的ETL服务器，此时，转换作业生成的往往是文本文件，在转 换作业完成后需要使用目标库特有的工具导入或者通过INSERT入目标库。同时，根据抽取作业的数据抽 取方式的不同（全量、增量），对目标表进行替换或者插入动作。
装载数据的最佳方法取决于所执行操作的类型以及需要装入多少数据。当目的库是关系数据库时，一般 来说有两种装载方式：
直接SQL语句进行insert、update、delete操作。
采用批量装载方法，如bcp、bulk、关系数据库特有的批量装载工具或api。
大多数情况下会使用第一种方法，因为它们进行了日志记录并且是可恢复的。
但是，批量装载操作易于使用，并且在装入大量数据时效率较高。使用哪种数据装载方法取决于业务系 统的需要。
4、流程控制
抽取加载和转换作业需要一个集中的调度平台控制他们的运行，决定执行顺序，进行错误捕捉和处理。 较为原始的ETL系统就是使用CRON做定时控制，定时调起相应的程序或者存储过程。但是这种方式过于 原始，只能进行简单的调起动作，无法实现流程依赖行为，同时按步执行的流程控制能力也弱，错误处 理能力几乎没有，只适合于极其简单的情况。
对于自行开发的较为完善的ETL系统，往往需要具有以下几个能力：
1）流程步骤控制能力

调度平台必须能够控制整个ETL流程（抽取加载和转换作业），进行集中化管理，不能有流程游离于系 统外部。
2）系统的划分和前后流程的依赖
由于整个ETL系统里面可能跨越数十个业务系统，开发人员有数十拨人，必须支持按照业务系统对ETL流 程进行划分管理的能力。
同时必须具有根据流程依赖进行调度的能力，使得适当的流程能在适当的时间调起。
3）合理的调度算法
同一时间调起过多流程可能造成对源数据库和ETL服务器还有目标数据库形成较大负载压力，故必须有 较为合理的调度算法。
4）日志和警告系统
必须对每一步的流程记录日志，起始时间，完成时间，错误原因等，方便ETL流程开发人员检查错误。 对于发生错误的流程，能及时通知错误人员进行错误检查和修复。
5）较高可靠性
5、常用商业ETL工具
常用的ETL工具有Ascential公司的Datastage、Informatica公司的Powercenter、 NCR Teradata公司的ETL
Automation等。
1） Datastage
是使用高级语言进行开发ETL服务器的代表。使用JAVA进行开发E/T/L的整个流程，同时支持平行添加服 务器提升处理效率的方法。
2） Powercenter
与Datastage类似，但元数据更加开放，存放在关系数据库中，可以很容易被访问。再有Powercenter不 能像Datastage运行多个实例，且不支持定制开发，参数控制更乱。
3） Automation
基于Teradata的TD数据库的ETL调度框架。其ETL流程是使用DSQL的存储过程进行开发，利用TD数据库 的海量数据处理能力，也具有一定的平行扩展能力

28 . 简述数据湖和数据仓库的区别 ？

1、数据湖
数据湖是以其自然格式存储的数据的系统或存储库，同行是对象blob或文件。数据湖通常是企业所有数 据的单一存储，包括源系统数据的原始副本，以及用于报告、可视化、分析和机器学习等任务的转换数 据。数据湖可以包括来自关系数据库（行和列）的结构化数据，半结构化数据（CSV，日志，XML， JSON），非结构数据（电子邮件、文档、PDF）和二进制数据（图像、音频、视频）。
2、数据仓库
是一个面向主题的、集成的、相对稳定的、反映历史变化的数据集合，用于支持管理决策。其主要功能 是将组织透过资讯系统之联机事务处理（OLTP）经年累月所积累的大量资料，透过数据仓库理论所特有 的资料存储架构，作一有系统的分析整理，以利各种分析方法如联机分析处理（OLAP）、数据挖掘
（Data Mining）之进行，并进而支持如决策支持系统（DSS）、主管资讯系统（EIS）之创建，帮助决策者能快速有效的自大量资料中，分析出有价值的资讯，以利决策拟定及快速回应外在环境变动，帮助构 建商业智能（BI）。
通俗一点，数据仓库存在的意义在于对企业的所有数据进行汇总，为企业各个部门提供统一的， 规范的数据出口。
3、数据仓库VS数据湖
相较而言，数据湖是较新的技术，拥有不断演变的架构。数据湖存储任何形式（包括结构化和非结构 化）和任何格式（包括文本、音频、视频和图像）的原始数据。根据定义，数据湖不会接受数据治理， 但专家们都认为良好的数据管理对预防数据湖转变为数据沼泽不可或缺。数据湖在数据读取期间创建模 式。与数据仓库相比，数据湖缺乏结构性，而且更灵活；它们还提供了更高的敏捷性。值得一提的是， 数据湖非常适合使用机器学习和深度学习来执行各种任务，比如数据挖掘和数据分析，以及提取非结构 化数据等。

29 . 简述离线处理和实时处理的区别 ？

1、离线处理
数据量大且时间周期长；
在大量数据上进行复杂的批量运算；
数据在计算之前已经固定，不再会发生变化； 能够方便的查询批量计算的结果。
2、实时处理
数据实时到达；
数据到达次序独立，不受应用系统所控制； 数据规模大且无法预知容量；
原始数据一经处理，除非特意保存，否则不能被再次取出处理，或者再次提取数据代价昂贵。

30 . 简述实时数仓和离线数仓的区别 ？

数据仓库的趋势：
实时数据仓库以满足实时化&自动化决策需求大数据&数据湖以支持大量&复杂数据类型

1、数据仓库架构的演变
从1990年 Inmon 提出数据仓库概念到今天，数仓架构经历了最初的传统数仓架构——离线数仓库——离线大数据架构、Lambda 架构、Kappa 架构以及 Flink 的火热带出的流批一体架构，数据架构技术不断演进，本质是在往流批一体的方向发展，让用户能以最自然、最小的成本完成实时计算。

1）传统数仓架构
这是比较传统的一种方式，结构或半结构化数据通过离线ETL定期加载到离线数仓，之后通过计算引擎 取得结果，供前端使用。这里的离线数仓+计算引擎，通常是使用大型商业数据库来承担，例如Oracle、DB2、Teradata等。
2）离线大数据架构
随着数据规模的不断增大，传统数仓方式难以承载海量数据。随着大数据技术的普及，采用大数据技术 来承载存储与计算任务。当然，也可以使用传传统数据库集群或MPP架构数据库来完成。例如
Hadoop+Hive/Spark、Oracle RAC、GreenPlum等。
3） Lambda架构（实时）
随着业务的发展，随着业务的发展，人们对数据实时性提出了更高的要求。此时，出现了Lambda架
构，其将对实时性要求高的部分拆分出来，增加条实时计算链路。从源头开始做流式改造，将数据发送 到消息队列中，实时计算引擎消费队列数据，完成实时数据的增量计算。与此同时，批量处理部分依然 存在，实时与批量并行运行。最终由统一的数据服务层合并结果给于前端。一般是以批量处理结果为 准，实时结果主要为快速响应。
4） Kappa架构（实时）
Lambda架构，一个比较严重的问题就是需要维护两套逻辑。一部分在批量引擎实现，一部分在流式引 擎实现，维护成本很高。此外，对资源消耗也较大。而后面诞生的Kappa架构，正是为了解决上述问
题。其在数据需要重新处理或数据变更时，可通过历史数据重新处理来完成。方式是通过上游重放完成
(从数据源拉取数据重新计算)。Kappa架构最大的问题是流式重新处理历史的吞吐能力会低于批处理，但 这个可以通过增加计算资源来弥补。
5）混合架构
上述架构各有其适应场景，有时需要综合使用上述架构组合满足实际需求。当然这也必将带来架构的复 杂度。用户应根据自身需求，有所取舍。在一般大多数场景下，是可以使用单一架构解决问题。现在很 多产品在流批一体、海量、实时性方面也有非常好的表现，可以考虑这种“全能手”解决问题。

2、三种大数据数据仓库架构
1）离线大数据架构
数据源通过离线的方式导入到离线数仓中。下游应用根据业务需求选择直接读取 DM 或加一层数据服务，比如 MySQL 或 Redis。数据仓库从模型层面分为三层：
ODS，操作数据层，保存原始数据； DWD，数据仓库明细层，根据主题定义好事实与维度表，保存最细粒度的事实数据；
DM，数据集市/轻度汇总层，在 DWD 层的基础之上根据不同的业务需求做轻度汇总；
典型的数仓存储是 HDFS/Hive，ETL 可以是 MapReduce 脚本或 HiveSQL。

2） Lambda架构（实时）
Lambda 架构问题：
同样的需求需要开发两套一样的代码：这是 Lambda 架构最大的问题，两套代码不仅仅意味着开发困难
（同样的需求，一个在批处理引擎上实现，一个在流处理引擎上实现，还要分别构造数据测试保证两者 结果一致），后期维护更加困难，比如需求变更后需要分别更改两套代码，独立测试结果，且两个作业 需要同步上线。
资源占用增多：同样的逻辑计算两次，整体资源占用会增多，多出实时计算这部分

3） Kappa 架构（实时）
Lambda 架构虽然满足了实时的需求，但带来了更多的开发与运维工作，其架构背景是流处理引擎还不完善，流处理的结果只作为临时的、近似的值提供参考。后来随着 Flink 等流处理引擎的出现，流处理技术很成熟了，这时为了解决两套代码的问题，LickedIn 的 Jay Kreps 提出了 Kappa 架构。
Kappa 架构可以认为是 Lambda 架构的简化版（只要移除 lambda 架构中的批处理部分即可）。在 Kappa 架构中，需求修改或历史数据重新处理都通过上游重放完成。
Kappa 架构最大的问题是流式重新处理历史的吞吐能力会低于批处理，但这个可以通过增加计算资源来弥补。

31 . 简述Hadoop（HDFS）和MySQL的区别 ？

1、Hadoop
优点：
Hadoop是天然分布式架构的，使用hdfs可以存储海量数据，通过分布式拓展可以获取无限的存储 资源；使用map-reduce可以并行计算海量数据，通过分布式拓展同样可以获取无限的计算资源。
hadoop支持存储和计算各种格式数据。数据来源可以使文本，mysql结构化数据，key/value键值对 等
缺点：
入门门槛高，需要学习大量存储计算框架，而且还需要有一定分布式思维。消耗资源比较多，一般来说都要很多节点同时工作，成本比较高。
处理数据量大，一般都是PB级别的，即使多个节点同时工作，依然处理一批数据长达小时级别
（使用flink和spark可以达到实时计算）。
维护成本高，架构复杂，需要经验丰富开发人员作业。
使用map-reduce编写计算程序，需要编写map和reduce代码，不如mysql直接使用sql语句方便
（hive,pig等框架支持sql转换为mapreduce程序）。
使用场景：

适合处理离线大数据，做一些报表，适合已经超过mysql处理能力范围之外的存储和计算。
由于计算存储可无限扩展，可以基于这个能力做一些数据分析挖掘工作，真正体现大数据框架的优 势和价值。
2、MySQL
优点：
mysql使用表存储数据,使用sql直接查询和一些聚合(sum,avg…)计算,使用操作简单；
mysql上手入门门槛低,基本上就是安装,学会使用基本的DDl,DQL就算是入门了；
mysql只是作为一个存储中间件,一般是单节点,主从节点的结构,架构相对简单,生态圈相对干净；
mysql响应速度快，基本处理速度能达到毫秒级别。
缺点：
一般单节点运行,存储数据量小,一般单表达到几千万条数据量，性能就会受到影响；当然目前也可 以采用分表分库（mycat,sharding jdbc）来解决。但是处理的数据依然有限。
mysql因为处理数据集有限，很容易就达到检索索引瓶颈，因此当达到一定数据量时，为了满足毫 秒级别响应，经常要做一些sql优化，借助redis缓存，分表分库来实现；对于一般开发人员而言是 一个很大的挑战，需要很多优化方案，而且可能带来新的问题。
mysql是关系型数据库，一般只方便用来处理结构固定的表结构数据，不支持或者不擅长别的格式 数据的存储和处理 。
mysql不太适合做一些报表统计类的业务，比如运营统计之类的，处理的话，耗时非常长，而且也 是要做成离线库单独跑job，而且也只能统计小数据集的统计业务，毕竟单机处理能力有限。
使用场景：
因为mysql响应快，一般用于处理线上业务，比如订单级别的数据，一般数据量不会很大，完全可 以通过mycat, sharding jdbc分表分库进行压力分担来解决。
mysql作为一个关系型数据库，适合处理结构单一的表结构数据。
能处理小数据集的报表运营统计，但是挺耗费时间的，而且单机处理能力有限，一般做成离线数据 库单独处理数据。
3、总结
mysql以处理小数据量，响应速度快为优势，服务于和用户交互场景。
hadoop以处理大数据量，服务于用户交互后场景的数据分析和挖掘场景

32 . 说说Storm、Flink、Spark的区别，各自的优缺点，适用场景 ？

从流处理的角度将Flink与Spark和Storm这两个框架进行比较，会主要基于以下这几点展开：
功能性（Functionality）
是否能很好解决流处理功能上的痛点 , 比如event time和out of order data。
容错性（Fault Tolerance）
在failure之后能否恢复到故障之前的状态，并输出一致的结果；此外容错的代价也是越低越好，因为其 直接影响性能。
吞吐量(throughputs)& 延时(latency)
性能相关的指标，高吞吐和低延迟某种意义上是不可兼得的，但好的流引擎应能兼顾高吞吐&低延时。

1、功能性（Functionality）
event time：指数据或者事件真正发生时间 , 比如用户点击网页时产生一条点击事件的数据，点击时间就是这条数据固有的event time。
processing time：指计算框架处理这条数据的时间。
spark DStream和storm 1.0以前版本往往都折中地使用processing time来近似地实现event time相关的业务。显然，使用processing time模拟event time必然会产生一些误差， 特别是在产生数据堆积的时候， 误差则更明显，甚至导致计算结果不可用。
在使用event time时，自然而然需要解决由网络延迟等因素导致的迟到或者乱序数据的问题。为了解决这个问题， spark、storm及flink都引入了watermark和lateness的概念。
watermark：是引擎处理事件的时间进度，代表一种状态，一般随着数据中的event time的增长而增长。比如 watermark(t)代表整个流的event time处理进度已经到达t， 时间是有序的，那么streaming 不应该会再收到timestamp t’ < t的数据，而只会接受到timestamp t’ >= t的数据。 如果收到一条timestamp t’ < t的数据， 那么就说明这条数据是迟到的。lateness：表示可以容忍迟到的程度，在lateness可容忍范围内的数据还会参与计算，超过的会被丢 弃。
spark底层对static batch data和streaming data有共同的rdd抽象，完美兼容互操作。而flink中DataSet 和
DataStream是完全独立的，不可以直接交互。
此外，flink还可以运行storm的topology，带来较强的移植性。另外一个有趣的功能是可以自由调整job latency and throughputs的取舍关系，比如需要high throughputs的程序可以牺牲latency来获得更大的
throughputs。
2、容错性（Fault Tolerance）
spark依赖checkpoint机制来进行容错，只要batch执行到doCheckpoint操作前挂了，那么该batch就会被 完整的重新计算。spark可以保证计算过程的exactly once（不包含sink的exactly once）。
storm的容错通过ack机制实现，每个bolt或spout处理完成一条data后会发送一条ack消息给acker bolt。当该条data被所有节点都处理过后，它会收到来自所有节点ack， 这样一条data处理就是成功的。storm 可以保证数据不丢失，但是只能达到at least once语义。此外，因为需要每条data都做ack，所以容错的开销很大。storm trident是基于micro¬batched实现了exactly once语义。
flink使用Chandy-Chandy-Lamport Algorithm 来做Asynchronous Distributed Snapshots（异步分布式快 照），其本质也是checkpoint。如下图，flink定时往流里插入一个barrier（隔栏），这些barriers把数据
分割成若干个小的部分，当barrier流到某个operator时，operator立即会对barrier对应的一小部分数据做checkpoint并且把barrier传给下游（checkpoint操作是异步的，并不会打断数据的处理），直到所有的 sink operator做完自己checkpoint后，一个完整的checkpoint才算完成。当出现failure时，flink会从最新完整的checkpoint点开始恢复。

flink的checkpoint机制非常轻量，barrier不会打断streaming的流动，而且做checkpoint操作也是异步的。 其次，相比storm需要ack每条data，flink做的是small batch的checkpoint，容错的代价相对要低很多。最重要的是flink的checkpoint机制能保证exactly once。

3、吞吐量和延迟（Throughputs& Latency）
1）吞吐量（throughputs）
spark是mirco-batch级别的计算，各种优化做的也很好，它的throughputs是最大的。但是需要提一下， 有状态计算（如updateStateByKey算子）需要通过额外的rdd来维护状态，导致开销较大，对吞吐量影响 也较大。
storm的容错机制需要对每条data进行ack，因此容错开销对throughputs影响巨大，throughputs下降甚至 可以达到70%。storm trident是基于micro-batch实现的，throughput中等。
flink的容错机制较为轻量，对throughputs影响较小，而且拥有图和调度上的一些优化机制，使得flink可 以达到很高 throughputs。
storm在打开ack容错机制后，throughputs下降非常明显。而flink在开启checkpoint和关闭的情况下
throughputs变化不大，说明flink的容错机制确实代价不高。对比官网的benchmark，我们也进行了
throughputs的测试，实测结果是flink throughputs是storm的3.5倍，而且在解除了kafka集群和flink集群的带宽瓶颈后，flink自身又提高了1.6倍。
2）延迟（latency）
spark基于micro-batch实现，提高了throughputs，但是付出了latency的代价。一般spark的latency是秒级 别的。
storm是native streaming实现，可以轻松的达到几十毫秒级别的latency，在几款框架中它的latency是最低的。storm trident是基于micro-batch实现的，latency较高。
flink也是native streaming实现，也可以达到百毫秒级别的latency。
从flink官网给出的和storm的latency对比benchmark得知。storm可以达到平均5毫秒以内的latency，而
flink的平均latency也在30毫秒以内。两者的99%的data都在55毫秒latency内处理完成，表现都很优秀。
4、总结
综合对比spark、storm和flink的功能、容错和性能如下表

框架 Storm Spark Flink
Streaming模型 Native Micro-batch Native
确保性 At-least-once Exactly-once Exactly-once
容错性 Record-ACK Checkpoint Checkpoint
容错开销 高 中等 低
延迟 非常低 高 低
吞吐量 低 高 高
如果想要的是一个允许增量计算的高速事件处理系统，Storm会是最佳选择。
如果必须有状态的计算，恰好一次的递送，并且不介意高延迟的话，那么可以考虑Spark Streaming，特别如果你还计划图形操作、机器学习或者访问SQL的话，Apache Spark的stack允许你将一些library与数据流相结合(Spark SQL，Mllib，GraphX)，它们会提供便捷的一体化编程模型。尤其是数据流算法(例
如：K均值流媒体)允许Spark实时决策的促进。
Flink支持增量迭代，具有对迭代自动优化的功能，在迭代式数据处理上，比Spark更突出，Flink基于每 个事件一行一行地流式处理，真正的流式计算，流式计算跟Storm性能差不多，支持毫秒级计算，而
Spark则只能支持秒级计算。

33 . 简述HDFS与HBase有什么关系 ？

1、HDFS文件存储系统和HBase分布式数据库
HDFS是Hadoop分布式文件系统。
HBase的数据通常存储在HDFS上。HDFS为HBase提供了高可靠性的底层存储支持。
Hbase是Hadoop database，即Hadoop数据库。它是一个适合于非结构化数据存储的数据库，HBase基于列的而不是基于行的模式。
HBase是Google Bigtable的开源实现，类似Google Bigtable利用GFS作为其文件存储系统，HBase利用Hadoop HDFS作为其文件存储系统；Google运行MapReduce来处理Bigtable中的海量数据，HBase可以使用Hadoop MapReduce来处理HBase中的海量数据。
HDFS为HBase提供了高可靠性的底层存储支持，Hadoop MapReduce为HBase提供了高性能的计算能力， Zookeeper为HBase提供了稳定服务和failover机制。Pig和Hive还为HBase提供了高层语言支持，使得在HBase上进行数据统计处理变的非常简单。Sqoop则为HBase提供了方便的RDBMS（关系型数据库）数据 导入功能，使得传统数据库数据向HBase中迁移变的非常方便。

2、HBase本身作为一个分布式数据库
HBase 本身其实可以完全不要考虑 HDFS 的，完全可以只把 HBase 当作是一个分布式高并发 k-v 存储系统，只不过它底层的文件系统是通过 HDFS 来支持的罢了。换做其他的分布式文件系统也是一样的，不影响 HBase 的本质。甚至如果不考虑文件系统的分布式或稳定性等特性的话，完全可以用简单的本地文件系统，甚至内存文件系统来代替。
HBase 在 HDFS 之上提供了：
高并发实时随机写，通过 LSM（内存+顺序写磁盘）的方式提供了 HDFS 所不拥有的实时随机写及修改功能
高并发实时点读及扫描了解一下 LSM 算法，在文件系统之上有数据库，在业务层面，HBase 完全可以独立于 HDFS 来理解

3、HBase可以满足大规模数据的实时处理需求
HDFS面向批量访问模式，不是随机访问模式Hadoop可以很好地解决大规模数据的离线批量处理问题， 但是，受限于Hadoop MapReduce编程框架的高延迟数据处理机制，使得Hadoop无法满足大规模数据实时处理应用的需求。
传统的通用关系型数据库无法应对在数据规模剧增时导致的系统扩展性和性能问题(分库分表也不 能很好解决)
传统关系数据库在数据结构变化时一般需要停机维护;空列浪费存储空间
因此，业界出现了一类面向半结构化数据存储和处理的高可扩展、低写入/查询延迟的系统，例如键值 数据库、文档数据库和列族数据库(如BigTable和HBase等)。
HBase多是应用于互联网服务领域和传统行业的众多在线式数据分析处理系统中。

34 . 简述存储格式的选择，行式存储与列式存储的优劣 ？

1、优缺点分析
列存储优点：
单列数据保存在一起，不同列分开存储，导致存下同样一个表需要更多的Block文件，看起来是更 复杂了，但是基于列和列分开存储，这种形式天生就适合分布式的存储，并能完全利用并发写入和 并发读取的能力
同一列存放在一起，数据类型相同，则更好的进行压缩
同一列存放在一起，则排序更加方便，基于排序方便，where某一列会更加快
行存储优点：
更容易实现事务性、一致性控制。应用场景：
关系型数据库基本都是行存储，Mysql、Oracle等，因其更强调一致性和事务性
NoSQL多数为列存储，因为高效、吞吐量高，但事务、一致性较弱（也有做到事务性比较强的，但 实现更加复杂，需要更多东西来配合）
总结：
行： 一致性、事务更加容易实现
列：吞吐量高、性能强，一致性、事务性较弱
2、列式存储和行式存储的比较
列式存储和行式存储是针对数据在存储介质中的排序形式而言的，假设存在一张table，那么：
行式存储：依次连续存储第1、2、3…行的数据到存储介质中； 列式存储：依次连续存储第1、2、3…列的数据到存储介质中。
下图所示为行式存储和列式存储的示意图，一张table包含5个字段（列）即rowid、date/time、customer
name以及quantity，共7行，图中的红色箭头表示存储顺序。

3、行式存储和列式存储的优缺点和适用场景
存储形式的差异决定了适用场景的不同：
1）行式存储适合”针对行”的查询：
比如（mysql）select * from table_name limit 1，因为只会读取图1-1中的“row-based store 第1个绿色部分的数据”（只有指定的行“1 845 2 3 1”才会被读取），而select rowid from table_name则需要读取row- based store所有绿色部分的数据（虽然目的仅是要查询1个字段）；此外还适用于insert/update操作比较多的场景，因为只需要更改部分数据块即可。
2）列式存储适合“针对列”的查询：
比如select rowid from table_name，因为只会读取上图中的“column-based store 第1个绿色部分的数据”
（查询时只有涉及到的字段会被读取），而select * from table_name limit 1则需要读取column-based
stores所有绿色部分的数据（虽然目的就是要查询第1行的数据）；但是不适用于insert/update操作比较 多的场景，比如当插入1个row时，由于列式存储导致同一个row的数据被分散在多个数据块中，因此需 要去遍历所有数据块的数据。此外由于同一个字段连续存储（同一列的内容有很多值是重复的，可以压 缩），因此更加便于编码压缩。

存储类别 适用于 不适用于
row-based 针对行的查询， insert/update操作 针对列的查询
column- based 针对列的查询， 编码压缩减小存储空间占用 针对行的查询， insert/update操作
综合来看，列式存储比较适合大数据量（压缩比高）、分析型操作（针对少数几列）；不适合频率较高 的删除（全列检索）、更新（重新压缩）操作。

35 . 简述Hive、HBase、HDFS之间的关系 ？

1、Hive
Hive 是基于 Hadoop 的一个数据仓库工具，提供静态数据的动态查询。其使用类SQL语言，底层经过编译转为MapReduce程序，在Hadoop上运行，数据存储在HDFS上。
2、HDFS
HDFS是GFS的一种实现，他的完整名字是分布式文件系统，类似于FAT32，NTFS，是一种文件格式，是 底层的。
Hive与Hbase的数据一般都存储在HDFS上。Hadoop HDFS为他们提供了高可靠性的底层存储支持。
3、HBase
Hbase是Hadoop database，即Hadoop数据库。它是一个适合于非结构化数据存储的数据库，HBase基于列的而不是基于行的模式。
HBase是Google Bigtable的开源实现，类似Google Bigtable利用GFS作为其文件存储系统，HBase利用Hadoop HDFS作为其文件存储系统；Google运行MapReduce来处理Bigtable中的海量数据，HBase可以使用Hadoop MapReduce来处理HBase中的海量数据。

Hadoop HDFS为HBase提供了高可靠性的底层存储支持，Hadoop MapReduce为HBase提供了高性能的计算能力，Zookeeper为HBase提供了稳定服务和failover机制。Pig和Hive还为HBase提供了高层语言支持， 使得在HBase上进行数据统计处理变的非常简单。 Sqoop则为HBase提供了方便的RDBMS（关系型数据库）数据导入功能，使得传统数据库数据向HBase中迁移变的非常方便

36 . 简述Hive中的数据在哪存放，MySQL的在哪存放 ？

Hive是把数据存储在HDFS上
MySQL数据是存储在自己的系统中，文件默认存放位置MySQL安装目录下的data文件夹。

37 . 简述当数据量非常多，HDFS扛不住Flume采集的压力怎么办 ？

使用Kafka做一个削峰
如果上游数据时有突发流量，下游可能扛不住，或者下游没有足够多的机器来保证冗余，Kafka在中间 可以起到一个缓冲的作用，把消息暂存在Kafka中，下游服务就可以按照自己的节奏进行慢慢处理

38 . 简述Hadoop和gp（GreenPlum）区别 ？

GreenPlum是分布式数据库系统。它是典型关系型数据库产品，是面向查询的关系型数据库。它的特点 主要就是查询速度快，数据装载速度快，批量DML处理快。而且性能可以随着硬件的添加呈线性增加， 拥有非常良好的可扩展性。因此，它主要适用于面向分析的应用。GreenPlum基于Apache MADLib具有高级机器学习功能，支持快速复杂查询分析，满足各种BI用户需求。
Hadoop是一种分布式计算框架，涉及分布式存储HDFS，分布式计算MapReduce，Yarn作业调度和集群 资源管理框架。
可以把GreenPlum部署到Hadoop上，完成数据的分析处理

39 . 简述为什么要使用Scala开发Spark而不使用python ？

1、从性能上来看
由于Java虚拟机的存在，Scala比Python快十倍，而Python在数据分析和有效数据处理的性能方面则较 慢。Python首先调用涉及大量代码处理的Spark库，并且性能自动降低。
同时，当内核数量有限时，Scala更好。如果他们的人数增加，那么Scala也会开始表现出怪异的行为， 并且不被专业人员所喜欢。这里，问题来了，性能应该基于内核或数据处理来决定。显然，数据处理应 视为性能的主要决定因素，毫无疑问，对于大数据Spark项目，Scala的性能要优于Python。
2、从并发上来看
基于大数据系统的复杂性，迫切需要能够将各种数据库程序或服务集成在一起的编程语言。Scala在这 里享有很高的偏爱，因为它提供了多个标准库和核心，可帮助在大数据生态系统中快速集成数据库。
使用Scala，开发人员可以编写具有多个并发原语的更高效，可维护和可读的代码。同时，Python不能 很好地支持并发和多线程。如果您将Python用于大型数据项目，则在该特定时间间隔内，Python进程中 只有一个CPU处于活动状态。
3、从安全性来看
在为Spark项目开发代码时，开发人员需要不断对其进行重构。Scala是一种静态类型的语言，提供了一 种捕获编译时错误的接口。与像Python这样的动态类型化语言相比，Scala中的重构代码轻松而轻松地体 验。
4、从高级功能来看
Scala具有各种存在性类型，隐式和宏。
Scala在框架，库，隐式，宏等方面总是更加强大。对于NLP和机器学习，Python是最佳选择

40 . 简述Scala和Java有什么区别 ？

1、什么是Scala
Scala是一种多范式的编程语言，其设计的初衷是要集成面向对象编程和函数式编程的各种特性。Scala
运行于Java平台（Java虚拟机），并兼容现有的Java程序。
2、为什么要学Scala
优雅：这是框架设计师第一个要考虑的问题，框架的用户是应用开发程序员，API是否优雅直接影响用 户体验。
速度快：Scala语言表达能力强，一行代码抵得上Java多行，开发速度快；Scala是静态编译的，所以和
JRuby,Groovy比起来速度会快很多。
能融合到Hadoop生态圈：Hadoop现在是大数据事实标准，Spark并不是要取代Hadoop，而是要完善
Hadoop生态。JVM语言大部分可能会想到Java，但Java做出来的API太丑，或者想实现一个优雅的API太费劲。
3、什么是Java
Java是一门面向对象编程语言，不仅吸收了C++语言的各种优点，还摒弃了C++里难以理解的多继承、指 针等概念，因此Java语言具有功能强大和简单易用两个特征。Java语言作为静态面向对象编程语言的代 表，极好地实现了面向对象理论，允许程序员以优雅的思维方式进行复杂的编程。
4、为什么要学Java
Java具有简单性、面向对象、分布式、健壮性、安全性、平台独立与可移植性、多线程、动态性等特点
[2] 。Java可以编写桌面应用程序、Web应用程序、分布式系统和嵌入式系统应用程序等