Knowledge

Chapters for every direction the job board covers — engineering, data, design, sales, marketing, operations and more. Every topic shows how many live jobs ask for it. The first chapter is free; a paid plan opens the rest.

Track syllabus

Data Engineering & Analytics

Covers SQL depth, warehouse modeling, ETL/ELT pipelines, data quality, metrics governance, BI, tracking and A/B testing for data roles.

4 chapters · 1686 jobs hiring now

Track progress 0 / 0
01 基础篇 6 topics Free
SQL 窗口函数

窗口函数是 SQL 深挖的入门筛子。面试官想确认你能不能在一条 SQL 里完成分组内的排名、累计与滑动计算,而不是靠多次查询或应用层拼装。

  • PARTITION BY 与 ORDER BY 的分工
  • ROW_NUMBER 与 RANK 的差异
  • 滑动窗口:ROWS 与 RANGE 帧
  • 用窗口函数替代自连接算同比环比
Example answer

我会先说清执行顺序:窗口计算发生在 WHERE 之后、ORDER BY 之前,是在结果集上再算一遍。举我们算用户首单的例子,用 ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY created_at) 取 rn 等于 1,替代了原来的三次自连接,查询从 14 秒降到不到 1 秒;再提一句 ROWS 与 RANGE 在去重累计时的差异,避免重复计数的坑。

SQL 执行计划与慢查询排查

线上慢查询是最常见的动手题。面试官在看你会不会读执行计划、能不能从扫描行数和实际耗时定位瓶颈,而不是直接加索引碰运气。语料里 32% 的岗位明确要求 SQL 与数据库能力。

  • EXPLAIN 与 EXPLAIN ANALYZE 的差别
  • 全表扫描、索引扫描与回表
  • 统计信息与基数估计偏差
  • 大表 JOIN 的顺序与中间结果膨胀
Example answer

我一般先拿 EXPLAIN ANALYZE 看哪一步的估算行数和实际行数差得最多,八成是统计信息过期。印象最深的一次是日报查询 P95 到了 40 秒,发现是两张大表先 JOIN 再过滤,把过滤条件下推、重建复合索引之后降到 1.2 秒,之后再没进过慢查询榜单。

索引与存储结构

考的是你有没有把索引当成有代价的结构来用。只会说加索引不够,要能讲清哪些字段值得建、建完之后写入与存储各付出什么代价。

  • B+ 树索引与覆盖索引
  • 复合索引的最左前缀原则
  • 索引选择性与区分度评估
  • 写放大与索引维护成本
Example answer

我给宽表建复合索引时先看选择性:区分度低的 status 放最后,高基数的 tenant_id 和 created_at 放前面,把查询用到的列全部覆盖、省掉回表。同时讲清代价:这张表每天写入 300 万行,索引从 5 个减到 3 个之后,写入延迟降了约三成,存储也省了 200GB。

维度建模与星型模型

数仓方向必考。面试官在判断你能不能把业务过程翻译成可复用的表结构;粒度没想清楚就动手建表,后面几乎全是返工。

  • 事实表与维度表的职责划分
  • 声明粒度:一行事实代表什么
  • 缓慢变化维 SCD Type 2 的处理
  • 代理键与自然键的选择
Example answer

我通常先从业务过程讲起:问清一行事实代表一次下单还是订单里的一件商品,粒度定了再选维度与度量。我们的交易事实表声明到订单行粒度,用户维度用 SCD Type 2 保留历史归属,用代理键做关联,这样按当时的地域做分析不会串数据。

数仓分层设计

面试官从分层看你的工程习惯:分层不是形式主义,是为了让同一份数据只被加工一次、同一个指标只有一个出口。语料里 36% 的岗位要求数据栈(数仓、Spark、dbt)经验。

  • ODS、DWD、DWS、ADS 的职责
  • 分层如何收敛指标口径
  • 禁止跨层引用与反向依赖
  • 表命名规范与生命周期管理
Example answer

我会讲清我们四层的约定:ODS 只贴源不动数据,DWD 做清洗与维度退化,DWS 按主题轻度汇总,ADS 面向报表。评审时我拦下过 DWD 直接引 ADS 的写法,并要求每张表带 owner 和生命周期。口径收敛之后,同一个 GMV 在三个报表里终于是同一个数。

范式与反范式的取舍

考的是判断力:什么时候该规范化省存储,什么时候该冗余换查询速度。答得好的人先问下游怎么用,而不是背教科书结论。

  • 3NF 与星型模型的适用场景
  • 宽表化的收益与代价
  • 一致性维度与总线架构
  • 多值关系用桥接表拆解
Example answer

我的原则是按消费方式定:面向分析师查询的表适度冗余,把常用维度属性打进宽表;面向高频写入的明细表保持规范化。我们做过一次宽表化,把五张 JOIN 的表合并之后,分析师自助查询从平均 26 秒降到 3 秒,代价是每天多存 12GB,评估后可以接受。

02 管道篇 6 topics Member

The first chapter is free. A paid plan opens the rest.

03 分析篇 6 topics Member

The first chapter is free. A paid plan opens the rest.

04 项目故事篇 6 topics Member

The first chapter is free. A paid plan opens the rest.

A paid plan opens every chapter in this track.

The remaining chapters cover the full knowledge map and a preparation checklist.

See plans

Hiring now

Related jobs hiring now

Roles whose skill requirements overlap with this track. Review a chapter, then check the live openings.