基于Lambda架構(gòu)的實(shí)時(shí)電商數(shù)倉(cāng)建設(shè)經(jīng)驗(yàn)

文目錄：.電商離線數(shù)倉(cāng)4.電商實(shí)時(shí)數(shù)倉(cāng).電商數(shù)據(jù)應(yīng)用6.后續(xù)演進(jìn)和流批一體探索分享嘉賓|王春波高級(jí)數(shù)倉(cāng)工程師《Doris實(shí)時(shí)數(shù)倉(cāng)實(shí)戰(zhàn)》作者文字校對(duì)|志明與數(shù)據(jù)出品社區(qū)|DataFun01背景介紹最重要的業(yè)務(wù)形式之一，目前主流的業(yè)務(wù)形態(tài)是B2C。在這個(gè)群雄逐鹿的年代，除了淘寶、京東、拼多多等頭部電商以外，還活躍著眾多的中小規(guī)模電商平臺(tái)。筆者所在公司的電商APP就是其中一個(gè)，目前注冊(cè)用戶超過(guò)2億，月活躍用戶接APP為載體，最重要的數(shù)據(jù)就是以訂單為核心的結(jié)構(gòu)化數(shù)據(jù)和以日志流為訂單業(yè)務(wù)包括下單、支付、發(fā)貨、物流、評(píng)價(jià)、退貨等業(yè)務(wù)流程，但是都可以通過(guò)order_id串聯(lián)起來(lái)，數(shù)據(jù)保存在關(guān)系型數(shù)據(jù)庫(kù)中。我們這邊通過(guò)MySQL分庫(kù)分表方案承載訂單相關(guān)的業(yè)務(wù)數(shù)據(jù)，目前積累了自系統(tǒng)上線以來(lái)的1.5億訂單，目前日增長(zhǎng)訂單數(shù)為點(diǎn)擊流數(shù)據(jù)則是APP上所有用戶的操作行為埋點(diǎn)記錄數(shù)據(jù)，是源源不斷產(chǎn)生的半結(jié)構(gòu)化數(shù)據(jù)。由于前期對(duì)APP埋點(diǎn)和日志流數(shù)據(jù)做過(guò)治理，所以目前數(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í)際的頁(yè)面情況生成，不同的頁(yè)面或者埋點(diǎn)對(duì)應(yīng)的擴(kuò)展信息不同。點(diǎn)擊流數(shù)據(jù)每日增量在筆者接手電商數(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ù)雜、沒(méi)有明確的數(shù)據(jù)分層和清晰的數(shù)據(jù)處理邏輯，基本上是面向需求開(kāi)發(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大促的考型數(shù)據(jù)中臺(tái)作為公司統(tǒng)一的數(shù)據(jù)平臺(tái)，承載著全公司大數(shù)據(jù)集群平臺(tái)的基礎(chǔ)能力，包括離e如自助分析工具QuickBI、調(diào)度系統(tǒng)、畫(huà)像系統(tǒng)、監(jiān)控告警系統(tǒng)、基于Zepplin的統(tǒng)一數(shù)據(jù)多臺(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)部改造過(guò)的Presto計(jì)算引擎。目ive實(shí)時(shí)數(shù)據(jù)處理分為實(shí)時(shí)數(shù)據(jù)采集、實(shí)時(shí)數(shù)據(jù)計(jì)算和實(shí)時(shí)數(shù)據(jù)查詢?nèi)齻€(gè)方面。實(shí)時(shí)數(shù)據(jù)采集通過(guò)自動(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ù)查詢包括為交互式查詢引擎。選擇ClickHouse的原因主要是由于查詢性能快、查詢穩(wěn)定，只要設(shè)置合理的分區(qū)，單表數(shù)據(jù)量可以達(dá)到百億甚至千億級(jí)別。目前公司在多個(gè)業(yè)務(wù)線引入了L數(shù)據(jù)的快速實(shí)時(shí)查詢。大數(shù)據(jù)線的ClickHouse集群由28臺(tái)節(jié)點(diǎn)組成14主*2副本集群，每ODS叫數(shù)據(jù)采集層，數(shù)據(jù)來(lái)源于源系統(tǒng)，保留源系統(tǒng)概貌，為上游邏輯層提供原始放快照數(shù)據(jù)、增量追加數(shù)據(jù)和全量歷史快照數(shù)據(jù)。對(duì)于全量采集的數(shù)據(jù)，直接抽取到按日分區(qū)存入ODS庫(kù)，然后按照庫(kù)表主鍵合并去重寫入SNAP庫(kù)；對(duì)于有保存歷史快照份按日保存到History庫(kù)。DWS據(jù)主要來(lái)源于DWD層，以指標(biāo)加工為核心，按照維度建模的兩步進(jìn)行數(shù)據(jù)加工，第一步聚焦于指標(biāo)計(jì)算，統(tǒng)一加工業(yè)務(wù)指標(biāo)，第二步關(guān)聯(lián)維度信DM應(yīng)用層，數(shù)據(jù)來(lái)源主要來(lái)自DWS層，可按業(yè)務(wù)和應(yīng)用主題分ClickHouse庫(kù)；對(duì)于百萬(wàn)級(jí)以下的數(shù)據(jù)，則直接保存到MySQL數(shù)據(jù)庫(kù)。此外，還有應(yīng)用是在DWS層的基礎(chǔ)上進(jìn)行二次加工，包括簡(jiǎn)單匯總、計(jì)算同環(huán)比、多維匯總等，先寫入表：際項(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ù) 04在離線數(shù)據(jù)加工的基礎(chǔ)上，業(yè)務(wù)用戶提出來(lái)實(shí)時(shí)數(shù)據(jù)的需求，主要包括企業(yè)微信業(yè)績(jī)播最開(kāi)始開(kāi)發(fā)的是企業(yè)微信業(yè)績(jī)播報(bào)機(jī)器人需求，每小時(shí)匯總一次當(dāng)日成交數(shù)據(jù)，并和歷史成交進(jìn)行對(duì)比，將數(shù)據(jù)寫入MySQL，再由Java程序讀取數(shù)據(jù)，按照指定的數(shù)據(jù)格式播針對(duì)這個(gè)業(yè)務(wù)場(chǎng)景，我們按照典型的Lambda架構(gòu)設(shè)計(jì)，復(fù)用公司的Kafka寫入Hive數(shù)據(jù)組件，通過(guò)配置化實(shí)現(xiàn)關(guān)鍵業(yè)務(wù)數(shù)據(jù)自動(dòng)同步到Hive的rt_ods數(shù)據(jù)庫(kù)。然后我們通過(guò)Presto算引擎簡(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)，并分別按照商品維度第一代實(shí)時(shí)數(shù)倉(cāng)架構(gòu)實(shí)時(shí)播報(bào)滿足了業(yè)務(wù)用戶跟蹤業(yè)績(jī)進(jìn)展的需求，但是時(shí)效性比較差，無(wú)法滿足實(shí)時(shí)成交監(jiān)控、實(shí)時(shí)看板和大促大屏的需求，于是我們又進(jìn)一步開(kāi)發(fā)了新的實(shí)時(shí)鏈路，即Flink實(shí)第二代實(shí)時(shí)數(shù)倉(cāng)架構(gòu)FlinkFlinkSQL組成，分別讀取訂單CDC日志流數(shù)據(jù)和點(diǎn)擊埋點(diǎn)日志流數(shù)據(jù)，在進(jìn)行簡(jiǎn)單的數(shù)據(jù)轉(zhuǎn)換以后關(guān)聯(lián)離線加工的商品信息表(定時(shí)同步到HBase，全量1600萬(wàn))獲取商品維度然后寫入Clickhouse。在電商業(yè)務(wù)的多維分析中，用戶基本屬性、用戶成交記錄和用戶衍生標(biāo)簽。在我們的業(yè)務(wù)場(chǎng)景中，商品維度是千萬(wàn)級(jí)別，用戶維度是億級(jí)別，經(jīng)過(guò)測(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í)再利用LocalJoin的優(yōu)勢(shì)來(lái)關(guān)聯(lián)用戶維度。實(shí)時(shí)加FlinkClickHouse們首先將離線加工好的訂單寬表、點(diǎn)擊流寬表和用戶維度信息表在每天跑批完成以后同步到Clickhouse(其中訂單寬表是每日全量同步最近三個(gè)自然年的數(shù)據(jù)，點(diǎn)擊流每日增量同步昨日數(shù)據(jù))，然后通過(guò)一個(gè)視圖來(lái)合并離線數(shù)1.離線數(shù)據(jù)取下單(點(diǎn)擊)日期小于當(dāng)日的數(shù)據(jù)，實(shí)時(shí)數(shù)據(jù)取離線數(shù)據(jù)沒(méi)有的下單(點(diǎn)擊)日期對(duì)應(yīng)的數(shù)據(jù)。這是為了避免在凌晨時(shí)離線數(shù)據(jù)還沒(méi)有跑出來(lái)，導(dǎo)致查詢昨日沒(méi)2.實(shí)時(shí)數(shù)據(jù)關(guān)聯(lián)用戶維度，取用戶注冊(cè)時(shí)間和用戶引流渠道等信息。基于ClickHouse的特性，我們將所有接入的數(shù)據(jù)默認(rèn)按照f(shuō)uid的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中使用右表?yè)?jù)訂單和點(diǎn)擊流的不同特點(diǎn)，承接訂單實(shí)時(shí)數(shù)據(jù)的表我們采用ReplicatedReplacingMergeTree表則采用ReplicatedMergeTree引擎表。在使用訂單實(shí)時(shí)數(shù)據(jù)時(shí)，我們會(huì)在表名后增加final關(guān)鍵字，確保讀取到最新的Flink數(shù)據(jù)完整度高并且基本上都是明細(xì)數(shù)據(jù)，可以滿足各種業(yè)務(wù)場(chǎng)景，因此在這個(gè)數(shù)據(jù)集基礎(chǔ)上我們創(chuàng)建實(shí)時(shí)成交看板、實(shí)時(shí)監(jiān)控預(yù)警和大促大屏等據(jù)應(yīng)用在電商數(shù)倉(cāng)的基礎(chǔ)上，我們構(gòu)建了自助分析、固定報(bào)表、企業(yè)微信播報(bào)、標(biāo)簽畫(huà)像、大促大屏等多個(gè)數(shù)據(jù)應(yīng)用。其中，自助分析和固定報(bào)表都是基于QuickBI實(shí)現(xiàn)的，企業(yè)微信VUEWeb首先是自助分析，我們基于訂單數(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字段等固定報(bào)表，滿足管理層經(jīng)營(yíng)數(shù)據(jù)分析需求。這些報(bào)表主要在同環(huán)比、日周月年等維度第三個(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)，需要做很多第四個(gè)應(yīng)用是標(biāo)簽畫(huà)像。我們的標(biāo)簽畫(huà)像系統(tǒng)支持用戶和商品兩個(gè)維度，在標(biāo)簽系統(tǒng)定義的基礎(chǔ)標(biāo)簽都會(huì)換成成SparkSQL，加工以后同步到HBase。衍生標(biāo)簽在基礎(chǔ)標(biāo)簽的基礎(chǔ)上組合定義，結(jié)果數(shù)據(jù)也會(huì)加工到HBase。標(biāo)簽系統(tǒng)提供單個(gè)用戶查詢標(biāo)簽值和標(biāo)簽組合圈選用戶兩個(gè)功能，前者用于在線接口調(diào)第五個(gè)應(yīng)用是大促大屏。我們參照阿里雙十一大屏，構(gòu)建了實(shí)時(shí)大促大屏，包括實(shí)時(shí)成交額、大促期間累計(jì)成交額、用戶分類成交金額及本同期對(duì)比、商品分類成交金額及本后續(xù)演進(jìn)和流批一體探索補(bǔ)補(bǔ)的微調(diào)，但是整④①離線數(shù)據(jù)跑完以后，昨日的實(shí)時(shí)成交數(shù)據(jù)會(huì)提高，但是第三天又會(huì)下降。這是因?yàn)殡x線數(shù)據(jù)是以12點(diǎn)作為快照時(shí)間點(diǎn)計(jì)算的，后面的成交或者退款數(shù)據(jù)在實(shí)時(shí)里面可以體②商品維度數(shù)據(jù)一天只更新一次，導(dǎo)致當(dāng)日上線的商品在統(tǒng)計(jì)時(shí)丟失，或者商品層級(jí)調(diào)③流處理SQL封裝在Flink管理平臺(tái)中，批處理SQL封裝在調(diào)度平臺(tái)，導(dǎo)致兩邊容易出現(xiàn)較困難，導(dǎo)致我們點(diǎn)擊流數(shù)據(jù)只保留最近半年數(shù)據(jù)并且一次最多查詢一個(gè)月的數(shù)據(jù)，用面對(duì)以上這些問(wèn)題，我們開(kāi)啟了第三代實(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)過(guò)多方對(duì)比，最終選擇Hudi作為數(shù)據(jù)湖底座，繼續(xù)沿用Flink進(jìn)行流式數(shù)據(jù)i選擇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)》一書(shū)。有了Doris，最大的好處是我們可以做到維度解耦，可以在查詢的時(shí)候才進(jìn)行關(guān)采用這種流批一體的架構(gòu)，可以解決流數(shù)據(jù)和實(shí)時(shí)數(shù)據(jù)切換時(shí)成交金額回退的情況；同時(shí)保留中間過(guò)程數(shù)據(jù)，可以邏輯變更導(dǎo)致需要回溯歷史重算的情況；引入獨(dú)立的OLAP查雖然理想狀態(tài)下，所有數(shù)據(jù)都通過(guò)Flink流式進(jìn)行加工，但是經(jīng)過(guò)調(diào)研，我們還是有一些數(shù)據(jù)的邏輯無(wú)法做到純流處理，比如用戶下單時(shí)是新用戶還是老用戶，所以我們還是保留了批處理的鏈路，批處理的數(shù)據(jù)通過(guò)Spark加工完成以后，直接寫入Doris更新主鍵模監(jiān)控，預(yù)計(jì)Q4會(huì)全