[toc]

性能优化

大表join怎么优化

1. 大表过滤前置，减少数据量
2. 合理分区，按时分区裁剪
3. 小表广播join
4. 倾斜key单独打散
5. 开启MapJoin
6. 避免笛卡尔积
7. 拆分复杂SQL，分步执行。

详解

合理分区，按时分区裁剪

拆分复杂SQL，分步执行

[toc]

实时数仓 vs 离线数仓 最全对比 + 面试背诵版

一、核心一句话区别

离线数仓：T+1 / 小时级，批量调度、跑历史数据，用于报表、复盘、画像；

实时数仓：秒 / 分钟级，CDC 增量流式处理，用于大屏、实时指标、实时风控。

二、整体架构对比

离线数仓

• 数据源：MySQL 定时全量 / 增量、日志归档
• 采集工具：DataX、Sqoop、定时调度
• 计算引擎：Hive、Spark
• 存储：HDFS、Hive、Hudi
• 调度：Airflow、Azkaban、DataWorks
• 延迟：小时级 / T+1

实时数仓

• 数据源：MySQL Binlog、实时业务日志
• 采集工具：Flink CDC、Canal
• 缓冲：Kafka
• 计算引擎：Flink
• 存储：Doris、ClickHouse、Hudi、Paimon
• 延迟：秒级～分钟级

三、分层对比（都用 ODS/DWD/DWS/ADS）

离线数仓分层

• ODS：定时批量导入全量 / 增量
• DWD：Spark/Hive 清洗明细
• DWS：离线聚合宽表
• ADS：离线报表、用户标签

实时数仓分层

• ODS：CDC 实时增量进 Kafka
• DWD：Flink 实时清洗、维度关联
• DWS：Flink 窗口实时聚合
• ADS：Doris/ClickHouse 对外实时查询

四、关键维度对比表（直接背）

五、开发方式区别

离线

写 Hive/Spark SQL，定时调度，跑批、重跑方便，逻辑简单稳定。

实时

Flink SQL + CDC + Kafka，要考虑：

水位线、迟到数据、状态管理、数据倾斜、反压、Exactly-Once、幂等去重。

六、优缺点总结

离线数仓优点

• 技术成熟、稳定、易运维
• 可反复重跑、数据精准
• 资源利用率高，夜间跑批不抢占白天业务

离线缺点

• 数据延迟大，不能实时看业务

实时数仓优点

• 数据秒级新鲜，支撑实时决策
• 增量 CDC 同步，不用全量拉表
• 流式处理，适合高并发流量

实时缺点

• 引擎复杂、调优成本高
• 常驻任务，资源占用多
• 要处理乱序、迟到、状态膨胀等问题

七、面试标准口述（直接背）

离线数仓以 Hive+Spark 为核心，采用定时批量抽取、T+1 或小时级调度，适合日报月报、用户画像、业务复盘，数据精准可重跑；

实时数仓基于 Flink+Kafka+CDC 架构，通过监听 MySQL Binlog 做增量同步，秒级延迟，分层实时加工，落地到 Doris/ClickHouse，支撑实时大屏、风控、订单实时指标；

现在企业主流都是离线 + 实时双仓架构，实时看当下、离线做复盘和校准。

八、双仓统一趋势（湖仓一体）

用 Hudi/Paimon 做数据湖，一套数据支持：

• Flink 实时消费

• Spark 离线分析

  实现 流批一体、实时离线统一。

[toc]

doris和clickhouse全方位对比

一、核心定位与架构

• Apache Doris：Apache 顶级项目，标准 MPP 架构（FE+BE），无本地 / 分布式表区分，统一逻辑表，兼容 MySQL 协议与 SQL。
• ClickHouse：ClickHouse Inc. 主导，Shared-Nothing+Scatter-Gather，分 Local 表与 Distributed 表，自研 SQL 方言，依赖 ZooKeeper。

二、数据模型与更新能力

三、查询引擎与性能（2026 基准）

• 单表查询：ClickHouse 略优（极致压缩 + 向量化）；Doris 接近，ClickBench 互有胜负。

• 多表 Join ：Doris 碾压级优势

  • Doris：成熟CBO 优化器，支持 Shuffle/Broadcast/Colocate Join、Runtime Filter；TPC-H 比 CK 快60 倍Apache Doris。
  • ClickHouse：无 CBO，Join 能力弱，复杂查询需 SQL 改写或打平宽表Apache Doris。

• 并发能力：Doris 支持千级 QPS（BI / 报表）；ClickHouse 并发低，高负载易引发 Merge 风暴Apache Doris。

• 实时更新查询：Doris（Unique Key）比 CK（ReplacingMergeTree）快2.5–4.6 倍（ClickBench）VeloDB。




四、写入与实时性

• Doris：

  • 写入：Stream Load/Flink CDC/Routine Load，支持事务性导入（Exactly-Once）。
  • 实时：亚秒级摄入，支持 MySQL Binlog 实时同步，高并发写入稳定。

• ClickHouse：

  • 写入：批量（INSERT/CSV）性能强；并发写易触发 Merge，性能陡降。
  • 实时：依赖 Kafka+MaterializedView，延迟高，更新冲突多。

五、SQL 兼容性与易用性

• Doris：高度兼容 MySQL（协议 + 语法），支持子查询 / CTE / 窗口函数，学习成本低。
• ClickHouse：非标 SQL 方言，窗口函数 / 关联语法特殊，需适配；Local+Distributed 表分离，需手动路由。

六、运维与扩缩容

• Doris：

  • 无外部依赖（无 ZooKeeper），FE/BE 自管理。
  • 自动扩缩容 + 副本平衡，故障自动转移，运维极简Apache Doris。

• ClickHouse：

  • 强依赖 ZooKeeper，部署 / 配置复杂（XML）。
  • 扩容需手动平衡数据，新节点不自动接管负载，运维成本高。

七、湖仓一体与生态

• Doris：原生支持Hive/Iceberg/Hudi/Paimon，可直接查询数据湖，物化视图加速湖仓查询。
• ClickHouse：湖仓集成弱，需自定义开发，兼容性差。

八、适用场景

✅ 选 Apache Doris

• 混合负载：实时报表 + BI 看板 + 即席查询（高并发）。
• 复杂多表关联：星型 / 雪花模型分析、用户行为路径分析。
• 实时更新：交易数据、用户画像、MySQL Binlog 同步。
• 湖仓一体：数据湖查询、流批一体分析。
• 低运维：团队小，希望 “MySQL 式” 易用性。

✅ 选 ClickHouse

• 单表海量分析：PB 级日志、广告点击流、时序数据（大宽表）。
• 极致压缩存储：成本敏感，数据极少更新。
• 离线批量：ETL 后大宽表聚合，无复杂 Join。
• 强定制团队：有能力维护 ZooKeeper、调优 Merge、处理读写不一致。

九、选型总结（一句话）

• Doris：全能型 OLAP，强在多表 Join、实时更新、高并发、易用运维、湖仓一体，适合企业级混合负载与实时分析。
• ClickHouse：单表性能之王，强在极致单表查询、高压缩，适合日志 / 时序 / 离线宽表场景，需接受高运维成本与弱 Join 能力。

[toc]

工具

工具对比

DataProfiler

它的核心价值不在于“验证”数据是否满足预期，而在于**“探索和发现”数据中有什么，尤其在自动识别敏感数据方面非常出色**-7。

下面我们来看看它的几项关键能力：

• 🤖 敏感数据检测：内置深度学习的预训练模型，可高效识别和定位文本中的个人敏感信息，如信用卡号、社保号、邮箱地址等，有助于控制合规风险-7-3。
• 📊 自动化数据概要：能自动完成数据集的概要分析，通过简单的API，即可获得一份包含列名、类型、非空值、唯一值等信息的详细统计报告-6-1。
• 🔌 灵活的数据支持：兼容 CSV、Parquet、Avro、JSON 等多种格式，并支持通过集成 Dask 或 Spark 对大规模数据集进行并行处理--6。
• 🔗 版本比对与合并：这是它很有特色的一项功能。支持对同一数据集在不同时间点的Profile进行比对，生成差异报告来检测数据漂移；也支持将多个Profile文件合并，这在处理按日期分区的数据时尤为方便-7。

⚙️ 技术架构

DataProfiler 提供了一个简洁的 API，其内部架构主要围绕以下几个组件构建：

• 数据读取与自动检测：通过 Data 类自动识别并加载多种格式的数据-1。
• 核心分析器：Profiler 类是核心组件，负责协调分析任务-1。
• 统计计算引擎：负责计算每列的数据类型、直方图、分位数等统计量-1。
• 可插拔的标签器：敏感数据检测模块，用户可以替换或训练自定义模型-3。

📊 工具对比速览

下面将 DataProfiler 与其他常用工具进行对比，方便你评估选择：

✅ 优点与 ⚠️ 局限性

DataProfiler 在特定场景下很有优势，但同时也有一些局限性需要注意：

• ✅ 优点：
  • 易于使用：API 设计简洁，只需几行代码便可快速上手-1。
  • 内存效率高：采用流式处理技术，可以处理远超内存容量的超大数据集-。
  • 企业级品质：由 Capital One 开源并实际使用，稳定性和成熟度有保障-6-7。
