第3章 · 核心技术栈深度解析：数据仓库、数据湖、OLAP引擎、BI工具
面试中，核心技术栈的掌握程度直接决定定级。本章从存储层（数仓/数湖）、计算层（OLAP引擎）到展示层（BI工具），拆解选型逻辑、性能优化与工程落地要点，帮助你在面试中展现系统性技术视野。
📊 知识结构 · 存储层选型对比
| 对比维度 | 数据仓库 | 数据湖 | 湖仓一体 |
|---|---|---|---|
| 数据模型 | Schema-on-Write，结构化 | Schema-on-Read，原始存储 | 统一元数据，ACID 事务 |
| 典型场景 | 固定报表、BI看板、高并发 | AI训练、探索分析、日志存储 | 实时数仓+AI 混合负载 |
| 性能侧重 | 查询快、数据一致性高 | 写入吞吐高、存储成本低 | 读写均衡、弹性扩展 |
| 代表技术 | Snowflake、BigQuery、Greenplum | Delta Lake、Iceberg、Hudi | Databricks、LakeHouse 架构 |
⚙️ 知识结构 · OLAP引擎选型对比
| 对比维度 | ClickHouse | Apache Doris | StarRocks |
|---|---|---|---|
| 核心优势 | 单表聚合极快，列式存储 | 兼容MySQL，高并发，Rollup | 物化视图强，主键模型 |
| 瓶颈短板 | 多表JOIN弱，高并发点查 | 大表JOIN需优化 | 生态较新，社区规模小 |
| 推荐场景 | 日志分析、事件追踪 | 报表BI、用户画像 | 实时数仓、复杂分析 |
| 面试关键词 | 向量化执行、分区裁剪 | 物化视图、Bucket 分桶 | CBO 优化器、Pipeline 执行 |
🎯 面试问题
请详细说明数据仓库与数据湖的核心区别，以及在什么场景下选择数据仓库，什么场景下选择数据湖？
🔍 面试官考察点
- 是否理解两种架构的本质差异（Schema 策略、ACID、存储格式）
- 能否结合业务场景做选型判断，而非死记硬背概念
- 对湖仓一体趋势是否有认知
📋 回答框架
定义对比 → 核心差异（Schema 策略、ACID、查询性能） → 选型场景 → 融合趋势（湖仓一体）
💡 示例回答
数据仓库是 Schema-on-Write，结构化存储，适合高并发 BI 报表；数据湖是 Schema-on-Read，保存原始数据，适合 AI 训练和探索分析。选型上：固定报表、需强一致性选数仓；多源异构、数据探索选数据湖。大型企业建议湖仓一体，兼顾性能与灵活性。
❓ 可能追问
- 湖仓一体的主流实现方案有哪些？（Delta Lake、Iceberg、Hudi 对比）
- 数据湖的 ACID 事务是如何实现的？
- 你们项目中遇到过数据湖的小文件问题吗？怎么解决的？
🎯 面试问题
ClickHouse、Apache Doris、StarRocks 这三个 OLAP 引擎的优缺点对比及选型建议？
🔍 面试官考察点
- 是否深入使用过至少一种引擎，了解其原理和瓶颈
- 技术选型能力：能否根据负载特征做合理判断
- 对引擎生态和社区发展是否有持续关注
📋 回答框架
引擎定位 → 核心优势 → 瓶颈短板 → 选型场景 + 量化指标
💡 示例回答
ClickHouse 单表聚合极快，但多表 JOIN 和高并发点查弱；Doris 兼容 MySQL 协议，支持高并发和 Rollup，适合报表场景；StarRocks 在 Doris 基础上优化了物化视图和主键模型。选型时：日志分析选 ClickHouse，报表 BI 选 Doris/StarRocks，实时大宽表分析优先 StarRocks。
❓ 可能追问
- 你们项目中如何对 OLAP 引擎做性能压测？核心指标看哪些？
- 数据一致性（实时写入 vs 查询可见性）怎么保证？
- 遇到过查询抖动或 OOM 吗？如何排查和优化？
🎯 面试问题
BI 工具（如 Superset、FineBI、Tableau）与底层数仓 / OLAP 引擎集成时，有哪些性能优化手段？
🔍 面试官考察点
- 全链路优化思维：是否从 BI → 引擎 → 存储整体考虑
- 工程落地经验：是否真正处理过慢查询、资源争抢等问题
- 对查询治理、资源隔离、预计算等策略的理解深度
📋 回答框架
查询加速（物化视图） → 缓存策略（结果缓存 / 异步查询） → 预计算（Cube / 汇总表） → 查询治理（超时熔断 / 资源隔离）
💡 示例回答
核心策略：① OLAP 引擎层建物化视图加速聚合查询；② BI 层配置结果缓存和异步查询，避免重复计算；③ 通过查询队列和超时熔断保护集群稳定；④ 固定报表使用预计算 Cube。同时通过审计日志分析慢查询，针对性优化表结构和索引。
❓ 可能追问
- 多租户场景下怎么做查询治理和资源隔离？
- BI 工具直接查询 vs 通过语义层（Semantic Layer）有何优劣？
- 你们是如何做 BI 查询的 SLO 监控和告警的？
🏗️ 项目案例 · 实时数仓 + OLAP 引擎的 BI 决策平台
| 项目名称 | 某电商实时数仓及 BI 决策平台建设 |
| 业务背景 | 大促期间需实时展示 GMV、用户行为漏斗、库存热力图；业务方要求看板延迟 < 5s，支持多维下钻。 |
| 规模指标 | 日增数据量 500 亿条（埋点 + 交易 + 物流），查询峰值 QPS 2000+，存储总量 1.2PB。 |
| 技术栈 | Kafka + Flink（实时 ETL）+ ClickHouse（实时聚合）+ Doris（离线报表）+ Superset（可视化） |
| 核心难点 | ① 实时写入与查询隔离：写入峰值 200MB/s，避免查询抖动；② 大促弹性扩缩容：集群资源按小时级弹性调整；③ 数据一致性：实时流与离线批处理数据对齐。 |
| 面试高频追问 | • 实时 ETL 延迟如何优化？（Flink 算子链、Kafka 分区策略） • 大促期间如何保证 SLA？（查询熔断、分级降级、预留资源） • ClickHouse 与 Doris 数据如何同步？（物化视图 + 定时任务） |
| 可迁移回答话术 | “我们采用 Lambda 架构，实时链路走 ClickHouse 聚合查询，离线链路走 Doris 做深度分析。核心优化点是写入链路使用独立节点组，与查询节点物理隔离，同时通过查询队列控制并发，确保大促峰值时核心看板不受影响。” 此类话术可直接复用到其他实时数仓项目场景。 |