電商供應(yīng)鏈數(shù)倉(cāng)平臺(tái)該如何建設(shè)？哪些點(diǎn)需要注意？

導(dǎo)讀：隨著蜀海供應(yīng)鏈業(yè)務(wù)的發(fā)展，供應(yīng)鏈中各個(gè)環(huán)節(jié)角色的工作人員利用數(shù)據(jù)對(duì)業(yè)務(wù)進(jìn)行增長(zhǎng)分析的需求越來(lái)越迫切。在過(guò)去大數(shù)據(jù)分析平臺(tái)架構(gòu)1.0的實(shí)踐中，存在數(shù)據(jù)生產(chǎn)鏈路太長(zhǎng)，架構(gòu)太復(fù)雜，開(kāi)發(fā)運(yùn)維成本都很高，之前的團(tuán)隊(duì)對(duì)這個(gè)架構(gòu)的駕馭能力不足，數(shù)據(jù)冗余，對(duì)業(yè)務(wù)的適應(yīng)能力較弱和不能快速的響應(yīng)業(yè)務(wù)各種數(shù)據(jù)需求等諸多問(wèn)題，基于這種問(wèn)題，我們通過(guò)引入Apache Doris引擎優(yōu)化生產(chǎn)方案，實(shí)現(xiàn)蜀海供應(yīng)鏈大數(shù)據(jù)數(shù)倉(cāng)的升級(jí)，在數(shù)據(jù)開(kāi)發(fā)上跑通了一套完整的流程，使我們數(shù)據(jù)需求的日常迭代更加迅速和開(kāi)發(fā)效率的提升，同時(shí)也解決了我們?cè)?/span>1.0架構(gòu)中存在的諸多問(wèn)題。

01

業(yè)務(wù)介紹

蜀海供應(yīng)鏈成立于2011年6月，是集銷售、研發(fā)、采購(gòu)、生產(chǎn)、品保、倉(cāng)儲(chǔ)、運(yùn)輸、信息、金融為一體的餐飲供應(yīng)鏈服務(wù)企業(yè)，現(xiàn)為廣大餐飲連鎖企業(yè)及零售客戶提供整體食材供應(yīng)鏈解決方案服務(wù)。

我們主要業(yè)務(wù)如下圖：

• 領(lǐng)導(dǎo)駕駛艙數(shù)據(jù)實(shí)時(shí)分析，T+1報(bào)表分析

• 財(cái)務(wù)各類日?qǐng)?bào)，月報(bào)，對(duì)賬等

• 客戶銷售：采購(gòu)類實(shí)時(shí)報(bào)表、日?qǐng)?bào)、月報(bào)各個(gè)維度的數(shù)據(jù)分析及查詢銷售明細(xì)數(shù)據(jù)

• 供應(yīng)商類：采購(gòu)分析，供應(yīng)商對(duì)賬分析，采購(gòu)策略優(yōu)化等

• 倉(cāng)儲(chǔ)庫(kù)存周轉(zhuǎn)、庫(kù)位、實(shí)時(shí)庫(kù)存等各種維度數(shù)據(jù)指標(biāo)及報(bào)表需求

• 運(yùn)輸類：準(zhǔn)點(diǎn)率、溫控、運(yùn)輸成本，調(diào)度等分析

• 數(shù)據(jù)分析師：快速響應(yīng)各種數(shù)據(jù)分析需求，及高層領(lǐng)導(dǎo)各種臨時(shí)數(shù)據(jù)需求，數(shù)據(jù)挖掘及各種實(shí)時(shí)交互式分析

• 各業(yè)務(wù)運(yùn)營(yíng)/策略/負(fù)責(zé)人主要查看各自業(yè)務(wù)運(yùn)營(yíng)的整體情況，查詢數(shù)據(jù)中臺(tái)的各該業(yè)務(wù)各種維度實(shí)時(shí)聚合數(shù)據(jù)

• 還有一些其他業(yè)務(wù)的數(shù)據(jù)報(bào)表及分析需求