• ⚠️ 局限性：
  • 不支持实时监控：它本身是一个分析工具，更像快照而非持续监控系统。但可以将生成的报告集成到监控流程中-3。
  • 静态文件为主：更适合处理静态文件，对数据库的直接连接支持有限。
  • 报告可读性：默认生成的 JSON 报告可能需要配合其他可视化工具展示。

💎 总结：它适合解决什么问题？

综合来看，DataProfiler 是数据工程师和数据科学家在数据探索、数据发现、敏感数据识别和数据漂移检测等场景下的得力助手。

它通常用于数据管道的以下阶段：

1. 数据导入时的快速“体检”：当一个新的数据文件或表被添加到数据湖时，可以使用 DataProfiler 快速了解其结构、统计信息，并自动检查其中是否包含未声明的敏感数据（如 PII）-6。
2. ETL过程中的“把门人”：在处理一个上游来源不可控的数据文件时，可以在 ETL 任务执行前先用它进行分析，一旦发现关键列的空值比例或数据类型发生异常变化，可以立即触发告警或中断任务-6。
3. 机器学习建模前的数据理解：在进行特征工程和模型训练前，利用其生成的可视化报告快速了解数据分布、缺失情况，能帮助数据科学家更快地制定数据清洗和预处理策略-6。

总的来说，DataProfiler 适合在数据生命周期的前期使用，也就是“先探查，后开发”的思路，这一点与其他工具形成了很好的互补。

它通常被用在数据处理管道的前期，也就是在正式开发和测试开始前，先对数据做一个全面的摸底-6。

🗺️ DataProfiler 在整个开发流程中的角色定位

总的来说，DataProfiler 是用在 “先探查，后开发” 的思路里。

它会在项目前期帮你回答“我的数据里到底有什么？有什么风险？”这个问题，并在后期帮你持续监控“我的数据和上个月比，有没有发生奇怪的变化？”。因此，它通常在正式编写数据质量测试用例（如用Great Expectations）之前，以及在数据资产上线后持续运行的监控任务中发挥最大价值。

Great Expectations

dbt测试

[toc]

对比Flink CDC、Flume、DataX 优势，适用场景及项目上常遇到的问题有哪些

这是一份关于 Flink CDC、Flume 和 DataX 这三个数据同步工具的对比分析，我会从核心定位、优势、适用场景以及项目实战中的常见问题这几个方面展开。

📊 核心定位速览

💎 各工具优势与适用场景详解

Flink CDC

Flink CDC（Change Data Capture）的优势在于其全增量一体化的流处理架构。它基于Flink引擎，不仅能实时捕获数据库的增量变更日志（如MySQL的binlog），还能一次性完成历史数据的全量快照读取，并在全量同步完成后无缝切换到增量模式，整个过程无需中断，保证数据一致性-。这使其成为构建实时数据湖、实时数仓和需要低延迟响应的数据管道的理想选择-1。

Flume

Flume 的核心优势在于其专为日志而生的轻量级、高可靠架构。它采用简单的管道（Source-Channel-Sink）模型，稳定且易于部署，是处理非结构化或半结构化日志数据的利器-10。因此，它广泛用于将分散在大量服务器上的应用日志、系统日志、访问日志等汇聚到HDFS、Kafka等中央存储系统中，为后续的离线或实时分析提供原始数据–。

DataX

DataX 的优势在于其高度的可扩展性和对离线批量同步场景的专注。它采用插件化架构，官方支持大量异构数据源（关系型数据库、NoSQL、大数据存储等），通过配置JSON文件即可完成开发，简单稳定-6-20。因此，当需要进行大规模、周期性、对实时性无要求的离线数据迁移、数据备份或T+1数据仓库ETL时，DataX是一个非常成熟可靠的选择--20。

⚠️ 项目实战中的常见问题

这三个工具在落地时也会遇到一些典型问题，以下是常见问题速查表，方便你快速定位和排查。

💎 总结

什么时候选 Flink CDC？

• 需要实时同步数据库变更，延迟要求在秒级甚至毫秒级。
• 数据源为关系型数据库，需要同时处理历史全量数据和实时增量数据。
• 希望利用Flink的流处理能力进行实时计算和清洗。

什么时候选 Flume？

• 数据源是大量的日志文件、网络数据包、系统事件等。
• 目标系统是 HDFS、Kafka、HBase 等大数据生态组件。
• 对数据的实时性有一定要求，但对数据质量（如少量重复、丢失）的容忍度较高。

什么时候选 DataX？

• 任务是离线的、批量的数据迁移，对实时性没有要求。
• 需要在多种异构数据源之间进行数据交换（如MySQL → Hive, Oracle → HBase）。
• 追求工具的稳定性和易用性，希望用简单的配置快速完成数据同步任务。

[toc]

Spark vs Flink 技术选型（面试满分版 + 业务场景怎么选）

一、核心本质区别（先记这句）

• Spark：微批处理，离线计算之王，批量吞吐强、成本低
• Flink：原生流处理，实时计算之王，低延迟、事件时间、Exactly-Once、水位线窗口完善

二、关键维度对比表（直接背）

表格

三、坚决选 Spark 的场景

1. 离线数仓全链路（Hive 数仓分层、日 / 小时级调度）
2. 海量数据批量清洗、迁移、大表全量计算
3. 离线报表、离线指标、用户画像离线标签
4. 数据量大、不要求低延迟、追求低成本高吞吐
5. 历史数据回溯、批量重跑、大规模离线 ETL
6. 团队以 SQL 开发为主、追求简单易维护

四、坚决选 Flink 的场景

1. 实时数仓、实时大屏、实时指标
2. 实时特征计算、推荐 / 广告实时数据流
3. Kafka 实时消费、乱序日志、需要事件时间精准窗口
4. 要求低延迟（秒级甚至毫秒级）
5. 需要严格 Exactly-Once、不丢不重
6. 状态长期存储、窗口计算、迟到数据兜底
7. 实时风控、实时告警、行为实时分析

五、折中场景怎么选

1. 准实时（5~10 分钟延迟）

   可用 Spark Streaming，但现在业界更倾向直接上 Flink，统一流批引擎。

2. 流批一体架构

   直接用 Flink 流批统一，一套代码跑实时 + 离线，不用维护两套引擎。

3. 数据湖 Hudi/Iceberg

   写入、增量消费 Flink 更适配；离线分析 Spark 更强。

六、面试标准口述回答（直接背）

技术选型主要看延迟要求、业务场景、数据量级、一致性诉求：

离线批量、海量 ETL、日级小时级数仓、高吞吐低成本场景选 Spark；

低延迟实时计算、实时大屏、实时特征、乱序日志、事件时间窗口、要求精确一次语义的场景选 Flink；

现在主流架构采用Flink 流批一体，实时离线一套引擎统一开发，离线分析依然用 Spark 做大规模批量查询和报表。

七、最简选型口诀

离线批量、数仓报表 → 选 Spark

实时低延迟、窗口乱序、精准一次 → 选 Flink

流批一体统一架构 → 全站 Flink，离线分析保留 Spark

Spark vs Flink 面试必问 10 道（标准满分答案 直接背）

1. 底层计算模型有什么本质区别？

答：Spark 是微批计算，把流拆成小批量离线任务跑；

Flink 是原生流式计算，一条一条事件持续处理，是真正的流引擎。

2. 延迟对比？

答：Spark 分钟级、小时级，适合离线；

Flink 毫秒 / 秒级低延迟，适合实时大屏、实时指标。

3. 时间语义谁更强？

答：Flink 强很多，原生支持 EventTime 事件时间、Watermark 水位线、迟到数据处理；

Spark 偏向处理时间，事件时间、乱序支持较弱。

4. 窗口功能对比？

答：Flink 窗口完备：滚动、滑动、会话、全局窗口，支持水位线 + 允许迟到 + 侧输出兜底；

Spark 窗口简单，对乱序、晚到数据处理能力差。

5. 数据一致性 Exactly-Once 谁更好？

答：Flink 原生 Checkpoint + 状态后端，天然支持 Exactly-Once；

Spark 只能靠业务幂等、事务兜底，引擎层面支持不彻底。

6. 状态管理能力对比？

答：Flink 内置 RocksDB 状态后端、TTL 过期、增量 Checkpoint，适合长期驻留任务；

Spark 无原生状态，状态只能存在内存或外部存储，不适合复杂实时聚合。

7. 容错机制区别？

答：Spark 基于 RDD 宽窄依赖血统重算，失败重算整个分区；

Flink 基于 Checkpoint 快照，只恢复失败节点最近状态，粒度更细、开销更小。

8. 吞吐和资源开销对比？

答：Spark 批量调度，吞吐更高、资源利用率好、成本低，适合海量离线；

Flink 任务常驻集群，资源长期占用，吞吐略低于 Spark 批处理。

9. 处理乱序、迟到数据谁更强？

答：Flink 靠水位线推进时间，三层处理：水位线等待 + 允许迟到 + 侧输出兜底；

Spark 对乱序不友好，很难保证时间窗口精度。

10. 实际项目怎么技术选型？

答：

离线数仓、批量 ETL、历史回溯、日 / 小时级报表、海量高吞吐低成本 → 选 Spark；

