DataWarehouse實(shí)戰(zhàn)如何建設(shè)實(shí)時數(shù)倉從建設(shè)目的到場景選型的完整方案【免費(fèi)下載鏈接】DataWarehouse從數(shù)據(jù)倉庫到用戶畫像從數(shù)據(jù)建設(shè)到數(shù)據(jù)應(yīng)用項(xiàng)目地址: https://gitcode.com/gh_mirrors/da/DataWarehouseDataWarehouse從數(shù)據(jù)倉庫到用戶畫像的學(xué)習(xí)資料庫系統(tǒng)總結(jié)了實(shí)時數(shù)倉的完整建設(shè)方法論實(shí)時數(shù)倉的建設(shè)目的、四大應(yīng)用場景、整體架構(gòu)設(shè)計、分層策略、存儲選型與數(shù)據(jù)質(zhì)量驗(yàn)證。本文將帶你避開常見陷阱從 0 到 1 理解如何快速建設(shè)一套可用的實(shí)時數(shù)倉。 實(shí)時數(shù)倉的建設(shè)目的只為解決時效性問題實(shí)時數(shù)倉不是要替代離線數(shù)倉而是解決傳統(tǒng)數(shù)據(jù)倉庫數(shù)據(jù)時效性無法覆蓋的問題。在立項(xiàng)之前先明確兩條原則原則說明離線能解決的實(shí)時不解決比如上個月的歷史統(tǒng)計不需要用實(shí)時數(shù)倉建設(shè)數(shù)倉本身不適合的實(shí)時也不解決業(yè)務(wù)性很強(qiáng)的需求、或?qū)r效性要求極高的需求不建議走數(shù)倉路線數(shù)據(jù)保留策略離線數(shù)倉保存歷史累積數(shù)據(jù)而實(shí)時數(shù)倉只保留上一次批處理到當(dāng)前的數(shù)據(jù)。實(shí)踐中通常保留約 3 天的數(shù)據(jù)保證批處理還沒處理完昨天數(shù)據(jù)的間隙依然能提供完整的數(shù)據(jù)服務(wù)。 實(shí)時數(shù)倉的四大應(yīng)用場景實(shí)時數(shù)倉最適合支撐以下四類業(yè)務(wù)場景實(shí)時 OLAP 分析把數(shù)倉的時效性能力提升原有 OLAP 分析工具幾乎不用改造就能分析實(shí)時數(shù)據(jù)實(shí)時數(shù)據(jù)看板例如雙 11 實(shí)時大屏滾動展示核心數(shù)據(jù)支撐市場人員與領(lǐng)導(dǎo)層決策實(shí)時特征通過匯總指標(biāo)運(yùn)算給用戶打上特征標(biāo)記如多次購買判定為優(yōu)質(zhì)用戶支撐實(shí)時精準(zhǔn)推廣實(shí)時業(yè)務(wù)監(jiān)控對核心業(yè)務(wù)指標(biāo)實(shí)時監(jiān)控線上故障導(dǎo)致指標(biāo)下降時盡早發(fā)現(xiàn)、減少損失。? 實(shí)時數(shù)倉整體架構(gòu)Lambda 分層模型實(shí)時數(shù)倉的數(shù)據(jù)架構(gòu)與離線數(shù)倉非常相似同樣有 ODS 層、明細(xì)層、匯總層、應(yīng)用層整體遵循 Lambda 架構(gòu)的思路數(shù)據(jù)鏈路為數(shù)據(jù)源業(yè)務(wù)庫/日志→ 消息隊列Kafka→ ODS 層 → DWD 層 → OLAP 數(shù)據(jù)應(yīng)用。 離線數(shù)倉到實(shí)時數(shù)倉的概念映射理解實(shí)時數(shù)倉最快的方式是把離線數(shù)倉的每個概念翻譯成實(shí)時版的對應(yīng)物層面離線數(shù)倉實(shí)時數(shù)倉編程方式Hive SQL UDFSpark SQL / Flink SQL UDF作業(yè)執(zhí)行MapReduce / Spark Job持續(xù)運(yùn)行的 Spark Streaming / Flink 作業(yè)數(shù)倉對象Hive 表Stream Table流表物理存儲HDFS大數(shù)據(jù)量存 Kudu小數(shù)據(jù)量存 Kafka 分層設(shè)計層次越少越好實(shí)時數(shù)倉與離線數(shù)倉最大的區(qū)別是層次更少原因有二每多一層延遲必然增加實(shí)時數(shù)據(jù)每經(jīng)過一層計算都會產(chǎn)生額外延遲匯總層要盡量少建最好不超過兩層為了保證數(shù)據(jù)準(zhǔn)確匯總往往要人為等待數(shù)據(jù)到齊比如等到 10:00:05 再統(tǒng)計 10:00 前的數(shù)據(jù)層次越多這種人為延遲疊加越嚴(yán)重。另外實(shí)時數(shù)倉的應(yīng)用層其實(shí)已經(jīng)不在倉庫內(nèi)部——APP 層的應(yīng)用表本質(zhì)上已經(jīng)同步到了應(yīng)用系統(tǒng)的數(shù)據(jù)庫里。 物理存儲如何選型實(shí)時數(shù)倉的一個特點(diǎn)是同一份數(shù)倉不同層可以用不同的存儲方式。明細(xì) / 匯總數(shù)據(jù)數(shù)據(jù)量大存Kudu兼顧高吞吐與低延遲支持 update/delete數(shù)據(jù)量小的中間數(shù)據(jù)用Kafka這類消息隊列維度數(shù)據(jù)存HBase這類 KV 存儲。Kudu 專為快速變化的數(shù)據(jù)被快速分析的場景設(shè)計數(shù)據(jù)到達(dá)后馬上可被終端用戶訪問是實(shí)時數(shù)倉物理層的高頻選擇詳見 docs/kudu.md。? ODS 層建設(shè)三大要點(diǎn)ODS 層是實(shí)時數(shù)倉的地基主流實(shí)時數(shù)據(jù)源是Kafka數(shù)據(jù)來源以binlog、SDK 數(shù)據(jù)、埋點(diǎn)日志為主。建設(shè)時有三點(diǎn)必須強(qiáng)調(diào)數(shù)據(jù)源盡可能統(tǒng)一實(shí)時數(shù)據(jù)源自身要統(tǒng)一交易數(shù)據(jù)要么從 binlog 接要么從 SDK 發(fā)不能兩邊都發(fā)實(shí)時與離線要統(tǒng)一計算邏輯和數(shù)據(jù)來源完全一致避免使用方對數(shù)據(jù)產(chǎn)生誤解。用分區(qū)保證數(shù)據(jù)局部有序同一實(shí)體的數(shù)據(jù)可能因亂序?qū)е潞蟀l(fā)生的狀態(tài)先被消費(fèi)利用 Kafka 分區(qū)局部有序的機(jī)制即可解決。流式寫 HDFS 的小文件問題微批次處理會不斷產(chǎn)生小文件必須有程序異步合并小文件并移動到表中注意避開正在寫入的文件否則會導(dǎo)致實(shí)時任務(wù)失敗。 DWD 層模型規(guī)范化與數(shù)據(jù)漂移DWD 層負(fù)責(zé)消除原始數(shù)據(jù)的噪聲和不規(guī)范形成統(tǒng)一的數(shù)據(jù)源。為什么實(shí)時數(shù)倉特別強(qiáng)調(diào)模型規(guī)范化因?yàn)閷?shí)時作業(yè)是24 小時運(yùn)行的離線數(shù)倉改了上游表一天內(nèi)把下游改完即可而實(shí)時數(shù)倉只要改了上游表結(jié)構(gòu)下游作業(yè)必須能正確解析上游數(shù)據(jù)才能變更。再加上 Kafka 本身無元數(shù)據(jù)概念事后治理的代價非常大——務(wù)必在建設(shè)之初就把命名、類型等規(guī)范落地。數(shù)據(jù)漂移怎么處理由于小文件按物理時間異步合并昨天臨近 24 點(diǎn)的業(yè)務(wù)數(shù)據(jù)可能漂到今天。解決方式在 DWD 層解析邏輯上擴(kuò)大分區(qū)范圍按業(yè)務(wù)時間過濾即可把漂移數(shù)據(jù)排除。 數(shù)據(jù)質(zhì)量驗(yàn)證用離線數(shù)據(jù)持續(xù)驗(yàn)證實(shí)時數(shù)據(jù)實(shí)時數(shù)倉上線初期數(shù)據(jù)到底準(zhǔn)不準(zhǔn)人工每天去查庫對數(shù)太累且耗時。更優(yōu)方案是將實(shí)時中間層的表寫入 Hive利用離線數(shù)據(jù)豐富的質(zhì)量驗(yàn)證工具持續(xù)對比離線 vs 實(shí)時同一模型的數(shù)據(jù)差異再根據(jù)設(shè)定的閾值進(jìn)行監(jiān)控報警。該方案雖不能秒級發(fā)現(xiàn)問題但能幫助你在上線前了解實(shí)時模型的準(zhǔn)確程度并通過任務(wù)改造不斷提高準(zhǔn)確率——同時它還能反向檢驗(yàn)離線數(shù)據(jù)的準(zhǔn)確性。 建設(shè)清單上手前過一遍確認(rèn)場景屬于離線時效性滿足不了的問題看板 / 實(shí)時 OLAP / 實(shí)時特征 / 業(yè)務(wù)監(jiān)控實(shí)時與離線的數(shù)據(jù)來源、計算邏輯保持完全一致分層做減法匯總層不超過兩層物理存儲分層選型大數(shù)據(jù)量 Kudu、小數(shù)據(jù)量 Kafka、維度 HBase模型命名與類型規(guī)范在建設(shè)之初落地部署小文件異步合并 數(shù)據(jù)漂移過濾邏輯建立離線驗(yàn)證實(shí)時的質(zhì)量報警閉環(huán)?? 最后提醒數(shù)倉建設(shè)的成敗最終取決于業(yè)務(wù)是否買賬。選型前建議先閱讀 docs/數(shù)倉建設(shè)的十大陷阱.md避免過度迷戀技術(shù)、忘了業(yè)務(wù)目標(biāo)這個最常見陷阱。 延伸閱讀實(shí)時數(shù)倉完整筆記docs/實(shí)時數(shù)倉.mdOLAP 引擎分類與選型MOLAP/ROLAP/HOLAPdocs/olap.mdKudu 存儲引擎深入docs/kudu.md維度建模基礎(chǔ)docs/數(shù)據(jù)模型.mdPresto、Impala 與 Hive 對比docs/presto_impala_hive.md【免費(fèi)下載鏈接】DataWarehouse從數(shù)據(jù)倉庫到用戶畫像從數(shù)據(jù)建設(shè)到數(shù)據(jù)應(yīng)用項(xiàng)目地址: https://gitcode.com/gh_mirrors/da/DataWarehouse創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考