为什么不能在业务数据库上直接做分析？企业如何为分析单独盖了一个房间（数据仓库），ETL 的苦役、维度建模的直觉、Teradata 一体机的特权定价——以及所有故事的起源：数据孤岛。
第一篇讲到，业务数据库（OLTP）是「收银台」——它为「处理一笔」而生。但当企业想回答的问题是「过去五年华东区哪个品类卖得最好」时，收银台就变成了灾难现场。这一篇讲企业如何为「分析」单独盖了一个房间——数据仓库，以及这个房间里长出来的新行业：ETL、维度建模、BI 工具，还有那个所有故事共同的起点：数据孤岛。
本篇要回答的问题
1. 为什么不能直接在业务数据库上做分析？（第一性原理拆解）
2. 数据仓库、ETL、维度建模这些黑话到底是什么？
3. Teradata 一体机为什么能卖到百万美元级？它贵在哪？
4. 「数据孤岛」是怎么诞生的——ERP、CRM 各说各话的根源
5. 企业为打破孤岛做的第一次挣扎，为什么大多以失败告终？
先看一个真实的场景还原。2005 年，一家连锁超市的信息部接到市场部的需求：「把过去三年所有门店、所有品类的销售明细拉出来，我要按城市和季节做个交叉分析。」信息部的工程师小张叹了口气——他知道这个查询意味着什么。
业务数据库里的销售表，存着过去两年全部门店的每一笔交易：假设 500 家门店、每天每店 2,000 笔，两年就是 7 亿行。这个查询要把 7 亿行全部扫一遍，按门店归类、按品类汇总、按季节切片——在当年的硬件上，这个查询要跑四个小时。
更糟的是它跑在「收银台」里。OLTP 数据库处理每笔交易时要对相关数据行加锁；一个全表扫描的分析查询，会和白天潮水般的销售写入互相干扰。结果就是：小张的查询一启动，当晚的POS 交易明显变慢。第二次提这种需求时，信息部经理直接把小张的查询权限限制到了每天凌晨 1 点到 5 点——分析师，从此变成了夜行动物。
这个场景里藏着三个结构性的矛盾，每一个都源自 OLTP 的设计取向：
| 矛盾 | 业务数据库的取向 | 分析的取向 |
|---|---|---|
| 读写冲突 | 为高频小写入优化，查询锁表影响交易 | 长查询、全表扫描，一动就是几小时 |
| 数据保留 | 只留热数据（近 1–2 年），历史归档移走 | 恰恰需要全部历史，越久越值钱 |
| 表结构 | 为「写一笔」设计的几十张规范小表 | 希望一张宽表直接看全貌，懒得跨 8 张表关联 |
三个矛盾叠加，结论清晰：分析必须有自己的房间。这个房间，就叫数据仓库（Data Warehouse）。
数据仓库的概念由 Bill Inmon 在 1991 年的著作中系统化，定义只有一句话：面向主题的、集成的、相对稳定的、反映历史变化的数据集合，用于支持管理决策。翻译成人话：把全公司各个业务系统里的数据，搬到一个专门的地方，按「分析」重新组织，只读不改。
定义里最关键的字是「搬」。数据不会自己走进仓库——你需要一套管道，每天夜里从销售系统抽数据、清洗格式、核对口径、装进货仓。这套流程有个行话缩写：ETL（Extract 抽取、Transform 转换、Load 装载）。
ETL 听起来是技术活，实际上是数据行业最早的「苦役」。一家中大型企业的 ETL 管道动辄几百条：销售系统的「门店编号」在财务系统里叫「机构代码」、在会员系统里叫「网点ID」——三套编码，每天夜里要对齐；商品分类标准三年换过两次，历史数据要打补丁；某门店半夜搞了场临时促销改了系统配置，管道直接崩了，第二天的报表全是空的。数据工程师这个职业在当时有个更传神的绰号——「修水管的」：数据团队一半以上的精力不是在分析数据，而是在维护那些把水从各处引到仓库的水管。
但无论多苦，这次「搬家」带来一个革命性的变化：分析从此不再伤害业务。收银台终于清净了——因为想分析的人都在隔壁房间。也正因为可以放心大胆地扫，分析师第一次能够自由地问那些「涉及全部历史」的问题。数据仓库时代，企业第一次拥有了「回看一亿笔」的能力。
搬进仓库的数据如果还保持业务系统的原始表格（几十张互相关联的规范小表），分析师用起来依然痛苦——查一个「门店月度销售」，要跨 8 张表写 7 个 JOIN。于是数据仓库时代诞生了一门专为分析设计的手艺：维度建模（Kimball 方法）。
它的核心思想非常直观：把数据重新组织成「一张大事实表 + 几张小的维度表」的星型结构。以便利店为例：
| 组成 | 装什么 | 便利店类比 |
|---|---|---|
| 事实表（中间的大表） | 一笔一笔的「事件」：每笔销售的金额、数量、时间、门店编号、商品编号 | 一摞销售小票 |
| 维度表：商品 | 每个商品的名称、品类、品牌、供应商 | 商品目录册 |
| 维度表：门店 | 每家门店的城市、区域、开业日期、面积 | 门店名录 |
| 维度表：时间 | 每个日期对应的星期、月份、季度、是否节假日 | 日历 |
分析师想问「2024 年 Q3 华东区域饮品品类的周末销售额」，就是在事实表里筛出对应行、沿三条维度表切片汇总——SQL 变得简单，更重要的是这张表的结构和商业问题的结构同构：任何「什么时间、什么地点、什么东西、卖了多少」的问题，都可以直接翻译成对星型模型的操作。维度建模统治分析领域三十年，至今仍然是所有 BI 课程的必修第一章。
数据仓库很好，但 2000 年代初盖这个房间的成本是天文数字。市场霸主 Teradata 卖的是软硬一体的「一体机」：专用硬件 + 专用数据库软件 + 原厂实施服务，一套入门配置百万美元级，支撑全公司分析的中大型部署三五百万美元起步，之后每两年扩一次容又是数十万到百万美元的采购。除此以外每年 20% 左右的维护费。而且和 Oracle 一样，换掉它的成本约等于心脏移植。
结果是一个清晰的市场分层：只有大银行、大电信、大零售集团养得起数据仓库；中小企业要么继续在业务库上夜跑报表，要么靠 Excel + 导出硬扛。分析能力在那个时代是一种「特权」——这不是夸张，是定价现实。
这个分层还带来了一个隐蔽的副作用：数据仓库的门槛把「分析」这个动作本身精英化了。企业里的分析是信息部几个工程师的专属技能，业务部门想看个数据要提需求、排期、等工单。全公司对数据的真实需求远大于仓库的产能——这个供需矛盾被一个新角色部分承接：ETL 工程师加班做报表，「取数民工」成了那个年代数据从业者的自嘲。
到此为止，本篇讲的都是「一个企业、一个仓库」的理想叙事。真实世界的企业远比这混乱——而混乱的根源，要追溯到企业信息化建设的方式本身。
一家成长中的中大型企业，信息化通常是这么发生的：2003 年上财务系统（用友/金蝶，自带财务数据库）；2005 年上 ERP（SAP/用友，库存、采购、生产）；2008 年上 CRM（Salesforce/自研，客户与销售）；2012 年上 HR 系统、OA 系统；2015 年上了官网和电商后台……每一个系统在当时都是合理的采购决策——但每个系统都自带一套数据库，各自记录着公司经营的一个侧面。
于是产生了数据行业最著名的顽疾：数据孤岛。它的杀伤力不在于「数据分散」（分散无非是查起来麻烦），而在于三件更阴险的事：
| 杀伤 | 具体表现 | 例子 |
|---|---|---|
| 口径分裂 | 同一个商业概念，在各系统里定义不同 | 「活跃客户」：CRM 里定义为「今年有联系」，营销系统定义为「90 天内有成交」，财务定义为「有应收余额」——三个部门报的「活跃客户数」永远对不上，开会先吵数字 |
| 拼接困难 | 跨系统的数据缺少统一的关联键 | 想知道「高消费客户的退货率」，需要把 CRM 的客户与 ERP 的订单关联——但两边客户编码规则不同，且 CRM 里三分之一客户没有 ERP 编号 |
| 重复建设 | 每个部门自建小仓库、小报表 | 市场部一套报表体系、销售部一套、财务一套——同一个公司，三套「真相」，维护成本三倍 |
数据孤岛的本质不是技术问题，而是组织问题：每个系统的采购决策都是部门级的，而数据的价值是公司级的。用部门预算买来的系统，天然只会为部门服务。
孤岛的痛积攒到一定程度，企业的标准动作出现了：建一个全公司统一的数据仓库，把 ERP、CRM、财务的数据全部 ETL 进来，统一口径、统一管理——「单一真相源」（Single Source of Truth）是这个时期最响亮的口号。
这场挣扎的结果值得如实记录：成功了大半，留下了一个后患。成功的部分——统一后的仓库确实终结了「三个部门三个数字」的混乱，维度建模让分析变得可用，一批企业借此建立了数据团队。留下来的后患是：所有数据进了一个池子，但取水的人依然要排队。
原因在第一篇就埋下了：2000 年代的统一数据仓库，底层还是 Teradata 式的架构（或 Oracle RAC），资源是共享的、容量是有限的、扩容是采购制的。市场部双十一要做大促分析时，占用的算力会让财务部的月结查询变慢；数据团队要人工做资源调度；业务部门想自助分析？不可能，算力太贵，必须计划使用。仓库变成了新的排队现场——只不过从「排队找分析师」变成了「排队等算力」。
请把这个局面记牢，因为接下来二十年里最精彩的故事，都是围绕这个局面展开的：
本篇留下的三把钥匙（后续各篇的入口）
钥匙一：算力太贵、扩容靠采购——直到云计算让「存储按 GB 计、算力按秒计」成为可能，Snowflake 才有了土壤（第四篇）。
钥匙二：开源组件各管一摊——Hadoop 时代的免费方案带来了新的复杂度，兴盛优选的「四件套」之痛（第四篇）与 Databricks 的 Lakehouse 整合（第五篇）由此而来。
钥匙三：孤岛是组织病——中国 2015–2021 年的「数据中台」热潮，是全世界对这个问题最激进的组织化尝试，它的成败兴衰（第六篇）是理解中国市场的一把钥匙。
本篇概念史实（Inmon 1991 数据仓库定义、Kimball 维度建模、ETL 与星型模型、Teradata 一体机定价量级）为数据仓库行业公认知识，可在 Wikipedia「Data warehouse」「Dimensional modeling」词条及 Inmon/Kimball 原著交叉验证。场景还原（2005 年连锁超市查询案例）为基于行业普遍实践的示意性还原，不指向具体企业。Teradata 定价量级为行业普遍认知范围，具体项目价格因配置差异极大。
系列下一篇 · 《大数据的十年：Hadoop、数据湖与数据沼泽》——Google 的三篇论文如何催生开源大数据；「什么都往湖里扔」的自由与代价；以及一家中国企业用四套开源组件打架的真实案例。