实时大屏、实时特征、实时风控、乱序日志、要求低延迟 + 精确一次 → 选 Flink；

流批一体架构统一用 Flink 做实时 + 离线，复杂离线分析保留 Spark。

Spark Streaming / Structured Streaming / Flink 三者终极对比（面试直接背）

一、核心模型一句话

1. Spark Streaming：纯微批，固定时间切分批次，老旧 API，已淘汰。
2. Spark Structured Streaming：默认微批，API 封装成流，底层还是批次触发；仅 Continuous 模式是真流但生产不用。
3. Flink：原生事件驱动流，来一条处理一条，不是微批。

二、三者对比总表

表格

三、关键细节区别（面试必问）

1. Spark Streaming

• 基于 DStream
• 按批次间隔（如 1s、5s）切分数据
• 没有完善事件时间、水位线
• 不推荐新项目，已过时

2. Spark Structured Streaming

• 基于 DataFrame/Dataset，统一 SQL 编程
• 底层Trigger 触发微批，轮询 Kafka
• 也支持 EventTime、窗口，但乱序、水位线能力远不如 Flink
• 有状态，但无 RocksDB、TTL 能力弱
• 适合简单准实时，不适合复杂乱序、长期状态任务

3. Flink

• 真正事件驱动，不是轮询微批
• 完美支持 Watermark+EventTime + 迟到数据三层处理
• 原生状态后端、RocksDB、增量 CK、状态 TTL
• 低延迟、Exactly-Once、复杂窗口、实时特征首选

四、延迟层级排序

Flink (毫秒级 10ms) < Structured Streaming (百毫秒 100ms) < Spark Streaming (秒级 1000ms+)

五、面试标准口述版

Spark Streaming 是老旧固定微批已淘汰；

Structured Streaming 虽然 API 是流式，默认底层依旧微批轮询触发，延迟和乱序处理能力有限；

Flink 是原生事件驱动流式，支持完善的事件时间、水位线、迟到数据和原生状态管理，低延迟、一致性更好，复杂实时业务优先选 Flink。

六、选型口诀

简单准实时、熟悉 Spark 生态 → 用 Structured Streaming

低延迟、乱序严重、窗口精准、长期状态 → 必选 Flink

老项目 Spark Streaming 直接废弃重构

Spark Structured Streaming是微批处理吗

一句话结论

Spark Structured Streaming 默认还是微批，但从架构设计上伪装成了 “流式”，不是真正的事件逐条处理；只有开启 Continuous 模式才是真正低延迟流。

1. 普通默认模式 —— 依然是微批

Spark Structured Streaming 底层依旧是按固定间隔生成 Batch，

每隔一段时间触发一次 Job，批量处理这段时间的数据。

• 本质：微批调度
• 延迟：百毫秒～秒级
• 缺点：没法做到毫秒级超低延迟，没有真正的事件驱动

2. 和 Flink 本质区别

• Flink：事件驱动，来一条处理一条，原生流式
• Spark Structured Streaming：架构包装成流，底层还是微批轮询触发

3. Spark 有没有真正流式？

有，但极少用：

Continuous 连续处理模式

1

spark.sql.streaming.continuous.execution.enabled=true

• 不再走微批
• 长驻线程持续拉取数据
• 延迟可到 毫秒级
• 缺点：稳定性差、功能阉割、生产基本不用

4. 面试标准口述（直接背）

Spark Structured Streaming 默认底层仍是微批处理，按照固定时间间隔生成批次任务执行，并不是像 Flink 那样事件驱动的原生流式；

虽然 API 设计成流式编程模型，但调度引擎还是微批。只有开启 Continuous 连续模式才是真正低延迟流，但生产稳定性不足，一般不用。

5. 最简总结

• 默认 SSS = 微批
• Flink = 原生流
• SSS Continuous 模式 = 真流，但生产不用

[toc]

机器学习/数据挖掘工程师面试宝典

核心定位：本宝典适配机器学习、数据挖掘工程师全岗位（初级/中级/高级），聚焦面试高频考点、核心技能、项目话术与实操要点，兼顾理论深度与工程落地，帮你快速梳理核心知识、规避面试误区，高效通关各类企业面试（互联网、AI公司、传统行业数字化岗均适用）。

核心原则：面试核心考察「理论基础+工程能力+项目落地+业务理解」，避免只背公式不聊落地，拒绝只讲概念不懂实操，突出“能建模、能落地、能解决业务问题”的核心竞争力。

第一部分：面试核心准备（必做，奠定基础）

一、自我定位与自我介绍（1分钟/3分钟版，直接背）

1. 1分钟精简版（初面/群面适用）

面试官您好，我是XX，有X年机器学习/数据挖掘相关经验，熟练掌握机器学习算法（LR、树模型、深度学习等）、数据处理工具（Python、Spark、Pandas），主导/参与过XX（项目类型，如用户流失预测、推荐系统、异常检测）项目，擅长从业务场景出发，完成数据预处理、特征工程、模型训练、部署落地全流程。我的核心优势是XX（如：擅长特征工程、熟悉分布式建模、能快速定位模型问题），希望深耕XX（方向，如推荐、风控、NLP）领域，助力业务价值落地。

2. 3分钟详细版（复面/技术面适用）

面试官您好，我是XX，毕业于XX院校XX专业，有X年机器学习/数据挖掘工程师工作经验，主要聚焦XX（核心方向，如风控建模、用户画像、时序预测）领域。

技术层面，我熟练掌握：① 算法：逻辑回归、随机森林、XGBoost/LightGBM、CNN/RNN/Transformer等，懂算法原理、调参技巧及适用场景；② 工程工具：Python（Pandas、Scikit-learn、PyTorch/TensorFlow）、Spark（MLlib）、Hive，能处理千万级以上数据，完成分布式特征工程与模型训练；③ 落地能力：熟悉模型部署（FastAPI、TensorFlow Serving）、监控（数据漂移、模型精度）与迭代优化。

项目层面，我主导过XX项目（核心项目），从业务需求拆解、数据采集清洗，到特征工程、模型选型调优，再到上线部署，全程负责，最终实现XX（业务价值，如准确率提升15%、流失率降低10%）。

我注重“算法落地而非单纯调参”，擅长结合业务场景选择合适的模型，解决实际业务痛点，希望能加入贵司，在XX领域持续深耕，创造业务价值。

二、面试核心考察维度（明确重点，针对性准备）

无论初级/中级/高级，面试均围绕以下4个维度考察，优先级：工程落地 > 算法基础 > 项目经验 > 业务理解，不同职级侧重不同：

• 初级岗（1-2年）：侧重基础算法（LR、树模型）、数据处理、简单特征工程，能跑通模型训练流程，懂基础调参。
• 中级岗（3-5年）：侧重特征工程深度、模型调优技巧、项目全流程落地、简单分布式建模，能独立负责项目。
• 高级岗（5年+）：侧重业务建模能力、复杂场景解决方案（如高并发、数据稀疏、多模态）、算法创新与优化、团队协作与技术选型。

第二部分：高频面试考点（分模块，必背+必懂）

模块一：数据预处理与特征工程（面试最高频，占比30%）

一、核心知识点（必背）

1. 数据预处理流程：数据采集 → 数据清洗（缺失值、异常值、重复值） → 数据转换（归一化、标准化、分箱、编码） → 数据划分（训练集/验证集/测试集）。
2. 缺失值处理：
   1. 数值型：均值/中位数/众数填充（适用于正态分布/偏态分布）、插值法（线性/多项式）、模型预测填充（如用LR预测缺失值）；
   2. 类别型：众数填充、新增“缺失值”类别、基于业务逻辑填充（如“未知”）；
   3. 注意：避免直接删除缺失值（易导致样本偏差），需结合业务场景选择填充方式。
3. 异常值处理：
   1. 检测方法：3σ原则、箱线图（IQR）、DBSCAN聚类、Z-score；
   2. 处理方法：删除（异常值极少且无业务意义）、修正（如录入错误）、分箱平滑、盖帽法（替换为临界值）、单独建模。
4. 数据转换：
   1. 归一化（Min-Max Scaling）：映射到[0,1]，适用于距离类算法（KNN、SVM），受异常值影响大；
   2. 标准化（Standard Scaling）：均值为0、方差为1，适用于线性模型（LR、神经网络），降低异常值影响；
   3. 分箱：离散化（等频/等距/聚类分箱），适用于非线性关系、异常值平滑，提升模型鲁棒性；
   4. 编码：类别型特征（One-Hot、LabelEncoder、TargetEncoder、Embedding），避免类别特征有序化误导模型。
5. 特征工程核心：
   1. 特征衍生：基于业务逻辑，构造统计特征（均值、方差、频次）、时间特征（窗口统计、滞后特征）、交叉特征（特征相乘/拼接）；
   2. 特征选择：过滤法（相关性分析、方差分析）、包裹法（递归特征消除RFE）、嵌入法（树模型特征重要性、L1正则）；
   3. 特征降维：PCA（无监督，降维去冗余）、LDA（有监督，保留类别区分度），适用于高维数据（如文本、图像）。

二、高频面试题（标准答案，直接背）

