设计好的数据架构

一句话

你以为好的数据架构是一张选对了工具的终态蓝图，其实本章给它下的定义是：支撑企业不断演进的数据需求，靠的是在仔细权衡之后做出灵活、可逆的决策。关键词是「可逆」——仓、湖、湖仓、Lambda、数据网格都只是不同场景下的权衡，没有一种是终点。

Glossary · 术语表

坐标

Part I「基础与构件」第 3 章。第 2 章把数据架构列为生命周期的六条暗流之一，这一章把它单独展开；第 4 章接着讲在这些原则下怎么选具体技术。对应现实里「数据平台该怎么搭、几年后还能不能改」的架构评审。

这章要解决什么

数据团队最贵的错误往往不是某条管道写错，而是架构把自己锁死：一个花了三年建成的本地数仓，业务换了方向就跟不上；所有原始数据倒进一个湖，三年后没人说得清哪些可用、哪些含个人信息该删；一个中心团队排着几十个部门的需求，新报表要等一个季度。

本章先给数据架构下定义，再给出九条判断「好不好」的原则，然后把业界几种主流架构——数据仓库、数据湖、湖仓、Lambda、Kappa、Dataflow 统一模型、数据网格——放在同一把尺子下比较。作者特别强调：数据工程师未必是架构师，但必须懂架构，能看懂一个决定是可逆还是不可逆。

核心内容，讲透

一、什么是数据架构：运营架构、技术架构与两种门

作者从企业架构（TOGAF、Gartner 等多种定义）出发，归纳出自己的版本：企业架构是为支撑企业变化而做的系统设计，靠在仔细权衡后做出灵活、可逆的决策；数据架构是它在数据这一侧的子集。数据架构又分两层：运营架构（operational architecture）回答「做什么」——要支持哪些业务流程、数据质量要多高、从数据产生到可查询能容忍多少延迟；技术架构（technical architecture）回答「怎么做」——数据怎么采集、存储、转换和服务。比如「每小时把 10 TB 数据从源库搬进数据湖」就是技术架构层面的描述。

「可逆」借用了 Jeff Bezos 的说法：单向门（one-way door）是一旦走过去几乎无法回头的决定，例如卖掉公司、把核心系统写死在某个专有平台上；双向门（two-way door）是随时能退回的决定，例如把对象存储里一批数据换到更便宜的存储层，发现不合适再换回来。双向门应该快做、多做；单向门才值得慢、值得开评审会。好架构的作用，是把尽可能多的决定变成双向门。

二、九条原则：从云厂商的框架里提炼

作者参考了 AWS Well-Architected Framework 和 Google Cloud 的云原生架构原则，归纳出九条：

• 明智地选择公共组件：对象存储、版本控制、编排、可观测这类组件让多个团队共享，避免重复造轮子；但不要强推一刀切的方案，伤害具体团队的需求。
• 为失败做规划：先定可用性、可靠性、RTO、RPO 的目标。例如一张面向管理层的日报，RTO 定 4 小时、RPO 定 24 小时就够；一条面向在线交易风控的管道可能要求分钟级。目标不同，成本可能相差一个数量级。
• 为可扩展性而设计：不只是能扩上去，还要能缩下来，甚至在不用时缩到零，用弹性（elasticity）换成本。
• 架构即领导力：架构师主要靠指导团队、沟通取舍来工作，而不是靠下命令。
• 始终在做架构：架构是持续的工作，要清楚当前的基线、目标架构，以及从前者走到后者的顺序计划。
• 构建松耦合系统：下面第三节展开。
• 做可逆的决策：技术更新太快，今天的最佳选择几年后可能就过时。
• 安全优先：从「守住边界、内网可信」的旧思路转向零信任（zero-trust），每一次访问都要验证；在云上还要理解共享责任模型——云厂商保障底层设施，你负责自己的配置和数据。
• 拥抱 FinOps：上云后，成本从一次性的硬件采购（资本支出）变成按用量计费的持续开销（运营支出）。一个写错的查询或忘了关的集群，一夜之间就能烧掉一个月的预算，所以成本要像性能一样被监控。

三、松耦合：层、单体、微服务与「绞杀者」

书中引用了亚马逊内部那份著名的 API 指令：所有团队只能通过服务接口暴露数据和功能，不允许直接读别人的数据库。它是松耦合最有名的例子——每个团队只对接口负责，内部怎么改都不影响别人。

落到数据系统：单层架构把数据库和应用放在一台机器上，最简单也最脆弱；多层架构把数据层、应用逻辑层、展示层分开。单体（monolith）把一切放在一起，好上手但难改；微服务拆成各自独立的小服务，好改但运维复杂。几个必须考虑的因素：单租户还是多租户（多租户要防「吵闹的邻居」抢资源，更要防数据串到别的客户那里）；事件驱动（服务之间靠事件异步通信，生产者和消费者互不等待）。

改造旧系统时，作者推荐绞杀者模式（strangler pattern）：不一次性推倒重来，而是让新系统一块一块接管旧系统的功能，直到旧系统可以下线。它本质上是把一次巨大的单向门拆成许多扇双向门。

四、仓、湖、湖仓：三代分析架构

