不同岗位、不同公司、不同面试官问的内容是不一样的。大数据开发包括 Hadoop(ETL,Mapreduce),Spark(SparkSql 和 SparkStreaming),Python 等,看你偏向的技术了。另外大数据开发看是否偏向数仓开发和数据分析,又会不一样。不同的面试官和公司用到的技术栈也不一样,问的问题也会有很大差别的。

我说说我面试大数据开发岗面试官常问的问题吧。因为我简历项目项目经验注重实时流处理这方面,在面试时,面试会在这些方面问的比较深,我前后梳理一遍吧。

一般上来就是自我介绍,谈下工作经历和项目经验,面试官会根据你的项目经验对你进行技术面试。

  1. Java 是必问的,不过问的不深,把 Javase 部分吃透,足以应付 Java 部分的面试。
  2. Hadoop 生态,Yarn、Zookeeper、HDFS 这些底层原理要懂,面试经常被问。
  3. Mapreduce 的 shuffle 过程这个也是面试被常问的。
  4. Hbase 和 HIve,搞大数据这些不懂真的说不过去。
  5. Mysql、Oracle 和 Postgres 数据库操作要回,Sql 要会写。
  6. linux 操作系统,这个简单得命令必须要懂,会写 shell 脚本更好了。
  7. Kettle 或 Sqoop 这种数据处理工具至少要会一个。
  8. 数据仓库建模、数据模型的问题。

上面这些更偏向数仓方面,这些能回答明白足以找一份大数据开发工作了,当然想谋求更好发展,还要了解下面的。

  1. SparkSql 和 SparkStreaming,底层原理、内核、提交任务的过程等等,尽量深入内幕,这个经常会跟 MapReduce 作比较的。当然也要了解 Storm 和 Flink,Flink 这个建议要学会,以后用处会越来越广。
  2. Redis、Kafka、ElasticSearch 这些都得懂原理,深入了解,会使用,会操作,会调优。
  3. impala 和 kylin 这些尽量也要了解会用
  4. Python 这个要是有能力,有精力,建议也要往深处学习,我目前正在自学中。
  5. 集群的问题,包括一些简单的运维知识。
  6. 大数据数据倾斜的问题,包括 Spark JVM 内存调优问题等等。

我以前找工作面试很多家公司,这些都会问到,当然不同的公司问的技术是不一样的,大体上都是围绕着上面来问的。

作者:尘寂

链接:https://www.zhihu.com/question/306127087/answer/1060994701

MapReduce

说一下 shuffle,以 MR 为例 shuffle 中涉及到哪些算法,不同算法涉及到哪些场景

Shuffle 是 MapReduce 框架中的关键步骤之一,负责将 map 阶段产生的中间结果分发给 reduce 任务。在 shuffle 过程中,主要涉及以下几种算法或技术:

  • 排序与合并:默认情况下,MapReduce 会对每个 map 输出的键值对进行排序,然后可能还会进行合并(Combiner)操作来减少传输的数据量。适用于大多数场景,特别是在需要聚合操作时。
  • 分区(Partitioning):决定中间数据分配到哪个 reduce 任务上。典型的分区策略包括哈希分区,它确保了相同键的数据会被发送到同一个 reduce 任务。适用于需要基于键进行全局聚合的场景。
  • 压缩:为了减少网络传输的数据量和提高 I/O 效率,shuffle 过程中可能会对数据进行压缩。选择合适的压缩算法可以在不影响性能的前提下显著减少数据传输量。适用于任何需要优化 I/O 或网络传输的场景。

Hive

在 Hive 中,当您使用动态分区功能进行数据插入时,可能会遇到“too many dynamic partitions”错误,如何处理

这个问题可以通过调整 Hive 配置参数hive.exec.max.dynamic.partitionshive.exec.max.dynamic.partitions.pernode来解决,增加这两个参数的值可以允许更多的动态分区被创建。

Apache Spark

在 Apache Spark 中,宽依赖(Wide Dependency)和窄依赖(Narrow Dependency)是两种不同类型的依赖关系,对性能分别有什么影响

宽依赖会导致 Shuffle 操作,这通常比较耗时且资源密集,因为它需要跨节点传输数据。而窄依赖则不需要进行 Shuffle,它可以在本地完成计算,因此效率更高。

reduce 的阶段,长时间卡在 99%,分析原因,如何排查

这种情况可能是因为数据倾斜导致的,即某些 reduce 任务处理的数据量远大于其他任务。解决办法包括重新分区数据、优化数据分布或者调整算法逻辑。

