摘要：数据仓库就是帮企业把这些散数据“拢到一块儿、理清楚、存好”的工具，而数据仓库模型，就是给这些数据“搭架子”——怎么放才规整、怎么查才快、怎么用才方便。今天咱们就把数据仓库和数据仓库模型说透，全是能落地的干货，保证你听完就知道该怎么选、怎么用。

现在做企业的，谁手里没点数据？销售流水、客户信息、库存记录……但这些数据散在各个系统里，想用的时候要么调不出来，要么格式不对，根本没法好好分析。

数据仓库就是帮企业把这些散数据“拢到一块儿、理清楚、存好”的工具，而数据仓库模型，就是给这些数据“搭架子”——怎么放才规整、怎么查才快、怎么用才方便。今天咱们就把数据仓库和数据仓库模型说透，全是能落地的干货，保证你听完就知道该怎么选、怎么用。

在文章正式开始之前，先分享一份《数据仓库建设方案》，里面包括调研、需求梳理、建设规范、建模全流程，从数据标准的规范到报表体系的建设都提供明确的建设思路，高效解决常见的口径不一致、报表查询慢等问题。需要自取：

一、数据仓库是什么

1.基本概念

简单来说，数据仓库就是个“专门存企业分析用数据的地方”。不是说把业务系统里的数据直接搬过来就行，得先处理——比如把不同系统里的“客户ID”统一格式，把重复的订单数据删掉，把缺失的库存数量补全，然后再存到一起。

说白了，它跟业务系统的数据库不一样。业务系统的数据库是“实时干活用的”，比如你在电商下单，数据马上存到业务库；但数据仓库是“事后分析用的”，比如月底分析“这个月哪个地区下单多”，就从数据仓库里调数据。我一直强调，数据仓库的核心是“支持决策”，不是“支持实时交易”，你懂我意思吗？

2.数据仓库的组成

数据仓库不是一个“黑盒子”，是由四个部分凑起来干活的，少一个都不行：

数据源：就是数据从哪儿来。比如企业内部的ERP、CRM、POS系统，外部的行业报告、天气数据、竞品数据，这些都是数据源。之前有个客户做农业的，连气象局的降雨数据都算数据源，因为要分析降雨对农产品销量的影响。

数据存储与管理：这是核心，就是“存处理好的数据的地方”。得选合适的数据库，比如Hadoop、Greenplum这些，还得管数据的分区、索引，保证存得下、查得快。比如把销售数据按“年-月-日”分区，查“2024年5月的销售”，就不用翻全年的数据，能快很多。

OLAP服务器：负责“分析数据”的。比如你想“按地区、按产品、按月份”看销售情况，OLAP服务器就能快速算出结果，不用你自己写复杂的SQL去拼数据。之前有个客户用普通SQL查“全国各省市近三年每月的家电销量”，要等20分钟，用了OLAP服务器，30秒就出来了。

前端工具：就是用户直接用的东西。比如报表工具、BI工具，管理层在上面看报表、做可视化分析，不用管后台怎么处理。FineReport就常跟数据仓库搭着用，把数据仓库里的分析结果做成仪表盘，老板打开就能看。

FineDataLink在这儿扮演的角色，就是“帮数据源的数据进到数据存储里”——把ERP里的订单数据、CRM里的客户数据抽出来，处理好格式，再加载到数据存储里，整个过程不用人工干预，省了好多事>>>

3.数据仓库的建设流程

建数据仓库不是“拍脑袋就上”，得按步骤来，不然建一半发现不对，返工成本太高。一般分五步：

第一步，需求分析。先搞清楚“企业要分析什么、谁用、怎么用”。比如销售部门要“每周看各产品的销量”，财务部门要“每月看各地区的利润”，管理层要“季度看整体营收趋势”。之前有个客户没做需求分析，上来就建，结果建完发现销售要的“产品分类维度”没加，又花了两个月补，特别耽误事。

