1. AI的召回率和准确率怎么计算
  2. DWM和DWS的区别
  3. Hadoop 有哪些组件
  4. Mapreduce 的过程
  5. 数据质量监控
  6. 数据治理怎么理解
  7. 维护表总共有多少张，设置数据监控的有多少。
  8. 多天分区数据处理，UDF函数报错，怎么排查
  9. 最近在学什么
  10. Clickhouse 和 Doris 的区别，使用场景
  11. AI方面的了解吗。
  12. SQL，连续7+天登录

答案如下

1 . AI的召回率和准确率怎么计算？

考察知识点

  • 机器学习二分类任务的核心评价指标（混淆矩阵的应用）
  • 召回率与准确率的业务含义差异（漏检vs误检）
  • 指标适用场景（不同业务对“漏检”“误检”的容忍度）

参考回答

召回率（Recall）和准确率（Precision）是AI分类任务（如简历匹配、垃圾邮件识别）的核心评价指标，基于“混淆矩阵”（True Positive/False Positive/True Negative/False Negative）计算，适用于判断模型的“查全能力”与“查准能力”。

（1）混淆矩阵定义（以“候选人-岗位匹配”为例）

实际情况\预测结果 正例（匹配） 负例（不匹配）
正例（真匹配） TP（真阳性）：模型预测匹配，实际确实匹配（正确推荐） FN（假阴性）：模型预测不匹配，实际匹配（漏推荐）
负例（真不匹配） FP（假阳性）：模型预测匹配，实际不匹配（错推荐） TN（真阴性）：模型预测不匹配，实际不匹配（正确拒绝）

（2）计算公式

  1. 准确率（Precision，查准率）：
    1. 定义：模型预测为“正例”的结果中，实际为“正例”的比例（衡量“推荐结果的精准度，避免错推荐”）；
    2. 公式：Precision = TP / (TP + FP)；
    3. 示例：模型推荐20个候选人（TP+FP=20），其中实际匹配的有17人（TP=17），则准确率=17/20=85%。
  2. 召回率（Recall，查全率）：
    1. 定义：实际为“正例”的样本中，被模型预测为“正例”的比例（衡量“是否漏推荐，避免错过优质候选人”）；
    2. 公式：Recall = TP / (TP + FN)；
    3. 示例：企业岗位实际匹配的候选人有20人（TP+FN=20），模型仅推荐了16人（TP=16），则召回率=16/20=80%。

（3）适用场景差异

  • 优先选准确率：业务对“错推荐”容忍度低（如高端岗位招聘，错推荐会浪费顾问面试时间），需确保推荐的候选人“尽可能精准”；
  • 优先选召回率：业务对“漏推荐”容忍度低（如稀缺技术岗位招聘，需尽可能覆盖所有潜在匹配候选人），避免错过优质人才；
  • 平衡指标：实际场景中常用“F1分数”（准确率与召回率的调和平均）综合评价，公式：F1 = 2*Precision*Recall/(Precision+Recall)。

补充注意要点

  • 指标需结合业务场景：脱离业务谈“高准确率/召回率”无意义（如模型仅推荐1个候选人且匹配，准确率100%但召回率极低，无实际价值）；
  • 避免样本不均衡影响：若数据集中“正例（匹配）”占比仅5%，模型可能通过“全预测为负例”实现95%准确率，但召回率为0，需通过“样本均衡（过采样/欠采样）”优化。

2. DWM和DWS的区别

考察知识点

  • 数仓分层的核心定位差异（中间加工vs主题汇总）
  • 数据粒度、加工程度、复用性的本质区别
  • 两层在数仓链路中的协同关系（承上启下vs直接输出）

参考回答

DWM（中间数据层）与DWS（汇总数据层）均为数据仓库的核心分层，核心区别在于“加工程度、数据粒度、服务对象”，前者是“通用中间加工站”，后者是“业务主题输出站”，具体对比如下：

