亿信华辰

连续4年稳坐商务智能应用榜首

与此同时,亿信华辰在数据治理领域也获得殊荣,摘得榜眼

首页关于行业资讯数据治理

为什么我们需要数据仓库

时间:2019-01-07来源:LongFei浏览数:565

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

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

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

  • 结构复杂

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

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

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

  • 数据脏乱

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

  • 理解困难

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

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

  • 缺少历史

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

  • 大规模查询缓慢

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

数据仓库解决方案

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

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

  • 结构清晰,简单

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

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

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

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

  • 可复用,易拓展

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

  • 数据干净

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

  • 数据语义化/统一描述

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

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

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

  • 保存历史

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

  • 高速查询

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

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


(部分内容来源网络,如有侵权请联系删除)
立即免费申请产品试用 申请试用

微信
咨询

立即扫码
享受一对一服务

亿信微信二维码

联系
电话

您好,商务咨询请联系

咨询热线:400-0011-866转0

手机咨询:137-0121-6790