作者：螞蟻金服數(shù)據(jù)中臺技術(shù)專家－王飛（必武）
整理:平凡的世界-zkx,轉(zhuǎn)載請注明出處。
第一節(jié)會介紹一下數(shù)據(jù)倉庫的基本理論
第二節(jié)給大家介紹一下基于spark多數(shù)據(jù)源的集成，
第三節(jié)給大家介紹基于SparkSQL里面對數(shù)倉進(jìn)行OLAP的分析
希望大家?guī)е鴨栴}去看本博客的內(nèi)容?
1.我們所有的系統(tǒng)都是圍繞業(yè)務(wù)去解決問題的，從一些業(yè)務(wù)不同的視角，業(yè)務(wù)的視角,所看到的問題是不一樣的。
比如，傳統(tǒng)數(shù)據(jù)庫解決的是什么樣的業(yè)務(wù)問題?數(shù)據(jù)倉庫又是解決什么樣的問題?數(shù)據(jù)倉庫和在傳統(tǒng)數(shù)據(jù)庫在形式上有較大的類似,
很多時候，都是使用sql語句對數(shù)據(jù)進(jìn)行操作，但是他們的區(qū)別本質(zhì)到底是什么呢?這個話題我們可以展開和大家聊一下。
2.第二個問題希望大家聽完這節(jié)課，對數(shù)據(jù)倉庫的基礎(chǔ)架構(gòu)有大致的了解，不同的核心模塊使用哪些技術(shù)棧，業(yè)務(wù)模型是什么樣子的?該怎么去設(shè)計模型?
3.第三個問題希望大家去了解一下spark構(gòu)建數(shù)據(jù)倉庫的核心能力，和數(shù)據(jù)倉庫的哪些核心組件核心能力的要求是比較match的？方便進(jìn)行技術(shù)選型。
4.如何使用Spark Core/Streaming去擴(kuò)展數(shù)據(jù)倉庫的多個數(shù)據(jù)源。
5.如何使用Spark進(jìn)行OLAP? 除了sparksql還有哪些可以進(jìn)行OLAP？
image.png
image.png
介紹數(shù)據(jù)倉庫的基本理論，1991年 數(shù)據(jù)倉庫之父 比爾恩門 下過這樣一個定義，這個定義是比較受大家廣泛接受的這樣一個定義。用幾個關(guān)鍵詞描述了數(shù)據(jù)倉庫?面向主題和集成的這幾個關(guān)鍵詞其實是描述了一個數(shù)據(jù)的特征，最后一個支持管理決策，介紹了一個數(shù)據(jù)倉庫的一個使用場景。
image.png
面向主題跟傳統(tǒng)的數(shù)據(jù)庫相比的一個特征，傳統(tǒng)數(shù)據(jù)庫主要用的是OLTP的數(shù)據(jù)處理方式(聯(lián)機(jī)事務(wù)處理方式)，
OLTP要求數(shù)據(jù)倉庫使用的是OLAP(聯(lián)機(jī)分析處理方式)，OLTP在處理的時候，側(cè)重于事務(wù)的特性，要求數(shù)據(jù)操作的原子性，一致性等等。
所進(jìn)行的操作是具體的action,一個行為，而數(shù)據(jù)倉庫使用的OLAP做聯(lián)機(jī)分析的時候，面向的是一個主題，是一個分析的話題，
比如想分析整個商品相連的趨勢，相當(dāng)于確定了一個主題，主題的主體就是商品，內(nèi)容就是往年的相當(dāng)?shù)内厔?圍繞整個主題，
構(gòu)建整個OLAP所需要的數(shù)據(jù),拿出來分析，最終達(dá)到一個結(jié)果。首先這個是面向主題，代表了對數(shù)據(jù)的處理方式,要的結(jié)果不同而定義的，
image.png
由于我們面向于一個主題做數(shù)據(jù)分析的時候，往往要需要多個數(shù)據(jù)源，不同的數(shù)據(jù)源，不同的業(yè)務(wù)系統(tǒng)數(shù)據(jù)合并到一起
日志，業(yè)務(wù)系統(tǒng)數(shù)據(jù)，數(shù)據(jù)的定義是全局的，要保證數(shù)據(jù)的一致性，無法放到一起進(jìn)行數(shù)據(jù)分析。
比如會員系統(tǒng)，交易系統(tǒng)，商品瀏覽系統(tǒng)，3個不同的業(yè)務(wù)系統(tǒng)，3個系統(tǒng)合并到一起，來分析用戶日常的消費行為。
在不同的系統(tǒng)中，對用戶定義的字段是不一樣的，有的是ID，有的可能是名字，有的可能是其他的來定義用戶
，在把這些數(shù)據(jù)進(jìn)行整合的時候，那我們就需要全局的用戶定義,全局統(tǒng)一的用戶定義來描述用戶的信息
多個系統(tǒng)對數(shù)據(jù)定義的時候，要求數(shù)據(jù)是全局統(tǒng)一的，如果沒有全局統(tǒng)一的數(shù)據(jù)是很難關(guān)聯(lián)起來的。
image.png
image.png
相對穩(wěn)定是傳統(tǒng)數(shù)倉比較明顯的特征，以前的數(shù)據(jù)，因為數(shù)據(jù)都是通過在線系統(tǒng)清洗出來的，
它不需要插入，和頻繁的update,數(shù)據(jù)時效性要求不高。當(dāng)前互聯(lián)網(wǎng)的發(fā)展，當(dāng)前的T+1離線分析場景以及不能滿足了。
當(dāng)前數(shù)據(jù)對時效性要求是挺高的，最近流行的流批都是解決數(shù)據(jù)時效性的問題。 比如lambad kappa架構(gòu)。
時效性現(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通過時間驅(qū)動的，通過傳入時間參數(shù)，返回這個時間階段的RDD。
image.png
image.png
image.png
image.png
image.png
image.png
image.png
對sql解析,生成邏輯計劃和物理計劃，未解析的 解析后的 優(yōu)化后的 可執(zhí)行的物理計劃,catalog是構(gòu)建數(shù)據(jù)的元數(shù)據(jù)(數(shù)據(jù)源 udf 表結(jié)構(gòu)的所有信息)
image.png
這節(jié)課請大家搞清這倆問題哈～
哪些操作是窄依賴?
數(shù)倉的特性有哪些?
問題總結(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寫的。
答：你指的分層具體指什么，中間表臨時表嘛?
追問:是的，ODS->DWD->DWS-ADM中的處理邏輯?
答： ODS->DWD->DWS->ADM 描述的是數(shù)據(jù)的分層，是為了方便進(jìn)行數(shù)據(jù)管理的，更偏理論；實際應(yīng)用的時候其實概念并不是 太強(qiáng)；SQL 只是用來連接表與表之間的計算關(guān)系，和實現(xiàn)這個數(shù)據(jù)分層并沒有直接關(guān)系。
4.現(xiàn)在經(jīng)常提到的數(shù)據(jù)中臺和數(shù)倉之間是怎樣的關(guān)系？
側(cè)重點不一樣，中臺更強(qiáng)調(diào)服務(wù)，是業(yè)務(wù)和數(shù)據(jù)的連接層
5.A:從etl到事實表維表過程中，etl的結(jié)果也會在數(shù)倉中嗎？ 那對于數(shù)據(jù)源表新增字段等，有什么解決辦法嗎？
B:其實你問了一個比較細(xì)節(jié)的技術(shù)問題，表結(jié)構(gòu)變化了，原始數(shù)據(jù)怎么處理；其實這個要看具體的存儲模塊能不能解決了；新增字段這種場景下，如何能夠兼容老的數(shù)據(jù)結(jié)構(gòu)（新增字段自動填充null），就可以解決；
A:那碰到復(fù)雜的ETL邏輯的時候，比如說生成大寬表的時候，通常都是上百個字段，那spark sql適用這類的復(fù)雜邏輯么？
B:看你自己接受程度吧，理論上SQL是能夠表達(dá)的，但是處理太過復(fù)雜；我們自己的場景下就有100+字段的數(shù)據(jù)，但是我們不是用的SQL，我們自己定義的一套計算模型；模型化的數(shù)據(jù)可以使用程序自動生成，對于這種上百列的數(shù)據(jù)任務(wù)處理起來會更容易一點；
6.A:spark sql能否實現(xiàn)表結(jié)構(gòu)的合并、基于原有屬性派生新屬性等較復(fù)雜的數(shù)據(jù)轉(zhuǎn)換操作？B:自定義 UDF 能解決你的這個問題嗎?
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：時間+多維+事實列 構(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ù)場景吧
8.增量ETL時，處理源數(shù)據(jù)刪除的數(shù)據(jù)有什么思路嗎？
B： 這是個數(shù)據(jù)建模的問題；如果你的數(shù)據(jù)是操作型的數(shù)據(jù)，可以把操作類型作為一個維度進(jìn)行管理；計算分析的時候把操作類型作為選擇分析方式的一個條件
A： 這個可以理解為，要修改etl處理source部分的處理邏輯嗎？
B： 我沒實際處理過這種問題；只能是探討一下，原始數(shù)據(jù)是操作類型的數(shù)據(jù)，包含了刪除等動作，在構(gòu)建 明細(xì)表的時候，就可以是 以這種流水型的數(shù)據(jù)進(jìn)行建模；創(chuàng)建一條記錄->更新有一條記錄->刪除一條記錄；根據(jù)行為進(jìn)行數(shù)據(jù)的計算分析；
