hive 拉链表

-- This example demonstrates Type 2 Slowly Changing Dimensions in Hive.
-- Be sure to stage data in before starting (load_data.sh)
drop database if exists type2_test cascade;
create database type2_test;
use type2_test;

-- Create the Hive managed table for our contacts. We track a start and end date.
create table contacts_target(id int, name string, email string, state string, valid_from date, valid_to date)
clustered by (id) into 2 buckets stored as orc tblproperties("transactional"="true");

-- Create an external table pointing to our initial data load (1000 records)
create external table contacts_initial_stage(id int, name string, email string, state string)
row format delimited fields terminated by ‘,‘ stored as textfile
location ‘/tmp/merge_data/initial_stage‘;

-- Copy the initial load into the managed table. We hard code the valid_from dates to the beginning of 2017.
insert into contacts_target select *, cast(‘2017-01-01‘ as date), cast(null as date) from contacts_initial_stage;

-- Create an external table pointing to our refreshed data load (1100 records)
create external table contacts_update_stage(id int, name string, email string, state string)
row format delimited fields terminated by ‘,‘ stored as textfile
location ‘/tmp/merge_data/update_stage‘;

-- Perform the Type 2 SCD.
merge into contacts_target
using (
-- The base staging data.
select
contacts_update_stage.id as join_key,
contacts_update_stage.* from contacts_update_stage

union all

-- Generate an extra row for changed records.
-- The null join_key means it will be inserted.
select
null, contacts_update_stage.*
from
contacts_update_stage join contacts_target on contacts_update_stage.id = contacts_target.id
where
( contacts_update_stage.email <> contacts_target.email or contacts_update_stage.state <> contacts_target.state )
and contacts_target.valid_to is null
) sub
on sub.join_key = contacts_target.id
when matched and contacts_target.valid_to is null
and sub.email <> contacts_target.email or sub.state <> contacts_target.state
then update set valid_to = current_date() //旧用户的信息发生了改变,则将旧信息的有限期时间改为当前
when not matched and sub.join_key is null //改变了信息的旧用户(join_key为null而匹配不上),将旧用户的最新信息数据插入
then insert values (sub.id, sub.name, sub.email, sub.state, contacts_target.valid_from, current_date(), null);
when not matched and sub.join_key is not null //新用户(join_key有值但匹配不上)
then insert values (sub.id, sub.name, sub.email, sub.state, current_date(),current_date(), null);

-- Confirm 92 records are expired.
select count(*) from contacts_target where valid_to is not null;

-- Confirm we now have 1192 records.
select count(*) from contacts_target;

-- View one of the changed records.
select * from contacts_target where id = 12;

时间: 2024-11-08 15:18:19

hive 拉链表的相关文章

Hive拉链表实现

拉链表测试: 有如下测试数据 --2019/12/1号订单的全量数据 id status create_time operation_time 1 待支付 2019-12-01 2 待支付 2019-12-01 3 已支付 2019-12-01 --2019/12/2号订单的全量数据 id status create_time operation_time 1 待支付 2019-12-01 2 已支付 2019-12-01 2019-12-02 3 已支付 2019-12-01 4 待支付 20

hive 中的拉链表 1

hive中拉链表 在有些情况下,为了保持历史的一些状态,需要用拉链表来做,这样做目的在可以保留所有状态的情况下可以节省空间. 拉链表适用于以下几种情况吧 数据量有点大,表中某些字段有变化,但是呢变化的频率也不是很高,业务需求呢又需要统计这种变化状态,每天全量一份呢,有点不太现实, 不仅浪费了存储空间,有时可能业务统计也有点麻烦,这时,拉链表的作用就提现出来了,既节省空间,又满足了需求. 一般在数仓中通过增加begin_date,en_date来表示,如下例,后两列是start_date和end_

基于hive的拉链表设计实现

参考http://lxw1234.com/archives/2015/08/473.htm 测试数据 order_2015-08-21 1 2015-08-18 2015-08-18 创建2 2015-08-18 2015-08-18 创建3 2015-08-19 2015-08-21 支付4 2015-08-19 2015-08-21 完成5 2015-08-19 2015-08-20 支付6 2015-08-20 2015-08-20 创建7 2015-08-20 2015-08-21 支付

拉链表流水表

1. 全量表:每天的所有的最新状态的数据, 2. 增量表:每天的新增数据,增量数据是上次导出之后的新数据. 3. 拉链表:维护历史状态,以及最新状态数据的一种表,拉链表根据拉链粒度的不同,实际上相当于快照,只不过做了优化,去除了一部分不变的记录而已,通过拉链表可以很方便的还原出拉链时点的客户记录. 4. 流水表: 对于表的每一个修改都会记录,可以用于反映实际记录的变更. 拉链表通常是对账户信息的历史变动进行处理保留的结果,流水表是每天的交易形成的历史: 流水表用于统计业务相关情况,拉链表用于统计

数仓1.4 |业务数仓搭建| 拉链表| Presto

电商业务及数据结构 SKU库存量,剩余多少SPU商品聚集的最小单位,,,这类商品的抽象,提取公共的内容 订单表:周期性状态变化(order_info) id 订单编号 total_amount 订单金额 order_status 订单状态 user_id 用户id payment_way 支付方式 out_trade_no 支付流水号 create_time 创建时间 operate_time 操作时间 订单详情表:(order_detail) order_detail.order_id 是要一

使用kettle制作拉链表

拉链表是在数据仓库中常见的表,主要用还存储不按时间变化的表,比如客户基本信息表. 下面先建两个实例表,user_info和user_info_l,其中user_info_l为拉链表. user_info表及数据: user_info_l表及转换后的数据: kettle的设计其实很简单,就一个“表输入”一个“维度查询/更新 下面来看一下表输入的配置: 这个很简单,但是一定要有个基本表的数据日期 下面几个是“维度查询/更新”的配置: 下面介绍一下设置中的关键地方,依次如下: 1.不钩选的话变化的数据

拉链表

拉链表是针对数据仓库设计中表存储数据的方式而定义的,顾名思义,所谓拉链,就是记录历史.记录一个事物从开始,一直到当前状态的所有变化的信息. 优点:为了节省数据库的空间 用处:记录一个事物从开始到现在所有的状态信息. 1采集原系统的全量数据到表new1. 2从历史表中获取昨日全量数据到表new2. 3从new1和new2中比较出新增和改变的数据,也就是增量数据到表new3. 4从new1和new2中比较出来改变的数据,到表new4. 5将new3的数据插入到历史表中,这些是新增记录,startda

极限存储--历史拉链表(上)

在数据仓库的数据模型设计过程中,经常会遇到这样的需求: 1. 数据量比较大;2. 表中的部分字段会被update,如用户的地址,产品的描述信息,订单的状态等等;3. 需要查看某一个时间点或者时间段的历史快照信息,比如,查看某一个订单在历史某一个时间点的状态,   比如,查看某一个用户在过去某一段时间内,更新过几次等等;4. 变化的比例和频率不是很大,比如,总共有1000万的会员,每天新增和发生变化的有10万左右;5. 如果对这边表每天都保留一份全量,那么每次全量中会保存很多不变的信息,对存储是极

Hive数据模型之历史拉链表

http://lxw1234.com/archives/2015/04/20.htm http://lxw1234.com/archives/2015/08/473.htm 原文地址:https://www.cnblogs.com/zbw1112/p/12100920.html