数据仓库和数据库的区别,数据仓库和数据库有什么区别？

通常情况下基于业务数据库数据分析人员也能完成数据分析需求，但是为什么要建数据仓库？

没有数据仓库时，我们需要直接从业务数据库中取数据来做分析。

业务数据库主要是为业务操作服务的，虽然可以用于分析，但需要很多额度的调整。

一，业务数据库中存在的问题

基于业务数据库来做分析，主要有以下几个问题：结构复杂，数据脏乱，难以理解，历史缺失，数据量大时查询缓慢。

结构复杂

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

数据脏乱

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

理解困难

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

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

缺少历史

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

大规模查询缓慢

当业务数据量较大时，查询就会变得缓慢。

二，数据仓库解决方案

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

业务数据库是面向操作的，主要服务于业务产品和开发。

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

数据仓库解决的问题

结构清晰，简单

数据仓库不需要遵循数据库设计范式，因此在数据模型的设计上有很大自由。

数据模型一般采用星型模型，表分为事实表和维度表两类。

其中事实表位于星星的中心，存储能描述业务状况的各种度量数据。

维度表围绕在事实表的周围，通过外键一对一的形式关联，提供了看待业务状况的不同角度。

星型模型使用方便，易于理解，聚焦于业务。

当我们做数据分析时，首先选定主题，比如分析用户注册情况；其次根据选定的主题找到对应的业务数据源，然后观察业务数据源提供了哪些分析角度，最后根据数据进行分析。

星形模型非常适合这个思路，并且大大简化了这个过程。下面以我们目前的模型来举例。

可复用，易拓展

星型模型不仅便于理解和使用，而且维度表还便于重复使用，维度表中字段易于拓展。

比如日期维度表，不仅可以被不同的事实表是使用，在同一张事实表里也可被复用，比如一个事实表里不同的操作日期，一个商品的订单有创建日期、付款日期、发货日期、退款时间、收货时间等等。

维度表中字段易于扩展，只要保证维度数据的主键不变，直接在维度表里添加新的字段内容即可，添加的新内容只会影响到维度表而已。而且，维度表通常数据量不大，即使完全重新加载也不需要花费多少时间。

数据干净

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

注：由于数据清洗需要建立一定的规则，而目前的工作重心是数据建模和ETL系统设计，没有额外的时间精力设计清洗规则。为了保证数据的完整性，没有在当前的ETL中做清洗。

数据语义化／统一描述

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

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

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

保存历史

数据仓库可通过拉链表的形式来记录业务状态变化，甚至可以设计专用的事实表来记录。只要有历史分析的需要，就可以去实现。

高速查询

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

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

大数据时代，如何构建企业数据仓库？

大数据是我的主要研究方向之一，目前也在带相关方向的研究生，所以我来回答一下这个问题。

首先，数据仓库对于企业来说是比较传统的数据管理方案，具有一定规模的企业通过建立数据仓库能够解决一定的“数据孤岛”问题，从而能够让企业的数据有一个更加合理的利用，同时也能够让多个系统通过数据仓库完成互联互通。

我一直想回答这个问题，但是由于我的答案是软件开发相关的，比较小众，怕别人很难理解。现在这个关于Spring的问题的回答就算是我对这个问题的回答吧。

软件开发的一个亘古不变的方针策略就是抽象、透明和封装。语言从汇编到面向过程到面向对象，开发从原生代码到类库到框架，都是这个趋势。别说软件开发了，就说软件使用吧，从DOS命令行到GUI图形化界面，也是这个方向。

抽象、透明、封装就是不让你陷入到底层的细节当中，把精力专注在你那一层面的问题上。什么叫你那一层面的问题？你开发产品或者项目，就把精力用在实现业务需求上。并不是底层不重要，而是没必要到一开始就去看底层源代码的地步！

我想先问一下题主和有些答主，http://spring.io上的文档你们都读了几遍了？

所有项目的文档读不过来没事，spring framework这一个项目的reference有完整从头到尾读一遍的吗？然后再来问怎么阅读spring源代码，或者回答人家如何阅读spring源代码。

详细认真读过spring所有项目的reference，并对所有API doc了如指掌的人都少之又少。你先开始读源代码干嘛？说明书和各种电器参数都不看就想把家里的电视拆了研究的，只能是熊孩子干出来的事。我见到太多简历里面写阅读Linux源代码的，这些人无一例外都是浮躁型的。

不建议读框架的源代码，如何实现一个框架和如何用框架实现业务有很大的不同，在阅读底层框架源代码上的时间精力投入相比收获来说不划算。

只有下面三种情况，你可能需要阅读源代码：

你打算发明一个类似Spring Framkework一样的框架，可以参考源代码。
你自认为发现了Spring的一个Bug，并提交到官方的Issues list，且得到确认。而你想贡献自己的力量帮助Spring团队解决这个Bug。不过在你发现疑似Bug的时候，最好先去Issues list里面或者stackoverflow上找一下答案再说。以目前Spring的健壮性和被广泛采用的程度，几乎没有可能有一个Bug被你捡漏。
Debug跟踪进入底层框架代码的时候，不得不看两眼。

反过来想想，如果什么框架要你必须阅读源代码才能掌握，那这个框架一定很烂、不成熟，或者说至少处于成熟的前期。

为什么这么说呢？像Google、Facebook、Microsoft等大厂，开源项目是专职团队做的，是有专门的文档编写和社区关系维护人员的。但有些开源团队确实是几个大牛用业余时间在做。没有专职的文档和公关人员。他们前期的精力肯定是要放在开发框架本身上。框架基本满意了，才开始考虑文档，然后还可能顺手把网站也搞漂亮点。Spring和Hibernate很早很早以前都是属于这种情况。

我把话说直接点吧：所有跳过文档这一步就想直接阅读底层源代码的，只能是英文水平不行，读不懂文档又急于求成。想给自己的简历或平时的谈资加点料而已。在没有正确的学习路径下，一时不知道如何提高自己又心急的人，很容易想到的就是去读底层源码