作為公司的大數(shù)據(jù)團(tuán)隊(duì)主要負(fù)責(zé)構(gòu)建公司級(jí)的數(shù)據(jù)倉(cāng)庫(kù)，向各個(gè)產(chǎn)品線提供面向業(yè)務(wù)的數(shù)據(jù)分析服務(wù)，如：銷售額，毛利，庫(kù)存周轉(zhuǎn)、客訴問(wèn)題、銷售達(dá)成率、物流準(zhǔn)點(diǎn)率、智慧工廠、供應(yīng)商等業(yè)務(wù)線，在過(guò)去半年多的時(shí)間里我們通過(guò)對(duì)Doris的應(yīng)用實(shí)踐，基于Doris構(gòu)建了蜀海的實(shí)時(shí)數(shù)據(jù)倉(cāng)庫(kù)。

本文總結(jié)一下我們?cè)谶@期間的工作，和大家一起分享，共同討。

我們的數(shù)倉(cāng)分層：

大數(shù)據(jù)團(tuán)隊(duì)主要負(fù)責(zé)到ODS-DWS的建設(shè)，從DWS到ADS一般是數(shù)倉(cāng)系統(tǒng)和業(yè)務(wù)線系統(tǒng)的邊界。

在過(guò)去，由于缺失統(tǒng)一的數(shù)據(jù)倉(cāng)庫(kù)，業(yè)務(wù)系統(tǒng)之間又相互依賴，業(yè)務(wù)系統(tǒng)那邊也探索了很多模式來(lái)支持各個(gè)業(yè)務(wù)線發(fā)展。但是效果都不是很好，出現(xiàn)各種各樣的問(wèn)題，隨著業(yè)務(wù)的發(fā)展，數(shù)據(jù)量也越來(lái)越大，之前的模式也越越來(lái)越不堪負(fù)重。

02

架構(gòu)演進(jìn)

1. 架構(gòu)1.0

我來(lái)公司之前這邊大數(shù)據(jù)團(tuán)隊(duì)規(guī)模也比較小，業(yè)務(wù)量也沒(méi)那么大，當(dāng)時(shí)只是為了支撐海底撈門店補(bǔ)貨系統(tǒng)（幾家門店試點(diǎn)），搭建了基于CDH一套大數(shù)據(jù)平臺(tái)，主要是為了完成每十分鐘給補(bǔ)貨系統(tǒng)推送一批計(jì)算好的數(shù)據(jù)，主要是POS銷售數(shù)據(jù)，沽清數(shù)據(jù)等，每天在全量的推送一次一整天的數(shù)據(jù)，當(dāng)時(shí)的架構(gòu)如下：

這是當(dāng)時(shí)的大數(shù)據(jù)架構(gòu)，為了解決這個(gè)問(wèn)題，基本上能用的組件都用了，但是數(shù)據(jù)的實(shí)時(shí)性還是滿足不了需求。

這個(gè)架構(gòu)存在的問(wèn)題：

• 數(shù)據(jù)生產(chǎn)鏈路太長(zhǎng)：中間經(jīng)過(guò)了三四次落地操作

• 不支持標(biāo)準(zhǔn)SQL

• 數(shù)據(jù)冗余太多：數(shù)據(jù)從阿里云到最終輸出，中間保存了三份同樣的數(shù)據(jù)，

• 聚合查詢效率不高：十分鐘的數(shù)據(jù)基本要三四分鐘甚至更長(zhǎng)時(shí)間才能計(jì)算出來(lái)結(jié)果

• 開(kāi)發(fā)成本太高：基本把CDH套件里的組件全部使用了

• 不能快速的響應(yīng)業(yè)務(wù)各種數(shù)據(jù)需求

2. 架構(gòu)2.0

① 為什么選擇Doris？

我來(lái)蜀海之前就是Doris的用戶，深知Doris的優(yōu)點(diǎn)，在這里還是說(shuō)一下。

