阿里云大数据开发一面面经，已过，面试题已配答案

先来看一张图

具体各个阶段做了什么

spliting ：Documents会根据切割规则被切成若干块，

map阶段：然后进行Map过程，Map会并行读取文本，对读取的单词进行单词分割，并且每个词以键值对<key,value>形式生成。

例如：读取到”Hello World Hello Java“，分割单词形成Map <Hello,1> <World,1><Hello,1> <Java,1>  

combine阶段：接下来Combine(该阶段是可以选择的，Combine其实也是一种reduce）会对每个片相同的词进行统计。

shuffle阶段：将Map输出作为reduce的输入的过程就是shuffle,次阶段是最耗时间,也是重点需要优化的阶段。shuffle阶段会对数据进行拉取，对最后得到单词进行统计，每个单词的位置会根据Hash来确定所在的位置，

reduce阶段：对数据做最后的汇总，最后结果是存储在hdfs上。

3、HDFS读写机制

4、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。

5、Spark Streaming和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 机制来处理滞后数据。

6、Kafka好处

高吞吐量、低延迟：kafka每秒可以处理几十万条消息，它的延迟最低只有几毫秒；

可扩展性：kafka集群支持热扩展；

持久性、可靠性：消息被持久化到本地磁盘，并且支持数据备份防止数据丢失；

容错性：允许集群中节点故障（若副本数量为n,则允许n-1个节点故障）；

高并发：支持数千个客户端同时读写。

7、数据仓库架构

架构是数据仓库建设的总体规划，从整体视角描述了解决方案的高层模型，描述了各个子系统的功能以及关系，描述了数据从源系统到决策系统的数据流程。业务需求回答了要做什么，架构就是回答怎么做的问题。

1、架构的价值

• 最大满足需求

• 便于团队沟通

• 便于进行规划

• 提高灵活性、生成率

• 便于维护

• 便于团队学习

2、数据仓库架构

数据仓库的核心功能从源系统抽取数据，通过清洗、转换、标准化，将数据加载到BI平台，进而满足业务用户的数据分析和决策支持。

数据仓库架构包含三个部分：数据架构、应用程序架构、底层设施。

1）底层设施

底层设施为架构提供了基础，底层设施包括硬件、数据库平台、网络和桌面系统。

（1）硬件

硬件主要指服务器硬件，主要有数据库服务器、ETL服务器、调度服务器、报表服务器、BI门户服务器、接口服务器。

（2）数据库平台

数据库平台分为二大类：联机事务处理OLTP（on-line transaction processing）、联机分析处理OLAP（On-Line Analytical Processing），主要有Oracel，MySQL。OLAP是为数据分析而设计的数据库管理系统。主要有Teradata, Greenplum，Hive，Kudu。

（3）桌面系统

数据仓库不同的应用对桌面系统也有不同的要求，开发工具主要有Window、Mac面系统，部署服务器主要有Unix桌面系统，系统BI应用程序主要有Window、Mac、移动设备桌面系统。

（4）网络

网络是底层设施的基础，特别是大数据时代对网络的要求越来越高。

2）BI应用程序架构

数据仓库是数据处理的后台，业务用户并不关心后台怎么处理。BI应用是数据呈现的前台，是业务用户进行查询的入口。BI应用程序的体验也是衡量数据仓库是否成功的主要因素。

（1）BI分析周期

业务分析从监视活动开始识别某个问题或时机，进而采取行动，最终回到监视该活动产生的结果上来，达到数据驱动业务增长的目的。分析周期把这个过程分为五个不同的阶段。

（2）BI应用分类

接口查询

• 数据以接口的形式提供给上下游系统，供上下业务系统进行查询。主要有推和拉二种模式。

即席查询

• 业务用户根据自己的需求，自定义查询请求，后台自动组织SQL语句访问维度模型。

标准报表

• 根据业务用户的需求，进行定制报表。

仪表盘

• 它是向企业展示度量信息和关键业务指标现状的数据可视化工具。

数据挖掘

• 为数据挖掘工具提供标准基础数据。

运营查询

• 为了减少业务系统的大数据量查询压力，数据仓库为业务系统提供实时的查询。

（3）数据存储

• 为了提高查询性能，BI工具需要把数据存储在本地服务器上

• OLAP多维模型需要把数据存储成Cube格式

• 把数据存储成文件格式，放在其他服务器上

3）数据结构

数据架构主要描述数据从源系统抽取数据，然后经过清洗、规范化、提交形成标准模型，最终提交给业务用户，以及对数据的管理。

（1）源系统

数据仓库一般会面临多个、异构数据源的问题，主要分为结构化，半结构化以及非结构化数据。为了便于管理需要对源系统建立元数据信息。

（2）抽取

因为源系统的多样性，源抽取阶段一般选择使用工具。在抽取之前还要做以下工作：

数据剖析是对数据的技术性分析，对数据的内容、一致性和结构进行描述。对源系统的数据质量进行评估。

• 数据剖析

• 变化数据捕获策略

为了减少对源系统的影响，一般只抽取变化的数据，也需要识别物理删除的数据。CDC策略主要有：

添加审计列

• 在源系统追加日期字段，当数据发生变化的时候，系统会自动更新该值。如果由后台人员手工修改数据，可能就发生遗漏。

数据比较

• 比较源系统和数据仓库的数据，只抽取变化的数据。这种方法需要全量的数据，比较耗费资源。可以视数据量的大小而定。

读取日志

• 读取数据库操作日志信息，同步到数据仓库中。一般日志的有效期比较短，一旦发生要重跑的情况，可能以前的日志已经被清空了。

消息队列

• 把事务信息放到消息队列里，以流的形式同步到数据仓库。这种方式即可以减轻源系统的压力，又能做到实时同步。

（3）数据转换

数据从源系统抽取过来之后，就要进入数据转换阶段。 这一阶段是数据仓库开发核心阶段。主要有以下步骤：

清洗

数据清洗是制定转换规则，筛选数据并纠正数据的过程。清洗的目的是改进源系统的数据质量，但是不要在数据仓库做过多的清洗，源系统的数据质量应该在源头处理。清洗的主要内容包括：

• 制定数据转换规则

• 提交错误事实表

规范化

规范化就是整合各个源系统的数据，把数据统一命名，统一取值，建立企业标准版本数据。主要内容包括：

• 数据标准化

• 删除重复数据

• 数据共存策略

（4）提交

提交就要根据维度模型生成维度表和事实表。 提交主要内容包括：

• 选择合适的缓慢变化维类型

• 为维表生成代理键

• 管理不同粒度的层次维

• 管理专项维

• 生成维度桥接表

• 生成代理键管道

• 选择合适的事实表类型

• 处理延迟到达的事实

• 生成维度表

• 生成事实表

（5）聚集

聚集是指根据事务事实表进行更高粒度的聚合以及生成相对应的维度表。主要内容包括：

• 数据聚合

• 缩小维度表

• 生成OLAP多维数据集

（6）数据存储

数据存储是指在在数据的生命周期内对数据的管理，主要内容包括：

• 数据备份

• 历史数据归档

• ETL过程中数据分层存储

首先，我要知道数据仓库分层架构的目标是什么？是为了实现维度建模，进而支撑决策分析目标。

数据分层从关系型在线交易系统到面向主题的数据仓库系统，从范式建模到维度建模的必经之路。

数据分层是一套让我们的数据体系更有序的行之有效的数据组织和管理方法。数据分层不是银弹，也没有绝对标准，当然也不能包治百病，不能解决所有的数据问题，但是，数据分层却可以给我们带来如下的好处：

隔离原始数据：不论是数据的异常还是数据敏感度，使真实数据与统计数据解耦开。

数据结构化更清晰：每一个数据分层都有它的作用域和职责，在使用表的时候能更方便地定位和理解。

数据血缘追踪：提供给外界使用的是一张业务表，但是这张业务表可能来源很多张表。如果有一张来源表出问题了，我们可以快速准确的定位到问题，并清楚每张表的作用范围。

增强数据复用能力：减少重复开发，通过数据分层规范化，开发一些通用的中间层数据，能够减少重复计算，提高单张业务表的使用率，提升系统的执行效率。

简化复杂的问题：把一个复杂的业务分成多个步骤实现，每一层只处理单一的步骤，比较简单和容易理解。而且便于维护数据的准确性，当数据出现问题之后，可以不用修复所有的数据，只需要从有问题的步骤开始修复。

减少业务的影响：业务可能会经常变化，这样做就不必改一次业务就需要重新接入数据。

减少重复开发：规范数据分层，开发一些通用的中间层数据，能够减少极大的重复计算。

统一数据口径：通过数据分层，提供统一的数据出口，统一对外输出的数据口径。

分层的核心思想就是解耦，再解耦，把复杂的问题简单化。

数据仓库基础分层主要是分为四层，如下图所示

如上图所示，一个公司可能有多个业务系统，而数据仓库就是将所有的业务系统按照某种组织架构整合起来，形成一个仓储平台，也就是数仓。

1、四层分层

第一层：

ODS——原始数据层：存放原始数据

ODS层即操作数据存储，是最接近数据源中数据的一层，数据源中的数据，经过抽取、洗净、传输，也就说传说中的ETL之后，装入本层；一般来说ODS层的数据和源系统的数据是同构的，主要目的是简化后续数据加工处理的工作。从数据粒度上来说ODS层的数据粒度是最细的。ODS层的表通常包括两类，一个用于存储当前需要加载的数据，一个用于存储处理完后的历史数据。历史数据一般保存3-6个月后需要清除，以节省空间。但不同的项目要区别对待，如果源系统的数据量不大，可以保留更长的时间，甚至全量保存；数据在装入本层前需要做以下工作：去噪、去重、提脏、业务提取、单位统一、砍字段、业务判别。

第二层：

DWD——数据明细层：对ODS层数据进行清洗、维度退化、脱敏等。覆盖所有系统的、完整的、干净的、具有一致性的数据层。

该层一般保持和ODS层一样的数据粒度，并且提供一定的数据质量保证，在ODS的基础上对数据进行加工处理，提供更干净的数据。同时，为了提高数据明细层的易用性，该层会采用一些维度退化手法，当一个维度没有数据仓库需要的任何数据时，就可以退化维度，将维度退化至事实表中，减少事实表和维表的关联。例如：订单id,这种量级很大的维度，没必要用一张维度表来进行存储，而我们一般在进行数据分析时订单id又非常重要，所以我们将订单id冗余在事实表中，这种维度就是退化维度。

第三层：

DWS——数据服务层： 对DWD层数据进行一个轻度的汇总。

DWS层为公共汇总层，会进行轻度汇总，粒度比明细数据稍粗，会针对度量值进行汇总，目的是避免重复计算。该层数据表会相对比较少，大多都是宽表(一张表会涵盖比较多的业务内容，表中的字段较多)。按照主题划分，如订单、用户等，生成字段比较多的宽表，用于提供后续的业务查询，OLAP分析，数据分发等。

第四层：

DM——数据集市层：为各种统计报表提供数据。

存放的是轻度聚合的数据，也可以称为数据应用层，基于DWD、DWS上的基础数据，整合汇总成分析某一个主题域的报表数据。主要是提供给数据产品和数据分析使用的数据，通常根据业务需求，划分成流量、订单、用户等，生成字段比较多的宽表，用于提供后续的业务查询，OLAP分析，数据分发等。从数据粒度来说，这层的数据是汇总级的数据，也包括部分明细数据。从数据的时间跨度来说，通常是DW层的一部分，主要的目的是为了满足用户分析的需求，而从分析的角度来说，用户通常只需要分析近几年的即可。从数据的广度来说，仍然覆盖了所有业务数据。

2、三层分层

上述四层数仓，如果是问的三层数仓，就相当于是把DWD、DWS合并成DW层，往细的方面分，DW还包括DWM层（数据中间层），三层分层如下：

第一层：

ODS——原始数据层：存放原始数据

第二层：

DW——数据仓库层：数据清洗，初步汇总

本层将从 ODS 层中获得的数据按照主题建立各种数据模型，每一个主题对应一个宏观的分析领域，数据仓库层排除对决策无用的数据，提供特定主题的简明视图。在DW层会保存BI系统中所有的历史数据，例如保存10年的数据。

第三层：

DM——数据集市层

3、五层分层

五层分层如下：

第一层：

ODS——原始数据层：存放原始数据

第二层：

DWD——数据明细层：对ODS层数据进行清洗、维度退化、脱敏等。

第三层：

DWS——数据汇总层： 对DWD层数据进行一个轻度的汇总。

第四层：

ADS——数据应用层：为各种统计报表提供数据

该层是基于DW层的数据，整合汇总成主题域的服务数据，用于提供后续的业务查询等。

第五层：

DIM——维表层：基于维度建模理念思想，建立整个企业的一致性维度。

维表层主要包含两部分数据：

高基数维度数据：一般是用户资料表、商品资料表类似的资料表。数据量可能是千万级或者上亿级别。

低基数维度数据：一般是配置表，比如枚举值对应的中文含义，或者日期维表。数据量可能是个位数或者几千几万。