数据架构 · 概念讲解 + 一次真实选型

一次改一行，
还是一次读一亿行

OLTP、OLAP、Lakehouse 到底在分什么？Snowflake 和 Databricks 跟我们的数据库、跟「企业大脑」是什么关系——以及最实际的那个问题：我们现在该不该上。

// 先把三个名词讲清楚，再用生产库的真实体量做判断 · 数据实测 2026-08-06

POSTGRESQL · OLTP 列存 · OLAP DELTA / ICEBERG SNOWFLAKE · DATABRICKS PARQUET + DUCKDB PGVECTOR · HNSW 家底 1,356 MB

SCROLL / 向下滚动

The Trigger · 问题是怎么冒出来的

一条橙色告警，引出一个架构问题

这不是一篇从名词讲起的科普。它起于生产环境的一次真实告警——而告警修完之后，真正值得回答的问题才浮出来。

Incident · 2026-08-05

数据库控制台弹出 exhausting multiple resources：CPU 82%、内存 76%，当天有 4 份资料写库超时失败。把 compute 从 Micro 升到 Small（2GB / 独占 CPU）之后，CPU 掉回 13%，橙条消失，之前反复失败的写入当日首次通过。

SYMPTOM问题解了，但只是"加了一档马力"

升配是有效的止血，不是答案。库还在长——它会在某个点再次顶到天花板，而那时再加一档的边际收益会越来越小。

QUESTION是不是该上一套"正经"数据平台了

市面上最常被提到的两个名字是 Snowflake 和 Databricks。要回答该不该上，得先分清三个总被混着说的名词。

本文的顺序

先用三节把 OLTP / OLAP / Lakehouse 讲清楚（这部分与具体项目无关，可当通用概念读），再用生产库的真实体量做一次有数字的选型判断，最后落到五个「不用买也能抄」的做法。

OLTP · Online Transaction Processing

一次改一行：让线上业务跑起来

联机事务处理。支撑线上业务的每一次读写——下单、改状态、锁一条记录。特点是并发高、每次只碰几行、对正确性零容忍。我们的 Postgres 就是纯粹的 OLTP。

STORAGE行存（Row-oriented）

一行数据在磁盘上连续存放。取一整行只要一次 IO——这正是"给我这个用户的全部信息"这类请求最需要的布局。

ACCESSB-tree 索引 + ACID 事务

靠索引直接跳到目标行，毫秒级点查。事务保证「转账不会只扣钱不到账」、「两个人抢同一条线索只能有一个抢到」。

WORKLOAD高并发、小事务

几千 QPS，每条只碰几行。评价标准是并发正确性与尾延迟，而不是吞吐量——这一点和 OLAP 正好相反。

落到我们自己身上

抢线索的 RPC——按「组织 + 抖音用户」锁一条线索 4 小时，两个运营同时拉单不会拉到同一个人；消息队列状态流转——从待审批到已通过到已发送，每次就改一行；行级安全（RLS）——每一次请求都要判断这个账号能看哪些组织的数据。这三件事都要求：快、准、能并发，而且错一次就是业务事故。

OLAP · Online Analytical Processing

一次读一亿行：让分析算得动

联机分析处理。回答的是「过去 90 天每个号源带来的中高意向评论，按周分组的转化率是多少」这种问题——不改数据，只扫和聚合。并发很低（可能就几个人在用），但每条查询要扫过海量的行。

STORAGE列存（Columnar）

同一列的数据连续存放。只关心两三列的聚合查询，就只读那两三列的数据——其余的一个字节都不碰。

COMPRESSION同类相邻 → 极高压缩比

一列里全是同类型、往往还高度重复的值（比如意向等级只有三四种取值），压缩率可以到几十分之一；压得越狠、要读的字节越少。

EXECUTION向量化执行

不是一行一行地过，而是一次处理一批值（SIMD 友好）。加上前两条，同一个聚合查询常常快 10～100 倍。

同一个问题 · 两种存储要读多少数据（量级示意）

行存ROW · 当前 PG ~442 MB

列存COLUMNAR ~几 MB

