大数据数据倾斜

1. 大数据数仓建设性能优化方案

大数据数仓的性能优化主要围绕以下四个方面：

在数据仓库建设的过程中，我们不可避免的要执行数据任务，那么这些任务如何进行配置才会是最优的？如果任务调度配置存在问题，将会导致出现瓶颈任务，或者无法及时提供业务所需的数据，这时我们就需要首先从调度则中段方面来考虑，是不是有些任务的调度时间设置不合理？或者是不是有的任务的优先级设置不合理？

对于数仓的建模而言，其实可以分为3NF建模和维度建模，推荐使用维度建模方式，可以按照星型模型或者雪花模型架构的方式去建模。3NF建模方式或者实体建模方式的应用性会差一点，在很多时候其性能也会差一点，但3NF会避免数据的冗余，其扩展性会好一些。而维度建模会有一定的数据冗余，并且冗余程度会很高，但是对于上层使用者而言，其易用性要好很多，并且其查询的性能也会好很多，虽然牺牲了一定的可扩展性，但是仍然在可接受的范围之内。之所以在大数据的框架下推荐使用维度建模，是因为建模产生的数据冗余对于大数据离线数仓来说，存储的成本并不高，因为其都属于SATA盘的存储，这样的存储成本是很低的。
总之，在大数据框架下推荐大家使用维度建模，使用星型模型或者雪花模型建模的方式，这样无论对于后续的运维还是后续的数据使用而言，都是比较便利的，并且性能会好一些。星型模型其实就是中间一个事实表，周边围绕着一堆维度表，其结构会简单一些，使用比较方便，性能也比较好；对于雪花模型而言，维度表可能还会继续关联其他的维度表，这种方式就是雪花模型，它会略微比星型模型复杂一些。其实星型模型也可以理解为较为简单的雪花模型。这里推荐大家使用星型模型，当然如果业务非常复杂，必须要使用雪花型也可以使用。这是因为星型模型虽然有数据冗余，但是其结构比较简单，容易理解，而且使用起来只需要A传给B就可以了，不需要再关联一个C。
除了上述两个较大的关键点之外，还有一些需要注意的小点，比如中间表的使用。我们一般将数仓分为三层，第一层做缓冲，第二层做整合，第三层做应用。但是并不是严格的只能分为三层，中间可能会有一些中间表，用于存储中间计算的结果，如果能够利用好中间表则会增强数仓的易用性和整体的性能。中间表的使用主要在数仓的第二层里面，因为需要整合数据，但整合后的数据仍是明细数据，对于这些表而言，数据量往往会比较大，而且会有见多的下游任务依赖这个表，因此可以做一些轻度的汇总，也就是做一些公共的汇总的中间表，这样应用层可以节省很多的计算量和成本。此外，虽然建议使用中间表，但也要注意中间表的数量，因为中间表数量过多，就会有太多的依赖层级。
在某些业务场景下，我们还需要对宽表进行拆表，拆表的情况一般发生在该表的字段较多，而其中几个字段的产出时间较晚，导致整个表的交付时间也会延迟，在这种情况下我们可以将这几个字段单独拆出来处理，这样就不会因为几个字段影响其余业务的使用。
与拆表相对的情况是合表，随着业务的增多，可能会有多个表中存放类似的数据指标，此时，我们可以将多个表整合到一个表中，减少数据任务的冗余。

表分区的功能一定要合理利用，这对于性能会产生很大的影响，一级分区一般都是按照天划分的，建议大家一天一个增量或者一天一个全量来做。二级分区的选择反而会多一些，首先大家要烤炉是否建立二级分区，其次大家再选择二级分区的建立方式。培数二级分区比较适合于在where语句中经常使用到的字段，而且这个字段应该是可枚举的，比如部门名称这样的。这里还有一个前提，就是如果这个字段的值的分布是非常不均匀的，那么就不太建议做二级分区。

