一、業(yè)務(wù)場景介紹

首先和大家分享下京東物流業(yè)務(wù)的需求和億級數(shù)據(jù)自助應(yīng)用的背景。介紹京東物流經(jīng)營數(shù)據(jù)發(fā)展路線，底層數(shù)據(jù)的演進思路，業(yè)務(wù)對于數(shù)據(jù)訴求迭代。

1. 業(yè)務(wù)需要什么

京東物流除了包括快遞服務(wù)的倉、運、配三個環(huán)節(jié)外，它的一體化供應(yīng)鏈物流服務(wù)，則更多是基于對商品銷售和供應(yīng)鏈的理解，合理規(guī)劃倉網(wǎng)，分布庫存，提前將用戶需要的貨物儲存到其在全國范圍數(shù)百個不同等級的倉庫中。當(dāng)用戶下單后，商品將直接從最近的倉庫送達(dá)站點，開始配送。用戶下單后，快遞公司會通過干線網(wǎng)絡(luò)，將貨物運輸至對應(yīng)的區(qū)域，再分發(fā)至配送站點進行配送。這些服務(wù)以一體化解決方案的形式提供予客戶，滿足客戶的各種需求，業(yè)務(wù)極其復(fù)雜。

對于我們數(shù)據(jù)側(cè)的建設(shè)工作者來說，會遇到各種各樣的現(xiàn)實問題：

• 早：海量數(shù)據(jù)的多維查詢已經(jīng)成為常態(tài)，高時效保障是業(yè)務(wù)的最新追求，甚至要求實時；
• 散：數(shù)據(jù)存儲在不同的業(yè)務(wù)系統(tǒng)，各個系統(tǒng)沒有標(biāo)準(zhǔn)的數(shù)據(jù)規(guī)范， 數(shù)據(jù)重復(fù)建設(shè)；
• 重：日報、周報、半月報、月報等工作效率低，部分重復(fù)工作多，數(shù)據(jù)統(tǒng)計費時費力；
• 慢：全國區(qū)域、戰(zhàn)區(qū)以及各產(chǎn)品群數(shù)據(jù)場景多樣，無法快速響應(yīng)數(shù)據(jù)變化；
• 缺：缺少統(tǒng)一的數(shù)據(jù)資產(chǎn)管理，運營人員無法方便、快捷地進行統(tǒng)一的數(shù)據(jù)分析；
• 難：領(lǐng)導(dǎo)獲取數(shù)據(jù)難， 營銷投入產(chǎn)出比衡量難，數(shù)據(jù)驅(qū)動業(yè)務(wù)難，數(shù)據(jù)價值挖掘難。

2. 當(dāng)前需要什么

1） 生產(chǎn)系統(tǒng)

是指在正常情況下支持單位日常業(yè)務(wù)運作的信息系統(tǒng)。它包括生產(chǎn)數(shù)據(jù)、生產(chǎn)數(shù)據(jù)處理系統(tǒng)和生產(chǎn)網(wǎng)絡(luò)。

2） 數(shù)據(jù)倉庫

是為企業(yè)所有級別的決策制定過程，提供所有類型數(shù)據(jù)支持的戰(zhàn)略集合。它是單個數(shù)據(jù)存儲，出于分析性報告和決策支持目的而創(chuàng)建。為需要業(yè)務(wù)智能的企業(yè)，提供指導(dǎo)業(yè)務(wù)流程改進、監(jiān)視時間、成本、質(zhì)量以及控制。

3） 數(shù)據(jù)集市

是基于京東數(shù)據(jù)倉庫和大數(shù)據(jù)平臺構(gòu)建的面向各BG/BU的數(shù)據(jù)環(huán)境，為各BG/BU提供數(shù)據(jù)應(yīng)用服務(wù)，包含CFO、CMO、COO、MOBILE等數(shù)據(jù)集市。

4） 應(yīng)用系統(tǒng)

是指可以發(fā)揮數(shù)據(jù)價值去輔助用戶更優(yōu)地做決策（甚至行動）的一種產(chǎn)品形式。

3. 數(shù)據(jù)團隊怎么做：業(yè)財數(shù)據(jù)體系建設(shè)

