数据仓库全流程

数仓建设的思路流程：

1 梳理业务流程

2 梳理数据流

3 数据类型、存储介质、样例数据

4 需求-功能性需求、非功能性需求(性能、时效性)

 

-------------------------------------数据来源

rdbms

log

nginx

https     third api    mongoDB    ：第三方数据http请求，访问第三方API， 第三方数据可能存储在mongoDB中

 

 

----------------------------------------数据采集方案

mysql

1,表的数据量、每日增量、updated_ time \created time, 自增的id,源表的索引情况

--split-by id

--split-by updated time

select min(id) , max(id) from tab where ...

2,数据采集方案

增量(流水、updated)、全量

user:全量采集

申请授信:增量采集

额度:全量采集

借款、还款计算:增量采集

 

-------------------------------------------数据仓库模型设计

1.维度建模

 

===============================================================================

 

 

一、为什么构建数据仓库？
业务系统和分析系统分离（不可能在业务系统去分析吧！）
数据源来自多个系统，跨系统整合分析很难
为企业决策做依据

-------

数据仓库的定义：
    1、面向主题的
    2、集成的（数据来源多方）
            消除不一致的现象 
            需要考虑的问题： 数据格式 计量单位 数据代码含义混乱 数据名称混乱
    3、非易失的（指的是数据一旦进入数据仓库，数据就不应该再有改变，数据基本是静态的；也有变化的，看业务，如scd）
    4、随变的（反映历史变化的数据集合）
           电商交易频繁的可能是2年。金融一般客户类、账户类等 信息要保留7年，交易类流水类信息要保留至少13个月以上，保险行业交易比较少的5年；
           太老的数据对于数据 分析没多大作用，你想10年前的电商交易数据对于现在的电商能有多大帮助，价格、产品、用户都已经完全不同了
     
            保留历史数据时长2年：
            basic（tmp）：（七天）
            ods（30天，每天都会备份到其它）
            dw（1年，每天都会备份到其它）

--------

数据库与数据仓库的区别：
    数据库是面向事务的设计，数据仓库是面向主题设计。 
    数据库设计是尽量避免冗余，一般采用符合范式的规则来设计，数据仓库在设计是有 意引入冗余，采用反范式的方式来设计。 
    数据库是为捕获和存储数据而设计，数据仓库是为分析数据而设计

二、数仓的建设流程
数仓构建：确认主题，确认粒度，确认维度事实

建模产品业务部门做的，已经界定好；从中我们得出主题都包含哪些！

------

1）业务建模  ：（确定系统规范、建设目标，时间节点），架构选型，主题，泛泛的表关系 
      如.操作出现的频率，即业务部门每隔多长时间做一次查询分析。 
        ∙在系统中需要保存多久的数据，是一年、两年还是五年、十年。 
        ∙用户查询数据的主要方式，如在时间维度上是按照自然年(12月31结束)，还是财政年(顺延12个月)。 
        ∙用户所能接受的响应时间是多长、是几秒钟，还是几小时。
2）领域建模（概念建模） ： 抽取关键业务概念，并将之抽象化，E-R图（实体关系属性）
   概念建模建模步骤 
       局部模型 ① 确定局部概念模型的范围； ② 定义实体； ③ 定义联系； ④ 确定属性； ⑤ 逐一画出所有的局部ER图，并附以相应的说明文件。 
       全局模型 建立全局E‐R图的步骤如下： ① 确定公共实体类型； ② 合并局部E‐R图； ③ 消除不一致因素； ④ 优化全局E‐R图； ⑤ 画出全局E‐R图，并附以相应的说明文件。 
       模型评审 概念模型的评审分两部分进行： 第一部分是用户评审。 第二部分是开发人员评审。
