數據倉庫還在用“昨天”的數據做今天的決策嗎？

數據倉庫還在用“昨天”的數據做今天的決策嗎？

在瞬息萬變的商業環境中，等一天才能看到分析結果？這已經過時了。實時數倉（Real-time Data Warehouse）讓數據從產生到洞察幾乎“零延遲”，徹底告別“T+1”的等待。

如果還在為數據時效性發愁，或者覺得之前的數倉方案總差那么點意思，那么這篇文章正是為解決此準備的。今天，本文就將深入淺出地拆解實時數倉：它到底是什么？有什么優勢？架構如何一步步進化而來？看(kan)完會發現，關于實(shi)時(shi)數倉(cang)建(jian)設(she)，之(zhi)前的(de)理解可能真的(de)“白看(kan)”了。

一、實時數倉是什么

簡單來說，實時數倉（Real-time Data Warehouse）是一個用于存儲和處理實時數據的系統。和傳統的“T+1”數據倉庫不一樣，實時數倉的數據的處理和分析是即時進行的，數據幾乎立即進入數倉并可以立即用于分析和決策。說白了，它(ta)能(neng)讓企業能(neng)更快(kuai)地(di)拿到有用的數據，更快(kuai)地(di)做決策(ce)。

二、實時數倉的特點

1. 速度快

實(shi)時(shi)數倉的數據(ju)延遲非常(chang)低，從數據(ju)產生到能(neng)被查(cha)詢使用，只需要短短幾(ji)(ji)秒(miao)(miao)甚至(zhi)幾(ji)(ji)毫秒(miao)(miao)。有(you)了這么快的響應速度，企(qi)業能(neng)及時(shi)看到數據(ju)變化，及時(shi)調(diao)整(zheng)策略。

2. 數據流處理

實(shi)時數(shu)倉的(de)(de)運行離不開消息隊列(lie)和(he)計(ji)算(suan)(suan)框(kuang)架(jia)的(de)(de)配(pei)合。像(xiang) Kafka、Pulsar 這些(xie)消息隊列(lie)，負責接(jie)收和(he)傳遞(di)數(shu)據(ju)(ju)；Flink、Spark Streaming 這些(xie)計(ji)算(suan)(suan)框(kuang)架(jia)，則對數(shu)據(ju)(ju)進行實(shi)時計(ji)算(suan)(suan)和(he)處理。它們相互協作，讓數(shu)據(ju)(ju)源源不斷地流動起(qi)來。?

3. 實時分析?

實(shi)時數(shu)倉支(zhi)持很多(duo)實(shi)用的場景，比如對業務數(shu)據(ju)進行即(ji)時監控，一旦出現異(yi)常情(qing)況，馬上發出預警；還能(neng)實(shi)時更(geng)新用戶畫像，幫助(zhu)企業更(geng)好地了解客戶需求，提供個性化服務。?

4. 吞吐量大

在(zai)一些高(gao)并發的(de)業務場景(jing)下，比(bi)如電商平(ping)臺的(de)雙 11 大促(cu)，實時數倉(cang)的(de)單集(ji)群通常要能處理百(bai)萬(wan)級的(de) QPS（每秒(miao)查詢(xun)率）。只有(you)具備這么強(qiang)的(de)高(gao)吞吐能力，才能保證系統穩(wen)定運行，不出現卡(ka)頓(dun)、崩潰(kui)的(de)情況。?

5. 復雜性

不過，要(yao)實現實時(shi)數倉可不容易。在處(chu)理(li)數據(ju)的過程(cheng)中，會遇到(dao)很(hen)多復(fu)雜的問(wen)題(ti)(ti)，像數據(ju)順序錯亂、保證數據(ju)只被處(chu)理(li)一(yi)次(ci)，也就是(shi)精確一(yi)次(ci)處(chu)理(li)，Exactly-once，還有數據(ju)狀態(tai)管(guan)理(li)等等。這些問(wen)題(ti)(ti)都(dou)需要(yao)一(yi)一(yi)解決，對(dui)技術要(yao)求很(hen)高。?

這里也提醒大家，有些企業把(ba) “T+1 小(xiao)時” 的數據(ju)處理說成是 “準實時”，其實還是慢(man)了一拍。真正的實時數倉，必(bi)須(xu)是秒級(ji)響應。

三、數倉架構的演變

從1990年 Inmon 提出數(shu)據倉庫概念到今天(tian)，數(shu)倉架構(gou)經歷了最(zui)初的(de)傳(chuan)統(tong)數(shu)倉架構(gou)、離(li)線大數(shu)據架構(gou)、Lambda 架構(gou)、Kappa 架構(gou)以(yi)及由Flink 的(de)火熱帶出的(de)流(liu)批一體架構(gou)，數(shu)據架構(gou)技術(shu)不斷演進，本質是(shi)在往流(liu)批一體的(de)方(fang)向發展，讓用戶(hu)能(neng)以(yi)最(zui)自然、最(zui)小(xiao)的(de)成(cheng)本完成(cheng)實時計算。

