从脏数据到数据资产
前几本里，小哲做出了轻记账、养大了账小灵、建好了网络和数据中心——公司攒下了海量数据。但老板要做经营报表时，财务说「两个系统的营业额对不上」；账小灵做分析时，发现用户分类乱成一锅粥。周师傅说：数据不治理，AI 再强也是「垃圾进垃圾出」。这一本，带小哲把公司的数据从「一摊脏乱差」打理成「一座金矿」。
数据一团糟
GIGO：垃圾进，垃圾出师傅！老板要看季度经营报表，结果财务说「App 端营业额 1280 万，网页端 910 万，加起来和银行流水对不上」；账小灵分析用户消费习惯，结果发现「餐饮」这个分类在系统里有 6 种叫法……全乱套了！
恭喜你，公司终于「数据多到需要治理」了——这是成长的烦恼，也是机会。先说句老话：GIGO（Garbage In, Garbage Out）——垃圾进，垃圾出。数据是脏的，再厉害的分析和 AI 都是白搭。
数据治理不是一次「大扫除」，而是一套持续运作的体系。我给你画了十站路线——
记住一句话：清洗是「把数据弄干净」，治理是「让数据一直干净，并且有人负责」——一个是技术活，一个是管理活，缺一不可。走，第一站，先搞清楚公司到底有哪些数据。
数据盘点：元数据与目录
元数据 · 数据目录 · 血缘 · 数据字典治理的第一件事不是「洗数据」，而是「数家产」——公司有多少数据表、存在哪、谁在用、从哪来。连家底都不清楚，谈何治理。
公司数据散落各处：MySQL 账目库、PostgreSQL 用户库、账小灵的对话日志、Excel 报表、第三方导出的 CSV……先建两张「地图」：
- 元数据（Metadata）：关于数据的数据——这个表叫什么、有哪些字段、字段什么类型、谁建的、更新频率多少。
- 数据目录（Data Catalog）：全公司数据资产的「图书馆检索系统」——业务同学也能搜到「我要的营业额数据在哪」。
再加一根数据血缘（Lineage）：数据从哪来、经过哪些加工、流到哪个报表——出了问题能倒查，改字段能评估影响。
【数据字典（字段级元数据）】
表：orders（订单表） 负责人：小哲 更新：实时
字段 类型 含义 约束
order_id BIGINT 订单号 主键，唯一
user_id BIGINT 用户ID 外键→users
amount DECIMAL 金额（元） >0
category VARCHAR 分类 参考字典表
created_at DATETIME 下单时间 必填
【数据血缘（从源头到报表）】
App订单库 ──┐
├─→ 清洗ETL ──→ 订单明细宽表 ──→ 营收报表
网页订单库 ──┘ └──→ 账小灵分析
↑ 改了这个字段，下游 2 个报表都会变——血缘一眼看清
【工具参考】
开源：DataHub / Apache Atlas / Amundsen
云厂商：AWS Glue / 阿里云 DataWorks 都有目录能力盘点术语
- 元数据（Metadata）：关于数据的数据——表结构、字段、负责人、更新频率。
- 数据目录（Data Catalog）：数据资产的检索系统——「有什么、在哪、谁负责」。
- 数据血缘（Lineage）：数据的来源与去向图——倒查问题、评估影响。
- 数据字典：字段级规范说明——技术同学和业务同学沟通的「翻译本」。
- 数据地图 / 资产盘点：盘点所有数据源的清单——治理的起点。
公司上了数据目录后，新来的数据分析师不再「挨个问老同事表在哪」，自己在目录里搜「营收」就能找到口径说明、负责人和血缘图；老板要的报表出问题，血缘图 5 分钟定位到是「网页订单清洗脚本」改坏了。
本站收获：盘点 = 元数据（是什么）+ 目录（在哪找）+ 血缘（从哪来）。先摸清家底，治理才有抓手——「不清楚的数据，就是不可控的数据」。
质量诊断：六维体检
完整性 · 准确性 · 一致性 · 及时性 · 唯一性 · 有效性数据到底「脏」在哪？别凭感觉，用六把尺子量。数据质量六维，是数据工程师的「体检表」。
我知道数据有问题，但老板问「问题多严重」时，我只会说「挺脏的」……太丢人了。
数据质量有标准的六维框架，每一条都能量化成「不合格率」。学会它，你就能把「挺脏的」说成「订单表完整性 98%、唯一性 94%，主要问题在重复下单记录」——这才叫专业。
① 完整性（Completeness）—— 有没有空值？
例：10% 的订单缺 category 字段 ❌
② 准确性（Accuracy）—— 数据对不对？
例：金额 0.1 存成 0.0999999、手机号 11 位却存了 13 位 ❌
③ 一致性（Consistency）—— 同一件事各处口径一样吗？
例：App 叫「餐饮」，网页叫「吃饭」，客服叫「Food」→ 三套叫法 ❌
④ 及时性（Timeliness）—— 数据够不够新？
例：报表 T+2 天才更新，老板看到的是两天前的数 ❌
⑤ 唯一性（Uniqueness）—— 有没有重复？
例：同一笔订单被同步了 3 次，营业额虚增 3 倍 ❌
⑥ 有效性（Validity）—— 值在不在合法范围？
例：金额出现 -999、年龄出现 200、分类不在字典里 ❌
【体检报告（示例）】
指标 不合格率 影响
category 缺失 10% 分类统计失真
amount 负值 0.3% 营收计算异常
重复订单 6% 用户/营收双虚增
口径不一致 3 套 跨系统对账失败
→ 全部量化！治理优先级一目了然质量术语
- 数据质量六维：完整性、准确性、一致性、及时性、唯一性、有效性——诊断的统一语言。
- 不合格率 / 质量评分：把问题量化（如 90 分），治理目标「可衡量」。
- 口径不一致：同一业务含义在不同系统的不同定义——对账失败的元凶。
- 脏数据分类：缺失、重复、异常、格式错、口径乱——先分类再开药。
- 体检报告：治理前必须出诊断报告——「先诊断，后手术」。
本站收获：质量诊断 = 六维量化体检。把「挺脏的」变成「六张不合格率表」——数字一出来，老板才肯批钱做治理。
清洗实操：Pandas 手术台
缺失值 · 去重 · 异常值 · 标准化 · SQL 清洗诊断完了，上手术台。清洗是数据工程师的「手艺活」——Pandas 和 SQL 两把刀，四大手术：补缺失、去重复、摘异常、整格式。
清洗的四大手术，每台都有「标准术式」：
- 补缺失：删行（缺失太多）、填默认值（分类填「未知」）、填统计量（金额填中位数）、前向填充（时间序列用上一条）。
- 去重复：按业务键去重（同一订单重复同步）——去重前先想清楚「唯一键是什么」。
- 摘异常：IQR（四分位距）或 3σ 法则找离群点——异常值要「判读」：是真异常（数据错了）还是真业务（大额订单）？别一刀切。
- 整格式：统一大小写、去空格、统一日期格式、类型转换——脏格式是分析的头号杀手。
import pandas as pd
df = pd.read_csv("orders_raw.csv") # 原始订单表
# ① 补缺失：category 缺失填「未知」；amount 缺失填中位数
df["category"] = df["category"].fillna("未知")
df["amount"] = df["amount"].fillna(df["amount"].median())
# ② 去重复：按订单号去重，保留第一条
df = df.drop_duplicates(subset=["order_id"], keep="first")
# ③ 摘异常：金额超出 [Q1-1.5IQR, Q3+1.5IQR] 的先打标人工看
Q1, Q3 = df["amount"].quantile([0.25, 0.75])
IQR = Q3 - Q1
df["amount_outlier"] = (df["amount"] < Q1-1.5*IQR) | (df["amount"] > Q3+1.5*IQR)
# ④ 整格式：分类统一小写、日期统一、手机号校验
df["category"] = df["category"].str.strip().str.lower()
df["created_at"] = pd.to_datetime(df["created_at"], errors="coerce")
df = df[df["phone"].str.fullmatch(r"1\d{10}", na=False)] # 只留合法手机号
# 手术记录（清洗日志！）
print("清洗前", raw.shape, "清洗后", df.shape) # (12000, 8) → (10520, 9)INSERT INTO orders_clean
SELECT
order_id,
COALESCE(category, '未知') AS category, -- 补缺失
CASE WHEN amount <= 0 THEN NULL -- 摘异常（金额<=0置空）
ELSE ROUND(amount, 2) END AS amount, -- 整格式
DATE(created_at) AS order_date
FROM orders_raw
WHERE order_id IS NOT NULL -- 去空主键
GROUP BY order_id; -- 配合唯一键去重清洗术语
- 缺失值处理：删除 / 填充（默认值/统计量/前向）——按业务场景选。
- 去重：先定义唯一键（业务键），再 drop_duplicates。
- 异常值检测：IQR / 3σ / 业务规则——异常≠错误，要判读。
- 数据标准化：格式、单位、大小写、日期统一。
- 清洗日志：洗前洗后对比、每步处理了多少行——可复现、可审计。
- 可重复性：清洗脚本要「参数化、可重跑」——不是一次性手工活。
清洗脚本上线后：重复订单去重（营收虚增修正 6%）、金额异常判读（剔除 3 笔测试数据）、分类统一口径——App 端 + 网页端合并后与银行流水对账，差异从「对不上」降到「±0.01 元」，财务同学终于不用加班核数了。
本站收获：清洗 = 补缺失 + 去重复 + 摘异常 + 整格式。Pandas 练手、SQL 上生产、日志留痕——清洗不是「一次性大扫除」，是「可重跑的手术」。
整合流转：ETL / ELT
ETL · 数据管道 · 多源整合 · 调度监控数据不是一个库里的——App 一个库、网页一个库、日志一个库。把多源数据「抽出来、洗一遍、装进目标」，就是数据工程师的日常：ETL。
ETL（抽取-转换-加载）三兄弟：Extract 从各源把数据抽出来 → Transform 在中间层清洗转换（第 3 站的手艺用在这）→ Load 装进数仓/目标库。现在的云原生时代流行 ELT：先原样 Load 进数据湖，再在湖里 Transform（计算力便宜了，先存后洗）。
ETL 不是跑一次就完——它是数据管道（Pipeline）：定时调度（每天凌晨 2 点跑）、失败重试、断点续跑、跑完校验、出错告警。管道是数据工程师的「生产线」。
【数据源】 【ETL 管道】 【目标】
App 订单库 MySQL ──┐
网页订单库 MySQL ──┼─→ ①抽取 ②清洗(第3站) ③合并 ──→ 订单明细宽表
账小灵日志 Kafka ──┘ 每天 02:00 调度 （数仓 ODS→DWD）
【管道四大纪律】
幂等：同一批数据重跑 N 次，结果一样（不会重复叠加）
可重跑：失败了从头再来，断点续传
可观测：每一步的行数、耗时、错误率都有日志
有校验：跑完对账（行数、金额合计）——不对就告警
【调度与工具】
调度：Airflow / DolphinScheduler / 云上 DataWorks
实时管道：Flink / Kafka Streams（账小灵的实时分析用）
离线管道：Spark / Hive（大宽表计算用）
【ELT 对比 ETL】
ETL：先洗再存（传统数仓，洗错了源头还在）
ELT：先存再洗（湖仓时代，灵活但要注意数据湖卫生）ETL 术语
- ETL / ELT：抽取-转换-加载 / 抽取-加载-转换——两种管道范式。
- 数据管道（Pipeline）：定时调度 + 清洗 + 加载的自动化生产线。
- 幂等性：同一批数据跑 N 次结果一致——管道的底线。
- 调度与依赖：任务编排、上下游依赖、失败重试——Airflow 类工具的核心。
- 实时 vs 离线：Flink 流式（毫秒级）vs Spark 批处理（小时级）——按场景选。
- 宽表：多表 JOIN 后的分析大表——报表/分析的直接数据源。
凌晨 2 点管道自动跑：抽 App/网页订单 → 清洗 → 合并宽表 → 汇总经营指标；6 点二次校验对账，不平自动重跑并告警；8 点老板打开日报，数据新鲜且准确。某天源库变更字段，血缘图 + 校验规则 10 分钟定位问题，管道自动暂停避免脏数据入库。
本站收获：ETL = 抽取 + 清洗 + 加载的自动化生产线。幂等、可重跑、可观测、有校验——管道稳了，数据才能天天干净。
标准统一：主数据 MDM
主数据 · MDM · 编码标准 · 参考数据一个「餐饮」，App 叫餐饮、网页叫吃饭、客服叫 Food——这不是清洗能解决的，是「标准」缺失。主数据管理，就是给全公司的核心实体立「唯一标准」。
主数据（Master Data）：公司最核心的共享实体——用户、产品、分类、门店、供应商。这些数据被所有系统引用，一旦各写各的，全公司对不上账。
MDM（主数据管理）：给主数据立「唯一官方版本」——谁创建、按什么编码规则、变更走什么流程、其他系统只能引用不能乱改。配套的还有参考数据（分类、国家、币种这类枚举字典）和编码标准（分类编码 CAT-001 = 餐饮）。
【治理前：三套分类】
App：餐饮/交通/购物/工资
网页：吃饭/出行/买买买/收入
客服：Food/Transport/Shopping
→ 跨系统对账？报表分类？AI 分析？全乱！
【治理后：统一主数据 + 编码】
分类主数据表（唯一官方版本）：
CAT-001 餐饮（餐饮/吃饭/Food/伙食 → 统一映射 CAT-001）
CAT-002 交通（交通/出行/Transport）
CAT-003 购物（购物/买买买/Shopping）
CAT-004 工资（工资/收入/Income）
各系统改造：只准引用主数据 ID，不许自造分类
→ 一张主表，全公司统一
【MDM 落地要点】
一个主数据一个「数据所有者」（业务负责人）
编码规则统一（CAT-XXX 前缀 + 顺序号）
变更走流程（新增分类要审批，不能随便加）
下游系统通过接口/订阅同步主数据主数据术语
- 主数据（MDM）：用户、产品、分类等核心实体的「唯一官方版本」。
- 参考数据：枚举字典（分类、国家、币种）——数据标准的「词典」。
- 编码标准：统一的编码规则——CAT-001 说人话就是「餐饮」。
- 数据标准化：单位、编码、口径的统一——「一个公司，一套标准」。
- 主数据服务：通过 API/订阅把标准数据同步给各系统。
- 维度表（数仓语境）：主数据进数仓就是「维度表」——星型模型的那张表。
分类主数据上线后，账小灵读到的所有订单都映射到 CAT 编码——「餐饮类消费 ¥268/周」终于和财务口径一致。老板看完分析说：这个月奶茶钱比房租还高，是谁！——数据统一的那一刻，AI 的分析才真正可信。
本站收获：标准统一 = 主数据 MDM 立唯一版本 + 编码规则统一 + 变更走流程。清洗是「治标」，主数据是「治本」——源头统一了，下游才不乱。
治理体系：组织与制度
治理委员会 · 数据所有者 · 制度 · DCMM清洗是技术活，治理是「组织活」——数据没人负责、制度没人执行，洗得再干净也会再脏。这一站，立规矩、定角色、上体系。
师傅，我清洗完了、ETL 也建好了……但感觉撑不过三个月——没人维护、没制度约束，大家还是各写各的。光靠我一个工程师，管不住全公司啊！
说到根子上了！治理不是「数据团队的事」，是全公司的治理结构。三个关键角色缺一不可：
- 数据治理委员会：高层拍板——数据战略、优先级、资源，老板不点头，治理寸步难行。
- 数据所有者（Data Owner）：每类数据的业务负责人——「订单数据」归财务总监管，「用户数据」归运营总监管。
- 数据管家（Data Steward）：日常执行者——维护数据字典、执行质量规则、处理问题数据。
中国还有个国家级参考框架——DCMM（数据管理能力成熟度评估模型）：把数据管理拆成 8 个能力域、5 个成熟度等级，政府项目招标常要求 DCMM 等级——它给治理提供了「标准答案式」的体检表。
【公司数据治理制度（示例目录）】
1. 数据资产管理规定：谁建表、谁负责、怎么命名
2. 数据标准管理办法：编码、分类、口径统一
3. 数据质量管理规程：规则、评分、整改流程
4. 数据安全与分级办法：分级、脱敏、授权
5. 数据生命周期管理：归档、留存、销毁
【DCMM 八大能力域（国家 GB/T 36073）】
① 数据战略 ② 数据治理 ③ 数据架构
④ 数据应用 ⑤ 数据安全 ⑥ 数据质量
⑦ 数据标准 ⑧ 数据生存周期
成熟度等级：初始级 → 受管理级 → 稳健级 → 量化管理级 → 优化级
【治理成熟度自评（我们到哪一级了？）】
L1 初始：数据乱，靠个人英雄主义救火 ← 现在的我们
L2 受管：有制度、有角色、有流程
L3 稳健：制度被执行、质量可量化、有监控
L4 量化：用数据管数据，ROI 可度量
L5 优化：持续改进，数据驱动创新 ← 目标治理体系术语
- 数据治理委员会：高层决策机构——治理的「董事会」。
- 数据所有者 / 数据管家：业务负责人 / 日常执行者——「有人管」是治理的命门。
- 数据管理制度：标准、质量、安全、生命周期的规矩——治理的「宪法」。
- DCMM：国家数据管理能力成熟度模型（8 域 5 级）——治理的「考试大纲」。
- 数据生命周期：采集 → 存储 → 使用 → 共享 → 归档 → 销毁——全程管理。
- 数据责任制：每类数据必须有一个「背锅的人」——出了事找得到人。
周师傅拉着 CFO、COO 和小哲开了治理启动会：明确「订单数据所有者=CFO、用户数据所有者=COO」，任命小哲为数据管家；通过《数据质量管理规程》——每月质量报告、季度治理评审；定了 DCMM 二级作为明年目标（正好满足政企客户招标门槛）。三个月后，数据质量从 62 分升到 88 分。
本站收获：治理体系 = 委员会拍板 + 所有者负责 + 管家执行 + 制度约束 + DCMM 指引。技术让数据「能干净」，体系让数据「一直干净」。
安全合规：分级与脱敏
分级分类 · 脱敏 · 个保法 · 访问控制数据越干净越值钱，也越危险——用户手机号、身份证、消费记录，都是敏感资产。清洗的同时必须做安全：先分级，再防护。
数据安全第一原则：不是所有数据都一样重要。先做分级分类：
- 公开数据：公司简介、公开报表——谁都能看。
- 内部数据：经营数据、内部文档——员工可看。
- 敏感数据：用户手机号、身份证、消费明细——严格授权。
- 核心数据：支付流水、密钥、完整用户库——最高防护。
然后按级上防护：脱敏（测试环境用假数据、报表里手机号打星号）、加密存储（敏感字段加密）、访问控制（谁查什么数据都要授权留痕）、合规底线（个保法：告知-同意、最小必要、可删除——和《网络安全知识路径》里讲的安全是一家人）。
【分级清单（示例）】
级别 数据示例 防护要求
公开 公司公告、财报 无特殊
内部 经营报表、内部通讯录 员工可读
敏感 手机号/邮箱/消费记录 加密 + 授权 + 脱敏展示
核心 支付流水/身份证/密钥 最高防护 + 审计
【脱敏手法】
手机号：138****5678（中间打星）
身份证：110***********1234
姓名： 张* 或 匿名化
邮箱： zh***@qq.com
测试环境：全量假数据（合成数据），绝不用真数据
【合规四件套（个保法）】
告知-同意：收集前说清楚，用户点头才行
最小必要：只收业务要的，不多收
可删除：用户要求删，必须能删干净
数据出境：跨境传输要评估（敏感数据有红线）
【数据血缘 × 安全】
知道敏感数据流到哪了 → 才能管得住
血缘图 + 分级标签 = 数据安全的地图某次外包测试误用了生产库的完整用户数据，虽然没出事但被安全审计点名。治理整改后：测试环境一律用合成数据、所有查询走统一数据服务层（自动脱敏）、敏感字段加密存储——之后每次审计都一次通过，还顺手满足了政企客户的数据安全尽调。
安全合规术语
- 数据分级分类：公开/内部/敏感/核心——防护强度的依据。
- 脱敏：打星、加密、假名化、匿名化——用数据但不碰隐私。
- 加密存储 / 传输：敏感字段加密、全链路 HTTPS（衔接密码学）。
- 访问控制与审计：最小权限 + 全程留痕——谁看了谁的数据。
- 个保法合规：告知-同意、最小必要、可删除、出境评估。
- 合成数据：测试环境用「假但像真的」数据——安全与开发两不误。
本站收获：安全合规 = 分级分类（分清轻重）+ 脱敏加密（用而不泄）+ 授权审计（全程留痕）+ 合规底线（个保法）。数据越干净越值钱，也越要管得严。
质量运营：监控与告警
质量规则 · 评分看板 · 自动告警 · 数据可观测性数据干净一天不难，难的是「天天干净」。质量运营 = 把质量检查变成自动化流水线：每天体检、自动打分、超标告警。
把第 2 站的「六维体检」自动化，就是质量运营的骨架——每条数据表配一套质量规则：
- 完整性：category 缺失率 < 1%
- 唯一性：订单号重复数 = 0
- 有效性：金额 ∈ (0, 100万)、分类必须在主数据表里
- 及时性：今日数据最迟 T+1 早 6 点到位
规则每天自动跑 → 每张表一个质量评分 → 低于阈值自动告警（钉钉/邮件）→ 数据管家接单整改。这就是数据质量运营，近年还升级成了数据可观测性（Data Observability）——不只是「数据在不在」，而是「数据好不好、管道健不健康」全看得见。
数据质量看板 —— 2026-09-09
─────────────────────────────────────
表 质量分 核心问题 状态
orders 订单表 96 ✓ 全部规则通过 🟢
users 用户表 91 ⚠ 手机号格式 1.2% 异常 🟡 已提单
chat_logs 对话日志 78 🔴 category 缺失 8% 🔴 告警!
summary 汇总宽表 88 ⚠ 昨日报表延迟 2h 🟡 处理中
【规则引擎（示例）】
规则：orders.amount ∈ (0, 1000000) AND 非空
频率：每日 03:00 跑
告警：质量分 < 85 → 钉钉 @数据管家
整改闭环：告警 → 提单 → 根因分析 → 修复 → 复测通过
【数据可观测性（进阶）】
不只是「表有没有数据」，还有：
管道延迟、数据漂移（分布突变）、Schema 变更
→ 数据「生病」前就有征兆，提前干预质量运营术语
- 数据质量规则：把六维要求写成可自动执行的检查项。
- 质量评分：每张表的健康分——管理层的「仪表盘」。
- 自动告警 / 整改闭环：发现问题 → 提单 → 修复 → 复测——不闭环等于没发现。
- 数据漂移检测：数据分布突变预警（如某分类突然归零）——质量问题的「前哨」。
- 数据可观测性（Data Observability）：数据管道全链路健康可视——数据版的监控系统。
- 质量运营 KPI：整体质量分、问题平均解决时长——治理效果的量化。
「orders 表分类缺失率突增到 8%」告警弹出——数据管家一查：是网页端新版本发版后，新分类没进主数据表。整改：新分类补录主数据 + 管道映射更新，2 小时恢复，质量分回到 96。没有监控的话，这个坑要等老板月底看报表才发现。
本站收获：质量运营 = 规则自动化 + 评分看板 + 告警闭环 + 可观测性。让「数据干净」从「一次项目」变成「天天发生的日常」。
平台架构：数仓与数据湖
ODS/DWD/DWS/ADS · 数仓分层 · 数据湖 · 湖仓一体清洗好的数据住哪？不能住 Excel。数据仓库和数据湖，就是数据的「正规住宅」——分楼层、分区域，各住各的用途。
数据仓库（数仓）是「精装修公寓」：数据按主题组织、清洗到位、方便分析。经典四层架构：
- ODS 贴源层：原样存一份（历史档案室，不动）。
- DWD 明细层：清洗标准化后的明细（干净的房间）。
- DWS 汇总层：按主题汇总（日营收、周留存……）。
- ADS 应用层：给报表/BI 直接用的结果（客厅）。
数据湖是「大仓库」：什么格式都收（结构化/半结构化/日志/图片），先存着再说，要用了再洗——适合探索和研究。现在的趋势是湖仓一体：湖的便宜灵活 + 仓的规范可靠，一套平台通吃。
订单原始数据
↓ ODS 贴源层（原样保存，只追加）
订单表_raw
↓ DWD 明细层（清洗 + 标准化 + 主数据映射）
订单明细表（干净、口径统一） ← 第3-5站的手艺在这层
↓ DWS 汇总层（按主题聚合）
日营收汇总 / 分类消费汇总 / 用户留存
↓ ADS 应用层（面向消费）
经营日报 / 老板看板 / 账小灵分析API
【选型参考】
传统数仓：MySQL/Hive + 调度（中小公司起步）
云数仓：Snowflake / BigQuery / 云上 MaxCompute
数据湖：对象存储 + Spark / Iceberg / Hudi / Delta
湖仓一体：Iceberg + Spark（近年主流）
实时数仓：Flink 计算 + Kafka（账小灵的实时推荐）
【数仓建模术语】
星型模型：事实表 + 维度表（主数据的数仓形态）
事实表：可累加的度量（订单金额）
维度表：描述性属性（时间/分类/用户）平台术语
- 数仓四层：ODS → DWD → DWS → ADS——分层解耦，各司其职。
- 数据湖：原始数据大仓库——先存后洗，灵活便宜。
- 湖仓一体：湖的灵活 + 仓的规范——当前主流演进方向。
- 事实表 / 维度表：星型模型的两大主角——数仓建模基础。
- 实时 vs 离线数仓：Flink 秒级 vs Spark/批处理小时级——账小灵实时分析用实时。
- ETL 与数仓的关系：ETL 管道是「搬家队」，数仓是「新家」——第 4 站和第 9 站是一对。
治理前：运营用 Excel 手动汇总，每月 3 天做报表。治理后：数据进数仓四层，BI 工具直接连 ADS 层——运营拖拽即出看板，账小灵的分析接口直接读 DWS 汇总；数据湖里躺着全量原始日志，新产品要探索随时捞。报表从「月更」变「实时」。
本站收获：平台 = 数仓分层（干净+规范）+ 数据湖（灵活+便宜）+ 湖仓一体（趋势）。清洗的终点，是把数据送进一个「住了舒心、找得到、用得起」的家。
资产变现：治理的终点
数据资产 · 指标口径 · 数据产品 · 数据驱动治理不是「成本」，是「投资」。数据干净了，才能变成资产、变成产品、变成决策依据——这一站，看治理如何回报。
老板最爱问：「投了这么多钱搞治理，回报呢？」答案在这四层——
- 数据资产：干净、有标准、有归属的数据，才叫「资产」——能进资产负债表的那种。
- 指标口径统一：全公司「营收」一个定义——开会不再吵「你的数和我对不上」。
- 数据产品：把数据做成可消费的东西——经营看板、用户画像服务、账小灵的分析接口、对外 API。
- 数据驱动决策：老板不再拍脑袋——「A 方案 B 方案，看数据说话」。
【治理前】
老板问：这个月到底赚多少？
财务说 A 数，运营说 B 数，开发说「看日志」
→ 开 3 次会，吵 2 小时，结论：再查查
【治理后】
统一指标口径：营收 = 已支付订单金额合计（全公司唯一定义）
经营看板（ADS 层）：日更、可下钻（按渠道/分类/地区）
老板 5 分钟看完：营收、成本、留存、各分类健康度
→ 决策从「拍脑袋」变「看数据」：砍掉亏损渠道、加投高毛利分类
【数据产品矩阵（变现路径）】
内部：经营看板 / 用户画像 / 风控规则 / 账小灵个性化
外部：数据 API / 行业报告 / 数据合作（合规前提下）
【数据文化的标志】
员工说「我们看下数据」而不是「我觉得」
——治理成功的最高境界资产化术语
- 数据资产：有标准、有质量、有归属、可计量价值的数据。
- 指标口径：每个核心指标的唯一官方定义——「营收」是什么，全公司一个答案。
- 数据产品：数据能力的封装——看板、画像、API、分析服务。
- 数据驱动决策：用数据代替「我觉得」——治理的终极回报。
- 数据服务（API）：把干净数据开放给业务系统/AI 应用（账小灵就是消费者）。
- 数据文化：全员用数据说话的组织氛围——比任何工具都值钱。
治理项目收官后：经营看板每天 8 点自动更新（老板的晨会标配）；账小灵的分析从 DWS 汇总层取数，消费洞察终于和财务对得上；风控团队用干净数据建了「异常消费预警」——抓到 3 起盗刷。数据治理的成本，三个月就赚回来了。
本站收获：资产变现 = 统一口径（不再吵架）+ 数据产品（能消费）+ 驱动决策（看数据说话）。治理的终点不是「干净」，是「值钱」。
速查：清洗函数 + 治理成熟度
干活的工具表和自评表Pandas 清洗函数速查
| 场景 | Pandas | SQL |
|---|---|---|
| 补缺失 | fillna(value / method="ffill")、dropna() | COALESCE(col, 默认值) |
| 去重复 | drop_duplicates(subset=[键]) | ROW_NUMBER() OVER(PARTITION BY 键) |
| 异常值 | quantile() + IQR 过滤 | WHERE amount BETWEEN 下限 AND 上限 |
| 格式统一 | str.strip() / str.lower() / to_datetime() | TRIM() / LOWER() / CAST() |
| 类型转换 | astype() / to_numeric(errors="coerce") | CAST(col AS DECIMAL) |
| 关联整合 | merge() / concat() | JOIN / UNION ALL |
数据治理成熟度自评表（照着打勾）
| 能力域 | L2 受管级标志 | L3 稳健级标志 |
|---|---|---|
| 数据标准 | 有编码规范文档 | 主数据统一，各系统强制引用 |
| 数据质量 | 有问题时有人处理 | 质量规则自动化 + 看板 + 告警 |
| 数据架构 | 有数仓雏形 | 四层架构 + 血缘完整 |
| 数据安全 | 有分级清单 | 脱敏加密 + 授权审计 + 合规检查 |
| 数据应用 | 手工报表 | BI 自助看板 + 数据 API |
| 数据治理 | 有角色有制度 | 制度被执行、有治理委员会例会 |
治理是「让数据一直干净，并且有人负责」。
数据干净了，报表才可信、AI 才聪明、决策才靠谱——
数据不是成本，是埋在公司地下的金矿，
而清洗与治理，就是那台淘金机。