3）逻辑建模 ： 业务概念实体化，并考虑其具体的属性，形成表与表关系模型（为什么这么设计这些度量值，形成这样的宽表，根据粒度、维度一致性，整合到一张宽表中），按照最小粒度去划分，如按天；
4）物理建模 ：对逻辑建模的具体实现（逻辑建模中的东西可能没有）， 表模型的实现
                （1）删除非战略性数据：数据仓库模型中不需要包含逻辑数据模型中的全部数据项，某些用于操作处理的数据项 要删除。 
                （2）增加时间主键：数据仓库中的数据一定是时间的快照，因此必须增加时间主键。 
                （3）增加派生数据：对于用户经常需要分析的数据，或者为了提高性能，可以增加派生数据。 
                （4）加入不同级别粒度的汇总数据：数据粒度代表数据细化程度，粒度越大，数据的汇总程度越高。
                     粒度是数据 仓库设计的一个重要因素，它直接影响到驻留在数据仓库中的数据量和可以执行的查询类型。
                     显然，粒度级别越 低，则支持的查询越多；反之，能支持的查询就有限。

----------

数据模型

    数据存储方式：
    1）虚拟存储方式 （如，视图）
    2）基于关系表的存储方式

    星型模型（性能高，一个事实表围绕一层维度，常用）、
    雪花模型（灵活性能低，一个事实表围绕多层维度）、
    星座模型（多个事实表决定）

    Data Vault模型 ： 一种综合了第三范式（3NF）和星型模型

                    中心表、链接表(事实表)、附属表（维度表）、PIT表（Point—In—Time表是由附属表派生而来的，多层次维度表）

  
    表的分类（一般事实表、维度表），更细分：
    实体表，一般是指一个现实存在的业务对象，比如用户，商品，商家，销售员等等       --- 商品表、用户表
    维度表，一般是指对应一些业务状态，编号的解释表。也可以称之为码表。            ----- 商品一二三级分类
              ---- 比如地区表，订单状态，支付方式，审批状态，商品分类等等
    事务型事实表，一般指随着业务发生不断产生的数据。特点是一旦发生不会再变化。       ------ 支付流水表、订单详情表
              ----一般比如，交易流水，操作日志，出库入库记录等等。                 
    周期型事实表，一般指随着业务发生不断产生的数据。                              -----  订单表
              ----比如订单，其中订单状态会周期性变化。再比如，请假、贷款申请，随着批复状态在周期性变化。

   拉链表：维护历史状态，以及最新状态数据的一种表（scd：缓慢变化维场景，数据变化不是很大，翻旧账场景

   流水表，用于统计业务相关情况(如，交易流水。。。)，拉链表用于统计账户及客户的情况

周期快照表          周期快照事实表的粒度是每个时间段一条记录，通常比事务事实表的粒度要粗，是在事务事实表之上建立的聚                             集表。周d期快照是在一个给定的时间对事实表进行一段时期的总计。例如，一个月销售订单周期快照是每个月                               底 时总的销 售订单金额。

 累计快照表    累计快照适用于较短周期，有着明确的开始和结束状态的过程，如一个订单执行的过程，并记录过程中每个步                             骤的 执行时间，使分析人员对执行的过程有整体的把握。

                          新增的数据与数仓中的历史数据 进行合并，得到最新的历史数据，然后覆盖数仓中原有的数据！

 

    实体表、事实表、维度表三者区别：
    实体表：实体表就是一个实际对象的表，实体表它放的数据一定是一条条客观存在的事物数据，比如说设备
    事实表（中心表）：事实表其实质就是通过各种维度和一些指标值得组合来确定一个事实的，比如通过时间维度，地域组织维度，指标值可以去确定在某时某地的一些指标值怎么样的事实。事实表的每一条数据都是几条维度表的数据和指标值交汇而得到的。
    维度表（附属表）：维度表可以看成是用户用来分析一个事实的窗口，它里面的数据应该是对事实的各个方面描述，比如时间维度表，它里面的数据就是一些日，周，月，季，年，日期等数据，维度表只能是事实表的一个分析角度。

