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