对比维度 DWM（中间数据层） DWS（汇总数据层）
核心定位 承上启下的“通用中间加工层”，为上层提供可复用的中间结果 面向业务的“主题汇总层”，直接支撑分析与应用
加工程度 轻度聚合+复杂业务逻辑加工（如用户每小时活跃行为统计、简历技能得分计算） 高度聚合+业务指标汇总（如每日各岗位匹配成功率、候选人地域分布）
数据粒度 中等粒度（介于明细与汇总之间，如user_id+hour（用户+小时）、resume_id+skill（简历+技能）） 粗粒度（按业务主题聚合，如job_id+day（岗位+日）、region+month（地域+月））
复用性 高：一个DWM表支撑多个DWS表/模型（如dwm_candidate_skill支撑“技能匹配模型”“候选人技能分析报表”） 中：一个DWS表对应一个业务主题（如dws_job_match_day仅支撑“岗位匹配效果日报”）
业务逻辑 包含通用业务规则（如“技能熟练度=（项目经验+证书）/2”） 包含定制化业务指标（如“岗位匹配成功率=面试人数/推荐人数”）
示例表 dwm_user_behavior_hourly（用户小时行为表）、dwm_resume_skill_score（简历技能得分表） dws_job_match_day（岗位日匹配效果表）、dws_candidate_region_month（候选人地域月汇总表）

协同关系示例

以AI猎头项目为例：

  • DWM层：dwm_resume_skill_score（简历技能得分表），按“resume_id+skill”粒度存储每个候选人各技能的得分（如Python 5分、TensorFlow 4分），包含通用技能评分逻辑；
  • DWS层：dws_job_match_day（岗位日匹配效果表），基于DWM表数据，按“job_id+day”粒度汇总“推荐人数、匹配成功人数、准确率”等业务指标，直接用于顾问的“岗位匹配效果日报”。

补充注意要点

  • 边界不可混淆：DWM层不做“主题级高度聚合”（如按地域汇总候选人数量），DWS层不做“通用中间逻辑”（如技能评分计算），避免分层职责混乱；
  • 复用性是DWM核心价值：开发DWM表时需考虑“能否支撑多个上层需求”，避免为单一DWS表开发专用DWM表（增加维护成本）；
  • 与AI模型协同：DWM层常为AI模型提供输入特征（如技能得分、行为向量），DWS层则汇总模型输出的业务效果（如匹配成功率）。

3. Hadoop有哪些组件？

考察知识点

  • Hadoop生态的核心组件（分布式存储、计算、资源管理）
  • 各组件的核心功能与协同关系
  • 生态扩展组件的业务场景适配

参考回答

Hadoop生态以“分布式存储+分布式计算”为核心，分为“核心组件”和“生态扩展组件”，前者实现基础存储与计算，后者满足多样化业务需求（如SQL分析、实时计算、NoSQL存储等）。

（1）核心组件（Hadoop 2.x+核心架构）

  1. HDFS（Hadoop Distributed File System，分布式文件系统）：
    1. 功能：解决“海量数据存储”问题，将大文件（如TB/PB级）拆分为128MB/256MB的块（Block），分布式存储在多个DataNode节点，由NameNode管理元数据（文件名、块位置、权限等）；
    2. 架构：主从架构（1个NameNode+多个DataNode+2个SecondaryNameNode（元数据备份）），保证数据高可用（副本数默认3，可配置）；
    3. 适用场景：存储非结构化/半结构化数据（日志、简历、视频等），不适合小文件（元数据管理压力大）。
  2. YARN（Yet Another Resource Negotiator，资源管理器）：
    1. 功能：解决“集群资源调度”问题，统一管理集群的CPU、内存等资源，为计算任务（如MapReduce、Spark）分配资源并调度执行；
    2. 架构：主从架构（1个ResourceManager+多个NodeManager），ResourceManager负责资源分配，NodeManager负责节点资源管理与任务执行；
    3. 核心优势：支持多计算框架（MapReduce、Spark、Flink均可运行在YARN上），提高集群资源利用率。
  3. MapReduce（分布式计算框架）：
    1. 功能：解决“海量数据离线计算”问题，将计算任务分为Map（拆分数据、局部计算）和Reduce（汇总局部结果、输出最终结果）两个阶段，分布式并行执行；
    2. 适用场景：批处理任务（如日志统计、数据清洗、全量数据聚合），不适合实时计算（延迟分钟/小时级）。

