|0x00 從流批一體誕生的必然性說起

通常來講，數(shù)據(jù)倉庫的建設(shè)屋讶，都是以離線作為主要的密報(bào)冰寻，下游的應(yīng)用，不論是報(bào)表還是接口皿渗，所提供的數(shù)據(jù)也大多是T-1時(shí)效性斩芭。

但伴隨著業(yè)務(wù)的變化，當(dāng)離線做到?jīng)]什么可以繼續(xù)做的時(shí)候羹奉，實(shí)時(shí)就會(huì)被拿出來秒旋，作為新一個(gè)階段的目標(biāo)進(jìn)行攻克。

在流批一體建設(shè)之前诀拭，這種實(shí)時(shí)訴求通常會(huì)開發(fā)成分鐘級的任務(wù)迁筛，通過近實(shí)時(shí)的方案來解決業(yè)務(wù)的問題，但分鐘級會(huì)帶來諸如任務(wù)過多耕挨、資源擠占較大细卧、無法支持復(fù)雜邏輯等問題。

因此專門支持實(shí)時(shí)計(jì)算的框架筒占，比如早期的Storm贪庙，能夠嘗試從純實(shí)時(shí)的角度解決業(yè)務(wù)問題，就被拿出來作為嘗試翰苫。然而Storm的局限性也很大止邮，因?yàn)槟菚?huì)的任務(wù)開發(fā)只能通過Java的方式來進(jìn)行，與Hive所推崇的純SQL方案相比奏窑，上手難度大了不少导披，同時(shí)兩套代碼的邏輯幾乎沒有可比性，這種方案也就一直沒有什么聲音埃唯。

盡管實(shí)時(shí)技術(shù)有各種缺陷撩匕，但作為一種能夠很容易講清楚價(jià)值的項(xiàng)目，同時(shí)又非常便于向上匯報(bào)的技術(shù)方案墨叛，實(shí)時(shí)技術(shù)還是被或多或少的做了起來止毕。在大多數(shù)的公司里模蜡，實(shí)時(shí)和離線就會(huì)有不同的團(tuán)隊(duì)進(jìn)行維護(hù)，或者是同一個(gè)團(tuán)隊(duì)扁凛，但分成不同的項(xiàng)目來執(zhí)行忍疾。這個(gè)階段，優(yōu)先高效的把業(yè)務(wù)做起來令漂，哪怕場景再簡單膝昆，但能夠證明實(shí)時(shí)有價(jià)值和前景，這個(gè)階段的目標(biāo)就算完成了叠必。

以上的各種方案，難免會(huì)帶來三個(gè)特別難以解決的問題：

（1）數(shù)據(jù)的口徑上妹窖，實(shí)時(shí)和離線很容易不統(tǒng)一纬朝；
（2）數(shù)據(jù)模型的規(guī)范上，實(shí)時(shí)和離線也往往是分開建設(shè)骄呼；
（3）即便是同一種口徑和同一種規(guī)范共苛，實(shí)時(shí)和離線也要分成兩套代碼來維護(hù)。

這三個(gè)問題短時(shí)間內(nèi)會(huì)被高速發(fā)展掩蓋掉蜓萄，但當(dāng)業(yè)務(wù)對實(shí)時(shí)的訴求越來越多隅茎、壓力越來越大的時(shí)候，口徑和代碼的不統(tǒng)一嫉沽，就會(huì)越來越成為阻礙敏捷開發(fā)的障礙辟犀，需要有方案進(jìn)行解決。

后來Flink出現(xiàn)了绸硕，帶來了流批一體的全新方案堂竟，這個(gè)問題便出現(xiàn)了解決的曙光，這也比較接近我們對于實(shí)時(shí)計(jì)算的理想方案玻佩，因?yàn)槠湟饬x堪比Hive出嘹，也成為了各個(gè)大廠面試的標(biāo)配問題。

