干货满满，202303最新各大厂大数据核心面试题

答案：Hive在实际项目中的优化主要包括以下几个方面：

• 小文件优化：通过CombineHiveInput、merge、jvm重用等技术减少小文件数量，提高处理效率。
• 数据倾斜优化：

  分组聚合导致的数据倾斜：采用map-side预聚合，或者在Hive中设置hive.groupby.skewindata=true，启动两个MR任务，第一个MR按照随机数分区，分散数据并完成部分聚合，第二个MR按照分组字段分区，完成最终聚合。

  Join产生的数据倾斜：过滤掉可以过滤的null值，对key加随机数进行打散；大小表join使用map join；大表和大表join时，可以分桶或者启用hive.optimize.skewjoin=true，自动处理倾斜key的map-join。

• 其他优化：

  分区裁剪：通过合理设置分区，减少扫描的数据量。

  桶表优化：使用桶表提高join和sample的效率。

  动态分区优化：调整动态分区的相关参数，如hive.exec.dynamic.partition.mode、hive.exec.max.dynamic.partitions等，以提高动态分区的性能。

  压缩优化：使用合适的压缩算法（如Snappy、Gzip）减少存储空间和I/O开销。

  SQL优化：避免使用SELECT *，尽量使用具体的列名；优化复杂的嵌套查询，使用子查询或WITH语句；避免在WHERE子句中使用函数或计算，尽量使用索引。

面试中可能遇到的追问及回答：

• 面试官：上面的回答都是理论上的，有没有实际中的Hive优化，高级一点的？

• 回答：在实际项目中，我们还对Hive的查询进行了优化，比如对经常查询的字段建立索引，使用物化视图存储复杂查询的结果，以减少查询时间。同时，我们也对Hive的元数据进行了优化，比如使用更高效的存储格式（如ORC）来提高查询性能。

• 面试官：你说的分组聚合的数据倾斜，利用map-side在map端预聚合，但是如果倾斜的key分布比较散乱在不同的mapTask上，每个mapTask预聚合的条数有限，预聚合后还是有大量倾斜的key要做shuffle怎么办？

• 回答：针对这种情况，我们可以进一步采用更细粒度的分区策略，或者在预聚合阶段使用更复杂的逻辑来减少倾斜key的数量。此外，还可以考虑使用Hadoop的分布式缓存来存储倾斜key的预聚合结果，以减少shuffle阶段的开销。

答案：Spark SQL运行缓慢的原因可能包括以下几个方面：

• 数据倾斜：检查是否存在某些key的数据量远大于其他key，导致处理这些key的任务运行缓慢。
• 资源不足：检查集群的资源使用情况，包括CPU、内存和磁盘I/O等，确保资源充足。
• 不合理的分区：检查数据的分区情况，确保数据在分区之间均匀分布。
• 复杂的查询逻辑：检查查询语句的复杂度，包括嵌套查询、多表join等，优化查询逻辑。
• 不合适的缓存策略：检查是否对频繁访问的数据进行了缓存，以及缓存策略是否合理。

分析步骤：

1. 使用EXPLAIN命令：查看Spark SQL的执行计划，了解查询的各个阶段和每个阶段的数据量。
2. 查看日志：检查Spark的日志文件，查找可能的错误或警告信息。
3. 监控资源使用情况：使用Spark UI或集群管理工具监控资源使用情况，包括CPU、内存和磁盘I/O等。
4. 调整配置参数：根据分析结果调整Spark的配置参数，如executor数量、内存大小、并行度等。

答案：针对两张大表join且存在热点key的问题，可以采取以下策略：

• 采样确定热点key：先对两张表进行采样，确定热点key的范围。
• 对热点key进行特殊处理：

  将热点key对应的数据单独过滤出来，使用map join进行连接。

  对非热点key的数据使用普通的common join进行处理。

• 启用Hive的倾斜join优化：设置hive.optimize.skewjoin=true，让Hive自动处理倾斜key的map-join。
• 手动打散大表：如果热点key很多，可以考虑对大表进行手动打散处理，将倾斜key分散到多个任务中处理。

面试中可能遇到的追问及回答：

