数据仓库与 ETL

• SCD2 的版本历史保留
• 生效/失效日期与当前标志
• 拉链表实现

SCD2（type 2 缓慢变化维）保留维度的历史版本，每次属性变化都新增一条记录，用生效日期（start_date）、**失效日期（end_date）与当前标志（is_current）**标识每条记录的有效期。设计：新属性变化时把旧记录 end_date 设为当前日期、is_current=false，插入新记录 start_date=当前日期、end_date=9999-12-31（或 null）、is_current=true。查询当前状态用 is_current=true，回溯历史用 start_date <= 某日 < end_date。拉链表（zipper table）实现：在 Hive/Spark SQL 中，增量更新时用全量拉链 + 增量合并：①把增量（新变化的维度行）与历史拉链表按主键 join，标记哪些历史记录需要失效（end_date=当前日期）；②插入新的有效记录（基于增量当前值）；③保留未变化的记录。实现可用 left join + case when 或 union 合并，或用 Spark 的 merge（Delta/Iceberg）做 upsert。拉链表在"key 很大但每次变化不多"的场景下能显著减少存储（相比全量快照），同时保留历史。注意需处理：新增记录、属性变化、失效记录三种情况，并保证主键+生效日期唯一。

抓住"SCD2 用起止日期+当前标志保历史"。核心是"拉链表的增量失效+追加"。答题要点到 start/end 日期与 is_current 三要素。

• 事务事实表
• 周期快照事实表
• 累积快照事实表

事实表按用途分三类：事务事实表（Transactional）：每行记录一个业务事件（如一笔订单、一次点击），粒度是"单笔事件"，可精确统计发生次数，适合"发生了什么"的增量分析；周期快照事实表（Periodic Snapshot）：每行记录一个周期（如每天）的累计状态快照（如每日库存、每日账户余额），粒度是"周期+维度组合"，适合"某时刻的状态"分析；累积快照事实表（Accumulating Snapshot）：每行记录一个业务流程的完整生命周期（如订单从下单到发货到完成），用多个阶段时间戳记录各环节，粒度是"一个业务实例"，适合"流程进度/时间差"分析。粒度设计是关键：粒度决定事实表的行数与可分析维度，粒度越细（如单笔事务）事实越精确、可下钻，但数据量越大；粒度应与业务需求匹配（分析到何种最小单位）。设计原则：①明确每行代表什么（事件/周期/流程）；②粒度与事实度量一致（同粒度才可聚合）；③事务表粒度最细、快照表按周期、累积表按实例。选型看分析需求：统计发生次数用事务、查状态用周期快照、看流程用累积快照。

抓住"事务=事件、快照=状态、累积=流程"。核心是"粒度决定可分析性与数据量"。答题要点到三类与粒度的匹配。

• Druid 的实时摄取与查询
• 列式存储与预聚合
• 架构（实时/历史节点）

Apache Druid 是分布式实时 OLAP 数据库，专为"实时摄取 + 低延迟查询"设计。特性：列式存储（按列存储、压缩、段级索引）、预聚合（Rollup）（摄入时按维度聚合，减少存储与查询量）、实时摄取（支持 Kafka 等流式摄入，数据秒级可见）、亚秒级查询（倒排索引 + 位图索引加速过滤）。架构：实时节点（Real-time）/ 摄入服务接收流式数据并生成段，**历史节点（Historical）**存储段并服务查询，Overlord/Coordinator管理分段与负载，Broker 路由查询。查询语法：类似 SQL 的查询（Druid SQL），支持 timeseries、groupBy、topN 等查询类型。与 Hive/Spark 相比，Druid 侧重"实时、交互式、低延迟"的 OLAP 查询（如监控面板、实时报表），而非全量批处理。适用场景：实时指标监控、时序分析、交互式 BI。取舍：Druid 摄入抽象了维度（需设计好维度/度量），对复杂 join 支持弱，适合"事实表 + 低延迟聚合"场景。

