数据分层

最新推荐文章于 2024-07-14 07:39:29 发布

weixin_34040079

最新推荐文章于 2024-07-14 07:39:29 发布

阅读量543

点赞数

CC 4.0 BY-SA版权

文章标签：大数据移动开发数据库

原文链接：https://my.oschina.net/sunmin/blog/3035519

为什么80%的码农都做不了架构师？>>>

1.数据计算层

01.数据计算层-主要考虑方面
	计算平台：离线数据计算 实时数据计算
	管理：元数据模型整合和应用、
		数据表的规范命名
		存储元数据：
		运行数据：

2.计算的数据分层：数据加工链路

	01.ODS--数据计算层，这一层作为原始数据层
		目前命名 qmc_da   qmc-dc qmc_dd
		以后的命名方式
	02.CDM层--
		DWD层-公共明细层
		DWS层- 公共汇总层
	03.ADS层
		应用层-- MySQL以及HBase
   说明：
	操作数据层--也就是我们放在Hive中的源表
	公共维度模型层：
		这层的话，我们是没有计算的
		这层的话，会把一些维度--采用维度退化的方式吧数据放到		明细事实表中，减少计算的关联
		  主要是复用关联，减少数据的扫描
	应用数据层： 这层是根据ODS直接计算得出的，以后可以根据ODS层以及CDM层计算出来

2.需要考虑的问题

01.ODS层
	Hive目前采用的是内部表，存在误删除的潜在风险，容易造成数据丢失。可以加强的手段是权限控制。
	目前考虑是否改成外部表，
		如果有操作失误，比如删表之类的操作，外部表只删除元数据，不涉及处理后的源数据
02.CDM层的相关内容
   CDM层这层目前没有，是把应用层往下移，还是怎么处理？
   目前分层的情况，是否需要考虑之前的数据的迁移改变，还是说老表老办法，新表新办法，
   CDM层的考虑的问题
   01.数据是否分库以及如何分库
   02.维度表的处理-
       提取公共维度表
       维度表中--把用户的原始数据推断出的新维度计算出来
       缓慢变化维的处理方式：同一ID对应的维度值变化，是采用哪些方式处理
        新增字段的处理
   03.对流量表中常见的业务的处理
   	明细是否要将一些维度加在内？
   	明细的结构--如何抽象出
	明细的计算：如何确保本层数据计算执行的稳定性以及故障发现和恢复
   04.CDM确定的原则和方法
    原则：
    	高内聚和低耦合
    	核心数据和扩展数据--数据分安全和价值等级
    	命名规范-易于开发和使用
    方法：维度建模
    步骤
    	需求调研--
    	           一是和业务人员沟通，
    				二是对目前报表以及数据营销平台的报表进行分析
    			确定根据什么汇总，以及汇总哪些数据-明细和汇总数据如何设计
    	模型设计：
    		……
    		推断信息加入到原始流量表中--例如用户的年龄
    		事实表--维度退化
    关于维度表
    	方式一：
    	   如两三个表都有产品名这个维度，提出来。维度key，和对应的维度值
    	    相应的字段- 表，维度和维度对应的key值
    		例如：
    			 表	维度key	维度Value
    		    act	productName  ltcp
    			act	productName  yccp
    			act	platform			iOS
    			….
    	方式二：
    		维度类型
    			维度类型	维度子ID 维度父ID
    			1	ltcp3     lt
    			1	ltcp5     lt
    			1	yccp      yc

3.使用的方式：

数据调用服务--优先使用CDM数据，当这层没有的时候，评估是否需要创建，如果不需要，再使用ODS层

4.附录：

01.名词术语解释：
  ODS <Operational Data Store> 操作数据层
  CDM<Common Dimension Model > 公共维度模型层
	DWD<Data Warehouse Detail>明细数据层
	DWS<Data WareHouse Summary> 汇总数据层
  ADS<Application Data Store> 应用数据层
02.维度建模

03.规范定义
	表命名规范

特殊情况的考虑

缓慢变化维（Slowly Changing Dimensions）

指的是：维度表里面的数据并非是始终不变的，总会随着时间发生变化。
缓慢渐变类型一 (Type 1 SCD)：

在数据仓库中，我们可以保持业务数据和数据仓库中的数据始终处于一致。可以在 Customer 维度中使用来自业务数据库中的 Business Key - CustomerID 来追踪业务数据的变化，一旦发生变化那么就将旧	的业务数据覆盖重写。

缓慢渐变类型二 (Type 2 SCD)：

当然在数据仓库中更多是对相对静态的历史数据进行数据的汇总和分析，因此会尽可能的维护来自业务系统中的历史数据，能够真正捕获到这种历史数据的变化。比如用户手机号，而应该新增加一条数据来说明现在 手机号， 同时保留以前的手机号。

缓慢渐变类型三 (Type 3 SCD)：

实际上 Type 1 and 2 可以满足大多数需求了，但是仍然有其它的解决方案，比如说 Type 3 SCD。 Type 3 SCD 希望只维护更少的历史记录，比如说把要维护的历史字段新增一列，然后每次只更新 Current Column 和 Previous Column。这样，只保存了最近两次的历史记录。但是如果要维护的字段比较多，就比较麻烦，因为要更多的 Current 和 Previous 字段。所以 Type 3 SCD 用的还是没有 Type 1 和 Type 2 那么普遍。

转载于:https://my.oschina.net/sunmin/blog/3035519