1. 傳統數倉架構

這是(shi)(shi)比較傳統的一種(zhong)方式，結(jie)構或半結(jie)構化數(shu)(shu)據通過離線(xian)ETL定期加載到離線(xian)數(shu)(shu)倉(cang)，之后通過計算引擎取得(de)結(jie)果，供前端(duan)使用。這里的離線(xian)數(shu)(shu)倉(cang)+計算引擎，通常是(shi)(shi)使用大型商(shang)業數(shu)(shu)據庫(ku)來承擔(dan)，例如(ru)Oracle、DB2、Teradata等。

2. 離線大數據架構

隨(sui)著數(shu)(shu)據(ju)規模的不斷增大，傳統數(shu)(shu)倉(cang)(cang)方(fang)式(shi)難以承載海(hai)量(liang)數(shu)(shu)據(ju)。隨(sui)著大數(shu)(shu)據(ju)技術(shu)的普及(ji)，采(cai)用(yong)(yong)大數(shu)(shu)據(ju)技術(shu)來承載存儲與計算任務。數(shu)(shu)據(ju)源通過(guo)離線的方(fang)式(shi)導入到離線數(shu)(shu)倉(cang)(cang)中。下游(you)應用(yong)(yong)根據(ju)業務需求選擇直接(jie)讀取 DM 或(huo)加一層(ceng)數(shu)(shu)據(ju)服務，比如(ru) MySQL 或(huo) Redis。

數據倉庫(ku)從模型層面分為三(san)層：

（1）ODS，操(cao)作數(shu)據層，保存原始(shi)數(shu)據；

（2）DWD，數(shu)據倉庫明細(xi)層，根據主(zhu)題定義(yi)好事(shi)實(shi)與(yu)維度表(biao)，保存最(zui)細(xi)粒度的(de)事(shi)實(shi)數(shu)據；

（3）DM，數(shu)據集市/輕度(du)匯(hui)總(zong)層，在 DWD 層的基礎之上根據不同(tong)的業務(wu)需求做輕度(du)匯(hui)總(zong)。

當然，也可以使用(yong)傳傳統(tong)數據(ju)庫集群或MPP架(jia)構數據(ju)庫來(lai)完成。例如(ru)Hadoop+Hive/Spark、Oracle RAC、GreenPlum等。

3. Lambda架構

隨著業務的發(fa)展，隨著業務的發(fa)展，人們對(dui)數(shu)據(ju)實(shi)(shi)時(shi)(shi)(shi)性(xing)提出了更高的要(yao)(yao)求。此(ci)時(shi)(shi)(shi)，出現了Lambda架構，其將對(dui)實(shi)(shi)時(shi)(shi)(shi)性(xing)要(yao)(yao)求高的部(bu)分(fen)拆分(fen)出來，增加條實(shi)(shi)時(shi)(shi)(shi)計算鏈路。從(cong)源頭開始做流式改(gai)造(zao)，將數(shu)據(ju)發(fa)送到消息(xi)隊列中，實(shi)(shi)時(shi)(shi)(shi)計算引(yin)擎消費隊列數(shu)據(ju)，完(wan)成實(shi)(shi)時(shi)(shi)(shi)數(shu)據(ju)的增量計算。與此(ci)同時(shi)(shi)(shi)，批量處(chu)理部(bu)分(fen)依然(ran)存在，實(shi)(shi)時(shi)(shi)(shi)與批量并行(xing)(xing)運行(xing)(xing)。最終由統一的數(shu)據(ju)服(fu)務層合(he)并結(jie)(jie)果給于前端(duan)。一般是(shi)以批量處(chu)理結(jie)(jie)果為準(zhun)，實(shi)(shi)時(shi)(shi)(shi)結(jie)(jie)果主要(yao)(yao)為快速響(xiang)應(ying)。

4. Kappa架構

