你真的了解全量表,增量表及拉链表吗？-低调大师

你真的了解全量表,增量表及拉链表吗？

2020-09-13 622

Mysql数据准备

第一天 9月10号数据

1,待支付,2020-09-10 12:20:11,2020-09-10 12:20:112,待支付,2020-09-10 14:20:11,2020-09-10 14:20:113,待支付,2020-09-10 16:20:11,2020-09-10 16:20:11

第二天 9月11号数据

1,待支付,2020-09-10 12:20:11,2020-09-10 12:20:112,已支付,2020-09-10 14:20:11,2020-09-11 14:21:113,已支付,2020-09-10 16:20:11,2020-09-11 16:21:114,待支付,2020-09-11 12:20:11,2020-09-11 12:20:115,待支付,2020-09-11 14:20:11,2020-09-11 14:20:11

对比mysql第一天和第二天的数据发现，第二天新增了订单id为4和5这两条数据，并且订单id为2和3的状态更新为了已支付

全量表

每天的所有的最新状态的数据。

1、全量表，有无变化，都要报

2、每次上报的数据都是所有的数据（变化的 + 没有变化的）

9月10号全量抽取到ods层

create table wedw_ods.order_info_20200910( order_id     string    COMMENT '订单id',order_status string    COMMENT '订单状态',create_time  timestamp COMMENT '创建时间',update_time  timestamp COMMENT '更新时间') COMMENT '订单表'row format delimited fields terminated by ',';

create table wedw_dwd.order_info_df( order_id     string    COMMENT '订单id',order_status string    COMMENT '订单状态',create_time  timestamp COMMENT '创建时间',update_time  timestamp COMMENT '更新时间') COMMENT '订单表'partitioned by (date_id string)row format delimited fields terminated by ',';

# 把wedw_ods.order_info_20200910数据全量插到dwd层2020-09-10分区insert overwrite table wedw_dwd.order_info_df partition(date_id = '2020-09-10')selectorder_id,order_status,create_time,update_timefrom wedw_ods.order_info_20200910;

9月11号全量抽取到ods层

create table wedw_ods.order_info_20200911( order_id     string    COMMENT '订单id',order_status string    COMMENT '订单状态',create_time  timestamp COMMENT '创建时间',update_time  timestamp COMMENT '更新时间') COMMENT '订单表'row format delimited fields terminated by ',';

# 把wedw_ods.order_info_20200911数据全量插到dwd层2020-09-11分区insert overwrite table wedw_dwd.order_info_df partition(date_id = '2020-09-11')selectorder_id,order_status,create_time,update_timefrom wedw_ods.order_info_20200911;

全量抽取，每个分区保留历史全量快照。

增量表

增量表：新增数据，增量数据是上次导出之后的新数据。

1、记录每次增加的量，而不是总量；

2、增量表，只报变化量，无变化不用报

3、业务库表中需有主键及创建时间，修改时间

9月10号全量抽取到ods层(全量初始化)

# 把wedw_ods.order_info_20200910数据全量插到dwd层2020-09-10分区insert overwrite table wedw_dwd.order_info_di partition(date_id = '2020-09-10')selectorder_id,order_status,create_time,update_timefrom wedw_ods.order_info_20200910;

9月11号抽取更新的数据及当天新增的数据，即订单id为2,3,4,5的数据

wedw_dwd.order_info_di表9月10号的分区数据与wedw_ods.order_info_20200911增量抽取的数据合并，有2种方案

a.两个表通过主键关联，dwd表存在并且ods表不存在的数据

union all 一下wedw_ods.order_info_20200911表所有的数据，即全量数据插入到dwd表的9月11号的分区

insert overwrite table wedw_dwd.order_info_di partition(date_id = '2020-09-11')select t1.order_id,t1.order_status,t1.create_time,t1.update_timefromwedw_dwd.order_info_di t1left joinwedw_ods.order_info_20200911 t2on t1.order_id = t2.order_idwhere t1.date_id = '2020-09-10'and t2.order_id is nullunion allselect  order_id,order_status,create_time,update_timefrom wedw_ods.order_info_20200911;

b.两个表数据union all一下，再根据order_id去重(根据order分组，更新时间降序，取第一条)