抓住"实时摄取 + 列式 + 预聚合 + 低延迟"。核心是"摄入即聚合、查询快"。答题要点到 Segment/段、Rollup、实时节点。

• ETL 与 ELT 的流程顺序
• 转换位置差异
• 适用场景

ETL（Extract-Transform-Load）与 ELT（Extract-Load-Transform）是数据处理的两种流程模式，核心差异在转换（Transform）发生的位置与时序：ETL：先抽取（Extract）→ 在中间层/数据仓库外部转换（Transform）→ 再加载（Load）到目标存储。转换在加载前完成，适合"目标存储不支持复杂转换"或"数据入仓前需清洗标准化"的场景（传统数仓）；ELT：先抽取（Extract）→ 直接加载（Load）到目标数据湖/仓 → 在目标存储内部转换（Transform）。转换在目标内用 SQL/引擎（如 Spark、Snowflake、dbt）进行，适合"云数仓/数据湖 + 计算引擎强大"的场景（现代 Lakehouse）。差异：ETL 转换上游做、数据入仓前已规范、加载的是结果；ELT 原始数据全量入仓（保留原始数据）、转换按需在计算层做、灵活可反噬。适用：ETL 适合数据源复杂、需严格清洗、目标存储弱计算；ELT 适合数据量大、原始数据需保留、目标存储计算能力强、需要灵活探索。现代主流是 ELT（数据湖仓 + 计算引擎强），但复杂清洗仍用 ETL 或在 ELT 中做预处理。

抓住"转换在加载前（ETL）还是加载后（ELT）"。核心是"目标存储计算能力决定选型"。答题要点到 ELT 保留原始数据。

• dbt 的定位（转换层）
• 模型（model）与测试
• 与 ELT 流水线协作

dbt（data build tool）是ELT 中的 T（Transform）工具：它不负责抽取与加载，而是在数据已加载到目标仓库（如 Snowflake、BigQuery、Redshift、Lakehouse）后，用 SQL 定义转换模型（model），在仓库内执行转换。核心概念：Model（模型）：用 SQL 定义的数据转换（一个 select 语句），用 ref/source 引用其他模型或源表，dbt 自动解析依赖、构建 DAG；Materialization（物化）：模型如何存储（view/table/incremental/增量）；Test（测试）：对模型做数据质量校验（唯一性、非空、自定义）；Seed：静态数据加载；Snapshot：SCD2 快照；Macros：可复用 SQL 模板。协作：dbt 让"转换作为代码"管理（版本控制、可测试、可复用），配合 ELT（数据全量入仓 + dbt 在仓内建模），形成"数据全量入湖 + dbt 敏捷建模"的流水线。dbt 与 Spark 可集成（dbt-spark）在 Spark SQL 上跑转换。dbt 的优势是"转换代码化、依赖管理、数据质量测试、可重现"。

抓住"dbt 是 ELT 的 T，用代码化 SQL 建模"。核心是"ref/source 依赖 + 物化 + 测试"。答题要点到 model 与 DAG。

• ODS 原始数据层
• DWD 明细数据层
• DWS 汇总数据层

数仓分层架构把数据按加工程度分层，常用四层：ODS（Operational Data Store，原始数据层）：直接存储业务系统/日志的原始数据，与源一致、不做清洗，作为数据底座；DWD（Data Warehouse Detail，明细数据层）：对 ODS 做清洗、标准化、维度建模（拉宽、规范化），生成明细数据（事实/维度），供业务分析；DWS（Data Warehouse Summary，汇总数据层）：按主题/维度做轻度汇总（如按日、按用户聚合），产出宽表/汇总表，减少重复计算，供查询；ADS（Application Data Store，应用数据层）：面向具体应用/报表/指标的定制化数据（如大屏、报表、推荐结果），可直接被应用消费。分层价值：职责清晰（每层负责特定加工）、数据复用（汇总层复用明细层）、降低重复计算（避免每张报表从头算）、便于追溯（数据血缘清晰）。数据流向：ODS→DWD（清洗建模）→DWS（汇总）→ADS（应用）。设计注意：分层不是越多越好，需平衡开发成本与灵活性；每层用统一命名与元数据管理。

