spark和hadoop的区别

spark和hadoop的区别：诞生的先后顺序、计算不同、平台不同。

诞生的先后顺序，hadoop属于第一代开源大数据处理平台，而spark属于第二代。属于下一代的spark肯定在综合评价上要优于第一代的hadoop。

计算不同spark和hadoop在分布式计算的底层思路上，其实是极为相似的，即mapreduce分布式运算模型：将运算分成两个阶段，阶段1-map，负责从上游拉取数据后各自运算，然后将运算结果shuffle给下游的reduce，reduce再各自对通过shuffle读取来的数据进行聚合运算spark和hadoop在分布式计算的具体实现上，又有区别；hadoop中的mapreduce运算框架，一个运算job，进行一次map-reduce的过程；而spark的一个job中，可以将多个map-reduce过程级联进行。

平台不同spark和hadoop区别是，spark是一个运算平台，而hadoop是一个复合平台（包含运算引擎，还包含分布式文件存储系统，还包含分布式运算的资源调度系统），所以，spark跟hadoop来比较的话，主要是比运算这一块大数据技术发展到目前这个阶段，hadoop主要是它的运算部分日渐式微，而spark目前如日中天，相关技术需求量大，offer好拿。

不论是Hive还是Spark SQL在使用过程中都可能会遇到小文件过多的问题。小文件过多最直接的表现是任务执行时间长，查看Spark log会发现大量的数据移动的日志。我们可以查看log中展现的日志信息，去对应的路径下查看文件的大小和个数。

通过上述命令可以查看文件的个数以及大小。count查看出的文件大小单位是B，需要转换为MB。

在spark官方的推荐文档中，parquet格式的文件推荐大小是128MB，小于该大小的均可以称之为小文件，在实际的工作，往往小文件的大小仅仅为几KB，表现为，可能文件大小为几百MB，但是文件个数可能到达了几十万个。一般来说，我们可以通过简单相除获得文件的平均大小，如果文件数目不多，我们也可以通过下述命令获得每个文件的大小。

1任务执行时间长

2真实的文件大小独占一个数据存储块，存放到DataNode节点中。同时 DataNode一般默认存三份副本，以保障数据安全。同时该文件所存放的位置也写入到NameNode的内存中，如果有Secondary NameNode高可用节点，也可同时复制一份过去。NameNode的内存数据将会存放到硬盘中，如果HDFS发生重启，将产生较长时间的元数据从硬盘读到内存的过程。

3不论在Hive还是在Spark中，每一个存储块都对应一个Map程序，一个Map呈现就需要一个JVM，启动一个JVM去读取或者写小文件是吃力不讨好的行为。在实际的生产中，为了更好的管理集群资源，一般会要求程序执行时限制Executor数量和每个Executor的核心数量，需要频繁创建Executor来读取写入。

5影响磁盘寻址时间

小文件合并，本质上就是通过某种 *** 作，将一系列小文件合并成大文件。我们知道，以MapReduce为代表的大数据系统，都习惯用K-V键值对的形式来处理文件，最后文件落盘，也是一个reduce对应一个输出文件。所以直观上，我们可以减少reduce数量，达到减少文件数量的目的。

从Map到Reduce需要一个Shuffle过程，所以我们将小文件合并理解为通过一个Shuffle，合并小文件成一个大文件。基于这样的思想，我们的策略可以分为两类：一类是原来的计算已经有Shuffle了，那么我们可以认为控制输出文件的数量；二类是强制触发Shuffle，进行小文件合并。

1-设置参数 (一般用于Hive)

2-distribute by rand()

往动态分区插入数据时，在已经写好的SQL末尾加上distribute by rand()

该算子只是起到打散的效果，但是我们还要设置文件的大小，以免打散后仍然有小文件。

表示每个reduce的大小，Hive可以数据总量，得到reduce个数，假设hive认为会有10个reduce,那么，这里rand()则会为 x % 10

3-group by

我们知道，group by算子会触发Shuffle，因此只要我们设置好Shuffle时的文件个数就好，在Spark SQL中，我们可以设置partition个数，因为一个partition会对应一个文件。

上述的 *** 作，会触发shuffle，因此我们再设置partition个数。

则表示，shuffle后，只会产生10个partition

4-repartition()

5-coalesce()

需要注意的是，4和5都是spark 24以及以后才会支持的。

最近一个从Hbase捞取数据进行统计值的Spark Job 计算经常报警，执行时间大大超过以前的平均执行时间。

于是打开一个application

发现这个application 有4个job，如上图所示，但是执行时间有点长。

于是我点开正在执行的job

然后点开一个执行比较的stage

在页面点开event TimeLine 看到如下

内存和cpu 看起来都ok，那是不是磁盘满了？

再看

看起来磁盘容量也没问题啊。

没啥办法，于是我又去我们ganggalia上去看读写等指标

读写次数和其他机器也没有太大的区别。

是不是读写hbase有问题，于是查看hbase相关的监控，发现数据分布均匀，而且没有什么异常。比如超时的

然后我想看看磁盘的读写速度吧

输入

iostat -x

突然发现上图中的有一个w-wait 也就是写入耗时，都到了300多ms了，然后我又看了一下其他机器的w-wait 发现都是20以下，所以基本断定是这个磁盘的问题了。然后通知运维，让运维换盘。

问题解决。

1、查看spark日志，err日志等看是否有什么异常（常见的网络，连接问题，磁盘空间等异常常见）

2、查看每个stage 数据是否发生切斜,

3、确认持久化级别，是否是全部内存，查看是否出现spillToDisk

4、查看是否有单个节点执行时间比较长

5、登陆有问题的节点，查看load，内存以及网络属性

6、查看磁盘读写情况

以上就是关于spark和hadoop的区别全部的内容，包括:spark和hadoop的区别、Spark 处理小文件、Spark Job执行变慢问题的排查的流程等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！