而Lambda架構，一(yi)個(ge)比較嚴重(zhong)(zhong)(zhong)的(de)問題(ti)就(jiu)是需要(yao)維(wei)護兩套邏輯。一(yi)部分在(zai)(zai)批量引(yin)擎(qing)(qing)實現，一(yi)部分在(zai)(zai)流式引(yin)擎(qing)(qing)實現，維(wei)護成(cheng)本很高。此外，對資源消(xiao)耗也較大。隨后誕生(sheng)的(de)Kappa架構，正是為了解決上述問題(ti)。其在(zai)(zai)數(shu)據需要(yao)重(zhong)(zhong)(zhong)新處(chu)理(li)或數(shu)據變(bian)更時，可通(tong)過歷史數(shu)據重(zhong)(zhong)(zhong)新處(chu)理(li)來完成(cheng)。方式是通(tong)過上游重(zhong)(zhong)(zhong)放(fang)完成(cheng)，即(ji)從數(shu)據源拉取數(shu)據重(zhong)(zhong)(zhong)新計算。

可Kappa架(jia)構最大的問題是流式重新(xin)處(chu)理歷史的吞吐能力會低于批處(chu)理，但(dan)這個可以(yi)通過增(zeng)加計算資源來彌補。

5. 混合架構

上述(shu)(shu)架(jia)構(gou)各有其適應場(chang)景，有時需(xu)要綜(zong)合(he)使(shi)用上述(shu)(shu)架(jia)構(gou)組合(he)滿足實際需(xu)求。當然這(zhe)也必(bi)將帶(dai)來架(jia)構(gou)的復雜度(du)。用戶應根(gen)據自身需(xu)求，有所取舍。在一般大多數場(chang)景下，是(shi)可(ke)以(yi)使(shi)用單一架(jia)構(gou)解決問(wen)(wen)題。現(xian)在很多產品在流(liu)批一體、海量、實時性方面也有非常好的表現(xian)，可(ke)以(yi)考慮(lv)這(zhe)種“全(quan)能(neng)手”解決問(wen)(wen)題。

四、怎樣搭建一個實時數倉

構建實(shi)時(shi)數(shu)倉需要根(gen)據(ju)業務(wu)需求選(xuan)擇合適的(de)(de)(de)技術架構，并通過ETL工具來實(shi)現數(shu)據(ju)的(de)(de)(de)實(shi)時(shi)采(cai)集(ji)、處(chu)理和分析，最終將結果存儲到(dao)實(shi)時(shi)數(shu)據(ju)倉庫中，并進行數(shu)據(ju)可(ke)視化和應用開發。我平時(shi)工作中常用的(de)(de)(de)數(shu)據(ju)集(ji)成與治理工具FineDataLink，提供了一套完整(zheng)而靈活的(de)(de)(de)解(jie)決方(fang)案(an)，可(ke)以快速構建可(ke)靠的(de)(de)(de)高時(shi)效/近實(shi)時(shi)數(shu)據(ju)倉庫系統。

具體來(lai)說，FineDataLink在以(yi)下幾個方面可以(yi)省下不(bu)少力：

1. 操作界面簡潔清晰

無(wu)代碼配(pei)置，字段(duan)自動映射，無(wu)需專業(ye)的(de)編程能力即(ji)可完成任務配(pei)置。

2.統一的數據管理

提供(gong)統一的(de)錯誤隊列管理、預警(jing)機制、日(ri)志管理，支持臟數(shu)據(ju)閾值設置和通(tong)知功能，可(ke)通(tong)過短信、郵件、平臺消息(xi)等進(jin)行消息(xi)提醒，保證企業(ye)敏感數(shu)據(ju)的(de)安(an)全性。

3. 打破數據壁壘

實(shi)(shi)現低成本(ben)業務系統的數(shu)據實(shi)(shi)時同步(bu)，從多(duo)個業務數(shu)據庫(ku)實(shi)(shi)時捕獲源數(shu)據庫(ku)的變(bian)化并(bing)毫秒內更新到目(mu)的數(shu)據庫(ku)。

數(shu)(shu)倉建設(she)是企業(ye)數(shu)(shu)據(ju)(ju)管理和(he)決策支(zhi)持的(de)關鍵環節，但(dan)在實踐(jian)中，企業(ye)需要根據(ju)(ju)自身業(ye)務需求和(he)數(shu)(shu)據(ju)(ju)規模，選擇合(he)適的(de)數(shu)(shu)倉建設(she)方案和(he)技術方案，以提高企業(ye)數(shu)(shu)據(ju)(ju)資產的(de)價(jia)值和(he)利用效率。

五、總結

實時數倉的建設，標志著數據處理能力從離線批處理向即時流處理的根本性躍遷。它不僅僅是技術的更新迭代，更是業務決策模式向敏捷化、智能化的轉變。從最早的“T+1”到現在的秒級響應，技術是越來越先進了。不過，建實時數倉也不是一蹴而就的，得考慮架構、開發、存儲、數據質量這些方方面面，并采用科學的建設方案，才能釋放數據實時價值。不妨從此刻起，擁(yong)抱實時化(hua)，讓數(shu)據價(jia)值最(zui)大(da)化(hua)。