抓住"ODS 原始→DWD 明细→DWS 汇总→ADS 应用"的递进。核心是"分层降低重复计算、职责清晰"。答题要点到各层职责与血缘。

• 命名规范（表/字段/索引）
• 命名一致性
• 可维护性关系

数据建模的命名规范是保证数据可维护性的基础。统一命名规范包括：表命名：常见 层级_主题_业务_粒度（如 dwd_order_detail、dws_user_day），用下划线分隔、小写；字段命名：统一语义（如 order_id、created_at、user_id），避免同义词混用（如既用 user_id 又用 uid）；索引/主键命名：如 pk_表名、idx_表_字段，统一前缀；主题字典：业务术语统一（如"订单""用户"的定义），避免歧义。命名与可维护性的关系：①一致性：统一命名让新开发者无需猜测表/字段含义，降低理解成本；②可追溯：表名含层级与主题，便于按层级检索与血缘追踪；③可维护：变更时能快速定位受影响表；④自动化：规范命名便于工具（元数据、血缘、调度）解析。反之，命名混乱（同义词、无层级、大小写混用）会显著增加维护成本与数据质量问题。规范体现为"命名即文档"——好的命名让结构自明。

抓住"命名规范=可维护性基础"。核心是"统一语义、层级、前缀，降低理解与维护成本"。答题要点到"层级_主题_业务"模式。

• 数据湖 vs 数据仓库
• 存储与处理模式
• 选型与湖仓一体

数据湖（Lake）与数据仓库（Warehouse）是两种数据管理范式。数据仓库：存储已清洗、结构化、经过建模的数据，schema 在写入时定义（schema-on-write），支持强一致事务与 SQL 分析，适合确定的报表/BI；数据湖：存储任意格式（结构化/半结构化/非结构化）原始数据，schema 在读取时定义（schema-on-read），可存海量原始数据，适合灵活探索、机器学习、数据保留。区别维度：数据（仓=结构化建模后，湖=原始任意格式）、schema（仓=写时定义，湖=读时定义）、处理（仓=ETL/严格的 SQL，湖=灵活异步处理）、成本灵活性（湖存储低成本、灵活；仓查询稳定但建模成本高）。选型：需要严格报表、强一致、低延迟 SQL 用数仓；需要海量原始数据、灵活探索、数据挖掘用数据湖。现代趋势是湖仓一体（Lakehouse）：在数据湖上叠加数仓能力（事务、schema、SQL 分析），如 Delta Lake、Iceberg、Hudi，兼顾"湖的灵活性 + 仓的可靠性"。实际常"湖仓分层"：湖存原始、仓存建模结果。

抓住"schema-on-write vs schema-on-read""结构化建模 vs 原始任意"。核心是"存什么/何时定义 schema"。答题要点到湖仓一体。

• 数据血缘的定义与价值
• 血缘的采集方式
• Atlas 的元数据与血缘

数据血缘（Data Lineage）描述数据从源头到目标（表、字段、任务）的链路关系，记录"数据从哪来、到哪去、经过什么转换"。价值：数据追溯（查数据来源与质量）、影响分析（改表/字段影响哪些下游）、合规审计（数据流向可查）、故障定位（加工链路上定位问题）。血缘采集方式：静态解析（解析 SQL/脚本的依赖关系）、动态采集（运行时 hook 捕获血缘）、调度系统上报（从调度平台拿到任务依赖）。Apache Atlas是数据血缘与元数据管理平台：通过hook（如 Hive、Spark、Sqoop、Atlas 的 hook）自动采集元数据与血缘，把血缘关系（Process 实体）存入 Atlas 的图数据库（JanusGraph），提供血缘图查询、影响分析、数据分类、标签与审计。Atlas 与数仓/湖平台集成，展示"表→表"、"字段→字段"的血缘关系，并支持告警（如血缘断链）。工程上，血缘让数据治理可追溯，是数据平台的核心能力。

