數(shù)倉架構(gòu)發(fā)展史
本文大綱
發(fā)展史
時代的變遷，生死的輪回，歷史長河滔滔，沒有什么是永恒的，只有變化才是不變的，技術(shù)亦是如此，當(dāng)你選擇互聯(lián)網(wǎng)的那一刻，你就相當(dāng)于乘坐了一個滾滾向前的時代列車，開往未知的方向，不論什么樣的技術(shù)架構(gòu)只有放在當(dāng)前的時代背景下，才是有意義的，人生亦是如此。
時間就是一把尺子，它能衡量奮斗者前進(jìn)的進(jìn)程；時間就是一架天平，它能衡量奮斗者成果的重量；時間就是一架穿梭機(jī)，它能帶我們遨游歷史長河,今天我們看一下數(shù)倉架構(gòu)的發(fā)展，來感受一下歷史的變遷，回頭看一下那些曾經(jīng)的遺跡。準(zhǔn)備好了嗎 let's go!，在此之前我們先看一下，數(shù)據(jù)倉庫在整個數(shù)據(jù)平臺中的地位。
開始之前，我們先上一張大圖，先有一個大概的認(rèn)知，從整體到局部從概括到具體，看一下導(dǎo)致機(jī)構(gòu)變化的原因是什么，探究一下時代背景下的意義，我們順便看一下什么是數(shù)倉。
那么什么是數(shù)倉，數(shù)據(jù)倉庫是一個面向主題的（Subject Oriented）、集成的（Integrate）、相對穩(wěn)定的（Non-Volatile）、反映歷史變化（Time Variant）的數(shù)據(jù)集合，用于支持管理決策，數(shù)據(jù)倉庫在數(shù)據(jù)平臺中的建設(shè)有兩個環(huán)節(jié)：一個是數(shù)據(jù)倉庫的構(gòu)建，另外一個就是數(shù)據(jù)倉庫的應(yīng)用。
數(shù)據(jù)倉庫是伴隨著企業(yè)信息化發(fā)展起來的，在企業(yè)信息化的過程中，隨著信息化工具的升級和新工具的應(yīng)用，數(shù)據(jù)量變的越來越大，數(shù)據(jù)格式越來越多，決策要求越來越苛刻，數(shù)據(jù)倉庫技術(shù)也在不停的發(fā)展 這就是架構(gòu)升級的原因，其實(shí)就是外部環(huán)境變了，現(xiàn)有的體系不能滿足當(dāng)前的需求，既然找到了原因，我們就來欣賞一下歷史長河中哪些閃亮的星。
“我們正在從IT時代走向DT時代(數(shù)據(jù)時代)。IT和DT之間，不僅僅是技術(shù)的變革，更是思想意識的變革，IT主要是為自我服務(wù)，用來更好地自我控制和管理，DT則是激活生產(chǎn)力，讓別人活得比你好”
——阿里巴巴董事局主席馬云。
經(jīng)典數(shù)倉
在開始之前，我們先說一點(diǎn)，其實(shí)數(shù)據(jù)倉庫很早之前就有了，也就是說在離線數(shù)倉之前(基于大數(shù)據(jù)架構(gòu)之前)，有很多傳統(tǒng)的數(shù)倉技術(shù)，例如基于Teradata的數(shù)據(jù)倉庫，只不過是數(shù)據(jù)倉庫技術(shù)在大數(shù)據(jù)背景下發(fā)生了很多改變，也就是我們開始拋棄了傳統(tǒng)構(gòu)建數(shù)倉的技術(shù)，轉(zhuǎn)而選擇了更能滿足當(dāng)前時代需求的大數(shù)據(jù)技術(shù)而已，當(dāng)然大數(shù)據(jù)技術(shù)并沒有完整的、徹底的取代傳統(tǒng)的技術(shù)實(shí)現(xiàn)，我們依然可以在很多地方看見它們的身影。
經(jīng)典數(shù)倉可以將數(shù)倉的數(shù)倉的不同分層放在不同的數(shù)據(jù)庫中，也可以將不同的分層放在不同的數(shù)據(jù)庫實(shí)例上，甚至是可以把不同的分層放在不同的機(jī)房。
大數(shù)據(jù)技術(shù)改變了數(shù)倉的存儲和計算方式，當(dāng)然也改變了數(shù)倉建模的理念，例如經(jīng)典數(shù)倉數(shù)據(jù)存儲在mysql等關(guān)系型數(shù)據(jù)庫上，大數(shù)據(jù)數(shù)倉存儲在hadoop平臺的hive中（實(shí)際上是HDFS中），當(dāng)然也有其他的數(shù)倉產(chǎn)品比如TD、greenplum等。
離線數(shù)倉(離線大數(shù)據(jù)架構(gòu))
隨著互聯(lián)網(wǎng)時代來臨，數(shù)據(jù)量暴增，開始使用大數(shù)據(jù)工具來替代經(jīng)典數(shù)倉中的傳統(tǒng)工具。此時僅僅是工具的取代，架構(gòu)上并沒有根本的區(qū)別，可以把這個架構(gòu)叫做離線大數(shù)據(jù)架構(gòu)。
隨著數(shù)據(jù)量逐漸增大，事實(shí)表?xiàng)l數(shù)達(dá)到千萬級，kettle等傳統(tǒng)ETL工具逐漸變得不穩(wěn)定，數(shù)據(jù)庫等存儲技術(shù)也面臨著存儲緊張，每天都陷入和磁盤的爭斗中單表做拉鏈的任務(wù)的執(zhí)行時間也指數(shù)級增加，這個時候存儲我們開始使用HDFS而不是數(shù)據(jù)庫；計算開始使用HIVE(MR)而不是傳統(tǒng)數(shù)倉技術(shù)架構(gòu)使用的kettle、Informatica 等ETL工具；
公司開始考慮重新設(shè)計數(shù)倉的架構(gòu)，使用hadoop平臺的hive做數(shù)據(jù)倉庫，報表層數(shù)據(jù)保存在mysql中，使用tableau做報表系統(tǒng)，這樣不用擔(dān)心存儲問題、計算速度也大大加快了。在此基礎(chǔ)上，公司開放了hue給各個部門使用，這樣簡單的提數(shù)工作可以由運(yùn)營自己來操作。使用presto可以做mysql、hive的跨庫查詢，使用時要注意presto的數(shù)據(jù)類型非常嚴(yán)格。
Lambda架構(gòu)
后來隨著網(wǎng)絡(luò)技術(shù)、通信技術(shù)的發(fā)展，使得終端數(shù)據(jù)的實(shí)時上報傳輸成為可能，從而業(yè)務(wù)實(shí)系統(tǒng)發(fā)生變化，進(jìn)而導(dǎo)致了我們對需求的時性要求的不斷提高開始之前我們先看一下，網(wǎng)絡(luò)技術(shù)和通信技術(shù)到底對我們的生活有什么樣的影響。
為了應(yīng)對這種變化，開始在離線大數(shù)據(jù)架構(gòu)基礎(chǔ)上加了一個加速層，使用流處理技術(shù)直接完成那些實(shí)時性要求較高的指標(biāo)計算，然后和離線計算進(jìn)整合從而給用戶一個完整的實(shí)時計算結(jié)果，這便是Lambda架構(gòu)。
為了計算一些實(shí)時指標(biāo)，就在原來離線數(shù)倉的基礎(chǔ)上增加了一個實(shí)時計算的鏈路，并對數(shù)據(jù)源做流式改造（即把數(shù)據(jù)發(fā)送到消息隊列），實(shí)時計算去訂閱消息隊列，直接完成指標(biāo)增量的計算，推送到下游的數(shù)據(jù)服務(wù)中去，由數(shù)據(jù)服務(wù)層完成離線&實(shí)時結(jié)果的合并。
需要注意的是流處理計算的指標(biāo)批處理依然計算，最終以批處理為準(zhǔn)，即每次批處理計算后會覆蓋流處理的結(jié)果（這僅僅是流處理引擎不完善做的折中），Lambda架構(gòu)是由Storm的作者Nathan Marz提出的一個實(shí)時大數(shù)據(jù)處理框架。Marz在Twitter工作期間開發(fā)了著名的實(shí)時大數(shù)據(jù)處理框架Storm，Lambda架構(gòu)是其根據(jù)多年進(jìn)行分布式大數(shù)據(jù)系統(tǒng)的經(jīng)驗(yàn)總結(jié)提煉而成。Lambda架構(gòu)的目標(biāo)是設(shè)計出一個能滿足實(shí)時大數(shù)據(jù)系統(tǒng)關(guān)鍵特性的架構(gòu)，包括有：高容錯、低延時和可擴(kuò)展等。Lambda架構(gòu)整合離線計算和實(shí)時計算，融合不可變性（Immunability），讀寫分離和復(fù)雜性隔離等一系列架構(gòu)原則，可集成Hadoop，Kafka，Storm，Spark，Hbase等各類大數(shù)據(jù)組件。
如果拋開上面的Merge 操作，那么Lambda架構(gòu)就是兩條完全不同處理流程，就像下面所示。
存在的問題
同樣的需求需要開發(fā)兩套一樣的代碼，這是Lambda架構(gòu)最大的問題，兩套代碼不僅僅意味著開發(fā)困難（同樣的需求，一個在批處理引擎上實(shí)現(xiàn)，一個在流處理引擎上實(shí)現(xiàn)，還要分別構(gòu)造數(shù)據(jù)測試保證兩者結(jié)果一致），后期維護(hù)更加困難，比如需求變更后需要分別更改兩套代碼，獨(dú)立測試結(jié)果，且兩個作業(yè)需要同步上線。
資源占用增多：同樣的邏輯計算兩次，整體資源占用會增多（多出實(shí)時計算這部分）。
實(shí)時鏈路和離線鏈路計算結(jié)果容易讓人誤解，昨天看到的數(shù)據(jù)和今天看到的數(shù)據(jù)不一致**。
下游處理復(fù)雜，需要整合實(shí)時和離線處理結(jié)果，這一部分往往是我們在呈現(xiàn)給用戶之前就完成了的。
Kappa架構(gòu)
再后來，實(shí)時的業(yè)務(wù)越來越多，事件化的數(shù)據(jù)源也越來越多，實(shí)時處理從次要部分變成了主要部分，架構(gòu)也做了相應(yīng)調(diào)整，出現(xiàn)了以實(shí)時事件處理為核心的Kappa架構(gòu)。當(dāng)然這不要實(shí)現(xiàn)這一變化，還需要技術(shù)本身的革新——Flink，F(xiàn)link 的出現(xiàn)使得Exactly-Once 和狀態(tài)計算成為可能，這個時候?qū)崟r計算的結(jié)果保證最終結(jié)果的準(zhǔn)確性。
Lambda架構(gòu)雖然滿足了實(shí)時的需求，但帶來了更多的開發(fā)與運(yùn)維工作，其架構(gòu)背景是流處理引擎還不完善，流處理的結(jié)果只作為臨時的、近似的值提供參考。后來隨著Flink等流處理引擎的出現(xiàn)，流處理技術(shù)很成熟了，這時為了解決兩套代碼的問題，LickedIn 的Jay Kreps提出了Kappa架構(gòu)。
Kappa架構(gòu)可以認(rèn)為是Lambda架構(gòu)的簡化版（只要移除lambda架構(gòu)中的批處理部分即可）。在Kappa架構(gòu)中，需求修改或歷史數(shù)據(jù)重新處理都通過上游重放完成。
Kappa架構(gòu)的重新處理過程
選擇一個具有重放功能的、能夠保存歷史數(shù)據(jù)并支持多消費(fèi)者的消息隊列，根據(jù)需求設(shè)置歷史數(shù)據(jù)保存的時長，比如Kafka，可以保存全部歷史數(shù)據(jù),當(dāng)然還有后面出現(xiàn)的Pulsar，以及專門解決實(shí)時輸出存儲的Pravega。
當(dāng)某個或某些指標(biāo)有重新處理的需求時，按照新邏輯寫一個新作業(yè)，然后從上游消息隊列的最開始重新消費(fèi)，把結(jié)果寫到一個新的下游表中。
當(dāng)新作業(yè)趕上進(jìn)度后，應(yīng)用切換數(shù)據(jù)源，使用新產(chǎn)生的新結(jié)果表。停止老的作業(yè)，刪除老的結(jié)果表。
存在的問題
Kappa架構(gòu)最大的問題是流式重新處理歷史的吞吐能力會低于批處理，但這個可以通過增加計算資源來彌補(bǔ)。
Pravega(流式存儲)
想要統(tǒng)一流批處理的大數(shù)據(jù)處理架構(gòu)，其實(shí)對存儲有混合的要求。
對于來自序列舊部分的歷史數(shù)據(jù)，需要提供高吞吐的讀性能，即catch-up read對于來自序列新部分的實(shí)時數(shù)據(jù)，需要提供低延遲的 append-only 尾寫 tailing write 以及尾讀 tailing read
存儲架構(gòu)最底層是基于可擴(kuò)展分布式云存儲，中間層表示日志數(shù)據(jù)存儲為 Stream 來作為共享的存儲原語，然后基于 Stream 可以向上提供不同功能的操作:如消息隊列，NoSQL，流式數(shù)據(jù)的全文搜索以及結(jié)合 Flink 來做實(shí)時和批分析。換句話說，Pravega 提供的 Stream 原語可以避免現(xiàn)有大數(shù)據(jù)架構(gòu)中原始數(shù)據(jù)在多個開源存儲搜索產(chǎn)品中移動而產(chǎn)生的數(shù)據(jù)冗余現(xiàn)象，其在存儲層就完成了統(tǒng)一的數(shù)據(jù)湖。
提出的大數(shù)據(jù)架構(gòu)，以 Apache Flink 作為計算引擎，通過統(tǒng)一的模型/API來統(tǒng)一批處理和流處理。以 Pavega 作為存儲引擎，為流式數(shù)據(jù)存儲提供統(tǒng)一的抽象，使得對歷史和實(shí)時數(shù)據(jù)有一致的訪問方式。兩者統(tǒng)一形成了從存儲到計算的閉環(huán)，能夠同時應(yīng)對高吞吐的歷史數(shù)據(jù)和低延時的實(shí)時數(shù)據(jù)。同時 Pravega 團(tuán)隊還開發(fā)了 Flink-Pravega Connector，為計算和存儲的整套流水線提供 Exactly-Once 的語義。
混合架構(gòu)
前面介紹了Lambda架構(gòu)與Kappa架構(gòu)的含義及優(yōu)缺點(diǎn)，在真實(shí)的場景中，很多時候并不是完全規(guī)范的Lambda架構(gòu)或Kappa架構(gòu)，可以是兩者的混合，比如大部分實(shí)時指標(biāo)使用Kappa架構(gòu)完成計算，少量關(guān)鍵指標(biāo)（比如金額相關(guān)）使用Lambda架構(gòu)用批處理重新計算，增加一次校對過程。
Kappa架構(gòu)并不是中間結(jié)果完全不落地，現(xiàn)在很多大數(shù)據(jù)系統(tǒng)都需要支持機(jī)器學(xué)習(xí)（離線訓(xùn)練），所以實(shí)時中間結(jié)果需要落地對應(yīng)的存儲引擎供機(jī)器學(xué)習(xí)使用，另外有時候還需要對明細(xì)數(shù)據(jù)查詢，這種場景也需要把實(shí)時明細(xì)層寫出到對應(yīng)的引擎中。
還有就是Kappa這種以實(shí)時為主的架構(gòu)設(shè)計，除了增加了計算難度，對資源提出了更改的要求之外，還增加了開發(fā)的難度，所以才有了下面的混合架構(gòu)，可以看出這個架構(gòu)的出現(xiàn)，完全是處于需求和處于現(xiàn)狀考慮的。
實(shí)時數(shù)倉
實(shí)時數(shù)倉不應(yīng)該成為一種架構(gòu)，只能說是是Kappa架構(gòu)的一種實(shí)現(xiàn)方式，或者說是實(shí)時數(shù)倉是它的一種在工業(yè)界落地的實(shí)現(xiàn)，在Kappa架構(gòu)的理論支持下，實(shí)時數(shù)倉主要解決數(shù)倉對數(shù)據(jù)實(shí)時化的需求，例如數(shù)據(jù)的實(shí)時攝取、實(shí)時處理、實(shí)時計算等。
其實(shí)實(shí)時數(shù)倉主主要解決三個問題 1. 數(shù)據(jù)實(shí)時性 2. 緩解集群壓力 ?3. 緩解業(yè)務(wù)庫壓力。
第一層DWD公共實(shí)時明細(xì)層 實(shí)時計算訂閱業(yè)務(wù)數(shù)據(jù)消息隊列，然后通過數(shù)據(jù)清洗、多數(shù)據(jù)源join、流式數(shù)據(jù)與離線維度信息等的組合，將一些相同粒度的業(yè)務(wù)系統(tǒng)、維表中的維度屬性全部關(guān)聯(lián)到一起，增加數(shù)據(jù)易用性和復(fù)用性，得到最終的實(shí)時明細(xì)數(shù)據(jù)。這部分?jǐn)?shù)據(jù)有兩個分支，一部分直接落地到ADS，供實(shí)時明細(xì)查詢使用，一部分再發(fā)送到消息隊列中，供下層計算使用。
第二層DWS公共實(shí)時匯總層 以數(shù)據(jù)域+業(yè)務(wù)域的理念建設(shè)公共匯總層，與離線數(shù)倉不同的是，這里匯總層分為輕度匯總層和高度匯總層，并同時產(chǎn)出，輕度匯總層寫入ADS，用于前端產(chǎn)品復(fù)雜的olap查詢場景，滿足自助分析；高度匯總層寫入Hbase，用于前端比較簡單的kv查詢場景，提升查詢性能，比如產(chǎn)出報表等。
實(shí)時數(shù)倉的的實(shí)施關(guān)鍵點(diǎn)
端到端數(shù)據(jù)延遲、數(shù)據(jù)流量量的監(jiān)控；
故障的快速恢復(fù)能?力力 數(shù)據(jù)的回溯處理理，系統(tǒng)?支持消費(fèi)指定時間端內(nèi)的數(shù)據(jù)；
實(shí)時數(shù)據(jù)從實(shí)時數(shù)倉中查詢，T+1數(shù)據(jù)借助離線通道修正；
數(shù)據(jù)地圖、數(shù)據(jù)?血緣關(guān)系的梳理理；
業(yè)務(wù)數(shù)據(jù)質(zhì)量量的實(shí)時監(jiān)控，初期可以根據(jù)規(guī)則的?方式來識別質(zhì)量量狀況；
數(shù)據(jù)保障
集團(tuán)每年都有雙十一等大促，大促期間流量與數(shù)據(jù)量都會暴增。實(shí)時系統(tǒng)要保證實(shí)時性，相對離線系統(tǒng)對數(shù)據(jù)量要更敏感，對穩(wěn)定性要求更高。
所以為了應(yīng)對這種場景，還需要在這種場景下做兩種準(zhǔn)備：1.大促前的系統(tǒng)壓測；2.大促中的主備鏈路保障。
數(shù)據(jù)湖
最開始的時候，每個應(yīng)用程序會產(chǎn)生、存儲大量數(shù)據(jù)，而這些數(shù)據(jù)并不能被其他應(yīng)用程序使用，這種狀況導(dǎo)致數(shù)據(jù)孤島的產(chǎn)生。隨后數(shù)據(jù)集市應(yīng)運(yùn)而生，應(yīng)用程序產(chǎn)生的數(shù)據(jù)存儲在一個集中式的數(shù)據(jù)倉庫中，可根據(jù)需要導(dǎo)出相關(guān)數(shù)據(jù)傳輸給企業(yè)內(nèi)需要該數(shù)據(jù)的部門或個人，然而數(shù)據(jù)集市只解決了部分問題。剩余問題，包括數(shù)據(jù)管理、數(shù)據(jù)所有權(quán)與訪問控制等都亟須解決，因?yàn)槠髽I(yè)尋求獲得更高的使用有效數(shù)據(jù)的能力。
為了解決前面提及的各種問題，企業(yè)有很強(qiáng)烈的訴求搭建自己的數(shù)據(jù)湖，數(shù)據(jù)湖不但能存儲傳統(tǒng)類型數(shù)據(jù)，也能存儲任意其他類型數(shù)據(jù)(文本、圖像、視頻、音頻)，并且能在它們之上做進(jìn)一步的處理與分析，產(chǎn)生最終輸出供各類程序消費(fèi)。而且隨著數(shù)據(jù)多樣性的發(fā)展，數(shù)據(jù)倉庫這種提前規(guī)定schema的模式顯得越來難以支持靈活的探索&分析需求，這時候便出現(xiàn)了一種數(shù)據(jù)湖技術(shù)，即把原始數(shù)據(jù)全部緩存到某個大數(shù)據(jù)存儲上，后續(xù)分析時再根據(jù)需求去解析原始數(shù)據(jù)。簡單的說，數(shù)據(jù)倉庫模式是schema ?on ?write，數(shù)據(jù)湖模式是schema on read。
總結(jié)
Kappa對比Lambda架構(gòu)
在真實(shí)的場景中，很多時候并不是完全規(guī)范的Lambda架構(gòu)或Kappa架構(gòu)，可以是兩者的混合，比如大部分實(shí)時指標(biāo)使用Kappa架構(gòu)完成計算，少量關(guān)鍵指標(biāo)（比如金額相關(guān)）使用Lambda架構(gòu)用批處理重新計算，增加一次校對過程。
這兩個架構(gòu)都是實(shí)時架構(gòu)，都是對離線架構(gòu)的擴(kuò)展。
實(shí)時數(shù)倉與離線數(shù)倉的對比
離線數(shù)據(jù)倉庫主要基于sqoop、hive等技術(shù)來構(gòu)建T+1的離線數(shù)據(jù)，通過定時任務(wù)每天拉取增量量數(shù)據(jù)導(dǎo)?到hive表中，然后創(chuàng)建各個業(yè)務(wù)相關(guān)的主題維度數(shù)據(jù)，對外提供T+1的數(shù)據(jù)查詢接口。
實(shí)時數(shù)倉當(dāng)前主要是基于實(shí)時數(shù)據(jù)采集工具，如canal等將原始數(shù)據(jù)寫?入到Kafka這樣的數(shù)據(jù)通道中，最后?一般都是寫 入到類似于HBase這樣存儲系統(tǒng)中，對外提供分鐘級別、甚?至秒級別的查詢?方案。