精华内容
下载资源
问答
  • 数据仓库建模案例

    千次阅读 2019-09-03 11:05:38
    数据仓库建模包含了几种数据建模技术,除了之前在数据库系列中介绍过的ER建模和关系建模,还包括专门针对数据仓库的维度建模技术。 本文将详细介绍数据仓库维度建模技术,并重点讨论三种基于ER建模/关系建模/维度...

    数据仓库与数据集市建模
    前言
    数据仓库建模包含了几种数据建模技术,除了之前在数据库系列中介绍过的ER建模和关系建模,还包括专门针对数据仓库的维度建模技术。

        本文将详细介绍数据仓库维度建模技术,并重点讨论三种基于ER建模/关系建模/维度建模的数据仓库总体建模体系:规范化数据仓库,维度建模数据仓库,以及独立数据集市。
    

    维度建模的基本概念
    维度建模(dimensional modeling)是专门用于分析型数据库、数据仓库、数据集市建模的方法。

        它本身属于一种关系建模方法,但和之前在操作型数据库中介绍的关系建模方法相比增加了两个概念:
    
        1. 维度表(dimension)
    
        表示对分析主题所属类型的描述。比如"昨天早上张三在京东花费200元购买了一个皮包"。那么以购买为主题进行分析,可从这段信息中提取三个维度:时间维度(昨天早上),地点维度(京东), 商品维度(皮包)。通常来说维度表信息比较固定,且数据量小。
    
        2. 事实表(fact table)
    
        表示对分析主题的度量。比如上面那个例子中,200元就是事实信息。事实表包含了与各维度表相关联的外码,并通过JOIN方式与维度表关联。事实表的度量通常是数值类型,且记录数会不断增加,表规模迅速增长。
    
        注:在数据仓库中不需要严格遵守规范化设计原则(具体原因请看上篇)。本文示例中的主码,外码均只表示一种对应关系,此处特别说明。
    

    维度建模的三种模式
    1. 星形模式

        星形模式(Star Schema)是最常用的维度建模方式,下图展示了使用星形模式进行维度建模的关系结构:
    

    在这里插入图片描述

        可以看出,星形模式的维度建模由一个事实表和一组维表成,且具有以下特点:
    
                a. 维表只和事实表关联,维表之间没有关联;
    
                b. 每个维表的主码为单列,且该主码放置在事实表中,作为两边连接的外码;
    
                c. 以事实表为核心,维表围绕核心呈星形分布;
    
        2. 雪花模式
    
        雪花模式(Snowflake Schema)是对星形模式的扩展,每个维表可继续向外连接多个子维表。下图为使用雪花模式进行维度建模的关系结构:
    

    在这里插入图片描述

        星形模式中的维表相对雪花模式来说要大,而且不满足规范化设计。雪花模型相当于将星形模式的大维表拆分成小维表,满足了规范化设计。然而这种模式在实际应用中很少见,因为这样做会导致开发难度增大,而数据冗余问题在数据仓库里并不严重。
    
        3. 星座模式
    
        星座模式(Fact Constellations Schema)也是星型模式的扩展。基于这种思想就有了星座模式:
    

    在这里插入图片描述

        前面介绍的两种维度建模方法都是多维表对应单事实表,但在很多时候维度空间内的事实表不止一个,而一个维表也可能被多个事实表用到。在业务发展后期,绝大部分维度建模都采用的是星座模式。
    
        4. 三种模式对比
    
        归纳一下,星形模式/雪花模式/星座模式的关系如下图所示:
    

    在这里插入图片描述

        雪花模式是将星型模式的维表进一步划分,使各维表均满足规范化设计。而星座模式则是允许星形模式中出现多个事实表。本文后面部分将具体讲到这几种模式的使用,请读者结合实例体会。
    

    实例:零售公司销售主题的维度建模
    在进行维度建模前,首先要了解用户需求。而笔者在数据库系列的第一篇就讲过,ER建模是当前收集和可视化需求的最佳技术。因此假定和某零售公司进行多次需求PK后,得到以下ER图:
    在这里插入图片描述

        随后可利用建模工具将ER图直接映射到关系图: 
    

    在这里插入图片描述
    需求搜集完毕后,便可进行维度建模了。本例采用星形模型维度建模。但不论采取何种模式,维度建模的关键在于明确下面四个问题:

        1. 哪些维度对主题分析有用?
    
        本例中,根据产品(PRODUCT)、顾客(CUSTOMER)、商店(STORE)、日期(DATE)对销售额进行分析是非常有帮助的;
    
        2. 如何使用现有数据生成维表?
    
                a. 维度PRODUCT可由关系PRODUCT,关系VENDOR,关系CATEGORY连接得到;
    
                b. 维度CUSTOMER和关系CUSTOMER相同;
    
                c. 维度STORE可由关系STROE和关系REGION连接得到;
    
                d. 维度CALENDAR由关系SALESTRANSACTION中的TDate列分离得到;
    
        3. 用什么指标来"度量"主题?
    
        本例的主题是销售,而销量和销售额这两个指标最能直观反映销售情况;
    
        4. 如何使用现有数据生成事实表?
    
        销量和销售额信息可以由关系SALESTRANSACTION和关系SOLDVIA,关系PRODUCT连接得到;
    
        明确这四个问题后,便能轻松完成维度建模:
    

    在这里插入图片描述
    细心的读者会发现三个问题:1. 维表不满足规范化设计(不满足3NF);2. 事实表也不满足规范化设计(1NF都不满足); 3. 维度建模中各维度的主码由***ID变成***Key;

        对于前两个问题,由于当前建模环境是数据仓库,而没有更新操作,所以不需要严格做规范化设计来消除冗余避免更新异常。
    
        因此虽然可以以雪花模型进行维度建模,如下所示: 
    

    在这里插入图片描述
    但这样会加大查询人员负担:每次查询都涉及到太多表了。因此在实际应用中,雪花模型仅是一种理论上的模型。星座模型则出现在"维度建模数据仓库"中,本文后面将会讲到。

        对于第三个问题,***Key这样的字段被称为代理码(surrogate key),它是一个通过自动分配整数生成的主码,没有任何其他意义。使用它主要是为了能够处理"缓慢变化的维度",本文后面会仔细分析这个问题,这里不纠结。
    

    更多可能的事实属性
    除了对应到维度的外码和度量属性,事实表中还常常考虑另外两个属性:事务标识码(transaction identifier)和事务时间(transaction time)。

        事务标识码通常被命名为TID,其意义就是各种订单号,事务编号...... 为什么将这个属性放到事实表而不是维表中呢?一个主要原因是它的数量级太大了,这样每次查询都会耗费很多资源来Join。这种将某些逻辑意义上的维度放到事实表里的做法被称为退化维度(degenerate dimension)。
    
        将事务时间维度放到事实表中的考虑也是出于相同考虑。然而这么设计又一次"逆规范化"了:事务标识码非主码却决定事务标识时间,显然违背了3NF。但现在我们是为数据仓库建模,所以这样做是OK的。另外在分布式的数据仓库中,这个字段十分重要。因为事实表的数量级非常大,Hive或者Spark SQL这类分布式数据仓库工具都会对这些数据进行分区。任何成熟的分布式计算平台中都应禁止开发人员建立非分区事实表,并默认分区字段为(当天)日期。
    

    经典星座模型
    前文已经讲过,有多个事实表的维度模型被称为星座模型。星座模型主要有以下两大作用:共享维度和设置细节/聚集事实表。下面分别对这两种情况进行分析:

        1. 共享维度
    
        以前文提到的零售公司为例,假如该公司质量监管部门希望用分析销售主题同样的方法分析劣质产品,那么此时不需要重新维度建模,只需往模型里加入一个新的劣质产品事实表。之后新的数据仓库维度建模结果如下:
    

    在这里插入图片描述

        2. 细节/聚集事实表
    
        细节事实表(detailed fact tables)中每条记录表示单一事实,而聚集事实表(aggregated fact tables)中每条记录则聚合了多条事实。从表的字段上看,细节事实表通常有设置TID属性,而聚集事实表则无。
    
        两种事实表各有优缺点,细节事实表查询灵活但是响应速度相对慢,而聚集事实表虽然提高了查询速度,但使查询功能受到一定限制。一个常见的做法是使用星座模型同时设置两种事实表(可含多个聚集事实表)。这种设计方法中,聚集事实表使用和细节事实表细节事实表的维度。如下维度建模方法采用星座模型综合了细节事实表和两种聚集事实表:
    

    在这里插入图片描述

    缓慢变化维度问题
    虽然,维表的数据比事实表更稳定。但不论如何维度在某些时候总会发生一些变化。在之前曾抛出一个问题:为什么维度建模后的关系不是***ID,而是***Key了。这样做的目的其实就是为了解决一种被称为缓慢维度变化(slowly changing dimension)的问题。在维度变化后,一部分历史信息就被丢掉了。比如张三是某公司会员。

        但仅仅这么做还是不够的,代理码需要配合时间戳,以及行标识符使用才能解决缓慢维度变化的问题。如下CUSTOMER表使用该方法避免缓慢维度变化:
    

    在这里插入图片描述

        可以看到用户张三对应新维度的TaxBracket状态由Low变成了High。如果需要统计张三的相关行为,那么可以让所有记录用CustomerID字段Join事实表;如果要统计当前TaxBracket为Low的用户状态,则可将Row Indicator字段为Current的记录用CustomerKey字段Join事实表;如果要统计历史TaxBracket状态为Low的用户情况,则只需要将TaxBracket属性为Low的用户记录的CustomerKey属性与事实表关联。
    

    数据仓库建模体系之规范化数据仓库
    所谓"数据仓库建模体系",指的是数据仓库从无到有的一整套建模方法。最常见的三种数据仓库建模体系分别为:规范化数据仓库,维度建模数据仓库,独立数据集市。很多书将它们称为"数据仓库建模方法",但笔者认为数据仓库建模体系更能准确表达意思,请允许我自作主张一次吧:)。下面首先来介绍规范化数据仓库。

        规范化数据仓库(normalized data warehouse)顾名思义,其中是规范化设计的分析型数据库,然后基于这个数据库为各部门建立数据集市。总体架构如下图所示:
    

    在这里插入图片描述

        该建模体系首先对ETL得到的数据进行ER建模,关系建模,得到一个规范化的数据库模式。然后用这个中心数据库为公司各部门建立基于维度建模的数据集市。各部门开发人员大都从这些数据集市提数,通常来说不允许直接访问中心数据库。    
    

    数据仓库建模体系之维度建模数据仓库
    非维度建模数据仓库(dimensionally modeled data warehouse)是一种使用交错维度进行建模的数据仓库,其总体架构如下图所示:
    在这里插入图片描述
    该建模体系首先设计一组常用的度集合(conformed dimension),然后创建一个大星座模型表示所有分析型数据。如果这种一致维度不满足某些数据分析要求,自然也可在数据仓库之上继续构建新的数据集市。

    数据仓库建模体系之独立数据集市
    独立数据集市的建模体系是让公司的各个组织自己创建并完成ETL,自己维护自己的数据集市。其总体架构如下图所示:
    在这里插入图片描述

        从技术上来讲这是一种很不值得推崇的方式,因为将使信息分散,影响了企业全局范围内数据分析的效率。此外,各组织之间的ETL架构相互独立无法复用,也浪费了企业的开发资源。然而出于某些公司制度及预算方面的考虑,有时也会使用到这种建模体系。
    

    三种数据仓库建模体系对比
    规范化数据仓库和维度建模数据仓库分别是Bill Inmon和Ralph Kimball提出的方法。关于哪种方法更好,哪种方法更优秀的争论已经由来已久。但随着这两种数据仓库应用越来越多,人们也逐渐了解到两种数据仓库的优劣之处,如下表所示:
    在这里插入图片描述

        产生这些区别的根本之处在于规范化数据仓库需要对企业全局进行规范化建模,这将导致较大的工作量。但这一步必须完成好,才能继续往上建设数据集市。因此也就导致规范化数据仓库需要一定时间才能投入使用,敏捷性相对后者来说略差。但是规范化数据仓库一旦建立好了,则以后数据就更易于管理。而且由于开发人员不能直接使用其中心数据库,更加确保了数据质量。还有由于中心数据库是采用规范化设计的,冗余情况也会更少。
    
        然而另一方面维度建模数据仓库除了敏捷性更强,而且适用于业务变化比较频繁的情况,对开发人员的要求也没有规范化数据仓库那么高。总之各有利弊,具体实施时需要仔细的权衡。
    

    小结
    数据仓库建模是一个综合性技术,需要使用到ER建模、关系建模、维度建模等技术。而且当企业业务复杂的时候,这部分工作更是需要专门团队与业务方共同合作来完成。因此一个优秀的数据仓库建模团队既要有坚实的数据仓库建模技术,还要有对现实业务清晰、透彻的理解。

    展开全文
  • 数据仓库建模方法与建模案例

    千次阅读 2020-07-28 09:51:57
    2. 常见的数据建模方法有哪些?3. 常见的建模工具有哪些?1.数据仓库建模的目的?为什么要进行数据仓库建模?大数据的数仓建模是通过建模的方法更好的组织、存储数据,以便在 性能、成本、效率和数据质量之间找到...

    1. 数据仓库建模的目的是什么?
    2. 常见的数据建模方法有哪些?
    3. 常见的建模工具有哪些?


    1.数据仓库建模的目的?

    为什么要进行数据仓库建模?大数据的数仓建模是通过建模的方法更好的组织、存储数据,以便在 性能、成本、效率和数据质量之间找到最佳平衡点。一般主要从下面四点考虑
     

    • 访问性能:能够快速查询所需的数据,减少数据I/O
    • 数据成本:减少不必要的数据冗余,实现计算结果数据复用,降低大数 据系统中的存储成本和计算成本
    • 使用效率:改善用户应用体验,提高使用数据的效率
    • 数据质量:改善数据统计口径的不一致性,减少数据计算错误 的可能性,提供高质量的、一致的数据访问平台


    2.常见的数据建模方法

    数据仓库本质是从数据库衍生出来的,所以数据仓库的建模也是不断衍生发展的。从最早的借鉴数据库的范式建模,到逐渐提出维度建模,Data Vault模型,Anchor模型等等,越往后建模的要求越高,越需满足3NF,4NF等。但是对于数据仓库来说,目前主流还是维度建模,会夹杂着范式建模。

    数据仓库建模方法论可分为:范式建模、维度建模、Data Vault模型、Anchor模型。



    3.常见四种建模方法的建模步骤与演示

    3.1.范式建模(E-R模型)

          将事物抽象为“实体”、“属性”、“关系”来表示数 据关联和事物描述;实体:Entity,关系:Relationship,这种对数据的抽象 建模通常被称为ER实体关系模型
          模型是数据库设计的理论基础,当前几乎所有的OLTP系统设计都采用ER模型建模的方式,且该建模方法需要满足3NF。Bill Inom提出的数仓理论,推荐采用ER关系模型进行建模,BI架构提出分层架构,数仓底层ods、dwd也多采用ER关系模型就行设计。
          但是逐渐随着企业数据的高增长,复杂化,数仓全部使用ER模型建模显得越来越不合时宜。为什么呢,因为其按部就班的步骤,三范式等,不适合现代化复杂,多变的业务组织。

    E-R模型建模的步骤(满足3NF)如下:

    • 抽象出主体         (教师,课程)
    • 梳理主体之间的关系   (一个老师可以教多门课,一门课可以被多个老师教)
    • 梳理主体的属性    (教师:教师名称,性别,学历等)
    • 画出E-R关系图




    3.2.维度建模

          维度建模,是数据仓库大师Ralph Kimball提出的,是数据仓库工程领域最流行的数仓建模经典。
          维度建模以分析决策的需求出发构建模型,构建的数据模型为分析需求服务,因此它重点解决用户如何更快速完成分析需求,同时还有较好的大规模复杂查询的响应性能。维度建模是面向分析的,为了提高查询性能可以增加数据冗余,反规范化的设计技术。

          Ralph Kimball提出对数据仓库维度建模,并且将数据仓库中的表划分为事实表、维度表两种类型。

    3.2.1.事实表

          在ER模型中抽象出了有实体、关系、属性三种类别,在现实世界中,每一个操作型事件,基本都是发生在实体之间的,伴随着这种操作事件的发生,会产生可度量的值,而这个过程就产生了一个事实表,存储了每一个可度量的事件。

    以电商行业为例:电商场景:一次购买事件,涉及主体包括客户、商品、商家,产生的可度量值 包括商品数量、金额、件数等



    事实表根据粒度的角色划分不同,可分为事务事实表、周期快照事实表、累积快照事实表。注意:这里需要值得注意的是,在事实表的设计时,一定要注意一个事实表只能有一个粒度,不能将不同粒度的事实建立在同一张事实表中。

    • 事务事实表,用于承载事务数据,通常粒度比较低,它是面向事务的,其粒度是每一行对应一个事务,它是最细粒度的事实表,例如产品交易事务事实、ATM交易事务事实。
    • 周期快照事实表,按照一定的时间周期间隔(每天,每月)来捕捉业务活动的执行情况,一旦装入事实表就不会再去更新,它是事务事实表的补充。用来记录有规律的、固定时间间隔的业务累计数据,通常粒度比较高,例如账户月平均余额事实表。
    • 累积快照事实表,用来记录具有时间跨度的业务处理过程的整个过程的信息,每个生命周期一行,通常这类事实表比较少见。


    3.2.2.维度表

          维度,顾名思义,业务过程的发生或分析角度。比如从颜色、尺寸的角度来比较手机的外观,从cpu、内存等较比比较手机性能维。维度表一般为单一主键,在ER模型中,实体为客观存在的事物,会带有自己的 描述性属性,属性一般为文本性、描述性的,这些描述被称为维度。
          比如商品,单一主键:商品ID,属性包括产地、颜色、材质、尺寸、单价等, 但并非属性一定是文本,比如单价、尺寸,均为数值型描述性的,日常主要的维度抽象包括:时间维度表、地理区域维度表等

    案例:某电商平台,经常需要对订单进行分析,以某宝的购物订单为例,以维度建 模的方式设计该模型
          涉及到事实表为订单表、订单明细表,维度包括商品维度、用户维度、商家维度、区域维 度、时间维度
          商品维度:商品ID、商品名称、商品种类、单价、产地等
          用户维度:用户ID、姓名、性别、年龄、常住地、职业、学历等
          时间维度:日期ID、日期、周几、上/中/下旬、是否周末、是否假期等


    维度分为:

    (1)退化维度(DegenerateDimension)

    在维度类型中,有一种重要的维度称作为退化维度,亦维度退化一说。这种维度指的是直接把一些简单的维度放在事实表中。退化维度是维度建模领域中的一个非常重要的概念,它对理解维度建模有着非常重要的作用,退化维度一般在分析中可以用来做分组使用。

    (2)缓慢变化维(Slowly Changing Dimensions)

    维度的属性并不是始终不变的,它会随着时间的流逝发生缓慢的变化,这种随时间发生变化的维度我们一般称之为缓慢变化维(SCD)。比如员工表中的部门维度,员工的所在部门有可能两年后调整一次。

    3.2.3.维度建模模型的分类

    维度建模按数据组织类型划分可分为星型模型、雪花模型、星座模型。
    (1)星型模型
    星型模型主要是维表和事实表,以事实表为中心,所有维度直接关联在事实表上,呈星型分布。


    (2)雪花模型

        雪花模型,在星型模型的基础上,维度表上又关联了其他维度表。这种模型维护成本高,性能方面也较差,所以一般不建议使用。尤其是基于hadoop体系构建数仓,减少join就是减少shuffle,性能差距会很大。


    尖叫提示:所以由上可以看出

    • 星型模型和雪花模型主要区别就是对维度表的拆分
    • 对于雪花模型,维度表的涉及更加规范,一般符合3NF,有效降低数据冗余,维度表之间不会相互关联,但是
    • 而星型模型,一般采用降维的操作,反规范化,不符合3NF,利用冗余来避免模型过于复杂,提高易用性和分析效率,效率相对较高。
       

    (3)星座模型

         星座模型,是对星型模型的扩展延伸,多张事实表共享维度表。数仓模型建设后期,大部分维度建模都是星座模型。

    3.2.4. 维度建模步骤

    维度建模步骤:选择业务过程->声明粒度->确定维度->确定事实。旨在重点解决数据粒度、维度设计和事实表设计问题。



    声明粒度,为业务最小活动单元或不同维度组合。以共同粒度从多个组织业务过程合并度量的事实表称为合并事实表,需要注意的是,来自多个业务过程的事实合并到合并事实表时,它们必须具有同样等级的粒度。

    3.3 DataVault模型
              Data Vault是Dan Linstedt发起创建的一种模型方法论,Data Vault是在ER模型的基础上衍生而来,模型设计的初衷是有效的组织基础数据层,使之易扩展、灵活的应对业务的变化,同时强调历史性、可追溯性和原子性,不要求对数据进行过度的一致性处理。同时设计的出发点也是为了实现数据的整合,并非为数据决策分析直接使用。
              Data Vault模型是一种中心辐射式模型,其设计重点围绕着业务键的集成模式。这些业务键是存储在多个系统中的、针对各种信息的键,用 于定位和唯一标识记录或数据

    Data Vault模型包含三种基本结构 :

    • 中心表-Hub :唯一业务键的列表,唯一标识企业实际业务,企业的业务主体集合
    • 链接表-Link: 表示中心表之间的关系,通过链接表串联整个企业的业务关联关系
    • 卫星表- Satellite: 历史的描述性数据,数据仓库中数据的真正载体


    3.3.1 中心表-Hub



    3.3.2 链接表-Link



    3.3.3 卫星表- Satellite



    3.3.4 Data Vault模型​​​​​​建模流程

    • 梳理所有主要实体
    • 将有入边的实体定义为中心表
    • 将没有入边切仅有一个出边的表定义为中心表
    • 源苦衷没有入边且有两条或以上出边的表定义为连接表
    • 将外键关系定义为链接表




    尖叫提示:Hub想像成人体的骨架,那么Link就是连接骨架的韧带组织, 而satelite就是骨架上的血肉。 Data Vault是对ER模型更近一步的规范化,由于对数据的拆解和更偏向于基础数据组织,在处理分析类场景时相对复杂, 适合数仓低层构建,目前实际应用场景较少

    3.4Anchor模型

    • Anchor是对Data Vault模型做了更近一步的规范会处理,初衷是为了 设计高度可扩展的模型,核心思想是所有的扩张只添加而不修改,于 是设计出的模型基本变成了k-v结构的模型,模型范式达到了6NF
    • 由于过度规范化,使用中牵涉到太多的join操作,目前木有实际案例,仅作了解


    4.四种模型总结

    以上为四种基本的建模方法,当前主流建模方法为:ER模型、维度模型

    • ER模型常用于OLTP数据库建模,应用到构建数仓时更偏重数据整合, 站在企业整体考虑,将各个系统的数据按相似性一致性、合并处理,为 数据分析、决策服务,但并不便于直接用来支持分析。缺陷:需要全面梳理企业所有的业务和数据流,周期长,人员要求高。
    • 维度建模是面向分析场景而生,针对分析场景构建数仓模型;重点关注快 速、灵活的解决分析需求,同时能够提供大规模数据的快速响应性能。针对性 强,主要应用于数据仓库构建和OLAP引擎低层数据模型。优点:不需要完整的梳理企业业务流程和数据,实施周期根据主题边界而定,容易快速实现demo
    • 数仓模型的选择是灵活的,不局限于某一种模型方法
    • 数仓模型的设计也是灵活的,以实际需求场景为导向
    • 模型设计要兼顾灵活性、可扩展,而对终端用户透明性
    • 模型设计要考虑技术可靠性和实现成本


    5.常用建模工具

    建模工具,一般企业以Erwin、powerdesigner、visio,甚至Excel等为主。也有些企业自行研发工具,或使用阿里等成熟套装组件产品。

    展开全文
  • 数据流图与需求分析建模案例数据流图与需求分析建模案例数据流图与需求分析建模案例
  • 数据建模讲解和案例分析

    万次阅读 多人点赞 2017-04-18 13:34:09
    第一部分:数据建模理论和逻辑 一、从数据分析的定义开始 维基百科对数据分析的定义如下: Analysis of data is a process of inspecting, cleaning, transforming, and modeling data with the goal of ...

    第一部分:数据建模理论和逻辑

    一、从数据分析的定义开始

    维基百科对数据分析的定义如下:

    Analysis of data is a process of inspecting, cleaning, transforming, and modeling data with the goal of discovering useful information, suggesting conclusions, and supporting decision making. Data analysis has multiple facets and approaches, encompassing diverse techniques under a variety of names, in different business, science, and social science domains.
    (来源:Data analysis

    简单翻译:数据分析是一个包含数据检验、数据清洗、数据重构,以及数据建模的过程,目的在于发现有用的信息,有建设性的结论,辅助决策的制定。数据分析有多种形式和方法,涵盖了多种技术,应用于商业、科学、社会学等多个不同的领域。

    和上篇文章中我画的图对比一下:

    我在上篇文章中为了让初学者更容易走通全流程,简化了数据清洗的过程,实际上数据清洗绝非一次完成,“检验-清洗-检验”的过程可能会重复数次乃至数十次。

    而建模呢?再次引用维基上对数据建模的定义:

    Data modeling is a process used to define and analyze data requirements needed to support the business processes within the scope of corresponding information systems in organizations. Therefore, the process of data modeling involves professional data modelers working closely with business stakeholders, as well as potential users of the information system.(来源:Data modeling
    简单翻译:数据建模是一个用于定义和分析在组织的信息系统的范围内支持商业流程所需的数据要求的过程。因此,数据建模的过程需要专业建模师与商业人员和信息系统潜在用户的紧密合作。这段话的定义更偏向信息系统和商业数据建模,我之所以在此引用这段话,是为了明确接下来的讨论内容主要方向是商业数据分析和建模,至于科学研究方向的数据建模,不在这篇文章的讨论范围以内。

    请注意上边这段话中的一个核心:支持商业流程。商业数据建模,乃至商业数据分析,其最终目的都是要支持某种商业流程,要么优化原有流程,提高各部分效率;要么重构原有流程,减少步骤;要么告诉决策者,哪些流程改造方向是错误的,以避免走错路。最终的目标,一定是提升效率。但在不同的情况下,提升效率的方式也是不同的,因此在每个模型建立时,都需要确定其解决的具体目标问题。

    再往前走一步,数学—主要是统计学,在建模的过程中又扮演什么样的角色呢?继续引用维基:

    Mathematical formulas or models called algorithms may be applied to the data to identify relationships among the variables, such as correlation or causation. In general terms, models may be developed to evaluate a particular variable in the data based on other variable(s) in the data, with some residual error depending on model accuracy (i.e., Data = Model + Error)(来源:Data modeling

    简单翻译:数学公式或模型称为算法,可应用于数据以确定变量之间的关系,如相关性或因果关系。在一般情况下,模型开发出来后用于评估一个特定的变量与数据中其他其他变量的关系,根据模型的准确性不同,这些关系中会包含残差(即,数据=模型+错误)

    这段描述很明确,统计学在数据建模的过程中,主要用于帮助我们找出变量之间的关系,并对这种关系进行定量的描述,输出可用于数据集的算法。一个好的数据模型,需要通过多次的测试和优化迭代来完成。

    综上,给出一个我认为的“数据建模”定义:数据集+商业目标+算法+优化迭代= 数据建模。定义中的每一部分都必不可少。

    二、数据模型的建立过程

    照例,先上流程图:

    上图的流程颜色对应数据分析全流程,为了方便大家阅读,我把全流程图再贴一次:

     

    接下来,我重点解读明黄色(浅黄?)部分的内容:

    • 选择变量与重构变量

    在进行建模之前,首先要考虑的是使用哪些变量来建立模型,需要从业务逻辑和数据逻辑两个方面来考虑:

    业务逻辑:变量基于收集到的数据,而数据在收集时,会产生与业务层面相关的逻辑,比如在汽车参数中,一旦我们定义了“家用轿车”这个类别,那么无论什么品牌什么车型,“轮胎数量(不计备胎)”这个变量就有99%以上几率为4……当然在接下来的建模中,我们不会选择这个变量。这一类情况是业务知识来告诉我们哪些变量可以选择,哪些不能选择。

    数据逻辑:通常从数据的完整性、集中度、是否与其他变量强相关(甚至有因果关系)等角度来考虑,比如某个变量在业务上很有价值,但缺失率达到90%,或者一个非布尔值变量却集中于两个值,那么这个时候我们就要考虑,加入这个变量是否对后续分析有价值。

    我个人认为,在选择变量时,业务逻辑应该优先于数据逻辑,盖因业务逻辑是从实际情况中自然产生,而建模的结果也要反馈到实际中去,因此选择变量时,业务逻辑重要程度相对更高。

    而在变量本身不适合直接拿来建模时,例如调查问卷中的满意度,是汉字的“不满意”“一般”“满意”,那么需要将其重构成“1”(对应不满意)“2”(对应一般)“3”(对应满意)的数字形式,便于后续建模使用。

    除这种重构方式之外,将变量进行单独计算(如取均值)和组合计算(如A*B)也是常用的重构方法。其他的重构方法还有很多种,在此不一一阐述。

    • 选择算法

    我们在建模时,目标是解决商业问题,而不是为了建模而建模,故此我们需要选择适合的算法。常用建模算法包括相关、聚类、分类(决策树)、时间序列、回归、神经网络等。

    以对消费者的建模为例,举一些场景下的常用算法对应:

    划分消费者群体:聚类,分类;

    购物篮分析:相关,聚类;

    购买额预测:回归,时间序列;

    满意度调查:回归,聚类,分类;

    等等。

    确定算法后,要再看一下变量是否满足算法要求,如果不满足,回到选择/重构变量,再来一遍吧。如果满足,进入下一步。

    • 设定参数

    算法选定后,需要用数据分析工具进行建模。针对不同的模型,需要调整参数,例如聚类模型中的K-means算法,需要给出希望聚成的类别数量,更进一步需要给出的起始的聚类中心和迭代次数上限。

    这些参数在后续测试中会经过多次调整,很少有一次测试成功的情况,因此请做好心理准备。

    • 加载算法与测试结果

    算法跑完之后,要根据算法的输出结果来确定该算法是否能够解决问题,比如K-means的结果不好,那么考虑换成系统聚类算法来解决。或者回归模型输出的结果不满足需求,考虑用时间序列来做。

    如果不需要换算法,那么就测试一下算法输出的结果是否有提升空间,比如聚类算法中指定聚类结果包含4类人群,但发现其中的两类特征很接近,或者某一类人群没有明显特征,那么可以调整参数后再试。

    在不断的调整参数,优化模型过程中,模型的解释能力和实用性会不断的提升。当你认为模型已经能够满足目标需求了,那就可以输出结果了。一个报告,一些规则,一段代码,都可能成为模型的输出。在输出之后,还有最后一步:接收业务人员的反馈,看看模型是否解决了他们的问题,如果没有,回到第一步,再来一次吧少年……

    以上,就是建模的一般过程。如果你有些地方觉得比较生涩,难以理解,也没有关系。下一篇专栏中,我将向你们介绍一个具体的数据模型,我会对建模的过程一步步进行拆解,力求简明易懂。

    第二部分:数据建模的应用

    我写了个建模的流程,有过建模经验的人自然懂,没有经验的各位也不要着急,这次我以一个真实模型为例,给大家详细讲述建模的各个步骤。照例,先上流程图:

    大家可以看到,这个图是由我之前文章中的两张图拼合而来,而我今天讲的这个真实模型,将把图中所有的流程都走一遍,保证一个步骤都不漏。

    Step 0:项目背景

    话说这个项目跟我加入百度有直接关系……

    2013年的最后一天,我结束了在三亚的假期,准备坐飞机回家,这时候接到一个知乎私信,问我对百度的一个数据科学家(其实就是数据分析师啦)职位是否感兴趣,我立刻回信,定了元旦假期以后去面试。两轮面试过后,面试官——也是我加入百度后的直属Leader——打电话给我,说他们对我的经历很满意,但是需要我给他们一份能体现建模能力的报告。

    按说这也不是一件难事,但我翻了翻电脑后发现一个问题:我从上家公司离职时,为了装13,一份跟建模相关的报告文件都没带……最后双方商定,我有一个星期时间来做一份报告,这份报告决定了我是否能加入百度。

    那么,是时候展示我的技术了!我的回合,抽卡!

    Step 1:目标确定

    看看报告的要求:

    数据最好是通过抓取得来,需要用到至少一种(除描述统计以外)的建模技术,最好有数据可视化的展示

    看来是道开放题,那么自然要选择一个我比较熟悉的领域,因此我选择了……《二手主机游戏交易论坛用户行为分析》

    为啥选这个呢?你们看了我那么多的Mario图,自然知道我会选主机游戏领域,但为什么是二手?这要说到我待在国企的最后半年,那时候我一个月忙三天,剩下基本没事干,因此泡在论坛上倒卖了一段时间的二手游戏……

    咳咳……总之,目标就确定了:分析某二手主机游戏交易论坛上的帖子,从中得出其用户行为的描述,为用户进行分类,输出洞察报告。

    Step 2:数据获取

    简单来说,就是用python写了个定向爬虫,抓了某个著名游戏论坛的二手区所有的发帖信息,包括帖子内容、发帖人信息等,基本上就是长这个样子:

    (打码方式比较简单粗暴,请凑合看吧……)

    Step 3:数据清洗

    这个模型中的数据清洗,主要是洗掉帖子中的无效信息,包括以下两类:

    1、论坛由于其特殊性,很多人成交后会把帖子改成《已出》等标题,这一类数据需要删除:

    2、有一部分人用直接贴图的方式放求购信息,这部分体现为只抓到图片链接,需要删除。

    数据清洗结束了么?其实并没有,后边会再进行一轮清洗……不过到时再说。

    Step 4:数据整理

    用上面的那些帖子数据其实是跑不出啥结果的,我们需要把数据整理成可以进一步分析的格式。

    首先,我们给每条帖子打标签,标签分为三类:行为类型(买 OR 卖 OR 换),目标厂商(微软 OR 索尼 OR 任天堂),目标对象(主机 OR 游戏软件)。打标签模式是”符合关键词—打相应标签“的方法,关键词表样例如下:

    (主机掌机那个标签后来我在实际操作时没有使用)

    打完标签之后,会发现有很多帖子没有打上标签,原因有两种:一是关键词没有涵盖所有的产品表述(比如三公主这种昵称),二是有一部分人发的帖子跟买卖游戏无关……

    这让人怎么玩……第二次数据清洗开始,把这部分帖子也洗掉吧。

    其次,我们用发帖用户作为视角,输出一份用户的统计表格,里边包含每个用户的发帖数、求购次数、出售次数、交换次数、每一类主机/游戏的行为次数等等,作为后续搭建用户分析模型之用。表格大概长这个样子:

    之后这个表的列数会越来越多,因为数据重构的工作都在此表中进行。

    整理之后,我们准备进行描述统计。

    Step 5 & 6:描述统计 & 洞察结论

    描述统计在这个项目中的意义在于,描述这一社区的二手游戏及主机市场的基本情况,为后续用户模型的建立提供基础信息。

    具体如何进行统计就不说了,直接放成品图,分别是从各主机市场份额、用户相互转化情况、地域分布情况进行的洞察。

     

    Step 7 & 8:选择变量 & 选择算法

    因为我要研究的是这些用户与二手交易相关的行为,因此初步选择变量为发帖数量、微软主机拥有台数、索尼主机拥有台数、任天堂主机拥有台数。

    算法上面,我们的目标是将用户分群,因此选择聚类,方法选择最简单的K-means算法。

    Step 9 & 10:设定参数 & 加载算法

    K-means算法除了输入变量以外,还需要设定聚类数,我们先拍脑袋聚个五类吧!

    (别笑,实际操作中很多初始参数都是靠拍脑袋得来的,要通过结果来逐步优化)

    看看结果:

    第一类别的用户数跟总体已经很接近了,完全没有区分度啊!

    Step 7‘ & 8’ & 9‘ & 10’ & 11:选择变量 & 选择算法 &设定参数 & 加载算法 &重构变量

    这一节你看标题都这么长……

    既然我们用原始值来聚类的结果不太好,那么我把原始值重构成若干档次,比如发帖1-10的转换为1,10-50的转换为2,依次类推,再聚一次看看结果。

    哦哦!看上去有那么点意思了!不过有一类的数量还是有一点少,我们聚成四类试试:

    哦哦,完美! 我们运气不错,一次变量重构就输出了一个看上去还可以的模型结果,接下来去测试一下吧。

    Step 12:结果测试

    测试过程中,很重要的一步是要看模型的可解释性,如果可解释性较差,那么打回重做……

    接下来,我们看看每一类的统计数据:

    这个表出来以后,基本上可以对我们聚类结果中的每一类人群进行解读了。结果测试通过!

    Step 13 & 14 & 15:输出规则 & 模型加载 & 报告撰写

    这个模型不用回朔到系统中,因为仅仅是一个我们用来研究的模型而已。因此,输出规则和模型加载两步可以跳过,直接进入报告撰写。

    聚类模型的结果可归结为下图:

    眼熟不?在我的第二篇专栏文章第一份数据报告的诞生 – 一个数据分析师的自我修养  中,我用这张图来说明了洞察结论的重要性,现在你们应该知道这张图是如何得来的了。

    撰写报告的另外一部分,在描述统计-洞察结论的过程中已经提到了,把两部分放在一次,加上背景、研究方法等内容,就是完整的报告啦!

    最后附送几张各类用户发帖内容中的关键词词云图:

    那么,这篇文章就到此结束了,最后的最后,公布一下我做这份报告用到的工具:

    大家可以看到,要当一个数据分析师,要用到很多类别的工具,多学一点总是没有坏处的,在此与大家共勉。

    展开全文
  • 数据管理与据建模案例实践
  • 数据流图和需求求分析建模案例.ppt
  • 数学建模案例分析--插值与拟合方法建模1数据插值方法及应用.pdf
  • 案例非常适合与IoT场景的数据采集,结合MongoDB的Sharding能力,文档数据结构等优点,可以非常好的解决物联网使用场景。 需求 案例背景是来自真实的业务,美国州际公路的流量统计。数据库需要提供的能力: ...

    注:本案例来自MongoDB官方教程PPT,也是一个非常典型的CASE,故此翻译,并结合当前MongoDB版本做了一些内容上的更新。

    本案例非常适合与IoT场景的数据采集,结合MongoDB的Sharding能力,文档数据结构等优点,可以非常好的解决物联网使用场景。

    需求

    案例背景是来自真实的业务,美国州际公路的流量统计。数据库需要提供的能力:

    • 存储事件数据
    • 提供分析查询能力
    • 理想的平衡点:

      • 内存使用
      • 写入性能
      • 读取分析性能
    • 可以部署在常见的硬件平台上

    几种建模方式

    每个事件用一个独立的文档存储

    {
        segId: "I80_mile23",
        speed: 63,
        ts: ISODate("2013-10-16T22:07:38.000-0500")
    }
    • 非常“传统”的设计思路,每个事件都会写入一条同样的信息。多少的信息,就有多少条数据,数据量增长非常快。
    • 数据采集操作全部是Insert语句;

    每分钟的信息用一个独立的文档存储(存储平均值)

    {
        segId: "I80_mile23",
        speed_num: 18,
        speed_sum: 1134,
        ts: ISODate("2013-10-16T22:07:00.000-0500")
    }
    • 对每分钟的平均速度计算非常友好(speed_sum/speed_num);
    • 数据采集操作基本是Update语句;
    • 数据精度降为一分钟;

    每分钟的信息用一个独立的文档存储(秒级记录)

    {
        segId: "I80_mile23",
        speed: {0:63, 1:58, ... , 58:66, 59:64},
        ts: ISODate("2013-10-16T22:07:00.000-0500")
    }
    • 每秒的数据都存储在一个文档中;
    • 数据采集操作基本是Update语句;

    每小时的信息用一个独立的文档存储(秒级记录)

    {
        segId: "I80_mile23",
        speed: {0:63, 1:58, ... , 3598:54, 3599:55},
        ts: ISODate("2013-10-16T22:00:00.000-0500")
    }

    相比上面的方案更进一步,从分钟到小时:

    • 每小时的数据都存储在一个文档中;
    • 数据采集操作基本是Update语句;
    • 更新最后一个时间点(第3599秒),需要3599次迭代(虽然是在同一个文档中)

    进一步优化下:

    {
        segId: "I80_mile23",
        speed: {
            0:  {0:47, ..., 59:45},
            ...,
            59: {0:65, ... , 59:56}
        }
        ts: ISODate("2013-10-16T22:00:00.000-0500")
    }
    • 用了嵌套的手法把秒级别的数据存储在小时数据里;
    • 数据采集操作基本是Update语句;
    • 更新最后一个时间点(第3599秒),需要59+59次迭代;

    嵌套结构正是MongoDB的魅力所在,稍动脑筋把一维拆成二维,大幅度减少了迭代次数;

    每个事件用一个独立的文档存储VS每分钟的信息用一个独立的文档存储

    从写入上看:后者每次修改的数据量要小很多,并且在WiredTiger引擎下,同一个文档的修改一定时间窗口下是可以在内存中合并的;
    从读取上看:查询一个小时的数据,前者需要返回3600个文档,而后者只需要返回60个文档,效率上的差异显而易见;
    从索引上看:同样,因为稳定数量的大幅度减少,索引尺寸也是同比例降低的,并且segId,ts这样的冗余数据也会减少冗余。容量的降低意味着内存命中率的上升,也就是性能的提高;

    每小时的信息用一个独立的文档存储VS每分钟的信息用一个独立的文档存储

    从写入上看:因为WiredTiger是每分钟进行一次刷盘,所以每小时一个文档的方案,在这一个小时内要被反复的load到PageCache中,再刷盘;所以,综合来看后者相对更合理;
    从读取上看:前者的数据信息量较大,正常的业务请求未必需要这么多的数据,有很大一部分是浪费的;
    从索引上看:前者的索引更小,内存利用率更高;

    总结

    那么到底选择哪个方案更合理呢?从理论分析上可以看出,不管是小时存储,还是分钟存储,都是利用了MongoDB的信息聚合的能力。

    • 每小时的信息用一个独立的文档存储:设计上较极端,优势劣势都很明显;
    • 每分钟的信息用一个独立的文档存储:设计上较平衡,不会与业务期望偏差较大;

    落实到现实的业务上,哪种是最优的?最好的解决方案就是根据自己的业务情况进行性能测试,以上的分析只是“理论”基础,给出“实践”的方向,但千万不可以此论断。

    VS InfluxDB

    说到时序存储需求,大家一定还会想到非常厉害的InfluxDB,InfluxDB针对时序数据做了很多特定的优化,但MongoDB采用聚合设计模式同样也可以大幅度较少数据尺寸。根据最新的测试报告,读取性能基本相当,压缩能力上InfluxDB领先MongoDB。但MongoDB的优势在于可以存储更丰富的信息,比如地理坐标,文本描述等等其他属性,业务场景上支持更广泛。

    另外,MongoDB的Sharding水平扩展能力,Aggragation功能,Spark Connector等等特性,对IoT来说,生态优势明显。

    原文地址:https://yq.aliyun.com/articles/66477?spm=5176.100239.blogcont73664.27.h8eZaz

    展开全文
  • 一个r语言数据分析案例(里面有代码和论文报告),包括对数据的绘图、线性回归和非线性回归,模型的拟合优度,模型的数据预测等等。
  • 2.2.2 数据流图 数据流图Data Flow DiagramDFD是描述系统中数据流程的图形工具它标识了一个系统的逻辑输入和逻辑输出以及把逻辑输入转换为逻辑输出所需的加工处理 数据存储 数据源点 或终点 加 工 加工名 数据流 ...
  • 摘要: MongoDB数据建模案例:朋友圈评论内容管理 需求 社交类的APP需求,一般都会引入“朋友圈”功能,这个产品特性有一个非常重要的功能就是评论体系。 先整理下需求: 这个APP希望点赞和评论...
  • 资源名称:数据、模型与决策:运用电子表格建模案例资源截图: 资源太大,传百度网盘了,链接在附件中,有需要的同学自取。
  • 数据仓库建模

    2018-04-08 22:01:21
    1 什么是数据模型 2 为什么需要数据仓库模型 3 如何建设数据仓库模型 3.1 数据仓库数据模型架构 3.2 数据仓库建模阶段划分 3.4 数据仓库建模方法 4 数据仓库建模案例 4.1 零售行业案例分析
  • 数据仓库建设---建模案例【转】

    千次阅读 2015-06-26 11:26:49
    所以,这里举一个例子说明数据仓库建模的大概规程。 一、背景介绍  熟悉社保行业的人员知道,目前我们国家的社保主要分为养老、失业、工伤、生育、医疗保险和劳动力市场这6大块主要业务领域。在这6大业务领域中,...
  • 8 HBase数据分析与建模,实战案例剖析
  • 数学建模案例分析-Matlab实现 20个案例
  • 数据分析精华案例-员工流失建模与预测实例
  • 在这篇文章中,你将会学到如何一步步地进行维度数据建模,你将看到如何在真实的场景中使用维度模型。   什么是维度数据建模 维度数据建模是在进行数仓设计时的一种数据建模方法。这种建模方法的主要目标是为了...
  • 数据建模应用

    千次阅读 2019-09-05 09:43:29
    数据建模应用一、数据建模种类1、关系建模(3NF)2、维度建模 一、数据建模种类 1、关系建模(3NF) 定义:根据实体之间的关系(E-R)梳理和组织我们的数据,这里的实体可以是我们数据库中具体的一张表。通过满足3NF...
  • 案例一,公交车调度方案的优化模型;案例二,彩票发行方案的最优决策;案例三,露天矿生产车辆安排方案的优化模型;案例四,SARS传播状态预测的优化模型;案例五,抢渡长江问题的竞渡策略探讨;案例六,电站建设供电...
  • 《仓库管理系统》:仓库管理员对本单位所需要的物品进行编码。日常工作主要有物品登记入库,物品出库;不定期进行仓库盘点,盘点结果报仓库主管审批后进行盘盈调整或盘亏调整。仓库主管对各物品定期分别计算安全存量...
  • 概述 数据仓库包含的内容很多,它可以包括架构、建模和方法论。对应到具体工作中的话,它可以包含下面的这些内容: 以Hadoop、Spark、Hive等组建为中心的数据架构体系。...因此,下面的将详细地阐述数据建模...
  • 本书共15章,分两个部分:基础篇、实战篇。基础篇介绍了数据挖掘的基本原理,实战篇...读者在阅读过程中,应充分利用随书配套的案例建模数据,借助相关的数据挖掘建模工具,通过上机实验,以快速理解相关知识与理论。
  • UML建模案例分析;1 网络教学系统的需求分析 2 系统的UML基本模型 3 系统中的类 4 系统的配置与实现 ; ;数据信息管理模块包含的功能 教师信息管理 课程简介信息管理 文件上传信息的管理; ;基本业务模块包含的功能 ...
  • 使用sparkR和sparklyr进行大数据建模案例文档,其中包括了对飞机航班、出租车等数据的建模分析与可视化,具有非常好的参考意义。数据和源码可以通过文档中的链接很方便的下载。
  • 大数据建模应用案例

    2021-02-23 22:57:34
    客户能够方便的采用数据测量与数据分析的方式建立虚拟车辆及ECU仿真模型,并基于该模型开展模型在环(MIL)仿真测试,软件代码在环(SiL)仿真测试以及硬件在环(HiL)测试以及车辆故障模拟与诊断等验证与测试工作,以...
  • 数学建模 matlab 数据建模基础

    千次阅读 多人点赞 2020-05-30 21:47:56
    一、数据的获取 1.从Excel中读取数据 (1)xlsread函数 :从EXCEL读入数据到MATLAB中。 例如: a = xlsread(‘D:\adc.xlsx’,1,‘A1:D2’) 其中,‘D:\abc.xlsx’表示读入的EXCEL数据所在的路径以及EXCEL的文件名称...
  • 浅谈数据分析和数据建模

    千次阅读 2018-03-20 07:33:42
    浅谈数据分析和数据建模大数据应用有几个方面,一个是效率提升,帮助企业提升数据处理效率,降低数据存储成本。另外一个是对业务作出指导,例如精准营销,反欺诈,风险管理以及业务提升。过去企业都是通过线下渠道...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 42,358
精华内容 16,943
关键字:

数据建模案例