企业官网建设流程全解析

简介：这份资源是面向数据仓库工程师求职者与初入行的数据开发人员整理的一份面试题文档，围绕数据仓库核心概念与工程实践组织内容，可用于面试前的知识梳理与查漏补缺。压缩包内共 1 个 docx 文件，大小约 31KB，篇幅精炼但知识点密集，便于在电脑或手机上直接阅读、检索与二次整理。目前已有一千七百余人学习下载，具备一定的参考热度。内容涵盖数据仓库的主题性、集成性、稳定性与时变性四大特点，ETL 的抽取、转换、加载流程及其日志分类与告警发送方式，Hive、Teradata、Oracle 等常见数据仓库工具的定位，以及 STG、ODS、DW、Presentation 四层模型各自的职责、开发步骤与设计要点，并延伸到数据清洗、规范化、维度表与事实表提交等建模细节。适合用来快速搭建从概念到分层落地的完整知识框架，对照自身薄弱环节做针对性复习。

1. 数据仓库工程师面试：开场十分钟决定的那道概念题

数据仓库工程师的面试有个反直觉的地方：最难的不是拉链表怎么写，而是开场那句「你说说数据仓库和业务库有什么区别」。这题看着像送分，实际是分水岭——答成「一个存历史、一个存当下」，面试官心里会把你归到「用过工具但没建过模」那一档，后面的缓慢变化维、拉链表基本不会再往深里挖。

这场面试真正考三块：概念能不能自圆其说，分层能不能落到每一步具体做什么，建模题能不能给出可执行的方案。分值分布上，概念辨析决定开场十分钟的印象分，四层模型和维度建模撑起中段的主体，拉链表和缓慢变化维是拉开差距的压轴题。适合已经写过 ETL 脚本、但一被追问「为什么这么设计」就卡壳的人，也适合校招想一次把知识点串成线的人。下面按考点顺序拆，每块都落到具体怎么答。

2. 概念辨析：四个特点、ETL 与日志告警的送分答法

2.1 四大特点不要背成四句口号

主题性、集成性、稳定性、时变性，这四条几乎每场必问，但能把它们答出层次的人不多。多数人的问题是只报菜名，不解释「所以」。比较稳的答法是每个特点后面挂一句因果：因为是按主题组织而不是按业务系统组织，所以同一个客户的信息会从多个源系统汇总到一张维度表里；因为要集成多源数据，所以中间必须有 ETL 这一层做抽取、清洗、转换；因为存的是历史快照、不允许改，所以查询只能走分析工具，不能像业务库那样直接 update；因为要定期接收新数据，所以必须有分区、有时间戳、有增量加载策略。

稳定性和时变性常被追问「这不矛盾吗」，这是一道送分的辨析题。答法是把两条落到不同对象上：稳定性说的是已经进入仓库的那条历史记录不改写，昨天的订单金额不会因为今天退款就被覆盖；时变性说的是仓库整体会按周期接收新数据，新的一天产生新分区、新快照。一条记录不动，整张表在长，两者不冲突。能主动把这层说清楚，比背四句定义强得多。

2.2 ETL 三个字母对应的其实是分层职责

Extract 是从数据源读取，Transform 是把原始数据转成期望的格式和维度，在数仓场景里还包括清洗掉噪音数据，Load 是把处理结果加载到目标层。真正容易被追问的是「转换到底转什么」：一是不一致数据转换，比如同一个供应商在结算系统编码是 xx0001、在客户系统是 yy0001，抽过来要统一成一个编码；二是粒度转换，业务库存明细，仓库要按分析粒度聚合；三是业务规则计算，指标不是简单加减，得在 ETL 里算好再落库。

这里有个高频陷阱：面试官问「ETL 和 ELT 有什么区别」，其实在探你对分层和计算位置的理解。稳妥的说法是把重心放在「转换发生在哪一层」——先在暂存区落地再做转换，还是加载后在下游做转换，取决于数据量、源系统压力和目标引擎能力，别硬答哪个更先进。

提示：被问到 Hive 时，答「基于 Hadoop 的数据仓库工具，能对 HDFS 上的文件数据集做查询分析，提供类 SQL 的查询语言，执行时把查询语句转成 MapReduce 任务」就够了，别延伸到自己不熟的执行细节。