第二步，概念设计。把需求变成“数据主题”。比如“销售主题”“库存主题”“客户主题”，每个主题下有哪些数据，比如“销售主题”包括订单号、产品ID、销售金额、销售时间。这一步不用太细，先把大框架定下来。

第三步，逻辑设计。把概念设计变成“表结构”。比如“销售主题”要建“销售事实表”，字段包括订单号、产品ID、客户ID、销售金额、销售时间；还要建“产品维度表”，字段包括产品ID、产品名称、产品分类。这一步要确定表和表之间的关系，比如“销售事实表”通过“产品ID”关联“产品维度表”。

第四步，物理设计。确定“用什么数据库、数据怎么存”。比如选Hadoop存大量历史数据，选Greenplum存高频查询的数据；给“销售时间”加索引，查特定时间段的数据更快；按“产品分类”分区，查某类产品的数据不用扫全表。

第五步，数据加载与维护。把数据源的数据抽出来、处理好、加载到数据仓库里，还得定期更新。比如每天凌晨自动抽前一天的销售数据，每月底做一次数据校验，看看有没有缺失、错误。FineDataLink就是干“数据加载”这活的，能自动处理数据格式，还能监控加载进度，加载失败了会报警。

二、数据仓库的重要性

1.支持企业决策

企业做决策不能靠“拍脑袋”，得靠数据。但数据散在各个系统里，根本没法用。数据仓库把数据整合好之后，管理层就能快速拿到准确的数据，做决策也有底气。

比如一家服装企业，之前想推新款，靠“老板觉得好看”来定款式，结果压了一堆库存。后来建了数据仓库，整合了销售数据、客户评价数据、天气数据，发现“轻薄款在南方春季卖得好”“带口袋的裤子客户评价高”，再推新款就照着这些数据来，库存周转率提高了30%。听着是不是很熟？很多企业就是因为没数据支撑，决策错了，白白浪费钱。

2.提高数据分析效率

没数据仓库的时候，分析师要数据，得先找IT部门从ERP里导销售数据，再从CRM里导客户数据，然后自己用Excel拼格式、删重复，光准备数据就要花半天，真正分析的时间没多少。

有了数据仓库之后，分析师直接从数据仓库里调数据就行，格式是统一的，数据是干净的，不用再做准备工作。之前有个客户的分析师，没数据仓库的时候，一周只能出1份报表；有了之后，一天能出3份，还能腾出时间做深入分析，比如“客户复购率和购买频次的关系”。

FineDataLink在这儿也帮了不少忙，它能自动把数据加载到数据仓库里，不用分析师催着IT部门导数据，效率提了一大截。

3.促进企业数据共享

企业里各部门的数据往往是“各管各的”。销售部的客户数据不跟售后部共享，售后部不知道客户之前买过什么，服务的时候经常出错；财务部的利润数据不跟销售部共享，销售部不知道哪些产品赚钱，还在推低利润的产品。

数据仓库能打破这种“数据壁垒”，所有部门都从数据仓库里拿数据，数据是统一的，不会出现“销售部说卖了100万，财务部说只到账80万”的情况。比如售后部从数据仓库里查到客户买了某款家电，就能主动问“您的家电快过保修期了，需要预约检修吗”，客户满意度也高了。

4.挖掘数据价值

企业里藏着很多“没用起来的数据”，比如客户的浏览记录、售后的维修记录，这些数据单独看没意义，但整合到数据仓库里，就能挖出大价值。

比如一家电商企业，在数据仓库里整合了客户的浏览、加购、下单、评价数据，发现“浏览超过5分钟没下单的客户，给张10元优惠券，转化率能提高20%”，就针对这类客户推优惠券，GMV（商品交易总额）涨了15%。用过来人的经验告诉你，很多企业不是没有数据价值，是没把数据整合起来，根本挖不出来。

三、数据仓库模型类型

