Data Lake Management 2019 — 数据湖从文件堆变成可治理资产

是什么

Data Lake Management 讲的是：一家公司把各种原始数据先倒进一个大池子后，怎样还能找到、看懂、清洗、整合和追踪这些数据。

日常类比：数据湖像一个超级共享仓库。销售、客服、爬虫、日志系统都把箱子搬进来，但箱子大小不同、标签不同、有些还没写日期。管理数据湖，就是给这些箱子补标签、建目录、做质检、找相似箱子、记录版本，避免仓库变成垃圾堆。

这篇 PVLDB 2019 tutorial 不是发明一个新系统，而是把数据湖的管理问题系统列出来：摄入、抽取、清洗、发现、元数据、整合、版本。它适合作为理解 lakehouse 之前的入口，因为 lakehouse 很多设计就是在补这些坑。

为什么重要

不理解这篇，下面这些事都很难解释：

• 为什么企业明明有数据仓库，还要建数据湖：仓库要求先整理再入库，湖允许先保留原始数据再按需处理
• 为什么数据湖容易变成 data swamp：只存文件不存语义，用户最后不知道哪个数据能用
• 为什么数据发现和数据整合会绑在一起：先找到能 join / union 的表，才谈得上临时拼出分析结果
• 为什么 lakehouse-2021 和 delta-lake-2020 强调事务、schema、版本和治理：它们是在给数据湖补管理能力

核心要点

1. 数据湖的价值来自“先收下，再慢慢用”。类比：搬家时先把所有东西放进仓库，之后再分类。好处是不会丢原始材料，坏处是后面必须补目录、标签和质检。

2. 管理难点不只在存储，而在理解。湖里有日志、网页、表格、文档、二进制文件，格式和 schema 都可能未知。系统要回答“这份数据是什么、谁生成的、和谁相似、质量如何、能不能 join”。

3. 论文的中心愿景是按需回答查询。今天很多湖只是中转站，数据要先清洗并装进仓库才真正可用。作者希望未来能在查询时自动完成发现、抽取、清洗和整合，让湖里的原始数据直接产生价值。

实践案例

案例 1：摄入时只做轻量登记

假设爬虫每天把开放数据集下载进湖里。摄入阶段不能做太重的分析，因为网络慢、文件多、延迟要求高；但它至少要留下“箱子标签”。

{
  "path": "raw/open-data/city-budget-2026.csv",
  "source": "city-open-data",
  "ingested_at": "2026-07-09T10:00:00Z",
  "checksum": "sha256:8a1...",
  "version_hint": "daily-snapshot"
}

逐部分解释：

• path 告诉你箱子放在哪，不等于它已经被理解
• source 和 ingested_at 是未来追责、刷新、删除时的基础线索
• checksum 可以发现重复文件，也能判断“同名文件内容有没有变”
• version_hint 先记一个粗粒度版本，后续版本管理系统再精细处理

这对应论文的 Data Ingestion：摄入主要做文件 bookkeeping、版本线索和浅层 sketch，而不是一次性完成深度清洗。

案例 2：抽取和清洗不要等到最后

湖里常见问题是“所有字段都先当字符串”。如果等到分析前才发现日期、金额、地区写法混乱，错误会一路传播到发现和整合阶段。

-- 把原始字符串抽取成更稳定的字段
SELECT
  CAST(order_id AS BIGINT) AS order_id,
  PARSE_DATE(order_date) AS order_date,
  NORMALIZE_CITY(city) AS city,
  CAST(amount AS DECIMAL(12, 2)) AS amount
FROM raw_orders;

逐部分解释：

• CAST(order_id AS BIGINT) 是抽取：从原始文本变成有类型的数据
• PARSE_DATE(order_date) 是清洗入口：统一不同日期格式
• NORMALIZE_CITY(city) 是质量规则：把“北京”“北京市”“Beijing”对齐
• DECIMAL(12, 2) 防止金额被当成普通字符串排序

论文强调，传统清洗通常依赖正确 schema 和完整约束；数据湖恰好缺这些东西。所以抽取、元数据和清洗不能完全分开，要尽早互相补信息。

案例 3：查询驱动的数据发现和整合

数据分析师手里有一张用户表，想找能补充“城市收入”“消费分层”的外部表。数据湖系统不能只做关键词搜索，还要判断哪些表能 join 或 union。

