背景介紹
電商是移動(dòng)互聯(lián)網(wǎng)時(shí)代最重要的業(yè)務(wù)形式之一笨忌，目前主流的業(yè)務(wù)形態(tài)是B2C。在這個(gè)群雄逐鹿的年代俱病，除了淘寶官疲、京東袱结、拼多多等頭部電商以外，還活躍著眾多的中小規(guī)模電商平臺(tái)途凫。筆者所在公司的電商APP就是其中一個(gè)垢夹，目前注冊(cè)用戶超過2億，月活躍用戶接近2000萬维费。
電商平臺(tái)以APP作為載體果元，最重要的數(shù)據(jù)就是以訂單為核心的結(jié)構(gòu)化數(shù)據(jù)和以日志流為核心的半結(jié)構(gòu)化數(shù)據(jù)，這也互聯(lián)網(wǎng)業(yè)務(wù)最典型的應(yīng)用場(chǎng)景犀盟。
訂單業(yè)務(wù)包括下單而晒、支付、發(fā)貨阅畴、物流倡怎、評(píng)價(jià)、退貨等業(yè)務(wù)流程贱枣，但是都可以通過order_id串聯(lián)起來诈胜，數(shù)據(jù)保存在關(guān)系型數(shù)據(jù)庫(kù)中。我們這邊通過MySQL分庫(kù)分表方案承載訂單相關(guān)的業(yè)務(wù)數(shù)據(jù)冯事，目前積累了自系統(tǒng)上線以來的1.5億訂單焦匈，目前日增長(zhǎng)訂單數(shù)為10萬左右。
點(diǎn)擊流數(shù)據(jù)則是APP上所有用戶的操作行為埋點(diǎn)記錄數(shù)據(jù)昵仅，是源源不斷產(chǎn)生的半結(jié)構(gòu)化數(shù)據(jù)缓熟。由于前期對(duì)APP埋點(diǎn)和日志流數(shù)據(jù)做過治理，所以目前數(shù)據(jù)格式比較規(guī)范摔笤，數(shù)據(jù)輸出也比較穩(wěn)定够滑。點(diǎn)擊流數(shù)據(jù)包括30+固定字段和一個(gè)擴(kuò)展json字段組成，固定字段包括設(shè)備信息吕世、會(huì)話信息彰触、用戶信息、網(wǎng)絡(luò)信息命辖、埋點(diǎn)編碼等况毅，擴(kuò)展json字段內(nèi)容則根據(jù)實(shí)際的頁面情況生成，不同的頁面或者埋點(diǎn)對(duì)應(yīng)的擴(kuò)展信息不同尔艇。點(diǎn)擊流數(shù)據(jù)每日增量在10億左右尔许，ORC格式占用存儲(chǔ)在1.16T左右。
筆者接手電商數(shù)倉(cāng)項(xiàng)目時(shí)终娃，恰逢公司推進(jìn)數(shù)據(jù)治理項(xiàng)目味廊，準(zhǔn)備重建電商數(shù)倉(cāng)。在我接手之前，公司數(shù)倉(cāng)按照不同的業(yè)務(wù)模塊劃分不同的數(shù)據(jù)集市余佛，電商業(yè)務(wù)有專門的電商集市柠新，但是內(nèi)部數(shù)據(jù)加工邏輯比較復(fù)雜、沒有明確的數(shù)據(jù)分層和清晰的數(shù)據(jù)處理邏輯辉巡，基本上是面向需求開發(fā)恨憎，重復(fù)邏輯比較多，數(shù)據(jù)一致性差红氯。我接手電商數(shù)倉(cāng)以后框咙，按照標(biāo)準(zhǔn)的數(shù)倉(cāng)分層重構(gòu)了電商數(shù)倉(cāng)咕痛，同步產(chǎn)出實(shí)時(shí)數(shù)據(jù)痢甘，滿足了實(shí)時(shí)數(shù)據(jù)看板、自助分析數(shù)據(jù)集茉贡、雙十一大屏塞栅、每日業(yè)績(jī)播報(bào)等多個(gè)數(shù)據(jù)應(yīng)用。恰逢最近經(jīng)歷了新一輪618大促的考驗(yàn)腔丧，因此予以總結(jié)放椰，形成經(jīng)驗(yàn)分享給其他數(shù)倉(cāng)開發(fā)的同行。
02
技術(shù)選型
數(shù)據(jù)中臺(tái)作為公司統(tǒng)一的數(shù)據(jù)平臺(tái)愉粤，承載著全公司大數(shù)據(jù)集群平臺(tái)的基礎(chǔ)能力砾医，包括離線集群Hive、Hdfs衣厘、Yarn如蚜、Spark和Presto，實(shí)時(shí)集群Flink影暴、ClickHouse错邦，以及相關(guān)工具如自助分析工具QuickBI、調(diào)度系統(tǒng)型宙、畫像系統(tǒng)撬呢、監(jiān)控告警系統(tǒng)、基于Zepplin的統(tǒng)一數(shù)據(jù)查詢平臺(tái)等妆兑。
公司的離線大數(shù)據(jù)有400多臺(tái)服務(wù)器魂拦，基于Yarn框架進(jìn)行統(tǒng)一的資源管理，計(jì)算資源分為離線計(jì)算搁嗓、實(shí)時(shí)計(jì)算晨另、實(shí)時(shí)查詢等不同的資源隊(duì)列，其中離線計(jì)算目前以Spark為主谱姓，部分高優(yōu)先級(jí)的任務(wù)或者時(shí)效性較高的任務(wù)已經(jīng)切換到內(nèi)部改造過的Presto計(jì)算引擎借尿。目前公司大數(shù)據(jù)平臺(tái)上運(yùn)行的離線數(shù)據(jù)處理任務(wù)主要分為MySQL2Hive數(shù)據(jù)采集、Hive2Hive數(shù)據(jù)加工、Hive2MySQL數(shù)據(jù)分發(fā)和Hive2CK數(shù)據(jù)分發(fā)四種類型路翻，任務(wù)數(shù)分別是1.0W狈癞、1.2W、6K茂契、500蝶桶。
實(shí)時(shí)數(shù)據(jù)處理分為實(shí)時(shí)數(shù)據(jù)采集、實(shí)時(shí)數(shù)據(jù)計(jì)算和實(shí)時(shí)數(shù)據(jù)查詢?nèi)齻€(gè)方面掉冶。實(shí)時(shí)數(shù)據(jù)采集通過自動(dòng)化配置真竖，直接寫入Hive數(shù)倉(cāng)的rt_ods庫(kù)，目前有接近1000張表厌小；實(shí)時(shí)數(shù)據(jù)計(jì)算目前主要是交給Flink完成恢共，目前線上運(yùn)行的大約500個(gè)任務(wù)；實(shí)時(shí)數(shù)據(jù)查詢包括MySQL和Clickhouse璧亚，接入數(shù)據(jù)量不確定讨韭。
早期的數(shù)據(jù)結(jié)果查詢都是基于MySQL分庫(kù)分表來實(shí)現(xiàn)，2021年底開始引入ClickHouse作為交互式查詢引擎癣蟋。選擇ClickHouse的原因主要是由于查詢性能快透硝、查詢穩(wěn)定，只要設(shè)置合理的分區(qū)疯搅，單表數(shù)據(jù)量可以達(dá)到百億甚至千億級(jí)別濒生。目前公司在多個(gè)業(yè)務(wù)線引入了ClickHouse集群，在大數(shù)據(jù)線幔欧，ClickHouse集群主要替代MySQL分庫(kù)分表方案罪治，來實(shí)現(xiàn)數(shù)據(jù)的快速實(shí)時(shí)查詢。大數(shù)據(jù)線的ClickHouse集群由28臺(tái)節(jié)點(diǎn)組成14主*2副本集群琐馆，每臺(tái)節(jié)點(diǎn)84核CPU+256G內(nèi)存规阀。
03
電商離線數(shù)倉(cāng)
離線數(shù)倉(cāng)總體上分為三層，即ODS瘦麸、DW和DM層谁撼。
ODS層也叫數(shù)據(jù)采集層，數(shù)據(jù)來源于源系統(tǒng)滋饲，保留源系統(tǒng)概貌厉碟，為上游邏輯層提供原始數(shù)據(jù)，隔離對(duì)源系統(tǒng)的影響屠缭。我們這邊分為SNAP箍鼓、ODS、History三個(gè)數(shù)據(jù)庫(kù)呵曹，分別存放快照數(shù)據(jù)款咖、增量追加數(shù)據(jù)和全量歷史快照數(shù)據(jù)何暮。對(duì)于全量采集的數(shù)據(jù)，直接抽取到SNAP庫(kù)铐殃；對(duì)于增量采集的數(shù)據(jù)默認(rèn)會(huì)按照修改日期抽取最近一天新增或者修改的數(shù)據(jù)海洼，按日分區(qū)存入ODS庫(kù)，然后按照庫(kù)表主鍵合并去重寫入SNAP庫(kù)富腊；對(duì)于有保存歷史快照數(shù)據(jù)需求的表坏逢，我們還會(huì)將歷史快照復(fù)制一份按日保存到History庫(kù)。
DW層也叫數(shù)據(jù)倉(cāng)庫(kù)層赘被，我們分為DIM是整、DWD和DWS三個(gè)庫(kù)。
DIM庫(kù)用于保存公共維度數(shù)據(jù)民假，例如商品浮入、商戶、供應(yīng)商阳欲、用戶基礎(chǔ)信息等舵盈。
DWD層也叫明細(xì)模型層陋率，數(shù)據(jù)來源于ODS層球化，根據(jù)上游提供原始數(shù)據(jù)，劃分?jǐn)?shù)據(jù)主題瓦糟，對(duì)ODS層數(shù)據(jù)進(jìn)行關(guān)聯(lián)整合筒愚。DWD層用于保存業(yè)務(wù)明細(xì)數(shù)據(jù)，只做簡(jiǎn)單的數(shù)據(jù)加工和多表關(guān)聯(lián)菩浙，得到按照主題域和數(shù)據(jù)域劃分的明細(xì)數(shù)據(jù)表巢掺。
DWS層也叫輕度匯總層，數(shù)據(jù)主要來源于DWD層劲蜻，以指標(biāo)加工為核心陆淀，按照維度建模的思路，加工一致性指標(biāo)和一致性維度先嬉。DWS層也包括寬表層轧苫，所以DWS通常可以劃分為兩步進(jìn)行數(shù)據(jù)加工疫蔓，第一步聚焦于指標(biāo)計(jì)算含懊，統(tǒng)一加工業(yè)務(wù)指標(biāo)，第二步關(guān)聯(lián)維度信息衅胀，形成大寬表岔乔。有時(shí)候會(huì)把大寬表叫做DWT層，但是我們這邊沒有嚴(yán)格的區(qū)分滚躯。DWS層的寬表通常都是同步到ClickHouse雏门，用于自助分析或者固定報(bào)表查詢嘿歌。
DM層也叫集市層或者數(shù)據(jù)應(yīng)用層，數(shù)據(jù)來源主要來自DWS層茁影，可按業(yè)務(wù)和應(yīng)用主題分類搅幅，滿足特定應(yīng)用查詢。DM數(shù)據(jù)主要保存在Hive數(shù)倉(cāng)的DM庫(kù)和對(duì)接數(shù)據(jù)應(yīng)用的MySQL庫(kù)呼胚、ClickHouse庫(kù)茄唐。對(duì)于數(shù)據(jù)量超過千萬的明細(xì)數(shù)據(jù)分析，數(shù)據(jù)會(huì)直接同步到ClickHouse庫(kù)蝇更；對(duì)于百萬級(jí)以下的數(shù)據(jù)沪编，則直接保存到MySQL數(shù)據(jù)庫(kù)。此外年扩，還有應(yīng)用層的用戶畫像數(shù)據(jù)保存在HBase蚁廓。DM層的大部分?jǐn)?shù)據(jù)直接來源于DWS，也有有些數(shù)據(jù)是在DWS層的基礎(chǔ)上進(jìn)行二次加工厨幻，包括簡(jiǎn)單匯總相嵌、計(jì)算同環(huán)比、多維匯總等况脆，先寫入DM層饭宾，再同步到外部數(shù)據(jù)庫(kù)。
具體到電商數(shù)倉(cāng)模塊格了，我們主要構(gòu)建了以下幾個(gè)模型表：
當(dāng)然看铆，實(shí)際項(xiàng)目上設(shè)計(jì)和建設(shè)的模型遠(yuǎn)不止這幾張表，我們還針對(duì)售后訂單創(chuàng)建單獨(dú)的表盛末、根據(jù)埋點(diǎn)業(yè)務(wù)的運(yùn)營(yíng)位曝光和點(diǎn)擊計(jì)算下單成交率弹惦、根據(jù)商品的推薦計(jì)算推薦模型的有效性，根據(jù)搜索的結(jié)果及點(diǎn)擊計(jì)算不同入口的搜索成交情況等等悄但。但是項(xiàng)目主要的核心的訂單和點(diǎn)擊數(shù)據(jù)流就是這10張表棠隐，其中商品標(biāo)簽表和用戶標(biāo)簽表還作為電商業(yè)務(wù)商品畫像和用戶畫像的基礎(chǔ)數(shù)據(jù)來源表，提供畫像標(biāo)簽的統(tǒng)一出口檐嚣。
04
電商實(shí)時(shí)數(shù)倉(cāng)
在離線數(shù)據(jù)加工的基礎(chǔ)上助泽，業(yè)務(wù)用戶提出來實(shí)時(shí)數(shù)據(jù)的需求，主要包括企業(yè)微信業(yè)績(jī)播報(bào)機(jī)器人和實(shí)時(shí)交易看板净嘀、實(shí)時(shí)成交監(jiān)控报咳、雙十一大屏等。
最開始開發(fā)的是企業(yè)微信業(yè)績(jī)播報(bào)機(jī)器人需求挖藏，每小時(shí)匯總一次當(dāng)日成交數(shù)據(jù)暑刃，并和歷史成交進(jìn)行對(duì)比，將數(shù)據(jù)寫入MySQL膜眠，再由Java程序讀取數(shù)據(jù)岩臣，按照指定的數(shù)據(jù)格式播報(bào)到企業(yè)微信群溜嗜。
針對(duì)這個(gè)業(yè)務(wù)場(chǎng)景，我們按照典型的Lambda架構(gòu)設(shè)計(jì)架谎，復(fù)用公司的Kafka寫入Hive數(shù)據(jù)組件炸宵，通過配置化實(shí)現(xiàn)關(guān)鍵業(yè)務(wù)數(shù)據(jù)自動(dòng)同步到Hive的rt_ods數(shù)據(jù)庫(kù)。然后我們通過Presto計(jì)算引擎簡(jiǎn)化訂單業(yè)務(wù)的加工邏輯谷扣，只計(jì)算關(guān)鍵成交指標(biāo)土全，加工到DWS，并和離線數(shù)據(jù)加工的DWS層數(shù)據(jù)進(jìn)行合并去重会涎，保留最近13個(gè)月的訂單明細(xì)裹匙。點(diǎn)擊流數(shù)據(jù)不需去重，只保留當(dāng)日末秃、上月環(huán)期和去年同期三個(gè)日期的明細(xì)數(shù)據(jù)概页，并加工好關(guān)鍵指標(biāo)，保留明細(xì)數(shù)據(jù)练慕。最后一步是加工計(jì)算本期惰匙、同期、環(huán)期的不同指標(biāo)铃将，并分別按照商品維度和用戶維度進(jìn)行數(shù)據(jù)匯總项鬼，寫入MySQL供JAVA應(yīng)用查詢。
第一代實(shí)時(shí)數(shù)倉(cāng)架構(gòu)
將實(shí)時(shí)播報(bào)任務(wù)串聯(lián)成工作流麸塞，按照一小時(shí)一次的頻率執(zhí)行秃臣，截圖如下：
實(shí)時(shí)播報(bào)滿足了業(yè)務(wù)用戶跟蹤業(yè)績(jī)進(jìn)展的需求涧衙，但是時(shí)效性比較差哪工，無法滿足實(shí)時(shí)成交監(jiān)控、實(shí)時(shí)看板和大促大屏的需求弧哎，于是我們又進(jìn)一步開發(fā)了新的實(shí)時(shí)鏈路雁比，即Flink實(shí)時(shí)鏈路。
第二代實(shí)時(shí)數(shù)倉(cāng)架構(gòu)
Flink實(shí)時(shí)鏈路主要由兩個(gè)FlinkSQL任務(wù)組成撤嫩，分別讀取訂單CDC日志流數(shù)據(jù)和點(diǎn)擊埋點(diǎn)日志流數(shù)據(jù)偎捎，在進(jìn)行簡(jiǎn)單的數(shù)據(jù)轉(zhuǎn)換以后關(guān)聯(lián)離線加工的商品信息表（定時(shí)同步到HBase，全量1600萬）獲取商品維度然后寫入Clickhouse序攘。在電商業(yè)務(wù)的多維分析中茴她，最主要的維度就是商品維度和用戶維度，其中商品維度包括商戶信息程奠、商品層級(jí)信息丈牢、商品規(guī)格信息、商品業(yè)務(wù)歸屬瞄沙、商品價(jià)格和進(jìn)貨渠道等己沛，用戶維度包括用戶注冊(cè)信息慌核、用戶基本屬性、用戶成交記錄和用戶衍生標(biāo)簽申尼。在我們的業(yè)務(wù)場(chǎng)景中垮卓，商品維度是千萬級(jí)別，用戶維度是億級(jí)別师幕，經(jīng)過測(cè)試粟按，在實(shí)時(shí)點(diǎn)擊流中，由于數(shù)據(jù)流量比較大霹粥，關(guān)聯(lián)用戶信息會(huì)出現(xiàn)查詢超時(shí)導(dǎo)致關(guān)聯(lián)不上的場(chǎng)景钾怔，因?yàn)槲覀兛车袅藢?shí)時(shí)數(shù)據(jù)的用戶維度，而選擇在ClickHouse進(jìn)行結(jié)果數(shù)據(jù)查詢時(shí)再利用Local Join的優(yōu)勢(shì)來關(guān)聯(lián)用戶維度蒙挑。實(shí)時(shí)加工數(shù)據(jù)在ClickHouse中設(shè)置的TTL時(shí)間是3天宗侦，即僅保留最近三天的實(shí)時(shí)數(shù)據(jù)。
Flink實(shí)時(shí)鏈路的關(guān)鍵在于ClickHouse,我們首先將離線加工好的訂單寬表忆蚀、點(diǎn)擊流寬表和用戶維度信息表在每天跑批完成以后同步到Clickhouse(其中訂單寬表是每日全量同步最近三個(gè)自然年的數(shù)據(jù)矾利，點(diǎn)擊流每日增量同步昨日數(shù)據(jù))，然后通過一個(gè)視圖來合并離線數(shù)據(jù)和實(shí)時(shí)數(shù)據(jù)馋袜，對(duì)外提供純實(shí)時(shí)的一致性數(shù)據(jù)結(jié)果男旗。
在ClickHouse這邊主要處理邏輯有以下幾點(diǎn)：
1.離線數(shù)據(jù)取下單（點(diǎn)擊）日期小于當(dāng)日的數(shù)據(jù)，實(shí)時(shí)數(shù)據(jù)取離線數(shù)據(jù)沒有的下單（點(diǎn)擊）日期對(duì)應(yīng)的數(shù)據(jù)欣鳖。這是為了避免在凌晨時(shí)離線數(shù)據(jù)還沒有跑出來察皇，導(dǎo)致查詢昨日沒有數(shù)據(jù)的情況。
2.實(shí)時(shí)數(shù)據(jù)關(guān)聯(lián)用戶維度泽台，取用戶注冊(cè)時(shí)間和用戶引流渠道等信息什荣。基于ClickHouse的特性怀酷，我們將所有接入的數(shù)據(jù)默認(rèn)按照fuid的hash值進(jìn)行數(shù)據(jù)分片稻爬，確保同一個(gè)用戶的訂單、點(diǎn)擊數(shù)據(jù)和用戶維度數(shù)據(jù)在同一個(gè)數(shù)據(jù)分片上蜕依，既可以實(shí)現(xiàn)Join的本地化桅锄，又能減少用戶數(shù)去重計(jì)算的資源消耗。為了強(qiáng)制join在本地進(jìn)行样眠，我們會(huì)直接在SQL中使用右表的local表進(jìn)行關(guān)聯(lián)友瘤。
3.根據(jù)訂單和點(diǎn)擊流的不同特點(diǎn)，承接訂單實(shí)時(shí)數(shù)據(jù)的表我們采用ReplicatedReplacingMergeTree引擎表檐束，點(diǎn)擊流實(shí)時(shí)數(shù)據(jù)表則采用ReplicatedMergeTree引擎表辫秧。在使用訂單實(shí)時(shí)數(shù)據(jù)時(shí)，我們會(huì)在表名后增加final關(guān)鍵字厢塘，確保讀取到最新的數(shù)據(jù)茶没。
Flink實(shí)時(shí)數(shù)據(jù)由于實(shí)時(shí)性高肌幽、數(shù)據(jù)完整度高并且基本上都是明細(xì)數(shù)據(jù)，可以滿足各種業(yè)務(wù)場(chǎng)景抓半，因此在這個(gè)數(shù)據(jù)集基礎(chǔ)上我們創(chuàng)建實(shí)時(shí)成交看板喂急、實(shí)時(shí)監(jiān)控預(yù)警和大促大屏等應(yīng)用需求。下一部分笛求，我們將具體展開數(shù)據(jù)應(yīng)用場(chǎng)景的方案解讀廊移。
05
數(shù)據(jù)應(yīng)用
在電商數(shù)倉(cāng)的基礎(chǔ)上，我們構(gòu)建了自助分析探入、固定報(bào)表狡孔、企業(yè)微信播報(bào)、標(biāo)簽畫像蜂嗽、大促大屏等多個(gè)數(shù)據(jù)應(yīng)用苗膝。其中，自助分析和固定報(bào)表都是基于QuickBI實(shí)現(xiàn)的植旧，企業(yè)微信播報(bào)是Java程序辱揭，標(biāo)簽畫像是自研系統(tǒng)，大促大屏是基于VUE開發(fā)的Web應(yīng)用病附。
首先是自助分析问窃，我們基于訂單數(shù)據(jù)和點(diǎn)擊流數(shù)據(jù)各自構(gòu)建了一個(gè)寬表并同步到ClickHouse，不同的類目運(yùn)營(yíng)用戶和數(shù)據(jù)產(chǎn)品都可以基于這兩個(gè)自主數(shù)據(jù)構(gòu)建自己的看板完沪，并分享給其他同事域庇。自助分析數(shù)據(jù)集根據(jù)用戶的需求還在不停的追加字段，完成各種實(shí)驗(yàn)場(chǎng)景分析覆积、用戶成交分析和經(jīng)營(yíng)利潤(rùn)分析听皿。訂單寬表已經(jīng)擴(kuò)充到了256個(gè)字段，還有不少的用戶標(biāo)簽和商品標(biāo)簽封裝在fuser_label_json和fsku_label_json兩個(gè)json字段中技健。目前写穴，訂單自助數(shù)據(jù)集是使用用戶最多，應(yīng)用最廣泛的數(shù)據(jù)集雌贱。
其次是固定報(bào)表。在自助分析數(shù)據(jù)集的基礎(chǔ)上偿短，我們構(gòu)建了業(yè)務(wù)經(jīng)營(yíng)日?qǐng)?bào)欣孤、KPI進(jìn)度監(jiān)控等固定報(bào)表，滿足管理層經(jīng)營(yíng)數(shù)據(jù)分析需求昔逗。這些報(bào)表主要在同環(huán)比降传、日周月年等維度上有一些特殊處理，導(dǎo)致需要做一些定制化開發(fā)勾怒，所以由我們數(shù)倉(cāng)完成婆排。
第三個(gè)應(yīng)用是前面提到的企業(yè)微信播報(bào)声旺，這里只截取其中一部分內(nèi)容展現(xiàn)。企業(yè)微信從早上9點(diǎn)到晚上24點(diǎn)段只，每小時(shí)播報(bào)一次腮猖。其中最難的是24點(diǎn)以后的那次播報(bào)，需要做很多特殊處理赞枕，才能實(shí)現(xiàn)澈缺。
標(biāo)簽系統(tǒng)提供單個(gè)用戶查詢標(biāo)簽值和標(biāo)簽組合圈選用戶兩個(gè)功能，前者用于在線接口調(diào)用涯贞，后者用于導(dǎo)出用戶進(jìn)行分析或者廣告投放杖们。
第五個(gè)應(yīng)用是大促大屏。我們參照阿里雙十一大屏肩狂，構(gòu)建了實(shí)時(shí)大促大屏摘完，包括實(shí)時(shí)成交額、大促期間累計(jì)成交額傻谁、用戶分類成交金額及本同期對(duì)比孝治、商品分類成交金額及本同期對(duì)比。
06
后續(xù)演進(jìn)和流批一體探索
目前第二代實(shí)時(shí)架構(gòu)已經(jīng)穩(wěn)定運(yùn)行了接近一年時(shí)間审磁，做過一些修修補(bǔ)補(bǔ)的微調(diào)谈飒，但是整體架構(gòu)沒有變動(dòng)過。這中間遇到的痛點(diǎn)主要有：
①離線數(shù)據(jù)跑完以后态蒂，昨日的實(shí)時(shí)成交數(shù)據(jù)會(huì)提高杭措，但是第三天又會(huì)下降。這是因?yàn)殡x線數(shù)據(jù)是以12點(diǎn)作為快照時(shí)間點(diǎn)計(jì)算的钾恢，后面的成交或者退款數(shù)據(jù)在實(shí)時(shí)里面可以體現(xiàn)手素，但是離線需要到第三天才能體現(xiàn)。這個(gè)問題在大促期間暴露比較明顯瘩蚪。
②商品維度數(shù)據(jù)一天只更新一次泉懦，導(dǎo)致當(dāng)日上線的商品在統(tǒng)計(jì)時(shí)丟失，或者商品層級(jí)調(diào)整不能實(shí)時(shí)體現(xiàn)到看板中疹瘦。
③流處理SQL封裝在Flink管理平臺(tái)中崩哩，批處理SQL封裝在調(diào)度平臺(tái)，導(dǎo)致兩邊容易出現(xiàn)邏輯不一致的情況。
④點(diǎn)擊流數(shù)據(jù)積累過多以后邓嘹，ClickHouse存儲(chǔ)和查詢性能出現(xiàn)瓶頸酣栈，但是集群擴(kuò)容又比較困難，導(dǎo)致我們點(diǎn)擊流數(shù)據(jù)只保留最近半年數(shù)據(jù)并且一次最多查詢一個(gè)月的數(shù)據(jù)汹押，用戶滿意度降低矿筝。
⑤維度變更導(dǎo)致點(diǎn)擊流數(shù)據(jù)統(tǒng)計(jì)出現(xiàn)異常，比如商品類目鲸阻、用戶分類等跋涣。
面對(duì)以上這些問題，我們開啟了第三代實(shí)時(shí)架構(gòu)的設(shè)計(jì)和驗(yàn)證之路鸟悴。第三代實(shí)時(shí)架構(gòu)我們引入了基于數(shù)據(jù)湖的流批一體模式和基于OLAP數(shù)據(jù)庫(kù)的多維實(shí)時(shí)數(shù)據(jù)查詢模式陈辱。在數(shù)據(jù)湖方面，經(jīng)過多方對(duì)比细诸，最終選擇Hudi作為數(shù)據(jù)湖底座沛贪，繼續(xù)沿用Flink進(jìn)行流式數(shù)據(jù)加工，選擇Doris作為查詢引擎震贵。
選擇Hudi的原因是：
①數(shù)據(jù)湖技術(shù)中Hudi目前最成熟利赋，并且有很多案例分享；
②Hudi支持流式數(shù)據(jù)寫入和流式數(shù)據(jù)讀取猩系，可以滿足我們保存中間過程數(shù)據(jù)的需求媚送；
③Hudi支持索引，可以更快的檢索數(shù)據(jù)寇甸。
④Hudi和當(dāng)前的HDFS存儲(chǔ)底座結(jié)合更好塘偎。
選擇Doris的原因有很多，例如支持多表關(guān)聯(lián)拿霉、方便擴(kuò)展吟秩、支持多種數(shù)據(jù)模型、支持多種索引機(jī)制和查詢優(yōu)化绽淘，還支持存算分離遷移歷史數(shù)據(jù)到對(duì)象存儲(chǔ)涵防，直接查詢外部數(shù)據(jù)源。更詳細(xì)的關(guān)于Doris的特點(diǎn)和使用方法沪铭，歡迎購(gòu)買筆者撰寫的《Doris實(shí)時(shí)數(shù)倉(cāng)實(shí)戰(zhàn)》一書壮池。有了Doris，最大的好處是我們可以做到維度解耦伦意，可以在查詢的時(shí)候才進(jìn)行關(guān)聯(lián)火窒，一方面減少了數(shù)據(jù)存儲(chǔ)空間占用，另一方面避免了歷史維度不一致的情況驮肉。
總體來說，我們的第三代實(shí)時(shí)數(shù)倉(cāng)架構(gòu)如下：
采用這種流批一體的架構(gòu)，可以解決流數(shù)據(jù)和實(shí)時(shí)數(shù)據(jù)切換時(shí)成交金額回退的情況渴频；同時(shí)保留中間過程數(shù)據(jù)聋丝，可以邏輯變更導(dǎo)致需要回溯歷史重算的情況躏哩；引入獨(dú)立的OLAP查詢引擎页响，可以解決查詢的性能問題和多表關(guān)聯(lián)問題垦江。
雖然理想狀態(tài)下侄非，所有數(shù)據(jù)都通過Flink流式進(jìn)行加工片拍，但是經(jīng)過調(diào)研浪读，我們還是有一些數(shù)據(jù)的邏輯無法做到純流處理昔榴，比如用戶下單時(shí)是新用戶還是老用戶，所以我們還是保留了批處理的鏈路碘橘，批處理的數(shù)據(jù)通過Spark加工完成以后互订，直接寫入Doris更新主鍵模型的部分列。
目前這個(gè)方案已經(jīng)驗(yàn)證完成痘拆，正在進(jìn)行配套平臺(tái)的搭建和持續(xù)運(yùn)行監(jiān)控仰禽，預(yù)計(jì)Q4會(huì)全面鋪開應(yīng)用。
相比第一代架構(gòu)和第二代架構(gòu)纺蛆，我們最大的特點(diǎn)就是用Doris代替了ClickHouse吐葵。雖然ClickHouse快并且穩(wěn)定，但是其使用門檻較高桥氏、擴(kuò)展性較差温峭，元數(shù)據(jù)用ZooKeeper管理，在我們這邊已經(jīng)達(dá)到瓶頸字支，并且在實(shí)時(shí)數(shù)據(jù)高頻寫入的場(chǎng)景容易出現(xiàn)元數(shù)據(jù)管理異常導(dǎo)致數(shù)據(jù)寫入失敗的情況凤藏。
Apache Doris作為一款國(guó)產(chǎn)開源數(shù)據(jù)庫(kù)軟件，不僅實(shí)現(xiàn)了向量化引擎祥款、存算分離清笨、Merge on Write等前沿功能，還開創(chuàng)性的融合了數(shù)據(jù)分桶刃跛、行列混合存儲(chǔ)抠艾、多種索引支持、多種數(shù)據(jù)模型等功能到MPP數(shù)據(jù)庫(kù)中桨昙，是OLAP和數(shù)據(jù)倉(cāng)庫(kù)領(lǐng)域冉冉升起的新星检号。《Doris實(shí)時(shí)數(shù)倉(cāng)實(shí)戰(zhàn)》一書囊括Doris的基本操作蛙酪、架構(gòu)設(shè)計(jì)齐苛、進(jìn)階使用、運(yùn)維管理桂塞、拓展應(yīng)用等各方面的內(nèi)容凹蜂，還有大量的具體項(xiàng)目實(shí)踐經(jīng)驗(yàn)分析，非常適合想使用Doris進(jìn)行數(shù)倉(cāng)開發(fā)的小伙伴學(xué)習(xí)。目前Doris社區(qū)非陈耆活躍汰瘫，功能還在不斷迭代和演化中，Doris背后的商業(yè)公司飛輪科技也給予了Doris發(fā)展非常大的助力擂煞，Apache Doris一定能成為一款具有全球影響力的開源產(chǎn)品混弥。
今天的分享就到這里，謝謝大家对省。
