1. 自我介绍

2. dqc怎么配的？

3. sla怎么配的？

4. mysql发生数据的增删改的时候，你怎么同步？

5. 你说用Flink cdc完成了数据同步，你讲讲具体怎么操作？

6. 了不了解redis？

7. redis为什么快

8. redis的底层结构是什么？

9. mysql的事务了解吗？

10. 索引了解吗？有哪些索引？

11. 前缀索引是怎么匹配的？

12. 前缀索引的底层原理是什么？

13. 前缀索引的数据结构是什么？

14. 死锁了解吗？ 什么条件会导致死锁？

15. 日常用的什么语言比较多？ 我答python和sql

16. python多线程和多进程了解吗？

17. 用python读过大数据量的表吗？

18. 给一个分布式的多个机器，要同时访问/修改某个文件，你说说怎么解决？

19. numpy怎么读大数据量的表

20. 做过通知机器人吗？

21. 智力题？硬币翻转 我说递归去做，面试官说你这只是提出了个方法，没给答案。

22. 快排了解吗？说一下原理

1. 自我介绍

考察知识点：自我认知、技术栈与岗位匹配度、项目成果量化能力。

参考回答：我叫 XX，有 2 年数据开发经验，核心聚焦数据同步、质量监控和离线分析，熟练用 Python（Pandas/Numpy）做数据处理、SQL 写数仓脚本，还掌握 Flink CDC 实时同步、Redis 缓存、MySQL 优化等技能。

过往项目中，主导过 “xxx 电商数仓 DQC 建设”：用 xxx DQC 工具配置空值、一致性规则，将数据异常率从 3% 降到 0.1%；也用 Flink CDC 实现 MySQL 到 Hive 的实时同步，把数据延迟从 T+1 降秒级。日常工作中 Python 写脚本（如数据清洗、通知机器人）、SQL 做报表的场景最多，和贵公司数据开发岗位的需求匹配度很高，希望能加入团队解决实际业务问题。

回答注意要点：

1. 必含 “核心技术栈”（Python/SQL/Flink CDC），对应岗位需求；
2. 项目成果需 “量化”（如异常率从 3%→0.1%），避免空泛；
3. 结尾关联 “岗位匹配”，体现求职动机。

2. DQC 怎么配的？

考察知识点：数据质量监控（DQC）的通用配置逻辑、规则设计思路与异常处理闭环。

参考回答：我之前配置 DQC 是基于通用流程来的，核心分 4 步，具体平台组件会根据公司实际情况调整：

1. 确定监控对象：先在 xxx DQC 工具里选中要监控的目标表（比如数仓 xxx 层的 xxx 业务表），再指定监控的分区维度（比如按 xxx 时间分区，每天监控当日数据）；
2. 设计监控规则：
   • 基础规则：针对数据完整性、有效性，比如 “xxx 主键字段（如用户 ID）的空值率必须≤0”“xxx 数值字段（如订单金额）的范围在 0-xxx 合理最大值之间”“当日数据量不能低于近 7 天均值的 50%（避免数据缺失）”；
   • 业务规则：结合业务逻辑，比如 “xxx 表的 xxx 字段（如用户所属部门 ID）必须在 xxx 字典表中存在（一致性校验）”；
3. 设置阈值与告警：给每个规则设触发条件，比如 “空值率> 0” 或 “数据量低于阈值” 就触发告警，告警渠道选公司常用的 xxx 方式（如企业微信 / 邮件），同时指定 xxx 角色（如数据开发、业务负责人）为接收人；
4. 关联调度与复盘：把 DQC 任务和 xxx ETL 工具的表处理任务绑定，确保 ETL 跑完数据后，DQC 自动执行；每天会看 DQC 生成的质量报告，若有异常（如规则触发），先排查上游数据源（比如 xxx 系统同步是否出问题），修复后重新跑数，再验证 DQC 结果。

回答注意要点：

1. 用 “xxx” 替代具体平台 / 字段 / 工具，避免绑定特定组件，同时保留 “监控对象→规则→告警→复盘” 的完整流程；
2. 规则必须分 “基础规则 + 业务规则”，体现对数据质量的全面覆盖；
3. 重点提 “异常处理闭环”，说明能落地解决问题，而非仅配置。

3. SLA 怎么配的？

考察知识点：服务等级协议（SLA）的指标定义、阈值设定与保障措施（通用逻辑）。

参考回答：SLA 主要针对数据产出和服务可用性配置，核心是 “定指标 + 设阈值 + 明补偿”，具体工具依赖公司的 xxx 平台：

1. 定义核心指标：
   • 数据产出 SLA：数仓 xxx 层报表需在每日早 8 点前产出（延迟≤30 分钟），数据准确率≥99.99%；
   • 服务 SLA：实时同步服务（Flink CDC）可用性≥99.9%（每月 downtime≤43 分钟），同步延迟≤5 秒；
2. 设阈值与告警：
   • 预警阈值：报表 7:45 还没产出触发预警，通过 xxx 工具通知开发；
   • 熔断阈值：报表 8:30 仍未产出，触发补偿机制（如用前一天数据临时替代）；
3. 保障与补偿：
   • 保障：核心任务用 “主备调度”（主任务失败自动跑备任务，依赖 xxx 调度工具），实时服务多节点部署；
   • 补偿：若 SLA 未达标（如报表延迟 2 小时），需向业务方发致歉函，同步修复方案（如优化 ETL 脚本）。

回答注意要点：

1. 指标需 “量化”，避免模糊；
2. 区分 “预警 + 熔断” 阈值，体现分级处理思路；
3. 提 “保障措施 + 补偿机制”，不是只定规则。

4. MySQL 发生数据的增删改的时候，你怎么同步？

考察知识点：MySQL 数据同步方案的选型与适用场景（通用方案，不依赖特定工具）。

参考回答：根据同步实时性需求选方案，主要用两种通用思路：

1. 实时同步（毫秒 / 秒级）：用 CDC 工具（如 Flink CDC、Canal），基于 MySQL 的 binlog 同步 —— 开启 MySQL 的 binlog（ROW 格式），CDC 工具伪装成 MySQL 从库，读取 binlog 解析增删改事件，同步到目标（如 ES、Hive、Redis）；适合实时数仓、实时监控场景（如 xxx 业务的订单数据同步到 ES 做搜索）；
2. 离线同步（T+1）：用 ETL 工具（如 DataX、Sqoop 或公司自研的 xxx ETL 工具），按分区全量 / 增量同步 —— 全量同步（如每月 1 号同步全量用户表）、增量同步（按update_time字段同步当日修改数据）；适合离线数仓、报表场景（如每日同步前一天的订单表到 Hive）。

回答注意要点：

1. 分 “实时 + 离线” 两种场景，每种场景带 “原理 + 适用场景”；
2. 提关键配置（如 binlog ROW 格式），体现实践细节；
3. 避免只说工具，要关联业务场景。

5. 用 Flink CDC 完成了数据同步，你讲讲具体怎么操作？

考察知识点：Flink CDC 实时同步的通用实操步骤与配置逻辑（替换具体地址 / 参数为 xxx）。

参考回答：以 “MySQL 订单表同步到 Hive” 为例，具体分 5 步，依赖公司的 xxx Flink 集群：