（2）生态扩展组件（常用核心组件）

  1. Hive（数据仓库工具）：
    1. 功能：将HDFS上的结构化数据映射为“表”，支持用SQL（Hive SQL）进行查询分析，底层将SQL转化为MapReduce/Spark任务执行；
    2. 适用场景：离线数仓建设（如DWD/DWS层表开发、报表统计），适合非实时的海量数据分析。
  2. HBase（分布式NoSQL数据库）：
    1. 功能：基于HDFS的列存储数据库，支持“随机读写”和“海量数据存储”（亿级行、百万级列），按“行键（RowKey）”快速查询；
    2. 适用场景：实时读写场景（如用户画像标签存储、订单实时查询），不适合复杂SQL分析（无JOIN/GROUP BY等复杂算子）。
  3. ZooKeeper（分布式协调服务）：
    1. 功能：为分布式组件提供“一致性协调”服务，如NameNode高可用（主备切换）、HBase RegionServer管理、任务调度同步等；
    2. 核心能力：分布式锁、配置管理、节点状态监控，保证分布式系统的稳定性。
  4. Flume（日志采集工具）：
    1. 功能：分布式、高可靠的日志采集与传输工具，支持从多源（服务器日志、文件、Socket）采集数据，传输至HDFS/HBase/Kafka等目的地；
    2. 适用场景：日志数据采集（如用户行为日志、应用程序日志），实现“实时采集+批量写入”。
  5. Kafka（分布式消息队列）：
    1. 功能：高吞吐量的消息中间件，用于实时数据传输（如日志、交易数据），支持“发布-订阅”模式，消息持久化存储在磁盘；
    2. 适用场景：实时计算数据接入（如Flink实时任务的数据源）、系统解耦（如业务系统与数仓之间通过Kafka传输数据）。

（3）组件协同示例（数仓数据采集链路）

业务服务器日志 → Flume（采集） → Kafka（缓存削峰） → Spark Streaming/Flink（实时处理）/Hive（离线处理） → HDFS（存储结果）/HBase（实时查询），ZooKeeper协调各组件状态，YARN为计算任务分配资源。

补充注意要点

  • 核心组件与生态组件的依赖：Hive/HBase依赖HDFS存储数据，依赖ZooKeeper实现高可用；Spark/Flink依赖YARN调度资源，依赖Kafka接入实时数据；
  • 组件选型按场景：实时计算选Flink+Kafka，离线数仓选Hive+MapReduce/Spark，实时读写选HBase，日志采集选Flume；
  • 版本兼容性：不同组件版本需匹配（如Hadoop 3.x兼容Spark 3.x，不兼容Spark 2.x），避免因版本冲突导致集群不稳定。

4. MapReduce的过程

考察知识点

  • MapReduce的核心计算模型（分而治之思想）
  • 三阶段（Map/Shuffle/Reduce）的数据流转与任务逻辑
  • 各阶段的核心作用（拆分→分发→汇总）

参考回答

MapReduce是基于“分而治之”思想的分布式离线计算框架，将海量数据计算任务分为Map（映射）、Shuffle（洗牌）、Reduce（归约） 三个阶段，全流程由YARN调度资源，在多个节点并行执行，具体过程如下：

（1）整体架构角色

  • Client：提交计算任务（Jar包/配置参数），查看任务执行状态；
  • ResourceManager：YARN主节点，为Map/Reduce任务分配资源（CPU/内存）；
  • NodeManager：YARN从节点，负责在本节点启动/监控MapTask和ReduceTask；
  • ApplicationMaster：每个MapReduce任务的“总指挥”，负责任务拆分、进度监控、结果汇总。

（2）三阶段详细过程（以“统计简历中各技能出现次数”为例）

