1. 你实习做过最难的需求，难在哪里
2. 口径都是谁定的
3. 你负责这块业务，团队的关注点在哪里
4. 你负责这块业务每日gmv多少
5. 你处理的数据量多大
6. 你怎么做数据探查的
7. 你和产运同学，DS同学是怎样的合作模式 这个合作模式你觉得优点是什么，缺点是什么
8. 你的职业规划
9. 你是北方人，为什么去湖南读大学
10. 为什么高考志愿选择计算机 为什么选择做数据
11. 你平时喜欢逛什么社区 有看什么书吗

大数据技术问题+计算机基础知识

12 HA高可用

13 zookeeper是什么

14 HDFS是什么架构

15 MapReduce的过程讲一下

16 三次握手四次挥手

17 进程和线程的区别

18 线程的通信安全是如何保障的

19 AI了解过吗

20 GPT 5刚发布，比上一代做出了哪些优化呢

21 sql 题目

table1 id user_id 这两个字段为联合主键table2id order_id 这两个字段为联合主键写一段SQL，求出id,user_id_cnt,order_id_cnt（效率越高越好）`

答案如下

1. 实习做过最难的需求，难在哪里

• 考察知识点：复杂问题拆解能力、技术攻坚能力、复盘总结意识
• 参考回答： 最难的是「实时用户画像标签计算」需求，核心难点在“低延迟+高准确性+大状态”三重约束：
• 难在状态管理：标签需保留用户近30天行为（如点击、加购），Flink State数据量达50GB，默认Memory State频繁OOM，调试2天发现需切换为RocksDB State（支持磁盘存储），并配置State TTL（自动清理30天前数据），解决内存溢出问题；
• 难在延迟控制：业务要求标签更新延迟<1秒，但维表关联（用户等级表）需查询MySQL，单次查询耗时200ms，通过「预加载维表至Redis+定时刷新」优化，关联耗时降至20ms；
• 难在准确性保障：用户行为存在乱序（如10:05的点击比10:00的点击晚到达），需用Watermark设置5分钟乱序容忍，同时在Sink端加“去重逻辑”（按user_id+行为时间去重），最终标签准确率从92%提升至99.5%。
• 回答注意要点：
  • 明确“难的具体点”（状态/延迟/准确性），而非笼统说“难”；
  • 讲清「解决步骤+技术选型」（如RocksDB State、Redis预加载）；
  • 量化优化效果（如“延迟<1秒”“准确率99.5%”）。

2. 口径都是谁定的

• 考察知识点：业务口径对齐流程、跨团队协作能力
• 参考回答： 口径分「业务口径」和「技术口径」，定责和流程不同：
• 业务口径（如GMV定义、活跃用户标准）：由产品/运营同学主导，数据团队协助对齐——比如“GMV是否包含退款”，运营提出需求后，我们会拉产品、财务开对齐会，明确“GMV=实付金额-退款金额”，并同步到「指标字典」（文档沉淀，全团队共享）；
• 技术口径（如字段类型、分区规则）：由数据团队主导，结合技术规范定——比如用户行为表按“dt（日期）+hour（小时）”分区，字段user_id用string类型（避免数值溢出），定好后同步给下游（如算法、运营），确保全链路使用一致。 若口径有变更（如运营调整活跃用户定义），会走「变更流程」：先同步影响范围（如涉及3个报表、2个实时任务），再灰度切换，最后验证数据一致性。
• 回答注意要点：
  • 区分“业务/技术口径”，逻辑清晰；
  • 提及「文档沉淀+变更流程」，体现规范化意识；
  • 结合具体例子（如GMV定义），避免抽象。

3. 你负责这块业务，团队的关注点在哪里

• 考察知识点：业务优先级认知、团队协作目标感
• 参考回答： 我负责的「用户行为数据链路」，团队核心关注3个维度：
• 数据质量：重点监控“准确性”（如订单表金额是否与业务库一致）、“完整性”（核心字段null率<0.1%）、“及时性”（离线表T+1早6点前产出，实时表延迟<1秒），每天晨会同步质量报表，异常时1小时内响应；
• 业务支撑效率：运营/算法提需求后，从需求拆解到数据产出的周期——简单需求（如新增字段）1天内完成，复杂需求（如用户画像标签）3-5天，团队会定期复盘需求响应时长，优化流程（如预定义常用宽表）；
• 成本控制：监控HDFS存储占用（避免冗余表）、Spark/Flink任务资源利用率（CPU<50%时调减Executor），上月通过清理3个月前的临时表，节省存储成本20%。
• 回答注意要点：
  • 贴合数据团队核心关注点（质量/效率/成本）；
  • 提及「监控/复盘」机制，体现团队规范性；
  • 用案例（如“节省20%存储成本”）佐证。

4. 你负责这块业务每日GMV多少

• 考察知识点：业务熟悉度、数据敏感度
• 参考回答： 略
• 回答注意要点：
  • 数据要具体（分日常/大促、分品类），体现业务熟悉；
  • 关联自身负责的工作（如支撑GMV报表），避免脱离岗位；
  • 若记不清精确值，可说“大概范围+波动原因”，避免编造。

5. 你处理的数据量多大

• 考察知识点：大数据场景实战经验、技术适配能力
• 参考回答： 实习期间处理的数据分「离线」和「实时」两类，量级和技术适配如下：
• 离线数据：日均50TB，主要是用户行为日志（浏览、点击、下单）和业务库同步数据（订单、商品）——用HDFS存储（按日期分区），Hive做离线计算（采用ORC压缩格式，比Text格式节省60%存储空间），Spark做复杂聚合（如用户近30天消费统计），单任务处理10亿条数据，通过分桶JOIN（按user_id分100桶）解决数据倾斜，执行时间从2小时优化至40分钟；
• 实时数据：日均10亿条，峰值QPS 5000（大促期间达1万），主要是订单流、用户行为流——用Kafka接入（3副本+20分区，保障高可用），Flink做实时计算（窗口大小5秒，并行度16），结果写入ClickHouse（按时间分区），供实时看板查询，延迟稳定在50ms内。
• 回答注意要点：
  • 分「离线/实时」说明，贴合大数据岗位场景；
  • 提及「技术适配方案」（如ORC压缩、分桶JOIN），体现技术深度；
  • 数据量要具体（如“50TB”“10亿条”），避免模糊表述。

6. 你怎么做数据探查的

• 考察知识点：数据质量保障能力、探查工具与方法落地
• 参考回答： 数据探查分「新表上线前」和「日常监控」两类场景，核心是“发现异常（空值、异常值、逻辑矛盾）并定位原因”：
• 新表上线前（如DWD层用户行为表）：
  1. 基础指标探查：用Hive SQL查核心字段——① 空值率（count(case when user_id is null then 1 end)/count(*)）；② 取值范围（如score是否在0-100）；③ 唯一性（联合主键是否重复，count(distinct id,user_id) = count(*)）；
  2. 业务逻辑探查：验证跨表一致性（如订单表的user_id在用户表中存在，select o.user_id from order o left join user u on o.user_id=u.user_id where u.user_id is null）；
  3. 工具辅助：用DataGrip的「数据采样」功能（取1000条数据），快速查看数据格式（如时间字段是否为“yyyy-MM-dd”）；