大家好，我是数据库小学妹 👋
今天聊一个我以前特别容易混淆的话题——数据库架构。
说来惭愧，我刚入行那会儿。领导让我说说公司的数据库架构。我憋了半天，来了一句："我们用的MySQL，主从复制，读写分离。"领导看了我一眼，说了句让我记到现在的话："这不是架构，这是选了个产品。"
当时我不理解，后来踩的坑多了，才慢慢明白。数据库架构不是选一个库就完事。你得想清楚：数据怎么存、怎么流、出了问题谁负责、写入规范是什么。是一整套规矩。
今天就结合我自己的踩坑经历，聊聊数据库架构到底是什么、怎么演进的、以及怎么设计。
一、先搞清楚：数据库架构到底是什么？
很多人把数据库架构等同于"用什么数据库"。
打个比方：你在城市里盖楼，选了钢筋水泥——这叫选建材。但"这片区域建什么、主干道怎么走"——这才叫城市规划。
数据库架构也是一样的道理。你得回答清楚五个问题：
| 问题 | 含义 | 城市规划类比 |
|---|---|---|
| 有什么数据？ | 核心业务实体有哪些 | 住宅区、商业区分别是什么 |
| 放在哪？ | 数据分布在哪些系统里 | 各功能区怎么分布 |
| 怎么流？ | 数据从哪来到哪去 | 道路管网怎么走 |
| 按什么规则？ | 命名规范、质量标准 | 门牌号和交通规则 |
| 谁来负责？ | 每份数据的Owner | 物业管理和市政执法 |
这五个问题没答清楚，光选了个数据库，后面一定会出问题。
我之前就犯过这个错。刚到公司的时候，业务系统各自配一个库。CRM一个、ERP一个、财务一个。老板要看跨部门报表，三个部门的数字对不上。每家管每家的账，根本没法统一。
这就是典型的"有数据库，没架构"。
二、架构演进：从一间平房到智慧城市
理解架构怎么设计，先看看它是怎么一步步长大的。
2.1 阶段一：各管各的——独立筒仓
最早期的架构就是没有架构。每个系统配一个库，互不相通。
优点是简单，缺点也明显——数据孤岛。想做跨系统分析？只能写脚本去对方库里手动捞数据。效率低不说，数据还不一定对得上。我后来接手的几个项目，前期都是这么搞的。后面想整合才发现到处是坑。
2.2 阶段二：建中央账本——数据仓库
为了解决孤岛，企业开始搞ETL（抽取-转换-加载），把各系统的数据清洗后统一放进数据仓库。
这是第一次系统性的架构设计。有了统一的维度定义和标准模型，老板终于能看到一份各方认可的报表了。我第一次看到数仓的时候，觉得"哇好高级"。后来才知道这是最基础的操作。
但互联网时代一来，日志、图片、视频涌进来。传统数仓存不下也处理不了了。
2.3 阶段三：先倒进来再说——数据湖与湖仓一体
Hadoop带来了数据湖的思路：先不管格式，把原始数据全倒进来，之后再按需处理。
听着很美好，但很多公司的数据湖很快变成了"数据沼泽"。数据堆了一堆，没人知道里面有什么。业务根本用不起来。
于是湖仓一体出现了：在低成本的对象存储上面，加一层数仓级别的事务管理和质量控制。便宜的底子上盖了规范的管理，两头好处都沾一点。
2.4 阶段四：各管各的但有规矩——数据网格
这是最新的趋势。数据网格的核心思路：各业务域管自己的数据，把它当"产品"运营，对外提供标准接口。
架构师的职责从"画中央规划图"变成了"制定联邦标准"。
不过说真的，这个对组织成熟度要求极高。搞不好就是从旧的数据孤岛，走向新的数据孤岛。我看到不少公司盲目跟风，结果比之前还乱。
架构没有最好的，只有最合适的。别看大厂用了什么就跟着上。先看看自己处在哪个阶段。
三、三层设计法：别上来就选数据库
这是我踩坑最深的领悟。很多数据项目的失败，根源在于跳过了前面两层。直接在最后一层建表。
3.1 第一层：概念模型——给老板看的
这一步不涉及任何技术。你要梳理清楚公司的核心业务实体是什么。
比如电商公司：用户、订单、商品、门店、营销活动。先把这些定义清楚。各部门对"有效订单"达不成共识，后面系统再牛也白搭。
这就像城市的功能分区图。"这一片是住宅区，那一片是商业区"。决策者一看就懂。
3.2 第二层：逻辑模型——给架构师看的
有了业务概念，接下来设计数据怎么分层清洗和流转。大部分公司用的都是这个四层结构：
贴源层（ODS） → 原封不动把业务数据抽过来
明细层（DWD） → 统一格式、去脏数据、标准化字段
汇总层（DWS） → 按业务维度聚合成主题数据
应用层（ADS） → 面向报表和应用的最终数据
打个比方：ODS是原材料仓库，DWD是加工厂，DWS是货架上的成品，ADS是摆在你面前的那盘菜。
这一层还要画清楚数据血缘。哪张表的数据从哪来的、中间经过了什么处理。出了问题顺着血缘往回追，快速定位是哪个环节出了岔子。
我之前接手过一个项目。"月活用户数"比实际少了一半。查了两天才发现，中间某张汇总表的过滤条件写错了。一部分正常用户被过滤掉了。有完整的数据血缘文档，半小时就能定位。
3.3 第三层：物理模型——给工程师看的
前面两层确定了，最后才是选什么数据库、用什么存储方案。
比如：
- 贴源层数据量大、不需要频繁查询，用对象存储就够了
- 明细层需要快速查询，选行存或列存数据库
- 实时推荐场景，用内存数据库
- BI报表从数据仓库出
这一步才是大多数人心目中的"数据库架构"——但它只是最后一层而已。
一句话说：先画规划图（概念层），再定规矩（逻辑层），最后选建材（物理层）。顺序不能反。
四、存储架构选型：MPP、Lambda、Kappa怎么选？
到了物理层，存储架构的选型也是个让人头疼的事。我最早接触这块的时候分不清这几个概念，后来在项目里实际踩过坑才搞明白。
4.1 MPP架构——分而治之
说白了就是把一个大活拆成很多小活，分给多台机器同时干。
每台机器有自己的计算和存储，通过网络配合。加机器就能提升处理能力，扩展性不错。适合跑大数据量的复杂分析查询，比如数据仓库、BI报表这些场景。
4.2 Lambda架构——批流分开跑
早期的经典方案，同时搞两条路：
- 批处理层（用Spark等）处理历史数据，保证准确性
- 速度层（用Flink等）处理实时数据，保证低延迟
- 服务层把两边结果合并
优点是成熟、坑少。缺点嘛——两套代码要保持逻辑一致，维护起来想哭。资源也要双份，成本不低。而且数据一致性是个老大难。
我在一个项目里就遇到过，批处理和流处理的结果对不上。排查了半天才发现，两边的时间窗口定义有细微差异。这种问题在Lambda架构下特别容易出现。
4.3 Kappa架构——一切皆流
为了解决Lambda的复杂性，Kappa提出"一切皆流"的思路。所有数据都走消息队列进来，用一套流引擎统一处理。批处理？只是流处理的一个特例而已。
架构简单了，代码只维护一套就行。但代价是对消息队列的长期存储能力和流引擎的重处理能力要求很高。不是所有团队都扛得住。
4.4 湖仓一体——灵活与规范的融合
这是目前用得比较多的方向。在低成本的对象存储上，通过Iceberg、Hudi这些表格式，加上ACID事务和版本管理。把数据湖和数据仓库捏到一起。
简单说：存的便宜，管的规范，查的也不慢。三样能占两样半，已经比之前的割裂状态好很多了。
选型没有标准答案。业务能容忍多大的延迟、团队能扛多高的运维复杂度，才是决定因素。别为了追新技术把架构搞复杂了。
五、从"人治"到"自治"：架构的未来方向
最后聊聊我观察到的一个趋势。
现在大部分公司做数据库运维还是那套老路子。装监控、设告警、出了问题DBA肉眼排查。有时候一个慢查询排查半天都找不到根因。全靠经验和直觉。
未来的方向是走向"主动预警、自我优化"的自治架构。我关注到两个核心技术方向：
第一个是eBPF，能在操作系统内核层面无侵入地采集数据库行为数据。相当于给数据库做了个CT，SQL执行的每一步都看得清清楚楚。
第二个是AI根因分析加智能体执行。机器学习模型自动识别异常、定位原因。然后通过智能体把优化操作自动执行掉。出问题不用等DBA了，系统自己就能诊断甚至修复。
不过说句实在话，现阶段大多数公司还在解决"有没有架构"的问题。离"自治"还有很长的路。但了解这个方向，至少做架构设计的时候能留出演进空间。
六、避坑清单
最后分享几条我自己踩过的坑，都是真金白银换来的教训~
第一，别把"买了什么产品"当成架构。 我最早就犯过这个错。以为用了MySQL主从复制就是有架构。后来发现，没有数据标准、没有血缘机制、没有Owner，产品再好也是摆设。架构是一套规则和蓝图，不是一堆服务器。
第二，数据量小的时候别上重型架构。 之前有个项目，核心数据不到500GB。团队非要上Hadoop集群。结果运维成本比业务价值还高。折腾半年还是回退到单机加合理索引。一台高配单机加上好的索引设计，够跑赢大多数场景了。
第三，跳过概念层和逻辑层直接选型，是最大的隐患。 这个坑我踩过两次。最近一次，项目刚启动，团队就花了两周讨论用什么数据库。争论选PostgreSQL还是MySQL，方案写了一大堆。结果上线第一周，运营和财务就打起来了。报表数字对不上。排查才发现，各部门对"有效订单"的定义完全不一样。有的按已付款算，有的要排除退款，有的还要求签收确认。我们在数据库层面做了再多优化，底层定义不统一，数据就是对不上。最后推倒重来，先花一个月把各部门的业务规则理清楚，再重新设计。先搞清楚业务规则，再谈技术选型。顺序不能反。
好啦，今天的分享就到这里。架构这个话题太大，一篇文章只能搭个框架。但我觉得很多人最缺的不是技术细节，而是认知。你得先搞明白架构在管什么，才能去选型、去设计。
你在实际项目中遇到过哪些架构方面的坑？欢迎在评论区聊聊~
我是数据库小学妹，咱们下篇见 👋
