漫谈纬度表如何设计(二)

作者: 愤怒的谜团 | 来源:发表于2019-08-27 18:01 被阅读0次

    一:纬度设计时遇到的复杂背景

    数据仓库的重要数据来源是大量的、分散的面向应用的操作型环境。不同的应用在设计过程中,可以自由决策,主要满足本应用的需求, 很少会考虑和其他系统进行数据集成。应用之间的差异具体表现在如下几个方面:
    •应用在编码、命名习惯、度量单位等方面会存在很大的差异。比如不同应用对于用户的性别编码不同,有o和1、F和M等;不同应用的用户ID含义相同,但字段名称不同,有user、user_id 等,不同应用对于金额的度量单位不同,有元、分等。
    •应用出于性能和扩展性的考虑,或者随技术架构的演变,以及业务的发展,采用不同的物理实现。拆分至不同类型数据库中,部分数据釆用关系型数据库存储(如Oracle、MySQL等),部分数据采用NoSQL数据库存储(如HBase、Tair等)。拆分成同一类型数据库中的多个物理表,比如对于淘宝商品,有商品主表和商品扩展表,商品主表存储商品基本信息,商品扩展表存储商品特殊信息,如不同产品线的定制化信息等;对于淘宝会员,有会员主表和会员扩展表,会员主表存储用户基本信息,会员扩展表存储用户扩展信息,如用户的各种标签信息等。
    -- 引用《大数据之路》

    二:纬度表如何进行整合

    面对如何复杂的业务,复杂的数据来源,如何设计出统一,规范,高效,质量的纬度表是一个难点,一般需要遵循以下规范:

    • 命名规范统一
      表名和字段名的命名应该要统一,一般情况下表的命名需要看到是什么纬度表,是主表还是从表,字段的命名应该要见名知意,描述相同业务含义的字段在不同表,不允许命名不同。
    • 字段类型要统一
      实践发现,如果字段类型不统一,后续对数据进行加工,导入导出就会产生不必要的麻烦,更加致命的可能会造成精度丢失。
    • 公共代码及代码值统一
      公共代码及标志性字段的数据类型、 命名方式等统一。
    • 业务含义相似的表统一
      如果两个纬度表描述的业务场景比较类似,但是也有差异的部分,这种情况下,一般有如下处理方式:
      1.主从表设计
      将共有的公共核心属性进行下沉,抽象出主纬度表,每个纬度表差异的部分抽象成从纬度表。这样做的好处是,保证了主表的稳定,不会因从表的变更影响到主表,并且更加有利于扩展,遵循了类似于软件设计的思想,高内聚,低耦合。但是缺点是使用起来会有不便,可能会多join一张表。
      2.直接合并
      另外一种就是直接合并,这个方式的好处是将多个描述相似业务场景的纬度表进行垂直整合,使得这张表的纬度属性很丰富,符合我们纬度表设计的原则,并且查询起来也很方便。但是也会出现一个问题,就是这张表会存在很有空值,表很稀疏。
      3.不合并
      如果两张纬度表描述的业务场景差异较大,那么可以选择不合并,分开维护也是可以的,这样可以凸显出每张纬度表的核心注意,不易混淆。
    • 表级别的整合问题
      在上述业务含义相似的表统一里面也提到表的整合,这里来详细讨论一下表级别的整合问题。
      1.垂直整合
      如果不同的来源表有相似的业务含义,只是存储的数据集不一样,比如会员基础信息表,会员扩展信息表,其实都是存的会员信息,只是字段表述不一样,那么这样的话就可以垂直整合到一张会员表里面去,这样就可以使纬度属性尽可能的丰富起来。
      2.水平整合
      如果不同的来源表,表结构都类似,而且描述的也是相似业务场景下的环境,那么可以进行水平整合,比如说淘宝会员,1688会员等。由于是水平整合,需要考虑到唯一主键的问题。如果整合完以后不同子集各自的主键不冲突,那么可以不用做处理,如果存在冲突就需要设置超自然键,保证唯一性。
      有合并就会有拆分,思路是一样的,只不过拆分是逆思维,这里就不做详述了。不管是整合还是拆分一般要遵循一下几点:
      扩展性:当源系统、业务逻辑变化时,能通过较少的成本快速扩展模型,保持核心模型的相对稳定性。软件工程中的高内聚、低耦合的思想是重要的指导方针之一。
      效能:在性能和成本方面取得平衡。通过牺牲一定的存储成本, 达到性能和逻辑的优化。
      易用性:模型可理解性高、访问复杂度低。用户能够方便地从模型中找到对应的数据表,并能够方便地查询和分析。

    三:历史归档问题

    随着业务的发展和时间的推移,纬度表当中的纬度属性也会发生变化(针对这种变化的具体处理非本文重点),假设纬度表处理部分纬度属性变化是采用增量插入的方式,那么数据量就会增长的很快,并且不是最新的数据是没有实际业务意义的,针对这种情况,我们为了有效数据的查询时效,应该要做好历史归档的问题。
    一般目前归档数据的方式有如下几种:
    1.根据业务系统那边的归档策略来,比如说业务系统那边以怎样的策略让这个商品处于失效状态,那么在数据仓库也是采用同样的策略,但是业务系统那边发生更新,数据仓库也会跟着变化。
    2.对接binlog,解析数据,如果有解析到类似于delete,同业务系统那边失效的标志字段,那么就做归档操作。
    3:数据仓库这边自定义归档策略,根据业务特点,自定义一套归档策略,单独维护。

    相关文章

      网友评论

        本文标题:漫谈纬度表如何设计(二)

        本文链接:https://www.haomeiwen.com/subject/ubgeectx.html