1. 问：归一化和标准化的区别？什么时候用归一化，什么时候用标准化？ 答：核心区别是归一化映射到固定区间[0,1]，标准化映射到均值0、方差1的正态分布； 适用场景：① 归一化：适用于对特征范围有明确要求（如神经网络输入）、距离类算法（KNN、SVM），但受异常值影响大；② 标准化：适用于线性模型（LR、逻辑回归）、深度学习，降低异常值影响，使模型更快收敛。
2. 问：特征选择的目的是什么？常用的特征选择方法有哪些？ 答：目的：减少冗余特征、降低模型复杂度、避免过拟合、提升训练效率、增强模型可解释性； 常用方法：① 过滤法：计算特征与标签的相关性（皮尔逊、斯皮尔曼），剔除低相关特征；② 包裹法：RFE（递归特征消除），逐步剔除不重要特征，验证模型效果；③ 嵌入法：树模型（XGBoost/LightGBM）自带特征重要性，L1正则（Lasso）会使不重要特征系数为0，实现特征筛选。
3. 问：高 cardinality（高基数）特征（如用户ID、手机号）怎么处理？ 答：① 避免直接One-Hot（会导致维度爆炸）；② 采用TargetEncoder（用标签均值编码）、CountEncoder（用频次编码）；③ 嵌入编码（将高基数特征转为低维向量）；④ 结合业务逻辑分组（如手机号归属地、用户ID按注册时间分组），降低基数。
4. 问：数据划分时，为什么要分训练集、验证集、测试集？比例一般怎么设置？ 答：① 训练集：用于模型训练，学习数据规律；② 验证集：用于调参、选择模型，避免过拟合；③ 测试集：用于评估模型最终效果，模拟真实场景，不参与任何调参过程； 比例：常规场景（数据量充足）7:2:1；数据量较少（万级以下）采用交叉验证（K折，K=5/10），替代验证集。

模块二：机器学习算法（核心，占比35%）

一、基础算法（必懂原理+适用场景+调参技巧）

1. 线性模型（LR、线性回归）

• 原理：通过线性组合（y = wx + b）拟合数据，LR用于分类（输出概率），线性回归用于回归（输出连续值）；
• 损失函数：LR（交叉熵损失）、线性回归（MSE均方误差）；
• 正则化：L1（Lasso，特征选择，稀疏解）、L2（Ridge，防止过拟合，平滑解）；
• 适用场景：数据线性可分、需要高可解释性（如风控评分卡）、特征维度不高的场景；
• 调参重点：正则化系数（alpha）、学习率、迭代次数，处理特征共线性（如PCA降维、剔除冗余特征）。

2. 树模型（决策树、随机森林、GBDT、XGBoost、LightGBM）（工业界首选，高频中的高频）

• 决策树：基于特征分裂（信息增益、信息增益比、Gini系数）构建树，易过拟合，可解释性强；
• 随机森林：集成多个决策树（bagging思想），随机采样样本+随机选择特征，抗过拟合、鲁棒性强，适合分类+回归；
• GBDT：梯度提升树（boosting思想），串行训练，每棵树拟合前一棵树的残差，只用一阶导数；
• XGBoost：GBDT的优化版，用到一二阶导数、加入L1/L2正则、支持并行建树、预排序、缺失值自动处理，泛化能力更强；
• LightGBM：工业界首选，直方图优化（减少计算量）、Leaf-wise叶子生长策略（速度快）、内存占用低，原生支持分布式，适合千万级以上样本；
• 调参重点（LightGBM）：学习率（0.01-0.1）、树深度（3-10）、叶子节点数、子采样率、列采样率、正则系数（lambda）、min_child_weight（防止过拟合）。

3. 聚类算法（K-Means、DBSCAN）

• K-Means：无监督，指定K值，迭代优化簇中心，适用于球形簇、数据量较大的场景，缺点是需手动指定K、对异常值敏感；
• DBSCAN：无监督，基于密度（核心点、边界点、噪声点），无需指定K，能识别任意形状簇、过滤异常值，缺点是对密度不均匀数据效果差；
• 适用场景：用户分群、异常检测、数据探索（无标签数据）。

4. 其他常用算法

• SVM：支持向量机，最大化分类间隔，适用于小样本、高维数据（如文本），可通过核函数（线性核、RBF核）处理非线性问题；
• KNN：懒惰学习，无训练过程，基于距离（欧氏距离、曼哈顿距离）分类，适用于小样本、简单场景，缺点是高维数据效果差、速度慢；
• 朴素贝叶斯：基于贝叶斯定理，假设特征独立，适用于文本分类（如垃圾邮件识别）、小样本，速度快、可解释性强。

二、深度学习基础（中级/高级岗必问）

• CNN（卷积神经网络）：核心是卷积层（局部感知）、池化层（降维）、全连接层，适用于图像、空间特征相关场景（如图像分类、目标检测）；
• RNN/LSTM：处理序列数据（文本、时间序列），LSTM解决RNN梯度消失/爆炸问题，适用于时序预测、文本生成；
• Transformer：核心是自注意力机制，并行计算、捕捉全局依赖，是大模型（BERT、GPT）的基础，适用于文本、多模态数据；
• Embedding：将离散特征（如文本、类别特征）转为低维稠密向量，保留特征语义信息，用于推荐、NLP场景。

三、高频面试题（标准答案，直接背）

1. 问：GBDT、XGBoost、LightGBM的区别？工业界为什么首选LightGBM？ 答：① 区别：GBDT串行迭代、只用一阶导数、无正则；XGBoost加入一二阶导数、L1/L2正则、并行建树、处理缺失值；LightGBM用直方图优化、Leaf-wise生长、内存占用低、速度最快，原生支持分布式。 ② 工业界首选LightGBM：训练速度快、内存占用低、精度高、自带正则防过拟合、支持类别特征、原生分布式，适配千万级以上海量数据，适合业务落地（如风控、推荐、流失预测）。
2. 问：过拟合和欠拟合的原因及解决办法？ 答：① 过拟合：模型复杂度过高、样本量不足、噪声过多、特征冗余； 解决：增加训练数据、正则化（L1/L2、Dropout）、树模型剪枝（限制深度、叶子节点数）、早停（监控验证集精度，停止过拟合）、特征筛选（剔除冗余特征）。 ② 欠拟合：模型复杂度过低、特征不足、训练不充分； 解决：增加特征（衍生特征、交叉特征）、提升模型复杂度（如用树模型替代线性模型）、减少正则化、增加训练迭代次数。
3. 问：分类和回归的区别？常用的评估指标有哪些？ 答：① 区别：分类输出离散标签（如0/1、多类别），回归输出连续值（如房价、销量）； ② 分类指标：准确率（Accuracy）、精确率（Precision）、召回率（Recall）、F1值、AUC（衡量模型排序能力，不受样本不均衡影响）、混淆矩阵； ③ 回归指标：MAE（平均绝对误差，抗异常值）、MSE（均方误差，惩罚大误差）、RMSE（均方根误差，与目标值同量纲）、R²（拟合优度，越接近1越好）。
4. 问：样本不均衡怎么处理？（高频，如风控、异常检测场景） 答：① 数据层面：过采样（SMOTE、ADASYN，增加少数类样本）、欠采样（减少多数类样本，避免信息丢失）、合成样本（生成虚拟少数类样本）； ② 模型层面：调整类别权重（如LightGBM的class_weight）、采用合适的损失函数（如Focal Loss，降低多数类样本权重）； ③ 评估层面：不用准确率，重点看少数类的召回率、F1值、AUC。
5. 问：什么是梯度下降？常用的梯度下降方法有哪些？区别是什么？ 答：① 梯度下降：通过计算损失函数的梯度，沿梯度负方向更新参数，最小化损失函数； ② 常用方法及区别： - 批量梯度下降（BGD）：每次用全部样本更新参数，收敛稳定，但速度慢、内存占用大； - 随机梯度下降（SGD）：每次用单个样本更新参数，速度快、有随机性，收敛不稳定； - 小批量梯度下降（Mini-Batch GD）：每次用部分样本（如32、64、128）更新参数，兼顾速度和稳定性，工业界首选。

模块三：工程化与落地能力（面试加分项，占比20%）

一、核心知识点（必懂）

1. 模型部署方式：
   1. 离线部署：批量预测（Spark MLlib），适用于报表生成、标签更新，吞吐量高；
   2. 在线部署：RESTful API（Flask/FastAPI）、gRPC、TensorFlow Serving、TorchServe，适用于低延迟、高并发场景（如实时推荐、在线风控）；
   3. 流式部署：Flink对接消息队列（Kafka），实现实时特征计算+实时预测，适用于时序场景（如实时异常检测）。
2. 模型监控：
   1. 监控指标：数据漂移（特征分布变化）、模型漂移（预测精度下降）、接口延迟、吞吐量、错误率；
   2. 工具：Prometheus+Grafana（可视化监控）、Flink/Spark（实时计算指标）、钉钉/邮件告警；
   3. 处理：数据漂移→重新做特征工程、模型漂移→重新训练模型、延迟过高→优化模型推理速度（如模型量化、剪枝）。
