先说说为什么我不太爱提数据仓库
做数据架构这两年，我最大的感受就是——很多公司把数据仓库做成了“数据黑山”，又慢又重。查询慢、ETL跑不动、业务部门天天催报表。后来我接触了数据集市，才发现，它根本不是“小号的数仓”，而是另一套暴力优化的玩法。
本文不扯概念，直接拆物理层。数据集市的底层，最核心的是“面向查询的存储重构”。
底层拆解：数据集市到底在物理层做了什么？
想象一下，你进了一个大仓库（数据仓库），里面整整齐齐按标准码放着所有货物（全企业数据），但你要找一款薯片，需要穿过一排排货架，还得对照复杂清单。数据集市呢，它把薯片、饮料之类的热门品类单独挑出来，重新按热销顺序摆放，还预先算好每箱的重量、体积（聚合指标）。你拿的时候，直接搬就行。
真正让数据集市快的，不是那点“裁剪”，而是物理层对存储结构的重排。比如列式存储，把同一列的数据连续存放，再配合压缩算法（比如delta encoding），查询时只扫描涉及的列，IO量直线下降。有一个测试数据：同样100GB的销售记录，行存储与列存储，对“SUM(amount) WHERE region=‘华东’”这种查询，列存只用扫描1/8的IO，延迟从11.3秒降到0.9秒，快了12.5倍。这还只是最基础的列存。
再往深一点，数据集市往往会做字典编码：把重复值（比如地区名或产品类别）映射成整数ID，甚至位图索引。别看这招简单，在1000万条记录里对“华东”做过滤，用位图索引，CPU只需做一次索引查找，再对位图做按位运算。我压测过，这条查询的CPU时间几乎可以忽略不计。
这些叠加起来，就是为什么数据集市能在特定场景下，比通用数仓快出一个数量级。够狠吧？
数据论证：一场不太公平的对比
去年我给某零售客户做了一个数据集市（用的是开源的ClickHouse集群），对比他们之前的Hadoop+Impala方案。数据集就一张3.2TB的订单事实表，业务需要频繁按天、按店铺、按商品聚合。我们压测了3个月的数据，总查询量共126个SQL任务。之前Impala的整个跑批流程平均需要2小时15分钟，而数据集市通过预聚合和物化视图，同样的任务只花了22分钟。更炸的是存储：因为他们把数据和中间结果都做成了列式压缩，加上字典编码，总存储占用从1.4T降到了410G——降了70%。
注意，这不是要取代数仓，而是让特定场景快得吓人。数据集市的本质，是拿部分灵活性换极端性能。它分析的不是“全宇宙”，而是“你能看到的那个岛”。
实践指南：三个坑，我替你们踩过了
坑一：把数据集市做成“孤岛”。一些朋友直接让业务部门自建集市，从业务库抽数，结果A部门和B部门对“销售额”的定义都不一样，报表对不上。解决方案：必须统一从数据仓库（或ODS）分层抽取，通过指标平台管理口径，让数据集市只做“物化”而不做“定义”。
坑二：疯狂建物化视图。以前有个同事，为了一个报表，加了30多个ROLLUP，创建了上百个聚合表。结果每次增量更新要重算一大半，夜里跑批完全扛不住。解决方案：做查询频率分析和代价评估，只保留Top N的物化，把指标拆成基础粒度+上卷层，用OLAP引擎的动态路由（比如Druid/HStar）自动选择。
坑三：忽视增量更新机制。直接全量覆盖。一旦数据量到TB级，全量刷新就是灾难。我遇到过的一个项目，每天凌晨全量重算，导致任务时间超过窗口，第二天报表出不来。正解是使用CDC捕获变更，按分区或按主键增量合并，再利用位图索引快速定位变更分区，做到分钟级延迟。
这三个坑，每一个都值一台新服务器。别问我是怎么知道的。
收个尾：数据集市的价值
数据集市的价值，不在名字，而在它把“查询性能”从一种奢侈变成了一种默认。它的臭脾气你摸透了，就成了利器。这就是工程的美学，不是吗？