• 面试官：如果产生倾斜的热点key很多呢？你都要采样一个一个把这些过滤出来再join吗？
• 回答：如果热点key很多，采样确定热点key的范围可能会变得复杂。此时，可以考虑使用更高效的算法或工具来识别热点key，或者结合业务逻辑对热点key进行预处理。同时，也可以考虑使用分布式缓存来存储热点key的预处理结果，以减少join时的开销。

答案：统一指标口径是数据治理中的重要环节，可以采取以下措施：

• 建立指标体系：梳理所有指标，将其拆分成原子指标，并定义派生指标的计算公式和统计口径。
• 开发指标管理系统：建立指标管理系统，将指标体系中的指标录入系统，并提供指标检索、定义和审批等功能。
• 规范指标使用：要求业务方在需要指标时，先在指标管理系统中检索是否有现成的指标，如果有则直接使用；如果没有则按照规范提交指标需求，经过评审和审批后再进行开发。
• 加强培训和沟通：定期对业务方进行数据治理和指标口径的培训，加强沟通和协作，确保各方对指标口径的理解和使用一致。

面试中可能遇到的追问及回答：

• 面试官：你怎么强迫大家都遵守web平台的规则呢？

• 回答：通过制定数据治理规范和流程，明确指标口径的统一要求和使用规范。同时，加强培训和沟通，提高业务方对数据治理和指标口径的认识和重视程度。此外，还可以建立奖惩机制，对遵守规则的业务方给予奖励，对违反规则的业务方进行处罚。

• 面试官：你这个是说怎么建立的指标体系吧？我是问你怎么统一口径的？

• 回答：建立指标体系是统一口径的基础。在建立指标体系的过程中，我们会对所有指标进行梳理和定义，明确每个指标的统计口径和计算公式。这样，在后续使用指标时，就可以按照统一的口径进行统计和分析。同时，通过开发指标管理系统和加强培训沟通等措施，可以确保各方对指标口径的理解和使用一致。

答案：Flink在生产环境中可能遇到的高级问题包括：

• CDC（Change Data Capture）启动报错：可能是由于版本不兼容、配置错误或业务库表锁定等问题导致。
• Left Join产生撤回流导致重复数据：在Flink SQL中使用Left Join时，如果右表数据发生变化，会产生撤回流（Retract Stream），这可能导致左表数据被重复处理。
• 数据倾斜：由于数据分布不均或处理逻辑复杂等原因，可能导致某些任务处理的数据量远大于其他任务。
• 背压问题：当下游处理速度跟不上上游发送速度时，会产生背压问题，导致数据积压和延迟增加。

解决过程：

• CDC启动报错：检查Flink CDC的版本是否与业务库兼容，检查配置文件中的参数设置是否正确，以及业务库表是否存在锁定等问题。
• Left Join产生撤回流导致重复数据：可以通过优化查询逻辑、使用窗口函数或状态管理等方式来避免重复数据处理。
• 数据倾斜：采用更细粒度的分区策略、使用自定义分区器或对数据进行预处理等方式来减少数据倾斜。
• 背压问题：调整下游的处理能力或增加下游的并行度来缓解背压问题；同时，也可以优化上游的数据发送策略或增加缓存来减少数据积压。

答案：离线数仓和实时数仓的下游业务主要包括以下几个方面：

• 离线数仓下游：

  报表：为业务方提供定期的数据报表和分析结果。

  用户画像：基于离线数仓的数据构建用户画像系统，为个性化推荐和精准营销提供支持。

• 实时数仓下游：

  实时报表：为业务方提供实时的数据监控和分析结果。

  推荐系统：基于实时数仓的数据构建推荐系统，为用户提供个性化的推荐内容。

  业务监控：对业务数据进行实时监控和预警，及时发现并处理异常情况。

面试中可能遇到的追问及回答：

• 面试官：报表是给谁看的？用户画像从你们数仓里取哪些数？

• 回答：报表主要给业务方、管理层和数据分析师等人员查看，用于了解业务情况和制定决策。用户画像主要从离线数仓中提取用户的基本信息、行为数据、偏好数据等，用于构建用户画像系统和个性化推荐系统。