大数据面试总结

熟练使用kettle数据转换工具

Kettle了解过，因为公司使用的 是oozie,不过这只是数据处理的工具，都可以学习

数据库优化：

1. 索引优化：将经常查询的字段创建索

提高查询速度

1. SQL：表关联时，将数据量少的表放在右边

Where执行的是之下往上的，尽可能把过滤大量数据的条件放在最下面

Where执行速度比having快

尽量减少使用select *

使用>=代替>

用union 、in代替or

Or全表扫描，不用索引-----union命中索引，

尽可能避免三表关联

Union all 与union的区别

Union all 直接连接，得到的是所有值

Union是union all+去重（取唯一值，记录没有重复

 

 

1. 数据库存储引擎

Innodb:支持事物

 

 

Hadoop—mr、hdfs、yarn

数据采集：sqoop、flume

数据源：数据库（使用sqoop）、日志（flume）、网络爬取

数据存储：hdfs 分布式存储

                   Kafka 中间件，

                   MySQL

数据预处理：MapReduce、spark、

对数据加模式（schema）变成表，易于处理、去重、

数据计算：hive

 

优化问题：

Hdfs优化：

1.使用Gzip算法压缩，减少带宽

2.将小文件合并，减少master的内存使用，（元数据）

3.设置机架感知，减少数据节点之间的rpc通信

4.设置短路读，在数据节点的内存上创建一个与客户端共享内存的空间，以空间换时间

 

Yarn调度算法

能力调度：capacity scheduler

 

调度算法：当多个任务在yarn执行的时候，采取什么样的方法来安排各个任务的执行。

常见的调度算法：

FIFO：fan in fan out(先进先出)：按照任务提交的先后顺序，逐个执行。

优点：简单 缺点：不能并行，不能根据任务的大小合理执行。

公平调度：（Fair scheduler）:每个任务安排一段时间去执行

能力调度（基于时间片轮询）：根据每个任务的大小合理分配计算资源。

 

MapReduce数据倾斜：

原因：在mr中当一部分reduce节点上的key值过多，执行的数据就会比其他节点慢，导致整个执行过程慢，解决：key加随机数

Mr的优化，尽可能在map端进行reduce操作（combine），减少与reduce节点的rpc通信

Hive优化：

2.分区：访问的数据按分区，缩小查询范围

3.分桶：对表中的字段取哈希值莫桶数，防止数据倾斜

数据倾斜：

大小表join：使用map join让小表先进内存，在map端完成reduce

Hive自定义函数：

实现upf 重写evaluate方法  打包上传 add jar 将java中的类映射到hive中定义的函数

 

Hbase优化：

1.预分区

2,。创建二级索引，利用协处理器observer

1. rowkey设计：

不要过长：hbase持久化hfile文件是安装keyvalue形式存储的，key=rowkey-列簇-列，极大的影响的hfile的存储效率

Rowkey尽可能与业务逻辑相关（经常作为查询条件）

Rowkey散列：为了region（rowkey）负载均衡，避免写热点（rowkey自增才能造成写热点）

Hash、反向rowkey

分页：pagefilter批量查询

 

Kafka优化

创建多个分区、增大并行度

Kafka在底层摒弃了Java堆缓存机制，采用了操作系统级别的页缓存，同时将随机写操作改为顺序写

通过将topic的消息打散到多个分区并分布保存在不同的broker上实现了消息处理

日志保存策略配置：定时删除磁盘空间中的文件

 

Kafka

快速:单一的Kafka代理可以处理成千上万的客户端，每秒处理数兆字节的读写操作。

可伸缩:在一组机器上对数据进行分区和简化，以支持更大的数据

持久:消息是持久性的，并在集群中进行复制，以防止数据丢失。

设计:它提供了容错保证和持久性
 

Kafka：数据丢失与重复

 

 

Spark优化：

1. kryo 优点：序列化速度快，占用空间小

Rdd序列化缓存（以空间换时间）

更改shuffle并行度：

spark.default.parallelism =cpu cores*2-3

广播变量：Brocast

 

Spark数据倾斜(数据分布不均匀)

数据倾斜发生时的现象：

1. 绝大多数task（任务）执行得都非常快，但个别task执行极慢。
2. OOM(内存溢出)，这种情况比较少见。

数据倾斜发生的原理

数据倾斜的原理很简单：在进行shuffle的时候，必须将各个节点上相同的key拉取到某个节点上的一个task来进行处理，比如按照key进行聚合或join等操作。此时如果某个key对应的数据量特别大，就会发生数据倾斜。比如，大部分key对应的数据是10条，有一个key对应的数据是100万条，那么大部分的task只分配了10条数据，可能1秒就完成了，但是那个100万条数据的task，可能还要经过一两个小时，整个Spark作业的运行进度是由运行时间最长的那个task决定的。木桶原理。

因此出现数据倾斜的时候，Spark作业看起来会运行得非常缓慢，甚至可能因为某个task处理的数据量过大导致内存溢出。

数据倾斜产生在那些地方

首先要看的，就是数据倾斜发生在第几个stage中。

Stage的划分是触发了shuffle操作，才会划分stage。

触发shuffle操作的算子：

distinct、groupByKey、reduceByKey、aggregateByKey、join、cogroup、repartition

数据倾斜解决方法

1.     使用spark通用的优化方案

2.     分两种情况，

一种聚合数据倾斜：

1. 先对key前加n以内的随机前缀，然后计算，计算完成去掉随机前缀，再次合并结果。N一般来说取值在10左右

 

一种是join类型的数据倾斜：

a.     先对左表加随机前缀

b.     对右表扩容n倍

c.      执行join操作

d.     去掉结果中的前缀

 

sparksql可以处理那些数据：

结构化的数据源—json、parquet（默认）、hive表、外部数据库MySQL、已经存在的rdd

可以通过配置设置数据源类型：spark.sql.sources.default

 

数据加载：1,read.load(文件路径)

         Spark.read.format(“json”).load(文件路径)

         Spark.sql(“sql语句”)

 

Hbase扩展集群怎么进行负载均衡

0.92版本以后hbase的负载均衡算法可以通过实现LoadBalancer接口的hbase.master.loadbalancer.class来自定义。

Hbase通过region数据实现简单的负载均衡。

 

Kafka一秒可以处理多少数据

1秒---超过上百万条，内存与CPU不高时，处理十万条数据。

 

GC垃圾回收机制与JVM架构

JVM可以分成：类加载器、运行时加载区、执行引擎

数据区：方法区—静态变量共享区

堆区：对象、实例变量，多线程共享—不安全

栈区：局部变量—安全

GC:收集/删除来引用的对象，system.gc()

Jvm垃圾回收只收集那些new创建的对象，不是new出来的对象可以使用finalize函数清理。

JVM三大性能调优参数:-xms –xmx –xss

 

分布式系统无法同时满足：

1. 一致性、可用性、分区可容错

最终保证一致性：加分布式事物、分布式锁

同一个方法在同一时间只能够在一台机器上一个线程执行。

错误致命，不可捕获。

异常，非致命，程序中可以捕获处理

受检异常：编译器检查异常

运行时异常：不必捕获处理

 

泛型是参数化类型，好处：提高安全性、避免类型转换

 

死锁：在多线程环境中，存在多个共享资源，线程间持有对方想要的资源，而都得不到释放，由此造成程序终止运行。

解决:

1.保证锁（资源顺序）2.使用显示锁（可重入锁）

装饰模式：是对客户端透明的方式扩展对象的功能。

java主要体现在io---read---bufferreader

 

工厂：对象的创建权利交给了工厂。客户端不需要去创建。解耦