對(duì)我們用戶來(lái)說(shuō)，Doris 的優(yōu)點(diǎn)是功能強(qiáng)大，易用性好。功能強(qiáng)大指可以滿足我們用戶的需求，易用性好主要指兼容 Mysql 協(xié)議和語(yǔ)法，以及 Online Schema Change。兼容 Mysql 協(xié)議和語(yǔ)法讓用戶的學(xué)習(xí)成本和開(kāi)發(fā)成本很低， Online Schema Change 也是一個(gè)很吸引人的 feature，因?yàn)樵跇I(yè)務(wù)快速發(fā)展和頻繁迭代的情況下，Schema 變更會(huì)是一個(gè)高頻的操作。

對(duì)我們平臺(tái)側(cè)來(lái)說(shuō)，Doris 的優(yōu)點(diǎn)是易運(yùn)維，易擴(kuò)展和高可用：

• 易運(yùn)維指 Doris 無(wú)外部系統(tǒng)依賴，部署和配置都很簡(jiǎn)單。

• 易擴(kuò)展指 Doris 可以一鍵加減節(jié)點(diǎn)，并自動(dòng)均衡數(shù)據(jù)。

• 高可用值 Dors 的 FE 和 BE 都可以容忍少數(shù)節(jié)點(diǎn)掛掉。

② 基于Doris的數(shù)倉(cāng)架構(gòu)

如下圖：

• 數(shù)倉(cāng)整體以Doris為核心構(gòu)建公司企業(yè)級(jí)數(shù)據(jù)倉(cāng)庫(kù)

• 通過(guò)統(tǒng)一的數(shù)據(jù)采集系統(tǒng)，多種數(shù)據(jù)采集手段，包括Mysql binlog解析（Cannal），日志采集Flume（Doris審計(jì)日志）、埋點(diǎn)接口等實(shí)現(xiàn)多種異構(gòu)數(shù)據(jù)的采集

• 將采集的數(shù)據(jù)統(tǒng)一通過(guò)消息隊(duì)列（Kafka）完成高并發(fā)的數(shù)據(jù)吞吐，同時(shí)實(shí)現(xiàn)數(shù)倉(cāng)及計(jì)算引擎的解耦

• Flink計(jì)算引擎完成數(shù)據(jù)的ETL處理及實(shí)時(shí)數(shù)據(jù)的統(tǒng)計(jì)，并將數(shù)據(jù)推送到Kafka及Doris（Stream Load）

• 對(duì)外通過(guò)doris和消息隊(duì)列對(duì)外提供數(shù)據(jù)服務(wù)

• 數(shù)據(jù)質(zhì)量管理是實(shí)現(xiàn)對(duì)從數(shù)據(jù)采集到數(shù)據(jù)ETL處理，數(shù)據(jù)存儲(chǔ)及數(shù)據(jù)服務(wù)全生命周期的數(shù)據(jù)管理，包括元數(shù)據(jù)，數(shù)據(jù)質(zhì)量，數(shù)據(jù)規(guī)范、數(shù)據(jù)安全

下面這個(gè)圖可能更清晰的看清楚我們基于Doris的數(shù)據(jù)流向

新架構(gòu)優(yōu)點(diǎn)：

• 數(shù)據(jù)導(dǎo)入方式簡(jiǎn)單，我們針對(duì)不同業(yè)務(wù)場(chǎng)景使用了三種導(dǎo)入方式：

• Routin load : 異構(gòu)實(shí)時(shí)異步數(shù)據(jù)導(dǎo)入（這種主要使用在一些臨時(shí)的數(shù)據(jù)接入）

• Stream Load ：業(yè)務(wù)數(shù)據(jù)實(shí)時(shí)異步數(shù)據(jù)接入（我們封裝了業(yè)務(wù)數(shù)據(jù)零代碼入倉(cāng)，后面我會(huì)介紹）

• Insert into ：定時(shí)通過(guò) DWD 層數(shù)倉(cāng)表生成 DWS/ADS 層數(shù)倉(cāng)表

