作者：螞蟻金服數(shù)據(jù)中臺(tái)技術(shù)專家－王飛（必武）
整理:平凡的世界-zkx,轉(zhuǎn)載請(qǐng)注明出處告丢。
第一節(jié)會(huì)介紹一下數(shù)據(jù)倉(cāng)庫(kù)的基本理論
第二節(jié)給大家介紹一下基于spark多數(shù)據(jù)源的集成，
第三節(jié)給大家介紹基于SparkSQL里面對(duì)數(shù)倉(cāng)進(jìn)行OLAP的分析
希望大家?guī)е鴨栴}去看本博客的內(nèi)容?
1.我們所有的系統(tǒng)都是圍繞業(yè)務(wù)去解決問題的损谦，從一些業(yè)務(wù)不同的視角岖免，業(yè)務(wù)的視角,所看到的問題是不一樣的。
比如照捡，傳統(tǒng)數(shù)據(jù)庫(kù)解決的是什么樣的業(yè)務(wù)問題?數(shù)據(jù)倉(cāng)庫(kù)又是解決什么樣的問題?數(shù)據(jù)倉(cāng)庫(kù)和在傳統(tǒng)數(shù)據(jù)庫(kù)在形式上有較大的類似,
很多時(shí)候颅湘，都是使用sql語句對(duì)數(shù)據(jù)進(jìn)行操作，但是他們的區(qū)別本質(zhì)到底是什么呢?這個(gè)話題我們可以展開和大家聊一下栗精。
2.第二個(gè)問題希望大家聽完這節(jié)課闯参，對(duì)數(shù)據(jù)倉(cāng)庫(kù)的基礎(chǔ)架構(gòu)有大致的了解，不同的核心模塊使用哪些技術(shù)棧悲立，業(yè)務(wù)模型是什么樣子的?該怎么去設(shè)計(jì)模型?
3.第三個(gè)問題希望大家去了解一下spark構(gòu)建數(shù)據(jù)倉(cāng)庫(kù)的核心能力鹿寨，和數(shù)據(jù)倉(cāng)庫(kù)的哪些核心組件核心能力的要求是比較match的？方便進(jìn)行技術(shù)選型薪夕。
4.如何使用Spark Core/Streaming去擴(kuò)展數(shù)據(jù)倉(cāng)庫(kù)的多個(gè)數(shù)據(jù)源脚草。
5.如何使用Spark進(jìn)行OLAP? 除了sparksql還有哪些可以進(jìn)行OLAP？
image.png
image.png
介紹數(shù)據(jù)倉(cāng)庫(kù)的基本理論寥殖，1991年 數(shù)據(jù)倉(cāng)庫(kù)之父 比爾恩門 下過這樣一個(gè)定義玩讳，這個(gè)定義是比較受大家廣泛接受的這樣一個(gè)定義涩蜘。用幾個(gè)關(guān)鍵詞描述了數(shù)據(jù)倉(cāng)庫(kù)?面向主題和集成的這幾個(gè)關(guān)鍵詞其實(shí)是描述了一個(gè)數(shù)據(jù)的特征嚼贡，最后一個(gè)支持管理決策，介紹了一個(gè)數(shù)據(jù)倉(cāng)庫(kù)的一個(gè)使用場(chǎng)景同诫。
image.png
面向主題跟傳統(tǒng)的數(shù)據(jù)庫(kù)相比的一個(gè)特征粤策，傳統(tǒng)數(shù)據(jù)庫(kù)主要用的是OLTP的數(shù)據(jù)處理方式(聯(lián)機(jī)事務(wù)處理方式)，
OLTP要求數(shù)據(jù)倉(cāng)庫(kù)使用的是OLAP(聯(lián)機(jī)分析處理方式)，OLTP在處理的時(shí)候伴郁，側(cè)重于事務(wù)的特性送膳，要求數(shù)據(jù)操作的原子性东揣，一致性等等稳其。
所進(jìn)行的操作是具體的action,一個(gè)行為皂股，而數(shù)據(jù)倉(cāng)庫(kù)使用的OLAP做聯(lián)機(jī)分析的時(shí)候界弧，面向的是一個(gè)主題伟阔，是一個(gè)分析的話題愈魏，
比如想分析整個(gè)商品相連的趨勢(shì)觅玻，相當(dāng)于確定了一個(gè)主題，主題的主體就是商品培漏，內(nèi)容就是往年的相當(dāng)?shù)内厔?shì),圍繞整個(gè)主題溪厘，
構(gòu)建整個(gè)OLAP所需要的數(shù)據(jù),拿出來分析，最終達(dá)到一個(gè)結(jié)果牌柄。首先這個(gè)是面向主題畸悬，代表了對(duì)數(shù)據(jù)的處理方式,要的結(jié)果不同而定義的，
image.png
由于我們面向于一個(gè)主題做數(shù)據(jù)分析的時(shí)候珊佣，往往要需要多個(gè)數(shù)據(jù)源蹋宦，不同的數(shù)據(jù)源，不同的業(yè)務(wù)系統(tǒng)數(shù)據(jù)合并到一起
日志咒锻，業(yè)務(wù)系統(tǒng)數(shù)據(jù)妆档，數(shù)據(jù)的定義是全局的，要保證數(shù)據(jù)的一致性虫碉，無法放到一起進(jìn)行數(shù)據(jù)分析贾惦。
比如會(huì)員系統(tǒng)，交易系統(tǒng)敦捧，商品瀏覽系統(tǒng)须板，3個(gè)不同的業(yè)務(wù)系統(tǒng)，3個(gè)系統(tǒng)合并到一起兢卵，來分析用戶日常的消費(fèi)行為习瑰。
在不同的系統(tǒng)中，對(duì)用戶定義的字段是不一樣的秽荤，有的是ID甜奄，有的可能是名字，有的可能是其他的來定義用戶
窃款，在把這些數(shù)據(jù)進(jìn)行整合的時(shí)候课兄，那我們就需要全局的用戶定義,全局統(tǒng)一的用戶定義來描述用戶的信息
多個(gè)系統(tǒng)對(duì)數(shù)據(jù)定義的時(shí)候，要求數(shù)據(jù)是全局統(tǒng)一的晨继，如果沒有全局統(tǒng)一的數(shù)據(jù)是很難關(guān)聯(lián)起來的烟阐。
image.png
image.png
相對(duì)穩(wěn)定是傳統(tǒng)數(shù)倉(cāng)比較明顯的特征，以前的數(shù)據(jù)，因?yàn)閿?shù)據(jù)都是通過在線系統(tǒng)清洗出來的蜒茄，
它不需要插入唉擂，和頻繁的update,數(shù)據(jù)時(shí)效性要求不高。當(dāng)前互聯(lián)網(wǎng)的發(fā)展檀葛，當(dāng)前的T+1離線分析場(chǎng)景以及不能滿足了玩祟。
當(dāng)前數(shù)據(jù)對(duì)時(shí)效性要求是挺高的，最近流行的流批都是解決數(shù)據(jù)時(shí)效性的問題屿聋。 比如lambad kappa架構(gòu)卵凑。
時(shí)效性現(xiàn)在已經(jīng)足夠的打破了。
image.png
image.png
image.png
image.png
image.png
image.png
image.png
image.png
image.png
image.png
image.png
image.png
image.png
image.png
image.png
image.png
image.png
image.png
image.png
image.png
image.png
image.png
image.png
image.png
image.png
sparkstreaming通過時(shí)間驅(qū)動(dòng)的胜臊，通過傳入時(shí)間參數(shù)勺卢，返回這個(gè)時(shí)間階段的RDD。
image.png
image.png
image.png
image.png
image.png
image.png
image.png
對(duì)sql解析,生成邏輯計(jì)劃和物理計(jì)劃象对，未解析的 解析后的 優(yōu)化后的 可執(zhí)行的物理計(jì)劃,catalog是構(gòu)建數(shù)據(jù)的元數(shù)據(jù)(數(shù)據(jù)源 udf 表結(jié)構(gòu)的所有信息)
image.png
這節(jié)課請(qǐng)大家搞清這倆問題哈～
哪些操作是窄依賴?
數(shù)倉(cāng)的特性有哪些?
問題總結(jié):
1.write接口包含什么?
write接口包含Append Overwrite Ignore等等黑忱；
2.Catalyst優(yōu)化的API開發(fā)的Spark任務(wù)包含什么?
優(yōu)化的API開發(fā)的Spark任務(wù)包含DataFrame SQL DataSet等等
3.spark sql適合復(fù)雜的ETL分層的邏輯么。我看好多都是用hive寫的勒魔。
答：你指的分層具體指什么甫煞，中間表臨時(shí)表嘛?
追問:是的，ODS->DWD->DWS-ADM中的處理邏輯?
答： ODS->DWD->DWS->ADM 描述的是數(shù)據(jù)的分層冠绢，是為了方便進(jìn)行數(shù)據(jù)管理的抚吠，更偏理論；實(shí)際應(yīng)用的時(shí)候其實(shí)概念并不是 太強(qiáng)弟胀；SQL 只是用來連接表與表之間的計(jì)算關(guān)系楷力，和實(shí)現(xiàn)這個(gè)數(shù)據(jù)分層并沒有直接關(guān)系。
4.現(xiàn)在經(jīng)常提到的數(shù)據(jù)中臺(tái)和數(shù)倉(cāng)之間是怎樣的關(guān)系孵户？
側(cè)重點(diǎn)不一樣萧朝，中臺(tái)更強(qiáng)調(diào)服務(wù)，是業(yè)務(wù)和數(shù)據(jù)的連接層
5.A:從etl到事實(shí)表維表過程中夏哭，etl的結(jié)果也會(huì)在數(shù)倉(cāng)中嗎检柬？ 那對(duì)于數(shù)據(jù)源表新增字段等，有什么解決辦法嗎竖配？
B:其實(shí)你問了一個(gè)比較細(xì)節(jié)的技術(shù)問題何址，表結(jié)構(gòu)變化了，原始數(shù)據(jù)怎么處理进胯；其實(shí)這個(gè)要看具體的存儲(chǔ)模塊能不能解決了用爪；新增字段這種場(chǎng)景下，如何能夠兼容老的數(shù)據(jù)結(jié)構(gòu)（新增字段自動(dòng)填充null）龄减，就可以解決项钮；
A:那碰到復(fù)雜的ETL邏輯的時(shí)候班眯，比如說生成大寬表的時(shí)候希停，通常都是上百個(gè)字段烁巫，那spark sql適用這類的復(fù)雜邏輯么？
B:看你自己接受程度吧宠能，理論上SQL是能夠表達(dá)的亚隙，但是處理太過復(fù)雜；我們自己的場(chǎng)景下就有100+字段的數(shù)據(jù)违崇，但是我們不是用的SQL阿弃，我們自己定義的一套計(jì)算模型；模型化的數(shù)據(jù)可以使用程序自動(dòng)生成羞延，對(duì)于這種上百列的數(shù)據(jù)任務(wù)處理起來會(huì)更容易一點(diǎn)渣淳；
6.A:spark sql能否實(shí)現(xiàn)表結(jié)構(gòu)的合并、基于原有屬性派生新屬性等較復(fù)雜的數(shù)據(jù)轉(zhuǎn)換操作伴箩？B:自定義 UDF 能解決你的這個(gè)問題嗎?
A:在spark中能基于ETL后的數(shù)據(jù)構(gòu)建多維數(shù)據(jù)集嗎入愧？
B：多維數(shù)據(jù)集具體是指什么樣的形式呢，能具體解釋一下嗎
A:微軟的SSAS能構(gòu)建多維數(shù)據(jù)集嗤谚，多維數(shù)據(jù)集的形式就是您前面講的星型模型或雪花模型棺蛛，多維數(shù)據(jù)集中的數(shù)據(jù)以多維的形式而不只是二維的形式展示
B：時(shí)間+多維+事實(shí)列 構(gòu)成了多維數(shù)據(jù)模型，數(shù)據(jù)處理的方式還是用 SQL 進(jìn)行的
7.A:關(guān)于元數(shù)據(jù)管理巩步，有哪些比較好的方案嗎旁赊？
B： 你指的是維表數(shù)據(jù)，還是表信息相關(guān)的元數(shù)據(jù)?
A：表信息相關(guān)的元數(shù)據(jù)椅野。
B：spark 默認(rèn)提供了 Hive 的元數(shù)據(jù)终畅，可以直接基于 Hive 管理元數(shù)據(jù)；
如果你是想自己管理元數(shù)據(jù)的話竟闪，很復(fù)雜声离，看你們自己的業(yè)務(wù)需要，投入產(chǎn)出比瘫怜；
A：人為地去理解术徊，把這三部分看成多維數(shù)據(jù)模型吧？
B：我是這么理解的鲸湃，可能還要看具體的數(shù)據(jù)場(chǎng)景吧
8.增量ETL時(shí)赠涮，處理源數(shù)據(jù)刪除的數(shù)據(jù)有什么思路嗎？
B： 這是個(gè)數(shù)據(jù)建模的問題暗挑；如果你的數(shù)據(jù)是操作型的數(shù)據(jù)笋除，可以把操作類型作為一個(gè)維度進(jìn)行管理；計(jì)算分析的時(shí)候把操作類型作為選擇分析方式的一個(gè)條件
A： 這個(gè)可以理解為炸裆，要修改etl處理source部分的處理邏輯嗎垃它？
B： 我沒實(shí)際處理過這種問題；只能是探討一下，原始數(shù)據(jù)是操作類型的數(shù)據(jù)国拇，包含了刪除等動(dòng)作洛史，在構(gòu)建 明細(xì)表的時(shí)候，就可以是 以這種流水型的數(shù)據(jù)進(jìn)行建模酱吝；創(chuàng)建一條記錄->更新有一條記錄->刪除一條記錄也殖；根據(jù)行為進(jìn)行數(shù)據(jù)的計(jì)算分析；