1.范式模型

范式模型是最“规矩”的模型，严格按照数据库的范式来设计，核心是“减少数据冗余”。比如一个订单，包含订单信息、客户信息、产品信息，范式模型不会把这些信息都存在一张表里，而是分成“订单表”“客户表”“产品表”，通过ID关联。

它的优点很明显：数据没重复，比如客户的姓名、电话只存在“客户表”里，改的时候只改一处，不会出现“一处改了，另一处没改”的情况，数据一致性特别好。而且数据量小，因为没重复，存起来省空间。

但缺点也很突出：查询效率低。比如想查“某客户某订单买了什么产品”，得把“订单表”“客户表”“产品表”三张表连起来查，表多的时候，查询速度会很慢。之前有个客户用范式模型查“近一年各地区各产品的销量”，连了8张表，查了15分钟才出来，分析师都快等睡着了。

所以范式模型一般用在“数据更新频繁、对一致性要求高”的场景，比如银行的交易系统、企业的财务系统，这些场景更在意数据准不准，而不是查得快不快。

2.维度模型

维度模型是数据仓库里最常用的模型，核心是“方便查询、适合分析”，主要由“事实表”和“维度表”组成。

事实表存的是“业务事实”，比如销售金额、销售数量、订单数，都是能算的数字；维度表存的是“分析的角度”，比如时间、客户、产品、地区，都是用来“切数据”的维度。比如“2024年5月北京地区A产品的销售额”，“销售额”是事实表的字段，“2024年5月”是时间维度，“北京”是地区维度，“A产品”是产品维度。

它的优点很直接：查询快。想分析什么，直接用事实表关联对应的维度表就行，不用连很多表。比如查“各产品的销量”，连“销售事实表”和“产品维度表”两张表就行，几秒钟就能出来结果。而且容易理解，业务人员一看“事实表+维度表”，就知道怎么查数据，不用懂复杂的数据库知识。

缺点就是数据有冗余。比如“时间维度表”里的“2024年5月”，会跟很多订单关联，相当于存了很多次“2024年5月”这个信息。但现在存储成本很低，这点冗余根本不算事，所以大部分企业做分析，都选维度模型。

FineDataLink特别适配维度模型，加载数据的时候，能自动区分事实表和维度表，事实表按时间分区，维度表建索引，加载完之后查询更快。

3.星座模型

星座模型是维度模型的“升级版”，核心是“多个事实表共享维度表”。比如企业有“销售事实表”和“库存事实表”，这两个事实表都需要“时间维度表”“产品维度表”“地区维度表”，就不用各建一套维度表，共享一套就行。

它的优点是“减少维度表冗余”。如果“销售”和“库存”各建一套维度表，“产品维度表”就得存两份，改产品名称的时候得改两处；共享之后，只存一份，改一处就行，数据一致性也更好。

而且适合“多业务主题分析”。比如想分析“某产品的销量和库存的关系”，因为“销售事实表”和“库存事实表”共享“产品维度表”，直接关联这三张表就能查，不用再处理维度表的差异。之前有个零售客户，用星座模型分析“销量高但库存低的产品”，很快就找出了需要补货的产品，避免了缺货损失。

所以星座模型适合“业务主题多、维度重复多”的企业，比如大型商超、综合电商，既有销售数据，又有库存数据，还有会员消费数据，共享维度表能省不少事。

4.雪花模型

雪花模型是维度模型的“另一种变形”，核心是“维度表再拆分”，把维度表按范式规则拆成更细的子表。比如“客户维度表”里有“客户所在地区”，雪花模型会把“地区”拆成“地区表”，包含“地区ID”“省份”“城市”“区县”，然后“客户维度表”通过“地区ID”关联“地区表”。

它的优点是“维度表冗余更少”。比如“省份”“城市”这些信息，在“地区表”里只存一次，所有客户共享，不会像维度模型那样，每个客户都存一次“省份”“城市”。对于数据量特别大的企业，能省不少存储成本。