// 问题：441,753 条评论里，各意向等级各占多少条？
// 行存必须把每一行整行读进内存——包括几百字节的评论正文；列存只读「意向等级」那一列，且这列高度重复、压缩极狠。
// 上图为量级示意而非基准实测，用来说明差距来自哪里：不是引擎更聪明，是要搬的字节根本不在一个数量级。

HTAP

想让一套系统同时干这两件事，业内叫 HTAP（混合事务/分析处理）。Postgres 在小体量下天然就是个够用的 HTAP——这正是我们现在还不需要拆的根本原因。矛盾只在体量上来之后才变得不可调和：两类负载对存储布局的要求是相反的。

Warehouse → Lake → Lakehouse

湖仓不是凭空冒出来的，是被两代人的坑逼出来的

Lakehouse（湖仓一体）是个演化产物，按顺序讲才说得清。每一代都是在修上一代的致命伤，同时带进新的问题。

第一代
DATA WAREHOUSE 数据仓库：只收结构化数据，schema-on-write——写进去之前必须先定好表结构。 ✓ 强治理、强一致、SQL 好用　✗ 贵；存不了非结构化数据（图片、视频、日志、模型权重）
代表：Teradata → Redshift → Snowflake

第二代
DATA LAKE 数据湖：直接往对象存储（S3 / R2 / OSS）上丢原始文件，什么格式都行，schema-on-read——读的时候再解释这堆文件是什么结构。 ✓ 便宜到几乎白送，格式开放不锁厂商　✗ 没有事务、没有 schema 约束、没有治理
写一半失败就留下一堆半截文件，没人知道哪个目录是最新的——业内管这个叫 数据沼泽（data swamp）

第三代
LAKEHOUSE 湖仓一体：在数据湖的开放文件格式之上，加一层元数据 + 事务日志。这层东西就是 Delta Lake / Apache Iceberg / Hudi。于是凭空长出了：ACID 事务（写失败能回滚，不留半截数据）· Schema 演进（加字段不用重写全量）· Time Travel（能查上周三这张表长什么样）· 同一份数据同时供 SQL 分析与 ML 训练，不用再复制一份进数仓

今天
两头收敛 Snowflake 从数仓出发，补上了对 Iceberg 与非结构化数据的支持；Databricks 从湖出发，补上了 SQL 数仓能力。所以 2026 年再问「选哪个」，界限已经比几年前模糊很多——更该问的是「我到底在哪一档体量上」。

// 一句话：Lakehouse = 便宜开放的对象存储（湖的成本）+ 元数据事务层（仓的可靠性）。

顺手澄清一个常见误解

Snowflake / Databricks 都不能替代业务库。它们不服务线上流量、不做逐请求的行级安全。就算上了，也是「再加一套」而不是「换一套」——它们和 Postgres 是叠加关系，不是替换关系。

Reality Check · 先量一量自己

家底核对：我们离他们的适用区有多远

选型讨论最容易跑偏的地方，是不先量自己。以下全部是 2026-08-06 直连生产库跑出来的真实数字。

0MB

整库体积
（含索引）

0张

public schema
表数量

评论表行数
（最大业务表）

0块

知识库向量分块
（460 个条目）

表	行数	体积	性质
comments	441,753	443 MB	抓取到的评论原始数据（bronze 层）
llm_call_provenance	192,527	442 MB	模型调用审计日志 · append-only，无保留策略
scrape_jobs	200,042	170 MB	抓取任务队列 · 已有 7 天滚动窗口
videos	55,867	62 MB	视频元数据
lead_profiles	23,443	35 MB	线索画像（silver 层）
kb_chunks	3,856	28 MB	知识库分块 + 512 维向量 · pgvector HNSW
messages	26,165	14 MB	会话消息

这意味着什么

整个库 1.35 GB——塞得进一台笔记本的内存。Snowflake / Databricks 的性价比拐点在 TB ~ PB 级；我们在 GB 级。差距不是「还差一点」，是三个数量级。在这个体量上，一台笔记本上的 DuckDB 做全表聚合都在一秒以内。

Note

「企业大脑」的知识层也在这张表里：460 个条目 / 3,856 个向量分块。这个量级用 pgvector + HNSW 是正解——要到千万级分块才谈得上需要专用向量基础设施。

Cost Model · 真上要花多少

算笔账：为什么现在上是纯亏