2.3 面试题演练：ETL 日志分几类，出错了怎么办

标准答法是三类日志加一套告警：

答完分类要补两句实操。第一句：如果用 ETL 工具，工具本身会自动产生一部分日志，这部分也算日志体系的组成部分，不要另起一套。第二句：出错不只是写日志，还要给系统管理员发告警，常见做法是邮件带上错误信息，方便第一时间定位，避免等到业务方发现报表空了才回头查。

面试官最想听的是「重跑」两个字。日志的价值不只是记录，而是支撑断点续跑和幂等重跑——知道哪一步失败了、影响多少行，才敢只重跑失败的那一段。这句话说出来，比罗列三类日志更能证明你真在生产上跑过任务。

2.4 面试题演练：任务半夜失败，你早上怎么排查

答题顺序建议按「看总体 → 看过程 → 看错误 → 定范围 → 决定重跑方式」走。先看总体日志确认是整体失败还是部分失败，再看执行过程日志找到卡住的那一步和影响行数，然后翻错误日志定位是源表连不上、字段类型不匹配还是主键冲突，接着判断影响范围——是单分区还是多分区、下游有没有已经跑完的任务读到脏数据，最后决定全量重跑还是从失败步骤续跑。

这里有个加分点：主动提到「重跑前先确认目标表这一批数据是否已经部分写入」。如果上一次任务写了一半失败，直接重跑会造成重复数据，正确做法是先按批次或分区删掉本批数据再写，保证幂等。这个细节属于典型的血泪经验，答出来面试官基本会认定你独立维护过任务。

3. 分层落地：STG/ODS/DW/DM 四层职责与开发步骤

3.1 四层职责用一张表说清

分层是数仓面试的中段主菜，面试官往往从「你们分几层」切入，然后逐层往下问。四层的核心差异在于「模型是否和源系统一致」和「做不做转换」：

答这张表的时候要把「作用」带上，因为面试官真正想听的是设计意图。STG 存在的意义是缓冲：源系统压力大、抽取失败要重跑、数据有问题要能追溯，这三点都靠 STG 兜住。ODS 存在的意义是存档：源系统会物理删除数据，如果不在这里留一份全量，历史就永远找不回来了。DW 是建模工作区，DM 是面向分析的出口。分层不是摆样子，每一层都在解决一个具体麻烦。

3.2 STG 层：为什么不做转换，为什么只留几天

STG 层开发有固定的五步：先确定 CDC 策略，根据源系统数据状况选增量还是全量；再设计 mapping 文档；然后设计物理模型，一般包括源系统全部字段加审计字段，审计字段典型有源系统名、源表名、加载时间、加载方式，同时去掉主键、索引、默认值这类约束；接着抽取数据，因为面向异构数据源，优先用支持多数据源的 ETL 工具；最后加载，通常只保留 7 天或一个月的数据。

两个高频追问要提前准备。第一个是「为什么 STG 不做转换」，答法是把职责分离讲清楚：STG 只负责把数据完整搬过来，一旦在这里做转换，出问题时就分不清是抽取错了还是转换错了，排查成本翻倍；不转换还带来一个好处，源系统数据变了可以随时从 STG 重跑下游，不用回头再压源库。第二个是「为什么只留几天」，答存储成本和定位窗口的平衡——STG 是过程数据，不是资产，留够排查和重跑的窗口即可。

还有一个容易漏的点：如果是按日志做实时同步，可以跳过 STG 直接进 ODS。这句话说出来，说明你知道分层不是死规矩，批处理和流处理路径不一样。

3.3 ODS 层：逻辑删除标记和增量时间戳是关键

ODS 层的定位是全量存档，保留源系统的所有历史数据，同时支持下游实时查询和数据质量检查。开发步骤和 STG 类似，但物理模型上有一个关键差异：除了源系统全部字段和审计字段，还要额外加逻辑删除标记和增量时间戳。

