達(dá)達(dá)-京東到家大數(shù)據(jù)平臺是根據(jù)公司業(yè)務(wù)持續(xù)快速成長，而規(guī)劃建設(shè)的一個可持續(xù)發(fā)展的平臺。在建設(shè)過程中我們借鑒了很多公司實施大數(shù)據(jù)平臺的經(jīng)驗，并因地制宜構(gòu)建了我們自己的實施策略，確保在大方向上不會走偏，并且每一年都會有重大變化和質(zhì)的成長。

建設(shè)回顧

圖1 大數(shù)據(jù)平臺建設(shè)歷程

        2016年——DRP平臺建設(shè)

這個階段數(shù)據(jù)倉庫還是Mysql，所有工作幾乎都是圍繞著短、平、快實現(xiàn)重要核心報表而開展，DRP的成功實施大大減少了分析師的工作量，給公司數(shù)據(jù)驅(qū)動換上了新的引擎。

        2017年——工具專業(yè)化建設(shè)

這個階段數(shù)據(jù)倉庫已經(jīng)換成Hive，因為mysql實在跑不動了，但是圍繞數(shù)據(jù)的一些工具都是空白的，分析師需要靠自己強大的記憶力來記住重要的元數(shù)據(jù)信息，業(yè)務(wù)部門也只能通過分析師獲取數(shù)據(jù)。在這一年，統(tǒng)一權(quán)限管理、元數(shù)據(jù)平臺、自助報表平臺、自助查詢平臺、數(shù)據(jù)交換平臺等工具應(yīng)運而生，讓數(shù)據(jù)開放由設(shè)想變成實際可行。

        2018年——應(yīng)用體系化建設(shè)

由于歷史原因，這個時候整個平臺技術(shù)和應(yīng)用體系其實還是挺參差不齊的，隨之而來的是系統(tǒng)穩(wěn)定性比較差，DW值班人員經(jīng)常需要起夜處理問題。這一年我們花大力氣重構(gòu)了調(diào)度開發(fā)平臺、需求管理平臺，研發(fā)了數(shù)據(jù)質(zhì)量監(jiān)控系統(tǒng)，優(yōu)化了權(quán)限體系、報表體系、查詢體系和數(shù)據(jù)交換體系，自研了E-SQL來解決HUE糟糕的使用體驗。同時，在數(shù)據(jù)服務(wù)和數(shù)據(jù)應(yīng)用的建設(shè)上有了實際性的進(jìn)展，各種數(shù)據(jù)開始通過數(shù)據(jù)服務(wù)中臺更加直接的影響業(yè)務(wù)，蒼穹系統(tǒng)也探索完成首個業(yè)務(wù)模塊。

        2019年——資產(chǎn)生態(tài)化建設(shè)

2019年的主要方向是讓數(shù)據(jù)回歸資產(chǎn)本質(zhì)，讓平臺擁有生態(tài)體系，讓應(yīng)用實現(xiàn)產(chǎn)品驅(qū)動。我們會在數(shù)據(jù)倉庫建設(shè)上提煉行業(yè)數(shù)據(jù)資產(chǎn)；在計算引擎、存儲引擎、安全引擎及同步引擎上實現(xiàn)平臺生態(tài)化；在蒼穹系統(tǒng)建設(shè)上用更加產(chǎn)品化的思維幫助業(yè)務(wù)方發(fā)現(xiàn)問題并提供解決方案，提升大家的工作效率。

        下面我將簡單介紹一下當(dāng)前達(dá)達(dá)-京東到家大數(shù)據(jù)平臺的總體框架及主要組成部分的情況，并結(jié)合這些模塊的建設(shè)過程來闡述一下我們的實施策略。

總體框架

圖2 大數(shù)據(jù)平臺總體框架

        達(dá)達(dá)-京東到家大數(shù)據(jù)平臺作為同時支持公司達(dá)達(dá)物流和京東到家兩大事業(yè)群發(fā)展的基礎(chǔ)平臺，它由四部分組成：

統(tǒng)一的數(shù)據(jù)倉庫（One Data）、

統(tǒng)一的數(shù)據(jù)平臺(One Platform)、

統(tǒng)一的數(shù)據(jù)服務(wù)(One Service)、

豐富的數(shù)據(jù)應(yīng)用(Many Apps)

        如圖2所示，數(shù)據(jù)倉庫和數(shù)據(jù)平臺是基礎(chǔ)構(gòu)件，數(shù)據(jù)服務(wù)是將數(shù)據(jù)開放出去的中軸，而數(shù)據(jù)應(yīng)用是數(shù)據(jù)價值的最終體現(xiàn)者，整個大數(shù)據(jù)平臺建設(shè)致力于成為物流和零售行業(yè)數(shù)據(jù)驅(qū)動的標(biāo)桿。

一、統(tǒng)一數(shù)據(jù)倉庫（One Data）

圖3 數(shù)據(jù)倉庫主題

        統(tǒng)一的數(shù)據(jù)倉庫涉及物流和到家共計22個主題域，5000+的離線任務(wù)，120+的實時任務(wù)，數(shù)PB數(shù)據(jù)總量。在數(shù)據(jù)倉庫領(lǐng)域我們主要考慮的因素是覆蓋面、準(zhǔn)確性及穩(wěn)定性。

        1、覆蓋面

        數(shù)據(jù)覆蓋面是決定數(shù)據(jù)倉庫能否支持所有業(yè)務(wù)的基礎(chǔ)。想要完全覆蓋一個快速迭代和發(fā)展的業(yè)務(wù)，跟著業(yè)務(wù)系統(tǒng)走是行不通的，我們必須站在數(shù)據(jù)倉庫的視角來審視覆蓋的內(nèi)容行業(yè)本質(zhì)和用戶行為。如果把行業(yè)本質(zhì)和用戶行為的內(nèi)容都覆蓋了，那數(shù)據(jù)倉庫的覆蓋面就是完整的，需要解決的只是內(nèi)容的豐富度而已。

        從圖3看出，我們在達(dá)達(dá)物流及京東到家的數(shù)據(jù)主題域規(guī)劃上是分開的，但基本上大同小異。拿物流舉例：從行業(yè)本質(zhì)來說，物流是將一個客戶的物品配送到另外一個客戶，會產(chǎn)生賬戶交易和財務(wù)結(jié)算；從用戶行為來說，為了做好物流這個事，我們需要有公司的組織保障、必要的市場營銷及良好的客戶售后服務(wù)，這些用戶行為將共同沉淀下來客戶端設(shè)備信息、位置信息及流量日志信息等。對到家來說，商品銷售和社區(qū)管理是零售不可或缺的重要組成部分，而這個不是物流的必要組成部分。

        2、準(zhǔn)確性

        數(shù)據(jù)準(zhǔn)確性是數(shù)據(jù)倉庫產(chǎn)生價值的根本。我們通過統(tǒng)一數(shù)據(jù)源、統(tǒng)一數(shù)據(jù)建模、集中ETL處理來規(guī)避了源頭的不一致、模型的二義性及處理邏輯的偏差，同時通過數(shù)據(jù)質(zhì)量系統(tǒng)對核心指標(biāo)做了監(jiān)控預(yù)警，確保提供給出去的數(shù)據(jù)是準(zhǔn)確無誤的。

        3、穩(wěn)定性

        穩(wěn)定性是衡量數(shù)據(jù)倉庫成熟度最重要的因素。只有覆蓋度和準(zhǔn)確性，數(shù)據(jù)卻不能穩(wěn)定交付是不行的，我們在穩(wěn)定性提升的路上走得并不是太順利，很長一段時間這都是困擾我們的存在。為了保證穩(wěn)定性，我們采用了事前預(yù)防、事中處理及事后復(fù)盤等多種策略，目前穩(wěn)定性已經(jīng)明顯好轉(zhuǎn)。幾個重要的事情說明一下：

        ① 數(shù)據(jù)源探測：離線抽數(shù)和推數(shù)任務(wù)成百上千，任何一個數(shù)據(jù)源的變動都會導(dǎo)致任務(wù)報錯。雖然與DBA保持了良好的溝通，但是通過人工預(yù)判總是會疏漏一些結(jié)構(gòu)變化，每天定期做數(shù)據(jù)源探測則讓問題提前暴露，讓夜間抽數(shù)、推數(shù)報錯的概率大大降低。

        ② ETL優(yōu)化解耦：集群的資源永遠(yuǎn)是不夠用的，ETL性能優(yōu)化及鏈路解耦是日常有空就得做的事情。好處很明顯，正常執(zhí)行可以節(jié)省資源，異常重跑還可以節(jié)省時間。

        ③ 調(diào)度集群化：5000多個離線任務(wù)依賴調(diào)度系統(tǒng)運行，調(diào)度系統(tǒng)的高可用是非常核心的事情，任何一個調(diào)度環(huán)節(jié)出現(xiàn)單點故障，整個任務(wù)就會堵住，而大數(shù)據(jù)調(diào)度系統(tǒng)是個很復(fù)雜的系統(tǒng)，里面集成了很多任務(wù)類型的引擎，異常情況重新部署無論從資源協(xié)調(diào)還是部署時間上講都是不可行的。在調(diào)度未集群化之前，我們碰到過好幾次硬件故障導(dǎo)致只能等硬件搶修的情況，調(diào)度集群化之后我們在好幾次硬件宕機的情況下都安然無恙挺過。

        ④ 多重預(yù)警：期待不出問題是不可能的，當(dāng)問題發(fā)生時及時的人工干預(yù)就是最后的兜底。我們設(shè)置了值班人員-任務(wù)開發(fā)者-ETL負(fù)責(zé)人-部門負(fù)責(zé)人四道防線來確保不會漏接異常預(yù)警；同時我們設(shè)置了進(jìn)度預(yù)警機制，確認(rèn)任務(wù)掛起不報錯的情況下能夠發(fā)現(xiàn)問題。

        ⑤ 運維專業(yè)化：Hadoop是個復(fù)雜的平臺，集群上了規(guī)模之后，運維專業(yè)化非常必要。我們嚴(yán)格拆分了實時集群和離線集群，任何一個配置變動都需要經(jīng)過研發(fā)和運維的雙重審核。到目前為止，離線集群已經(jīng)一年多沒有重啟了，相對于早期“重啟是解決一切疑難雜癥的最后良藥”，這已經(jīng)是很大的進(jìn)步了。

二、統(tǒng)一數(shù)據(jù)平臺（One Platform）

圖4 數(shù)據(jù)平臺模塊

        統(tǒng)一的數(shù)據(jù)平臺涵蓋統(tǒng)一權(quán)限、開發(fā)平臺、數(shù)據(jù)采集、存儲引擎、計算引擎、資源管理和數(shù)據(jù)應(yīng)用等組件的封裝和集成，如圖4所示。

        ① 統(tǒng)一權(quán)限平臺：權(quán)限管理是數(shù)據(jù)安全的基礎(chǔ)，Hadoop生態(tài)的權(quán)限管理做的非常一般，覆蓋不全、實施復(fù)雜及性能瓶頸的問題都會遇到，基于這個原因我們是自研了權(quán)限管理平臺，將hdfs、hive、presto、kafka、es、redis等離線和實時的數(shù)據(jù)對象做了統(tǒng)一管理和授權(quán)，同時與公司的ldap打通，保障用戶的使用體驗。

        ② 調(diào)度開發(fā)平臺：大數(shù)據(jù)平臺的調(diào)度開發(fā)平臺有別于線上的純調(diào)度系統(tǒng)，為了保障開發(fā)的體驗及運行的可控，我們集成了離線任務(wù)、近線任務(wù)、實時任務(wù)及任務(wù)預(yù)警等很多引擎，與git集成支持版本管理，同時保障多機房、多集群、負(fù)載均衡等任務(wù)分發(fā)機制，它已經(jīng)是我們所有系統(tǒng)中最復(fù)雜的一個系統(tǒng)。目前配置2個主節(jié)點，每個機房或者每個集群同時配置2個以上的執(zhí)行從節(jié)點，任何一個節(jié)點出現(xiàn)問題，其它多活節(jié)點都可以無縫托管這個問題節(jié)點的任務(wù)。

        ③ 數(shù)據(jù)源及采集：目前主流的關(guān)系型數(shù)據(jù)庫、Kafka、文本文件及非關(guān)系型數(shù)據(jù)庫等都支持配置化抽取。同時支持對MYSQL智能增量抽取，所有目標(biāo)表及分區(qū)智能創(chuàng)建，大幅提升了ETL開發(fā)的工作效率。

        ④ 數(shù)據(jù)存儲：離線數(shù)據(jù)按天以上的頻度更新，以Hive、HDFS和Hbase存儲為主；近線數(shù)據(jù)按分鐘級的頻度更新，以Hive存儲為主，通過Presto提供查詢；實時數(shù)據(jù)根據(jù)應(yīng)用的特性會存放在kafka、redis、hbase、es、druid及mysql中。

        ⑤ 資源管理：資源管理這塊沒有做太多了封裝，主要基于Yarn做了部分隊列的資源限制和權(quán)限限制。

        ⑥ 數(shù)據(jù)計算：實時計算引擎我們早期是基于Spark Streaming定制開發(fā)，目前已經(jīng)基本遷移到Flink，并且基于開源的FLinkStreamSQL封裝了我們自己基于SQL的流式任務(wù)；近線計算引擎我們早期是基于Spark SQL定制開發(fā)，目前已經(jīng)全部遷移到封裝好的基于SQL的Spark SQL引擎，并且同時支持Spark 1.6和Spark 2.2，與此同時我們所有的數(shù)據(jù)都支持以Presto引擎對用戶開放；離線計算引擎以Hive為主，我們正計劃通過封裝好的Spark SQL來逐步代替Hive引擎。

        ⑦ 數(shù)據(jù)應(yīng)用：目前數(shù)據(jù)應(yīng)用主要包括數(shù)據(jù)產(chǎn)品、查詢體系、算法應(yīng)用、數(shù)據(jù)分析以及數(shù)據(jù)服務(wù)等這幾個方向。每個方向的用戶群體和使用場景都不太一樣，在設(shè)計應(yīng)用架構(gòu)時需要特別考慮這些因素，以精簡實用為主，避免周期長、大而全的建設(shè)，那樣研發(fā)試錯成本及應(yīng)用實用化會是非常大的問題。

三、統(tǒng)一數(shù)據(jù)服務(wù)（One Service）

圖5 數(shù)據(jù)中臺服務(wù)

        統(tǒng)一的數(shù)據(jù)服務(wù)整合了優(yōu)質(zhì)的數(shù)據(jù)倉庫和數(shù)據(jù)平臺資源，將數(shù)據(jù)以最短鏈路提供給數(shù)據(jù)應(yīng)用、線上業(yè)務(wù)及開放平臺，如圖5所示，承擔(dān)的是數(shù)據(jù)中臺的職責(zé)，目標(biāo)是讓內(nèi)外部應(yīng)用更加便捷的獲取到數(shù)據(jù)，加速數(shù)據(jù)的利用。統(tǒng)一數(shù)據(jù)服務(wù)是個邏輯上的概念，更側(cè)重于歸口建設(shè)、統(tǒng)一標(biāo)準(zhǔn)和集中管理，物理部署上我們是分開的。

        ① 中間庫服務(wù)：早期數(shù)據(jù)服務(wù)很簡單，就是提供中間庫服務(wù)，誰要數(shù)據(jù)去中間庫取。隨著應(yīng)用的深入和數(shù)據(jù)量的增加，中間庫接口實現(xiàn)起來不僅費時費力，而且無法承載大數(shù)據(jù)量的交互。鑒于此，我們增加文件存儲服務(wù)和API服務(wù)。

        ② 存儲服務(wù)：通過把數(shù)據(jù)轉(zhuǎn)化成文本，存放到共享的sftp、http存儲及云盤等，需求方只要下載文件就可以解釋入庫，解決了大數(shù)據(jù)量交互的問題，但需求方還是需要開發(fā)對應(yīng)的解釋入庫程序。

        ③ API服務(wù)：對于單次數(shù)據(jù)獲取量不大，讓數(shù)據(jù)需求方開發(fā)中間庫服務(wù)或者存儲服務(wù)接口，成本上比較高，而且同一接口不同需求方要重復(fù)建設(shè)，確實影響效率和浪費成本。鑒于此，通過數(shù)據(jù)部集中設(shè)計和開發(fā)api服務(wù)就應(yīng)運而生，最開始我們每個api接口都需要定制開發(fā)，目前我們已經(jīng)研發(fā)了基于配置化的通用服務(wù)，對redis、hbase、es、druid、mysql等存儲引擎的數(shù)據(jù)，通過配置一個簡單的SQL或者一些表和字段名就能很方便的開發(fā)出一個數(shù)據(jù)服務(wù)接口。

四、豐富數(shù)據(jù)應(yīng)用（Many Apps）

圖6 數(shù)據(jù)應(yīng)用模塊

        豐富的數(shù)據(jù)應(yīng)用包括了BI自建應(yīng)用、共享平臺應(yīng)用以及共建業(yè)務(wù)應(yīng)用等三部分，如圖6所示。

        ① BI自建應(yīng)用：包含以蒼穹平臺為主的數(shù)據(jù)運營體系，以DRP和MiniReport為主的報表體系，以MyQuery和E-SQL為主的查詢體系，以調(diào)度開發(fā)為主的數(shù)據(jù)平臺體系，以及在移動端、H5端和微信端的各種定制數(shù)據(jù)產(chǎn)品應(yīng)用。

        ② 共享平臺應(yīng)用：在BI自建應(yīng)用中My-Query、MiniReport作為共享平臺開放給了公司總部所有業(yè)務(wù)部門，調(diào)度開發(fā)平臺開放給了BI相關(guān)部門，這三個平臺支持用戶在上面構(gòu)建屬于自己的應(yīng)用或者任務(wù)；

        ③ 共建業(yè)務(wù)應(yīng)用：包括了以平臺、商戶和品牌為主的CRM體系，以物流和到家算法為主的算法應(yīng)用，以及圍繞訂單、配送、商戶、商品、營銷、廣告等業(yè)務(wù)的線上業(yè)務(wù)應(yīng)用。在這些系統(tǒng)的建設(shè)過程中，數(shù)據(jù)中臺服務(wù)發(fā)揮了重大作用，將復(fù)雜的數(shù)據(jù)計算與整合環(huán)節(jié)全部交給數(shù)據(jù)部，業(yè)務(wù)部門只要專注于實現(xiàn)業(yè)務(wù)場景即可，實施效率得到了大幅度的提升。

        對BI自建應(yīng)用和共享平臺來說，使用頻次是考核這個系統(tǒng)是否成功的重要標(biāo)準(zhǔn)。基于研發(fā)資源狀況，我們并沒有追求應(yīng)用的數(shù)量，而是爭取把每個應(yīng)用質(zhì)量做到最好。到目前為止，DRP、燈塔、MiniReport、MyQuery、E-SQL等系統(tǒng)的查詢頻次都達(dá)到了每天數(shù)千人次，為業(yè)務(wù)部門獲取數(shù)據(jù)提供了極為方便且多樣的選擇；同時，我們對DRP的官方報表做了嚴(yán)格篩選，到目前為止也沒超過300個，但共享平臺MiniReport和MyQuery上的自助報表和自助查詢數(shù)據(jù)都達(dá)到了600+，它們?yōu)闃I(yè)務(wù)探索期間的數(shù)據(jù)獲取及監(jiān)控提供了簡單有效的解決方案，深受公司內(nèi)廣大用戶喜歡。

總結(jié)展望

        如果用一個人的成長期來比喻，那么達(dá)達(dá)-京東到家大數(shù)據(jù)平臺正好進(jìn)入了青年期，在經(jīng)過了懵懂的少年期之后，正在快速的向壯年期邁進(jìn)，我們將會在數(shù)據(jù)賦能及技術(shù)縱深領(lǐng)域做出更多積極的探索。