缓慢变化维(变化不是很频繁)：拉链表实现 （在原有基础上增加一行）
周期型事实表(频繁变化，要管理它的生命周期) ： 累积快照表实现 （放到一张表的同一行中）

 

---------
数据仓库数据模型优化
     经常对其性能进行监控，并随着需求和数据量的变更进行调整。 
     优化数据仓库设计的主要方法是： 合并不同的数据表。 
                                    通过增加汇总表避免数据的动态汇总。 
                                    通过冗余字段减少表连接的数量，不要超过3~5个。 
                                    用ID代码而不是描述信息作为键值。 
                                    对数据表做分区。
                                    
                                    
                                    
                                    
三、数据装载（etl）

1、建立逻辑映射（规划阶段、元数据管理）

逻辑数据映射是指源系统中表和数据仓库中的表的对应关系，一般使用excel进行记录

逻辑映射文件归纳为元数据，源数据结构（如，数据库信息），目标结构（数据仓库中的表），数据转换规则，映射关系，数据的上下文等，
逻辑数据映射中还应该标识出一些需要引起重视的操作，比如隐式转换引起长度变化时，可能会丢失数据，比如utf8转换为Latin1时，字符集的变化会引起字节数量的增减，因此要在文档中标识出来，提醒开发人员注意

2、数据抽取 

从源数据导入到数据仓库或者贴源层有两种方式：
push：一般需要增加业务系统的功能，一般不采取（业务系统编写个定时器功能，把发生变化的数据拉取到另外一张表，然后再全量导入这张表的数据）

pull：
    全量 （数据量少）

    增量（四种实现方式，cdc）： （数据量大）
        CDC大体分为两种侵入式和非侵入式。侵入式是指CDC操作会给源系统带来性能影响
        1）基于时间戳的CDC
                  时间戳：要求源数据里有插入时间和更新时间列，取新增数据根据插入时间，取修改数据根据更新时间
                  自增列：根据自增列取新增数据
                  
                  缺点,不能记录删除操作；无法识别过多次更新,只能拿到最后一次的；具有侵入性
                  
        2）基于触发器的CDC
                a）当执行insert,update,delete这些SQL语句是,可以使用数据库的触发器来执行一些动作,比如触发器将变更的数据保存到临时表中,然后从临时表中抽取数据到贴源层,大多数情况下,触发器会降低业务系统的性能,因此这种方式使用的不多.
                
                b）作为替代方案,可以使用源数据库的复制功能,复制一份数据到备库上,在备库上建立触发器,是个很有效的方法,而且没有侵入性.
                   这个方式需要额外的存储空间,看起来是冗余数据,实际上对业务库来讲,实现主库上进行写操作,备库上进行读操作,实现读写分离,是提高性能和高可用一个手段.

        3）基于快照的CDC
              如果没有时间戳也不允许使用触发器,就要使用快照表了，通过比较原表和快照表来获得变化数据。
              所谓快照就是一次性抽取源数据中的全部数据，把这些数据加载到ODS层，下次需要同步的时候，再从源数据抽取全部的数据，并把这些数据放到ODS层，比较这两个版本的数据，找出变化数据。
        
              缺点：浪费存储空间
              
        4）基于日志的CDC
             最复杂和最没有入侵的CDC方式就是基于日志的方式。数据库会把每个插入、更新和删除操作记录在日志里。
             只要在数据库中开启事务日志，再将日志读取出来，就可以还原这部分变化数据了。 可以考虑用canal监听mysql的 binlog，实时接入即可
             缺陷，即只能用来处理一种特定的数据库。

实现的方式：
     1）使用sqoop抽取数据（append和lastmodified）
        Sqop中提供了 hive-overwrite参数实现覆盖导入。
        hive-overwrite的另一个作用是提供了一个幂等操作的选择。
               所谓幂等操作指的是其执行任意多次所产生的影响均与次执行的影响相同。
               这样就能在导入失败或修复bug后可以再次执行该操作,而不用担心重复执行会对系统造成数据混乱。
     2）导出为文本方式
        hdfs命令或者使用hive的load data local inpath