query_table = "users(user_id, city, age)"

candidates = discover(
    query_table,
    goal="find tables joinable on city or user_id"
)

result = integrate(query_table, candidates, keys=["city"])

逐部分解释：

• discover 负责从湖里找“可能相关”的数据集，不要求用户知道文件名
• goal 说明发现不是普通搜索，而是服务于后续整合
• integrate 才是真正拼表，可能要处理字段名不同、值域不同、质量不稳
• keys=["city"] 是一个简化版 schema mapping：告诉系统按什么语义连接

这就是论文说的 query-driven discovery：找表和拼表不是两步独立工作，而是一条按需分析流水线。

踩过的坑

1. 把数据湖当便宜硬盘：只把文件扔进去，不建目录和血缘，最后搜索成本比重新采集还高。

2. 把数据湖当数据仓库：强行要求所有数据先建模再入湖，会失去保存原始数据和快速试验的优势。

3. 清洗太晚：抽取器产生的系统性错误会污染后续发现、join、union，最后很难定位根因。

4. 版本只靠文件名：data_final_v3_new.csv 这种命名无法回答谁改了、改了哪里、能否回滚。

适用 vs 不适用场景

适用：

• 企业有大量异构数据源：日志、爬虫、CSV、JSON、文档、旧系统导出
• 数据科学团队需要快速试验，先保留原始输入和中间结果
• 分析任务经常要找“有没有类似表”“能不能补特征”“能不能临时 join”
• 组织想在上数据仓库之前保留低成本、可复用的数据资产

不适用：

• 数据量很小，单个数据库或对象存储目录已经够清楚
• 业务强依赖固定 schema、强事务和外键约束，直接用关系数据库更合适
• 团队没有治理投入，只想“先都存下来以后再说”
• 低延迟在线交易系统，数据湖不是替代 OLTP 数据库的方案

历史小故事（可跳过）

• 2000 年代：gfs、mapreduce、hdfs-2010 把“海量文件 + 批处理”这条路铺起来。
• 2010 年前后：企业发现数据仓库太慢太贵，开始把原始日志和外部数据先放进 Hadoop 生态。
• 2015 年左右：data swamp 这个词流行起来，大家意识到“能存”不等于“能用”。
• 2019 年：这篇 tutorial 把数据湖管理问题归纳成一组数据库研究议题，而不只是工程运维问题。
• 2020 年以后：delta-lake-2020、Apache Iceberg、lakehouse 把事务、schema、版本和 catalog 带回湖上。

学到什么

• 数据湖的核心矛盾：越想灵活收纳原始数据，越需要后续管理系统补语义和质量。
• 发现、抽取、清洗、整合是耦合的：找不到相关表就无法整合，schema 不准又会影响清洗。
• 元数据是湖的地图：没有 owner、schema、血缘、相似关系、版本信息，湖再大也很难复用。
• lakehouse 不是凭空出现：它是在数据湖管理挑战之上，把仓库能力逐步补回来的工程路线。

延伸阅读

• 论文 PDF：Data Lake Management: Challenges and Opportunities
• lakehouse-2021 —— 后续把数据仓库能力搬回数据湖的代表性论文
• delta-lake-2020 —— 用事务日志给湖上的文件补 ACID、schema 和版本
• snowflake-2016 —— 云数仓路线，与数据湖路线形成对照
• bigtable-2006 —— 结构化但非 SQL 的大规模存储，帮助理解“存储”和“管理”不是一回事
• hdfs-2010 —— 早期数据湖常见的底层文件系统背景

关联

• lakehouse-2021 —— 直接回应数据湖缺事务、治理和高性能查询的问题
• delta-lake-2020 —— 用日志和版本机制解决湖上文件难管理的痛点
• snowflake-2016 —— 代表“先结构化再分析”的云数仓方向，可与数据湖对比
• mapreduce —— 数据湖常依赖分布式批处理框架消费原始数据
• hdfs-2010 —— Hadoop 数据湖的典型存储底座
• bigtable-2006 —— 提醒我们大规模数据系统必须同时设计数据模型和访问方式
• dataflow-model-2015 —— 对应湖中高速度数据和实时摄入后的处理问题

反向链接

• lakehouse-2021 —— Lakehouse 2021 — 把数据湖和数仓合成一套开放平台