如果不用数据仓库的话，我们的数据也总还是要用来分析用户行为的吧？别跟我说你看着日益见长的数据就没有别的想法，但是！如果你的数据库是业务数据库，那么你有可能会遇到结构复杂、数据脏乱、难以理解透彻各表字段、缺少历史数据、大规模查询慢

我们来具体说一下问题

结构复杂

业务数据库通常是根据业务操作的需要进行设计，所以为了避免数据冗余，表与表之间的关系错综复杂，所以在分析业务的时候，需要的业务表与维度表应该需要关联多个表才能查询得到

数据脏乱

因为业务数据库会接受大量用户的输入，如果业务系统没有做好足够的数据校验，就会产生一些错误数据，比如不合法的身份证号，或者不应存在的Null值，空字符串等。

理解困难

业务数据库中存在大量语义不明的操作代码，比如各种状态的代码，地理位置的代码等等，在不同业务中的同一名词可能还有不同的叫法。

这些情况都是为了方便业务操作和开发而出现的，但却给我们分析数据造成了很大负担。各种操作代码必须要查阅文档，如果操作代码较多，还需要了解储存它的表。来自不同业务数据源的同义异名的数据更是需要翻阅多份文档。

缺少历史

出于节约空间的考虑，业务数据库通常不会记录状态流变历史，这就使得某些基于流变历史的分析无法进行。比如想要分析从用户申请到最终放款整个过程中，各个环节的速度和转化率，没有流变历史就很难完成。

大规模查询缓慢

当业务数据量较大时，查询就会变得缓慢。尤其需要同时关联好几张大表，比如还款表关联订单表再关联用户表，这个体量就非常巨大，查询速度非常慢。美好的青春都浪费在了等待查询结果上，真是令人叹息。

上面的问题，都可以通过一个良好的数仓来解决，另外，业务数据库是面向操作的，主要服务于业务产品和开发。而数据仓库则是面向分析的，主要服务于我们分析人员。评价数据仓库做的好不好，就看我们分析师用得爽不爽。因此，数据仓库从产品设计开始，就一直是站在分析师的立场上考虑的，致力于解决使用业务数据进行分析带来的种种弊端

结构清晰，简单

数据仓库的通常是一天变动一次，批量更新，由ETL系统完成。在这种情况下，数据的输入是高度可控的，所以不需要像业务数据库那样尽可能地减少数据冗余。自然地，数据模型就可以不遵循3NF范式，而是以分析方便为目的。

目前主流的数据模型就两种，E-R模型和维度模型。我在实践中主要采用维度模型。维度模型采用星形结构，表分两类——事实表和维度表。事实表处于星星的中心，储存能描述业务状况的各种度量数据，可以通过事实表了解业务状况。维度表则围绕着事实表，通过外键以一对一的形式相关联，提供看待业务状况的不同角度。相比业务数据库常用的E-R模型，星形结构更容易理解，更方便进行分析。

星形模型的特点是：使用方便，易于理解，聚焦业务。

当我们要做数据分析时，第一步是选定主题，比如要分析还款情况，逾期情况等等。接下去才是根据选定的主题来找到业务数据源，然后再看看业务数据源提供了哪些分析角度，最后导出数据进行分析。星形模型非常适合这个思路，并且大大简化了这个过程。