离线数仓的计算任务基本都是通过SQL实现，这里也只讲在SQL部分如何进行优化。我们平时在进行数据处理，数据清洗，数据转换，数据加工的过程中都会使用到SQL。对于大数据体系下孙誉的SQL的优化而言，主要集中在两个大的方面进行：减少数据输入和避免数据倾斜。减少数据输入是最核心的一点，如果数据输入量太大，就会占用很多的计算资源。而数据倾斜是在离线数仓中经常会遇到的，数据倾斜分为几种，需要针对性的进行优化。

对有分区的表，合理使用分区可以过滤数据，避免全表扫描，有效的降低计算的数据输入。

SQL支持只读取一次源数据，然后将其写入到多个目标表，这样就保证了只做一次查询。语法如下

当我们在使用join，Rece或者UDF时，先对数据进行过滤也能有效的提高任务的效率

当发生数据再Map阶段倾斜的情况，第一种处理方式反馈至业务层面，看能否通过业务层面的修改让kv值均衡分布，如果业务层面无法处理，那么可以调整Map的个数，也就是加大Map的计算节点，默认情况是每256M的数据为一个计算节点，我们可以将其调小，也就是加大Map处理的节点的个数，使得数据分割的更加均匀一些。

Join阶段的倾斜也是比较常见的，其解决方案需要分钟如下几种情况处理：

Rece倾斜可能的情况有以下几种：

总结一下，性能调优归根结底还是资源不够了或者资源使用的不合理，或者是因为任务分配的不好，使得某些资源分配和利用不合理。

2. 2021年大数据工程师面试内容包括哪些

【导语】近年来，大数据发展如火如荼，很多人都选择学习大数据专业或者转行大数据，大数据里又包含很多就业岗位，所以在进行岗位选择的时候，还是需要大家合理选择，为了帮助大家更好的进入大数据行业执业，下面就把2021年大数据工程师面试内容给大家进行一下具体介绍。

1、自我介绍

一般上来就是自我介绍，谈下工作经历和项目经验，面试官会根据你的项目经验对你进行技术面试。在自我介绍时，一定要抓住核心说，不要太啰嗦，尽量放大自己的价值，让面试官感受到你对工作的热情，以及以后对公司贡献的能力。

2、数仓开发知识技能

(1)java是必问的，不过问的不深，把Javase部分吃透，足以应付Java部分的面试。

(2)Hadoop生态，Yarn、Zookeeper、HDFS这些底层原理要懂，面试经常被问。

(3)Maprece的shuffle过程这个也是面试被常问的。

(4)Hbase和HIve，搞大数据这些不懂真的说不过去。

(5)Mysql、Oracle和Postgres数据库操作要回，Sql要会写。

(6)linux操作系统，这个简单得命令必须要懂，会写shell脚本更好了。

(7)Kettle或Sqoop这种数据处理工具至少要会一个。8，数据仓库建模、数据模型的问题。

3、技术方面知识技能

(1)SparkSql和SparkStreaming，底层原理、内核、提交任务的过程等等，尽量深入内幕，这个经常会跟MapRece作比较的。当然也要了解Storm和Flink，Flink这个建议要学会，以后用处会越来越广。

(2)Redis、Kafka、ElasticSearch这些都得懂原理，深入了解，会使用，会操作，会调优。

(3)impala和kylin这些尽量也要了解会用

(4)Python这个要是有能力，有精力，建议也要往深处学习，我目前正在自学中。

(5)集群的问题，包括一些简单的运维知识。

(6)大数据数据倾斜的问题，包括Spark JVM内存调优问题等等。

关于2021年大数据工程师面试内容，就给大家介绍到这里了，希望对大家能有所帮助，当然进入大数据行业，还需要大家在平时不断进行技能提升，这样才能更好的拥有一席之地。

3. 常见大数据公司面试问题有哪些

1、您对“大数据”一词有什么了解?

答： 大数据是与复杂和大型数据集相关的术语。关系数据库无法处理大数据，这就是为什么使用特殊的工具和方法对大量数据执行操作的原因。大数据使公司能够更好地了解其业务，并帮助他们从定期收集的非结构化和原始数据中获取有意义的信息。大数据还使公司能够根据数据做出更好的业务决策。

2、告诉我们大数据和Hadoop之间的关系。