每個公司的業(yè)務(wù)數(shù)據(jù)和財務(wù)數(shù)據(jù)是天然割裂的狀態(tài)。舉例來說，一家全國規(guī)模的連鎖店，每個店的店員的薪資和日程運營的費用（如水電費）怎么來反映到每一單上面去，如何把業(yè)務(wù)數(shù)據(jù)和財務(wù)數(shù)據(jù)打通，這有點像銀行的分潤，把業(yè)務(wù)數(shù)據(jù)規(guī)范到每一個環(huán)節(jié)對應(yīng)的每個功能點上去，即成本因素和收支因素的影響點，再把數(shù)據(jù)再給分擔(dān)上去。這也就是基礎(chǔ)模型搭建的一個過程，最終會支撐到上游資金分析體系的客戶的分析和成本支持。

標(biāo)準(zhǔn)化后的管理側(cè)數(shù)據(jù)口徑、顆粒度及維度將全面滿足企業(yè)對精細(xì)化、實時化業(yè)財分析的要求，為業(yè)務(wù)財務(wù)出具專業(yè)的分析與報告提供數(shù)據(jù)支撐。同時，可復(fù)用的、具備公共能力的標(biāo)準(zhǔn)數(shù)據(jù)將支持企業(yè)在價值鏈條上建立多維分析架構(gòu)，利用多層次、可交叉的分析直接加強企業(yè)對業(yè)務(wù)信息的鉆取能力，推動業(yè)務(wù)洞察和管理智能化。

二、面臨的困境

數(shù)據(jù)可視化、靈活分析迫在眉睫，權(quán)限管理，數(shù)據(jù)安全需要保障。

1. 數(shù)據(jù)可視化建設(shè)

在數(shù)據(jù)導(dǎo)出控制方面：

存在的隱患：

數(shù)據(jù)導(dǎo)出至本地電腦，并做分析；數(shù)據(jù)導(dǎo)出后，無法做跟蹤控制。導(dǎo)出次數(shù)達(dá)3000次/周。

解決方案：

• 長遠(yuǎn)解決方案：用戶需求反哺，沉淀方法論，線下分析報表化，支持自助探索。
• 短期解決方案：導(dǎo)出時，彈窗提醒法律風(fēng)險；導(dǎo)出形成賬單，并每月發(fā)送給區(qū)總了解。

在數(shù)據(jù)權(quán)限控制方面：

存在的隱患：

• 分析權(quán)限：因歷史積累，訪問大數(shù)據(jù)開發(fā)分析平臺的權(quán)限不匹配當(dāng)前安全要求。例如，有些業(yè)務(wù)分析師可以訪問庫內(nèi)全量表，未區(qū)分區(qū)域；
• 指標(biāo)權(quán)限：指標(biāo)的訪問權(quán)限控制散落在各系統(tǒng)管理，無法做到統(tǒng)一控制，容易混亂和遺漏。

解決方案：

• 分析權(quán)限：梳理BDP訪問權(quán)限，按照業(yè)務(wù)特性縮小訪問范圍，并制定崗位權(quán)限白皮書；
• 指標(biāo)權(quán)限：指標(biāo)出口由統(tǒng)一數(shù)據(jù)API進行控制，指標(biāo)查看權(quán)限設(shè)置由指標(biāo)收口人在資產(chǎn)管理平臺統(tǒng)一設(shè)置。

2. 工具論證

與業(yè)務(wù)用戶代表組成調(diào)研小組，對后續(xù)工具選型進行調(diào)研：

• 內(nèi)部工具調(diào)研，京東動力目前處于快速迭代階段，調(diào)研現(xiàn)階段支持功能，定制化開發(fā)的相應(yīng)速度；
• 外部工具調(diào)研，從成本，市場成熟度，產(chǎn)品易用性，擴展性，性能等多維度交叉比對市場主流BI工具的優(yōu)缺點；
  
• 內(nèi)外部工具對比，業(yè)務(wù)方、產(chǎn)品經(jīng)理以及研發(fā)三方組成專家評分組，對內(nèi)外部工具進行評分；
  
• 工具對比結(jié)論，最終確定BI工具實施方案。

3. 目標(biāo)現(xiàn)狀分析

目前京東物流數(shù)據(jù)探索領(lǐng)域分析工具的目標(biāo)以及當(dāng)前目標(biāo)現(xiàn)狀的分析，包括：

現(xiàn)狀情況：

• 京東動力作為分析工具
• 動力從商城數(shù)據(jù)中臺引入