然而咬崔，僅僅學(xué)會(huì)Flink是不夠的税稼，因?yàn)榱髋惑w帶來的并不僅僅是技術(shù)方案或者是框架的改變，同樣帶來了數(shù)據(jù)模型的改變垮斯，這就要求我們從數(shù)據(jù)模型上郎仆，而不是技術(shù)方案上，來制定我們的實(shí)時(shí)方案甚脉。

|0x01 實(shí)時(shí)的數(shù)據(jù)模型方案是怎樣的

那么我們?nèi)绾卫斫狻皩?shí)時(shí)數(shù)據(jù)模型”這件事情呢丸升？

通常而言，我們關(guān)心的內(nèi)容牺氨，包括如下幾個(gè)方面：

（1）實(shí)時(shí)數(shù)據(jù)源與離線數(shù)據(jù)源存在差異狡耻，導(dǎo)致相同的字段墩剖，取值或者類型會(huì)存在不相等的情況；
（2）實(shí)時(shí)和離線由于底層執(zhí)行機(jī)制的不同夷狰，通常需要維護(hù)兩套代碼岭皂，會(huì)帶來諸如口徑不統(tǒng)一、質(zhì)量檢測難的問題沼头；
（3）產(chǎn)品邏輯變化較快時(shí)爷绘，離線模型修改相對容易，但實(shí)時(shí)模型需要考慮壓測进倍、削峰土至、重啟等技術(shù)問題，維護(hù)成本非常高昂猾昆。

數(shù)據(jù)倉庫之所以能夠普及并被業(yè)務(wù)接受陶因，正是因?yàn)槠淠Ｐ湍軌蚱帘蔚舻讓硬町惖膯栴}，并且有相對可靠的數(shù)據(jù)質(zhì)量監(jiān)控方法垂蜗，并且變更成本非常低楷扬。而實(shí)時(shí)數(shù)倉如果想要替代掉離線數(shù)倉，以上的問題通常是需要一些模型設(shè)計(jì)甚至是平臺(tái)工具的來解決贴见，這些問題解決的重要性烘苹，并不比Flink弱。

我們先從比較可控的模型層面說起片部。

在離線的概念里镣衡，數(shù)倉模型設(shè)計(jì)成了DWD/DWS/ADS三個(gè)層級，原本的概念是DWD面向事實(shí)表的構(gòu)建吞琐，DWS面向公共指標(biāo)的統(tǒng)一捆探，ADS負(fù)責(zé)靈活的口徑變化問題。

在離線的概念里站粟，DWD/DWS/ADS三個(gè)層級需要保留黍图，但負(fù)責(zé)的目標(biāo)會(huì)有一些變化，同時(shí)還需要增加存儲(chǔ)統(tǒng)一層奴烙，也就是以TiDB/Holo為代表的數(shù)據(jù)庫助被，來承擔(dān)服務(wù)分析一體化的訴求。

讓我們先看DWD層切诀，DWD承擔(dān)了屏蔽實(shí)時(shí)離線鏈路差異的問題揩环，最重要的作用是保證表結(jié)構(gòu)的統(tǒng)一及字段內(nèi)容的對齊。DWD最重要的意義幅虑，是保證離線表和實(shí)時(shí)表丰滑，其表結(jié)構(gòu)和字段概念是相同的。

為什么這么強(qiáng)調(diào)倒庵？試想一下褒墨，在離線場景下炫刷，我們可以在DWD上靈活的增加各種統(tǒng)計(jì)標(biāo)簽，或者是將維度退化到事實(shí)表郁妈，都是一些left join或者是服務(wù)端直接打標(biāo)可以解決的事情浑玛。但在實(shí)時(shí)場景下，這會(huì)變成多流join或者是緩存等更復(fù)雜的技術(shù)場景噩咪，導(dǎo)致這些信息并不能有效的記錄到DWD顾彰，因此DWD的設(shè)計(jì)就要產(chǎn)生一些變化，有一些內(nèi)容在實(shí)時(shí)場景下無法準(zhǔn)確記錄胃碾，這一類信息需要標(biāo)識(shí)到對應(yīng)的字段描述上涨享，下游使用時(shí)才不會(huì)出錯(cuò)。