答： 大数据和Hadoop几乎是同义词。随着大数据的兴起，专门用于大数据操作的Hadoop框架也开始流行。专业人士可以使用该框架来分析大数据并帮助企业做出决策。

注意： 在大数据采访中通常会问这个问题。 可以进一步去回答这个问题，并试图解释的Hadoop的主要组成部分。

3、大数据分析如何有助于增加业务收入?

答：大数据分析对于企业来说已经变得非常重要。它可以帮助企业与众不同，并增加收入。通过预测分析，大数据分析为企业提供了定制的建议。此外，大数据分析使企业能够根据客户的需求和偏好推出新产品。这些因素使企业获得更多收入，因此公司正在使用大数据分析。通过实施大数据分析，公司的收入可能会大幅增长5-20%。一些使用大数据分析来增加收入的受欢迎的公司是-沃尔玛，LinkedIn，Facebook，Twitter，美国银行等。

4. 「每日一道大数据面试题系列」spark如何调优

如果面试时被问到spark任务如何调优，我们该如何回答呢？

下面我们从四大方面回答这个问题，保证吊打面试官。

一、spark性能调优

1、分配更多的资源

比如增加执行器个数（num_executor）、增加执行器个数（executor_cores）、增加执行器内存（executor_memory）

2、调节并行度

spark.default.parallelism

3、重构RDD架构以及RDD持久化

尽量去复用RDD，差不多的RDD可以抽取成一个共同的RDD，公共RDD一定要实现持久化

4、广播变量

SparkContext.broadcast方法创建一个对象，通过value方法访问

5、使用kryo序列化

SparkConf中设置属性：spark.serializer: org.apache.spark.serializer.kryoSerializer

6、使用fastutil优化数据格式（代替java中的Array、List、Set、Map）

7、调节数据本地化等待时长

调节参数: spark.locality.wait

二、JVM调优

降低cache操作的内存占比 1.6版本之前使用的是静态内存管理

spark中堆内存被划分为两块：

一块是专门来给RDD作cachepersist持久化的 StorageMemory，另一块是给spark算子函数运行使用的，存放函数中自己创建的对象。

1.6版本之后采用统一内存管理机制

storage和execution各占50%，若己方不足对方空余可占用对方空间

可尝试调节executor堆外内存

spark.yarn.executor.memoryOverhead = 2048m

调节连接等待时长

spark.core.connection.ack.wait.timeout = 300

三、shuffle数据倾斜调优

1、预聚合源数据，对hive源表提前进行聚合操作，在hive聚合之后，spark任务再去读取

2、检查倾斜的key是否是脏数据，可以提前过滤

3、提高shuffle操作rece的并行度

4、使用随机key实现双重聚合

5、将rece端 join转换成map端 join

6、sample采样倾斜key，单独进行join后在union

7、使用随机数以及扩容表进行join

四、算子调优

1、使用mapPartition提升map类操作的性能

2、filter过后使用coalesce减少分区数量

3、使用foreachPartition优化写数据性能

4、使用repartition解决sparkSql低并行度的性能问题

5、receByKey替换groupByKey实现map读预聚合

5. 数据倾斜时 hadoop和spark哪个性能更好