突出問題：

• 性能慢：分鐘級，高峰期出不來
• 上卷、下鉆等功能缺失
• 體驗不友好，拖拽繁瑣

臨時方案：

• 提數(shù)，本地分析
• 隱患：數(shù)據(jù)導(dǎo)出后無法跟蹤

長期方案：

• 引入更適合的工具
• 調(diào)研：動力的計劃，Tableau、永洪BI等

分析工具目標(biāo)：

• 提供便捷自助服務(wù)：一站式分析平臺，集數(shù)據(jù)準(zhǔn)備、報告制作、數(shù)據(jù)分析為一體，業(yè)務(wù)人員也能輕松、快速地制作并分析數(shù)據(jù)報告，帶來業(yè)務(wù)驅(qū)動的數(shù)據(jù)分析工作模式。多維度下鉆和上卷。
• 內(nèi)嵌豐富組件，上線周期短，組件豐富，可以對所有數(shù)據(jù)源進行合并、搜索、交互和分析。
• 移動跨屏，無縫支持PC、iPhone、iPad和Android，并在這些終端設(shè)備上保持一致、易用的用戶體驗。
• 高性能，秒級計算，利用列存儲和內(nèi)存計算，實現(xiàn)千萬級數(shù)據(jù)分析的秒級響應(yīng)；提升性能，支撐更多的分析維度和更大的數(shù)據(jù)范圍。

當(dāng)前問題詳解：

• 自主分析不便捷，加工鏈條過長，需要前端，UI，產(chǎn)品以及UI多方配合，資源協(xié)調(diào)困難，溝通成本較高；
• 定制化研發(fā)投入多，定制化開發(fā)，不同維度的分析需要開發(fā)不同的匯總以及前段展示界面，底表模型變更影響范圍廣；
• 圖表組件不豐富，對于每種新的應(yīng)用場景均需要不同的額開發(fā)集成，各功能模塊之前需要聯(lián)調(diào)測試，開發(fā)周期長，暫不支持移動端；
• 無法跨屏展示&性能低，現(xiàn)沒有APP端展示；查詢依托于大數(shù)據(jù)平臺資源，在業(yè)務(wù)忙時查詢性能低。

4. 分析工具功能矩陣

由前面的分析，總結(jié)了分析工具的功能矩陣：

三、解決方案

數(shù)據(jù)從無到有，從有到準(zhǔn)，從準(zhǔn)到全，每個階段都會面臨不同的業(yè)務(wù)訴求，需要緊跟業(yè)務(wù)變化做迭代。

1.  數(shù)據(jù)引擎的變遷

2. 資源模式及架構(gòu)優(yōu)化

領(lǐng)航中分析師報表，為保證靈活性多通過報表工具（京東動力）配置實現(xiàn)，以Presto作為計算節(jié)點，以BDP大數(shù)據(jù)平臺作為數(shù)據(jù)存儲架構(gòu)。但計算資源和存儲資源均是共享模式，無法通過擴資源的方式有效的提升查詢效率，嚴(yán)重影響用戶體驗，急需改變。

• 之前架構(gòu)：領(lǐng)航+動力+PRESTO+BDP
• 弊端

     Presto集群無法資源隔離，易出現(xiàn)資源競爭；無法按業(yè)務(wù)條線對資源進行擴容；

     報表數(shù)據(jù)存放在BDP平臺，當(dāng)前集群任務(wù)多，任務(wù)運行貫穿正常工作時段，容易造成BDP平臺繁忙導(dǎo)致報表數(shù)據(jù)讀取慢的情況。

• 解決方案：領(lǐng)航+動力+DORIS

引入新架構(gòu)，資源獨占；解耦BDP平臺對數(shù)據(jù)展示影響

• 效果：已借助單票分析項目完成嘗試及驗證

     查詢從10秒+到秒級響應(yīng)提升

     獨立資源管控，按需優(yōu)化

3. Doris表管理

常用的表管理操作，包括：

1）表創(chuàng)建

2） 添加分區(qū)

ALTER TABLE table_name ADD PARTITION IF NOT EXISTS p20200803 VALUES [('2020-08-03'), ('2020-08-04'));

3）刪除分區(qū)