数据同步策略的类型包括：全量表、增量表、新增及变化表、拉链表（处理SCD）
全量表：存储完整的数据。
增量表：存储新增加的数据。
新增及变化表：存储新增加的数据和变化的数据。
拉链表：对新增及变化表做定期合并。

实体表数据量比较小，每日全量               --- 商品表、用户表
维度表数据量比较小，每日全量（没变化的客观世界的维度（比如性别，地区，民族，政治成分，鞋子尺码）可以只存一份固定值，用增量导入）      ----- 商品一二三级分类
事务型事实表同步策略：数据不会变化，而且数据量巨大，所以每天只同步新增数据即可，所以可以做成每日增量表，即每日创建一个分区存储。          ---------支付流水表、订单详情表
周期型事实表同步策略： 利用每日新增和变化表，制作一张拉链表（对新增及变化表做定期合并）         -----  订单表
       ---存每日全量的话，数据量太大，冗余也太大。如果用每日增量的话无法反应数据变化。

kettle示范根据时间的增量导入：
    实现增量导出步骤：
        1、times里的原始记录（t0, t0）,获取当前时间，记录到中间表（t0, now()）
        2、获取users数据，指定获取条件
        3、数据同步完毕后，更新times表（now(), now()）
        4、重复以上步骤，now时间需要不断更新

sqoop先导入到hdfs中（mr清洗再到ods。。。）：
     关系型数据库，表的字段不一致、数据需要清洗

sqoop直接导入到hive中：
     字段类型一致，如时间维度表

-----------------------------------------

3、转换

数据转换是将数据进行重构以及标准化，消除数据的不一致，处理缺失数据，转换最主要的任务就是数据清洗。
数据清洗：按照一定的规则处理脏数据的过程。(目的在于删除重复信息，纠正存在的错误，并提供数据一致性)