抓住"血缘记录数据链路+价值追溯影响分析"。核心是"Atlas 用 hook 采血缘、图存储、血缘查询"。答题要点到静态/动态采集。

• 星型模型
• 雪花模型
• 选择与规范化

维度建模（星型/雪花）是数仓建模的经典方法，核心是"事实表 + 维度表"。星型模型（Star）：事实表在中心，围绕若干直接关联的维度表（维度表不拆分），形如星形。查询简单（事实 join 维度表单层）、性能好、符合"先事实后维度"的易用性，是数仓主流。雪花模型（Snowflake）：维度表进一步规范化（拆分子维度表），如"地区"维度拆成"省份-城市"多层，形如雪花。减少冗余、维度更规范，但查询需多层 join、复杂度高、性能略差。选择：星型优先（简单、易查询、性能好），适合大多数 OLAP 场景；雪花适合维度层次复杂、需严格规范化、空间敏感的场景，但现代宽表/冗余存储下雪花优势不明显。工程上常"星型为主、适度维度拆分"。星型/雪花都基于维度建模（事实+维度），区别于 3NF 的规范化建模。设计时注意维度表主键、事实表外键、以及维度表 SCD 处理。

抓住"星型=维度不拆分、雪花=维度规范化"。核心是"星型简单性能好、雪花规范复杂"。答题要点到选型。

• MPP 架构
• Doris/StarRocks 的组件
• 列式与实时 OLAP

Apache Doris 与 StarRocks 都是**MPP（Massively Parallel Processing，大规模并行处理）**架构的实时 OLAP 数据库，面向高并发、低延迟的交互式分析。MPP 架构：数据分片分布到多个节点（BE/CN），查询由协调节点（FE/Catalog）拆分为并行子任务分发到各节点并行执行，结果汇总返回，实现"并行计算、水平扩展"。Doris/StarRocks 组件：**FE（Frontend，前端）**负责 SQL 解析、查询规划、元数据管理、调度；**BE（Backend，后端）**负责数据存储与执行（列式存储、并行扫描、聚合）。StarRocks 进一步引入向量化执行、CBO（成本优化器）、物化视图（异步物化）、主键模型（支持细粒度更新）等。特点：列式存储（压缩、高效扫描）、实时摄入（支持 Kafka 实时导入）、物化视图（预聚合加速）、高并发点查（倒排索引/主键）。适用：实时报表、人口分析、BI、大屏；相比 ClickHouse，Doris/StarRocks 更擅长 join 与事务、多表分析。选型：Mpp 架构的 Doris/StarRocks 是"实时数仓"首选之一。

抓住"MPP 并行分片 + FE/BE 分工 + 列式实时 OLAP"。核心是"并行计算、水平扩展、实时导入"。答题要点到 FE/BE 与物化视图。

• Metastore 元数据存储
• 内部表 vs 外部表
• 外部表与共享数据

Metastore是 Hive 的元数据存储，保存表结构（schema）、分区信息、表与文件的位置映射、SerDe、统计信息等，用关系型数据库（MySQL/PostgreSQL）存储，是 Hive（及 Spark、Flink 通过 Hive Metastore）访问数据的"目录"。外部表（External Table）：表与数据文件解耦，表定义（Metastore）管理，但数据文件存放在外部路径（HDFS/OSS），删除表只删元数据、不删数据文件；内部表（Managed Table）：表和物理数据都由 Hive 管理，删除表会级联删除数据文件。区别核心：数据所有权不同。外部表优势：①数据可共享（其他引擎/外部系统也读写同一文件）；②数据安全（删表不删数据）；③适合"数据在数仓外、只需元数据映射"的场景（如原始数据、共享数据）。用途：ETL 落地、对接外部存储、与 Spark 共享表。Metastore 是"元数据层"，外部表是"数据与元数据解耦"的建模方式，两者是 Hive 体系的核心。