• 數(shù)據(jù)鏈路縮短，數(shù)據(jù)實(shí)時(shí)性更高；

• 數(shù)倉(cāng)使用成本降低：

• Doris 支持 MySQL 協(xié)議，數(shù)據(jù)分析師可以直接進(jìn)行自助取數(shù)。

• Doris 不依賴 Hadoop 生態(tài)圈組件，降低了架構(gòu)的復(fù)雜度，大大降低運(yùn)維成本

• Doris 同時(shí)支持離線批量和實(shí)時(shí)數(shù)據(jù)，一個(gè)框架搞定一切

03

我們做的一些工作

我們基于Doris開(kāi)發(fā)了自己的數(shù)據(jù)中臺(tái)，主要是為了解決以下五個(gè)問(wèn)題：

• 找數(shù)：要知道數(shù)據(jù)從哪來(lái)到哪去

• 理解數(shù)據(jù)：這個(gè)數(shù)據(jù)是干嘛的，每個(gè)字段是什么意思

• 問(wèn)題評(píng)估：一個(gè)新的需求過(guò)來(lái)，怎么評(píng)估開(kāi)發(fā)，會(huì)使用到哪些數(shù)據(jù)，這些數(shù)據(jù)關(guān)系是什么

• 取數(shù)：上面問(wèn)題都解決以后，數(shù)據(jù)怎么獲取

• 數(shù)據(jù)可視化展現(xiàn)：這是最終呈現(xiàn)的結(jié)果

圍繞上面這五個(gè)問(wèn)題，我們?cè)O(shè)計(jì)和開(kāi)發(fā)了公司的數(shù)據(jù)中臺(tái)，下面主要介紹基于Doris開(kāi)發(fā)數(shù)據(jù)中臺(tái)過(guò)程中我們做的一些工作。

1. 零代碼入倉(cāng)

要做到業(yè)務(wù)快速響應(yīng)，首先你要能實(shí)現(xiàn)數(shù)據(jù)的快速數(shù)據(jù)接入，包括數(shù)據(jù)接入過(guò)程中的 ETL。

我們這邊業(yè)務(wù)庫(kù)基本都是 Mysql，也有非 Mysql 數(shù)據(jù)庫(kù)，基于這種情況，我們采用了 Canal 及 Datax 完成數(shù)據(jù)采集，同時(shí)對(duì) Datax 進(jìn)行了改造，是 Datax 抽取的數(shù)據(jù)格式和 Canal 一致，然后通過(guò) Flink 基于 Doris Stream Load 完成數(shù)據(jù)入倉(cāng)操作，整個(gè)過(guò)程可以零代碼完成，并集成了我們自研的規(guī)則引擎，實(shí)現(xiàn)規(guī)則自定義及規(guī)則自動(dòng)下發(fā)到Flink Job中，具體展示效果如下：

數(shù)據(jù)分析人員可以通過(guò)Web方式零代碼完成業(yè)務(wù)數(shù)據(jù)接入，最后提交任務(wù)即可。

• 數(shù)據(jù)接入

目前支持 Mysql，Kafka，Datax，這里我們采用的是Canal實(shí)現(xiàn)對(duì)Mysql binlog進(jìn)行監(jiān)控，然后將mysql的數(shù)據(jù)實(shí)時(shí)推送到Kafka，接入任務(wù)可以監(jiān)控，接入數(shù)據(jù)量可監(jiān)控

• 數(shù)據(jù)入倉(cāng)

數(shù)據(jù)接入到Doris數(shù)據(jù)倉(cāng)庫(kù)對(duì)應(yīng)的表中，這里我們采用的是Flink實(shí)時(shí)消費(fèi)KafKa的數(shù)據(jù)，然后通過(guò)Doris的Stream Load完成。Flink消費(fèi)Kafka數(shù)據(jù)我們支持兩種方式：

• 指定Kafka Topic的Offset進(jìn)行消費(fèi)：kafka.offset

• 指定時(shí)間戳的方式：kafka.timestamp

• 數(shù)據(jù)丟失的問(wèn)題