为什么要加这两个字段，是这一节最容易被追问的地方。源系统很多会做物理删除，甚至有些系统表面上有逻辑删除标记，后台仍会人工清理数据。ODS 层从 STG 抽取后要做数据比对，发现源端已经不存在的记录就打上删除标记，而不是从表里删掉。这样下游看到的仍然是完整历史，只是状态变了。增量时间戳则给下游增量抽取提供水位线。

被问到「ODS 和 STG 最大的区别」，一句话就能答住：STG 是短周期缓冲、不判删除，ODS 是全量沉淀、要判删除并打时间戳。

3.4 DW 层：数据清洗的四种异常处理策略

DW 层是清洗、规范化、提交一致化维度和事实的工作区，也是整场面试问得最细的一层。数据清洗的第一步不是写 SQL，而是定义质量要求：根据业务需求和数据剖析结果排优先级，再制定测量类型，最后把测量结果落成表。异常数据的处理策略有四类，答的时候要按「在哪处理」分开说：

一类必须中断处理，比如主键重复导致后续加载全乱；一类是把拒绝记录写进错误事件表，不影响主流程继续跑；一类是只做标记、数据继续往下走，适合非关键字段缺失；一类是直接纠正数据，但纠正必须有明确规则，不能凭感觉改。

同样重要的是判断「在哪一层处理」。原则大致是：能在源头解决的必须在源头解决，比如录入格式问题；必须在 ETL 处理的也不推给源头，比如跨系统编码统一；介于两者之间的，优先在源头做，源头改不动才在 ETL 兜底。这段答好了，比背清洗步骤更能体现工程判断。

脏数据本身分三类：不完整的数据，比如供应商名称、分公司名称、客户区域信息缺失，主表和明细表匹配不上；错误的数据，比如数值字段里混进全角字符、前后有不可见字符；重复的数据。处理方式也不一样，不完整的通常过滤出来按缺失内容分文件反馈给业务方补全后再写入，错误的往往只能写 SQL 找出来、要求业务系统修正后重新抽取。

3.5 规范化：把多个源系统的同一件事说成一句话

规范化的目标是把各业务系统里命名、取值各有一套的数据统一成企业标准版本，主要三步。第一步数据标准化，从内容、格式、命名、计算规则上输出唯一版本，最典型的例子就是性别字段：有的系统用 0 和 1，有的用 man 和 women，通过映射表统一成 m 和 f。第二步删除重复数据，源系统内部有重复、或多个源系统维护同一对象时，按保留规则只留唯一一条。第三步数据共存，同一个客户号在两个源系统都有联系方式时，按业务规则决定保留哪个源系统的值，必要时拆分合并。

面试里常被追问「标准化和去重哪个先做」。没有绝对答案，但要有理由：一般先标准化再判重，因为格式不统一时判重会把同一条记录认成两条；如果判重依赖的是业务主键而非文本相似度，顺序影响不大。能给出判断依据，比给出顺序更重要。

3.6 数据抽取：四类源系统四种打法

抽取设计要在调研阶段做足功课：搞清楚数据来自几个业务系统、各系统跑什么类型的数据库、有没有手工数据、手工数据量多大、有没有非结构化数据。落到实现上分四类。与仓库同类型的数据源最省事，直接建连接写查询就能访问。不同类型的数据源，一般通过标准 ODBC 方式建链接；建不了链接的有两条路，一是用工具把源数据导出成文本或表格文件再导入，二是通过程序接口对接。文件类型的数据源，可以培训业务人员用数据库工具先导入指定库再抽取，也可以借助工具实现。最后一类是增量问题，数据量大的系统必须考虑增量，通常用业务发生时间做增量标志，每次抽取前先取目标端最大时间，再取源端大于该时间的所有记录。

-- 按水位线做增量抽取，水位线单独存一张控制表 INSERT INTO stg_order SELECT src.*, '${src_sys_name}' AS src_sys_name, -- 审计列：来源系统 'src_order' AS src_table_name, -- 审计列：来源表 current_timestamp AS load_time, -- 审计列：加载时间 '${load_mode}' AS load_mode -- 审计列：加载方式，增量/全量 FROM src_order src WHERE src.update_time > ( SELECT max_watermark FROM etl_watermark WHERE table_name = 'src_order' ) -- 只取上次水位线之后的数据 AND src.update_time <= '${biz_date} 23:59:59'; -- 卡住上界，避免跨批次重复