但缺点也很明显：查询更复杂。想查“某省份的客户销量”，得连“销售事实表”“客户维度表”“地区表”三张表，比维度模型多连一张，查询速度会慢一点。而且理解起来更难，业务人员可能搞不懂“客户表”为什么要跟“地区表”关联，得花时间培训。

所以雪花模型一般用在“维度层级多、对冗余特别敏感”的场景，比如做全国性业务的企业，地区维度分“国家-省份-城市-区县-街道”，拆成子表更规整，也能减少冗余。

四、各类数据仓库模型的区别与特点

1.数据冗余度

从低到高排，依次是范式模型＜雪花模型＜星座模型＜维度模型。

范式模型严格按范式来，没任何冗余，比如客户信息只存一次；雪花模型把维度表拆了，维度表没冗余，但事实表还是有少量；星座模型共享维度表，维度表冗余比维度模型少，但事实表冗余差不多；维度模型为了查询快，会存重复的维度信息，冗余最多。

这里要注意，不是冗余越少越好。很多企业选模型的时候，觉得“冗余少就是好”，结果选了范式模型，查询慢得要死，根本没法分析。用过来人的经验告诉你，除非数据量特别大、存储成本特别高，否则不用太纠结冗余，查询效率更重要。

2.查询效率

从高到低排，依次是维度模型≈星座模型＞雪花模型＞范式模型。

维度模型和星座模型都是为查询设计的，关联的表少，查得快；雪花模型比它们多关联几层子表，会慢一点；范式模型关联的表最多，查得最慢。

之前做过一个测试，查“2024年Q1各省份各产品的销量”，维度模型用了3秒，雪花模型用了8秒，范式模型用了25秒。对于需要频繁出报表、做实时分析的企业，维度模型和星座模型肯定是首选。

3.数据一致性

从高到低排，依次是范式模型≈雪花模型＞星座模型＞维度模型。

范式模型和雪花模型都是规范化设计，数据改一处就行，一致性最好；星座模型共享维度表，维度表的一致性好，但事实表可能有重复数据，一致性稍差；维度模型有冗余数据，改的时候得改多处，容易漏改，一致性最差。

但维度模型的一致性问题是可以解决的，比如用FineDataLink加载数据的时候，设置“数据更新规则”，改客户信息的时候，自动同步到所有关联的表，就能保证一致性。所以不用因为一致性，就放弃维度模型。

4.适用场景

范式模型：适合数据更新频繁、对一致性要求高、查询少的场景，比如银行的核心交易系统、企业的财务总账系统。这些场景主要是记录数据，不是分析数据，慢一点也没关系。

维度模型：适合查询频繁、需要做简单多维分析的场景，比如中小企业的销售分析、门店业绩分析。大部分企业用这个模型就够了，性价比最高。

星座模型：适合多业务主题、维度重复多的场景，比如大型商超的“销售+库存+会员”分析、电商的“交易+物流+售后”分析。

雪花模型：适合维度层级多、对冗余敏感的场景，比如全国性企业的地区维度分析、跨国公司的多语言维度分析。

FineDataLink能根据不同模型的特点，优化数据加载。比如对维度模型，优先加载维度表再加载事实表；对雪花模型，自动处理维度表和子表的关联；对星座模型，确保共享维度表只加载一次，不会重复。

总结

数据仓库不是“大企业的专属”，中小企业也需要，而数据仓库模型，就是给这些整合好的数据“搭架子”，架子搭对了，查数据才快、做分析才顺，不然数据堆进去就是一团乱麻，根本没法用。

选模型的时候，别跟风选“看起来高级”的。用过来人的经验告诉你，选模型的核心是“贴合需求”，免得把简单的事搞复杂。