insert overwrite table wedw_dwd.order_info_di partition(date_id = '2020-09-11')select t2.order_id,t2.order_status,t2.create_time,t2.update_time from(    select     t1.order_id    ,t1.order_status    ,t1.create_time    ,t1.update_time    ,row_number() over(partition by order_id order by update_time desc) as rn    from    (        select         order_id        ,order_status        ,create_time        ,update_time        from        wedw_dwd.order_info_di         where date_id = '2020-09-10'         union all         select          order_id        ,order_status        ,create_time        ,update_time        from         wedw_ods.order_info_20200911    ) t1) t2where t2.rn = 1;

特殊增量表：da表，每天的分区就是当天的数据，其数据特点就是数据产生后就不会发生变化，如日志表。

拉链表

维护历史状态，以及最新状态数据

适用情况：

1.数据量比较大

2.表中的部分字段会被更新

3.需要查看某一个时间点或者时间段的历史快照信息

查看某一个订单在历史某一个时间点的状态

某一个用户在过去某一段时间，下单次数

4.更新的比例和频率不是很大

如果表中信息变化不是很大，每天都保留一份全量，那么每次全量中会保存很多不变的信息，对存储是极大的浪费

优点

1、满足反应数据的历史状态

2、最大程度节省存储

9月10号全量抽取到ods层

create table wedw_ods.order_info_20200910( order_id     string    COMMENT '订单id',order_status string    COMMENT '订单状态',create_time  timestamp COMMENT '创建时间',update_time  timestamp COMMENT '更新时间') COMMENT '订单表'row format delimited fields terminated by ',';

建立dwd层拉链表

增加两个字段：
start_dt(表示该条记录的生命周期开始时间——周期快照时的状态)
end_dt(该条记录的生命周期结束时间)

end_dt= ‘9999-12-31’ 表示该条记录目前处于有效状态

create table wedw_dwd.order_info_dz( order_id     string    COMMENT '订单id',order_status string    COMMENT '订单状态',create_time  timestamp COMMENT '创建时间',update_time  timestamp COMMENT '更新时间',start_dt     date      COMMENT '开始生效日期',end_dt       date      COMMENT '结束生效日期') COMMENT '订单表'partitioned by (date_id string)row format delimited fields terminated by ',';

注：第一次加工的时候需要初始化所有数据，start_time设置为数据日期2020-09-10 ，end_time设置为9999-12-31

insert overwrite table wedw_dwd.order_info_dz partition(date_id = '2020-09-10')select order_id    ,order_status,create_time ,update_time ,to_date(update_time) as start_dt   ,'9999-12-31' as end_dt  fromwedw_ods.order_info_20200910;

9月11号抽取更新的数据及当天新增的数据到ods层，即订单id为2,3,4,5的数据

insert overwrite table wedw_dwd.order_info_dz partition(date_id = '2020-09-11')select t1.order_id    ,t1.order_status,t1.create_time ,t1.update_time,t1.start_dt,case when t1.end_dt = '9999-12-31' and t2.order_id is not null then t1.date_id else t1.end_dt end as end_dtfromwedw_dwd.order_info_dz t1left join wedw_ods.order_info_20200911 t2on t1.order_id = t2.order_idwhere t1.date_id = '2020-09-10'union allSELECT t1.order_id    ,t1.order_status,t1.create_time ,t1.update_time,to_date(update_time) as start_dt,'9999-12-31' as end_dtFROM wedw_ods.order_info_20200911 t1;

查询当前的所有有效记录：

select * from wedw_dwd.order_info_dz where date_id = '2020-09-11'and end_dt ='9999-12-31';

查询9月10号历史快照:

select * from wedw_dwd.order_info_dz where date_id = '2020-09-10' and start_dt <= '2020-09-10' and end_dt >='2020-09-10';

查询9月11号历史快照:

select * from wedw_dwd.order_info_dz where date_id = '2020-09-11' and start_dt <= '2020-09-11' and end_dt >='2020-09-11';

总结

不知道以上的一些例子大家有没有看明白呢？

在工作中，其实上述3种表都是很有可能会用到的，那么我们应该怎么选择呢？

如果数据量不是很大(不超过20W)且预估后续增长的非常慢，可以考虑全量表抽取，这是最简便的方法
如果数据量目前来说不是很大，但是业务发展很快，数据量一段时间后就会上来，建议增量抽取哦
目前数据量本身就非常大，肯定是需要增量抽取的，比如现在有10亿数据，如果你每天全量抽取一遍，相信我，你会抽哭的
对于历史状态需要保存的，这个时候就需要使用拉链表了，实际工作中，使用拉链表的场景并不会太多，比如订单表，保存订单历史状态，维表(缓慢变化维的处理)