两家的计费模型不一样，但共同点是——贵在算力，不在存储。而算力的最小档位，对我们这种体量来说全是浪费。

SNOWFLAKE按 credit 计费

Standard $2 / credit（Enterprise $3、Business Critical $4）。最小的 XS 虚拟仓 1 credit/小时，按秒计费但启动有 60 秒起步。

存储另计，约 $23–40 / TB / 月。

DATABRICKS按 DBU + 云主机双重计费

DBU 从 jobs light 的 $0.22 到 serverless SQL 的 $0.70 不等，另外还要付底层云厂商的机器钱。

这套双重计费让成本估算明显更难，基础设施常在 DBU 之上再加 50–200%。

FOR US存储费几乎为零，全在算力

1.35 GB 按 $23/TB 算是 每月三分钱。也就是说我们付的钱100% 是算力的最小档位费，而那个档位是为 TB 级设计的。

月度成本对照（同一份 1.35 GB 数据）

现状SUPABASE SMALL $14.83

Snowflake XS每天跑 2 小时 ≈ $120

DatabricksDBU + 云主机更难估

// Snowflake 一栏＝ 1 credit/小时 × $2 × 2h × 30 天，且这还只是分析侧的额外开销——线上业务库该付的钱一分不少。
// 换算下来：为一个塞得进内存的数据集，多付 8 倍于整个生产库的钱。

Diagnosis · 痛点根本不在分析侧

真凶：一张审计表吃掉了三分之一的库

回到第 01 节那次告警。它是 OLTP 的内存与算力不够，不是分析能力不够——上数仓一行也不会缓解，因为线上写入还是走 Postgres。顺着这条线查下去，找到了真正该动的东西。

Root Cause

llm_call_provenance 一张审计表就占了整库的 三分之一（442 MB），其中 101,495 行超过 30 天。它最早的记录只到 2026-06-05——两个月长出 442 MB，年化约 2.6 GB，而且没有任何保留策略。

它凭什么该被搬走

这是纯 append-only 的观测日志：写完就不再改，没有任何事务需求，线上请求也从不读它。它却和最热的业务表抢同一块内存。

对照：邻居们都已经有窗口

scrape_jobs 有 7 天滚动窗口，196,568 行里超过 30 天的是 0 行；video_stats_history 超 30 天的只有 505 行。唯一在裸奔的就是它。

判断

该做的第一件事不是买平台，是给这张表加保留窗口 + 冷数据外迁。它既是当前最大的单表负担，又是最没有事务需求的纯日志，改动风险最低、见效最直接。

Steal The Ideas, Not The Invoice

不买他们的服务，但抄他们的五个思想

「不该买」不等于「没关系」。这两家真正值钱的是架构思想，而这些思想在 GB 级同样成立，而且几乎不花钱。按 ROI 排序如下。

① LAKEHOUSE 的核心存算分离 · 冷热分层

Databricks 的本质是：热数据在库、冷数据在对象存储、按需拉起算力。这件事我们可以在自有的 R2 桶上做，成本约等于零。

做法：审计表超 30 天的十万行按月导成 Parquet 丢进对象存储，库里只留 30 天；要回溯查成本归因时用 DuckDB 直接查 Parquet，比在 PG 里扫全表还快。预计立刻释放约 300 MB——在 2GB 内存上是实打实的余量。

② MEDALLIONbronze / silver / gold 分层

原始评论与视频是 bronze，线索画像与会话是 silver，日报与统计是 gold。

铁律只有一条：报表只读 gold，永不扫 bronze。这正是「分析查询和线上业务抢 CPU」最典型的入口——值得把所有报表脚本翻一遍，看有没有偷偷直查原始表。

③ UNITY CATALOG 的精神数据治理与打标

Databricks 的 Unity Catalog 解决的是「哪些数据、谁能碰、能流到哪」。这条正好命中我们知识库的一个已知缺口——

在库的资料里只有一部分可以合规外发给客户，但库里根本没有「能不能发给客户」这个标记字段。不需要买它，加一列加一条策略就够了。这条的价值不在性能，在于它防的是合规事故。

④ TIME TRAVEL版本化与快照

