Artikel ini membawa anda pengetahuan yang berkaitan tentang mysql, yang terutamanya memperkenalkan isu yang berkaitan dengan jadual zip pangkalan data ialah model data, terutamanya untuk reka bentuk gudang data data. Seperti namanya, apa yang dipanggil zip adalah untuk merakam sejarah Mari kita lihat bersama-sama.
Pembelajaran yang disyorkan: tutorial video mysql
Dalam proses reka bentuk model data gudang data, kami sering menghadapi keperluan seperti:
1 Jumlah data yang agak besar
2 akan Dikemas kini, seperti alamat pengguna, maklumat perihalan produk, status pesanan, dll.; untuk melihat maklumat petikan sejarah pesanan pada titik tertentu dalam sejarah Status pada satu masa, contohnya, semak berapa kali pengguna telah mengemas kini dalam tempoh masa tertentu pada masa lalu, dsb.; 🎜>
4. Perkadaran dan kekerapan perubahan tidak begitu besar, contohnya, terdapat 10 juta jumlahnya terdapat kira -kira 100,000 ahli baru dan perubahan setiap hari; daripada jadual ini disimpan setiap hari, maka banyak maklumat yang tidak berubah akan disimpan dalam jumlah penuh setiap kali, yang memudaratkan penyimpananTerdapat beberapa pilihan untuk jenis ini daripada jadual:
Pilihan 1: Hanya simpan salinan terkini setiap hari, seperti milik kami Gunakan Sqoop untuk mengekstrak jumlah data penuh terkini ke dalam Hive setiap hari. Pilihan 2: Simpan sekeping data penuh setiap hari.
Pilihan 1
Tidak perlu dikatakan, penyelesaian ini sangat mudah untuk laksanakan. Mudah, lepaskan data hari sebelumnya setiap hari dan ekstrak yang terbaru sekali lagi.Kelebihan yang jelas Ia menjimatkan ruang. Ia juga sangat mudah untuk beberapa kegunaan biasa.
Kekurangan juga jelas Tiada data sejarah Satu-satunya cara untuk menyemak akaun lama dahulu adalah melalui kaedah lain, seperti melukis dari helaian aliran.Pilihan 2
Hidangan penuh kepingan setiap hari ialah pelan yang agak selamat dan data sejarahnya ada.Kelemahannya ialah ia mengambil terlalu banyak ruang storan Jika salinan penuh jadual ini disimpan setiap hari, banyak maklumat yang tidak berubah akan disimpan dalam setiap salinan penuh, yang merupakan pembaziran besar storan. . , saya masih berasa sangat mendalam tentang perkara ini...
Sudah tentu kita juga boleh membuat pertukaran, seperti hanya mengekalkan data bulan lalu? Walau bagaimanapun, permintaan itu tidak tahu malu, dan kitaran hayat data bukanlah sesuatu yang boleh kita kawal sepenuhnya.Meja zip
Meja zip pada asasnya mengambil kira keperluan kita dalam penggunaan.Pertama sekali, ia membuat pertukaran dari segi ruang Walaupun ia tidak menempati ruang sekecil Pelan 1, kenaikan hariannya mungkin hanya seperseribu atau sepersepuluh ribu daripada Pelan 2. .
Malah, ia boleh memenuhi keperluan pilihan dua Ia bukan sahaja boleh mendapatkan data terkini, tetapi juga menambah syarat penapis dan mendapatkan data sejarah. Jadi masih perlu untuk kita menggunakan meja berzip. Konsep meja zipJadual zip ialah model data, yang ditakrifkan terutamanya untuk cara jadual menyimpan data dalam reka bentuk gudang data Seperti namanya, apa yang dipanggil zip adalah untuk rekod sejarah. Rekod maklumat tentang semua perubahan dalam sesuatu daripada permulaannya hingga keadaan semasanya. Jadual zip boleh mengelakkan masalah storan besar-besaran yang disebabkan oleh menyimpan semua rekod untuk setiap hari, dan juga merupakan cara biasa untuk menangani data yang berubah secara perlahan-lahan (SCD2). Penjelasan daripada Baidu Encyclopedia: Jadual zip ialah jadual yang mengekalkan status sejarah dan data status terkini Bergantung pada butiran zip, jadual zip sebenarnya bersamaan dengan syot kilat, tetapi ia telah dioptimumkan dan beberapa bahagian. telah dialih keluar rekod tidak berubah, rekod pelanggan pada masa zip boleh dipulihkan dengan mudah melalui jadual zip. Algoritma jadual zip1 Kumpulkan data penuh hari itu ke jadual ND (NowDay) 2 simpannya dalam jadual OD ( OldDay (hari terakhir); 3. Bandingkan kedua-dua jadual dengan semua medan. (ND-OD) ialah data baharu dan diubah pada hari tersebut, iaitu, kenaikan hari, diwakili oleh W_I;4. Bandingkan medan penuh dua jadual (OD-ND) ialah data yang perlu ditutup apabila status tamat, diwakili oleh W_U; 5. Tukar kandungan jadual W_I Semua dimasukkan ke dalam jadual sejarah Ini adalah rekod baharu ialah hari semasa, dan tarikh_akhir ialah nilai maksimum, yang boleh ditetapkan kepada '9999 -12-31'; 6. Lakukan bahagian W_U jadual sejarah Dalam operasi kemas kini, tarikh_mula kekal tidak berubah, manakala tarikh_akhir ditukar kepada hari semasa, yang merupakan operasi pautan (. OD) dibandingkan dengan jadual W_U, kecuali untuk START_DATE dan END_DATE Jadual W_U akan diguna pakai. Contoh jadual zip 1Sebagai contoh mudah, contohnya, terdapat jadual pesanan: Terdapat 3 rekod pada 20 Jun:
| 订单创建日期 | 订单编号 | 订单状态 |
|---|---|---|
| 2012-06-20 | 001 | 创建订单 |
| 2012-06-20 | 002 | 创建订单 |
| 2012-06-20 | 003 | 支付完成 |
Menjelang 21 Jun, terdapat 5 rekod dalam jadual:
| 订单创建日期 | 订单编号 | 订单状态 |
|---|---|---|
| 2012-06-20 | 001 | 创建订单 |
| 2012-06-20 | 002 | 创建订单 |
| 2012-06-20 | 003 | 支付完成 |
| 2012-06-21 | 004 | 创建订单 |
| 2012-06-21 | 005 | 创建订单 |
Menjelang 22 Jun, terdapat 6 rekod dalam jadual:
| 订单创建日期 | 订单编号 | 订单状态 |
|---|---|---|
| 2012-06-20 | 001 | 创建订单 |
| 2012-06-20 | 002 | 创建订单 |
| 2012-06-20 | 003 | 支付完成 |
| 2012-06-21 | 004 | 创建订单 |
| 2012-06-21 | 005 | 创建订单 |
| 2012-06-22 | 006 | 创建订单 |
Kaedah daripada mengekalkan jadual ini dalam gudang data:
1. Hanya simpan salinan penuh, maka data akan sama dengan rekod pada 22 Jun. Jika anda perlu menyemak status pesanan 001 pada 21 Jun , ia tidak akan berpuas hati ;
2 Jika salinan penuh disimpan setiap hari, jadual dalam gudang data mempunyai sejumlah 14 rekod, tetapi banyak rekod disimpan berulang kali dan tiada perubahan tugas. Sebagai contoh, pesanan 002,004, jumlah data adalah besar, ia akan Menyebabkan banyak pembaziran penyimpanan
Jika jadual direka untuk disimpan sebagai jadual berzip sejarah di gudang data, akan ada; jadual seperti berikut:
| 订单创建日期 | 订单编号 | 订单状态 | dw_bigin_date | dw_end_date |
|---|---|---|---|---|
| 2012-06-20 | 001 | 创建订单 | 2012-06-20 | 2012-06-20 |
| 2012-06-20 | 001 | 支付完成 | 2012-06-21 | 9999-12-31 |
| 2012-06-20 | 002 | 创建订单 | 2012-06-20 | 9999-12-31 |
| 2012-06-20 | 003 | 支付完成 | 2012-06-20 | 2012-06-21 |
| 2012-06-20 | 003 | 已发货 | 2012-06-22 | 9999-12-31 |
| 2012-06-21 | 004 | 创建订单 | 2012-06-21 | 9999-12-31 |
| 2012-06-21 | 005 | 创建订单 | 2012-06-21 | 2012-06-21 |
| 2012-06-21 | 005 | 支付完成 | 2012-06-22 | 9999-12-31 |
| 2012-06-22 | 006 | 创建订单 | 2012-06-22 | 9999-12-31 |
Penjelasan:
1 dw_begin_date menunjukkan masa mula kitaran hayat rekod, dw_end_date menunjukkan masa tamat kitaran hayat rekod. ;
2. dw_end_date = '9999-12-31' menunjukkan bahawa rekod pada masa ini dalam status Sah; '9999-12-31';
4 Jika menanyakan petikan sejarah 2012-06-21, kemudian pilih * daripada order_nya di mana dw_begin_date <= '2012-06-21' dan end_date >= '2012 -06-21', penyataan ini akan menanyakan rekod berikut:
Selaras betul dengan rekod dalam jadual sumber pada 21 Jun:| 订单创建日期 | 订单编号 | 订单状态 | dw_bigin_date | dw_end_date |
|---|---|---|---|---|
| 2012-06-20 | 001 | 支付完成 | 2012-06-21 | 9999-12-31 |
| 2012-06-20 | 002 | 创建订单 | 2012-06-20 | 9999-12-31 |
| 2012-06-20 | 003 | 支付完成 | 2012-06-20 | 2012-06-21 |
| 2012-06-21 | 004 | 创建订单 | 2012-06-21 | 9999-12-31 |
| 2012-06-21 | 005 | 创建订单 | 2012-06-21 | 2012-06-21 |
Dapat dilihat bahawa jadual berzip sejarah bukan sahaja dapat memenuhi permintaan untuk data sejarah, tetapi juga menjimatkan sumber storan pada tahap yang besar
dalam Mungkin terdapat hanya beberapa rekod kehidupan seseorang dalam jadual sejarah, yang mengelakkan masalah penyimpanan besar-besaran yang disebabkan oleh merekod status pelanggan setiap hari:
| 人名 | 开始日期 | 结束日期 | 状态 |
|---|---|---|---|
| client | 19000101 | 19070901 | H在家 |
| client | 19070901 | 19130901 | A小学 |
| client | 19130901 | 19160901 | B初中 |
| client | 19160901 | 19190901 | C高中 |
| client | 19190901 | 19230901 | D大学 |
| client | 19230901 | 19601231 | E公司 |
| client | 19601231 | 29991231 | H退休在家 |
Setiap rekod di atas tidak dikira pada Sebagai contoh, pada tahun 19070901, pelanggan sudah berada dalam A, bukan H. Oleh itu, kecuali rekod terakhir, yang statusnya tidak berubah setakat ini, rekod selebihnya sebenarnya berada di negeri pada tarikh tamat rekod dan tidak lagi berada di negeri pada tarikh tamat rekod. Fenomena ini boleh difahami sebagai mengira permulaan tetapi bukan penamat.
1 Tentukan dua jadual sementara, satu untuk data penuh hari itu dan satu lagi untuk data yang perlu ditambah atau dikemas kini; 🎜>
2. Dapatkan jumlah data penuh untuk hari ituCREATE VOLATILE TABLE VT_xxxx_NEW AS xxxx WITH NO DATA ON COMMIT PRESERVE ROWS;CREATE VOLATILE SET TABLE VT_xxxx_CHG,NO LOG AS xxxx WITH NO DATA ON COMMIT PRESERVE ROWS;
INSERT INTO VT_xxxx_NEW(xx) SELECT (xx,cur_date, max_date) FROM xxxx_sorce;
INSERT INTO VT_xxxx_CHG(xx)SELECT xx FROM VT_xxxx_NEWWHERE (xx) NOT IN (select xx from xxxx_HIS where end_date='max_date');
UPDATE A1 FROM xxxx_HIS A1, VT_xxxx_CHG A2SET End_Date='current_date'WHERE A1.xx=A2.xx AND A1.End_Date='max_date';
INSERT INTO xxxx_HIS SELECT * FROM VT_xxxx_CHG;
Terdapat jadual produk t_product, struktur jadual adalah seperti berikut:
Nama lajur |
|
Penerangan
|
|||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| goods_id | varchar(50) | Nombor item | |||||||||||||||||||||||||||||||||||
| goods_status | varchar(50) | Status barangan (menunggu semakan, untuk dijual, dijual, dipadamkan) | |||||||||||||||||||||||||||||||||||
| createtime | varchar(50) | Tarikh pembuatan produk | |||||||||||||||||||||||||||||||||||
| modifytime | varchar(50) | Tarikh pengubahsuaian produk |
Data pada 20 Disember 2019 adalah seperti berikut:
goods_id |
goods_status |
createtime |
modifytime |
|---|---|---|---|
| 001 | Untuk disemak | 2019-12-20 td> | 2019-12 -20 |
| 002 | Untuk Dijual | 2019- 12-20 | 2019-12-20 |
| 003 | Dijual | 2019-12-20 | 2019-12- 20 |
| Dipadamkan | 2019-12- 20 | 2019-12-20 |
| goods_id | goods_status | createtime | modifytime |
|---|---|---|---|
| 001 | 待审核 | 2019-12-18 | 2019-12-20 |
| 002 | 待售 | 2019-12-19 | 2019-12-20 |
| 003 | 在售 | 2019-12-20 | 2019-12-20 |
| 004 | 已删除 | 2019-12-15 | 2019-12-20 |
| goods_id | goods_status | createtime | modifytime | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 001 | Tunggu Semakan | 2019-12-18 | 2019-12-20 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 002 | Untuk Dijual | 2019-12-19 | 2019- 12 -20 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 003 | Dijual | 2019 - 12-20 | 2019-12-20 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 004 | Dipadamkan | 2019-12-15 | 2019-12-20 |
|
goods_status | createtime | modifytime | ||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Berikut ialah data syot kilat pada 20 Disember | |||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 001 | Semakan belum selesai | 2019-12-18 | 2019-12-20 | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| 002 | Untuk dijual | 2019-12-19 | 2019-12-20 | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| 003 | Dijual2019-12-20 | 2019-12-20 | |||||||||||||||||||||||||||||||||||||||||||||||||||||
| 004 | Dipadamkan | 2019-12-15 | 20-12-2019 | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| Berikut ialah data syot kilat pada 21 Disember | |
||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 001 | Untuk dijual (daripada belum selesai kepada belum selesai) | 2019-12-18 | 2019-12-21|||||||||||||||||||||||||||||||||||||||||||||||||||||
| 002 | Untuk Dijual | 2019-12-19 | 2019-12-20 | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| 003 td> | Dijual | 20-12-2019 | 20-12-2019 td> | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| 004 | Dipadamkan | 2019-12-15 | 20-12-2019 | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| 005 (produk baharu) | Kepada disemak | 2019-12-21 | 2019-12-21 | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| Untuk disemak | 2019-12-21 | 21-12-2019 |
| goods_id | goods_status | createtime | modifytime |
|---|---|---|---|
| 以下为12月20日快照数据 | |||
| 001 | 待审核 | 2019-12-18 | 2019-12-20 |
| 002 | 待售 | 2019-12-19 | 2019-12-20 |
| 003 | 在售 | 2019-12-20 | 2019-12-20 |
| 004 | 已删除 | 2019-12-15 | 2019-12-20 |
| 以下为12月21日快照数据 | |||
| 001 | 待售（从待审核到待售） | 2019-12-18 | 2019-12-21 |
| 002 | 待售 | 2019-12-19 | 2019-12-20 |
| 003 | 在售 | 2019-12-20 | 2019-12-20 |
| 004 | 已删除 | 2019-12-15 | 2019-12-20 |
| 005 | 待审核 | 2019-12-21 | 2019-12-21 |
| 006 | 待审核 | 2019-12-21 | 2019-12-21 |
| 以下为12月22日快照数据 | |||
| 001 | 待售 | 2019-12-18 | 2019-12-21 |
| 002 | 待售 | 2019-12-19 | 2019-12-20 |
| 003 | 已删除（从在售到已删除） | 2019-12-20 | 2019-12-22 |
| 004 | 待审核 | 2019-12-21 | 2019-12-21 |
| 005 | 待审核 | 2019-12-21 | 2019-12-21 |
| 006 | 已删除（从待审核到已删除） | 2019-12-21 | 2019-12-22 |
| 007 | 待审核 | 2019-12-22 | 2019-12-22 |
| 008 | 待审核 | 2019-12-22 | 2019-12-22 |
MySQL初始化
在MySQL中 lalian 库和商品表用于到原始数据层
-- 创建数据库create database if not exists lalian;-- 创建商品表create table if not exists `lalian`.`t_product`( goods_id varchar(50), -- 商品编号 goods_status varchar(50), -- 商品状态 createtime varchar(50), -- 商品创建时间 modifytime varchar(50) -- 商品修改时间);
在MySQL中创建ods和dw层来模拟数仓
-- ods创建商品表create table if not exists `lalian`.`ods_t_product`( goods_id varchar(50), -- 商品编号 goods_status varchar(50), -- 商品状态 createtime varchar(50), -- 商品创建时间 modifytime varchar(50), -- 商品修改时间 cdat varchar(10) -- 模拟hive分区)default character set = 'utf8';-- dw创建商品表create table if not exists `lalian`.`dw_t_product`( goods_id varchar(50), -- 商品编号 goods_status varchar(50), -- 商品状态 createtime varchar(50), -- 商品创建时间 modifytime varchar(50), -- 商品修改时间 cdat varchar(10) -- 模拟hive分区)default character set = 'utf8';
增量导入12月20号数据
原始数据导入12月20号数据（4条）
insert into `lalian`.`t_product`(goods_id, goods_status, createtime, modifytime) values('001', '待审核', '2019-12-18', '2019-12-20'),('002', '待售', '2019-12-19', '2019-12-20'),('003', '在售', '2019-12-20', '2019-12-20'),('004', '已删除', '2019-12-15', '2019-12-20');注意：由于这里使用的MySQL来模拟的数仓所以直接使用insert into的方式导入数据，在企业中可能会使用hive来做数仓使用 kettle 或者 sqoop 或 datax 等来同步数据。
# 从原始数据层导入到ods 层insert into lalian.ods_t_productselect *,'20191220' from lalian.t_product ;# 从ods同步到dw层insert into lalian.dw_t_productselect * from lalian.ods_t_product where cdat='20191220';
查看dw层的运行结果
select * from lalian.dw_t_product where cdat='20191220';
| goods_id | goods_status | createtime | modifytime | cdat |
|---|---|---|---|---|
| 1 | 待审核 | 2019/12/18 | 2019/12/20 | 20191220 |
| 2 | 待售 | 2019/12/19 | 2019/12/20 | 20191220 |
| 3 | 在售 | 2019/12/20 | 2019/12/20 | 20191220 |
| 4 | 已删除 | 2019/12/15 | 2019/12/20 | 20191220 |
增量导入12月21数据
原始数据层导入12月21日数据（6条数据）
UPDATE `lalian`.`t_product` SET goods_status = '待售', modifytime = '2019-12-21' WHERE goods_id = '001';
INSERT INTO `lalian`.`t_product`(goods_id, goods_status, createtime, modifytime) VALUES
('005', '待审核', '2019-12-21', '2019-12-21'),
('006', '待审核', '2019-12-21', '2019-12-21');将数据导入到ods层与dw层
# 从原始数据层导入到ods 层insert into lalian.ods_t_productselect *,'20191221' from lalian.t_product ;# 从ods同步到dw层insert into lalian.dw_t_productselect * from lalian.ods_t_product where cdat='20191221';
查看dw层的运行结果
select * from lalian.dw_t_product where cdat='20191221';
| goods_id | goods_status | createtime | modifytime | cdat |
|---|---|---|---|---|
| 1 | 待售 | 2019/12/18 | 2019/12/21 | 20191221 |
| 2 | 待售 | 2019/12/19 | 2019/12/20 | 20191221 |
| 3 | 在售 | 2019/12/20 | 2019/12/20 | 20191221 |
| 4 | 已删除 | 2019/12/15 | 2019/12/20 | 20191221 |
| 5 | 待审核 | 2019/12/21 | 2019/12/21 | 20191221 |
| 6 | 待审核 | 2019/12/21 | 2019/12/21 | 20191221 |
增量导入12月22日数据
原始数据层导入12月22日数据（6条数据）
UPDATE `lalian`.`t_product` SET goods_status = '已删除', modifytime = '2019-12-22' WHERE goods_id = '003';UPDATE `lalian`.`t_product` SET goods_status = '已删除', modifytime = '2019-12-22' WHERE goods_id = '006';INSERT INTO `lalian`.`t_product`(goods_id, goods_status, createtime, modifytime) VALUES('007', '待审核', '2019-12-22', '2019-12-22'),('008', '待审核', '2019-12-22', '2019-12-22');将数据导入到ods层与dw层
# 从原始数据层导入到ods 层 insert into lalian.ods_t_product select *,'20191222' from lalian.t_product ; # 从ods同步到dw层 insert into lalian.dw_t_productpeizhiwenjian select * from lalian.ods_t_product where cdat='20191222';
查看dw层的运行结果
select * from lalian.dw_t_product where cdat='20191222';
| goods_id | goods_status | createtime | modifytime | cdat |
|---|---|---|---|---|
| 1 | 待售 | 2019/12/18 | 2019/12/21 | 20191222 |
| 2 | 待售 | 2019/12/19 | 2019/12/20 | 20191222 |
| 3 | 已删除 | 2019/12/20 | 2019/12/22 | 20191222 |
| 4 | 已删除 | 2019/12/15 | 2019/12/20 | 20191222 |
| 5 | 待审核 | 2019/12/21 | 2019/12/21 | 20191222 |
| 6 | 已删除 | 2019/12/21 | 2019/12/22 | 20191222 |
| 7 | 待审核 | 2019/12/22 | 2019/12/22 | 20191222 |
| 8 | 待审核 | 2019/12/22 | 2019/12/22 | 20191222 |
查看dw层的运行结果
select * from lalian.dw_t_product;
| goods_id | goods_status | createtime | modifytime | cdat |
|---|---|---|---|---|
| 1 | 待审核 | 2019/12/18 | 2019/12/20 | 20191220 |
| 2 | 待售 | 2019/12/19 | 2019/12/20 | 20191220 |
| 3 | 在售 | 2019/12/20 | 2019/12/20 | 20191220 |
| 4 | 已删除 | 2019/12/15 | 2019/12/20 | 20191220 |
| 1 | 待售 | 2019/12/18 | 2019/12/21 | 20191221 |
| 2 | 待售 | 2019/12/19 | 2019/12/20 | 20191221 |
| 3 | 在售 | 2019/12/20 | 2019/12/20 | 20191221 |
| 4 | 已删除 | 2019/12/15 | 2019/12/20 | 20191221 |
| 5 | 待审核 | 2019/12/21 | 2019/12/21 | 20191221 |
| 6 | 待审核 | 2019/12/21 | 2019/12/21 | 20191221 |
| 1 | 待售 | 2019/12/18 | 2019/12/21 | 20191222 |
| 2 | 待售 | 2019/12/19 | 2019/12/20 | 20191222 |
| 3 | 已删除 | 2019/12/20 | 2019/12/22 | 20191222 |
| 4 | 已删除 | 2019/12/15 | 2019/12/20 | 20191222 |
| 5 | 待审核 | 2019/12/21 | 2019/12/21 | 20191222 |
| 6 | 已删除 | 2019/12/21 | 2019/12/22 | 20191222 |
| 7 | 待审核 | 2019/12/22 | 2019/12/22 | 20191222 |
| 8 | 待审核 | 2019/12/22 | 2019/12/22 | 20191222 |
Daripada kes di atas, kita dapat melihat bahawa jadual mengekalkan volum penuh setiap hari, dan banyak maklumat yang tidak berubah akan disimpan dalam setiap volum penuh Jika jumlah data adalah besar, ia akan menjadi a pembaziran besar storan , meja boleh direka bentuk sebagai jadual zip, yang bukan sahaja dapat mencerminkan status sejarah data, tetapi juga menjimatkan ruang storan ke tahap maksimum.
Jadual zip tidak menyimpan data berlebihan, hanya 行的数据发生变化，才需要保存下来 tertentu, yang akan menjimatkan ruang storan berbanding penyegerakan penuh setiap kali
Keupayaan untuk menanyakan petikan sejarah
Menambahkan dua lajur tambahan (dw_start_date, dw_end_date) untuk kitaran hayat baris data.
|
goods_status |
dw_end_dateth > |
|||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 001 | Semakan belum selesai | 2019-12-18 | 2019-12-20 | 2019-12-20 | 9999-12-31 | ||||||||||||||||||||||||||||||
| 002 | Untuk Dijual | 2019-12-19 | 2019-12-20 | 2019-12-20 | 9999-12-31 | ||||||||||||||||||||||||||||||
| 003 | Tersedia | 20-12-2019 | 20-12-2019 | 20-12-2019 | 9999-12-31 | ||||||||||||||||||||||||||||||
| 004 | Dipadamkan | 2019-12-152019-12-20 | 2019-12-20 | 9999-12-31 |
| goods_id | goods_status | createtime | modifytime | dw_start_date | dw_end_date |
|---|---|---|---|---|---|
| 001 | 待审核 | 2019-12-18 | 2019-12-20 | 2019-12-20 | 2019-12-21 |
| 002 | 待售 | 2019-12-19 | 2019-12-20 | 2019-12-20 | 9999-12-31 |
| 003 | 在售 | 2019-12-20 | 2019-12-20 | 2019-12-20 | 9999-12-31 |
| 004 | 已删除 | 2019-12-15 | 2019-12-20 | 2019-12-20 | 9999-12-31 |
| 001（变） | 待售 | 2019-12-18 | 2019-12-21 | 2019-12-21 | 9999-12-31 |
| 005（新） | 待审核 | 2019-12-21 | 2019-12-21 | 2019-12-21 | 9999-12-31 |
| goods_id | goods_status | createtime | modifytime | dw_start_date | dw_end_date | tr>
|---|---|---|---|---|---|
| 001 | Untuk disemak | 2019-12 -18 | 2019-12-20 | 2019 -12-20 | 2019-12-21 |
| 002 td> | Untuk Dijual | 2019-12-19 | 2019-12-20 | 20-12-2019 | 9999-12-31|
| 003 | Dijual | 2019-12-20 | 2019-12-20 td> | 20-12-2019 | 9999-12-31 |
| 004 | Dipadamkan td> | 2019-12-15 | 2019-12-20 | 2019-12-20 | 9999-12-31 |
| 001 (ubah) | Untuk Dijual | 2019 -12-18 | 2019-12-21 | 2019-12 -21 | 9999-12-31 |
| 005 (baru) | Untuk disemak | 2019-12 -21 | 2019-12-21 | 2019-12-21 | 9999-12-31 |
Tiada data berlebihan yang disimpan dalam jadual zip, iaitu, selagi data tidak berubah, tidak perlu disegerakkan
|
goods_status | createtime | modifytime | dw_start_date | dw_end_date | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 001 | Untuk disemak | 2019-12-18 | 2019-12-20 | 2019-12-20 | 2019-12-21 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 002 | Untuk Dijual | 2019-12-19 | 2019-12-20 | 2019-12-20 | 9999-12-31|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 003 | Dijual | 2019-12-20 | 20-12-2019 | 2019-12-20 | 22-12-2019 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 004 | Dipadamkan | 2019-12-15 | 2019-12-20 | 2019-12-20 | 9999-12-31 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 001 | Untuk dijual | 2019-12-18 | 2019-12-21 | 2019-12-21 | 9999-12-31 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 005 | Untuk disemak2019-12-21 | 2019-12-21 | 2019-12-21 | 9999-12-31 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 006 | Untuk disemak | 2019-12-21 | 2019-12-21 | 2019-12-219999-12-31 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 003 (ubah) | Dipadamkan | 2019-12-20 | 2019-12-22 | 2019-12-22 mark> mark> | 9999-12-31 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 007 ( Baharu) | Untuk disemak | 2019-12-22 | 22-12-2019 | 2019-12-22 mark>| 9999-12-31 | |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 008 ( baru) | Untuk disemak | 2019-12-22 mark> td>| 2019-12-22 |
2019-12-22 | 9999-12-31 | |
拉链表中没有存储冗余的数据，即只要数据没有变化，无需同步
操作流程：
代码实现
在MySQL中lalian库和商品表用于到原始数据层
-- 创建数据库create database if not exists lalian;-- 创建商品表create table if not exists `lalian`.`t_product2`( goods_id varchar(50), -- 商品编号 goods_status varchar(50), -- 商品状态 createtime varchar(50), -- 商品创建时间 modifytime varchar(50) -- 商品修改时间)default character set = 'utf8';
在MySQL中创建ods和dw层 模拟数仓
-- ods创建商品表create table if not exists `lalian`.`ods_t_product2`( goods_id varchar(50), -- 商品编号 goods_status varchar(50), -- 商品状态 createtime varchar(50), -- 商品创建时间 modifytime varchar(50), -- 商品修改时间 cdat varchar(10) -- 模拟hive分区)default character set = 'utf8';-- dw创建商品表create table if not exists `lalian`.`dw_t_product2`( goods_id varchar(50), -- 商品编号 goods_status varchar(50), -- 商品状态 createtime varchar(50), -- 商品创建时间 modifytime varchar(50), -- 商品修改时间 dw_start_date varchar(12), -- 生效日期 dw_end_date varchar(12), -- 失效时间 cdat varchar(10) -- 模拟hive分区)default character set = 'utf8';
全量导入2019年12月20日数据
原始数据层导入12月20日数据（4条数据）
insert into `lalian`.`t_product_2`(goods_id, goods_status, createtime, modifytime) values('001', '待审核', '2019-12-18', '2019-12-20'),('002', '待售', '2019-12-19', '2019-12-20'),('003', '在售', '2019-12-20', '2019-12-20'),('004', '已删除', '2019-12-15', '2019-12-20');将数据导入到数仓中的ods层
insert into lalian.ods_t_product2select *,'20191220' from lalian.t_product2 where modifytime >='2019-12-20';
将数据从ods层导入到dw层
insert into lalian.dw_t_product2select goods_id, goods_status, createtime, modifytime, modifytime,'9999-12-31', cdat from lalian.ods_t_product2 where cdat='20191220';
增量导入2019年12月21日数据
原始数据层导入12月21日数据（6条数据）
UPDATE `lalian`.`t_product2` SET goods_status = '待售', modifytime = '2019-12-21' WHERE goods_id = '001';INSERT INTO `lalian`.`t_product2`(goods_id, goods_status, createtime, modifytime) VALUES('005', '待审核', '2019-12-21', '2019-12-21'),('006', '待审核', '2019-12-21', '2019-12-21');原始数据层同步到ods层
insert into lalian.ods_t_product2select *,'20191221' from lalian.t_product2 where modifytime >='2019-12-21';
编写ods层到dw层重新计算 dw_end_date
select t1.goods_id, t1.goods_status, t1.createtime, t1.modifytime, t1.dw_start_date, case when (t2.goods_id is not null and t1.dw_end_date>'2019-12-21') then '2019-12-21'else t1.dw_end_date end as dw_end_date , t1.cdatfrom lalian.dw_t_product2 t1left join (select * from lalian.ods_t_product2 where cdat='20191221')t2 on t1.goods_id=t2.goods_idunionselect goods_id, goods_status, createtime, modifytime, modifytime,'9999-12-31', cdat from lalian.ods_t_product2 where cdat='20191221';
执行结果如下：
| goods_id | goods_status | createtime | modifytime | dw_start_date | dw_end_date | cdat |
|---|---|---|---|---|---|---|
| 1 | 待审核 | 2019-12-18 | 2019-12-20 | 2019-12-20 | 2019-12-21 | 20191220 |
| 2 | 待售 | 2019-12-19 | 2019-12-20 | 2019-12-20 | 9999-12-31 | 20191220 |
| 3 | 在售 | 2019-12-20 | 2019-12-20 | 2019-12-20 | 9999-12-31 | 20191220 |
| 4 | 已删除 | 2019-12-15 | 2019-12-20 | 2019-12-20 | 9999-12-31 | 20191220 |
| 1 | 待售 | 2019-12-18 | 2019-12-21 | 2019-12-21 | 9999-12-31 | 20191221 |
| 5 | 待审核 | 2019-12-21 | 2019-12-21 | 2019-12-21 | 9999-12-31 | 20191221 |
| 6 | 待审核 | 2019-12-21 | 2019-12-21 | 2019-12-21 | 9999-12-31 | 20191221 |
拉链历史表，既能满足反应数据的历史状态，又可以最大程度的节省存储。我们做拉链表的时候要确定拉链表的粒度，比如说拉链表每天只取一个状态，也就是说如果一天有3个状态变更，我们只取最后一个状态，这种天粒度的表其实已经能解决大部分的问题了。
推荐学习：mysql视频教程
Atas ialah kandungan terperinci Mari bercakap tentang jadual zip pangkalan data. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!
![[Web front-end] Permulaan pantas Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
