数仓介绍

刘超 5天前 ⋅ 3962 阅读   编辑

目录

  1、数仓痛点

  2、数仓模型

    a、实施时层次划分

    b、调用原则

  3、数仓规范

  4、外围系统建设

  5、发展防线展望

一、概述

  数仓大体分三个阶段

  第一阶段:使用大量成熟的开源框架,主要以离线批处理为主,外围系统自研能力较弱,数据量和集群资源比较少

  第二阶段:使用开源+自研方式,有自己的方法论和建模体系,有比较完善的元数据管理、数据质量监控,能有效支持实时需求

  第三阶段:有自研的通用的一站式大数据处理平台、有完善的数仓理论基础和外围工具,有完善的数据共享机制和权限管理

 

  发展趋势:工具越来越智能,平台越来越完善。实时和离线一体化,技术不再是障碍。数据膨胀速度比以往任何时候都快,吞噬了大量的计算资源

二、数仓痛点

 

  由于口径不一致,导致两份报表结果不一样,那这两份报表都是不可信的;烟囱式开发,可能没有维度建模的概念,开发就是case by case的做,例如做一个报表,单启一个脚本、调度,另一个人又有需求,再启一个脚本,彼此之间没有交集的或者比较少的,因为没有抽象出公共层出来,所以一般数仓会有数据治理这一概念;业务发展比较快,数据膨胀快,早先使用的脚本可能不是最优化的,可能会导致执行时间越来越长;早上发现了一个问题,排查这个问题时间可能很长,因为业务复杂度越来越高,上游可能有几十个依赖任务,这就导致我们早上第一件时间先看看有没有任务报错;当要保证数据安全时,就没法很好的保证数据共享,如果要保证100%数据共享,又会有数据安全的担忧,所以需要有一个制度或者流程来保证去取得一个相对平衡的状态(例如我们可以为表、字段会指定保密等级,不同保密等级对应不权限);当你试图解决如上问题时,还是会发现需求永远是做不完的,不管加班到几点,可能还是会有其他部门来投诉数据部门。