3. 常用工具栈：
   1. 数据处理：Python（Pandas、NumPy）、Spark（SQL、MLlib）、Hive（数仓）；
   2. 模型训练：Scikit-learn、PyTorch、TensorFlow、XGBoost、LightGBM；
   3. 模型管理：MLflow（版本管理、实验跟踪）；
   4. 部署工具：Docker、K8s（容器化部署，支持高并发）、FastAPI。
4. 分布式建模：Spark MLlib（分布式特征工程、模型训练）、LightGBM分布式版，解决海量数据（亿级）训练速度慢的问题。

二、高频面试题（标准答案，直接背）

1. 问：模型从训练到上线的完整流程是什么？ 答：完整流程：业务需求拆解（明确建模目标）→ 数据采集与清洗（处理缺失值、异常值）→ 特征工程（衍生、筛选、转换）→ 样本划分→ 模型选型与训练→ 模型评估（验证集+测试集）→ 模型调优→ 模型导出（ONNX格式）→ 部署上线（API/批量/流式）→ 线上监控→ 模型迭代（定期重训/触发式重训）。
2. 问：线上模型效果变差，怎么排查？ 答：排查顺序：① 数据层面：检查数据源是否变更、特征分布是否发生数据漂移、是否有新的缺失值/异常值；② 模型层面：检查流量结构是否变化（如用户群体变更）、样本分布是否偏移（概念漂移）、模型版本是否有误；③ 工程层面：检查接口延迟、日志异常、部署环境是否变更； 处理方案：补全数据、重新做特征工程、重新训练模型、灰度回滚到上一版本、优化部署环境。
3. 问：如何提升模型的推理速度？（高并发场景必问） 答：① 模型层面：模型剪枝（剔除冗余参数）、模型量化（FP32→FP16/INT8）、模型蒸馏（用大模型训练小模型）；② 工程层面：批量推理、容器化部署（K8s）、负载均衡、缓存热点预测结果；③ 数据层面：优化特征维度（剔除冗余特征）、减少输入数据量。
4. 问：Spark MLlib和Scikit-learn的区别？什么时候用Spark MLlib？ 答：① 区别：Scikit-learn适用于单机、小样本（万级/十万级），API简洁、易上手；Spark MLlib适用于分布式、海量数据（百万级以上），支持大规模特征工程和模型训练； ② 适用场景：当数据量超过单机处理能力（如千万级以上），需要分布式特征工程、分布式训练时，用Spark MLlib；数据量小时，用Scikit-learn快速验证模型。

模块四：业务理解与项目实战（面试核心，占比15%）

一、核心原则（必记）

面试聊项目，重点不是“调了多少参、用了什么算法”，而是“如何从业务出发，用算法解决实际问题，带来什么业务价值”，核心逻辑：业务痛点 → 技术方案 → 落地过程 → 效果复盘 → 优化方向。

二、高频业务场景（适配各类企业）

1. 风控场景：用户逾期预测、欺诈检测，核心指标（召回率、AUC），重点是样本不均衡处理、特征工程（用户行为、消费习惯）；
2. 推荐场景：用户推荐、商品推荐，核心算法（协同过滤、LightGBM、深度学习推荐模型），重点是用户画像、特征工程、实时推荐；
3. 用户运营：流失预测、用户分群、精准营销，核心是特征工程（用户活跃度、消费能力）、模型落地后的运营策略；
4. 时序预测：销量预测、流量预测，核心算法（ARIMA、LSTM、LightGBM），重点是时间特征工程（窗口统计、滞后特征）；
5. NLP场景：文本分类、情感分析、知识库问答（RAG），核心是Embedding、Transformer、RAG架构。

三、项目口述模板（直接套用，适配所有场景）

项目名称：XX（如：基于LightGBM的用户流失预测系统）

1. 项目背景（1句话）：业务侧存在XX痛点（如：用户流失率过高，传统规则筛选准确率低，无法精准挽留），需要通过机器学习模型解决，明确建模目标（如：预测用户流失概率，提升挽留效率）。
2. 技术栈：Python（Pandas、Scikit-learn）、Spark（SQL、MLlib）、LightGBM、FastAPI、Prometheus（监控）。
3. 核心职责（重点，体现个人能力）： - 数据处理：从业务库（MySQL）/数仓（Hive）采集用户行为、消费、活跃度等数据，完成清洗（缺失值、异常值处理）、转换（归一化、分箱）； - 特征工程：构造200+维度特征（统计特征、时间特征、交叉特征），用树模型筛选重要特征，剔除冗余特征； - 模型训练：对比LR、随机森林、LightGBM等模型，最终选择LightGBM（理由：精度高、速度快、适配海量数据），调参优化，模型AUC达到0.88以上； - 工程落地：将模型导出为ONNX格式，封装FastAPI接口，Docker容器化部署，用Prometheus监控数据漂移和模型精度，定期触发重训； - 效果复盘：上线后，流失预测准确率提升XX%，成功挽留XX%的高流失用户，为业务减少XX损失（量化价值）。
4. 项目难点及解决方案（加分项）： - 难点1：样本不均衡（少数类流失用户占比低）；解决方案：采用SMOTE过采样+Focal Loss损失函数，提升少数类召回率； - 难点2：特征维度高、冗余多；解决方案：用LightGBM特征重要性+RFE递归特征消除，筛选核心特征，提升模型速度和精度； - 难点3：线上数据漂移；解决方案：用Flink实时监控特征分布，设置告警阈值，异常时自动触发模型重训。
5. 优化方向（体现思考能力）：① 加入实时特征，提升模型响应速度；② 尝试深度学习模型（如LSTM），结合时序特征优化预测效果；③ 优化部署架构，提升接口并发能力。

四、高频业务题（标准答案）

1. 问：如何用机器学习解决“用户流失预测”问题？ 答：① 业务拆解：明确流失定义（如：30天未登录/未消费），确定建模目标（预测未来7天流失概率）；② 数据采集：用户基础信息、行为信息、消费信息、服务反馈等；③ 数据预处理：处理缺失值（如用中位数填充消费金额）、异常值（如剔除极端消费用户）；④ 特征工程：构造活跃度（近7天登录次数）、消费能力（月均消费）、粘性（连续登录天数）等特征；⑤ 模型选型：对比LightGBM、XGBoost，优先选择LightGBM（适配海量用户数据）；⑥ 样本处理：解决样本不均衡（SMOTE过采样）；⑦ 模型评估：重点看召回率、AUC；⑧ 落地：部署API接口，给运营提供流失用户名单，制定挽留策略；⑨ 监控：定期监控模型效果，触发重训。
2. 问：推荐系统中，协同过滤和基于内容的推荐有什么区别？ 答：① 协同过滤：基于用户/物品的相似性推荐（如“喜欢A的用户也喜欢B”），无需物品特征，适用于冷启动初期，但存在冷启动（新用户/新物品无数据）、稀疏性问题；② 基于内容的推荐：基于物品特征（如商品类别、文本描述）和用户画像，推荐相似物品，解决冷启动问题，但推荐多样性不足；③ 工业界常用“协同过滤+基于内容”混合推荐，兼顾准确性和多样性。

第三部分：面试避坑指南（必看，避免踩雷）

1. 误区1：只背算法公式，不懂落地。面试官更关注“你怎么用算法解决业务问题”，不要只说“我用了LightGBM”，要说明“为什么用、怎么调参、落地后带来什么价值”。
2. 误区2：过度追求复杂模型。工业界80%的业务场景用LightGBM/XGBoost就能解决，不要盲目说“用Transformer、深度学习”，要结合数据量和业务场景选择模型（小样本用简单模型，大样本/复杂场景用复杂模型）。
3. 误区3：忽视数据质量。“数据决定模型上限，算法决定模型下限”，面试时要重点讲数据预处理、特征工程的细节，体现你对数据的重视。
4. 误区4：项目描述没有量化指标。不要说“模型效果很好”，要量化（如AUC从0.7提升到0.88，流失率降低12%），量化指标更有说服力。
5. 误区5：不懂工程化。即使是算法岗，也需要懂基础部署和监控，不要说“我只负责训练模型，部署交给开发”，要体现全流程落地能力（至少懂如何导出模型、封装简单API）。
6. 误区6：造假项目。面试官会追问项目细节（如“特征怎么构造的？调了哪些参数？遇到什么问题？”），造假很容易被拆穿，建议准备真实项目，哪怕是小项目，讲清细节即可。

第四部分：面试准备清单（1-2周突击）

一、理论准备（每天1-2小时）

1. 基础算法：LR、树模型（重点LightGBM/XGBoost）、聚类，掌握原理、损失函数、调参技巧；
2. 特征工程：数据预处理、特征衍生、筛选、转换，熟记各类处理方法的适用场景；
3. 工程化：模型部署、监控、分布式建模，掌握常用工具（Spark、FastAPI）的基础用法；
4. 业务场景：熟悉1-2个核心场景（如风控、推荐），掌握场景化解决方案。

二、实操准备（每天1-2小时）

1. 代码实操：用Python跑通LR、LightGBM训练+评估，手写特征工程代码（缺失值、归一化、分箱）；
2. 工程实操：将训练好的模型封装成FastAPI接口，用Docker简单部署；
3. 项目实操：梳理1-2个真实项目，跑通完整流程（数据处理→特征工程→模型训练→部署），记录关键参数和问题。

