SELECT * FROM world
{ "petabytes": 1e15 }
map → shuffle → reduce
∑ data = insight
0110 1010 1101
A Visual Introduction · 2026
走进 大数据 的世界
用最贴近生活的比喻，理解最庞大的技术体系。
从「为什么重要」到「它是什么」，一次看明白。
20 张幻灯片
2 个交互演示
0 行术语堆砌
按 → 或 Space 开始
made by 刘梓枫
以下内容仅为本人主观判定 · 欢迎交流
PART · 01
01
大数据 为什么重要?
不是因为数据"大"。
是因为当数据足够大、足够全、足够新，
它会从「记录」变成「决策」。
指标产出
数据洞察
智能决策
三大核心价值 · The Three Pillars
数据，是企业的 第二大脑
数据系统每天默默做着三件事——量出企业的现在、看见看不见的规律、替我们做更好的选择。
指标观测
把企业的「生命体征」量化。日活、留存、GMV、转化率——告诉你昨天发生了什么，今天发展得如何。
REPORT
数据洞察
从亿级行为里挖出肉眼看不见的规律。机器学习、深度学习——把"经验"变成可复制、可放大的能力。
INSIGHT
智能决策
当 51% 的优势被反复利用，结果会发生质变。数据是把模糊直觉变成可证明、可累计优势的方式。
DECIDE
价值 #1 · 指标产出 & 长期观测
大数据是企业的 体检报告
没有体检报告，你只能凭"感觉良好"判断身体好坏；没有数据指标，公司只能凭"老板拍脑袋"判断业务好坏。
短期 — 每日健康码。异常告警、活动效果、AB 实验显著性，第二天就要看。
长期 — 一年体检趋势。用户增长曲线、品类渗透、季节性规律，按周/月/年回看。
为什么需要"大"数据？
1 万用户的指标，Excel 就够了；
1 亿用户、1 秒一次行为、要看 3 年——单机数据库会原地爆炸。
价值 #2 · 数据洞察
大数据是企业的 侦探
人类一次看不完 10 亿条记录，但模型可以。机器学习就是"让数据自己说话"——从海量样本里学到一个看不见的规则。
ML / DL
网络安全 · 异常检测
广告 · CTR 预估
推荐 · 协同过滤
营销 · 用户画像
🛡 网络安全
99.99% 的请求是正常的——异常隐藏在长尾里。靠规则永远滞后，靠数据让模型学会"什么不正常"。
🎯 营销 / 推荐 / 广告
"猜你喜欢"不是猜，是基于"和你相似的 10 万人都点了什么"。数据越多，相似得越准，推荐越懂你。
💡 一个朴素的真理
在很多任务上，"更多数据" 比 "更聪明的算法" 更管用。这就是为什么平台公司都在卷数据规模。
数据洞察 · 实战故事
当攻击 潜伏 在 99.99% 的"正常"流量里
一台服务器每秒收到上千条请求。写死规则 能挡住"明牌攻击"，但挡不住 一个 IP 每隔 30 秒试一次密码、持续两周 的潜伏者。
这种"藏在长尾里的故事"，只有 海量日志 + 序列模型 (LSTM) 才看得懂。
access.log · 实时 · ~ 1.2k QPS
总量 / 天 · 1.04 亿条
① 规则引擎 PRE-BIGDATA
已知特征匹配。看到 UNION SELECT、../etc/passwd 就拦截——明牌攻击拦得住。
✗ 漏检 · 缓慢扫描 / 凭证填充 / 异常时段访问 / 看起来正常的请求
② LSTM 序列模型 BIG-DATA + DL
把同一来源 24 小时的请求当作 "一段话"，丢给学过几万条历史攻击的 LSTM。模型从"语法"上判断这段行为 读起来正不正常。
🚨 检出潜伏攻击 · src=198.51.100.42 · 凭证填充 · 持续 14 天
必要条件 ①
存得下 14 天日志——Hive / 对象存储让"留两周"变得便宜
必要条件 ②
算得动 1 亿条——Spark / Flink 在分钟级聚合同源行为
必要条件 ③
学得到模式——历史攻击样本足够多，模型才有"语感"
数据洞察 · 实战故事 #2
转化漏斗 × AB 实验 · 把 直觉 变成 可信的决策
"新按钮看着好像更好用"——是直觉。
把 10 万用户随机分两组、跑 7 天、看每一层漏斗、做显著性检验——是数据驱动的决策。
📥 总曝光
100,000
UV
→ 随机 50 / 50 分流 →
📅 实验周期 · 7 天
对照组 · v1 (老按钮)
CONTROL · A
① 曝光50,000
② 点击39,000
③ 加车19,500
④ 支付11,050
7 日转化率
22.1%
实验组 · v2 (新按钮)
EXPERIMENT · B
① 曝光50,000
② 点击42,000
③ 加车22,500
④ 支付13,200
7 日转化率
26.4%
提升
+4.3 pp
显著性p < 0.001 ✓
样本量n = 100,000
95% 置信区间[+3.8, +4.8] pp
→ 决策：灰度放量 100%
💡 没有 AB 实验，你只能猜测 v2 是否真比 v1 好；
有了 AB + 显著性检验，你能用 95% 的把握说"提升是真的、不是抖动"。这正是"数据驱动"不只是口号的原因。
价值 #3 · 智能决策
数据，是把 51% 的优势 反复放大
抛硬币：正面 +1，反面 -1。公平硬币时长期收益 = 0；可如果概率变成 60/40，这 10% 的优势随时间会变成多少？动手试试。
当前模式: FAIR · 每次自动模式 50ms 抛一次
累计收益
理论期望
💡 公平硬币时，曲线在 0 附近反复摆动；切到 60/40 后再抛几百次——曲线会稳稳向上漂。
企业里的"数据决策"，本质就是 把每个决定的胜率从 50% 推到 51%，然后让时间帮你赚钱。
PART · 02
02
那么，大数据 到底是什么?
它不是一个软件，也不是一种数据库。
它是一整套——为了"在很大的数据上做事"——而长出来的技术生态。
20 年发展史
三层岗位地图
数据建模 & 合作链路
发展历程 · 一图看懂 20 年
大数据的 四个时代
每一次硬件、网络、需求的变化，都把大数据推向一个新形态。今天我们处在的位置，是过去 20 年累积的结果。
~ 2005
史前时代
单机数据库 + 后端写 SQL 直查。数据一变大就崩。
2005 · 2015
Hadoop 时代
HDFS + MapReduce + Hive 全家桶。把一台超级机器拆成一群普通机器。
2015 · 2022
云原生数据湖
存储算力分离、对象存储 + Spark/Flink、流批一体、湖仓融合。
2022 · 至今
AI 时代
数据 × 大模型。向量库、Embedding、Agent 直接吃数据。
↓ 接下来逐个时代展开，看看每一代留下了什么
史前时代 · ~ 2005
在 "大数据"之前，每加一次需求，业务库都离崩溃更近一步
那时候没有数仓，所有分析都直接打在业务库 (MySQL / Oracle) 上。让我们走一遍当年的剧本——
产品提了 3 次需求，后端被打爆了 3 次。
01简单聚合 · 一切美好
"今天新增了多少注册用户？"
后端 · 1 秒返回
SELECT COUNT(*) FROM users
WHERE reg_date = CURDATE();
✓ 一条 SQL · 直接打线上库
02多维拆分 · 开始有点吃力
"近 7 天每天，按渠道 + 平台拆开看一下。"
后端 · 跑 30s，主库 IOPS 抖动
SELECT date, channel, platform, COUNT(*) ...
GROUP BY date, channel, platform;
🩹 曲线救国：建只读从库 · 凌晨预跑 · 物化中间表 · 加 Redis 缓存
⚠ 勉强能给 · 但只能 T+1 看
03深度下钻 · 彻底爆炸
"我要看 渠道 × 城市 × 性别 × 年龄段 的注册→激活→留存漏斗，看过去一年的趋势。最好明天给。"
后端 · 已尝试 3 种方案
... 8-way JOIN, 16 维, 365 天 ...
- 试 1 · 跑一夜没出，第二天还在转
- 试 2 · 把主库 IOPS 打爆，DBA 凌晨电话
- 试 3 · 拆 100 条小 SQL 用 Java 拼，3 天对不上
✗ 业务库真的做不了
总结 · 业务数据库 (OLTP) 的本质局限
· 行存为主 — 聚合 / 列扫描慢
· 单机算力 — 横向扩不动
· 写多读少优化 — 复杂查询不擅长
· 影响线上 — 跑大查询就抖业务
· 跨业务 JOIN 难 — 数据分散在 N 个库
· 历史保留有限 — 老数据被清掉
于是有人开始想：把"分析"从"业务库"剥离出来——用一批便宜的机器、专门为分析而生的存储与计算，做一个独立的"数据世界"。
下一页 → Hadoop 时代登场。
时代 #1 · 2005 — 2015
Hadoop 全家桶 · 蚂蚁军团崛起
谷歌三篇论文（GFS / MapReduce / BigTable）拉开序幕。核心思想朴素到惊人:
既然一台超级计算机太贵，那就用 1000 台普通 PC 拼起来。
类比 · 蚂蚁搬大象
一只蚂蚁搬不动一片饼干（单机存不下），但一万只蚂蚁可以搬一头大象。
关键不是每只蚂蚁多强壮，而是怎么协调、怎么分工、有蚂蚁掉队怎么办。
两大核心原语
HDFS：把一份大文件切块、复制三份、撒到不同机器上。
MapReduce：把计算搬到数据旁边做，最后再汇总。
时代 #1 · 深度剖析 · 一夜故事
蚂蚁军团是怎么诞生的 · 又是怎么治好业务库时代的病的
故事要从 2003 年说起 —— Google 把自己的"秘籍"写成三篇论文公开了，
一个叫 Doug Cutting 的工程师在家里默默照抄，十年后整个互联网都跑在他写的代码上。
📜 诞生时间线 · ORIGIN
2003
Google 发表 GFS 论文 —— "我们用普通 PC 存了上 PB 的网页"
2004
Google 再发 MapReduce 论文 —— "1000 台机器，2 小时算完一年日志"
2005
Doug Cutting 写开源搜索 Nutch 被存储瓶颈卡住，照着 Google 论文重写了存算两层，用儿子的玩具大象命名 —— Hadoop
2006
Yahoo! 把 Doug 挖走，搭起 200 节点的第一个生产集群
2008
晋升 Apache 顶级项目。Yahoo 用 910 节点 209 秒排序 1TB，刷新世界纪录
2010+
Facebook / Twitter / 阿里 / 腾讯 / 百度 全部上 Hadoop。"大数据"第一次成为能买能装的产品
核心
范式转变 —— 不再追求"一台机器更强"，而是"更多廉价机器协同"
🔧 每个组件，治一种"业务库时代的病"
业务库时代的痛
对应组件
怎么治
📦 单机存不下 PB 数据
HDFS
大文件切 128MB 块，每块复制 3 份撒到不同机器
🐌 跑大查询主库 IOPS 爆炸
MapReduce
把计算"搬到数据旁"，千台并行 Map → Shuffle → Reduce
⚔️ 多任务抢资源
YARN
统一算力调度器 —— 队列、配额、抢占（云的雏形）
🤯 写 Java MR 太累
Hive
SQL → MR，分析师不学 Java 也能跑分布式查询
⏱️ HDFS 不能按 key 实时查
HBase
仿照 BigTable，千亿行 KV 毫秒级随机读写
🔄 业务库数据搬不过来
Sqoop
MySQL / Oracle ↔ HDFS / Hive 双向并行批导
📜 日志散在几千台机器
Flume / Kafka
分布式管道实时收集 + 削峰填谷，挂一台不丢数
🧵 谁先跑、失败怎么重
Oozie
批处理工作流编排，DAG 依赖 + 失败重试
👑 谁是 master，挂了怎么办
Zookeeper
分布式协调底座 —— 选主、配置同步、分布式锁
🐘 一句话总结：
Hadoop 不是一个软件，而是一整套"廉价机器协同"的工程方法论 ——
HDFS 解决"存"、MapReduce 解决"算"、YARN 解决"调度"、Hive / HBase 解决"用"、Sqoop / Flume / Kafka 解决"进出"、Oozie / Zookeeper 解决"秩序"。
每多一台 PC，整个系统的存储和算力就线性增长 —— 这就是大数据时代真正的"魔法"。
时代 #2 · 2015 — 2022
云原生数据湖 · 水库时代
Hadoop 把数据"存下来"了，但 MapReduce 太慢、运维太苦。云出现后，思路变了:
存储和计算分开，按需扩容；批和流统一，越来越实时。
类比 · 从粮仓到水库
Hadoop 像装满一袋袋谷物的仓库——结构整齐但搬运笨重。
数据湖像水库——什么形态的数据都先存进来（结构化、日志、图片、视频），需要用时再"取水"加工。
关键转变
- · 存储算力分离 — 算力按分钟付费
- · 内存计算 — Spark 把 MR 慢的部分干掉
- · 流批一体 — Flink 让"实时"成为标配
- · 湖仓融合 — Iceberg / Hudi / Delta 给湖加上事务能力
时代 #2 · 深度剖析 · 水库故事
数据湖是怎么炼成的 · 又是怎么治好Hadoop 时代的病
云一来，整个剧本被改写 —— 存储和算力分开卖，按分钟付费；
一份份开源协议（Spark / Flink / Iceberg）让"大数据"从运维苦差变成乐高积木。
🌊 演进时间线 · EVOLUTION
2006
AWS S3 上线 —— "存储可以按 GB·月卖，算力按秒卖" · 公有云的奠基石
2009
UC Berkeley AMPLab 发表 Spark / RDD 论文 —— "数据放内存，迭代算法不要老往硬盘写"
2014
Spark 1.0 + Databricks 成立 · 同年柏林工大孵化 Apache Flink —— 流批一体范式
2017
Netflix 开源 Iceberg、Uber 开源 Hudi —— 给"湖"加上事务和版本
2019
Databricks 开源 Delta Lake，提出 Lakehouse —— "湖 + 仓"融合架构
2020+
Snowflake 上市、阿里 MaxCompute / 腾讯 EMR / 字节 ByteLake 全面上云，"湖仓"成为新标配
核心
范式转变 —— 从"自建机房 · 存算一体"到"对象存储 + 弹性算力 + 开源表格式"
🔧 每个组件，治一种"Hadoop 时代的病"
Hadoop 时代的痛
对应组件
怎么治
🪨 HDFS 扩容必须存算同扩
S3 / OSS
对象存储 · 存只付存的钱，算只付算的钱
🐢 MR shuffle 落盘太慢
Spark
DAG 优化 + 内存缓存，常见 10–100× 加速
🔁 一份逻辑写两遍（批 + 流）
Flink
流批一体，相同 SQL / State 跑实时与回溯
📊 Hive 查询要分钟级
Presto / Trino
MPP 引擎，跨库即席查询，秒级返回
💨 多维报表查不动
ClickHouse
列存 + 向量化执行，单机亿级聚合毫秒级
⚡ 实时大屏没法做
Doris / StarRocks
实时摄入 + OLAP 一体，秒级可见
🛠 Oozie XML 难写难调
Airflow
Python DAG，可调试 + 可视化 + 千任务并发
📐 SQL 改了没人知道
dbt
把数据转换当软件管 —— 版本 / 测试 / 文档化
🗺 元数据散落各 Metastore
DataHub
统一血缘 + 数据资产门户 + 治理
🩹 湖里读到半写数据
Iceberg / Hudi / Delta
ACID 事务 + 快照隔离 + 时间旅行
🌊 一句话总结：
数据湖时代不是换了软件，而是把"运维一片机房"拆成了"按需租用 + 开源拼装" ——
底座（S3）、引擎（Spark / Flink）、表格式（Iceberg）、调度（Airflow）、转换（dbt）、元数据（DataHub）每一层都可替换、可独立演进。
大数据从"运维难题"变成"乐高积木"，门槛从千万级降到几万元起步。
时代 #3 · 2022 — 至今
AI 时代 · 数据不再只被查询，还被理解
大模型来了之后，数据的"被使用方式"被重写：原来要写 SQL 才能查的数据，现在可以被一句自然语言找到；
原来只能存 JSON，现在可以存"意思"——Embedding 向量。
类比 · 从图书管理员到博学顾问
以前的数据系统像图书管理员：你给关键词，他给你书号。
现在的数据 + 大模型像博学顾问：你说"我心情不好，想看点治愈的"，他真的能找到合适的内容并帮你总结。
新主角
- · 向量数据库 — 让"语义相似"成为一种新索引
- · RAG / Agent — 把企业数据接入大模型
- · 特征平台 — 训练 / 在线推理共用一份数据
- · Data + AI 一体化平台 — Lakehouse + ML 不再分离
时代 #3 · 深度剖析 · 智能故事
数据从"被查询"变成"被理解" · 自然语言成为新 SQL
Transformer 一出，整个数据栈被重写一遍 —— Embedding 成为新索引、向量库成为新存储、LLM 本身成为新 BI。
人类第一次可以用一句话，让机器"理解"自己想要的数据。
🧠 智能涌现时间线 · EMERGENCE
2017
Google 发表 Transformer 论文 ——《Attention Is All You Need》, 大模型的种子被埋下
2018–20
BERT / GPT-1/2/3 一路放量 —— "参数变大 + 数据变多 = 智能涌现" 成为行业共识
2019
Pinecone 成立、Milvus 开源 —— "Embedding 需要一种新型索引" · 向量数据库赛道诞生
2020
Meta 开源 FAISS —— 工业级向量检索基础库，喂养了之后所有向量库
2022.10
Harrison Chase 开源 LangChain —— 第一个把"企业数据 + LLM"拼起来的框架
2022.11
ChatGPT 发布，行业地震 —— 5 天百万用户、2 个月破亿，最快的消费级产品
2023+
RAG / Agent / Function Calling 范式确立 · Databricks / Snowflake 全面 AI · 大模型成为基础设施
核心
范式转变 —— 数据不再只"被查询"，而是被"被理解、被检索、被生成"
🔧 每个组件，治一种"数据湖时代的病"
数据湖时代的痛
对应组件
怎么治
🔍 关键词搜索找不到"意思相近"
Milvus / Pinecone / Qdrant
用 Embedding 把文本变向量, 按余弦相似度检索
💬 看数据要写 SQL, 业务方不会
LLM + Text2SQL
自然语言 → SQL → 结果 → 自然语言摘要
📚 ChatGPT 不懂我公司的事
RAG (LangChain / LlamaIndex)
先检索企业文档, 再把片段塞进 Prompt 喂给 LLM
🤖 单步问答答不了复杂任务
Agent / Function Calling
LLM 主动调工具、查数据、拆任务、循环推理
🎯 训练数据 ≠ 线上推理数据
Feast (Feature Store)
一份特征定义, 离线训练 / 在线推理共用
🧪 实验跑过了忘了哪个版本好
MLflow
实验追踪 + 模型注册 + 部署一站式
🚀 单卡训不动百亿参数
Ray / DeepSpeed
分布式训练 / 推理 / 数据加载, 千卡协同
🏗 数据在湖, AI 训练接不上
Databricks Lakehouse + ML
湖仓 + 训练 + 服务一体, 数据不出平台
❄️ 跨云数据集成又贵又难
Snowflake Cortex
共享数据 + 内置 LLM 推理, SQL 直接调模型
🦆 笔记本本地分析没工具
DuckDB
嵌入式 SQL 引擎, 零依赖跑亿行 Parquet
🧠 一句话总结：
AI 时代的数据栈不是"加一个向量库"那么简单 ——
存储（Embedding）、检索（向量索引）、计算（GPU / Ray）、消费（RAG / Agent）、消费界面（自然语言）每一层都被重写。
数据团队的工作从"喂报表"变成了"喂模型"，业务团队的工作从"看数"变成了"问数"。
三个时代 · 共同的方向
每一代演进，都沿着三条看得见的轨迹在加速
新组件不是为了"更复杂"，而是把"过去要人做的事"交给系统。
把 Hadoop → 数据湖 → 大模型 三代叠起来看，机器更聪明、迭代更快、人更轻松。
时代 #1
Hadoop 全家桶
~ 2005 – 2015
时代 #3 · 现在
大模型 / AI
2022 — 至今
写 Java MapReduce
手写 Map / Reduce 函数，分区策略全靠经验
Catalyst / CBO 优化器
SQL 自动重写，统计信息驱动执行计划
LLM + Agent + RAG
自然语言 → SQL / 工具调用 → 自主推理与回答
⚡
更加快速迭代
反馈循环从天到秒
一行代码到一个 Prompt
Jar 包部署 · T+1
改 Java → 打包 → 部署 → 凌晨跑数 → 第二天看结果（天级）
dbt run + DAG
改 SQL 即跑，Airflow 调度，弹性算力按分钟付费（分钟级）
Prompt + RAG 配置
改提示词 / 检索源即刻生效，提示词就是新代码（秒级）
👥
更加以人为本
门槛从工程师降到任何人
从"用工具"走向"说人话"
仅数据工程师可用
需懂 Java / Linux / 分布式系统才能写一个分析任务
SQL 用户 + BI 工具
分析师 / 运营自助拖拉看板、写 SQL 即可
任何人 · 自然语言
"上周新疆区的订单为什么涨了？" —— 直接说人话即可
🎯 一句话总结：
每一代演进的本质都是把"人做的事"逐步交给系统 ——
Hadoop 把"协调"自动化、数据湖把"调度与优化"自动化、AI 把"提问本身"自动化。
下一代会继续沿着这三条轴前进 —— 更聪明、更快、更近人。
岗位地图 · The Job Landscape
大数据的工作，可以分成 三层
从最底层的"修路造车"到最顶层的"产生洞察"，每一层都有不同的语言、不同的产出、不同的人。
LAYER · 03数据消费层把数据"用出去"
🔌数据服务
📈BI 工程师
🔍数据分析师
🧠数据科学家
🎯业务策略
LAYER · 02数据建模层把数据"组织好"
🧩数据建模师
🔧ETL 工程师
🩺数据质量
⚖️数据治理
LAYER · 01基础设施层把数据"装得下、算得动"
🗄️存储工程师
🗂️元数据 / Catalog
⚡计算引擎 (Flink/Spark)
📊分析引擎 (Doris/CK)
🛠️平台 / 调度
底层 → 顶层 · 数据离业务越来越近，离机器越来越远
第 1 层 · 基础设施
修路造车 的人
他们不直接产出业务指标，但他们决定了上层的人能跑多快。一个引擎的优化，可能为公司每年省下几千万算力。
🗄️
存储工程师
管"数据放在哪、怎么放最便宜可靠"。HDFS / 对象存储集群的扩容、副本、冷热分层。
🗂️
元数据 / Catalog
建公司的"数据地图"——表的字段含义、负责人、血缘、SLA。让"找数"从"问人"变"搜索"。
⚡
计算引擎研发
改 Flink / Spark 的源码——优化器、Codegen、State 后端。一行代码影响整个公司。
📊
分析引擎
做 ClickHouse / Doris / StarRocks 内核优化。让"亿级聚合毫秒返回"成为可能。
🛠️
平台 / 调度
把所有引擎缝合成开发者能用的产品——开发 IDE、调度、监控、租户隔离、成本治理。
🚗 类比：他们是修高速、造车的工程师。司机（业务方）不需要懂引擎，但没他们，车根本开不动。
↗ 点击任意卡片查看该岗位详情
第 2 层 · 数据建模
把生肉做成半成品 的人
原始数据像生肉——能吃，但难吃。建模 & ETL 把它清洗、切块、调味，让上层 100 个分析师不用每次从头处理一遍。
🧩
数据建模师
设计"数据该怎么组织"——分层、命名规范、维度建模、宽表。不写很多代码，但每一个决定影响下游 100 个分析师。
→ 关心: 复用性 / 一致性 / 可演进性
🔧
ETL 工程师
实现"把数据从 A 搬到 B 并加工"——写 Spark / Flink / SQL 任务，每天定时跑数，保证不丢不重不延迟。
→ 关心: 正确性 / 时效 / 稳定性
🩺
数据质量
守"数据可信"这条底线——监控空值率、唯一性、口径漂移、产出延迟。一个错的数比没有数更糟。
→ 关心: 你看到的数对不对
⚖️
数据治理
比质量更宏观——管标准、管权限、管合规、管资产。GDPR、PII、数据分级都是治理课题。
→ 一把手工程，没高层支持推不动
🍱 类比：他们是中央厨房的厨师。把市场买回的生鱼生肉，洗、切、腌、分装。下游的"前线餐厅"（分析师 / BI）拿到的是半成品，五分钟就能上菜，而不是从杀鱼开始。
↗ 点击任意卡片查看该岗位详情
第 3 层 · 数据消费
把数据变成决策 的人
他们最贴近业务。一个准时上线的看板、一个准确的归因分析、一个能提 5% 留存的策略——价值都从这一层兑现。
🔌
数据服务工程师
把"表"变成"接口"。后端、App、广告系统调一次 API 就拿到画像 / 特征 / 指标。
📈
BI 工程师
建看板、做报表。让 CEO 和一线运营每天打开就能"看见业务"，不用问人要数。
🔍
数据分析师
回答"为什么 / 怎么办"——归因、AB 实验、漏斗、留存、增长策略。把数据变 insight。
🧠
数据科学家
用 ML / DL 解决"靠规则解决不了"的问题——推荐、风控、定价、流失预警。
🎯
业务策略 / 数据运营
站在最业务的一端——基于数据制定业务策略。给谁发券、发多少、什么时间。
🍽 类比：他们是前线餐厅的服务员、主厨、营养师。客人（业务方）感受到的好与坏，最直接来自这一层。
↗ 点击任意卡片查看该岗位详情
深入一层 · 数据建模
为什么要 分层?
如果每个分析师都直接从原始日志算 DAU，会出现 100 种口径、5 个不同的数、上游字段一改全公司停摆。
分层 = 把"通用加工"集中做一次，下游复用 —— 就像把鱼变成菜的厨房分工。
↗ 鼠标悬停左侧任一层查看详情
ADS🍽 应用层 · 直接对接看板 / 接口 / 策略
DWS🍱 汇总层 · 按主题聚合的指标 / 宽表
DWD🔪 明细层 · 清洗 / 补全 / 规范化的事实明细
ODS🍣 原始层 · 业务库 / 日志 / 埋点的"生数据"
👇
悬停左侧任一层 · 看它的目的 / 监控指标 / 常见坑
💡 厨房四道工序
- ODS 🍣 刚到货的生鱼，原样冷藏，不动它
- DWD 🔪 切好的鱼片，洗净、去骨、规范尺寸
- DWS 🍱 配好的便当盒，常用搭配预先组合
- ADS 🍽 端到桌前的菜，业务方直接吃
🎯 三个核心收益
复用 · 100 个分析师不用各自重洗鱼 · 一致 · 全公司用同一份 DAU 口径 · 隔离 · 上游字段改了下游不全部炸。
ODS
原始层 · 🍣 刚到货的生鱼 · 原样冷藏
🎯 这一层的目的
把业务库 / 日志 / 埋点的"快照"原样存下来，作为下游一切加工的唯一可信源头。不做清洗、不做计算 —— 出错时方便回溯。
📊 关键监控指标
- 同步延迟 · 与上游业务时间差
- 同步成功率 · 任务失败比例
- 数据量波动 · 日 / 周同比异常
- Schema 漂移 · 字段增删 / 类型变更
⚠️ 常见踩坑
- 上游字段悄悄改了类型
- 分库分表后漏同步一张
- 时区 / 编码不一致（UTC vs +08）
- 重复同步导致数据翻倍
DWD
明细层 · 🔪 切好的鱼片 · 标准化处理
🎯 这一层的目的
把 ODS 的脏数据洗干净 + 拼齐维度，一行 = 一条标准事实。下游所有分析都不该再回到 ODS 翻原始日志。
📊 关键监控指标
- 主键唯一性 · 重复率
- 关键字段空值率 / 非法值率
- 维度关联补全率
- 处理延迟 · SLA 达成率
⚠️ 常见踩坑
- 上游重发，重复数据没去重
- 维度表晚到，关联取到空
- 跨日归属错位（UTC vs CST）
- 历史回刷，下游集体翻车
DWS
汇总层 · 🍱 配好的便当盒 · 常用组合
🎯 这一层的目的
按主题 / 粒度提前算好常用指标（DAU、订单 GMV、留存…），让下游 100 个分析师"select 一下就够"。
📊 关键监控指标
- 跨表口径一致性（DAU 不能多版）
- 跑批耗时 / 任务长度
- 数据更新频率与时效
- 下游依赖任务数
⚠️ 常见踩坑
- 同一指标多套口径打架
- 维度组合爆炸，宽表变千列
- 历史回算成本高（一次几小时）
- 字段没人敢删，越积越多
ADS
应用层 · 🍽 端到桌前的菜 · 业务直接吃
🎯 这一层的目的
直接服务具体场景 —— 看板 / 接口 / 策略 / AB / 推送。表结构跟着业务长，允许"非通用"。
📊 关键监控指标
- 接口响应 P50 / P99
- 数据时效 · 与业务时间差
- 业务方使用频次
- 每日产出按时率
⚠️ 常见踩坑
- 业务"+1 字段"，跨层穿透 ODS
- 报表口径与业务理解不一致
- 高峰查询打爆 OLAP 引擎
- 历史快照丢失，月底对账困难
建模 · 一个常被讨论的设计
宽表 · 把"常一起用的字段"放一起
业务库里数据按"实体"拆得很细：用户表、订单表、商品表、地址表……分析时却经常要 join 5 张表才能算一个指标。
宽表的做法：提前把这些 join 做好，落成一张大表，分析师"select 一下就够了"。
业务库 · 多张窄表
USERS
id · name · age
city · gender · ...
ORDERS
id · user_id
amount · time
ITEMS
id · category
price · brand
↓
JOIN · 5 张表的明细全部预聚合
宽表 · dws_user_order_1d
user_idcitygenderordersgmvfav_cat
u_001SHF3428.5美妆
u_002BJM189.03C
u_003HZF71280.0母婴
..................
合作链路 · 一个需求是怎么流动的
从一句业务话，到一个 有数支撑的决策
需求场景 ➜
产品同学说：「我想看新支付按钮上线后的 7 日转化率」。
点 「下一步」 看它怎么在 5 个角色之间流转，最终成为一个可执行的决策。
00
尚未开始
点击下方按钮启动
点击 「下一步 →」 开始模拟一个真实需求的流转过程。每一步会展示 这个角色具体在做什么、说什么话、交付什么产物。
⚠ 沟通陷阱 #1 · 口径
"转化率"分母是谁？看到？点击？下单？不对齐，每个人算出来的数都不一样。
⚠ 沟通陷阱 #2 · 埋点
后端没埋 button_version，ETL 跑出来全是空。需求要 从埋点设计 就介入。
⚠ 沟通陷阱 #3 · 节奏
明天就要看数？建模 + ETL + 回溯 至少 2 ~ 3 天。提前一周提需求 是最重要的礼貌。
我的标准动作 · 一次真实迭代
从一句需求，到高质量数据模型 · 5 步流程
不是理想化流程图，是 2026-05-13 一次真实的端到端迭代复盘 —— tally 数仓从 0 到
12 张 silver + 6 张 gold + 4 个 P0 全部解决，单日完成。每一步都有人和 AI 的明确分工。
PHASE · 01
v1 草案
🎯探索 + 规划
👤拉代码、答业务约定
拍架构决策
🤖读 Go 源码、Athena 抽样
出建模 Plan 草稿
📦10 silver + 6 gold 草案
飞书思路文档
PHASE · 02
v1 完成
🔨实施 + 首检
👤review 边界 case
跑物化（守生产）
🤖写 SQL / macro / dbt config
Athena 全表审计
📦DQ 报告 v1
定位 4 个 P0 + 4 个 P1
PHASE · 03
v2 → v3
🔥深度修复
👤口述隐性知识
"Stripe FX 老问题"
🤖PR-A/B/C 拆分修复
沉淀 fx_rates_normalized macro
📦FX 虚高 $11M → $111K
NULL 92% → 0.85%
PHASE · 04
v4
🧬维度扩展
👤提架构问题
"常一起出现是否下沉"
🤖新建 user_attributes silver
4 channel + industry 全链路
📦7 维 group by
WINBACK 92K → 19.8K（精确）
PHASE · 05
v5 收官
🔍兜底 + 洞察
👤授权深入到 dim 兜底
看分布定位 NULL 原因
🤖snapshot 反推 orphan plan
+ 数据分布全审计
📦NULL 1.83% · 修正 $322K
发现 special_channel 占 19.8% 收入
📨 输入
业务一个指标需求文档
↺ 每一 Phase 产出
= 下一 Phase 输入
五轮迭代闭环
🎁 产出
5.99M 用户 · 12 silver + 6 gold
+ 业务洞察 ×2 · 飞书文档 5 篇
终章 · 关于这次合作本身
用好 AI 的艺术 = 上下文管理的艺术
AI 给你 100× 效率，前提是你能给它"对的上下文"。
举一个真实案例 —— tally 数仓 · 5.99M 用户 · 12 张 silver + 6 张 gold · 单日 5 轮迭代 ——
交付质量从 plan_level 92% NULL → 1.83%。不是 AI 多厉害，是上下文给得对。
01
🧠
业务上下文
让 AI "懂业务"
🔧 怎么给
开始前一起读源码 + 跑数据；隐性约定口述出来，AI 会立即固化为 macro / 注释 / memory
💡 真实案例
"Stripe 对 0 小数币种（JPY / KRW）预先除以 100" —— 不在代码、不在文档，只在人脑里。用户一句话，AI 写出 15 币种白名单 macro，挽回 $11M 收入虚高
02
⚖️
决策上下文
让 AI "知你想要"
🔧 怎么给
AI 主动反问关键决策，不要默认假设；用户拍板架构选择，AI 主导细节实现
💡 真实案例
合并语义、切分时点、孤儿数据兜底、维度归属 —— 每一个"看起来明显"的决策都让用户拍板。没拍板就别动，否则后面会塌一整层
03
🔬
数据上下文
让 AI "贴近现实"
🔧 怎么给
写 SQL 前先 Athena 跑等价查询预演；物化后跑同样查询对比验证。用真实数据形态取代 schema 猜测
💡 真实案例
看 schema 以为 plan_level 字段很干净 —— 真跑发现 92% NULL。一次 5 秒的 Athena dry-run 救了一次错误物化
04
🧬
历史上下文
让 AI "记得之前"
🔧 怎么给
边干边沉淀 —— DQ 报告 / 设计稿 / macro / memory；前一轮的产出 = 后一轮的输入
💡 真实案例
v1 → v5 五轮迭代，每轮 DQ 报告写完即成下一轮起点。NULL plan_level 率从 92% 一路压到 1.83%，关联收入修正 $322K
🎯 "AI 不是替代数据工程师，而是把数据工程师从'写 SQL'解放出来做'判断业务规则'。"
这是协作模式的本质转变 —— 你给上下文，AI 给杠杆。
— 真实经验贴 · 2026-05-13 · 单日实战
完整版 · 后续可继续扩展
Thank You
大数据不是一座山，而是一片在持续生长的森林。
无论你最后停在哪一层——都希望这 20 分钟，让你对它不再陌生。
Q & A
欢迎讨论
PRESS ← TO REWIND · PRESS HOME TO RESTART