數(shù)據(jù)倉(cāng)庫(kù)之拉鏈表
Hive系列文章
- Hive表的基本操作
- Hive中的集合數(shù)據(jù)類型
- Hive動(dòng)態(tài)分區(qū)詳解
- hive中orc格式表的數(shù)據(jù)導(dǎo)入
- Java通過(guò)jdbc連接hive
- 通過(guò)HiveServer2訪問(wèn)Hive
- SpringBoot連接Hive實(shí)現(xiàn)自助取數(shù)
- hive關(guān)聯(lián)hbase表
- Hive udf 使用方法
- Hive基于UDF進(jìn)行文本分詞
- Hive窗口函數(shù)row number的用法
- 數(shù)據(jù)倉(cāng)庫(kù)之拉鏈表
場(chǎng)景
- 需要查看歷史某一時(shí)間節(jié)點(diǎn)的狀態(tài),同時(shí)考慮到存儲(chǔ)空間;或則適用于數(shù)據(jù)會(huì)發(fā)生變化,但是大部分是不變的
在數(shù)據(jù)倉(cāng)庫(kù)的數(shù)據(jù)模型設(shè)計(jì)過(guò)程中,經(jīng)常會(huì)遇到下面這種表的設(shè)計(jì):
有一些表的數(shù)據(jù)量很大,比如一張用戶表,大約10億條記錄,50個(gè)字段,這種表,即使使用ORC壓縮,單張表的存儲(chǔ)也會(huì)超過(guò)100G,在HDFS使用雙備份或者三備份的話就更大一些。 - 表中的部分字段會(huì)被update更新操作,如用戶聯(lián)系方式,產(chǎn)品的描述信息,訂單的狀態(tài)等等。
- 需要查看某一個(gè)時(shí)間點(diǎn)或者時(shí)間段的歷史快照信息,比如,查看某一個(gè)訂單在歷史某一個(gè)時(shí)間點(diǎn)的狀態(tài)。
- 表中的記錄變化的比例和頻率不是很大,比如,總共有10億的用戶,每天新增和發(fā)生變化的有200萬(wàn)左右,變化的比例占的很小
如果對(duì)這邊表每天都保留一份全量,那么每次全量中會(huì)保存很多不變的信息,對(duì)存儲(chǔ)是極大的浪費(fèi)
下面就是一張拉鏈表,存儲(chǔ)的是用戶的最基本信息以及每條記錄的生命周期。我們可以使用這張表拿到最新的當(dāng)天的最新數(shù)據(jù)以及之前的歷史數(shù)據(jù)。
說(shuō)明:
t_start_date
表示該條記錄的生命周期開(kāi)始時(shí)間,t_end_date
表示該條記錄的生命周期結(jié)束時(shí)間;t_end_date
= '9999-12-31' 表示該條記錄目前處于有效狀態(tài);- 如果查詢當(dāng)前所有有效的記錄,則
select * from user where t_end_date = '9999-12-31'
- 如果查詢
2017-01-01
的歷史快照,則select * from user where t_start_date <= '2017-01-01' and end_date >= '2017-01-01'
,這條語(yǔ)句會(huì)查詢到以下記錄:
拉鏈表的使用場(chǎng)景
在數(shù)據(jù)倉(cāng)庫(kù)的數(shù)據(jù)模型設(shè)計(jì)過(guò)程中,經(jīng)常會(huì)遇到下面這種表的設(shè)計(jì):
- 有一些表的數(shù)據(jù)量很大,比如一張用戶表,大約10億條記錄,50個(gè)字段,這種表,即使使用ORC壓縮,單張表的存儲(chǔ)也會(huì)超過(guò)100G,在HDFS使用雙備份或者三備份的話就更大一些。
- 表中的部分字段會(huì)被update更新操作,如用戶聯(lián)系方式,產(chǎn)品的描述信息,訂單的狀態(tài)等等。
- 需要查看某一個(gè)時(shí)間點(diǎn)或者時(shí)間段的歷史快照信息,比如,查看某一個(gè)訂單在歷史某一個(gè)時(shí)間點(diǎn)的狀態(tài)。
- 表中的記錄變化的比例和頻率不是很大,比如,總共有10億的用戶,每天新增和發(fā)生變化的有200萬(wàn)左右,變化的比例占的很小。
對(duì)于這種表的設(shè)計(jì)?下面有幾種方案可選:
- 方案一:每天只留最新的一份,比如我們每天用datax抽取最新的一份全量數(shù)據(jù)到Hive中。
- 方案二:每天保留一份全量的切片數(shù)據(jù)。
- 方案三:使用拉鏈表。
為什么使用拉鏈表
方案一:每天只留最新的一份
這種方案就不用多說(shuō)了,實(shí)現(xiàn)起來(lái)很簡(jiǎn)單,每天drop掉前一天的數(shù)據(jù),重新抽一份最新的。
優(yōu)點(diǎn)很明顯,節(jié)省空間,一些普通的使用也很方便,不用在選擇表的時(shí)候加一個(gè)時(shí)間分區(qū)什么的。
缺點(diǎn)同樣明顯,沒(méi)有歷史數(shù)據(jù),先翻翻舊賬只能通過(guò)其它方式,比如從流水表里面抽。
方案二:每天保留一份全量的切片數(shù)據(jù)
每天一份全量的切片是一種比較穩(wěn)妥的方案,而且歷史數(shù)據(jù)也在。
缺點(diǎn)就是存儲(chǔ)空間占用量太大太大了,如果對(duì)這邊表每天都保留一份全量,那么每次全量中會(huì)保存很多不變的信息,對(duì)存儲(chǔ)是極大的浪費(fèi)。
當(dāng)然我們也可以做一些取舍,比如只保留近一個(gè)月的數(shù)據(jù)?但是,需求是無(wú)恥的,數(shù)據(jù)的生命周期不是我們能完全左右的。
方案三:拉鏈表
拉鏈表在使用上基本兼顧了我們的需求。
首先它在空間上做了一個(gè)取舍,雖說(shuō)不像方案一那樣占用量那么小,但是它每日的增量可能只有方案二的千分之一甚至是萬(wàn)分之一。
其實(shí)它能滿足方案二所能滿足的需求,既能獲取最新的數(shù)據(jù),也能添加篩選條件也獲取歷史的數(shù)據(jù)。
所以我們還是很有必要來(lái)使用拉鏈表的。
拉鏈表的設(shè)計(jì)
在Mysql
關(guān)系型數(shù)據(jù)庫(kù)里的user
表中信息變化
在2017-01-01
表中的數(shù)據(jù)是:
在2017-01-02
表中的數(shù)據(jù)是,用戶002
和004
資料進(jìn)行了修改,005
是新增用戶:
在2017-01-03
表中的數(shù)據(jù)是,用戶004
和005
資料進(jìn)行了修改,006
是新增用戶:
如果在數(shù)據(jù)倉(cāng)庫(kù)中設(shè)計(jì)成歷史拉鏈表保存該表,則會(huì)有下面這樣一張表,這是最新一天(即2017-01-03)的數(shù)據(jù):
說(shuō)明:
t_start_date
表示該條記錄的生命周期開(kāi)始時(shí)間,t_end_date
表示該條記錄的生命周期結(jié)束時(shí)間;t_end_date = '9999-12-31'
表示該條記錄目前處于有效狀態(tài);- 如果查詢當(dāng)前所有有效的記錄,則
select * from user where t_end_date = '9999-12-31'
- 如果查詢
2017-01-01
的歷史快照,則select * from user where t_start_date <= ‘2017-01-01′ and end_date >= '2017-01-01'
。
拉鏈表的實(shí)現(xiàn)與更新
Hive中實(shí)現(xiàn)拉鏈表
- 我們需要一張
ODS
層的用戶全量表。至少需要用它來(lái)初始化。 - 每日的用戶更新表。
- 我們需要一張
而且我們要確定拉鏈表的時(shí)間粒度,比如說(shuō)拉鏈表每天只取一個(gè)狀態(tài),也就是說(shuō)如果一天有3個(gè)狀態(tài)變更,我們只取最后一個(gè)狀態(tài),這種天粒度的表其實(shí)已經(jīng)能解決大部分的問(wèn)題了。
獲取每日的用戶增量
監(jiān)聽(tīng)Mysql
數(shù)據(jù)的變化,比如說(shuō)用Canal
,最后合并每日的變化,獲取到最后的一個(gè)狀態(tài)。
假設(shè)我們每天都會(huì)獲得一份切片數(shù)據(jù),我們可以通過(guò)取兩天切片數(shù)據(jù)的不同來(lái)作為每日更新表,這種情況下我們可以對(duì)所有的字段先進(jìn)行concat
,再取md5
,這樣就ok了。
流水表,有每日的變更流水表
表結(jié)構(gòu)
ods
層的user
表
ods
層的user_update
表
拉鏈表
更新
假設(shè)已經(jīng)初始化了2017-01-01
的日期,然后需要更新2017-01-02
那一天的數(shù)據(jù)
補(bǔ)充
拉鏈表和流水表
流水表存放的是一個(gè)用戶的變更記錄,比如在一張流水表中,一天的數(shù)據(jù)中,會(huì)存放一個(gè)用戶的每條修改記錄,但是在拉鏈表中只有一條記錄。
這是拉鏈表設(shè)計(jì)時(shí)需要注意的一個(gè)粒度問(wèn)題。我們當(dāng)然也可以設(shè)置的粒度更小一些,一般按天就足夠。
拉鏈表性能優(yōu)化
拉鏈表當(dāng)然也會(huì)遇到查詢性能的問(wèn)題,比如說(shuō)我們存放了5年的拉鏈數(shù)據(jù),那么這張表勢(shì)必會(huì)比較大,當(dāng)查詢的時(shí)候性能就比較低了,個(gè)人認(rèn)為兩個(gè)思路來(lái)解決:
- 在一些查詢引擎中,我們對(duì)start_date和end_date做索引,這樣能提高不少性能。
- 保留部分歷史數(shù)據(jù),比如說(shuō)我們一張表里面存放全量的拉鏈表數(shù)據(jù),然后再對(duì)外暴露一張只提供近3個(gè)月數(shù)據(jù)的拉鏈表。
作者:柯廣的網(wǎng)絡(luò)日志
微信公眾號(hào):Java大數(shù)據(jù)與數(shù)據(jù)倉(cāng)庫(kù)