三、话术准备（每天30分钟）

1. 背熟自我介绍（1分钟+3分钟版）；
2. 背熟高频面试题标准答案（本宝典中的题目）；
3. 口述项目，练到脱稿流畅，重点讲细节和业务价值；
4. 模拟面试：自己对着手机自问自答，熟悉面试节奏，避免紧张。

第五部分：高频手写代码题（必练，避免临场卡壳）

1. 基础代码：用Pandas处理缺失值、异常值，实现归一化、标准化；
2. 模型代码：用Scikit-learn/LightGBM实现分类/回归模型（如用户流失预测），包含数据划分、训练、评估；
3. 特征工程代码：用Spark SQL做特征统计，用Spark MLlib做特征选择和转换；
4. 部署代码：用FastAPI封装模型接口，实现简单的预测调用。

结尾提示：面试的核心是“展现你的能力匹配岗位需求”，重点突出“能建模、能落地、懂业务”，结合本宝典的知识点和话术，针对性准备，即可高效通关。祝各位面试顺利！

[toc]

数据的一致性 完整详解（贴合数仓面试 + 生产场景）

数据一致性的核心定义是：数据在全生命周期中，始终保持准确、完整、统一、符合业务规则的状态，在不同环节、不同系统、不同时间维度下，不存在矛盾、冲突、偏差、丢失或重复的情况。

它是数据仓库、数据库、分布式系统的核心基础指标，在不同场景下有不同的侧重点，其中数仓场景下的业务一致性，是你面试中需要重点掌握的核心内容。

一、基础层面：数据库事务中的一致性（ACID 中的 C）

这是一致性最原始的定义，也是所有数据系统的底层基础，对应数据库 ACID 四大特性中的Consistency（一致性）。

• 定义：事务执行前后，数据库的完整性约束、业务规则不会被破坏。

• 核心逻辑：一致性是事务的最终目的，原子性、隔离性、持久性都是为了保障一致性而存在的。

• 通俗例子：

  银行转账场景，A 账户给 B 账户转 100 元，事务执行后，A 账户扣 100 元、B 账户加 100 元，两个账户的总金额必须和转账前完全一致，不能出现 A 扣了钱、B 没收到，或者总金额对不上的情况，这就是事务层面的一致性。

二、核心重点：数仓场景下的数据一致性（面试高频考点）

这是你之前数仓面试宝典中反复提到的核心概念，也是企业数仓建设的核心痛点，本质是保证数据在数仓全链路中，业务含义、统计口径、数值结果始终统一，不出现 “报表打架、指标对不上” 的问题。

主要分为 5 个核心维度，覆盖离线 + 实时全场景：

1. 维度一致性（数仓最核心、最基础的一致性）

• 定义：同一个分析维度，在数仓全链路、不同业务线、不同模型中，编码、命名、属性、业务含义完全统一。
• 通俗理解：不能出现 “华东地区” 在订单表中包含安徽，在物流表中不包含安徽；也不能出现 “商品分类” 在 A 报表中是三级分类，在 B 报表中是二级分类的情况。
• 保障方案：建设企业级统一 DIM 公共维度层，全公司所有数仓任务共用同一套维度数据，统一编码、统一属性、统一缓慢变化维处理规则。

2. 指标口径一致性

• 定义：同一个业务指标，在不同报表、不同场景、离线 / 实时链路中，计算逻辑、统计规则、过滤条件完全统一，结果一致。
• 通俗理解：不能出现 “公司日 GMV”，运营报表统计的是 1000 万，财务报表统计的是 800 万；也不能出现实时大屏的 GMV 和次日离线统计的 GMV 偏差超过合理范围的情况，这就是面试中常说的 “报表打架”。
• 保障方案：建设企业级统一指标体系，明确原子指标、派生指标的统一口径；指标计算逻辑下沉到 DWS 公共层，上层报表直接复用，避免重复开发；每日执行离线与实时指标自动对账。

3. 数据链路一致性（全链路数据准确性）

• 定义：数仓中数据从业务源系统接入，经过 ODS→DWD→DWS→ADS 全链路流转后，最终结果和源系统的原始数据保持一致，不丢失、不重复、不篡改。
• 通俗理解：业务库中当日有 100 万条订单数据，数仓 ODS 层必须同步到 100 万条，不能少也不能多；DWD 层清洗后，有效订单数据和源系统的有效订单数完全匹配，不能因为清洗逻辑错误导致数据丢失。
• 保障方案：数据同步时做行数校验、主键去重；ETL 任务配置数据量波动监控；全链路数据血缘追踪，出现偏差可快速溯源。

4. 数据时序一致性

• 定义：数据在时间维度上的统一，保证同一时间切片的数据，在不同计算任务、不同链路中保持一致。
• 通俗理解：离线数仓所有 T+1 任务，都必须基于前一天完整的业务数据计算，不能出现部分任务用了截止 24 点的数据，部分任务只用了截止 23 点的数据；实时数仓中，多流 Join 时，必须基于同一事件时间进度对齐，避免时间窗口不匹配导致的结果偏差。
• 保障方案：离线数仓统一数据切片时间，任务依赖按时间窗口串行调度；实时数仓通过 Watermark 统一事件时间进度，保证多流计算的时间对齐。

5. 分布式系统中的副本一致性

• 定义：在分布式组件（Kafka、HDFS、ClickHouse、Flink）中，同一份数据的多个副本之间，数据内容完全一致，不会出现副本之间数据不同步、丢失的情况。
• 通俗理解：Kafka 的一个 Partition 有 3 个副本，Leader 副本写入的消息，必须同步到所有 Follower 副本，保证 Leader 宕机后，Follower 能接管所有数据，不丢失、不偏差。
• 保障方案：合理设置副本数、ISR 同步规则、ACK 确认机制，保证分布式组件的副本数据同步。

三、数据一致性的核心价值

1. 保证决策的准确性：只有数据一致，管理层和业务方才能基于数据做出正确的业务决策，避免因为指标矛盾导致的决策失误。
2. 降低研发与运维成本：统一的一致性规则，避免重复开发、重复对账，减少指标核对、问题排查的工作量。
3. 规避业务与合规风险：财务、风控等核心场景，数据不一致会直接导致财务核算错误、风控失效，甚至违反监管合规要求。
4. 提升数据可信度：只有持续保证数据一致性，业务方才会信任数据，真正实现数据驱动业务，而不是质疑数据。

四、数仓中保障数据一致性的核心方案（面试可直接背诵）

1. 统一数据模型与规范：基于维度建模建设分层架构，统一公共维度层、统一指标体系、统一命名与开发规范，从架构层面避免一致性问题。
2. 全链路数据质量监控：配置完整性、准确性、一致性、唯一性监控规则，事前拦截脏数据，事中监控数据波动，事后异常告警。
3. 幂等性设计：离线任务采用分区覆盖写入，实时任务采用 upsert / 唯一键去重，保证任务重跑、重启不会导致数据重复，保证结果一致。
4. 事务与精准一次语义保障：离线任务通过 ACID 事务保证写入一致性；实时任务通过 Flink Checkpoint + 两阶段提交，实现端到端 Exactly-Once 语义，避免数据丢重。
5. 定期对账与校验：每日执行离线与源系统对账、离线与实时指标对账，自动检测数据偏差，及时修复。
6. 数据生命周期与版本管理：规范数据更新、回溯的流程，避免随意修改历史数据，保证历史数据的一致性与可追溯性。

[toc]

算法题

1、二分查找算法（海量有序数据快速查询）

面试原题：百亿条有序时间数据，怎么最快查到某条记录？

原理背诵：有序数组，每次取中间值比较，折半缩小范围；时间复杂度O(logN)。

大数据场景：Hive分区查找、索引查询、Doris有序列快速过滤、日志时间检索。

面试话术：海量有序数据优先二分查找，比遍历快得多；数仓中用于分区裁剪、有序索引定位。

2、双指针算法（去重、有序合并、区间判断）

原理：快慢指针、左右指针；一次遍历完成去重、合并、区间筛选。

大数据场景：有序大文件合并、日志去重、连续时间段筛选、行为轨迹分析。

面试举例：两个有序超大日志文件，双指针一趟遍历合并为一个有序文件。

3、链表算法（LRU底层、Flink状态链表）

原理背诵：单向链表、双向链表；插入删除快、查询慢；LRU底层=哈希表+双向链表。

大数据场景：Redis缓存、Flink状态管理、Kafka偏移量链表维护。

4、栈&队列算法（消息积压、任务调度）

栈：后进先出；用于括号匹配、递归回溯、任务回滚。

队列：先进先出；Kafka消息队列、任务排队、流量削峰。

阻塞队列：Flink线程池、Spark资源调度、生产消费模型。

5、递归算法（树形层级、维度层级）

原理：自己调用自己，拆分重复子问题；注意递归深度防止栈溢出。

数仓场景：商品类目层级、地区树形结构、部门层级、血缘溯源。

6、二叉树算法（血缘分析、层级结构）

面试必考：前序、中序、后序、层序遍历。

大数据场景：数据血缘树、任务依赖树、菜单类目树、索引B+树。

面试话术：数据平台血缘分析底层采用二叉树遍历，递归追溯上游依赖表。