这段逻辑的关键在三处。水位线单独存表而不是每次去目标表取 max，是为了避免目标表已经有更晚的数据时把中间一段漏掉；上界必须显式卡住跑批日期，否则同一批数据可能被相邻两个批次各抽一次；审计列在 STG 就要补齐，后面追溯来源全靠它们。参数上，${biz_date}是调度传入的业务日期，${load_mode}用于区分首次全量和后续增量，第一次跑的时候水位线置为一个足够早的时间即可。

3.7 ETL 优化：六条里最容易被追问的三条

优化这块面试官一般不会让你全背，而是挑一两条问原理。减少磁盘 I/O 的做法包括：关联查询前先把无效数据过滤掉、只查需要的列、大数据量尽量避免排序、加载时关闭日志。分区和并行是把大数据量切开，查询和调度都可以并行。增量加载、增加索引、大而化小拆子任务、重用结果集建临时表，是另外四条常规手段。

追问频率最高的是「为什么大数据量尽量不要排序」和「关闭日志不会出问题吗」。前者答排序要落盘、要占用大量内存和临时空间，能靠分区和预聚合规避就别硬排；后者答的是加载阶段的日志开销，属于可控取舍，不是所有环节都关。

4. 维度建模：事实表、维度表与拉链表的必考答法

4.1 事实表四种类型怎么区分

事实表存的是可度量的业务过程结果，通常行数很大，字段以数值和标记为主。四种类型的分辨点是「可加性」：

答题时要补一条设计铁律：一张事实表只能有一个粒度，不能把不同粒度的事实塞进同一张表。这句几乎是必考点的标准答案，因为粒度一混，后续所有聚合口径都会出错，而且错得很难发现。周期快照最典型的例子是账户余额和财务报表，按月粒度记录，跨月不能直接把余额相加。聚合快照适合合同履行、工单流转这类有始有终的过程。

4.2 维度表分类与几种特殊维度

维度表是分析数据的窗口，存放描述性信息、汇总规则和层次结构。常规分类里最常考的是缓慢变化维，此外还有快速变化维、大维与迷你维、退化维。

快速变化维的判断标准是变化频率，比如产品价格、关键词这类维度值增长极快。处理方式按规模分三档：维度字段少、数据量小，用缓慢变化维的类型 2 新增一行旧行置过期；字段多、数据量大，用类型 3 只保留上一个值，否则行数会炸；最糟的是字段多、数据量大、还只有一部分字段频繁变化，这时要把稳定字段和频繁变化字段拆开，变化部分独立成新维度表再与事实表关联。

大维指的是上百万甚至上千万记录的维度，比如客户、产品。大维的麻烦不在存储而在查询：填充数据慢、不带限制的维度浏览慢、带多个限制的属性浏览更慢、与事实表关联查询效率低。应对办法是高效率的设计加正确的索引。迷你维则是从大维里把常用字段抽出来单独成一张小表，查询先走迷你维，命中率高的场景下提速明显。

退化维值得单独说一句：订单号这类本身就在事实表里、没有独立维度表描述的字段，就是退化维。答出这个词，通常能换来面试官点一下头。

4.3 星型与雪花：不是谁先进，是谁更省事

星型模型是事实表被维度表包围，维度表之间不再互相连接；雪花模型是维度表还连着其他维度表，形成层次。星型是非规范化结构，数据有冗余，但正因为冗余，很多统计不需要做外部关联，效率通常更高。雪花减少了冗余，代价是查询要多关联几层。

这一题最容易翻车的地方是把星型说成「一定更快」。正确答法是加限定条件：在冗余可接受、查询以多维分析为主的前提下优先星型；当维度层次复杂且相对静态、存储和一致性要求更高时，用雪花更合适。星型与雪花的区别，本质是维度表直接连事实表，还是通过其他维度表间接连事实表。

4.4 表和加载顺序：引用完整性怎么保证

仓库里的表基本类型有维度表、事实表、子维度表、桥接表。子维度表对应雪花模型里的支架维度，桥接表用来处理多值维度或层级结构。加载顺序由依赖关系决定，原则是：子维度表加载成功后再加载维度表，维度表加载成功后再加载桥接表，这三类都成功后再加载事实表。这个顺序也可以直接由主外键关系推导出来。