假设任务：统计100GB简历数据中“Python”“Java”“TensorFlow”等技能的出现总次数。

  1. 阶段1：Map阶段（拆分数据+局部计算）
    1. 输入数据分片（InputSplit）：
      • 框架将HDFS上的100GB简历数据拆分为多个InputSplit（大小与HDFS块一致，默认128MB），每个InputSplit分配给一个MapTask（并行执行）；
      • 示例：100GB数据拆分为800个InputSplit（128MB/个），启动800个MapTask。
    2. 数据读取与处理：
      • MapTask通过“InputFormat”读取InputSplit数据，将其解析为“键值对（Key-Value）”（如Key=简历ID，Value=简历文本内容）；
      • 执行Map函数：对Value（简历文本）进行分词，筛选出技能关键词，输出局部键值对（如Key=“Python”，Value=1；Key=“Java”，Value=1）。
    3. 输出到本地磁盘：
      • MapTask将输出结果按Key的Hash值分区（默认分为10个分区），临时存储在本节点的本地磁盘（非HDFS，避免网络IO），每个分区对应一个ReduceTask。
  2. 阶段2：Shuffle阶段（数据分发+排序合并，核心环节）
    1. 洗牌（Shuffle）是Map与Reduce之间的“桥梁”，核心是“将Map输出的相同Key的Value分发到同一个ReduceTask，并按Key排序”，分为三个步骤：① Map端排序与合并：MapTask输出时，先在内存缓冲区（默认100MB）按Key排序，缓冲区满后溢写到本地磁盘，形成“溢写文件”；多个溢写文件合并为一个大文件，同时按Key排序；② Reduce端拉取数据：ReduceTask通过“HTTP协议”拉取所有MapTask中对应分区的数据（如ReduceTask 0拉取所有MapTask的分区0数据）；③ Reduce端排序与合并：ReduceTask将拉取的多个Map分区数据合并为一个文件，再次按Key排序（确保相同Key的Value连续），为Reduce计算做准备。
  3. 阶段3：Reduce阶段（汇总计算+输出结果）
    1. 执行Reduce函数：
      • ReduceTask按Key分组，对相同Key的Value列表进行汇总计算（如求和），输出最终键值对（如Key=“Python”，Value=100000；Key=“Java”，Value=85000）；
      • 示例：所有“Python”的Value（1+1+...+1）求和，得到总出现次数。
    2. 输出到HDFS：
      • 通过“OutputFormat”将Reduce输出结果写入HDFS（如/user/hive/warehouse/skill_count），结果文件按ReduceTask数量拆分（如10个ReduceTask输出10个结果文件）。

（3）核心特点

  • 并行性：MapTask与ReduceTask均可在多个节点并行执行，计算效率随节点数增加而提升；
  • 容错性：若某MapTask/ReduceTask失败，ApplicationMaster会自动在其他节点重试（默认重试4次）；
  • 离线性：基于磁盘存储中间结果，适合海量数据批处理，但延迟高（不适合实时计算）。

补充注意要点

  • Shuffle是性能瓶颈：Map与Reduce之间的数据传输（拉取）、排序、合并均涉及磁盘IO和网络IO，需优化（如增大Map内存缓冲区、压缩溢写文件）；
  • ReduceTask数量配置：数量过多会导致小文件过多，数量过少会导致单个ReduceTask处理数据量过大，建议设为“集群CPU核心数的1-2倍”；
  • 不适合实时场景：MapReduce任务启动与Shuffle过程耗时久（分钟/小时级），实时计算需用Flink/Spark Streaming替代。

5. 数据质量监控

考察知识点

  • 数据质量的核心评价维度（准确性、完整性等）
  • 全流程监控体系（事前预防→事中监控→事后审计）
  • 监控工具与自动化闭环逻辑（告警→处理→复盘）

参考回答

数据质量监控是保障数据“可用、可信、及时”的核心手段，通过“全流程管控+自动化工具”，发现并解决数据从采集到应用的各类问题（如空值、异常值、不一致），具体如下：

（1）核心监控维度（六大指标）