数据清洗流程通常包括如下内容:
    a）预处理: 对于大的数据文件的加载，特别是新的文件，要进行预先诊断和尖刺，不能贸然加载
    b)标准化处理: 根据标准化对照表，将不一致的数据进行统一(如，json数据，提取出一个个字段值)
    c)去重处理： 对于是否过滤，是否修正一般要求业务方确认
          一种是整行数据完全重复（使用distinct或者group by 进行处理） 
          一种是有重复的字段，这种一般需要子查询来进行处理
    d)错误值：错误值产生的原因是业务系统不够健全，在接收输入后没有进行判断直接写入后台数据库造成的，比如数值数据输成全角数字字符、字符串数据后面有一个回车操作、日期格式不正确、日期越界等。
            对于类似于全角字符、数据前后有不可见字符的问题，通过转换进行处理
            对于值的格式不正确或者越界或者一些主外键对应不上数据，需要将这些数据写入日志文件中，跟业务方确定这些数据的处理方式，是丢弃，还是修正，还是标准化等。
    e)缺失值：
          确定缺失值范围：对每个字段都计算其缺失值比例，然后按照缺失比例和字段重要性，分别制定策略   

           
          去除不需要的字段：这一步很简单，直接删掉即可，但强烈建议清洗每做一步都备份一下，或者在小规模数据上试验成功再处理全量数据，不然删错了会追悔莫及(多说一句，写SQL的时候delete一定要配where!)
          填充缺失内容：某些缺失值可以进行填充，方法有以下三种：
                    以业务知识或经验推测填充缺失值(如,性别)
                    以同一指标的计算结果(均值、中位数、众数等)填充缺失值
                    以不同指标的计算结果填充缺失值，例子：年龄字段缺失，但是有身份证号，可以通过截取身份证号来获取年龄
           重新取数：如果某些指标非常重要又缺失率高，那就需要和取数人员或业务人员了解，是否有其他渠道可以取到相关数据
    f)格式内容清洗：如果数据是由系统日志而来，那么通常在格式和内容方面，会与元数据的描述一致。
                   如果数据是由人工收集或用户填写而来，则有很大可能性在格式和内容上存在一些问题，
                   比如同一个值，有空格和没空格统计出来结果就不正确了、统计值不全(数字里掺个字母当然求和时结果有问题)、模型输出失败或效果不好(数据对错列了，把日期和年龄混了等)
                   格式内容问题有以下几类：
                        1、时间、日期、数值、全半角等显示格式不一致
                              这种问题通常与输入端有关，在整合多来源数据时也有可能遇到，将其处理成一致的某种格式即可。
                        2、内容中有不该存在的字符
                             某些内容可能只包括一部分字符，比如身份证号是数字+字母，中国人姓名是汉字(赵C这种情况还是少数)。
                             最典型的就是头、尾、中间的空格，也可能出现姓名中存在数字符号、身份证号中出现汉字等问题。这种情况下，需要以半自动校验半人工方式来找出可能存在的问题，并去除不需要的字符。
                        3、内容与该字段应有内容不符
                            姓名写了性别，身份证号写了手机号等等，均属这种问题。 但该问题特殊性在于：并不能简单的以删除来处理，因为成因有可能是人工填写错误，也有可能是前端没有校验，还有可能是导入数据时部分或全部存在列没有对齐的问题，因此要详细识别问题类型。
    g)逻辑错误清洗
      比如年龄超过200岁，日期越界，这种的就要么删掉，要么按缺失值处理。
    h)修正矛盾内容        
      有些字段是可以互相验证的，比如身份证号和年龄，当年龄跟身份证号上的出生日期不匹配的时候，
      在这种时候，需要根据字段的数据来源，来判定哪个字段提供的信息更为可靠，去除或重构不可靠的字段        
    i)非需求数据清洗
      如果数据量没有大到不删字段就没办法处理的程度，那么能不删的字段尽量不删，另外必须要删的时候，一定要做好数据的备份
    j)关联性验证
      如果你的数据有多个来源，那么有必要进行关联性验证。发现这种不一致，需要跟业务方确认，如何需要调整或去除数据。
 

------------------------------------
  
4、Load 数据装载

1）预装载：不从源数据中获取（时间维度，数仓生命周期）

2）初始装载：没有数据，第一次加载
    确定加载过程中需要做的处理过程，进行实现，装载完成要验证数据的正确性！
    如，需要生成sk键
         sk的生成方式有两种，使用row_number()函数，或者创建hive的用户自定义函数，

3）定期装载：全量、增量覆盖之前的数据

-------------------------------

5、ETL自动化

把每天需要跑的任务编写完了，这个任务需要每天定时去执行，一般来讲需要制定一个任务计划表，来记录所有的任务的执行周期，执行时间，负责人，联系方式等信息，
关于调度的执行周期，一般选在业务量的低峰，上线也是一样，在业务量最低的时候去进行操作，这个时候如果出现问题，进行回滚，业务影响不大，所以一般选择在凌晨2-4点之间，
                                    
                                    
----------------------

四、数仓分层
ods--->dwd--->dws---->dm

源数据->ods->dw : ETL
dw开始数据分析：BI

ods/sda  与源数据基本保持一致（log数据、埋点数据、第三方数据）
dwd/dwi 细粒度拆分数据（如，log：公共字段、事件名称、事件数据、服务器时间），一条条的详细的数据
dws/dwa 粗粒度聚合（按日月聚合，如，每日新增设备）
dm/ads/app 指标分析层，基于上述各层进行指标的聚合分析（如留存率）

dim 维度层 ： 将这些维度表放到单独的一个库中，形成维度库，即可看成是维度层，意在让数仓数据清晰明了

 

阿里数据体系中，数据仓库分为三层：

ODS、CDM（数据公共层,包含DIM、DWD、DWS）、ADS