TRUNCATE TABLE table_name PARTITION(p20200803,p20200804

注意事項：

• 規(guī)范分區(qū)，統(tǒng)一分區(qū)規(guī)則便于后續(xù)運維
• 導(dǎo)入時，會同時給所有Rollup 產(chǎn)生數(shù)據(jù)，過多的Rollup 會影響導(dǎo)入性能，評估Rollup創(chuàng)建個數(shù)
• 批量導(dǎo)入清理歷史數(shù)據(jù)建議小范圍多批次串行操作，合理利用資源

4. Doris數(shù)據(jù)導(dǎo)入：Hive2Doris通過Broker Load方式寫入

常用的數(shù)據(jù)導(dǎo)入操作，包括：

1） 轉(zhuǎn)換導(dǎo)入表格式

2）Broker Load

3） 追蹤導(dǎo)入狀態(tài)

show load from jddl_test where label = 'app_ea_pal_vender_all_sum_m_20201101_183213_19688970430' \G

注意事項：

• LABEL：用于指定這一批次導(dǎo)入的label，用于后期進行作業(yè)狀態(tài)查詢等
• max_filter_ratio：用于指定允許過濾不規(guī)范數(shù)據(jù)的最大比例，默認(rèn)是0，不允許過濾,自定義指定應(yīng)該如下：
  
• 'max_filter_ratio=0.2'，含義是允許20%的錯誤率
  
• timeout：指定load 作業(yè)的超時時間，單位是秒。當(dāng)load執(zhí)行時間超過該閾值時，會自動取消。默認(rèn)超時時間是86400 秒。

5. 數(shù)據(jù)自動導(dǎo)入管理

-t 表示的是待推送數(shù)據(jù)的表名【該參數(shù)是必選，如果不選會報錯】

-c 表示的是待推送數(shù)據(jù)的列名【該參數(shù)是可選，如果不選會默認(rèn)推送所有列，建議不選擇】

-n 表示的是推送多長時間的數(shù)據(jù)【需要與參數(shù)-e聯(lián)動使用，如果不填寫，默認(rèn)推送1天的數(shù)據(jù)】

-e 表示的是腳本數(shù)據(jù)推送的日期【默認(rèn)是昨天，該參數(shù)一般是追歷史數(shù)據(jù)時使用，比如今天是2020-05-08日，默認(rèn)推送20200507日的數(shù)據(jù)，如果指定了-n參數(shù)的話推送的就會是20200507-n天至20200507】

-d 表示對doris數(shù)據(jù)庫的表進行操作【默認(rèn)參數(shù)是：db_null 不執(zhí)行建表】db_get_crt：表示打印出doris建表語句，該邏輯會讀取hive中的表結(jié)構(gòu)，然后將HIVE中的字段為string類型的當(dāng)成維，int，bigint，double類型的當(dāng)成值生成建表語句【具體邏輯請參考腳本】

• db_reset ：表示重建表，如果調(diào)整表結(jié)構(gòu)后，需要使用這個參數(shù)重構(gòu)doris表結(jié)構(gòu)【如果指定了-c參數(shù)，記得增加列】
• db_drop ：表示刪除doris中對應(yīng)的表，用于下線任務(wù)
  
• db_create ：如果不存在對應(yīng)的表就創(chuàng)建表，如果存在表就打印表結(jié)構(gòu)下面，重點分享下縱向聯(lián)邦學(xué)習(xí)和橫向聯(lián)邦學(xué)習(xí)。

注意事項：

• 數(shù)據(jù)庫特性不同天然存在融合瓶頸，新技術(shù)的引入需要有充分的預(yù)案，做到各司其職，才能讓其特性得到發(fā)揮

6. 自動報表實現(xiàn)

通過動力連接數(shù)據(jù)庫，把對應(yīng)的表按照權(quán)限管理配置成數(shù)據(jù)源，在數(shù)據(jù)源上創(chuàng)建應(yīng)用，可以讓業(yè)務(wù)人員在10分鐘搭建起符合自己預(yù)期的分析報表。

7. 待優(yōu)化點：子查詢對應(yīng)Rollup的影響

子查詢?nèi)绻麤]有生效rollup，外層是無法生效。

四、未來規(guī)劃

技術(shù)迭代是手段，對業(yè)務(wù)發(fā)展起促進作用才是目的，如何通過技術(shù)的升級實現(xiàn)業(yè)務(wù)技術(shù)相互促進。

 1. 離線數(shù)據(jù)技術(shù)升級