同時(shí)仆百，實(shí)時(shí)和離線存儲(chǔ)數(shù)據(jù)的介質(zhì)灰伟，也必然有一些區(qū)別。例如離線可以存在HDFS上儒旬，實(shí)時(shí)則可能視情況保存在數(shù)據(jù)庫、HDFS甚至是內(nèi)存中帖族，這時(shí)候?qū)τ谧侄胃袷秸辉础⒆x取方式都會(huì)有差異，設(shè)計(jì)表時(shí)其約束條件也會(huì)更多竖般。

因而甚垦，DWD更多承擔(dān)了邏輯統(tǒng)一的職責(zé)，依舊以事實(shí)表為基礎(chǔ)涣雕，但約束條款要比離線更多艰亮。

再看一下DWS層，離線上DWS是負(fù)責(zé)口徑統(tǒng)一的重要一環(huán)挣郭，將通用的維度和口徑計(jì)算方法抽象出現(xiàn)迄埃，以提供跨數(shù)據(jù)域的靈活使用。但在實(shí)時(shí)場景下兑障，這一類的維護(hù)收益通常都比較低侄非，不僅因?yàn)閷?shí)時(shí)只看當(dāng)天的數(shù)據(jù)，也是因?yàn)閷?shí)時(shí)本身的維度難度就較大流译，多一層模型其收益會(huì)急速下降逞怨，因而大多數(shù)時(shí)候會(huì)忽略掉DWS的建設(shè)，ADS直接引用DWD進(jìn)行統(tǒng)計(jì)福澡。

然而叠赦，DWS畢竟存儲(chǔ)的內(nèi)容要比DWD少很多，因此如果計(jì)算資源瓶頸非常明顯革砸，或者是業(yè)務(wù)場景不需要分析實(shí)時(shí)明細(xì)數(shù)據(jù)的情況下除秀，或者是DWD的下游引用過多時(shí)糯累，DWS可以承擔(dān)削峰的重任，通過減少數(shù)據(jù)量以應(yīng)對大促等場景鳞仙，還是有一定意義的寇蚊。

接下來就是最重要的ADS層，在這一層上棍好，邏輯統(tǒng)一仗岸、口徑統(tǒng)一、大促削峰在前置模型上都得到了一定程度的解決借笙，ADS則像離線一樣承擔(dān)了應(yīng)對需求變化的重任扒怖。

但ADS所面臨的情況和離線還是有所不同的，因?yàn)锳DS的任務(wù)啟動(dòng)业稼，不僅要啟動(dòng)一個(gè)離線的跑批任務(wù)盗痒，還要同時(shí)啟動(dòng)一個(gè)實(shí)時(shí)的流式任務(wù)，而ADS往往會(huì)同時(shí)統(tǒng)計(jì)離線+實(shí)時(shí)的結(jié)果低散，以應(yīng)對同比俯邓、環(huán)比等場景。

這時(shí)候很多具體Case要具體分析了熔号，因?yàn)樘囟▓鼍暗目訒?huì)非常多稽鞭。例如最常見的“同比”，要對比今年和去年的結(jié)果變化引镊，離線往往會(huì)統(tǒng)計(jì)分小時(shí)的結(jié)果朦蕴，但實(shí)時(shí)會(huì)累計(jì)起始時(shí)刻到當(dāng)期時(shí)刻的結(jié)果，因而當(dāng)一個(gè)小時(shí)沒有結(jié)束的時(shí)候弟头，這個(gè)同比的波動(dòng)變化會(huì)非常大吩抓，給人一種“數(shù)據(jù)是錯(cuò)誤的”印象，新手很容易踩這個(gè)坑赴恨，從而被業(yè)務(wù)質(zhì)疑疹娶。

