前言

前几天写了面试的上，主要是6个问题，这次把剩下的面试题再复盘一下。

Q7：你有遇到过反压么？怎么解决的？

这个问题是做实时流处理经常会遇到的问题，反压是指Flink的某个算子数据处理有瓶颈。从而导致数据消费的速度跟不上生产，最后导致数据积压。

举例说明项目中棘手的反压问题 比如接口调用（网络IO）

然后说一下怎么解决的（async)

Q8: count distinct 执行原理？ 比如我有一个登录表， 我要算uv嘛， 底层是怎么执行的？ mapper reduce?

这里主要是想考察SQL的执行原理，对于count distinct这个语句，是对某个字段进行去重统计，如果直接写的话，就是一个MR任务，且只有一个reduce任务，很可能出现性能问题，如果数据量比较大的情况下，会导致失败，集群会直接kill掉container，因为是全内存的去重操作，从而引发了OOM问题。

优化方式就是使用group by，再进行count，这样多进行了一次job但是可以避免数据倾斜，不依赖域内存，效率会提升。

即

1
select count(*) from (select id from tb where id between 1 and 999999 group by id) a;

这个脚本会执行两个job，第一个是把ID去重，第二个是用于计算count。

Q9：hive SQL的优化策略？

  1. 目的就是减少单表 数据量，通过分区表可以大大减少数据统计的量，尤其是业务上不需要每次统计所有的数据的时候在join的时候附表要避免先关联全部再去过滤的情况。

  2. 尽量不是直接用count distinct

  3. 使用with as 语法，代替业务复杂的子查询，生成临时表，一次

  4. 大小表的join， 小表在左边。common join -》mapjoin

  5. 避免数据倾斜。数据倾斜只会发生在shuffle过程中。如distinct、 groupByKey、reduceByKey、aggregateByKey、join等。注意要过滤null值，将集中的Key按照一定规则添加随机数。避免全表扫描（例如on添加加上分区等）

Q10：星型模型和雪花模型都有什么优劣？

星型模型是一种简单且直观的模型，其中一个事实表与多个维度表相连。这种模型易于理解和查询，具有较好的性能。然而，它可能面临冗余数据存储的问题，因为多个维度表可能需要重复存储相同的数据。

雪花模型是在星型模型基础上进行扩展的模型，通过将维度表进一步细分为多个规范化的表来减少数据冗余。这种模型可以更好地处理复杂的关系和层次结构，并且在维度表数据更新时更加灵活，但相应地会增加查询的复杂性和开销。

总体而言，星型模型适合简单的数据关系和快速查询，而雪花模型适合包含复杂层次和关系的大型数据仓库。选择哪种模型取决于数据的特点、业务需求和性

Q11：如何衡量一个维度建模的优劣？

可以考虑以下几个方面出发

  1. 理解和查询能力：一个好的维度建模应该能够清晰地反映业务需求，并提供简单直观的查询路径。维度表的结构应该易于理解，而且查询性能要高效。

  2. 灵活性：维度建模应该具备足够的灵活性，以应对业务需求的变化。它应该能够轻松地添加、修改或删除维度和度量，以适应新的业务规则和指标。

  3. 数据准确性和一致性：维度建模应该保证数据的准确性和一致性。这包括确保维度和度量之间的关联是正确的，并且没有重复或冗余的数据。

  4. 性能和可扩展性：维度建模应该具备良好的性能和可扩展性，以支持大规模数据量和复杂查询。它应该能够处理快速增长的数据，并在查询时提供响应迅速的结果。

  5. 易于维护和管理：一个好的维度建模应该易于维护和管理。这包括数据加载过程的自动化、数据质量的监控和维护、元数据的管理等方面。

  6. 扩展性和适应性：维度建模应该具备良好的扩展性和适应性，以应对未来的业务需求和技术变化。它应该能够支持不断增加的数据和新的分析要求。

Q12：为什么从后端转了大数据？

兴趣使然。这个随便扯扯了。

总结

基本上还是以项目为主，结合项目中的知识点进行考察，所以平时准备面试的时候需要对项目简历中的技术栈保持关注，并且保持对业务的理解和思考。

千里之行始于足下，加油。