DIM：建立一致数据分析维表，在划分数据域、构建总线矩阵时，需要结合对业务过程的分析定义维度。

DWD：明细层

DWS：公共汇总层

 

---------------------
五、数仓管理：

1）数据库管理
      安全管理：权限管理
      数据仓库的备份和恢复
      数据老化：设计数据仓库中数据的存放时间周期和对过期数据的老化方法，如历史数据只保存汇总数据，当年数据保存详细记录
      
2）元数据管理：
      元数据管理贯穿于整个系统的建设过程中，元数据是描述数据的数据
      元数据不但是独立存放，而且对用户是透明的，标准元数据之间可以互相转换

    元数据：
         1）技术元数据：表怎么创建的，字 段类型、外部表还是内部表、分区表。。。
         2）业务元数据：表与表之间的转换依赖关系，业务规则
         3）管理元数据 ： 表有哪些人管理维护；谁拥有该表的权限，
         
             源数据的描述定义：类型、位置、结构。 
                 ∙数据转换规则：编码规则、行业标准。 
                 ∙目标数据仓库的模型描述：星型/雪花模型定义，维/事实结构定义。 
                 ∙源数据到目标数据仓库的映射关系：函数/表达式定义。 
                 ∙代码：生成转换程序、自动加载程序等。 
             在数据管理阶段，元数据主要包括下列信息： 
                 ∙汇总数据的描述：汇总/聚合层次、物化视图结构定义。 
                 ∙历史数据存储规则：位置、存储粒度。 
                 ∙多维数据结构描述：立方体定义、维结构、度量值、钻取层次定义等。 
             在数据展现阶段，元数据主要包括以下信息： 
                 ∙报表的描述：报表结构的定义。 
                 ∙统计函数的描述：各类统计分析函数的定义。 
                 ∙结果输出的描述：图、表输出的定义。 
             
             
数据质量管理、元数据管理 有专门人员管理，专门工具管理

将整个项目的实施分成若干个 阶段，以“总体规划、分步实施、步步见效”为原则

                                    
----------------------------------------------------------

六、元数据管理 
元数据：
     1）技术元数据：表怎么创建的，字 段类型、外部表还是内部表、分区表。。。
     2）业务元数据：表与表之间的转换依赖关系，业务规则
     3）管理元数据 ： 表有哪些人管理维护；谁拥有该表的权限，
         
详细见 文档！

----------------------------------------------------------

七、数据治理

1、建立完善的管理制度、管理规则
2、元数据管理 

3、数据质量管理
4、数据规则管理 

        空值、规范格式、阈值、业务逻辑、重复性、波动性、相关性、平衡性

----------------------------------------------------------

八、数据中台

即数据平台，依赖于数据仓库，可供第三方调用的统一标准

数据中台是指通过数据技术，对海量数据进行采集、计算、存储、加工，同时统一标准和口径

“数据中台”一般包含以下几个部分：

1、数据仓库：用来存储数据的，结构性数据、非结构性数据等，还有离线数据和实时数据等；

2、大数据中间件：包含了大数据计算服务、大数据研发套件、数据分析及展现工具；

3、数据资产管理：按照阿里的体系应该分为垂直数据、公共数据和萃取数据3层；

 

----------------------------------------------------------

九、数仓架构
                                    
                                    
inmon架构
    即从数据源到数据仓库再到数据集市的（先有数据仓库再有数据市场）一 种瀑布流开发方法。    
    缺点：    从数据源开始，数仓架构比较复杂
kimball架构（从需求、dm层反推，知道要得到什么数据，然后从ods开始导；）
    即从数据集市到数据仓库再到数据源(先有数据集市再有数据仓库)的一 种敏捷开发方法
    Kimball往往意味着快速交付、敏捷迭代，不会对数据仓库架构做过多复杂的设计，在变换莫测的互联网行业，这 种架构方式逐渐成为一种主流范式。    
    缺点：需求多变的话，表可能会频繁变更