抓住"Metastore 存元数据、外部表数据与元数据解耦"。核心是"删表不删数据=外部表"。答题要点到内部/外部表区别。

• Hudi 的 ACID 与段/文件
• 增量读取（incremental）
• 表类型（COPY_ON_WRITE/MERGE_ON_READ）

Apache Hudi 是增量数据湖框架，在 HDFS/对象存储上提供 ACID 事务、upsert（更新插入）、增量读取等能力，把数据湖从"只读追加"升级为"可更新、可回放"的湖。核心特性：①ACID 事务：通过文件组（file group）+ 基本文件/日志文件实现原子 commit，支持并发写；②upsert/delete：支持按主键更新、删除，解决数据湖"只能追加"的问题；③增量读取（Incremental Query）：支持只消费"上次 commit 之后"的新数据（beginInstant），用于增量 ETL/CDC；④时间旅行（Time Travel）：按 commit 时间查询历史快照。表类型：COPY_ON_WRITE（COW）：更新时重写基本文件，读快、写放大；MERGE_ON_READ（MOR）：更新写入日志文件，读时合并，写快、读需合并。查询类型：快照查询（当前）、读优化查询（COW 的当前、MOR 的已合并）、增量查询。Hudi 与 Spark/Flink 集成，常用于实时入湖、湖表 upsert、增量同步。与 Iceberg/Delta 同为"湖仓一体"表格式三强。

抓住"ACID + upsert + 增量读取"。核心是"COW 写放大 vs MOR 读需合并"。答题要点到增量查询与表类型。

• Iceberg 表格式（Table Format）
• Schema 演进
• 快照与时间旅行

Apache Iceberg 是开放表格式（Open Table Format），定义数据在存储上的组织方式（元数据 + 数据文件清单），提供 ACID、幂等、schema 演进等能力，让数据湖更接近数仓。核心特性：①Schema 演进（Schema Evolution）：支持在表上安全地添加/删除/重命名列、改变列顺序，schema 演进不重写数据（通过元数据记录），兼容性检查保证不破坏已有数据；②快照（Snapshot）与时间旅行：每个 commit 生成一个快照，查询可按快照/时间点读历史数据，支持回滚与增量读取；③ACID 事务：并发写通过乐观锁（基于元数据文件）保证一致性，避免脏读/部分写；④隐藏分区（Hidden Partitioning）：分区由元数据管理，用户无需关心分区键，变换自动分区；⑤与引擎解耦：Iceberg 表可被 Spark、Flink、Trino 等共享访问。表结构：元数据文件（Manifest/Manifest List）描述数据文件，数据文件组织为快照。Iceberg 的"表格式演进"指表 schema、分区、元数据可演进而不重写数据，是它与 Hive 表（schema 变更需重写）的关键区别。常用于数据湖仓、实时入湖、跨引擎共享。

抓住"Schema 演进不重写数据 + 快照时间旅行 + ACID"。核心是"表格式=元数据与数据解耦可演进"。答题要点到隐藏分区。

• 列式存储原理
• MergeTree 引擎
• 压缩与查询性能

ClickHouse 是面向 OLAP 的列式数据库，核心是列式存储：同一列的数据连续存储，而非按行存储。列式存储优势：①查询只读需要的列（OLAP 常只查少数列），大幅减少 IO；②同列数据同类型，压缩率高（如日期、枚举列压缩比可达几十倍）；③向量化执行（SIMD）高效处理列数据。存储引擎：MergeTree系列是核心，按分区+排序键组织，数据以列存（每个列一个文件），分区内按排序键有序，支持合并（merge）与主键索引（稀疏索引）加速范围查询。查询优化：投影/预聚合（如 AggregatingMergeTree、SummingMergeTree 预聚合）、物化视图。特点：超快聚合（group by、count）、高吞吐、单表查询强；但多表 join 弱（分布式 join 需广播/分片）、更新/删除弱（需 mutation，慢）、事务支持弱。适用：时序分析、日志分析、监控、大宽表聚合。取舍：ClickHouse 适合"单表/大宽表 + 聚合查询"，不适合"复杂 join + 高频更新"。

