基于Flink的實(shí)時數(shù)倉搭建秘訣 |附課件下載√
分享嘉賓：個推數(shù)據(jù)部資深數(shù)據(jù)研發(fā)工程師 羅揚(yáng)（筱得）
個推TechDay"治數(shù)訓(xùn)練營"系列直播課第二期舉辦。來自每日互動（個推）的資深數(shù)據(jù)研發(fā)工程師為大家詳細(xì)解讀了實(shí)時數(shù)倉架構(gòu)演進(jìn)，分享了實(shí)時數(shù)倉的技術(shù)選型要點(diǎn)，并結(jié)合實(shí)戰(zhàn)案例詳細(xì)剖析實(shí)時數(shù)倉搭建秘訣。
課件下載
關(guān)注個推技術(shù)實(shí)踐微信公眾號，
后臺回復(fù)"實(shí)時數(shù)倉"，
獲取本期直播課件~
直播回顧
當(dāng)下，企業(yè)的實(shí)時計算需求越來越高頻。比如很多企業(yè)在建的實(shí)時數(shù)據(jù)可視化大屏就是很典型的實(shí)時計算場景：大屏數(shù)據(jù)實(shí)時刷新，展示最近一分鐘甚至半分鐘內(nèi)的交易額。類似的實(shí)時計算場景還有很多，比如智能算法推薦、系統(tǒng)風(fēng)險預(yù)警、實(shí)時特征工程等。
而以往的離線數(shù)倉具有高延時性，數(shù)據(jù)時效性一般為T+1，調(diào)度頻率也是以天為單位，無法滿足這些場景的數(shù)據(jù)時效性要求。所以，實(shí)時數(shù)倉便成為很多企業(yè)的大數(shù)據(jù)架構(gòu)選擇。
何為實(shí)時數(shù)倉？
關(guān)于實(shí)時數(shù)倉，目前行業(yè)內(nèi)還沒有一個標(biāo)準(zhǔn)的定義。我們可以從以下幾個方面來理解"實(shí)時數(shù)倉"：①實(shí)時數(shù)倉主要支持實(shí)時數(shù)據(jù)處理，并能夠根據(jù)業(yè)務(wù)需求提供實(shí)時數(shù)據(jù)。②實(shí)時數(shù)倉的整個數(shù)據(jù)鏈路均采用實(shí)時的方式，包括數(shù)據(jù)歸集、加工處理、數(shù)據(jù)分發(fā)等各環(huán)節(jié)。③另外，實(shí)時數(shù)倉的數(shù)據(jù)生態(tài)也采用實(shí)時方式，比如數(shù)據(jù)建設(shè)、數(shù)據(jù)質(zhì)量、數(shù)據(jù)血緣、數(shù)據(jù)治理等。
數(shù)倉架構(gòu)演進(jìn)
從經(jīng)典數(shù)倉架構(gòu)到離線數(shù)倉架構(gòu)，再到能支撐實(shí)時計算場景需求的Lambda和Kappa架構(gòu)，數(shù)倉架構(gòu)也經(jīng)歷了較長的演進(jìn)過程。
數(shù)倉架構(gòu)演進(jìn)
這里著重介紹一下Lambda架構(gòu)和Kappa架構(gòu)。
Lambda架構(gòu)其實(shí)是在離線數(shù)倉架構(gòu)的基礎(chǔ)上，新增了一條實(shí)時鏈路，用于支撐低延時業(yè)務(wù)場景的計算需求。與此同時，離線計算（批處理）鏈路仍然存在。也就是說，Lambda架構(gòu)采用實(shí)時和離線兩條鏈路。由于同一部分業(yè)務(wù)代碼需要有兩套邏輯支撐，所以Lambda架構(gòu)的后期維護(hù)比較復(fù)雜，對資源的消耗也比較大。
基于此又迭代產(chǎn)生了Kappa架構(gòu)。Kappa架構(gòu)在Lambda架構(gòu)的基礎(chǔ)上進(jìn)行了優(yōu)化，刪除了Batch Layer（批處理層）的部分，將數(shù)據(jù)通道以消息隊(duì)列進(jìn)行替代，使用同一套邏輯進(jìn)行離線和實(shí)時任務(wù)的計算。不過，目前Kappa架構(gòu)還不是非常成熟，仍存在一些無法解決的問題。
鑒于Lambda架構(gòu)和Kappa架構(gòu)都存在一些缺陷，目前很多企業(yè)將兩者相結(jié)合，采用Lambda+Kappa的混合架構(gòu)進(jìn)行數(shù)倉建設(shè)。比如，針對大部分實(shí)時指標(biāo)，企業(yè)仍然使用Kappa架構(gòu)進(jìn)行計算；針對少量關(guān)鍵指標(biāo)（比如金額相關(guān)），則使用Lambda 架構(gòu)的批處理模塊重新計算，增加一次校對過程，以此確保數(shù)據(jù)的時效性和計算結(jié)果的準(zhǔn)確性。
實(shí)時數(shù)倉技術(shù)選型
目前主流的實(shí)時計算引擎有Storm、Spark和Flink。如下圖，每個計算引擎都有其特性。
各實(shí)時計算引擎特性對比
我們建議綜合考慮延時和實(shí)時場景需求等方面因素，來進(jìn)行計算引擎的選型。
1. 延時
如果對延時要求較低，可以使用Spark Streaming。Spark Streaming的API非常豐富，并且吞吐量高。此外Spark已經(jīng)發(fā)展較長時間，其生態(tài)體系也比較成熟。
如果對延時要求高，則推薦使用Flink。Flink的API也是相對比較豐富的，而且目前Flink社區(qū)非常活躍，尤其是在中國，其相關(guān)生態(tài)迭代迅速。
Structured Streaming也能夠滿足低延時需求，但是其目前的使用率還比較低，生態(tài)迭代發(fā)展較慢，相對來講不是非常成熟。
2. 實(shí)時場景的要求
如果企業(yè)需要支撐一些比較特殊的實(shí)時場景需求，比如窗口、Watermark等，我們比較推薦Flink。Flink對實(shí)時場景的支持已經(jīng)非常完善了。相對而言，Storm的優(yōu)勢不明顯，且整體較為陳舊，不是特別建議使用。
實(shí)時數(shù)倉的建設(shè)
和離線數(shù)倉一致，實(shí)時數(shù)倉的建設(shè)也采用分層思想：ODS原始層對接原始數(shù)據(jù)；在ODS原始層之上，對數(shù)據(jù)進(jìn)行ETL處理，形成DWD明細(xì)層；維度數(shù)據(jù)比如區(qū)域信息，建設(shè)成DIM維度層；最終經(jīng)過數(shù)據(jù)的分析加工，形成DM匯總層。
下圖是實(shí)時數(shù)倉的分層設(shè)計案例，供參考。
對于實(shí)時數(shù)倉的不同數(shù)據(jù)層，直播課程里都介紹了相應(yīng)的建設(shè)核心、建設(shè)方法。
1. 對于ODS層，需要使數(shù)據(jù)來源盡可能統(tǒng)一，并能夠利用分區(qū)來確保數(shù)據(jù)局部有序。
2. 對于DWD層，重點(diǎn)是解決原始數(shù)據(jù)中存在的數(shù)據(jù)噪聲、數(shù)據(jù)不完整和數(shù)據(jù)格式不統(tǒng)一等情況，形成規(guī)范、統(tǒng)一的數(shù)據(jù)源。在DWD層，除了數(shù)據(jù)本身，我們還需要為每條數(shù)據(jù)額外補(bǔ)充一些信息，以應(yīng)對實(shí)時數(shù)據(jù)生產(chǎn)環(huán)節(jié)的一些常見問題。比如為了解決重復(fù)數(shù)據(jù)的問題，需要給每一個數(shù)據(jù)打一個標(biāo)記，形成"唯一鍵"，來標(biāo)記微調(diào)數(shù)據(jù)。
3. 對于DIM層，業(yè)內(nèi)一般采用維表關(guān)聯(lián)等建設(shè)方式。
需要注意的是，DIM層的建設(shè)要分兩部分來看。一是針對變化頻率較低的維度數(shù)據(jù)，比如說地域信息等，可以將離線中的維度數(shù)據(jù)同步到緩存，然后在緩存中進(jìn)行訪問，或者通過一些公共服務(wù)以及維度服務(wù)進(jìn)行查詢；二是針對變化頻率較高的維度數(shù)據(jù)，比如說一些商品的價格信息，需要監(jiān)測其變化情況，并創(chuàng)建一張價格變動的拉鏈表。
4. 最后是DM匯總層的建設(shè)。這一層主要是對共性指標(biāo)進(jìn)行統(tǒng)一加工，同時根據(jù)主題進(jìn)行多維度的匯總等操作。
為了降低計算的延時，實(shí)時數(shù)倉減少了分層。所以相比離線數(shù)倉，實(shí)時數(shù)倉層次更少。同時，實(shí)時數(shù)倉和離線數(shù)倉分別采用不同的數(shù)據(jù)存儲方式。離線數(shù)倉主要采用Hive，實(shí)時數(shù)倉主要采用消息中間件，比如Kafka，來存儲明細(xì)數(shù)據(jù)，對于維度數(shù)據(jù)，實(shí)時數(shù)倉多采用HBase、MySQL等數(shù)據(jù)庫進(jìn)行存儲。
實(shí)時數(shù)倉的建設(shè)過程還是比較復(fù)雜的，本期課程還以Flink為例，為大家拆解了基于Flink進(jìn)行實(shí)時數(shù)倉建設(shè)的全過程。
更多課程詳情
查看直播回放視頻立即GET√
個推技術(shù)實(shí)戰(zhàn)
Q&A精選
直播過程中，大家就課程內(nèi)容進(jìn)行了交流，本文挑選了直播間的精彩提問做了Q&A梳理。
Q1：數(shù)據(jù)倉庫和數(shù)據(jù)湖之間有哪些關(guān)系？
A：大數(shù)據(jù)架構(gòu)從以數(shù)倉為主到演變?yōu)閿?shù)倉+數(shù)據(jù)湖的形式，其實(shí)是業(yè)務(wù)系統(tǒng)越來越復(fù)雜、數(shù)據(jù)量級越來越大、數(shù)據(jù)種類越來越多的體現(xiàn)。
早期的數(shù)據(jù)分析需求大多面對的是業(yè)務(wù)系統(tǒng)的日志數(shù)據(jù)，為了適應(yīng)大規(guī)模OLAP場景需求以及支持跨業(yè)務(wù)系統(tǒng)的復(fù)雜場景，基于數(shù)倉的大數(shù)據(jù)處理架構(gòu)逐漸衍生出來。
隨著業(yè)務(wù)系統(tǒng)的復(fù)雜性提升，數(shù)據(jù)量顯著增加，數(shù)據(jù)結(jié)構(gòu)也更加多元化，結(jié)構(gòu)化數(shù)據(jù)、半結(jié)構(gòu)化數(shù)據(jù)，甚至圖像、語音、視頻等非結(jié)構(gòu)化數(shù)據(jù)越來越豐富。也許很多數(shù)據(jù)暫時未得到明確應(yīng)用，但考慮到數(shù)據(jù)中可能蘊(yùn)藏著的巨大潛在價值，企業(yè)需要先做好這些數(shù)據(jù)的存儲，以便后續(xù)進(jìn)行探索和挖掘。
這樣就很自然的出現(xiàn)了一種妥協(xié)的解決方案，我們稱之為"數(shù)據(jù)湖"，即從先進(jìn)行數(shù)據(jù)處理后進(jìn)行數(shù)據(jù)使用，轉(zhuǎn)變?yōu)椋合却鎯?shù)據(jù)，待到后續(xù)想要使用數(shù)據(jù)時再考慮具體的數(shù)據(jù)加工處理方式。
"數(shù)據(jù)湖"架構(gòu)既節(jié)約了前期的數(shù)據(jù)接入成本，又可以避免因?yàn)閿?shù)據(jù)加工造成有價值信息丟失的情況。
綜上，數(shù)倉和數(shù)據(jù)湖面對的是兩種不同的大數(shù)據(jù)場景，個推目前也是通過將兩者結(jié)合，以更好地進(jìn)行數(shù)據(jù)價值挖掘。
Q2：實(shí)時任務(wù)與離線任務(wù)如何調(diào)度？
A：調(diào)度可以大致從任務(wù)調(diào)度、資源調(diào)度、調(diào)度框架幾個方面展開說明。
任務(wù)調(diào)度：目前，無論是實(shí)時還是離線引擎，都會將任務(wù)劃分為幾個階段（stage）執(zhí)行。在任務(wù)調(diào)度機(jī)制上，實(shí)時任務(wù)和離線任務(wù)有一定差異。實(shí)時程序一般為常駐程序，會在調(diào)度階段給每個stage提前分配資源，待所有資源申請好之后開始運(yùn)行任務(wù)。離線程序一般則是按照順序依次調(diào)度、依次申請資源。
資源調(diào)度：資源調(diào)度主要是對集群進(jìn)行資源分配。離線和實(shí)時任務(wù)在這方面區(qū)別不大，目前主流的方式是采用yarn、k8s。
調(diào)度框架：調(diào)度框架主要負(fù)責(zé)任務(wù)的啟動、調(diào)度、監(jiān)控。離線和實(shí)時任務(wù)使用的框架基本一致，常見的有azkaban、dophinscheduler。
Q3：實(shí)時數(shù)倉的建設(shè)過程中有哪些容易讓人陷入誤區(qū)的點(diǎn)？建設(shè)過程中如何避免呢？
A：首先，沒有一種技術(shù)能夠適用于所有的場景，實(shí)時數(shù)倉的引入在增加數(shù)據(jù)時效性的同時也會使數(shù)據(jù)處理的架構(gòu)復(fù)雜性增加。比如在Lamada架構(gòu)下，企業(yè)還需要維護(hù)兩套代碼。所以，實(shí)時數(shù)倉在應(yīng)用的時候，首先要從業(yè)務(wù)場景出發(fā)，期望通過引入實(shí)時數(shù)倉來解決哪些問題以及達(dá)成哪些目標(biāo)，需要提前思考清楚。
其次，在很多場景下，實(shí)時數(shù)倉還會出現(xiàn)數(shù)據(jù)質(zhì)量不高、離線實(shí)時數(shù)據(jù)不一致、故障容忍度低等缺點(diǎn)，所以數(shù)據(jù)開發(fā)人員還需要考慮這些新問題可能對業(yè)務(wù)造成的影響。
總體而言，實(shí)時數(shù)倉的建設(shè)還是要緊密結(jié)合公司的真實(shí)情況和業(yè)務(wù)需求，避免投入了很多的資源，無法帶來業(yè)務(wù)收益，甚至對業(yè)務(wù)產(chǎn)生干擾。
Q4：Lambda架構(gòu)和Kappa架構(gòu)有區(qū)分嗎？
A：在數(shù)據(jù)鏈路、開發(fā)成本、技術(shù)棧等方面都有較大區(qū)別：
數(shù)據(jù)鏈路：Lambda架構(gòu)存在離線、實(shí)時2條鏈路，而Kappa架構(gòu)會統(tǒng)一數(shù)據(jù)鏈路。
開發(fā)成本：主流Lambda由于歷史原因不同鏈路會使用不同的計算引擎，如離線采用Spark、實(shí)時采用Flink，開發(fā)成本較高。而Kappa架構(gòu)一般會統(tǒng)一計算引擎，開發(fā)流程簡化，維護(hù)成本較低。
技術(shù)棧：Lambda的2條數(shù)據(jù)鏈路會使用不同體系的組件，如離線采用Hive、Spark，實(shí)時采用Kafka、Flink，而kappa架構(gòu)統(tǒng)一使用實(shí)時相關(guān)的組件，如Flink、Kafka。
Q5：實(shí)時數(shù)倉的實(shí)時能達(dá)到什么級別？
A：實(shí)時數(shù)倉通過中間件和更少的數(shù)據(jù)層級來減少數(shù)據(jù)的處理周期，實(shí)時性可以達(dá)到秒級、毫秒級。
個推TechDay"治數(shù)訓(xùn)練營"
個推TechDay"治數(shù)訓(xùn)練營"系列直播課程由每日互動（個推）結(jié)合自身多年來的數(shù)據(jù)挖掘和治理經(jīng)驗(yàn)特別打造。
匯聚多位優(yōu)秀大數(shù)據(jù)架構(gòu)師的實(shí)操方法論，凝結(jié)眾多數(shù)據(jù)開發(fā)和數(shù)據(jù)分析工程師的一線實(shí)踐經(jīng)驗(yàn)，個推TechDay"治數(shù)訓(xùn)練營"下期更精彩，請大家持續(xù)關(guān)注~