BDP是一個公共平臺，支持開發(fā)人員、分析師以及業(yè)務(wù)人員做數(shù)據(jù)查詢，業(yè)務(wù)是不斷變化增長的，業(yè)務(wù)部門分析也會隨著對業(yè)務(wù)的理解程度不斷深入，但是實際的物理資源不能無限制擴容?；诖?，每天的重要任務(wù)SLA保障是數(shù)據(jù)團隊面臨的最大挑戰(zhàn)，并且隨著業(yè)務(wù)發(fā)展會愈發(fā)嚴(yán)重。這就需要做系統(tǒng)規(guī)劃：

• 不斷優(yōu)化迭代底層模型，對數(shù)據(jù)做最優(yōu)整合，對主題模型的數(shù)據(jù)引入生命周期管理，表現(xiàn)在兩個方面：

     其一，模型隨著業(yè)務(wù)有新增，也必須有消亡；

     其二，模型本身存儲數(shù)據(jù)需要有生命周期管理，對于可追溯的分析數(shù)據(jù)制定數(shù)據(jù)保留策略，滿足業(yè)務(wù)需求的同時盡量減少歷史數(shù)據(jù)存儲。

• 貼合平臺優(yōu)化加工策略，縱觀調(diào)度平臺全時段運行情況，在某些時段會出現(xiàn)資源利用波谷，通過并行任務(wù)合理利用資源。
  
• 新調(diào)度引擎引入，按照任務(wù)不同的加工場景選擇不同調(diào)度引擎（Hive/Spark）,以最小代價實現(xiàn)調(diào)入任務(wù)跑數(shù)。

2. 業(yè)務(wù)迭代技術(shù)跟進

隨著業(yè)務(wù)的不斷成熟，對精細(xì)化運營有了新的要求，會涉及到各方業(yè)務(wù)系統(tǒng)的迭代，數(shù)據(jù)處理需要夯實底層架構(gòu)。

• 通用化：業(yè)財一體化融合，對成熟的業(yè)務(wù)實現(xiàn)到單的融合；
• 體系化：通過各維度損益模型串聯(lián)業(yè)務(wù)實際運營成本，支持業(yè)務(wù)分析，做全盤優(yōu)化調(diào)優(yōu)成本；
• 清晰化：看清每個經(jīng)營動作成本，減少由于分?jǐn)傇斐伞安町愋浴澳ㄆ?，結(jié)合業(yè)務(wù)量、收入對不同環(huán)節(jié)進行改善；
• 靈活化：即席查詢，利用新的OLAP計算框架，支持各個維度數(shù)據(jù)查看，實現(xiàn)不同業(yè)務(wù)層級數(shù)據(jù)的上卷、下鉆。

3. 團隊建設(shè)

獨木不成林，任何一個項目的成功都是團隊配合的結(jié)果。在團隊建設(shè)之初，團隊的人員相對較少，對接的業(yè)務(wù)也相對聚焦，從0到1的數(shù)據(jù)建設(shè)過程中一定是采用“縱向”的開發(fā)方式——一個數(shù)據(jù)開發(fā)對接一個條線，對當(dāng)前條線從頭到全盤負(fù)責(zé)，實現(xiàn)高速迭代。這個階段會形成團隊核心價值，當(dāng)各業(yè)務(wù)方都認(rèn)可這種數(shù)據(jù)分析思路，隨之而來的就是業(yè)務(wù)需求膨脹，不同主題之間的橫向拉通分析，組內(nèi)人員的補充等。如何做到人員價值最大化，則需要投入精力在團隊建設(shè)上，主要包括：

• 方法論建設(shè)：沒有成熟的方法論，后續(xù)難以為繼。
• 技術(shù)提升：離線實時數(shù)據(jù)全鏈路的技術(shù)結(jié)合,技術(shù)要求高。
  
• 項目管理：大項目周期以半年設(shè)置年計，項目投入產(chǎn)出科學(xué)衡量。
  
• 數(shù)據(jù)權(quán)限：數(shù)據(jù)訪問的細(xì)粒度的控制，基礎(chǔ)元數(shù)據(jù)補全。
  
• 人才隊伍建設(shè)：需要人才梯隊來保障持續(xù)數(shù)據(jù)迭代。

今天的分享就到這里，謝謝大家。