触发shuffle的常见算子：distinct、groupByKey、receByKey、aggregateByKey、join、cogroup、repartition等。
要解决数据倾斜的问题，首先要定位数据倾斜发生在什么地方，首先是哪个stage，直接在Web UI上看就可以，然后查看运行耗时的task，查看数据是否倾斜了！
根据这个task，根据stage划分原理，推算出数据倾斜发生在哪个shuffle类算子上。
查看导致数据倾斜的key的数据分布情况
根据执行操作的不同，可以有很多种查看key分布的方式：
1，如果是Spark SQL中的group by、join语句导致的数据倾斜，那么就查询一下SQL中使用的表的key分布情况。
2，如果是Spark RDD执行shuffle算子导致的数据倾斜，那么可以在Spark作业中加入查看key分布的代码，比如RDD.countByKey()。然后对统计出来各个key出现的次数，collect、take到客户端打印一下，就可以看到key的分布情况。
比如针对wordCount案例，最后的receByKey算子导致了数据倾斜：
val sampledPairs = pairs.sample(false,0.1) //对pairs采样10%
val sampledWordCounts = sampledPairs.countByKey()
sampledWordCounts.foreach(println(_))
数据倾斜的解决办法
方案一：使用Hive ETL预处理数据
适用场景：导致数据倾斜的是Hive表，Hive表中的数据本身很不均匀，业务场景需要频繁使用Spark对Hive表执行某个分析操作。
实现思路：提前将join等操作执行，进行Hive阶段的ETL。将导致数据倾斜的shuffle前置。
优缺点：实现简单，Spark作业性能提升，但是Hive ETL还是会发生数据倾斜，导致Hive ETL的速度很慢。
实践经验：将数据倾斜提前到上游的Hive ETL，每天就执行一次，慢就慢点吧。

方案二：过滤少数导致倾斜的key
适用场景：少数几个key导致数据倾斜，而且对计算本身影响并不大的话。
实现思路：比如Spark SQL中直接用where条件过滤掉这些key，如果是RDD的话，用filter算子过滤掉这些key。如果是动态判断哪些key的数据量最多然后再进行过滤，那么可以使用sample算子对RDD进行采样，然后计算出每个key的数量，取数据量最多的key过滤掉即可。
优缺点：实现简单，效果也好。缺点是一般情况下导致倾斜的key还是很多的，不会是少数。

解决方案三：提高shuffle操作的并行度
适用场景：直接面对数据倾斜的简单解决方案。
实现思路：对RDD执行shuffle算子时，给shuffle算子传入一个参数，比如receByKey(1000)，该参数就设置了这个shuffle算子执行的shuffle read task的数量。对于Spark SQL中的shuffle类语句，比如group by，join等，需要设置一个参数，即spark.sql.shuffle.partitions，该参数默认值是200，对于很多场景来说有点过小。
优缺点：简单能缓解，缺点是没有根除问题，效果有限。

解决方案四：两阶段聚合（局部聚合+全局聚合）
适用场景：对RDD执行receByKey等聚合类shuffle算子或者在Spark SQL中使用group by语句进行分组聚合时，比较适合这种方案。
实现思路：先局部聚合，给每个key打一个小范围的随机数，比如10以内的随机数，相当于分成10份，一个task分成10个task。聚合聚合后，去掉key上的随机数前缀，再次进行全局聚合操作。

优缺点：大幅度缓解数据倾斜，缺点是仅适用于聚合类的shuffle操作。

解决方案五：将rece join转为map join

6. 大数据技术常用的数据处理方式有哪些

大数据技术常用的数据处理方式，有传统的ETL工具利用多线程处理文件的方式；有写MapRece，有利用Hive结合其自定义函数，也可以利用Spark进行数据清洗等，每种方式都有各自的使用场景。

在实际的工作中，需要根据不同的特定场景来选择数据处理方式。

1、传统的ETL方式

传统的ETL工具比如Kettle、Talend、Informatica等，可视化操作，上手比较快，但是随着数据量上升容易导致性能出问题，可优化的空间不大。

2、Maprece

写Maprece进行数据处理，需要利用java、python等语言进行开发调试，没有可视化操作界面那么方便，在性能优化方面，常见的有在做小表跟大表关联的时候，可以先把小表放到缓存中(通过调用Maprece的api)，另外可以通过重写Combine跟Partition的接口实现，压缩从Map到rece中间数据处理量达到提高数据处理性能。

3、Hive

在没有出现Spark之前，Hive可谓独占鳌头，涉及离线数据的处理基本都是基于Hive来做的，Hive采用sql的方式底层基于Hadoop的Maprece计算框架进行数据处理，在性能优化上也不错。

4、Spark

Spark基于内存计算的准Maprece，在离线数据处理中，一般使用Spark sql进行数据清洗，目标文件一般是放在hdf或者nfs上，在书写sql的时候，尽量少用distinct，group by recebykey 等之类的算子，要防止数据倾斜。