抓住"列式存储 + 只读所需列 + 高压缩 + 向量化"。核心是"MergeTree 分区有序 + 稀疏索引"。答题要点到 join 弱、更新弱。

• 3NF 规范化建模
• DataVault
• Anchor 建模

三种建模方法面向不同需求：3NF（第三范式）建模：通过规范化消除数据冗余（分解表、主外键），保证数据一致性，适合企业级数据仓库（EDW）的"整合层"，但查询需多表 join、建模复杂、冗余低但灵活性受限；DataVault（数据仓库）：区分 Hub（实体的主键）、Link（实体间关系）、Satellite（实体属性/历史），强调可追溯、可扩展、可审计，适合"多源、频繁变更、需长期演进"的数据仓库，建模灵活但初学复杂、查询需多 join；Anchor 建模：更细粒度，把属性拆成 Anchor（锚，实体）、Attribute（属性）、Tie（联系），单个属性一表，极致规范化、可弹性扩展，但表数量爆炸、查询 join 极多，适合"超高变化、超高扩展"的极端场景，工程上少用。选择：需要稳定、查询简单用 3NF/星型；需要可扩展可追溯、多源异构用 DataVault；追求极致规范化扩展用 Anchor（少用）。三者都区别于维度建模（星型/雪花）。

抓住"3NF 规范化、DataVault 的 Hub/Link/Satellite、Anchor 的极致拆分"。核心是"复杂度与扩展性权衡"。答题要点到 DataVault 的追溯性。

• Delta Lake 的 ACID 事务
• 事务日志（transaction log）
• 时间旅行与 schema 演进

Delta Lake 是湖仓一体数据湖框架，在数据文件之上叠加事务日志（transaction log）实现 ACID 表。核心机制：每次写操作（commit）在 _delta_log 目录追加一条 JSON 事务日志，记录数据的增删改（版本号递增），通过乐观并发控制（版本冲突检测）保证并发写的一致性；读时根据最新日志版本读取数据文件，实现原子性。特性：ACID 事务（原子、一致、隔离、持久）、时间旅行（Time Travel）（按版本/时间读历史快照）、Schema 演进（schema 变更管理）、upsert/merge（按主键更新插入）、数据质量约束（CHECK 约束）。相比 Hudi/Iceberg，Delta Lake 与 Spark 集成最紧密（Spark 原生支持），由 Databricks 开源。存储：数据文件（Parquet）+ 事务日志（JSON），表结构由事务日志定义。适用：Spark 生态的数据湖仓、实时/批量入湖、需要 ACID 与时间旅行的湖表。与 Hudi/Iceberg 三选一，都解决"数据湖缺 ACID/更新"问题。

抓住"事务日志实现 ACID + 乐观并发 + 时间旅行"。核心是"_delta_log 记录 commit 版本"。答题要点到与 Spark 集成。

• DolphinScheduler DAG 定义
• 任务节点与依赖
• 参数传递（全局/局部/任务间）