Snowflake 的 Time Travel 用来回答「上周三这份数据长什么样」。我们已经在给部分配置做快照了，值得把知识库、决策规则、人设也纳进来。

配合审计表里已有的调用指纹，就能回答一个很实际的问题：这条消息当时用的是哪一版规则、哪一版人设——出问题时这是唯一能定责的线索。

⑤ 反向结论最不用抄的，恰恰是招牌 AI 功能

Databricks Vector Search 与 Snowflake Cortex Search 干的，就是我们 pgvector 那一层的活。3,856 个分块要到千万级才谈得上换专用设施。

更要紧的是：「企业大脑」的瓶颈是策展不是存储——知识条目、对话样本、决策规则的数量才是天花板，换成 Snowflake 一条也不会变多。

SUMMARY共同点：都是「布局」而非「品牌」

五条里没有一条需要新增供应商。它们要的都是把数据放对位置——热的留在事务库、冷的沉到对象存储、算好的只读汇总层、该打标的打上标。

这也是为什么它们在 GB 级就能生效：这些是架构纪律，不是规模红利。

Trigger Lines & Upgrade Ladder

什么时候该重新讨论，以及按什么顺序升

「现在不上」是有条件的结论，所以要把条件写下来——否则半年后没人记得当初为什么否决，只好从头再吵一遍。

触发线 · 任一成立即重议

Postgres 单库 > 100 GB，或单张热表 > 5,000 万行
需要跨 ≥ 4 个异构数据源做每日 ETL
分析查询稳定地和线上业务抢 CPU，且加索引 / 物化视图已解决不了
客户合同要求交付 BI 或数据驻留合规

当前状态 · 逐条对照

1.35 GB / 最大表 44 万行 —— 差三个数量级
数据源集中在一个库里 —— 不成立
已知瓶颈是审计表体积，先做冷热分层
暂无 BI 交付要求 —— 不成立

为什么要写下条件

否决要可复核，不能只留一句「太贵了」
条件写死，触线时不用重新论证
避免半年后凭印象重开同一场讨论
也避免反过来——真触线了却没人注意到

升级阶梯 · 从便宜到贵，别跳级

现在
STEP 0 Postgres 单库扛全部负载　≈ $15 / 月体量够小，事务与分析共存完全没问题

下一步
STEP 1 冷数据 → 对象存储 Parquet + DuckDB 查询　≈ $0最小可用的湖仓雏形。就是本文建议立刻做的那一步

再下一步
STEP 2 读副本 / 物化视图，把分析查询和线上负载隔开当报表开始真正影响线上延迟时才需要

再下一步
STEP 3 专用 OLAP：ClickHouse / BigQuery / MotherDuck　几十美元量级数据到几十 GB、分析成为独立工种时

最后
STEP 4 Snowflake / Databricks　千美元量级 + 专职人力到 TB 级、多源、多团队、有治理与合规硬需求时

// 阶梯最大的好处是 Parquet 是开放格式——STEP 1 落下去的数据，到 STEP 3、STEP 4 依然直接可读。升级路径不是推倒重来。

Verdict

结论与下一步

不买差三个数量级

它们的性价比拐点在 TB~PB，我们在 GB。而且它们不能替代业务库，上了是加一套不是换一套。

但抄五个思想立刻可用

冷热分层 · 分层建模 · 治理打标 · 版本快照，加上一条反向结论：招牌向量检索恰恰是最不用抄的。

先做一件审计表加窗口 + 外迁

最大的单表负担、最没有事务需求的纯日志——风险最低、见效最直接，也顺手把湖仓的第一步落了地。

记忆口诀：一次改一行 → OLTP（行存 + 事务）；一次读一亿行 → OLAP（列存 + 向量化）；想又便宜又可靠地把这一亿行放在对象存储上 → Lakehouse（Parquet + 事务元数据层）。

而选型的第一步永远不是比较产品，是先量自己有多大——这一步做完，答案往往就不用比了。

口径

库内数字为 2026-08-06 直连生产库实测；Snowflake / Databricks 定价为 2026 年 8 月公开资料口径，真要立项前请按官方定价页重新核验——上一次凭印象说某云服务价格，实际与真实数字差了近 4 倍。

一次改一行，还是一次读一亿行