维度 定义（以简历数据为例） 监控规则示例
准确性 数据值符合业务逻辑（无错误/矛盾） 工作经验“100年”视为异常，技能得分“6分”（满分5分）视为无效
完整性 核心字段无缺失（无空值/漏字段） 简历表“姓名、手机号、工作经验”字段空值率≤0.1%
一致性 同一数据在不同表中值一致（无冲突） 候选人“手机号”在简历表与面试记录表中完全一致
及时性 数据按预期时间产出（无延迟） 每日简历数据需在凌晨6点前完成清洗并写入DWD层
唯一性 无重复数据（主键/唯一标识不重复） 简历表“手机号+姓名”组合无重复记录（去重率≥99.9%）
合规性 数据符合法律法规（无敏感信息泄露） 手机号中间4位替换为“*”，身份证号加密存储

（2）全流程监控体系

  1. 事前预防（源头控制）：
    1. 规范数据接入：制定《数据源接入规范》，要求业务系统输出数据必须包含“主键、时间戳、字段说明”，避免源头数据格式混乱；
    2. 开发规范约束：数仓ETL脚本必须包含“空值过滤、异常值处理”逻辑（如WHERE 工作经验 < 50），从开发环节减少脏数据。
  2. 事中监控（过程管控）：
    1. 实时任务监控：通过Flink UI监控实时数据采集任务（如Flume/Kafka），设置“数据量波动阈值”（如5分钟内采集量下降50%告警）；
    2. 批处理任务监控：通过Airflow监控Hive/Spark批处理任务，设置“执行时间阈值”（如DWD层任务超4小时未完成告警），失败时自动重试并通知负责人。
  3. 事后审计（结果校验）：
    1. 自动化校验：使用数据质量工具（Great Expectations、Griffin）配置校验规则，每日凌晨自动执行（如校验DWD层简历表的“手机号格式正确性”“工作经验合理性”）；
    2. 生成质量报告：输出《每日数据质量报告》，包含“各表合格率”“异常数据详情”（如简历表有100条工作经验异常数据，涉及5个数据源）；
    3. 问题闭环：对异常数据生成工单，责任人需在2小时内处理（如联系业务方修正数据源），处理完成后验证数据质量，形成“发现-处理-验证”闭环。

（3）常用监控工具与实现

  • 开源工具：Great Expectations（Python库，支持自定义校验规则）、Griffin（Apache项目，适合大规模数仓）；
  • 自研脚本：通过Python/Shell脚本编写校验逻辑（如SQL查询空值率、Python正则校验手机号格式），结合Crontab定时执行，异常时通过企业微信/短信告警；
  • 可视化监控：将校验结果接入Grafana，制作“数据质量仪表盘”，实时展示“各表合格率”“异常趋势”，便于团队快速定位问题。

补充注意要点

  • 监控规则需“业务驱动”：核心字段（如简历“手机号”）的监控规则要严格（空值率0容忍），非核心字段（如“兴趣爱好”）可放宽（空值率≤10%）；
  • 避免过度监控：无需对所有表、所有字段配置监控（如测试表、临时表），聚焦“核心业务表、高频使用表”（如DWD/DWS层表）；
  • 持续迭代规则：业务变化时（如新增“远程办公”岗位需求），需同步更新监控规则（如新增“求职意向-远程”字段的完整性校验）。

6. 数据治理怎么理解？

考察知识点

  • 数据治理的核心定义（全生命周期管理而非单一环节）
  • 治理的核心模块（质量、规范、安全等）与目标
  • 治理与业务价值的关联（从“数据资产”到“业务决策”）

参考回答

数据治理是对企业数据资产进行“全生命周期（采集→存储→加工→应用→消亡）的规范化管理”，核心目标是将“杂乱的数据”转化为“高质量、可信任、易使用的数据资产”，支撑业务决策与数字化转型，而非单一的“数据清洗”或“表下线”。

（1）核心治理模块（五大维度）

This post is for subscribers on the 网站会员 and 成为小万的高级会员 tiers only

Subscribe Now

Already have an account?