1. 看板优化4min->2s怎么实现的，
2. 上述优化过程中遇到的问题。
3. 公司数据架构。
4. 数据倾斜优化的经验。
5. 在生产中用spark多吗。(spark代码，spark sql没写过)
6. 简单说一下为什么在生产中有时候用mapreduce、有时候用spark，说一下他们各自的特点，在什么场景选什么技术方式场景
7. 集群资源紧张的情况下，跑一个任务，选择spark还是MR。
8. Hive 底层执行逻辑、将SQL转化为mapreduce程序的过程。
9. 说到逻辑优化，在HiveSQL中，有几种mapjoin方式。
10. 在map join中多大的表算小表。(默认25M)
11. 在实习过程中影响深刻、花费时间最多的问题，

简历深挖技术问题补充解答

1. 看板优化4min->2s怎么实现的

考察知识点

• 数据查询性能瓶颈分析能力（计算、存储、传输层面）；
• 优化手段的技术选型逻辑（缓存、计算引擎、数据预处理等）；
• 实战中性能调优的优先级判断。

参考回答

看板从4分钟优化到2秒，核心是分层突破性能瓶颈，按“数据层→计算层→展示层”逐步优化，具体步骤：

1. 数据层：减少计算量
   • 排查发现原始看板直接查询全量明细数据（每日1000万+条），且包含3个月历史数据。通过“预聚合+分区存储”优化：
     • 按“天+维度”预计算聚合结果（如用户地域、时段的汇总指标），存储到ClickHouse（列式存储，聚合查询比MySQL快100倍+）；
     • 按时间分区，看板默认展示近7天数据，仅扫描对应分区，避免全表扫描。
2. 计算层：优化查询逻辑
   • 原始SQL包含3层子查询和未索引的关联操作，重构为“宽表关联+索引优化”：
     • 将多表Join逻辑迁移到ETL阶段，生成单张宽表，避免查询时实时关联；
     • 对宽表的查询维度（如date、region_id）建立二级索引，ClickHouse的MergeTree索引使过滤速度提升10倍。
3. 展示层：减少重复计算
   • 发现看板刷新时重复执行相同查询，引入“多级缓存”：
     • 本地缓存：前端对相同参数的查询结果缓存1分钟（用户高频切换维度时复用）；
     • 服务端缓存：用Redis缓存聚合结果（过期时间5分钟，平衡实时性与性能），热门查询直接命中缓存，耗时<100ms。
4. 硬件与配置调优
   • 调整ClickHouse的max_threads参数（从默认4增至16），利用多核并行计算；
   • 将看板服务部署到离数据库更近的节点，减少网络传输延迟（从50ms降至5ms）。

补充回答注意要点

• 突出“数据量与耗时的对应关系”：如“全量1000万条→4分钟，预聚合后10万条→10秒”，用具体数据体现优化逻辑；
• 强调“分层优化的优先级”：先通过预聚合减少数据量（性价比最高），再优化查询，最后加缓存，体现系统性思维；
• 避免只说技术名词：每个手段（如ClickHouse、Redis）需说明“为什么用”（如ClickHouse适合聚合查询，Redis适合高频小数据缓存）。

2. 上述优化过程中遇到的问题

考察知识点

• 问题排查与解决能力；
• 技术方案落地的风险预判；
• 权衡优化效果与系统稳定性的经验。

参考回答

优化中遇到3个核心问题，均围绕“性能提升与业务需求的平衡”展开：

1. 预聚合数据的实时性缺失
   • 问题：预聚合按小时更新，导致看板数据延迟1小时，业务方要求实时性（延迟<5分钟）。
   • 解决：采用“增量预聚合”，每5分钟计算一次新增数据的聚合结果，与历史结果合并，既保证实时性，又避免全量重算。
2. 缓存一致性问题
   • 问题：Redis缓存过期前，数据更新后看板展示旧数据（如用户手动修正指标后未实时刷新）。
   • 解决：实现“缓存主动失效”机制，数据更新时通过消息队列触发缓存删除，确保下次查询重新加载最新数据。
3. 宽表存储成本激增
   • 问题：宽表包含200+字段，按天分区后存储量达10TB/月，远超预期。
   • 解决：按“访问频率”拆分字段，高频查询字段保留在宽表，低频字段存储在冷数据分区，查询时通过视图关联，存储成本降低60%。