因此，針對累計(jì)統(tǒng)計(jì)指標(biāo)嘱支，從代碼設(shè)計(jì)上就要考慮到這種情況蚓胸，都根據(jù)時(shí)間字段統(tǒng)計(jì)起始到當(dāng)前時(shí)刻的結(jié)果的，在代碼邏輯上會(huì)要求一些統(tǒng)計(jì)技巧除师。

很多時(shí)候沛膳，因?yàn)闃I(yè)務(wù)指標(biāo)變化太快，改實(shí)時(shí)代碼是來不及的汛聚，這時(shí)候一部分的工作量甚至需要報(bào)表工具的數(shù)據(jù)集來解決锹安，改動(dòng)查詢sql，要比改動(dòng)任務(wù)來的快捷多了。但這部分的能力叹哭，其實(shí)是依賴于存儲(chǔ)工具的忍宋，個(gè)人認(rèn)為可以分到存儲(chǔ)統(tǒng)一層來解決。

最后是存儲(chǔ)統(tǒng)一層风罩，因?yàn)橐恍┨厥獾膱鼍翱放牛热鐚?shí)時(shí)分析明細(xì)數(shù)據(jù)，或者是不確定時(shí)間周期的多天統(tǒng)計(jì)結(jié)果超升，如果依賴Flink SQL來解決是有些不現(xiàn)實(shí)的入宦，因而這部分的壓力需要數(shù)據(jù)庫來承擔(dān)。

簡單講室琢，就是將明細(xì)做輕度的匯總后乾闰，直接寫到數(shù)據(jù)庫，實(shí)時(shí)更新盈滴，下游自定義條件涯肩，并直接讀庫統(tǒng)計(jì)結(jié)果。這種場景既要求數(shù)據(jù)庫有OLAP的計(jì)算能力巢钓，也要有OLTP的穩(wěn)定特點(diǎn)病苗，因而TiDB和Holo這一類HTAP的引擎就變得非常重要。

|0x02 實(shí)時(shí)模型對于開發(fā)工具有哪些要求

因?yàn)槎嗔藢?shí)時(shí)的部分症汹，因此過去面向離線的開發(fā)工具铅乡，也需要有一些特定的改造，以適應(yīng)實(shí)時(shí)的開發(fā)和運(yùn)維訴求烈菌。

對于開發(fā)工具而言，其目標(biāo)集中在四個(gè)場景上：元數(shù)據(jù)定義與獲取花履、數(shù)據(jù)建模芽世、開發(fā)與測試、運(yùn)維與監(jiān)控诡壁。

首先講元數(shù)據(jù)定義與獲取济瓢，F(xiàn)link通常對接能夠支持發(fā)布訂閱的消息流框架，因而其元數(shù)據(jù)并不像表一樣有明確的定義妹卿，我們在獲取消息流的數(shù)據(jù)格式和定義時(shí)旺矾，就需要專門的系統(tǒng)來承載。同時(shí)夺克，離線和實(shí)時(shí)不同的地方箕宙，在于離線僅需要統(tǒng)計(jì)任務(wù)完成后的一些執(zhí)行情況，而實(shí)時(shí)則需要將日志量的趨勢展示出來铺纽。

其次講數(shù)據(jù)建模柬帕，因?yàn)榻５睦碚撘呀?jīng)穩(wěn)定了有些年頭了，絕大多數(shù)場景下都是按照既定的方案來執(zhí)行。過去離線當(dāng)?shù)罆r(shí)陷寝，規(guī)范執(zhí)行的弱一些不是什么大問題锅很，但流批一體當(dāng)?shù)赖哪甏?guī)范是需要強(qiáng)約束的凤跑，這就對了開發(fā)工具提出了一定的要求爆安，是否能夠從平臺(tái)層面上對規(guī)范進(jìn)行內(nèi)置，并以此來約束開發(fā)的同學(xué)仔引，降低不規(guī)范模型對后期維護(hù)帶來的壓力扔仓。