数据仓库的经典定义来自 Bill Inmon：面向主题、集成的、非易失的、随时间变化的数据集合，用于支持管理决策。传统做法是 ETL——先清洗再进仓。云数仓（Amazon Redshift 开了先河，随后有 Google BigQuery、Snowflake）把计算和存储分开，按需扩缩，ELT 因此流行：先原样载入，再用仓里的算力转换。面向某个部门的精简子集叫数据集市（data mart）。

数据湖随 Hadoop 时代兴起，主张把所有原始数据先倒进廉价存储，结构等用的时候再定。问题很快出现：没有目录和治理，湖变成数据沼泽（data swamp）；数据只写不读；更新、删除单条记录极其麻烦，碰上 GDPR 要求删除某个用户的数据时尤其痛苦。

湖仓（data lakehouse）由 Databricks 提出：数据仍然放在对象存储上的开放格式文件里，但在上面加一层表格式，提供 ACID 事务、表结构管理、更新与删除，让湖拥有仓的可靠性。作者观察到，仓和湖正在相互靠拢：云数仓开始能直接查湖里的文件，湖也越来越像仓，两者正在汇成一个「数据平台」。

作者还点名了现代数据栈（modern data stack）：用现成的云服务按模块拼装，即插即用、成本可控；其价值在于降低门槛，风险在于模块太多、账单与集成都会膨胀。

五、Lambda、Kappa 与统一的 Dataflow 模型

批和流要同时满足时怎么办？Lambda 架构（Nathan Marz 提出）让两套系统并行：批处理层定期重算出准确结果，速度层用流处理给出低延迟的近似结果，服务层把两者合并后对外提供查询。它的致命问题是同一套业务逻辑要在两个系统里各写一遍，两边结果对不上时很难排查。

Kappa 架构（Jay Kreps 于 2014 年提出）作为回应：只用一套流处理平台，所有数据都是事件流；需要重算时，从日志开头重放即可。作者的评价是，它在实践中并没有被广泛采用——长期保存并重放海量日志既复杂又昂贵。

Google 的 Dataflow 模型（开源实现为 Apache Beam）走第三条路：把所有数据都视为事件，用不同类型的窗口（window）做聚合；批处理只是「有边界的流」，于是一套代码同时跑批和流。Flink、Spark 也采用了类似的思路。

六、数据网格：把数据还给业务域

以上架构大多默认一个中心团队管所有数据。数据网格（data mesh）由 Zhamak Dehghani 提出，反对的正是这种集中：公司大了，中心数据团队会成为瓶颈，而且离业务太远、不懂数据的含义。它有四条原则：

• 按业务域去中心化地拥有数据：订单数据由订单团队负责，而不是交给中心团队。
• 数据即产品（data as a product）：各域把数据当成给别人用的产品来做，要有文档、质量承诺和负责人。
• 自助式数据平台：中心团队不再替人做数据，而是提供各域都能自助使用的基础设施。
• 联邦式计算治理：安全、口径、互操作这类规则由各域代表共同制定，并尽量写成代码自动执行。

它和第三节的 API 指令是同一个思想：按组织边界做松耦合。书中还提到数据编织（data fabric）、数据中心（data hub）等名词，提醒读者这类标签层出不穷，判断时回到九条原则即可。

关键权衡与选型

表 1 · 仓、湖、湖仓：什么场景选什么

判据：数据以规整的业务表为主、团队以 SQL 为主，先上云数仓；ML 与非结构化数据占比高，或者不想被单一厂商锁定，再考虑湖仓。

表 2 · 批流并存的三种做法

表 3 · 集中式平台 vs 数据网格

为什么重要 / 落到真实系统

这一章的词汇就是数据平台架构评审的通用语言。被问「为什么选湖仓而不是数仓」，好的回答不是报工具名，而是说清：数据里结构化与非结构化各占多少、有没有 ML 场景、哪些决定是单向门、RTO 和 RPO 定多少、成本谁来盯、组织规模是否需要去中心化。云数仓侧对应 Redshift、BigQuery、Snowflake；湖仓侧对应 Delta Lake、Apache Iceberg 这类开放表格式；统一批流对应 Apache Beam、Flink、Spark。

易错点与争议

• 「架构是一次性的蓝图」。本章的定义恰恰相反：架构是持续的工作，基线、目标和过渡计划都要随业务更新。
• 「所有决定都要慎重」。把双向门当单向门来评审，会让团队慢得失去竞争力；真正该慢的是少数单向门。
• 「湖仓淘汰了数仓」。两者在相互靠拢，选择取决于数据形态和团队技能，而非新旧。
• 「先建湖，以后再治理」。没有目录、责任人和删除能力的湖，几年后就是沼泽，GDPR 删除请求会让它变成合规风险。
• 「Lambda 是批流并存的标准答案」。它的两份代码是长期负担，今天多数团队优先考虑统一模型。
• 「数据网格是一种技术」。它首先是组织变革，没有各域的数据能力与治理共识，买再多工具也落不了地；对小团队往往是过度设计。
• 时代局限与争议。书出版于 2022 年，彼时湖仓与开放表格式之争仍在进行，之后几种表格式不断走向互通。数据网格的实际落地效果业界也有分歧，不少公司只采纳了其中「数据即产品」的部分。

要点