7、多路归并算法（海量文件合并）

面试原题：100个有序大文件，合并成一个全局有序文件？

原理：每个文件保留一个指针，最小堆维护最小值；每次取出最小写入结果。

生产场景：Hive合并小文件、日志合并、离线大排序、历史数据规整。

8、频率统计算法（热门商品、热点key排查）

原理：Hash统计频次，结合TopK找出高频key。

数仓用途：倾斜key排查、热点用户、爆款商品、恶意IP限流。

9、雪花算法（分布式唯一ID）

结构背诵：时间戳+机器码+序列号；全局唯一、趋势递增、无重复。

大数据场景：订单ID、埋点日志ID、分布式数据表主键、Flink唯一标识。

10、负载均衡算法（中间件必考）

1. 轮询：均匀分发；
2. 随机：随机分发；
3. 加权轮询：高性能节点多分配；
4. 一致性哈希：固定key固定节点；

场景：Kafka分区分发、Redis集群、服务网关、集群负载。

11、限流三大算法（实时风控、流量压测）

1. 计数器限流：固定时间计数，简单粗暴；
2. 滑动窗口限流：平滑流量，避免临界突刺；
3. 令牌桶：允许突发流量，实时大屏流量控制；

生产场景：埋点日志限流、风控防刷、Kafka流量削峰。

12、字典树Trie（前缀匹配、日志过滤）

原理：字符逐层存储，公共前缀共享节点；查询极快、节省内存。

场景：URL黑名单、敏感词过滤、日志前缀筛选、域名匹配。

13、正则匹配算法（数据清洗）

数仓用途：清洗手机号、身份证、URL、特殊乱码、脏数据过滤；DWD层高频使用。

14、哈希算法（大数据基石）

面试话术：哈希算法将任意长度数据转为定长哈希值；用于去重、分片、加密、路由。

生产应用：shuffle分区、分桶、一致性哈希、布隆过滤器、文件校验。

8、一致性哈希算法（Kafka、Redis、分库分表必考）

面试原题：Kafka分区为什么能保证同一个key发送到同一个分区？扩容为什么不会大量迁移数据？

原理背诵：

1. 构建0~2^32环形哈希环；
2. 节点IP哈希落在环上，数据key哈希顺时针找最近节点；
3. 新增节点只影响相邻一小部分数据，不会全局重分布；
4. 优化：增加虚拟节点，解决数据倾斜、节点不均匀。

大数据应用：Kafka分区路由、Redis集群、分库分表、数据分片。

1、洗牌算法（随机打乱、抽样）

适用场景：用户随机抽样、风控随机打散。

算法思想：从后往前遍历，当前位置与随机位置交换，时间复杂度O(n)。

面试背诵话术：Fisher-Yates洗牌，保证概率均匀、无偏，大数据抽样常用，Hive中order by rand()底层就是洗牌算法。

2、蓄水池抽样算法（海量数据随机取样）

面试原题：亿级数据随机抽取100条，内存放不下全部数据怎么做？

原理背诵：

1. 先初始化蓄水池，放入前k条数据；
2. 遍历后续每条数据，以k/i概率替换蓄水池；
3. 最终每条数据被选中概率相等。

使用场景：Hive抽样、日志随机采样、风控黑名单抽样。

3、数据倾斜算法（高频）

原理话术：数据倾斜本质是hash分区不均匀，热点key落在同一个reduce。解决方案：空值打散、加盐随机、热点key拆分、局部聚合。

4、LRU缓存淘汰算法（Redis、维度缓存必考）

面试原题：Redis缓存满了怎么淘汰？

原理背诵：最近最少使用淘汰，链表维护访问顺序，头部最新、尾部最久未使用；淘汰尾部节点；Redis近似LRU。

数仓场景：Redis缓存维度表、用户画像、热点特征，使用LRU淘汰冷数据。

5、布隆过滤器（去重、黑名单）

面试话术：二进制数组+多个哈希函数；判断一定不存在、不一定存在；优点内存极小；缺点无法删除、存在误判。

业务场景：用户去重、黑名单过滤、日志重复判断。

6、TopK 海量数据求最大/最小K个数（大数据必考）

面试原题：10亿条访问日志，找出访问量最高的100个IP，内存放不下全部数据怎么做？

算法原理（背诵）：

1. 采用小顶堆解决最大TopK；大顶堆解决最小TopK；
2. 维持堆容量为K，遍历全部数据；
3. 堆未满直接放入，堆满后比较堆顶；大于堆顶替换堆顶；
4. 遍历结束堆内即为最大K个数据。

大数据生产应用：热门商品、热点IP、倾斜key排查、流量TOP排行。

面试话术：海量数据求TopK不能全局排序，时间复杂度太高；使用小顶堆，时间复杂度O(nlogK)，内存只保留K个元素，适合超大数据量。

7、位图算法 BitMap（海量去重、状态标记）

面试原题：1亿用户ID，判断用户是否登录，怎么极致节省内存？

原理背诵：

1. 利用二进制bit位存储状态，一个int占4字节可以存32个状态；
2. ID对应下标，存在置为1，不存在置为0；
3. 优点：极度省内存、查询极快；
4. 缺点：ID必须为整型、连续、不能过大。

数仓应用场景：日活用户去重、签到状态、用户黑白名单、用户留存标记。

9、滑动窗口算法（Flink实时必考）

面试原题：Flink滚动窗口、滑动窗口底层原理？

算法原理：

1. 固定窗口大小，不断向前滑动；
2. 滑动步长 < 窗口大小产生数据重叠；
3. 只维护窗口内最新数据，过期数据丢弃；
4. 时间复杂度极低，适合流式实时计算。

业务场景：实时最近1小时交易额、最近30秒流量、实时告警、滑动留存。

10、快速排序（大数据最常用排序、面试手写）

原理背诵：选取基准值，小于基准放左边、大于基准放右边；递归拆分；平均时间复杂度O(nlogn)。

大数据优化点：Hive、Spark底层排序都是优化快排；结合外排序解决磁盘海量数据排序。

面试话术：大数据生产不用冒泡，全部使用快速排序，无序海量数据效率最高。

11、外排序算法（海量大文件排序）

面试原题：一个100G日志文件，内存只有4G，怎么排序？

解题步骤（必背）：

1. 拆分：大文件切分成多个小文件；
2. 内排序：内存中快速排序，生成有序小文件；
3. 归并排序：多路归并，最终输出一个全局有序大文件。

生产应用：Hive大表排序、离线超大日志排序、历史数据规整。

12、中位数算法（海量数据求中位数）

面试原题：十亿条交易金额，求交易中位数，内存放不下？

解法话术：双堆法，大顶堆存前半段、小顶堆存后半段；堆顶即为中位数；海量数据配合分片抽样，近似中位数。

13、贪心算法（数仓指标、资源调度）

原理：每一步只做当前最优选择，不回溯；局部最优推全局最优。

大数据场景：Azkaban调度资源分配、任务优先级、压缩策略、冷热数据存储选型。

14、冷热分离算法（中高级数仓必问）

原理背诵：

1. 热数据：近7天，高频查询，存放SSD、Doris、Kafka；
2. 温数据：近30天，中低频，存放HDFS；
3. 冷数据：超90天，归档、压缩、低成本存储。

生产作用：降低存储成本、提升查询速度、优化集群压力。

15、大数据去重三大算法（面试总结）

1. 布隆过滤器：超大批量、允许误判、不删除；黑名单、日志去重。
2. BitMap位图：整型连续ID、极致省内存；用户签到、日活去重。
3. Hash表：精准去重、占用内存大；中小批量明细去重。

大数据算法面试终极总结（一句话背诵）

1. 抽样：蓄水池抽样、洗牌算法；
2. 去重：布隆过滤器、位图、Hash；
3. 排序：快速排序、外排序；
4. TopK：大小顶堆；
5. 流式：滑动窗口、水位线；
6. 分片：一致性哈希；
7. 优化：贪心、冷热分离。

大数据算法终极分类（一页纸背诵清单）

1、海量数据处理：蓄水池、位图、布隆、外排序、多路归并、TopK

2、分片路由算法：一致性哈希、哈希取模、负载均衡

3、流式实时算法：滑动窗口、水位线、限流、令牌桶

4、基础高频算法：快排、二分、双指针、递归、栈队列、链表

5、工程实用算法：雪花ID、字典树、正则、贪心、冷热分离

6、去重算法三件套：BitMap > 布隆过滤器 > Hash表

算法一页纸极简口诀（面试前10分钟速背）

说明：全部最短口诀，不记原理、不记代码，面试张口就说，专门针对大数据数仓开发。

一、海量数据处理（超大文件、内存不够）

• 洗牌算法：倒序遍历、随机交换、均匀抽样，hive rand()底层。
• 蓄水池抽样：先存k个、概率替换、海量无偏抽样。
• TopK堆排序：大堆求最小、小堆求最大，内存只留k个。
• 外排序：大文件切小文件、内部快排、多路归并。
• 中位数：双堆维护，一大一小，堆顶为中位。

二、去重算法（面试最高频）