DolphinScheduler 是开源工作流调度平台，用 DAG（有向无环图）定义任务依赖：每个任务是一个节点，节点间通过边定义依赖关系（前驱完成后才执行后继），支持定时触发、失败重试、告警、条件分支等。DAG 定义方式：在 DolphinScheduler 的 Web 界面拖拽任务节点、连线设定依赖，或通过 API/项目文件定义；任务类型支持 Shell、Spark、Flink、SQL、Hive 等。与 Spark/Flink 任务集成时参数传递：①全局参数：在 DAG 或工作流级别定义，所有节点可引用（如日期 dt、环境变量）；②局部参数：在单个节点内定义，供该任务使用；③任务间传递：上游任务可通过输出（如写文件、写变量）传给下游，用 ${var} 引用；④shell 参数：Spark/Flink 任务节点可配置 --conf、--driver-memory、application 参数，通过 ${参数} 动态注入。DolphinScheduler 支持"参数中心"统一管理，任务用占位符 ${...} 引用。参数传递是"作业之间共享调度变量（如日期、路径）"的关键，保证 DAG 各节点协同。

抓住"DAG 定义依赖 + 全局/局部/任务间参数"。核心是"参数占位符 + 调度变量传递"。答题要点到全局参数与任务间传递。

• 数据质量维度（完整性/准确性/一致性/及时性/唯一性）
• 检验方法
• 数据质量治理

数据质量用多个维度衡量，常见维度：完整性（Completeness）：数据是否缺失（空值率、字段缺失率），如必填字段无空值；准确性（Accuracy）：数据是否正确（与真实值/源数据一致，抽样校验、规则校验）；一致性（Consistency）：数据在不同表/系统间是否一致（同一指标不同口径一致、主外键一致性）；及时性（Timeliness）：数据是否按时到达（延迟、调度超时）；唯一性（Uniqueness）：数据是否重复（主键唯一、去重率）；有效性（Validity）：数据是否符合取值范围/格式（枚举、正则）。检验方法：规则校验（脚本/SQL 检查空值、唯一、范围、格式）、抽样与参考比对（与源系统/权威数据对账）、监控告警（阈值触发告警）。数据质量治理：定义质量规则、建立质量监控（如 dbt test、Great Expectations、DataQC）、质量报告与指标、问题追踪与修复。数据质量是数据可信的前提，需在 ETL 中嵌入质量校验并在异常时阻断/告警。

抓住"完整性/准确性/一致性/及时性/唯一性"五大维度。核心是"规则校验 + 监控告警 + 治理"。答题要点到各维度定义。

• ES 的定位与能力
• ClickHouse/Doris 的定位
• 实时写入/聚合/Join 对比

ES 与 ClickHouse/Doris 都是大数据分析引擎，但定位不同：ES强在全文检索、倒排索引、日志检索、半结构化文档，擅长"关键词+过滤+聚合"的检索分析，聚合能力中等（对 text 聚合弱），join 能力弱（不支持真正的多表 join，需 nested/父子或应用层合并），实时写入靠 refresh 近实时；ClickHouse/Doris强在列式聚合、运算分析：ClickHouse 聚合极快（列式+向量化）、单表分析强，但 join 弱（分布式 join 有限）、更新弱；Doris/StarRocks 的 join 能力强（MPP 支持多表 join、主键模型更新）、实时导入与聚合兼顾。选型对比：实时写入：ES 近实时（秒级）、Doris 实时摄入（秒级）、ClickHouse 批量/实时均可；聚合查询：ClickHouse/Doris 列式聚合强于 ES；Join 能力：Doris/StarRocks 最强，ClickHouse 次之，ES 最弱。选择：全文检索/日志检索用 ES；大宽表聚合/时序分析用 ClickHouse；多表 join + 实时报表 / 实时数仓用 Doris/StarRocks。常组合使用（ES 做检索、Doris 做分析）。

抓住"ES 检索、ClickHouse 聚合、Doris join+实时"。核心是"按检索/聚合/join 能力选型"。答题要点到三者的强项。

• 联邦查询（跨数据源）
• connector 架构
• 特点与适用场景

