【大数据】——大数据知识点汇总(持续更新)

爱被打了一巴掌 2022-03-15 09:36 973阅读 0赞

###  一、前言 ###

知乎上有人对大数据平台总结的很好，地址：[一文读懂大数据平台][Link 1]

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MDQ0OTMwMA_size_16_color_FFFFFF_t_70][]

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MDQ0OTMwMA_size_16_color_FFFFFF_t_70 1][]

### 二、基础 ###

**\#简单概括安装hadoop的步骤**

1).创建 hadoop 帐户。

2).setup.改 IP。

3).安装 java，并修改/etc/profile 文件，配置 java 的环境变量。

4).修改 Host 文件域名。

5).安装 SSH，配置无密钥通信。

6).解压 hadoop。

7).配置 conf 文件下 hadoop-env.sh、core-site.sh、mapre-site.sh、hdfs-site.sh。

8).配置 hadoop 的环境变量。

9).Hadoop namenode -format

10).Start-all.sh

**\#简单概述hadoop中的角色的分配以及功能**

Namenode:负责管理元数据的信息

SecondName:做namenode冷备份，对于namenode的机器当掉后能快速切换到制定的Secondname上

DateNode:主要做储存数据的。

JobTracker:管理任务，并把任务分配到taskTasker

TaskTracker：执行任务的

\#**大数据的五个V是什么？**

**答**：大数据的五个V如下：

*  Volume -Volume表示体积大，即以高速率增长的数据量，即以PB为单位的数据量
 *  Velocity -Velocity是数据增长的速度。社交媒体在数据增长速度方面发挥着重要作用。
 *  Variety -Variety是指不同的数据类型，即各种数据格式，如文本，音频，视频等。
 *  Veracity -Veracity是指可用数据的不确定性。由于大量数据带来不完整性和不一致性，因此产生了准确性。
 *  Value -价值是指将数据转化为价值。通过将访问的大数据转换为价值，企业可以创造收入。

![大数据的5V][5V]

**\#格式化NameNode的命令是什么？**

**答**： $ hdfs namenode -format

**\#你认为用java , streaming , pipe 方式开发map/reduce,各有什么优点**

开发mapReduce只用过java与hive,不过使用java开发mapreduce显得笨拙，效率也慢，基于java慢的原因于是hive，这样就方便了查询与设计。

**\#简单概述hadoop的join的方法**

Hadoop 常用的jion有reduce side join  , map side  join ,  SemiJoin 不过reduce side join 与 map side join 比较常用，不过都是比较耗时的。

**\#hbase宕机了如何处理？**

HBase的RegionServer宕机超过一定时间后，HMaster会将其所管理的region重新分布到其他活动的RegionServer上，由于数据和日志都持久在HDFS中，该操作不会导致数据丢失。所以数据的一致性和安全性是有保障的。但是重新分配的region需要根据日志恢复原RegionServer中的内存MemoryStore表，这会导致宕机的region在这段时间内无法对外提供服务。而一旦重分布，宕机的节点重新启动后就相当于一个新的RegionServer加入集群，为了平衡，需要再次将某些region分布到该server。 因此，Region Server的内存表memstore如何在节点间做到更高的可用，是HBase的一个较大的挑战。

### \#**“jps”命令的用处？** ###

这个命令可以检查Namenode、Datanode、Task Tracker、 Job Tracker是否正常工作。

\#**hdfs写流程**

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MDQ0OTMwMA_size_16_color_FFFFFF_t_70 2][]

流程：

\#**读流程**

1.  client链接namenode存数据
2.  namenode记录一条数据位置信息（元数据），告诉client存哪。
3.  client用hdfs的api将数据块（默认是64M）存储到datanode上。
4.  datanode将数据水平备份。并且备份完将反馈client。
5.  client通知namenode存储块完毕。
6.  namenode将元数据同步到内存中。
7.  另一块循环上面的过程。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MDQ0OTMwMA_size_16_color_FFFFFF_t_70 3][]

流程：

1.  client链接namenode，查看元数据，找到数据的存储位置。
2.  client通过hdfs的api并发读取数据。
3.  关闭连接。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MDQ0OTMwMA_size_16_color_FFFFFF_t_70 4][]

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MDQ0OTMwMA_size_16_color_FFFFFF_t_70 5][]

### \#**Mapreduce和Spark的都是并行计算，那么他们有什么相同和区别** ###

答：两者都是用mr模型来进行并行计算:   
          1) hadoop的一个作业称为job，job里面分为map task和reduce task，每个task都是在自己的进程中运行的，当task结束时，进程也会结束。   
         2) spark用户提交的任务成为application，一个application对应一个sparkcontext，app中存在多个job，每触发一次action操作就会产生一个job。这些job可以并行或串行执行，每个job中有多个stage，stage是shuffle过程中DAGSchaduler通过RDD之间的依赖关系划分job而来的，每个stage里面有多个task，组成taskset有TaskSchaduler分发到各个executor中执行，executor的生命周期是和app一样的，即使没有job运行也是存在的，所以task可以快速启动读取内存进行计算。   
        3) hadoop的job只有map和reduce操作，表达能力比较欠缺而且在mr过程中会重复的读写hdfs，造成大量的io操作，多个job需要自己管理关系。 spark的迭代计算都是在内存中进行的，API中提供了大量的RDD操作如join，groupby等，而且通过DAG图可以实现良好的容错。

### \#**RDD机制？** ###

答：rdd分布式弹性数据集，简单的理解成一种数据结构，是spark框架上的通用货币。 所有算子都是基于rdd来执行的，不同的场景会有不同的rdd实现类，但是都可以进行互相转换。 rdd执行过程中会形成dag图，然后形成lineage保证容错性等。 从物理的角度来看rdd存储的是block和node之间的映射。

### \#**hadoop的shuffle过程** ###