針對(duì)Flink Job失敗，可能會(huì)造成數(shù)據(jù)丟失的問(wèn)題，我們解決方案如下：

• 如果你記錄了失敗的時(shí)間點(diǎn)的Kafka Offset，可以通過(guò)配置文件配置這個(gè)參數(shù)來(lái)重啟Flink Job就行。這樣不會(huì)造成數(shù)據(jù)丟失

• 如果沒(méi)有記錄這個(gè)offset，可通過(guò)指定consumer.setStartFromTimestamp(timestamp)；這個(gè)時(shí)間就是在配置文件中配置的時(shí)間戳，這樣無(wú)論是通過(guò)offset還是從指定的時(shí)間開(kāi)始消費(fèi)Kafka數(shù)據(jù)，都不會(huì)造成數(shù)據(jù)丟失

• 數(shù)據(jù)重復(fù)問(wèn)題

因?yàn)槲覀冞@個(gè)是在數(shù)據(jù)接入層使用的，數(shù)據(jù)是進(jìn)入到數(shù)據(jù)倉(cāng)ODS層，在這一層我們采用的是Doris Unique Key模型，就算數(shù)據(jù)重復(fù)入庫(kù)，也會(huì)自動(dòng)覆蓋原先的數(shù)據(jù)（這是Doris Unique Key模型的特點(diǎn)），不會(huì)出現(xiàn)數(shù)據(jù)重復(fù)的問(wèn)題。

• 自研規(guī)則引擎

提供內(nèi)置規(guī)則模板，及規(guī)則定義可視化開(kāi)發(fā)界面，規(guī)則試跑，規(guī)則發(fā)布等，發(fā)布的規(guī)則會(huì)自動(dòng)下發(fā)到Flink Job對(duì)應(yīng)的作業(yè)中執(zhí)行。

2. 基于Doris數(shù)倉(cāng)的元數(shù)據(jù)管理

• 數(shù)據(jù)地圖

基于Doris我們實(shí)現(xiàn)了元數(shù)據(jù)管理（業(yè)務(wù)元數(shù)據(jù)及技術(shù)元數(shù)據(jù)），提供物理元模型及血緣元模型的構(gòu)建，提供一鍵搜索的數(shù)據(jù)地圖服務(wù)。

• 血緣關(guān)系及關(guān)聯(lián)關(guān)系

血緣關(guān)系：通過(guò)解析Doris 審計(jì)日志，自動(dòng)化完成

關(guān)聯(lián)關(guān)系：這個(gè)主要是在ODS（貼源層），因?yàn)闃I(yè)務(wù)系統(tǒng)數(shù)據(jù)庫(kù)表沒(méi)有主外鍵關(guān)系，在這里我要知道數(shù)據(jù)之間關(guān)聯(lián)關(guān)系，通過(guò)手動(dòng)定義維護(hù)。

• 數(shù)據(jù)服務(wù)開(kāi)發(fā)

我們?yōu)榱丝焖夙憫?yīng)業(yè)務(wù)系統(tǒng)的數(shù)據(jù)服務(wù)需求，設(shè)計(jì)開(kāi)發(fā)了接口零代碼開(kāi)發(fā)平臺(tái)，數(shù)據(jù)分析人員不需要寫代碼就可以快速完成API接口的開(kāi)發(fā)，可以對(duì)接口進(jìn)行可視化上下線操作，接口調(diào)用限制（黑白名單），支持降級(jí)限流熔斷等，快捷方便，高效。

• 接口定義開(kāi)發(fā)

• 數(shù)據(jù)指標(biāo)管理

在指標(biāo)系統(tǒng)完成基于審批流程的指標(biāo)規(guī)范化定義，嚴(yán)格定義指標(biāo)規(guī)范，規(guī)避指標(biāo)二義性；支持和其它產(chǎn)品聯(lián)動(dòng)影響和展示，產(chǎn)品如模型設(shè)計(jì)中心、數(shù)據(jù)地圖等。

