为什么我们需要数据仓库(转自数据治理之道)

思考：没有数据仓库，我们也能完成数据分析任务。那么，建设数据仓库的理由是什么？

如果直接从业务数据库取数据

没有数据仓库时，我们需要直接从业务数据库中取数据来做分析。业务数据库主要是为业务操作服务，虽然可以用于分析，但需要做很多额外的调整，在我看来，主要有以下几个问题：结构复杂，数据脏乱，难以理解，缺少历史，大规模查询缓慢。

下面来简单解释一下这几个问题。

结构复杂
业务数据库通常是根据业务操作的需要进行设计的，遵循3NF范式，尽可能减少数据冗余。这就造成表与表之间关系错综复杂。在分析业务状况时，储存业务数据的表，与储存想要分析的角度表，很可能不会直接关联，而是需要通过多层关联来达到，这为分析增加了很大的复杂度。

举例：想要从门店的地域分布来分析用户还款情况。基本的还款数据在订单细节表里，各种杂项信息在订单表里，门店信息在门店表里，地域信息在地域表里，这就意味着我们需要把这四张表关联起来，才能按门店地域来分析用户的还款情况。

此外，随着NoSQL数据库的进一步发展，有许多数据储存在诸如MongoDB等NoSQL数据库中，另外一些通用信息，如节假日等，通常也不会在数据库中有记录，而是以文本文件的形式储存。多种多样的数据储存方式，也给取数带来了困难，没法简单地用一条SQL完成数据查询。如果能把这些数据都整合到一个数据库里，比如构造一张节假日表。这样就能很方便地完成数据查询，从而提高分析效率。

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

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

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

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

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

数据仓库解决方案

上面的问题，都可以通过一个建设良好的数据仓库来解决。

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

下面就来简单看一下数据仓库是如何解决上面的问题的。

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

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

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

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

想要分析用户还款的情况，直接找到储存还款业务数据的还款事实表fact_repayment，principal和amount分别代表单期还款的本金和本息。然后看事实表都关联了哪些维度(事实表中INT型的 字段)。这些维度就构成了所有可以分析的角度。不会再有长长的联结了，你想要哪个观察角度，只需要联结相应的维度表就行了。此外，每一个维度还有不同的层次，可以根据需要来选择。比如，想要按订单日期维度来对比分析正常还款的比率。你可以按年对比，按年-月对比，按月（不同年份同一个月都算一组）对比，按季度对比，按星期几对比等等……筛选也更加方便，目前日期维度表里储存着一个字段，表明某个日期是否是当月最后一天。所以我们可以很容易地筛选出所有订单日期在月末的数据。

可复用，易拓展
事实-多维度的星形结构，在便于理解和使用之外，还带来了额外的好处。一是可复用。比如日期维度表，不仅可被不同的事实表复用，在同一张事实表里也可被复用，分别用来表示各种不同操作的日期（订单日期、放款日期、应还日期、实还日期等等）。拓展也十分方便，直接在维度表里添加新的字段内容即可，只要保证维度数据的主键不变，添加新内容只会影响到维度表而已。而维度表通常数据量不大，即使完全重新加载也不需要花费多少时间。

数据干净
在ETL过程中会去掉不干净的数据，或者打上脏数据标签，使用起来更为方便。

数据语义化／统一描述
各种状态都可以直接写成具体的值，不再需要使用操作码进行查询，SQL语句更自然，更易理解。

对于部分常用的组合状态，可以合并成一个字段来表示。比如在还款分析中，需要根据还款状态、放款状态／发货状态的组合来筛选出有效的订单，可以直接设置一个订单有效的字段，简化筛选条件。

对于同一含义的数据在不同情境下的表示，也可以统一描述了。比如对于放款日期的描述，在产品是消费贷时，指的是发货的日期，产品是现金贷时，指的是放款给用户的日期。这两个日期都是表示放款日期，就可以统一起来，同样也简化了筛选条件。

保存历史
数据仓库可通过拉链表的形式来记录业务状态变化，甚至可以设计专用的事实表来记录。只要有历史分析的需要，就可以去实现。比如，用户的手机号可能会变化，但我们通过缓慢变化维度类型2的设计，可以记录他完成同一类业务操作，比如申请贷款的操作时，不同的手机号。

高速查询
数据仓库本身并不提供高速查询功能。只是由于其简单的星形结构，比业务数据库的复杂查询在速度上更有优势。如果仍然采用传统的关系型数据库来储存数据。在数据量上规模之后，同样也会遇到查询缓慢的问题。

但是，使用Hive来储存数据，再使用基于Hive构建的多维查询引擎Kylin，把星型模型下所有可能的查询方案的结果都保存起来，用空间换时间，就可以做到高速查询，对大规模查询的耗时可以缩短到次秒级，大大提高工作效率。

业务数据库和数据仓库比较

业务数据库和数据仓库虽然在本质上都是数据库，但由于面向的用户不同，所以设计的思想不同，最终的数据模型也不同。下面是两者的一些对比，希望可以帮助大家更好地理解数据仓库。