数据架构与现代数据栈

01

数据住在哪里、如何流动

把它想成一段有阶段的旅程：数据在源系统里被创建，然后被摄取进 中央存储，被转换成干净、可用的形状，最后被供给给仪表板、模型 与分析师。每一个数据平台都是这四个阶段的某种安排，而有趣的决定在于存储与转换在哪里发生——而这恰恰是过去十年里发生了剧变的地方。

02

两份工作：OLTP 对 OLAP

那个基础性的划分，来自数据库页：数据库做两份 非常不同的工作，而你不会想把它们混在一起。

• OLTP（事务型）——运行业务的那些运营数据库：快速、微小的读与写（「记录 这笔销售」「更新这个账户」）。为许多小操作而优化。
• OLAP（分析型）——为分析而建的系统：扫描并聚合巨量数据（「今年各地区的 总销售额」）。为大问题、而非小更新而优化。

在活的事务数据库上跑沉重的分析，会拖垮应用，所以一套分析架构的全部要点，就是把数据从 运营系统里搬出来、搬进一个为分析而建的地方。那个地方就是仓库——或者湖，或者湖仓。

03

仓库、湖与湖仓

三大存储范式，以及从一个到下一个的弧线：

• 数据仓库——把结构化的、清洗过的数据存进一个定义好的模式里（写时 模式：在存之前先把它塑形）。对快速、可靠的 BI 与 SQL 极好——但僵硬， 且不适合原始或非结构化数据。
• 数据湖——把一切都存下来，原始的、任何格式的（读时模式：先存， 查询时再施加结构）。便宜又灵活——但很容易变成一个「数据沼泽」：无治理、无文档、难以信任。
• 数据湖仓——现代的融合：湖式的、对原始数据廉价而灵活的存储，加上叠在 上面的仓库式结构、事务与治理。它的目标是给你一个同时容纳原始数据与分析就绪数据的平台，也是 2020 年代占主导的设计。

04

ETL 对 ELT：改变了一切的那次转变

最大的实际变化之一，是两个字母的顺序。经典的做法是 ETL——抽取（Extract）、转换（Transform）、加载（Load）：把数据拉出来，在把它加载进仓库之前清洗并重塑它。你不得不如此，因为仓库的存储与算力稀缺而昂贵。

廉价、可扩展的云存储把这个翻转成了 ELT——抽取、加载、转换：先把原始数据加载进仓库，再用仓库（如今充裕的）算力在仓库内部转换它。好处是实打 实的：你保留了原始数据（所以需求变化时你能在之后重新转换它）、转换是受版本控制的 SQL 而非 不透明的管道，而且更快、更灵活。这单单一次重新排序，就是让现代数据栈成为可能的东西。

05

现代数据栈

「现代数据栈」是如今标准的、模块化的、云原生的一套工具，围绕 ELT 组装而成。每一层都是一个 专门的、可替换的组件：

转换层值得有个名字：dbt（data build tool）成了行业标准，因为它让分析师把转换写成受版本控制的、经过测试的、模块化的 SQL——把软件工程纪律带到了数据建模上。一个编排器调度并串起整条流，而BI 工具坐在 上面做仪表板。

06

青铜、白银、黄金：奖牌架构

在湖仓内部组织转换的一种流行方式，是奖牌架构——数据流经三个质量层级：

• 青铜——原始的、按摄取原样的数据，未经触碰（你对到达之物的忠实记录）。
• 白银——清洗过、验证过、规整过的（那个数据准备层级——去重、定类型、连接）。
• 黄金——业务层面的聚合与特征，分析就绪（仪表板与模型实际消费的）。

这是一种干净的、逐级的精炼——每一层都改善质量与结构——而保留原始的青铜层本身就是一项可复现性的胜利：你总能从原初的真相重建白银与 黄金。

07

集中式对数据网格

最后一个组织层面的问题：该不该由一个中央数据团队拥有一切？传统模型是集中式的——一个团队、一个 仓库、一个可信来源——这易于治理，但随着机构成长可能变成一个瓶颈。数据网格是相反的 想法：去中心化所有权，让每个领域团队把自己的数据当作一件产品来拥有， 治理则以联邦的方式处理。它更像是一种组织哲学，而非一项技术，并且它更适合大型、复杂的机构，而非 小型的——是中央控制与领域自治之间的一个权衡，而非一次普适的升级。

08

它在我工作中的体现

09

60 秒回顾

仓库/湖/湖仓的弧线、ETL→ELT 的转变、现代数据栈（dbt）的组件，以及奖牌架构与数据网格的模式， 反映了当前的数据架构参考文献以及亲身的工作。