FineDataLink在这中间也能帮上大忙——不管你选哪种模型，它都能适配：给维度模型做事实表分区、维度表索引，让查询更快；给星座模型处理共享维度表的加载，避免重复；给范式模型做数据清洗，保证一致性。其实建数据仓库、选模型，最终目的都是“用好数据”，别为了追求技术复杂而忽略了这个核心，不然就是舍本逐末了。

最后想说，数据仓库不是建完就完事的，后续还要根据业务变化调整模型。只有模型跟着业务走，数据才能一直帮上忙，不然时间久了，数据仓库就成了“僵尸库”，白花钱还没用。

Q&A 常见问答

Q1：选好模型建了数据仓库后，能改模型吗？比如从维度模型改成星座模型？

A：能改，但得注意方法，不能瞎改。首先得想清楚“为什么要改”——是原来的维度模型满足不了新业务了（比如新增了售后数据要分析），还是查询效率不行了？别因为“觉得星座模型高级”就改，不然改完可能更麻烦。

改的时候要分三步：

第一步，先备份原来的数据，万一改坏了还能恢复；

第二步，先在测试环境改——比如想从维度模型加个“售后事实表”变成星座模型，就先在测试环境建个“售后事实表”，再共享原来的客户、时间维度表，测试能不能正常查数据、会不会影响原来的销售分析；

第三步，测试没问题了，再把新模型同步到生产环境，然后用FineDataLink把售后数据加载进去，加载完还要校验——比如查“某客户的销售和售后记录”，看看数据对不对，有没有重复或缺失。

另外要提醒的是，改模型后要给团队培训，不然改了模型也没人会用，等于白改。

Q2：数据仓库模型建好后，加载数据老出错，是模型的问题吗？

A：不一定是模型的问题，得先排查原因，别一出错就怪模型。常见的出错原因有三个，你可以对着看看：

第一个是“数据格式不统一”——比如模型里“客户ID”设的是数字格式（比如12345），但数据源里的“客户ID”有的带字母（比如C12345），加载的时候就会出错。这种情况不是模型的问题，是数据清洗没做好，用FineDataLink在加载前加个“格式转换”步骤，把带字母的“客户ID”改成纯数字就行。

第二个是“表关联错了”——比如维度模型里，销售事实表应该通过“产品ID”关联产品维度表，但加载的时候不小心用“客户ID”关联了，肯定出错。这种是配置问题，跟模型没关系，改改关联字段就好。我之前有个客户就犯过这错，查“某产品销量”一直出不来，后来发现是关联字段错了，改完马上就好了。

第三个才可能是“模型设计有问题”——比如维度模型里，事实表的“产品ID”在维度表里没有（比如维度表漏了这个产品的记录），加载的时候就会出现“孤儿数据”（事实表里有，维度表里没有）。这种情况就得改模型，要么在维度表里补全产品记录，要么在加载的时候加个“过滤规则”，把没对应的事实数据先存到临时表，后续补全维度数据再加载。

所以加载出错了，先查数据格式、关联配置，最后再看模型，别上来就否定原来的模型设计，不然可能绕很多弯路。

Q3：选模型的时候，IT说“范式模型规范”，业务说“维度模型好用”，该听谁的？

A：听业务的，但要跟IT沟通好，找个平衡点。因为数据仓库最终是给业务用的——IT觉得范式模型规范，但业务人员用的时候要连七八张表，查个数据得写复杂SQL，最后还是得找IT帮忙，IT反而更累；而维度模型业务人员自己就能用，不用麻烦IT，大家都省事。

当然，也不能完全不听IT的——比如IT担心维度模型的冗余问题，就可以跟IT商量“用维度模型，但用FineDataLink做数据校验，改数据的时候自动同步冗余字段”，既满足业务好用的需求，又解决IT担心的一致性问题。

核心是“数据仓库是服务业务的”，不是用来体现技术规范的。要是建出来的东西业务不用，再规范也没用，你说对不对？

来源：帆软