這種建模能力的代表有兩種，一種是規(guī)范表的命名肤寝，填寫相應(yīng)的分層+主題域+數(shù)據(jù)域+統(tǒng)計(jì)刷新方式当辐，從源頭上規(guī)范表的目標(biāo)和作用；一種是規(guī)范指標(biāo)的定義和使用鲤看，例如原子指標(biāo)還是派生指標(biāo)缘揪，統(tǒng)計(jì)周期多少，業(yè)務(wù)限定用語如何規(guī)范义桂，統(tǒng)計(jì)粒度怎么填寫找筝。

在實(shí)際開發(fā)中，通過工具的限制慷吊，如果規(guī)范可以做的好袖裕，代碼是可以自動(dòng)生成出來的。當(dāng)然溉瓶，以上的功能急鳄，都屬于通過犧牲開發(fā)效率，來提升數(shù)據(jù)質(zhì)量的范疇堰酿，使用時(shí)需要根據(jù)團(tuán)隊(duì)的情況來限定疾宏。

再次是開發(fā)和測試，這是平臺(tái)提供的最重要的能力触创。在開發(fā)層面坎藐，就是代碼的預(yù)編譯能力+發(fā)布功能。預(yù)編譯不僅要檢查代碼的邏輯是否正確哼绑，同時(shí)對于代碼中依賴的其他數(shù)據(jù)源岩馍，獲取到的元數(shù)據(jù)信息是否準(zhǔn)確，至少字段的命名不會(huì)有大的問題抖韩。當(dāng)代碼預(yù)編譯通過蛀恩，發(fā)布上線后，還需要檢測當(dāng)前是否有資源支持任務(wù)啟動(dòng)茂浮，并且上游的消息隊(duì)列是否是啟動(dòng)的狀態(tài)赦肋。

實(shí)時(shí)的測試一直都是比較大的問題块攒，它不像離線可以啟動(dòng)一個(gè)SQL任務(wù)看看結(jié)果，實(shí)時(shí)在每個(gè)階段的輸入和輸出佃乘，是需要通過平臺(tái)支持的日志打印功能來進(jìn)行輔助的囱井。很多時(shí)候我們會(huì)新建一個(gè)測試專用的topic來測試結(jié)果，但對于流量較大的線上任務(wù)而言趣避，這種方式無法像離線區(qū)分Dev環(huán)境一樣庞呕，能夠?qū)Y源進(jìn)行隔離，因而如果能夠支持圈定數(shù)據(jù)的輸入和打印輸出程帕，對于測試的效率而言無疑是最佳的住练。

最后要提到的是運(yùn)維與監(jiān)控能力。運(yùn)維能力是指根據(jù)輸入的RPS愁拭，或者是cu使用情況讲逛，或者是任務(wù)的整體延遲，提供相應(yīng)的參數(shù)調(diào)優(yōu)能力岭埠，通過參數(shù)來調(diào)整任務(wù)的執(zhí)行情況盏混。并且能夠根據(jù)以上指標(biāo)的變化，自定義相應(yīng)的閾值惜论，提供相應(yīng)的告警能力许赃，通過短信或者是消息工具的方式觸達(dá)任務(wù)維護(hù)者。

實(shí)時(shí)與離線有一些不同的是馆类，離線可以通過增加一個(gè)監(jiān)控節(jié)點(diǎn)的方式混聊，通過group by判斷數(shù)據(jù)是否重復(fù)，而實(shí)時(shí)任務(wù)則非常依賴Flink自身的一致性能力乾巧，因而發(fā)現(xiàn)和解決問題的成本更高句喜。

其實(shí)做到運(yùn)維這個(gè)環(huán)節(jié)，對人的要求其實(shí)是更高的沟于。因?yàn)榱髋惑w在運(yùn)維上會(huì)帶來一個(gè)好處藤滥，即實(shí)時(shí)任務(wù)和離線任務(wù)能夠錯(cuò)峰執(zhí)行，實(shí)時(shí)在白天壓力大社裆，而離線在晚上壓力大。但同樣的向图，這種方式對于維護(hù)者而言更加痛苦泳秀，因?yàn)椴粌H晚上要熬夜值班，白天同樣不能休息榄攀，在大促期間甚至需要輪班來維護(hù)任務(wù)嗜傅，可以說是“匯報(bào)一時(shí)爽，痛苦長相伴”檩赢。