• 調(diào)度系統(tǒng)

我們將海豚調(diào)度深度集成到我們的數(shù)據(jù)中臺(tái)中，各個(gè)模塊可以很方便的將任務(wù)添加到海豚調(diào)度系統(tǒng)中運(yùn)行及監(jiān)控。

3. Flink Doris Connector

為了讓 Doris 更好的適應(yīng)各種異構(gòu)數(shù)據(jù)的融合分析，使用大規(guī)模分布式環(huán)境下的機(jī)器學(xué)習(xí)場(chǎng)景及實(shí)時(shí)數(shù)據(jù)分析的場(chǎng)景，我們?cè)O(shè)計(jì)并發(fā)了 Flink Doris Connector，同時(shí)貢獻(xiàn)給了社區(qū)。具體的實(shí)現(xiàn)方案通過(guò)主數(shù)據(jù)分區(qū)來(lái)并行執(zhí)行，大大提高了讀取的速度和效率。同時(shí)通過(guò)FlinkSQL方式讀寫Drois數(shù)據(jù)。讀數(shù)據(jù)主要進(jìn)行異構(gòu)數(shù)據(jù)源的關(guān)聯(lián)分析，在回寫到Doris數(shù)倉(cāng)里面去。

詳細(xì)的設(shè)計(jì)方案可以參考我的博客：「Flink Doris Connector 設(shè)計(jì)方案」

https://my.oschina.net/u/3774656/blog/5017244 

04

收益

目前10臺(tái)BE ，3臺(tái)FE（高可用）的 Doris 環(huán)境，效率、性能表現(xiàn)情況如下：

• 支撐十幾條業(yè)務(wù)線以上，整體響應(yīng)達(dá)到ms級(jí)。

• 支持百萬(wàn)、千萬(wàn)級(jí)大表關(guān)聯(lián)查詢，同時(shí)進(jìn)行維表關(guān)聯(lián)的雪花模型，可以實(shí)現(xiàn)秒級(jí)響應(yīng)。

• 日級(jí)別，基于銷售明細(xì)現(xiàn)場(chǎng)計(jì)算，同時(shí)滿足匯總及下鉆明細(xì)查詢，查詢時(shí)效基本都可以控制在秒級(jí)。

• 七日趨勢(shì)分析，100毫秒-3秒，根據(jù)集群規(guī)模不同查詢性能有所區(qū)別，但數(shù)據(jù)量較大時(shí)，調(diào)動(dòng)的集群資源較多，因此MPP的并發(fā)性能受限于集群的性能。一般原則是并發(fā)較高的業(yè)務(wù)，需要嚴(yán)格控制查詢時(shí)效（基本在毫秒級(jí)），對(duì)于并發(fā)不高的業(yè)務(wù)，允許進(jìn)行較大的查詢，但也要考慮集群的承受能力。

• 通過(guò)應(yīng)用以及Doris的不斷改進(jìn)升級(jí)，Doris的高可靠、高可用、高可擴(kuò)展性也得到進(jìn)一步驗(yàn)證，服務(wù)穩(wěn)定可靠。

• 入庫(kù)性能，每秒峰值可以在30-40萬(wàn)條，同時(shí)不影響正常的數(shù)據(jù)分析

開(kāi)發(fā)效率的提升：

• 數(shù)據(jù)接入：整庫(kù)幾十張表在一天之內(nèi)可以完成接入到數(shù)倉(cāng)（包括ETL），無(wú)需代碼

• 報(bào)表開(kāi)發(fā)：效率提升至少2-3倍，大大節(jié)省人力資源，而且不需要開(kāi)發(fā)人員，只需要數(shù)據(jù)分析人員通過(guò)SQL加工，然后拖拽即可完成數(shù)據(jù)可視化展現(xiàn)

• 數(shù)據(jù)實(shí)時(shí)性：滿足業(yè)務(wù)各種實(shí)時(shí)準(zhǔn)實(shí)時(shí)數(shù)據(jù)分析需求，并且能做到快速響應(yīng)