**        视频讲解：**[https://www.bilibili.com/video/av50213534/?p=1][https_www.bilibili.com_video_av50213534_p_1]

1）Map端的shuffle

Map端会处理输入数据并产生中间结果，这个中间结果会写到本地磁盘，而不是HDFS。每个Map的输出会先写到内存缓冲区中，当写入的数据达到设定的阈值时，系统将会启动一个线程将缓冲区的数据写到磁盘，这个过程叫做spill。  
　　在spill写入之前，会先进行二次排序，首先根据数据所属的partition进行排序，然后每个partition中的数据再按key来排序。partition的目是将记录划分到不同的Reducer上去，以期望能够达到负载均衡，以后的Reducer就会根据partition来读取自己对应的数据。接着运行combiner(如果设置了的话)，combiner的本质也是一个Reducer，其目的是对将要写入到磁盘上的文件先进行一次处理，这样，写入到磁盘的数据量就会减少。最后将数据写到本地磁盘产生spill文件(spill文件保存在\{mapred.local.dir\}指定的目录中，Map任务结束后就会被删除)。

最后，每个Map任务可能产生多个spill文件，在每个Map任务完成前，会通过多路归并算法将这些spill文件归并成一个文件。至此，Map的shuffle过程就结束了。

2）Reduce端的shuffle

Reduce端的shuffle主要包括三个阶段，copy、sort(merge)和reduce。  
　　首先要将Map端产生的输出文件拷贝到Reduce端，但每个Reducer如何知道自己应该处理哪些数据呢？因为Map端进行partition的时候，实际上就相当于指定了每个Reducer要处理的数据(partition就对应了Reducer)，所以Reducer在拷贝数据的时候只需拷贝与自己对应的partition中的数据即可。每个Reducer会处理一个或者多个partition，但需要先将自己对应的partition中的数据从每个Map的输出结果中拷贝过来。  
　　接下来就是sort阶段，也成为merge阶段，因为这个阶段的主要工作是执行了归并排序。从Map端拷贝到Reduce端的数据都是有序的，所以很适合归并排序。最终在Reduce端生成一个较大的文件作为Reduce的输入。

最后就是Reduce过程了，在这个过程中产生了最终的输出结果，并将其写到HDFS上。

### \#**fsimage和edit的区别？** ###

大家都知道namenode与secondary namenode 的关系，当他们要进行数据同步时叫做checkpoint时就用到了fsimage与edit，fsimage是保存最新的元数据的信息，当fsimage数据到一定的大小事会去生成一个新的文件来保存元数据的信息，这个新的文件就是edit，edit会回滚最新的数据。

\#**datanode 首次加入 cluster 的时候，如果 log 报告不兼容文件版本，那需要namenode 执行格式化操作，这样处理的原因是？**

1）这样处理是不合理的，因为那么 namenode 格式化操作，是对文件系统进行格式化，namenode 格式化时清空 dfs/name 下空两个目录下的所有文件，之后，会在目录 dfs.name.dir 下创建文件。  
         2）文本不兼容，有可能时 namenode 与 datanode 的 数据里的 namespaceID、clusterID 不一致，找到两个 ID 位置，修改为一样即可解决。

**\#mr的工作原理**

1、当执行mr程序是，会执行一个Job

2、客户端的jobClick会请求namenode的jobTracker要执行任务

3、jobClick会去HDFS端复制作业的资源文件

4、客户端的jobClick会向namenode提交作业,让namenode做准备

5、Namenode的jobTracker会去初始化创建的对象

6、Namenode会获取hdfs的划分的分区

7、Namenode去检查TaskTracker的心跳信息，查看存活的机器

8、当执行的datenode执行任务时Datenode会去HDFS获取作业的资源的文件

9、TaskTracker会去执行代码，并登陆JVM的执行渠道

10、JVM或执行MapTask或者ReduceTask

11、执行终结

--------------------

**\#fsimage和edit的区别？**

大家都知道namenode与secondary namenode 的关系，当他们要进行数据同步时叫做checkpoint时就用到了fsimage与edit，fsimage是保存最新的元数据的信息，当fsimage数据到一定的大小事会去生成一个新的文件来保存元数据的信息，这个新的文件就是edit，edit会回滚最新的数据。

--------------------

**\#谈谈数据倾斜，如何发生的，并给出优化方案**

数据的倾斜主要是两个的数据相差的数量不在一个级别上，在只想任务时就造成了数据的倾斜，可以通过分区的方法减少reduce数据倾斜性能的方法，例如;抽样和范围的分区、自定义分区、数据大小倾斜的自定义侧咯

--------------------

**\#怎样快速的杀死一个job**

1、执行hadoop  job -list  拿到job-id

2、Hadoop job kill hadoop-id

--------------------

**\#简单概述hadoop的join的方法**

Hadoop 常用的jion有reduce side join  , map side  join ,  SemiJoin 不过reduce side join 与 map side join 比较常用，不过都是比较耗时的。

**\#简单概述hadoop的combinet与partition的区别**

combine和partition都是函数，中间的步骤应该只有shuffle！ combine分为map端和reduce端，作用是把同一个key的键值对合并在一起，可以自定义的,partition是分割map每个节点的结果，按照key分别映射给不同的reduce，也是可以自定义的。这里其实可以理解归类。

**\#datanode 首次加入 cluster 的时候，如果 log 报告不兼容文件版本，那需要namenode 执行格式化操作，这样处理的原因是？**

这样处理是不合理的，因为那么 namenode 格式化操作，是对文件系统进行格式化，namenode 格式化时清空 dfs/name 下空两个目录下的所有文件，之后，会在目录 dfs.name.dir 下创建文件。文本不兼容，有可能时 namenode 与 datanode 的 数据里的 namespaceID、clusterID 不一致，找到两个 ID 位置，修改为一样即可解决。

**\#hadoop的shuffer的概念**

Shuffer是一个过程，实在map端到reduce在调reduce数据之前都叫shuffer,主要是分区与排序，也就是内部的缓存分分区以及分发（是reduce来拉数据的）和传输

**\#写出你对zookeeper的理解**

随着大数据的快速发展，多机器的协调工作，避免主要机器单点故障的问题，于是就引入管理机器的一个软件，他就是zookeeper来协助机器正常的运行。Zookeeper有两个角色分别是leader与follower ，其中leader是主节点，其他的是副节点，在安装配置上一定要注意配置奇数个的机器上，便于zookeeper快速切换选举其他的机器。在其他的软件执行任务时在zookeeper注册时会在zookeeper下生成相对应的目录，以便zookeeper去管理机器。

**\# 请简述hadoop怎么样实现二级排序？**

--在MapReduce中本身就会对我们key进行排序，所以我们要对value进行排序，主要思想为将key和部分value拼接成一个组合key（实现WritableComparable接口或者调用 setSortComparatorClass函数），这样reduce获取的结果便是先按key排序，后按value排序的结果，在这个方法中，用户需 要自己实现Paritioner，继承Partitioner<>,以便只按照key进行数据划分。Hadoop显式的支持二次排序，在Configuration类中有个 setGroupingComparatorClass()方法，可用于设置排序group的key值。

**\#谈谈你对MapReduce的优化建议。**

一.mapper调优

mapper调优主要就一个目标：减少输出量。

我们可以通过增加combine阶段以及对输出进行压缩设置进行mapper调优。

1>combine合并：

实现自定义combine要求继承reducer类。比较适合map的输出是数值型的，方便进行统计。

2>压缩设置：

在提交job的时候分别设置启动压缩和指定压缩方式。

二、reducer调优

reducer调优主要是通过参数调优和设置reducer的个数来完成。

reducer个数调优：

要求：一个reducer和多个reducer的执行结果一致，不能因为多个reducer导致执行结果异常。

规则：一般要求在hadoop集群中的执行mr程序，map执行完成100%后，尽量早的看到reducer执行到33%，可以通过命令hadoop job -status job\_id或者web页面来查看。

原因：map的执行process数是通过inputformat返回recordread来定义的；而reducer是有三部分构成的，分别为读取mapper输出数据、合并所有输出数据以及reduce处理，其中第一步要依赖map的执行，所以在数据量比较大的情况下，一个reducer无法满足性能要求的情况下，我们可以通过调高reducer的个数来解决该问题。

优点：充分利用集群的优势。

缺点：有些mr程序没法利用多reducer的优点，比如获取top n的mr程序。

### Hive生产环境中为什么建议使用外部表？ ###

1、因为外部表不会加载数据到hive，减少数据传输、数据还能共享。  
2、hive不会修改数据，所以无需担心数据的损坏  
3、删除表时，只删除表结构、不删除数据。

### hive内部表和外部表的区别 ###

Hive 向内部表导入数据时，会将数据移动到数据仓库指向的路径；若是外部表，数据的具体存放目录由用户建表时指定在删除表的时候，内部表的元数据和数据会被一起删除，而外部表只删除元数据，不删除数据。这样外部表相对来说更加安全些，数据组织也更加灵活，方便共享源数据。

### \#hive 跟hbase的区别 ###

共同点都是用hadoop作为底层存储

区别：hive是为了减少mrjobs编写工作的批处理系统，处理速度慢。hive本身不存储数据和计算数据，依赖于hadoop，纯逻辑表  
hbase是为了hadoop对实时操作的缺陷的项目，处理速度快，是物理表，提供一个超大的内存hash表，方便查询操作  
**如果全表扫描用 hive+hadoop 如果用索引查询与hbase+hadoop**

### hive有哪些保存元数据的方式，各有什么特点 ###

1.内存数据库 derby，安装小不稳定  
2.mysql数据库，持久化好，查看方便

### \#hive的内表和外表 ###

内部表：未被external修饰，由hive自身管理，删除后会直接删除元数据及存储数据，对表的修改会将修改直接同步给元数据的内部表  
外表：被ex修饰，由hdfs管理，表存储有自己决定，删表仅会删除元数据，hdfs文件并不会被删除

###  \#Hive语言实现word count ###

<table> 
 <tbody> 
  <tr> 
   <td style="vertical-align:top;"> <p><strong>解答：</strong></p> <p>1.建表</p> <p>2.分组（group by）统计wordcount</p> <p>select word,count(1) from table1 group by word;</p> </td> 
  </tr> 
 </tbody> 
</table>

### \#有两个文本文件，文件中的数据按行存放，请编写MapReduce程序，找到两个文件中彼此不相同的行（写出思路即可） ###

解答：

写个mapreduce链  用依赖关系，一共三个mapreduce，第一个处理第一个文件，第二个处理第二个文件，第三个处理前两个的输出结果，第一个mapreduce将文件去重，第二个mapreduce也将文件去重，第三个做wordcount，wordcount为1的结果就是不同的。

### MapReduce的map数量和reduce数量怎么确定，怎么配置 ###

map的数量有数据块决定，reduce数量由配置文件配置

### Hbase的rowKey怎么创建比较好？列簇怎么创建比较好？ ###

rowKey最好要创建有规则的rowKey，即最好是有序的。经常需要批量读取的数据应该让他们的rowkey连续；将经常需要作为条件查询的关键词组织到rowkey中；

列族的创建：按照业务特点，把数据归类，不同类别的放在不同列族

### \#shuffle阶段你怎么理解 ###

shuffle过程包括在Map和Reduce两端中。  
1、在Map端的shuffle过程是对Map的结果进行分区（partition）、排序（sort）和分割（spill），然后将属于同一个划分的输出合并在一起（merge）并写在硬盘上，同时按照不同的划分将结果发送给对应的Reduce（Map输出的划分与Reduce的对应关系由JobTracker确定）。  
2、Reduce端又会将各个Map送来的属于同一个划分的输出进行合并（merge），然后对merge的结果进行排序，最后交给Reduce处理。通俗的讲，就是对Map输出结果先进行分区（partition），如“aaa”经过Partitioner后返回0，也就是这对值应当交由第一个reducer来处理。接下来，需要将数据写入内存缓冲区中，缓冲区的作用是批量收集map结果，减少磁盘IO的影响。我们的key/value对以及Partition的结果都会被写入缓冲区。当然写入之前，key与value值都会被序列化成字节数组。这个内存缓冲区是有大小限制的，默认是100MB。当map task的输出结果。很多时，需要在一定条件下将缓冲区中的数据临时写入磁盘，然后重新利用这块缓冲区。这个从内存往磁盘写数据的过程被称为Spill。Spill可以认为是一个包括Sort和Combiner（Combiner是可选的，用户如果定义就有）的过程。先进行sort可以把缓冲区中一段范围key的数据排在一起，（如果数据多的时候，多次刷新往内存缓冲区中写入的数据可能会有属于相同范围的key，也就是说，多个spill文件中可能会有统一范围的key，这就是需要下面Map端merge的原因），这里有点绕，具体的介绍可以看下面的详细过程，执行过sort之后，如果用户定义了combiner就会执combine，然后执行merge操作，接着就是Reduce端。

### \#Spark与Hadoop的shuffle的异同 ###

[https://blog.csdn.net/WYpersist/article/details/79982627][https_blog.csdn.net_WYpersist_article_details_79982627]

### \#请列出你所知道的hadoop调度器，并简要说明其工作方法？ ###

比较流行的三种调度器有：默认调度器FIFO，计算能力调度器CapacityScheduler，公平调度器Fair Scheduler

1、默认调度器FIFO：hadoop中默认的调度器，采用先进先出的原则

2、计算能力调度器CapacityScheduler：选择占用资源小，优先级高的先执行

3、公平调度器FairScheduler：同一队列中的作业公平共享队列中所有资源

### \#Hive中存放是什么？ ###

表。存的是和hdfs的映射关系，hive是逻辑上的数据仓库，实际操作的都是hdfs上的文件，HQL就是用sql语法来写的mr程序。

### \#Hive与关系型数据库的关系？ ###

没有关系，hive是数据仓库，不能和数据库一样进行实时的CURD操作。是一次写入多次读取的操作，可以看成是ETL工具。

### \#Sqoop工作原理是什么？ ###

hadoop生态圈上的数据传输工具。可以将关系型数据库的数据导入非结构化的hdfs、hive或者bbase中，也可以将hdfs中的数据导出到关系型数据库或者文本文件中。使用的是mr程序来执行任务，使用jdbc和关系型数据库进行交互。  
import原理：通过指定的分隔符进行数据切分，将分片传入各个map中，在map任务中在每行数据进行写入处理没有reduce。  
export原理：根据要操作的表名生成一个java类，并读取其元数据信息和分隔符对非结构化的数据进行匹配，多个map作业同时执行写入关系型数据库

### \#Hadoop性能调优？ ###

调优可以通过系统配置、程序编写和作业调度算法来进行。  
1、hdfs的block.size可以调到128/256（网络很好的情况下，默认为64）  
2、调优的大头：mapred.map.tasks、mapred.reduce.tasks设置mr任务数（默认都是1）  
     mapred.tasktracker.map.tasks.maximum每台机器上的最大map任务数  
     mapred.tasktracker.reduce.tasks.maximum每台机器上的最大reduce任务数  
     mapred.reduce.slowstart.completed.maps配置reduce任务在map任务完成到百分之几的时候开始进入  
这个几个参数要看实际节点的情况进行配置，reduce任务是在33%的时候完成copy，要在这之前完成map任务，（map可以提前完成）  
     mapred.compress.map.output,mapred.output.compress配置压缩项，消耗cpu提升网络和磁盘io  
3、合理利用combiner  
4、注意重用writable对象

### \#Kafka速度为何快 ###

Kafka速度的秘诀在于，它把所有的消息都变成一个批量的文件，并且进行合理的批量压缩，减少网络IO损耗，通过mmap提高I/O速度，写入数据的时候由于单个Partion是末尾添加所以速度最优；读取数据的时候配合sendfile直接暴力输出。

参考：[https://blog.csdn.net/eson\_15/article/details/90746239][https_blog.csdn.net_eson_15_article_details_90746239]

### Redis 优缺点 ###

优点：   
1 读写性能优异   
2 支持数据持久化，支持AOF和RDB两种持久化方式   
3 支持主从复制，主机会自动将数据同步到从机，可以进行读写分离。   
4 数据结构丰富：除了支持string类型的value外还支持string、hash、set、sortedset、list等数据结构。

缺点：   
1 Redis不具备自动容错和恢复功能，主机从机的宕机都会导致前端部分读写请求失败，需要等待机器重启或者手动切换前端的IP才能恢复。   
2 主机宕机，宕机前有部分数据未能及时同步到从机，切换IP后还会引入数据不一致的问题，降低了系统的可用性。   
3 redis的主从复制采用全量复制，复制过程中主机会fork出一个子进程对内存做一份快照，并将子进程的内存快照保存为文件发送给从机，这一过程需要确保主机有足够多的空余内存。若快照文件较大，对集群的服务能力会产生较大的影响，而且复制过程是在从机新加入集群或者从机和主机网络断开重连时都会进行，也就是网络波动都会造成主机和从机间的一次全量的数据复制，这对实际的系统运营造成了不小的麻烦。   
4 Redis较难支持在线扩容，在集群容量达到上限时在线扩容会变得很复杂。为避免这一问题，运维人员在系统上线时必须确保有足够的空间，这对资源造成了很大的浪费。

### \#kafka\\redis\\rabittMQ的区别 ###

### 1.1 redis ###

redis的特征就是快，由于其数据是存储在内存中的，处理速度相对另外两者快了不少。通过使用redis可以实现一个简单具有实时通信功能的聊天室。

### 2.2 kafka ###

kafka的设计初衷是一个日志系统，其队列中的数据能够持久化一段时间。因此后来的consumer能够通过自定义offset来实现获取之前的消息，而redis就不具备这样的能力。

### 2.3 rabittMQ ###

rabittMQ设计的一个核心概念为Exchange，Exchange存在的意义是producer不会直接向queue发送消息，而是将消息先发给exchanger，而exchanger选择将数据转发给queue。rabittMQ的exchanger有4种转发策略，包括direct、topic、headers、fanout。因此rabittMQ在消息的路由方面相比redis和kafka更加灵活。

redis 消息推送（基于分布式 pub/sub）多用于实时性较高的消息推送，并不保证可靠。  
其他的mq和kafka保证可靠但有一些延迟（非实时系统没有保证延迟）。redis-pub/sub断电就清空，而使用redis-list作为消息推送虽然有持久化，但是又太弱智，也并非完全可靠不会丢。

另外一点，redis 发布订阅除了表示不同的 topic 外，并不支持分组，比如kafka中发布一个东西，多个订阅者可以分组，同一个组里只有一个订阅者会收到该消息，这样可以用作负载均衡。

比如，kafka 中发布：topic = "发布帖子" data="文章1" 这个消息，后面有一百台服务器每台服务器都是一个订阅者，都订阅了这个 topic，但是他们可能分为三组，A组50台，用来真的做发布文章，A组50台里所有 subscriber 都订阅了这个topic。

由于在同一组，这条消息 （topic="发布帖子", data="文章1"）只会被A组里面一台当前空闲的机器收到。而B组25台服务器用于统计，C组25台服务器用于存档备份，每组只有一台会收到。

用不同的组来决定每条消息要抄送出多少分去，用同组内哪些订阅者忙，哪些订阅者空闲来决定消息会被分到哪台服务器去处理，生产者消费者模型嘛。

redis完全没有这类机制，这两点是最大的区别。。。。。

### \#hadoop数据倾斜及解决办法 ###

1、增加jvm内存,这适用于第一种情况(唯一值非常少，极少数值有非常多的记录值(唯一值少于几千)),这种情况下,往往只能通过硬件的手段来进行调优,增加jvm内存可以显著的提高运行效率。  
2、增加reduce的个数,这适用于第二种情况(唯一值比较多，这个字段的某些值有远远多于其他值的记录数，但是它的占比也小于百分之一或千分之一),我们知道,这种情况下,最容易造成的结果就是大量相同key被partition到一个分区,从而一个reduce执行了大量的工作,而如果我们增加了reduce的个数,这种情况相对来说会减轻很多,毕竟计算的节点多了,就算工作量还是不均匀的,那也要小很多。  
3、自定义分区,这需要用户自己继承partition类,指定分区策略,这种方式效果比较显著。  
4、重新设计key,有一种方案是在map阶段时给key加上一个随机数,有了随机数的key就不会被大量的分配到同一节点(小几率),待到reduce后再把随机数去掉即可。  
5、使用combinner合并,combinner是在map阶段,reduce之前的一个中间阶段,在这个阶段可以选择性的把大量的相同key数据先进行一个合并,可以看做是local reduce,然后再交给reduce来处理,这样做的好处很多,即减轻了map端向reduce端发送的数据量（减轻了网络带宽）,也减轻了map端和reduce端中间的shuffle阶段的数据拉取数量(本地化磁盘IO速率),推荐使用这种方法。

### Hue ###

Hue是一个开源的Apache Hadoop UI系统,通过使用Hue我们可以在浏览器端的Web控制台上与Hadoop集群进行交互来分析处理数据，例如操作HDFS上的数据，运行MapReduce Job等等。

(1) 基于文件浏览器（File Browser）访问HDFS

(2) 基于Hive编辑器来开发和运行Hive查询

(3) 支持基于Impala的应用进行交互式查询

(4) 支持Spark编辑器和仪表板（Dashboard）

(5) 支持Oozie编辑器，可以通过仪表板提交和监控Workflow、Coordinator和Bundle

(6) 支持HBase浏览器，能够可视化数据、查询数据、修改HBase表

(7) 支持Metastore浏览器，可以访问Hive的元数据，以及HCatalog

(8) 支持Job浏览器，能够访问MapReduce Job（MR1/MR2-YARN）

(9) 支持Job设计器，能够创建MapReduce/Streaming/Java Job

(10) 支持Sqoop 2编辑器和仪表板（Dashboard）

(11) 支持ZooKeeper浏览器和编辑器

###    Ooize ###

在Hadoop中执行的任务有时候需要把多个Map/Reduce作业连接到一起，这样才能够达到目的。\[1\]在Hadoop生态圈中，有一种相对比较新的组件叫做Oozie\[2\]，它让我们可以把多个Map/Reduce作业组合到一个逻辑工作单元中，从而完成更大型的任务。Oozie是一种Java Web应用程序，它运行在Java servlet容器——即Tomcat——中，并使用数据库来存储以下内容：

1）工作流定义。

2）当前运行的工作流实例，包括实例的状态和变量。

oozie是基于hadoop的调度器，以xml的形式写调度流程，可以调度mr，pig，hive，shell，jar等等。

### \#flume 和kafka ###

先说flume：  
日志采集。线上数据一般主要是落地文件或者通过socket传输给另外一个系统。这种情况下，你很难推动线上应用或服务去修改接口，直接向kafka里写数据。这时候你可能就需要flume这样的系统帮你去做传输。

Kafka：  
我个人觉得kafka更应该定位为中间件系统。LinkedIn开发这个东西目的也是这个初衷。可以理解为一个cache系统。你甚至可以把它理解为一个广义意义的数据库，里面可以存放一定时间的数据。kafka设计使用了硬盘append方式，获得了非常好的效果。我觉得这是kafka最大的亮点。不同系统之间融合往往数据生产/消费速率不同，这时候你可以在这些系统之间加上kafka。例如线上数据需要入HDFS，线上数据生产快且具有突发性，如果直接上HDFS（kafka-consumer）可能会使得高峰时间hdfs数据写失败，这种情况你可以把数据先写到kafka，然后从kafka导入到hdfs上。印象中LinkedIn公司有这么用。

业界比较典型的一中用法是：  
线上数据 -> flume -> kafka -> hdfs -> MR离线计算 或者：  
线上数据 -> flume -> kafka -> storm

**\#设计题**

采集nginx产生的日志，日志的格式为user  ip   time  url   htmlId  每天产生的文件的数据量上亿条，请设计方案把数据保存到HDFS上，并提供一下实时查询的功能（响应时间小于3s）

A、某个用户某天访问某个URL的次数

B、某个URL某天被访问的总次数

实时思路是：使用Logstash + Kafka + Spark-streaming + Redis + 报表展示平台

离线的思路是：Logstash + Kafka + Elasticsearch +  Spark-streaming + 关系型数据库

A、B、数据在进入到Spark-streaming 中进行过滤，把符合要求的数据保存到Redis中

### \#[Zookeeper实现Master选举（哨兵机制）][Zookeeper_Master] ###

### \#[Zookeeper原理][Zookeeper] ###

### \#MapReduce的区别与联系 ###

首先大数据涉及两个方面：分布式存储系统和分布式计算框架。前者的理论基础是GFS。后者的理论基础为MapReduce。MapReduce框架有两个步骤（MapReduce 框架其实包含5 个步骤：Map、Sort、Combine、Shuffle 以及Reduce。这5 个步骤中最重要的就是Map 和Reduce。这也是和Spark 最相关的两步，因此这里只讨论这两个步骤）：一个是 Map，另一个是 Reduce。Map 步骤是在不同机器上独立且同步运行的，它的主要目的是将数据转换为 key-value 的形式；而 Reduce 步骤是做聚合运算，它也是在不同机器上独立且同步运行的。Map 和 Reduce 中间夹杂着一步数据移动，也就是 shuffle，这步操作会涉及数量巨大的网络传输（network I/O），需要耗费大量的时间。 由于 MapReduce 的框架限制，一个 MapReduce 任务只能包含一次 Map 和一次 Reduce，计算完成之后，MapReduce 会将运算结果写回到磁盘中（更准确地说是分布式存储系统）供下次计算使用。如果所做的运算涉及大量循环，比如估计模型参数的梯度下降或随机梯度下降算法就需要多次循环使用训练数据，那么整个计算过程会不断重复地往磁盘里读写中间结果。这样的读写数据会引起大量的网络传输以及磁盘读写，极其耗时，而且它们都是没什么实际价值的废操作。因为上一次循环的结果会立马被下一次使用，完全没必要将其写入磁盘。整个算法的瓶颈是不必要的数据读写，而Spark 主要改进的就是这一点。具体地，Spark 延续了MapReduce 的设计思路：对数据的计算也分为Map 和Reduce 两类。但不同的是，一个Spark 任务并不止包含一个Map 和一个Reduce，而是由一系列的Map、Reduce构成。这样，计算的中间结果可以高效地转给下一个计算步骤，提高算法性能。虽然Spark 的改进看似很小，但实验结果显示，它的算法性能相比MapReduce 提高了10～100 倍。另：在MapReduce 框架下，数据的格式都是key-value 形式，其中key 有两个作用：一方面它被用作统计的维度，类似于SQL 语句里面的group by 字段，比如正文例子里的字符；另一方面它又被用作数据的“指南针”决定数据将被发送到哪台机器上。而后者是分布式计算框架的核心。在某些计算场景下，计算本身不需要key 值，或者说不需要Map 这一步，比如对一个数字数组求和。这种情况下，系统会自动地生成一个Map 用于将数据转换为key-value 形式，这时key 值就只被用作数据的“指南针”。

### \#Kafka 可以脱离 ZooKeeper 单独使用吗？为什么？ ###

不可以，kafka必须要依赖一个zookeeper集群才能运行。kafka系群里面各个broker都是通过zookeeper来同步topic列表以及其它broker列表的，一旦连不上zookeeper，kafka也就无法工作。

### \#Kafka 有几种数据保留的策略？ ###

1）N天前的删除。  
  2）保留最近的多少Size数据。

**\#Kafka 同时设置了 7 天和 10G 清除数据，到第五天的时候消息达到了 10G，这个时候 Kafka 将如何处理？**

Kafka Broker默认的消息保留策略是：要么保留一定时间，要么保留到消息达到一定大小的字节数    
  当消息达到设置的条件上限时，旧消息就会过期并被删除，所以在任何时刻，可用消息的总量都不会超过配置参数所指定的大小。

topic可以配置自己的保留策略，可以将消息保留到不再使用他们为止。因为在一个大文件里查找和删除消息是很费时的事，也容易出错，所以，分区被划分为若干个片段。默认情况下，每个片段包含1G或者一周的数据，以较小的那个为准。在broker往leader分区写入消息时，如果达到片段上限，就关闭当前文件，并打开一个新文件。当前正在写入数据的片段叫活跃片段。当所有片段都被写满时，会清除下一个分区片段的数据，如果配置的是7个片段，每天打开一个新片段，就会删除一个最老的片段，循环使用所有片段。

### \#hbase的rowkey怎么创建好？列族怎么创建比较好？ ###

hbase存储时，数据按照Row key的字典序(byte order)排序存储。设计key时，要充分排序存储这个特性，将经常一起读取的行存储放到一起。(位置相关性)

一个列族在数据底层是一个文件，所以将经常一起查询的列放到一个列族中，列族尽量少，减少文件的寻址时间。

### \#Impala ###

Impala是Cloudera公司主导开发的新型查询系统，它提供SQL语义，能查询存储在Hadoop的HDFS和HBase中的PB级大数据。已有的Hive系统虽然也提供了SQL语义，但由于Hive底层执行使用的是MapReduce引擎，仍然是一个批处理过程，难以满足查询的交互性。相比之下，Impala的最大特点也是最大卖点就是它的快速。

![aHR0cHM6Ly91cGxvYWQtaW1hZ2VzLmppYW5zaHUuaW8vdXBsb2FkX2ltYWdlcy8xNDc2NjkyMS0yZWE4ZDQwZjQwNWUwNTExLnBuZz9pbWFnZU1vZ3IyL2F1dG8tb3JpZW50L3N0cmlwJTdDaW1hZ2VWaWV3Mi8yL3cvODU5L2Zvcm1hdC93ZWJw][]

优点：

1.  Impala不需要把中间结果写入磁盘，省掉了大量的I/O开销。
2.  省掉了MapReduce作业启动的开销。MapReduce启动task的速度很慢（默认每个心跳间隔是3秒钟），Impala直接通过相应的服务进程来进行作业调度，速度快了很多。
3.  Impala完全抛弃了MapReduce这个不太适合做SQL查询的范式，而是像Dremel一样借鉴了MPP并行数据库的思想另起炉灶，因此可做更多的查询优化，从而省掉不必要的shuffle、sort等开销。
4.  通过使用LLVM来统一编译运行时代码，避免了为支持通用编译而带来的不必要开销。
5.  用C++实现，做了很多有针对性的硬件优化，例如使用SSE指令。
6.  使用了支持Data locality的I/O调度机制，尽可能地将数据和计算分配在同一台机器上进行，减少了网络开销。

参考文章：[https://www.jianshu.com/p/257ff24db397][https_www.jianshu.com_p_257ff24db397]

### 三、实例分析 ###

**1、海量日志数据，提取出某日访问百度次数最多的那个IP**。

**      解决方案：**首先是将这一天，并且是访问百度的日志中的IP取出来，逐个写入到一个大文件中。注意到IP是**32位**的，最多有个2^32个IP。同样可以采用**映射**的方法，比如模1000，把整个大文件映射为1000个小文件，再找出每个小文中出现频率最大的IP(可以采用hash\_map进行频率统计，然后再找出频率最大的几个)及相应的频率。然后再在这1000个最大的IP中，找出那个频率最大的IP，即为所求。

**2、有一个1G大小的一个文件****，里面每一行是一个词，词的大小不超过16字节，内存限制大小是1M。返回频数最高的100个词**。

**      解决方案：**顺序读文件中，对于每个词x，取hash(x)%5000，然后按照该值存到5000个小文件(记为x0,x1,...x4999)中。这样每个文件大概是200k左右。如果其中的有的文件超过了1M大小，还可以按照类似的方法继续往下分，直到分解得到的小文件的大小都不超过1M。 对每个小文件，统计每个文件中出现的词以及相应的频率(可以采用trie树/hash\_map等)，并取出出现频率最大的100个词(可以用含100个结点的最小堆)，并把100个词及相应的频率存入文件，这样又得到了5000个文件。下一步就是把这5000个文件进行归并(类似与归并排序)的过程了。

**3、有10个文件，每个文件1G，每个文件的每一行存放的都是用户的query，每个文件的query都可能重复。要求你按照query的频度排序。**

**      方案1：** 顺序读取10个文件，按照hash(query)%10的结果将query写入到另外10个文件(记为)中。这样新生成的文件每个的大小大约也1G(假设hash函数是随机的)。 找一台内存在2G左右的机器，依次对用hash\_map(query, query\_count)来统计每个query出现的次数。利用快速/堆/归并排序按照出现次数进行排序。将排序好的query和对应的query\_cout输出到文件中。这样得到了10个排好序的文件(记为)。

对这10个文件进行归并排序(内排序与外排序相结合)。

**      方案2：** 一般query的总量是有限的，只是重复的次数比较多而已，可能对于所有的query，一次性就可以加入到内存了。这样，我们就可以采用trie树/hash\_map等直接来统计每个query出现的次数，然后按出现次数做快速/堆/归并排序就可以了。

**       方案3：** 与方案1类似，但在做完hash，分成多个文件后，可以交给多个文件来处理，采用分布式的架构来处理(比如MapReduce)，最后再进行合并。

**4、 给定a、b两个文件，各存放50亿个url，每个url各占64字节，内存限制是4G，让你找出a、b文件共同的url。**

**       方案1：**可以估计每个文件安的大小为5G×64=320G，远远大于内存限制的4G。所以不可能将其完全加载到内存中处理。考虑采取[分而治之][Link 2]的方法。通读文件a，对每个url求取hash(url)%1000，然后根据所取得的值将url分别存储到1000个小文件(记为a0,a1,...,a999)中。这样每个小文件的大约为300M。通读文件b，采取和a相同的方式将url分别存储到1000小文件(记为b0,b1,...,b999)。这样处理后，所有可能相同的url都在对应的小文件(a0vsb0,a1vsb1,...,a999vsb999)中，不对应的小文件不可能有相同的url。然后我们只要求出1000对小文件中相同的url即可。求每对小文件中相同的url时，可以把其中一个小文件的url存储到hash\_set中。然后遍历另一个小文件的每个url，看其是否在刚才构建的hash\_set中，如果是，那么就是共同的url，存到文件里面就可以了。

**       方案2：**如果允许有一定的错误率，可以使用Bloom filter，4G内存大概可以表示340亿bit。将其中一个文件中的url使用Bloom filter映射为这340亿bit，然后挨个读取另外一个文件的url，检查是否与Bloom filter，如果是，那么该url应该是共同的url(注意会有一定的错误率)。

**5、腾讯面试题：给40亿个不重复的unsigned int的整数，没排过序的，然后再给一个数，如何快速判断这个数是否在那40亿个数当中?**

**       方案1：**申请512M的内存，一个bit位代表一个unsigned int值。读入40亿个数，设置相应的bit位，读入要查询的数，查看相应bit位是否为1，为1表示存在，为0表示不存在。

**方案2：**因为2^32为40亿多，所以给定一个数可能在，也可能不在其中;这里我们把40亿个数中的每一个用32位的二进制来表示假设这40亿个数开始放在一个文件中。然后将这40亿个数分成两类: 1.最高位为0 2.最高位为1 并将这两类分别写入到两个文件中，其中一个文件中数的个数<=20亿，而另一个>=20亿(这相当于折半了);与要查找的数的最高位比较并接着进入相应的文件再查找再然后把这个文件为又分成两类: 1.次最高位为0 2.次最高位为1，并将这两类分别写入到两个文件中，其中一个文件中数的个数<=10亿，而另一个>=10亿(这相当于折半了); 与要查找的数的次最高位比较并接着进入相应的文件再查找。 ....... [以此类推][Link 3]，就可以找到了,而且时间复杂度为O(logn)，方案2完。

**        附：**这里，再简单介绍下，位图方法： 使用位图法判断整形数组是否存在重复 判断集合中存在重复是常见编程任务之一，当集合中数据量比较大时我们通常希望少进行几次扫描，这时双重循环法就不可取了。位图法比较适合于这种情况，它的做法是按照集合中最大元素max创建一个长度为max+1的新数组，然后再次扫描原数组，遇到几就给新数组的第几位置上1，如遇到5就给新数组的第六个元素置1，这样下次再遇到5想置位时发现新数组的第六个元素已经是1了，这说明这次的数据肯定和以前的数据存在着重复。这种给新数组初始化时置零其后置一的做法类似于位图的处理方法故称位图法。它的运算次数最坏的情况为2N。如果已知数组的最大值即能事先给新数组定长的话效率还能提高一倍。

**6、如何解决系统高并发问题？**

第一步：系统集群化部署，添加负载均衡层，将请求均匀打到系统层，扛住初步的并发压力。

第二步：并发量继续增长时，我们就需要focus在数据库层面：分库分表、读写分离。

分库分表详解： [https://www.cnblogs.com/butterfly100/p/9034281.html][https_www.cnblogs.com_butterfly100_p_9034281.html]

第三步：引入缓存集群，用缓存集群抗住大量的读请求。

第四步：引入消息中间件技术，也就是MQ集群，他是非常好的做写请求异步化处理，实现削峰填谷的效果。

参考文章：[https://blog.csdn.net/gupao123456/article/details/86594406][https_blog.csdn.net_gupao123456_article_details_86594406]

**7、负载均衡在分布式架构中是怎么玩起来的？**

参考文章： [https://blog.csdn.net/gupao123456/article/details/83386428][https_blog.csdn.net_gupao123456_article_details_83386428]

[Link 1]: https://zhuanlan.zhihu.com/p/26545566
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MDQ0OTMwMA_size_16_color_FFFFFF_t_70]: /images/20220315/add98a883ec74f7dbed07195ac317fc1.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MDQ0OTMwMA_size_16_color_FFFFFF_t_70 1]: /images/20220315/5ff4443d2b8b412b920580866b3cad37.png
[5V]: /images/20220315/18f1196e25dc427e9184f6e92a57dc26.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MDQ0OTMwMA_size_16_color_FFFFFF_t_70 2]: /images/20220315/1411062b85604f838b82db0e0f636666.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MDQ0OTMwMA_size_16_color_FFFFFF_t_70 3]: /images/20220315/d543433c72f644409b7355a21f6dd170.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MDQ0OTMwMA_size_16_color_FFFFFF_t_70 4]: /images/20220315/1a44432304074c97be4b23a0b710c61b.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MDQ0OTMwMA_size_16_color_FFFFFF_t_70 5]: /images/20220315/b78ff6704755451594be876918f78d4d.png
[https_www.bilibili.com_video_av50213534_p_1]: https://www.bilibili.com/video/av50213534/?p=1
[https_blog.csdn.net_WYpersist_article_details_79982627]: https://blog.csdn.net/WYpersist/article/details/79982627
[https_blog.csdn.net_eson_15_article_details_90746239]: https://blog.csdn.net/eson_15/article/details/90746239
[Zookeeper_Master]: https://www.cnblogs.com/toov5/p/9905508.html
[Zookeeper]: https://blog.csdn.net/wzk646795873/article/details/79706627
[aHR0cHM6Ly91cGxvYWQtaW1hZ2VzLmppYW5zaHUuaW8vdXBsb2FkX2ltYWdlcy8xNDc2NjkyMS0yZWE4ZDQwZjQwNWUwNTExLnBuZz9pbWFnZU1vZ3IyL2F1dG8tb3JpZW50L3N0cmlwJTdDaW1hZ2VWaWV3Mi8yL3cvODU5L2Zvcm1hdC93ZWJw]: /images/20220315/151ed777d5894747aeeeb0cfe01104c8.png
[https_www.jianshu.com_p_257ff24db397]: https://www.jianshu.com/p/257ff24db397
[Link 2]: https://www.baidu.com/s?wd=%E5%88%86%E8%80%8C%E6%B2%BB%E4%B9%8B&tn=24004469_oem_dg&rsv_dl=gh_pl_sl_csd
[Link 3]: https://www.baidu.com/s?wd=%E4%BB%A5%E6%AD%A4%E7%B1%BB%E6%8E%A8&tn=24004469_oem_dg&rsv_dl=gh_pl_sl_csd
[https_www.cnblogs.com_butterfly100_p_9034281.html]: https://www.cnblogs.com/butterfly100/p/9034281.html
[https_blog.csdn.net_gupao123456_article_details_86594406]: https://blog.csdn.net/gupao123456/article/details/86594406
[https_blog.csdn.net_gupao123456_article_details_83386428]: https://blog.csdn.net/gupao123456/article/details/83386428