补充回答注意要点

• 遵循“问题→影响→解决方案→结果”的叙事逻辑，体现解决问题的闭环思维；
• 突出“业务视角”：每个问题需说明对业务的影响（如实时性影响运营决策），避免纯技术角度描述；
• 举例要具体：如“缓存过期时间设为5分钟”而非“调整了缓存时间”，体现细节把控能力。

3. 公司数据架构

考察知识点

• 对数据全链路的理解（采集→存储→计算→应用）；
• 各组件的选型逻辑与协作关系；
• 数据架构的扩展性与业务适配性。

参考回答

公司数据架构采用“分层式架构”，从下到上分为5层，支撑业务分析、风控、推荐等场景：

1. 数据源层
   • 业务系统：MySQL（交易、用户数据）、MongoDB（日志、非结构化数据）；
   • 第三方数据：API接口（支付流水、物流信息）、爬虫数据（竞品价格）。
2. 数据采集层
   • 实时采集：Flink CDC同步MySQL binlog（延迟<1秒），Kafka接收日志数据（峰值10万条/秒）；
   • 批量采集：Sqoop定时同步MySQL全量数据（每日凌晨执行），Python脚本抓取第三方数据。
3. 数据存储层
   • 原始数据：HDFS（存储历史明细，容量100TB+）；
   • 结构化数据：Hive（离线数仓，按主题分区，如用户主题、订单主题）；
   • 实时数据：ClickHouse（实时看板、监控指标）、Redis（缓存热点数据）。
4. 计算与加工层
   • 离线计算：Spark（批处理ETL、模型训练，如用户画像标签计算）；
   • 实时计算：Flink（实时指标计算、风控规则引擎）；
   • 查询引擎：Presto（跨Hive、MySQL的联邦查询，支持业务adhoc分析）。
5. 应用层
   • 数据服务：通过API网关提供指标查询接口（支撑业务系统）；
   • 可视化：Superset（业务看板）、Tableau（高管报表）；
   • 业务系统：推荐系统（调用用户画像数据）、风控平台（实时指标预警）。

补充回答注意要点

• 用“数据流”串联各层：如“用户下单数据→MySQL→Flink CDC→Kafka→Flink计算→ClickHouse→看板”，体现数据的完整链路；
• 说明组件选型原因：如“Hive适合离线数仓（成本低、支持SQL），ClickHouse适合实时查询（聚合快）”，避免只列组件名；
• 突出架构的“业务支撑能力”：如“实时计算层支撑风控系统的秒级预警”，体现架构与业务的结合。

4. 数据倾斜优化的经验

考察知识点

• 数据倾斜的根因分析能力；
• 不同场景下的优化策略选择；
• 优化效果的量化评估。

参考回答

数据倾斜优化的核心是“找到倾斜Key→分散计算压力”，实战中总结出3类场景的应对经验：

1. GroupBy倾斜（单Key数据量过大）
   • 案例：统计用户订单量时，某头部用户订单占比30%，导致单个Task OOM。
   • 优化：Key加盐+二次聚合。
     • 第一次聚合：对倾斜Key添加随机后缀（如“user123_0”到“user123_9”），分散到10个Task；
     • 第二次聚合：去掉后缀，合并结果。最终Task执行时间从1小时降至10分钟。
2. Join倾斜（大表与大表Join时某Key匹配过多）
   • 案例：订单表（1亿条）与用户表（1000万条）Join时，“匿名用户”Key（null值）匹配5000万条，导致倾斜。
   • 优化：拆分倾斜Key+广播小表片段。
     • 拆分订单表：将“匿名用户”数据单独拆分，其他正常Key走普通Join；
     • 广播用户表中“匿名用户”的默认信息（仅1条），与拆分出的订单数据做本地Join。Join耗时从40分钟降至5分钟。
3. 动态倾斜（数据分布随时间变化）
   • 案例：促销活动期间，某商品ID的交易量激增，平时正常的代码出现倾斜。
   • 优化：动态检测+自适应调整。
     • 用Spark的sample算子实时采样数据，若发现某Key占比超过10%，自动触发加盐逻辑；
     • 活动结束后，自动恢复正常计算，无需人工干预。

补充回答注意要点

• 每个案例说明“现象→根因→措施→效果”：用具体数据（如数据量、耗时）体现优化价值；