追问往往会落到「为什么事实表必须最后加载」。答代理键：事实表里存的是维度表的代理键，维度没加载完，事实表拿不到正确的代理键，要么关联不上，要么关联到错误记录。这里可以顺势带出维度表的默认记录设计——代理键为 -1 的默认行必须存在，首次加载就建好，作用是事实表查找不到对应维度时有个兜底，不至于整行被丢掉或者关联成空。

4.5 缓慢变化维：三种类型的标准答法

这题出现频率极高，答的时候按「怎么变、留下什么、代价是什么」三段说。类型 1 直接覆盖，用新值替换旧值，实现最简单，但不保留历史，只适合纠错场景。类型 2 增加新行，把当前行状态置为失效并写上结束时间，同时新增一行状态有效、起始时间为上一条结束时间加一，历史完整，代价是行数增长、查询要带状态条件。类型 3 增加新列，保留原值的同时多存一个新值，只保留上一次变化，适合变化极少且只关心前后对比的字段。

三种类型不是并列选项，而是按业务对历史的要求来选。答完可以补一句实践倾向：多数维度用类型 2，字段特别多或者只关心最近一次变化的用类型 3，纯粹的录入错误用类型 1 修正。

4.6 拉链表：使用场景、实现方式和优化

拉链表要解决的是一个很具体的矛盾：表很大、部分字段会被更新、还要能查历史某个时间点的状态，但不想每天存一份全量快照。典型场景是十亿级用户表，五十个字段，压缩后单表仍可能上百 G，副本再翻几倍；每天新增和变化的只有很小比例，比如两百万左右；业务又需要查某个订单在某个历史时刻的状态。

实现上先建历史表，带起始日期和结束日期两个字段；再在 ODS 建一张只存当日变化数据的更新表，包含新增和更新；然后用更新表与历史表的交集做封链，把旧记录的结束日期置为当天；最后把更新数据插入历史表，新记录的结束日期置为 9999-12-31，起始日期为当天。

-- 步骤一：关链，把当天发生变化的旧记录封链 UPDATE dw_order_his h SET end_date = date_sub('${biz_date}', 1), -- 结束日期取跑批日期的前一天 is_valid = 0 WHERE h.is_valid = 1 -- 只处理当前有效的链 AND EXISTS ( SELECT 1 FROM ods_order_update u WHERE u.order_id = h.order_id -- 主键相同即视为发生变化 ); -- 步骤二：开链，把当日增量数据作为新链插入 INSERT INTO dw_order_his (order_id, cust_id, order_status, start_date, end_date, is_valid) SELECT u.order_id, u.cust_id, u.order_status, '${biz_date}' AS start_date, -- 新链起始日期为跑批日期 '9999-12-31' AS end_date, -- 开链标记 1 AS is_valid FROM ods_order_update u;

两个参数最容易出错。结束日期取跑批日期的前一天而不是当天，是为了让新旧两条链在时间轴上不重叠，查询某个时间点时不会同时命中两条记录。开链的 9999-12-31 是约定俗成的开链标记，不要用空值，空值在关联和范围查询里会带来一堆判断。另外，判断「是否变化」如果涉及多个字段，要做全字段比对且排除起止日期字段，只比主键会把「主键存在但值没变」的记录也关链重开，白白膨胀。

性能优化有两个思路。一是在查询引擎里对起始日期和结束日期建索引，范围查询能明显提速。二是保留部分历史，全量拉链表留在底层，对外再暴露一张只提供近三个月数据的拉链表，绝大多数查询打不到那张大表上。

4.7 面试题演练：全量加载和增量拉链怎么选

这题考的是加载策略的分辨能力。全量加载是每次拿源表与目标表按主键比对，先删除目标表中在源数据里的相关记录，再整表插入，脚本表现就是先删后插，适合客户信息这类主数据表。增量拉链是把源表当作增量结果处理，数据变化时关旧链、开新链，适合需要保留历史变化的历史表，同样也能处理全量数据。