從遠(yuǎn)處來看吕嘀，流任務(wù)和批任務(wù)，在自身的機(jī)制上就存在非常大的差異，批程序面上的是特定時(shí)間內(nèi)相對靜態(tài)的數(shù)據(jù)偶房，而流程序處理的則是change-log趁曼，雖然有可能數(shù)據(jù)在表結(jié)構(gòu)層面，通過數(shù)據(jù)模型的設(shè)計(jì)來保持一致棕洋，但是在語義層面挡闰，其根本還是不一樣的。這一點(diǎn)可能是最制約批流一體發(fā)展的問題掰盘，也是最難實(shí)現(xiàn)統(tǒng)一或者永遠(yuǎn)也不可能統(tǒng)一的摄悯。

綜上，對于實(shí)時(shí)模型愧捕，開發(fā)工具需要將監(jiān)控實(shí)時(shí)部分的能力進(jìn)行補(bǔ)全奢驯，就像DWD層需要分別維護(hù)實(shí)時(shí)和離線兩套架構(gòu)一樣，開發(fā)工具也需要分別維護(hù)兩套架構(gòu)的結(jié)果次绘，因而現(xiàn)階段的實(shí)時(shí)開發(fā)瘪阁，還做不到降低維護(hù)和開發(fā)的成本，只能減輕其中部分環(huán)節(jié)的工作量断盛。

|0xFF 流批一體的價(jià)值取決于業(yè)務(wù)方

以上講了很長時(shí)間的實(shí)時(shí)模型罗洗，但從實(shí)際的效果上看，業(yè)務(wù)并不會(huì)感知到多么明顯的技術(shù)變化钢猛，相反會(huì)有一種“面子工程”的感覺在里面伙菜。

當(dāng)然，我并不否認(rèn)實(shí)時(shí)的價(jià)值命迈，在“搜廣推”這三個(gè)技術(shù)占主導(dǎo)的領(lǐng)域內(nèi)贩绕，作用還是很大的。但實(shí)時(shí)畢竟要比離線的內(nèi)容壶愤，更加的難以理解淑倾，出現(xiàn)問題的排查成本也更高。這種復(fù)雜性使得我們在應(yīng)對變化時(shí)征椒，往往做不出有效的應(yīng)對娇哆，就會(huì)變得特別被動(dòng)。

因而勃救，說一句事后的話碍讨，就是“實(shí)時(shí)的價(jià)值取決于業(yè)務(wù)方，而不是技術(shù)方”蒙秒。只有業(yè)務(wù)對實(shí)時(shí)痛點(diǎn)強(qiáng)烈的場景下勃黍，我們做如此復(fù)雜的研究和應(yīng)對，才能體現(xiàn)出自己的價(jià)值晕讲，更多的時(shí)候覆获，是在“王婆賣瓜马澈，自賣自夸”。有這種投入弄息，還不如多招幾個(gè)分析師更靠譜和實(shí)在痊班。

本人之前的文章《天下數(shù)據(jù)，唯快不破》疑枯，重點(diǎn)強(qiáng)調(diào)了一個(gè)“快”字辩块。但“天下熙熙皆為利來，天下攘攘皆為利往”荆永，這個(gè)快更多的是在講應(yīng)對“變化”的快废亭，而不是“技術(shù)”自己的快。

所以具钥，為了以后的職業(yè)發(fā)展豆村，我們要跟進(jìn)實(shí)時(shí)技術(shù)的變化，但從自身的工作角度出發(fā)骂删，如何應(yīng)對業(yè)務(wù)的變化掌动，才是自己要關(guān)心的課題。