三、数仓模型

  1、实施时层次划分

  别人问我们数仓是什么样的,我们一般会说分为多少多少层,其实我们说的多少层指的是在具体实施时的具体层次划分,实际在整个业界,数仓分层就三层,接入层(ods)、中间层、应用层(app),针对这三层架构,下面给一个具体实施时层次的划分,如下

 

 说明

  1)ODS/SRC层:是从各数据库(mysql、oracle、mongodb等)和日志文件抽过来的数据,表结构不变,存储格式也多样,可能是text,也可能是orc,还可能是rar等压缩文件,之所以存储格式多样是因为各路数据流入,我们很难控制流入数据的格式,其次也有etl工具限制(例如将日志文件处理成orc);这里我们不会做过多的数据处理(例如数据校验、过滤),根据自身情况选择数据保留天数(这里保留30天),之所以不做过多数据处理是因为当业务逻辑发生变化时,可能需要重算,保留一定时间的数据方便我们回溯,不至于数据缺失、数据异常等。
  2)DW层:可以将DW再细分一下,分为DWD、DWS,也可以放到一起
    a、DWD:所有表均为拉链表形式(具体见缓慢变化维 Type2代理键),保留所有历史数据;表名均以dwd_product_XXX(dwd代表所处分层+product代表产品主题+表名)命名;对ODS数据做清洗、转换以及维度补充等
      - 维度补充:比如表中没有名称字段,但有id字段,会在这层根据id填充名字字段;
      - 转换:包含一些格式转换,比如时间格式统一(yyyymmddHHSSMM)、固话加区号(0635-6831931)、银行卡去-(如9558-8217-1200-0180-500转换为:9558821712000180500)等操作
           也包含一些结构化处理,比如hive用于存结构化数据,非结构化数据(比如mongodb数据)同步到hive时,需要做一些行转列、列转行、json数据平铺等操作
      - 清洗:主要做一些过滤等操作,比如广告数据,可能存在一些刷单的数据,这时就需要去掉,后续我们使用统一维度表,不管怎么统计,结果都是一样的
      - 标准化:字段,表名标准化等
      - 整合:比如不同来源的同类型数据水平整合等
    b、DWS:表名均以dws_product_XXX(dws代表所处分层+product代表产品主题+表名)命名;预处理DWD数据,避免重复计算,缩减计算时间;其有以下特点:
      - 汇总的数据主要涉及单业务场景,我们的业务是不停发展的,一个业务可能由一个点发展成多个点,所以这里汇总最细粒度的数据
      - 数据是最细粒度的,但其已经具备简单的指标信息,进一步数据组装即可用于集市、应用等层;对于可重聚合指标,直接group by就可以了,这样能节省大量资源
      - 前面提到怎么减少烟筒式的开发,如果有公共汇总层,公共指标就能复用,这样就能减少一些指标重复计算,从源头规避指标不一致与资源消耗这种情况。
  3)DWM(DM)层:所有表都是宽表(也可以叫宽表集市,我们的业务不停发展,集市中会不停扩充字段,这时如果只要一个主题数据,只需去这个集市去取就可以了,如果是跨主题的,那就需要去不同集市去取了,对应用来说,它所需要关注的表,就非常少了,不需要关心单业务场景,只需要关心特定的主题数据即可;这里也有些行为数据的组装,和DW类似,表名均以dm_product_XXX(分层名+主题名+标识表信息的详细表名)命名
  4)DIM层:存储全局维度表,从长远来看,全局应该指的是公司级别的,毕竟如果维度不统一,那数据是不能互通的,但也有可能因为一些原因只能做到部门级别的,后续怎么弄看上级决策吧;维度包含组织架构、用户信息、位置信息等;表名均以dim_开头;
  5)APP层:主要做一些基于应用的数据组装以及对外展示的数据,包含saiku等OLAP分析数据、BI指标数据,表名均以app_+主题名
  6)TMP层:一些临时需求表所存的库
  
  2、调用原则
  ODS数据向上流,到DWD,DWD数据进一步可以到DWS或者DWM,DWD数据也可以被APP引用,DWS、DWM数据也可以被APP引用,在这里我们聊到了调用原则,首先不违反逻辑上的分层(逻辑上分层:应用层、中间层、接入层,具体见“实施时层次划分”),禁止逆向调用,就是说我们整体调度流程是从下往上的架构,不允许DWD访问DWS中的数据,如果架构(血缘)出现这种情况,就需要看看设计是否有问题;避免同层调用,比如DWS访问DWS中数据,同层调用最有可能会出现在DWS、DWM中了;对于APP层优先使用公共层中的数据(DWS、DWM),如果DWS、DWM中数据无法直接使用,可以从DWD中取,因为我们不可能提前预知所有的维度或者在实现不可重聚合指标时,这不违反数仓整体架构(应用层可以访问中间层,但不能访问接入层),但是还是建议优先使用公共层中的数据;避免跨层调用,这个跨层调用主要指APP不要直接访问ODS中的数据,APP可以直接访问DWD,也可以直接访问DWS,只要不违反逻辑上的分层(APP之所以可以访问DWD、DWS、DWM,不能访问ODS,是因为APP是应用层,DWD、DWS、DWM都属于中间层,ODS属于接入层,应用层可以访问中间层,但不能访问接入层)即可
 
四、数仓规范
  1、表命名规范
  表命名一般会包含以下部分,主要考虑就是见名知意,就是当我看到这个表名时,根据你我之间约定,能够猜出来,这份数据是属于哪个业务线、哪个数据域、它大概是讲什么、它时间周期是什么、它是怎么存的,如果一个表能够满足这些标准,表的命名是比较规范的
 
  2、字段命名规范
  3、需求对接规范
  4、数据开发规范
  

注意:本文归作者所有,未经作者允许,不得转载

全部评论: 0

    我有话说: