一、業務場景介紹

首先和大家分享下京東物流業務的需求和億級數據自助應用的背景。介紹京東物流經營數據發展路線，底層數據的演進思路，業務對于數據訴求迭代。

1. 業務需要什么

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

對于我們數據側的建設工作者來說，會遇到各種各樣的現實問題：

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

2. 當前需要什么

1） 生產系統

是指在正常情況下支持單位日常業務運作的信息系統。它包括生產數據、生產數據處理系統和生產網絡。

2） 數據倉庫

是為企業所有級別的決策制定過程，提供所有類型數據支持的戰略集合。它是單個數據存儲，出于分析性報告和決策支持目的而創建。為需要業務智能的企業，提供指導業務流程改進、監視時間、成本、質量以及控制。

3） 數據集市

是基于京東數據倉庫和大數據平臺構建的面向各BG/BU的數據環境，為各BG/BU提供數據應用服務，包含CFO、CMO、COO、MOBILE等數據集市。

4） 應用系統

是指可以發揮數據價值去輔助用戶更優地做決策（甚至行動）的一種產品形式。

3. 數據團隊怎么做：業財數據體系建設

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

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

二、面臨的困境

數據可視化、靈活分析迫在眉睫，權限管理，數據安全需要保障。

1. 數據可視化建設

在數據導出控制方面：

存在的隱患：

數據導出至本地電腦，并做分析；數據導出后，無法做跟蹤控制。導出次數達3000次/周。

解決方案：

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

在數據權限控制方面：

存在的隱患：

• 分析權限：因歷史積累，訪問大數據開發分析平臺的權限不匹配當前安全要求。例如，有些業務分析師可以訪問庫內全量表，未區分區域；
• 指標權限：指標的訪問權限控制散落在各系統管理，無法做到統一控制，容易混亂和遺漏。

解決方案：

• 分析權限：梳理BDP訪問權限，按照業務特性縮小訪問范圍，并制定崗位權限白皮書；
• 指標權限：指標出口由統一數據API進行控制，指標查看權限設置由指標收口人在資產管理平臺統一設置。

2. 工具論證

與業務用戶代表組成調研小組，對后續工具選型進行調研：

• 內部工具調研，京東動力目前處于快速迭代階段，調研現階段支持功能，定制化開發的相應速度；
• 外部工具調研，從成本，市場成熟度，產品易用性，擴展性，性能等多維度交叉比對市場主流BI工具的優缺點；
  
• 內外部工具對比，業務方、產品經理以及研發三方組成專家評分組，對內外部工具進行評分；
  
• 工具對比結論，最終確定BI工具實施方案。

3. 目標現狀分析

目前京東物流數據探索領域分析工具的目標以及當前目標現狀的分析，包括：

現狀情況：

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

突出問題：

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

臨時方案：

• 提數，本地分析
• 隱患：數據導出后無法跟蹤

長期方案：

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

分析工具目標：

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

當前問題詳解：

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

4. 分析工具功能矩陣

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

三、解決方案

數據從無到有，從有到準，從準到全，每個階段都會面臨不同的業務訴求，需要緊跟業務變化做迭代。

1.  數據引擎的變遷

2. 資源模式及架構優化

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

• 之前架構：領航+動力+PRESTO+BDP
• 弊端

     Presto集群無法資源隔離，易出現資源競爭；無法按業務條線對資源進行擴容；

     報表數據存放在BDP平臺，當前集群任務多，任務運行貫穿正常工作時段，容易造成BDP平臺繁忙導致報表數據讀取慢的情況。

• 解決方案：領航+動力+DORIS

引入新架構，資源獨占；解耦BDP平臺對數據展示影響

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

     查詢從10秒+到秒級響應提升

     獨立資源管控，按需優化

3. Doris表管理

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

1）表創建

2） 添加分區

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

3）刪除分區

TRUNCATE TABLE table_name PARTITION(p20200803,p20200804

注意事項：

• 規范分區，統一分區規則便于后續運維
• 導入時，會同時給所有Rollup 產生數據，過多的Rollup 會影響導入性能，評估Rollup創建個數
• 批量導入清理歷史數據建議小范圍多批次串行操作，合理利用資源

4. Doris數據導入：Hive2Doris通過Broker Load方式寫入

常用的數據導入操作，包括：

1） 轉換導入表格式

2）Broker Load

3） 追蹤導入狀態

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

注意事項：

• LABEL：用于指定這一批次導入的label，用于后期進行作業狀態查詢等
• max_filter_ratio：用于指定允許過濾不規范數據的最大比例，默認是0，不允許過濾,自定義指定應該如下：
  
• 'max_filter_ratio=0.2'，含義是允許20%的錯誤率
  
• timeout：指定load 作業的超時時間，單位是秒。當load執行時間超過該閾值時，會自動取消。默認超時時間是86400 秒。

5. 數據自動導入管理

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

-c 表示的是待推送數據的列名【該參數是可選，如果不選會默認推送所有列，建議不選擇】

-n 表示的是推送多長時間的數據【需要與參數-e聯動使用，如果不填寫，默認推送1天的數據】

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

-d 表示對doris數據庫的表進行操作【默認參數是：db_null 不執行建表】db_get_crt：表示打印出doris建表語句，該邏輯會讀取hive中的表結構，然后將HIVE中的字段為string類型的當成維，int，bigint，double類型的當成值生成建表語句【具體邏輯請參考腳本】

• db_reset ：表示重建表，如果調整表結構后，需要使用這個參數重構doris表結構【如果指定了-c參數，記得增加列】
• db_drop ：表示刪除doris中對應的表，用于下線任務
  
• db_create ：如果不存在對應的表就創建表，如果存在表就打印表結構下面，重點分享下縱向聯邦學習和橫向聯邦學習。

注意事項：

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

6. 自動報表實現

通過動力連接數據庫，把對應的表按照權限管理配置成數據源，在數據源上創建應用，可以讓業務人員在10分鐘搭建起符合自己預期的分析報表。

7. 待優化點：子查詢對應Rollup的影響

子查詢如果沒有生效rollup，外層是無法生效。

四、未來規劃

技術迭代是手段，對業務發展起促進作用才是目的，如何通過技術的升級實現業務技術相互促進。

 1. 離線數據技術升級

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

• 不斷優化迭代底層模型，對數據做最優整合，對主題模型的數據引入生命周期管理，表現在兩個方面：

     其一，模型隨著業務有新增，也必須有消亡；

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

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

2. 業務迭代技術跟進

隨著業務的不斷成熟，對精細化運營有了新的要求，會涉及到各方業務系統的迭代，數據處理需要夯實底層架構。

• 通用化：業財一體化融合，對成熟的業務實現到單的融合；
• 體系化：通過各維度損益模型串聯業務實際運營成本，支持業務分析，做全盤優化調優成本；
• 清晰化：看清每個經營動作成本，減少由于分攤造成“差異性“抹平，結合業務量、收入對不同環節進行改善；
• 靈活化：即席查詢，利用新的OLAP計算框架，支持各個維度數據查看，實現不同業務層級數據的上卷、下鉆。

3. 團隊建設

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

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

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