本文分享自微信公众号 - 大数据私房菜（datagogogo）。
如有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一起分享。

微信关注我们

原文链接：https://my.oschina.net/u/4631230/blog/4562781

转载内容版权归作者及来源网站所有！

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。

项目中的敏感数据处理还在百度？快来看看如何优雅实现吧！

项目中的敏感数据处理还在百度？快来看看如何优雅实现吧！对于项目中的敏感数据处理，很多同学刚开始接触的时候，往往觉得比较繁琐，项目中实现的方式也是千奇百怪，基本就是百度搜索和粘贴。对于敏感数据的处理，是任何一家互联网公司必须要注重的事情，用户的敏感信息泄露带来的危害也是十分严重的。在下不才，结合多年积累，整理了一款开箱即用的加解密解决方案，大致功能如下： RSA 加解密，支持分段加密，解决加密文本超长的问题 DES 加解密，支持多种模式 EBC、CBC（分组加密、迭代分组加密），增加盐混淆策略，避免 DES密文被抓包破解 Spring 单体应用下动态解密 Spring Cloud Gateway 微服务场景下网关动态解密针对以上功能，大体是笔者目前需要解决敏感数据传输几个常见场景。使用方式引入依赖 RSA 加解密 DES 加解密密钥获取网关动态解密准备工作服务注册接口测试实现原理小结手机用户请横屏获取最佳阅读体验，REFERENCES中是本文参考的链接，如需要链接和更多资源，可以加入『知识星球』获取长期知识分享服务。使用方式引入依赖 ##单体应用(基于Spr...

2020-09-14

604

urllib, urllib2, urllib3 都是小弟弟

urllib 是 python 的内置模块，主要用于处理url相关的一些操作，例如访问url、解析url等等。有趣的是，urllib、urllib2曾经同时出现在python2，python3又将两个模块合并成一个，社区又有大神提供了一个urllib3的库，都是用于处理网络请求相关功能，不过这些包在 requests 都是弟弟啦。而python3中，urllib包下面用的最多的恐怕还是parse模块，主要处理url相关的操作。特别是爬虫应用中，用得多。以下是我整理的关于urllib.parse的最常用方法，写爬虫过程中，经常要对url进行参数拼接、编码、解码、域名、资源路径提取等操作，parse 就可以排上用场。一、urlparse urlparse 方法是把一个完整的URL拆分成不同的组成部分，你可以根据自己的需求提取其中的某部分内容。返回结果ParseResult是namedtuple的子类，由以下10部分组成，每部分既可以通过名字获取也可以通过下表索引得到。 >>> from urllib import parse>>> url = ...

2020-09-14

636

发表评论

资源下载

更多资源

优质分享App

近一个月的开发和优化，本站点的第一个app全新上线。该app采用极致压缩，本体才4.36MB。系统里面做了大量数据访问、缓存优化。方便用户在手机上查看文章。后续会推出HarmonyOS的适配版本。

Nacos

Nacos /nɑ:kəʊs/ 是 Dynamic Naming and Configuration Service 的首字母简称，一个易于构建 AI Agent 应用的动态服务发现、配置管理和AI智能体管理平台。Nacos 致力于帮助您发现、配置和管理微服务及AI智能体应用。Nacos 提供了一组简单易用的特性集，帮助您快速实现动态服务发现、服务配置、服务元数据、流量管理。Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。

Spring

Spring框架（Spring Framework）是由Rod Johnson于2002年提出的开源Java企业级应用框架，旨在通过使用JavaBean替代传统EJB实现方式降低企业级编程开发的复杂性。该框架基于简单性、可测试性和松耦合性设计理念，提供核心容器、应用上下文、数据访问集成等模块，支持整合Hibernate、Struts等第三方框架，其适用范围不仅限于服务器端开发，绝大多数Java应用均可从中受益。

Rocky Linux

Rocky Linux（中文名：洛基）是由Gregory Kurtzer于2020年12月发起的企业级Linux发行版，作为CentOS稳定版停止维护后与RHEL（Red Hat Enterprise Linux）完全兼容的开源替代方案，由社区拥有并管理，支持x86_64、aarch64等架构。其通过重新编译RHEL源代码提供长期稳定性，采用模块化包装和SELinux安全架构，默认包含GNOME桌面环境及XFS文件系统，支持十年生命周期更新。