Presto/Trino 是分布式 SQL 查询引擎，核心能力是联邦查询（Federated Query）：通过统一 SQL 访问多个异构数据源（Hive、MySQL、PostgreSQL、Kafka、对象存储、ClickHouse、Iceberg 等）。通过 **connector（连接器）**架构，每个数据源是一个 connector，Presto 的 SQL 引擎把查询下推到各 connector 执行（谓词下推、计算下推），并把结果 join 起来返回，实现"一个入口查所有数据"。特点：无状态（不存数据，只做查询引擎）、跨源 join（join 不同数据源的表）、弹性扩展（worker 节点扩展并行）、生态丰富（支持 SQL 标准、可用 BI 工具）。应用场景：数据湖/仓的交互式查询、跨系统联邦分析（如 MySQL 业务数据 + Hive 日志数据 join）、临时分析。取舍：Presto 是查询引擎，不负责数据存储与 ETL，做过重分析（大聚合）性能不如数仓，且跨源 join 有网络开销；适合"轻量、交互式、跨源"查询。Trino 是 Presto 的后续开源分支（社区版）。

抓住"connector 连接多源 + 统一 SQL + 跨源 join"。核心是"无状态查询引擎、联邦访问"。答题要点到谓词下推。

• 任务依赖（DAG）
• 定时触发与重试
• SLA 监控与告警

DolphinScheduler 与 Airflow 都是工作流调度平台，用 DAG管理任务依赖：每个任务节点依赖其前驱任务，前驱成功后触发后继，支持失败重试、超时、并发限制。任务依赖：①DAG 依赖：节点间连线定义先后/并行关系；②时间依赖：任务依赖上一周期（如 T-1 数据）的完成，用"时间依赖/同周期依赖"；③数据依赖：依赖上游表/数据就绪（如 wait 上游数据）。定时触发：cron 表达式或调度周期（每天/小时），配置任务启停。SLA 监控：①任务监控：任务失败/超时/重试告警（邮件、钉钉、微信）；②流程监控：整体 DAG 的成功率、耗时、阻塞；③依赖监控：上游数据未就绪或上游失败导致下游中断的检测；④SLA 保障：设置任务完成时限，超时告警，保障数据按时产出。Airflow 用 execution_date、depends_on_past、sla 等机制，DolphinScheduler 提供 Web 界面与告警。工程上，调度平台是数仓"准时、可靠"的保障，监控与告警是核心。

抓住"DAG 依赖 + 定时触发 + 失败重试 + SLA 告警"。核心是"依赖与监控保障数据准时产出"。答题要点到时间依赖与 SLA 超时。

• SCD1/2/3 策略
• 各策略适用场景
• Hive/Spark SQL 实现

缓慢变化维（SCD）处理维度属性随时间的缓慢变化，策略：SCD1（覆盖）：直接用新值覆盖旧值，不保留历史，实现简单、存储省，但丢失历史，适合"只关心当前值"的属性（如手机号修正）；SCD2（新增版本）：属性变化时新增一条记录保留历史版本，用生效/失效日期与当前标志标识，适合"需追溯历史"的属性（如地址变更、价格），最常见但存储大、查询复杂；SCD3（新增列）：用额外的"原值/新值"列保留有限历史（如当前值+原值两列），只保最近一次变化，实现简单但历史有限，适合"只保留上一个值"的属性。选型：需要完整历史用 SCD2，只需当前值用 SCD1，只需最近变化用 SCD3。Hive/Spark SQL 实现：SCD1 用 update/insert overwrite（或 Spark 的 merge）覆盖；SCD2 用"增量拉链"（left join 失效旧记录 + 插入新记录）；SCD3 用 update 把旧值移到"原值"列、新值放当前列。Hive 传统用 insert overwrite + 关联实现，Spark/Delta/Iceberg 用 merge（upsert）实现更简洁。实现要点：确定主键、区分"新增/变化/不变"三类记录，并按策略更新。

抓住"SCD1 覆盖、SCD2 版本、SCD3 双列"。核心是"按历史需求选策略"。答题要点到 SCD2 拉链与 merge 实现。