ETL工程师知识点
前言
由于筆者很榮幸的參與了目前所在公司的登月計(jì)劃,整個(gè)登月計(jì)劃過(guò)程中收獲也頗豐,在此之前,完全沒(méi)有和數(shù)據(jù)打交道的經(jīng)驗(yàn),所以一些基本問(wèn)題需要總結(jié)出來(lái),以供自己日后參考;
1、作為一名開(kāi)發(fā)人員,我們不僅要懂得技術(shù)的實(shí)現(xiàn)要點(diǎn),也需要懂得自己所處工作組的業(yè)務(wù)邏輯;
2、作為處理數(shù)據(jù)的工程師,不僅要懂得寫基本的SQL,還需要懂得怎么去用日常的許多基本工具;
3、作為數(shù)據(jù)開(kāi)發(fā)和同步人員,我們往往有必要懂得如何分析基本的數(shù)據(jù);
正文
1、同步數(shù)據(jù)的過(guò)程中,有sa層數(shù)據(jù)、sda層數(shù)據(jù)、rda層數(shù)據(jù),那么這三種數(shù)據(jù)層的差異在哪里?
首先,簡(jiǎn)單說(shuō)明一下數(shù)據(jù)來(lái)源,sa層的數(shù)據(jù)來(lái)源于sqoop直接抽取mysql數(shù)據(jù)庫(kù)的數(shù)據(jù),屬于一個(gè)全量的非實(shí)時(shí)的數(shù)據(jù);
sda層數(shù)據(jù)則是結(jié)合了sa層數(shù)據(jù)+binlog操作日志,組合成為了一個(gè)全量的t-1的實(shí)時(shí)數(shù)據(jù);
binlog數(shù)據(jù)來(lái)源,通過(guò)阿里的開(kāi)源框架canal,模仿mysql slave的交互協(xié)議,偽裝自己為mysql slave,向mysql master發(fā)送dump協(xié)議,從而收集binary log給slave,得到binlog的字節(jié)流日志;
目前同步方式為binlog->Kafka->Spark Streaming->hdfs->Impala刷新;
rda層數(shù)據(jù)=sda的t-1數(shù)據(jù)+binlog的t數(shù)據(jù),組合成為一個(gè)全量的實(shí)時(shí)數(shù)據(jù),保證業(yè)務(wù)方使用到的數(shù)據(jù)都是實(shí)時(shí)的;
2、為什么會(huì)有這么多層數(shù)據(jù)產(chǎn)生,sda層相對(duì)于sa層解決了什么,rda層相對(duì)于sda層的優(yōu)點(diǎn)又在哪里?
(1)sda層數(shù)據(jù)的出現(xiàn),主要是因?yàn)橥ㄟ^(guò)sqoop抽取的sa數(shù)據(jù),可能會(huì)因?yàn)閟qoop進(jìn)程啟動(dòng)的時(shí)候晚了10分鐘,導(dǎo)致最終sa的數(shù)據(jù),可能是t-2的數(shù)據(jù)加上多余10分鐘的數(shù)據(jù);
為了解決這多處10分鐘的數(shù)據(jù)問(wèn)題,我們加上binlog的t-1的數(shù)據(jù),由于binlog只取最新的數(shù)據(jù),所以即使sa有多余10分鐘的數(shù)據(jù),也最終會(huì)被binlog最新的數(shù)據(jù)給替換,所以組成全新的完整的沒(méi)有多余數(shù)據(jù)的t-1數(shù)據(jù);
(2)rda層相對(duì)于sda層數(shù)據(jù)的優(yōu)點(diǎn)在于它是一個(gè)實(shí)時(shí)(t)的數(shù)據(jù),同樣用sda層數(shù)據(jù)+binlog數(shù)據(jù),是為了避免多余10分鐘數(shù)據(jù)的情況出現(xiàn),由sda+binlog的數(shù)據(jù),又能保證數(shù)據(jù)是實(shí)時(shí)的數(shù)據(jù);
3、hue平臺(tái)的使用總結(jié),我們?cè)诤芏鄷r(shí)候會(huì)通過(guò)hue添加一些大數(shù)據(jù)組件,其中就有hive和impala,那么兩者的區(qū)別和各自優(yōu)勢(shì)?
在底層表結(jié)構(gòu)和數(shù)據(jù)變更的時(shí)候,hive的實(shí)時(shí)響應(yīng)比impala要快很多,所以如果剛剛同步完一張表,如果沒(méi)有進(jìn)行refresh或者INVALIDATE METADATA的話,那么hive可能很快能查得到這張表的表結(jié)構(gòu)和同步數(shù)據(jù),而impala需要幾分鐘以后才能開(kāi)始使用這張表;
impala的查數(shù)速度快于hive,這是因?yàn)閔ive的底層查數(shù)使用緩慢的MapReduce批處理,而impala直接從HDFS或HBase中用SELECT、JOIN和統(tǒng)計(jì)函數(shù)查詢數(shù)據(jù),大大降低了延遲;
4、表結(jié)構(gòu)變更和表數(shù)據(jù)刷新:refresh table、INVALIDATE METADATA;
5、在刪除表的時(shí)候出現(xiàn)外健級(jí)聯(lián)的時(shí)候,無(wú)法drop table之后:
SET foreign_key_checks = 0; // 先設(shè)置外鍵約束檢查關(guān)閉
drop table table1; // 刪除表,如果要?jiǎng)h除視圖,也是如此
SET foreign_key_checks = 1; // 開(kāi)啟外鍵約束檢查,以保持表結(jié)構(gòu)完整性
6、union all的用法:
select count(*) from test.table where etl_tx_dt=20181226 union all
select count(*) from test.table1 where etl_tx_dt=20181226 union all
select count(*) from test.table2 where etl_tx_dt=20181226 union all
.......
7、刪除表分區(qū)、顯示表所有分區(qū):
alter table test.table drop partition (etl_tx_dt='2019-02-27');
show partitions test.table1;
8、sql驗(yàn)數(shù)的經(jīng)驗(yàn)分析:
(1)計(jì)算字段的時(shí)候,int、bigint、decimal類型的字段用sum,string、timestamp類型的用count;
(2)當(dāng)某張表出現(xiàn)數(shù)據(jù)條數(shù)不對(duì)的時(shí)候,首先要檢查基礎(chǔ)表數(shù)據(jù)條數(shù)對(duì)不對(duì);
(3)當(dāng)總條數(shù)對(duì)上,字段條數(shù)對(duì)上以后,需要去底層分析哪一個(gè)字段出現(xiàn)不對(duì),有可能是因?yàn)椴煌钠脚_(tái),同步數(shù)據(jù)的方式不同,假設(shè)a平臺(tái)的數(shù)據(jù)默認(rèn)null和''為空,都計(jì)算為一個(gè)字段,而b平臺(tái)同步完以后,只計(jì)算null的條數(shù),而不計(jì)算''的條數(shù),這就會(huì)導(dǎo)致某一個(gè)字段同步完以后,條數(shù)對(duì)應(yīng)不上;
解決辦法:case when xxx='' then null end as xxx ;
(4)當(dāng)null也對(duì)的上的時(shí)候,就需要去定位id,逐步縮小數(shù)據(jù)失誤的范圍,最終找到某條id的數(shù)據(jù),如:
9、較驗(yàn)數(shù)據(jù)時(shí)候,核對(duì)字段的統(tǒng)計(jì)策略:
(1)數(shù)值類型的都用sum,如:int、bigint、decimal(38,4);
(2)非數(shù)值類型的用count,如:string;
參考資料
轉(zhuǎn)載于:https://www.cnblogs.com/haoxinchen/p/10459432.html
總結(jié)
- 上一篇: MySQL 查询重复数据,删除重复数据保
- 下一篇: 一个函数让你看懂 'Why 0.1+0.