答题落点要放在「业务要不要历史」和「数据量能不能承受每天全量」这两个判断上。要历史、量又大，只能拉链；不要历史、量不大，全量最省心。答完这两句，再补一句「拉链表在跑批时要保证先关链后开链的顺序，顺序反了会把自己刚插入的记录关掉」，就是能落地的答案。

5. 易错点：五个当场被追问到答不上来的回答

5.1 把 ODS 说成「原始数据堆着就行」

错在哪：只强调 ODS 存全量，不说逻辑删除标记和增量时间戳。为什么错：源系统会物理删除数据，ODS 如果只是被动同步，删掉的历史就再也找不回来，整条数据链断在这里。怎么答对：明确 ODS 是全量存档，从 STG 抽取后要做数据比对，发现源端已不存在的记录打删除标记而不是物理删除，同时补增量时间戳为下游提供水位线。

5.2 拉链表关链条件写成了小于等于当天

错在哪：end_date = 当天，导致新旧两条链在当天这一天重叠。为什么错：查「某天有效」时用start_date <= d and end_date >= d会同时命中两条，数据直接翻倍，这种错在测试环境数据量小的时候根本看不出来。怎么答对：结束日期取跑批日期的前一天，新链起始日期取跑批日期，保证左闭右开或者严格衔接，并统一全表的区间口径。

5.3 星型模型说成「效率一定比雪花高」

错在哪：把「通常更快」说成绝对结论。为什么错：星型的优势来自冗余减少关联，但如果维度层次复杂、冗余带来一致性维护成本，或者查询本身就要跨层聚合，雪花反而更合适。怎么答对：先讲两者的结构差异是维度表是否直接连事实表，再给条件——冗余可接受的多维分析优先星型，层次复杂且相对静态的场景考虑雪花。

5.4 把不同粒度的事实塞进同一张事实表

错在哪：为了省事把订单明细和月度汇总放一张表，或者在一张表里混存交易和快照数据。为什么错：一张事实表只能有一个粒度，粒度混了以后任何一次求和都可能在重复计算，而且错误会一路传到报表上，属于最难回滚的坑。怎么答对：按业务过程建表，交易粒度、周期快照、聚合快照各自独立，聚合层用聚合事实表承载，用粒度声明把边界写清楚。

5.5 增量抽取只看创建时间

错在哪：源表用创建时间做增量标志，忽略了更新。为什么错：订单状态、客户联系方式这类字段是 update 出来的，只按创建时间抽，变更永远进不了仓库，下游看到的都是旧值，而且没人报错，属于最隐蔽的失分点。怎么答对：优先用更新时间做标志，源系统没有时间戳时考虑日志方式或全量比对；同时提醒抽取值要卡上界，避免相邻批次重复抽取。

6. 答题技巧：结论—依据—落地三段式怎么用

数仓面试的题大多不难，难的是答得有条理。我习惯把每道题压成三段：先给结论，一句话说清你的选择；再给依据，讲清楚为什么这么选、别的方案差在哪；最后给落地，说出具体字段、步骤或者脚本层面的动作。三段的比例大致是三成、三成、四成，落地部分最重，因为它证明你不是背书。

三段式最有用的时候是被追问。面试官追问通常不是要你换答案，而是要你补依据或补落地，只要停在第一段不往下走，就容易被问穿。我自己的习惯是每答完一道题，在心里过一遍「这句结论如果被问为什么，我下一句说什么」，说不出来就说明这块只是记住了词，不是真会。

押题方向按概率排一下：数据仓库四大特点与和业务库的区别、ETL 三个环节各自做什么、四层模型的职责与开发步骤、事实表和维度表的类型、星型与雪花的区别与选择、缓慢变化维三种类型、拉链表的使用场景与关链开链写法、表加载顺序与引用完整性、ETL 优化手段。前四个是必答，后五个决定档位。如果时间只够复习一轮，就把拉链表的关链开链手写一遍，这是唯一一道「会就是会、不会编不出来」的题。

从那以后我每次准备面试，都强制走一遍这三段：先把结论写成一句话，再逼自己补两条依据，最后找一个能写出来的落地动作。写不出来的地方就是漏洞，补上再去面，比反复看资料有用得多。希望帮到你。

本文还有配套的精品资源，点击获取