• BitMap位图：整型id、bit存状态、极致省内存、不能存大数。
• 布隆过滤器：二进制数组+多哈希、能判不存在、不能删、有误判。
• Hash表：精准去重、占用内存大、中小数据使用。

三、分片&路由（中间件必考）

• 哈希算法：任意长度转定长，分区、分桶、去重全靠它。
• 一致性哈希：环形哈希、新增节点少迁移、kafka、redis用。
• 负载均衡：轮询均匀、加权择优、哈希固定、随机分发。

四、实时流式算法（Flink必考）

• 滑动窗口：窗口固定、步长滑动、数据重叠、统计最近时段。
• 水位线：标记时间、处理乱序、容忍延迟、剔除迟到。
• 限流算法：计数器简单、滑动平滑、令牌桶扛突发流量。
• LRU缓存：哈希+双向链表、淘汰最久未使用、redis底层。

五、基础手撕算法（简单但必问）

• 快排：基准值、左右划分、递归、大数据默认排序。
• 二分查找：有序数据、折半查询、速度最快。
• 双指针：一趟遍历、合并有序、去重、区间筛选。
• 链表：增删快、查询慢、flink状态、偏移量。
• 栈队列：栈后进先出，队列先进先出，消息削峰。
• 二叉树：前中后层序遍历，数据血缘、索引底层。

六、工程实战算法（工作常用）

• 数据倾斜：分区不均、热点key、空值加盐、拆分打散。
• 多路归并：最小堆合并有序文件、hive合并小文件。
• 雪花算法：时间+机器+序号、全局唯一递增id。
• 字典树：前缀匹配、敏感词、url黑名单过滤。
• 贪心算法：局部最优、资源调度、任务优先级。
• 冷热分离：热数据ssd、温数据hdfs、冷数据归档压缩。
• 正则匹配：清洗脏数据、手机号、特殊字符剔除。

七、算法终极顺口溜（背这一段全部拿捏）

海量抽样蓄水池，去重位图布隆池；

分片一致哈希环，实时窗口水位齐；

堆求top快排序，二分指针最简单；

倾斜加盐打散用，冷热归档省机器；

工程雪花唯一id，缓存LRU永不弃。

SQL

面试手写SQL万能模板（直接默写）

1、通用开窗模板

1

row_number() over(partition by 分组字段 order by 排序字段 desc) rn

2、通用去重模板

1
2
3

select * from (
    select *,row_number() over(partition by id order by dt desc) rn
)t where rn=1

3、累计求和模板

1

sum(col) over(order by dt rows between unbounded preceding and current row)

4、分组内占比模板

1

count(1)/sum(count(1)) over(partition by class_id)

高频题目

一、窗口函数

1. 分组取TopN（高频手撕）

业务场景：每个部门薪资最高前2人、每个商品类目销量TOP3。

标准答案SQL：

1
2
3
4
5
6
7
8
9

select * from (
    select 
        dept_id,
        user_name,
        salary,
        row_number() over(partition by dept_id order by salary desc) as rn
    from emp
) t
where rn <= 2;

2. 累计求和（逐月累计）

1
2
3
4
5

SELECT
  month,
  amount,
  SUM(amount) OVER(ORDER BY month) AS total_acc
FROM sales;

3. 移动平均（近 3 日均值）

1

AVG(price) OVER(ORDER BY dt ROWS BETWEEN 2 PRECEDING AND CURRENT ROW)

4. 去重方案（面试追问）

方式1：distinct（少量数据、简单去重）

1

select distinct user_id from log;

方式2：group by（大数据量去重，推荐）

1

select user_id,max(dt) from log group by user_id;

方式3：row_number（复杂条件去重，生产最常用）

1
2
3
4

select * from (
    select *,row_number() over(partition by user_id order by dt desc) rn
    from log
)t where rn=1;

面试话术：生产环境禁止大表distinct，容易触发数据倾斜，优先row_number分组去重。

二、行列转换 面试必写

1. 行转列（多行变一行，逗号拼接）

Hive/Spark SQL

1
2
3
4
5

SELECT
  user_id,
  CONCAT_WS(',', COLLECT_LIST(course)) AS course_list
FROM user_course
GROUP BY user_id;

面试话术背诵：行转列使用collect_list无序聚合、collect_set去重聚合，搭配concat_ws拼接字符串，常用于标签合并、多属性合并。

2. 列转行（一行拆多行）

1
2
3
4
5

SELECT
  user_id,
  course
FROM user_course
LATERAL VIEW EXPLODE(SPLIT(course_list, ',')) tmp AS course;

面试话术背诵：使用lateral view炸裂函数，搭配explode数组拆分，split切割字符串，实现列转行，常用于标签拆分、多维拆解。

三、数据倾斜 SQL 写法（面试高频）

1. 空值 / 大量 NULL 倾斜 优化

1
2
3
4
5
6
7
8

-- 原写法倾斜
WHERE city IS NULL

-- 优化：加盐打散
SELECT *
FROM table
WHERE IF(city IS NULL, CONCAT('rand_', RAND()), city) 
  = IF(city IS NULL, CONCAT('rand_', RAND()), city);

2. Key 热点倾斜 加盐两阶段聚合

1
2
3
4
5
6
7
8
9

-- 第一层：局部聚合加盐
SELECT key, CONCAT(key,'_',CAST(RAND()*10 AS INT)) AS salt_key, COUNT(1) AS cnt
FROM log
GROUP BY key, CONCAT(key,'_',CAST(RAND()*10 AS INT));

-- 第二层：去掉盐全局聚合
SELECT REPLACE(salt_key,'_',SUBSTRING_INDEX(salt_key,'_',-1)) AS key, SUM(cnt)
FROM tmp
GROUP BY REPLACE(salt_key,'_',SUBSTRING_INDEX(salt_key,'_',-1));

3. Join 倾斜优化

• 小表广播 Join：/*+ BROADCAST(small_table) */
• 大表倾斜 Key 单独处理，其余正常 Join，再 Union

1
2
3
4

SELECT /*+ BROADCAST(b) */ a.* 
FROM big_table a
JOIN small_table b 
ON a.key = b.key;

四、经典业务 SQL 真题

1. 连续登录天数（超高频）

思路：日期减去行号，相同即为连续

1
2
3
4
5
6
7
8
9
10
11

# 连续登陆超过3天
SELECT user_id, MIN(dt), MAX(dt), COUNT(1) AS continue_days
FROM (
  SELECT
    user_id,
    dt,
    DATE_SUB(dt, ROW_NUMBER() OVER(PARTITION BY user_id ORDER BY dt)) AS flag
  FROM login_log
) t
GROUP BY user_id, flag
HAVING COUNT(1) >= 3;

2. 留存率计算（次日留存）

需求：计算每日新增用户、次日留存、7日留存。

留存定义：当天新增用户，后续某天再次活跃。

面试话术背诵：留存使用自关联，当天新增表关联未来活跃表；离线留存T+1计算，实时留存使用Flink状态做当日留存。

标准答案SQL：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

# 次日留存
select 
    today.dt,
    count(distinct today.user_id) as new_user,
    count(distinct tomorrow.user_id) as retain_1d
from (
    select dt,user_id from user_new
) today
left join (
    select dt,user_id from user_active
) tomorrow 
on today.user_id = tomorrow.user_id 
and tomorrow.dt = date_add(today.dt,1)
group by today.dt;

# 一段时间内的留存，7天为例

3. 漏斗转化分析（电商、金融必问）

业务：浏览-加购-下单-支付，每一步转化率。

解题思想：同一用户行为路径、判断是否走完下一个节点。

1
2
3
4
5
6

select 
    sum(if(step=1,1,0)) as view_cnt,
    sum(if(step=2,1,0)) as cart_cnt,
    sum(if(step=3,1,0)) as order_cnt,
    sum(if(step=4,1,0)) as pay_cnt
from user_funnel;

面试话术：漏斗核心逻辑是用户行为埋点、行为编号，分层统计人数，计算转化率；大厂一般使用Flink实时漏斗、离线Hive漏斗。

4. 累计指标（日累计销售额、累计用户）

开窗函数 rows between 边界，生产高频。

1
2
3
4
5

select 
    dt,
    sale_amount,
    sum(sale_amount) over(order by dt rows between unbounded preceding and current row) as total_amount
from sale_data;

关键字背诵：unbounded preceding（首行）、current row（当前行）。

大数据 SQL 通用优化口诀（面试背）

1. 尽早过滤：先 where 后 join，减少 shuffle
2. 分组前过滤，聚合少数据
3. 小表广播 Join，避免 shuffle 倾斜
4. 避免 select *，只查需要字段
5. 分区过滤必加，禁止全表扫描
6. 倾斜 Key：加盐打散、局部 + 全局聚合
7. 用好开窗代替子查询，简洁高效

SQL优化高频问答（面试必问）

1. where和having区别？ where分组前过滤，不经过shuffle；having分组后过滤，性能差；优先where过滤。
2. order by底层原理？ Hive两次排序，map端局部排序、reduce端全局排序，数据量大产生磁盘溢写。
3. 开窗函数优缺点？ 优点：减少join、代码简洁；缺点：大数据量分区容易倾斜、内存占用高。
4. 大表关联优化？ 前置过滤、分区裁剪、广播join、倾斜key打散、避免笛卡尔积。