Spark 运行任务,出现小文件的问题,如何处理

处理小文件问题的一个常见方法是使用 Spark 的 coalesce 或 repartition 方法减少文件数量,或者在写入数据之前先聚合数据。

如何权衡小文件处理过程中的时间、空间、资源消耗

根据具体的应用场景选择合适的策略,例如合并小文件以减少存储空间,同时考虑处理时间和系统资源的消耗。

Spark UI 怎么看,关注哪些点去判断数据倾斜

通过 Spark UI 可以查看各个 stage 的执行情况,尤其是 task 的完成时间和处理的数据量。如果发现某些 task 执行时间远长于其他 task,或者处理的数据量显著大于其他 task,则可能存在数据倾斜。通常需要关注以下几个指标:

  • Task 的执行时间分布。
  • Shuffle Read 和 Shuffle Write 的数量和大小。
  • Stage 中不同 Task 处理的数据量差异。

SQL 语法中哪些关键词最容易导致数据倾斜

在 SQL 语法中,JOIN 操作是最容易引起数据倾斜的,特别是当使用不均衡的键进行 JOIN 时(例如:一个表中的某键对应大量记录而另一个表中该键只对应少量记录)。此外,GROUP BY 也可能导致数据倾斜,尤其是在处理高度偏态分布的数据时。

Kafka

在使用 Kafka 作为消息队列时,消费者出现重复消费的问题是比较常见的,分析原因,怎么处理

消费者重复消费的原因可能是由于消费者组再平衡、消费者崩溃后重启等。为了解决这个问题,可以启用幂等性消费者或者实现基于业务逻辑的消息去重机制。

在使用 Kafka 拦截器(Interceptors)时,需要注意什么,以确保其正确性和效率

使用拦截器时需要注意拦截器的顺序以及它们之间如何交互。此外,还需要考虑拦截器的性能影响,尽量使拦截器轻量化,并对其进行充分测试。

数据治理与数仓设计

数据治理过程中,需要下线重复指标,如何验证下游不会受到影响

一个方法是建立一个完整的测试环境,模拟指标下线后的各种场景,观察下游系统的行为是否正常。

数仓设计中,如何设计 ODS 和 DWD 层的字段颗粒度

设计时应考虑到数据的最终用途和查询需求,保持适当的粒度以便于后续的数据处理和分析工作。

数据治理中,代码之外,哪些地方可以优化

包括但不限于流程优化、文档完善、人员培训等方面。

看板口径整合,数据一致性如何保障

可以通过制定严格的数据标准、定期进行数据质量检查和维护一致的数据字典等方式来保证数据的一致性。

MySQL 与 Hive

从 MySQL 导入数据至 Hive,使用 Scoop 如何解决数据不一致问题

使用 Sqoop 进行数据迁移时,可以通过设置事务边界、增量导入等方式来减少数据不一致的风险。

其他

DQC 告警如何判断

判断 DQC 告警首先需要理解告警的具体内容,然后根据业务规则和数据质量标准进行验证。

成果中的指标变化,数据计算方式和来源具体讲解

对于每个指标的变化,都需要详细记录其计算方法和数据来源,以便追踪和审计。

数据变化是如何评估的

数据变化的评估通常涉及对比基线数据和当前数据,使用统计学方法计算差异并分析原因。

思维题

设计一个高并发的日志采集和分析系统,要求使用 Flume、HDFS、Kafka,分析并详细讲解技术选型,在这个场景中,针对数据丢失的情况,如何做预防,设计一些方法思路

技术选型上,Flume 用于日志收集,Kafka 用于消息队列保证日志的实时传输,HDFS 用于长期存储。为了防止数据丢失,可以采用 Kafka 的持久化机制、Flume 的多通道配置以及 HDFS 的副本策略等措施。

Python

如何在数据清洗过程中应对内存不够的情况

面经作者通常会分享一些实际操作中的技巧,比如使用 Dask 或 Pyspark 来代替 Pandas 处理大规模数据集,因为它们能够更好地管理内存和计算资源。

如何避免,在使用 Pandas 处理大规模数据时,经常会遇到“SettingWithCopyWarning”警告

解决这个问题的方法之一是确保使用.copy()方法创建 DataFrame 的副本,以明确表达你的意图。另一个方法是通过设置pd.options.mode.chained_assignment = None来忽略这个警告,但这并不是推荐的做法,因为它可能会掩盖潜在的问题。