達(dá)達(dá)-京東到家大數(shù)據(jù)平臺(tái)是根據(jù)公司業(yè)務(wù)持續(xù)快速成長，而規(guī)劃建設(shè)的一個(gè)可持續(xù)發(fā)展的平臺(tái)。在建設(shè)過程中我們借鑒了很多公司實(shí)施大數(shù)據(jù)平臺(tái)的經(jīng)驗(yàn)，并因地制宜構(gòu)建了我們自己的實(shí)施策略，確保在大方向上不會(huì)走偏，并且每一年都會(huì)有重大變化和質(zhì)的成長。
建設(shè)回顧
2016年——DRP平臺(tái)建設(shè)
這個(gè)階段數(shù)據(jù)倉庫還是Mysql，所有工作幾乎都是圍繞著短、平、快實(shí)現(xiàn)重要核心報(bào)表而開展，DRP的成功實(shí)施大大減少了分析師的工作量，給公司數(shù)據(jù)驅(qū)動(dòng)換上了新的引擎。
2017年——工具專業(yè)化建設(shè)
這個(gè)階段數(shù)據(jù)倉庫已經(jīng)換成Hive，因?yàn)閙ysql實(shí)在跑不動(dòng)了，但是圍繞數(shù)據(jù)的一些工具都是空白的，分析師需要靠自己強(qiáng)大的記憶力來記住重要的元數(shù)據(jù)信息，業(yè)務(wù)部門也只能通過分析師獲取數(shù)據(jù)。在這一年，統(tǒng)一權(quán)限管理、元數(shù)據(jù)平臺(tái)、自助報(bào)表平臺(tái)、自助查詢平臺(tái)、數(shù)據(jù)交換平臺(tái)等工具應(yīng)運(yùn)而生，讓數(shù)據(jù)開放由設(shè)想變成實(shí)際可行。
2018年——應(yīng)用體系化建設(shè)
由于歷史原因，這個(gè)時(shí)候整個(gè)平臺(tái)技術(shù)和應(yīng)用體系其實(shí)還是挺參差不齊的，隨之而來的是系統(tǒng)穩(wěn)定性比較差，DW值班人員經(jīng)常需要起夜處理問題。這一年我們花大力氣重構(gòu)了調(diào)度開發(fā)平臺(tái)、需求管理平臺(tái)，研發(fā)了數(shù)據(jù)質(zhì)量監(jiān)控系統(tǒng)，優(yōu)化了權(quán)限體系、報(bào)表體系、查詢體系和數(shù)據(jù)交換體系，自研了E-SQL來解決HUE糟糕的使用體驗(yàn)。同時(shí)，在數(shù)據(jù)服務(wù)和數(shù)據(jù)應(yīng)用的建設(shè)上有了實(shí)際性的進(jìn)展，各種數(shù)據(jù)開始通過數(shù)據(jù)服務(wù)中臺(tái)更加直接的影響業(yè)務(wù)，蒼穹系統(tǒng)也探索完成首個(gè)業(yè)務(wù)模塊。
2019年——資產(chǎn)生態(tài)化建設(shè)
2019年的主要方向是讓數(shù)據(jù)回歸資產(chǎn)本質(zhì)，讓平臺(tái)擁有生態(tài)體系，讓應(yīng)用實(shí)現(xiàn)產(chǎn)品驅(qū)動(dòng)。我們會(huì)在數(shù)據(jù)倉庫建設(shè)上提煉行業(yè)數(shù)據(jù)資產(chǎn)；在計(jì)算引擎、存儲(chǔ)引擎、安全引擎及同步引擎上實(shí)現(xiàn)平臺(tái)生態(tài)化；在蒼穹系統(tǒng)建設(shè)上用更加產(chǎn)品化的思維幫助業(yè)務(wù)方發(fā)現(xiàn)問題并提供解決方案，提升大家的工作效率。
下面我將簡(jiǎn)單介紹一下當(dāng)前達(dá)達(dá)-京東到家大數(shù)據(jù)平臺(tái)的總體框架及主要組成部分的情況，并結(jié)合這些模塊的建設(shè)過程來闡述一下我們的實(shí)施策略。
總體框架
達(dá)達(dá)-京東到家大數(shù)據(jù)平臺(tái)作為同時(shí)支持公司達(dá)達(dá)物流和京東到家兩大事業(yè)群發(fā)展的基礎(chǔ)平臺(tái)，它由四部分組成：
統(tǒng)一的數(shù)據(jù)倉庫（One Data）、統(tǒng)一的數(shù)據(jù)平臺(tái)(One Platform)、統(tǒng)一的數(shù)據(jù)服務(wù)(One Service)、豐富的數(shù)據(jù)應(yīng)用(Many Apps)
如圖2所示，數(shù)據(jù)倉庫和數(shù)據(jù)平臺(tái)是基礎(chǔ)構(gòu)件，數(shù)據(jù)服務(wù)是將數(shù)據(jù)開放出去的中軸，而數(shù)據(jù)應(yīng)用是數(shù)據(jù)價(jià)值的最終體現(xiàn)者，整個(gè)大數(shù)據(jù)平臺(tái)建設(shè)致力于成為物流和零售行業(yè)數(shù)據(jù)驅(qū)動(dòng)的標(biāo)桿。
一、統(tǒng)一數(shù)據(jù)倉庫（One Data）
統(tǒng)一的數(shù)據(jù)倉庫涉及物流和到家共計(jì)22個(gè)主題域，5000+的離線任務(wù)，120+的實(shí)時(shí)任務(wù)，數(shù)PB數(shù)據(jù)總量。在數(shù)據(jù)倉庫領(lǐng)域我們主要考慮的因素是覆蓋面、準(zhǔn)確性及穩(wěn)定性。
1、覆蓋面
數(shù)據(jù)覆蓋面是決定數(shù)據(jù)倉庫能否支持所有業(yè)務(wù)的基礎(chǔ)。想要完全覆蓋一個(gè)快速迭代和發(fā)展的業(yè)務(wù)，跟著業(yè)務(wù)系統(tǒng)走是行不通的，我們必須站在數(shù)據(jù)倉庫的視角來審視覆蓋的內(nèi)容——行業(yè)本質(zhì)和用戶行為。如果把行業(yè)本質(zhì)和用戶行為的內(nèi)容都覆蓋了，那數(shù)據(jù)倉庫的覆蓋面就是完整的，需要解決的只是內(nèi)容的豐富度而已。
從圖3看出，我們?cè)谶_(dá)達(dá)物流及京東到家的數(shù)據(jù)主題域規(guī)劃上是分開的，但基本上大同小異。拿物流舉例：從行業(yè)本質(zhì)來說，物流是將一個(gè)客戶的物品配送到另外一個(gè)客戶，會(huì)產(chǎn)生賬戶交易和財(cái)務(wù)結(jié)算；從用戶行為來說，為了做好物流這個(gè)事，我們需要有公司的組織保障、必要的市場(chǎng)營銷及良好的客戶售后服務(wù)，這些用戶行為將共同沉淀下來客戶端設(shè)備信息、位置信息及流量日志信息等。對(duì)到家來說，商品銷售和社區(qū)管理是零售不可或缺的重要組成部分，而這個(gè)不是物流的必要組成部分。
2、準(zhǔn)確性
數(shù)據(jù)準(zhǔn)確性是數(shù)據(jù)倉庫產(chǎn)生價(jià)值的根本。我們通過統(tǒng)一數(shù)據(jù)源、統(tǒng)一數(shù)據(jù)建模、集中ETL處理來規(guī)避了源頭的不一致、模型的二義性及處理邏輯的偏差，同時(shí)通過數(shù)據(jù)質(zhì)量系統(tǒng)對(duì)核心指標(biāo)做了監(jiān)控預(yù)警，確保提供給出去的數(shù)據(jù)是準(zhǔn)確無誤的。
3、穩(wěn)定性
穩(wěn)定性是衡量數(shù)據(jù)倉庫成熟度最重要的因素。只有覆蓋度和準(zhǔn)確性，數(shù)據(jù)卻不能穩(wěn)定交付是不行的，我們?cè)诜€(wěn)定性提升的路上走得并不是太順利，很長一段時(shí)間這都是困擾我們的存在。為了保證穩(wěn)定性，我們采用了事前預(yù)防、事中處理及事后復(fù)盤等多種策略，目前穩(wěn)定性已經(jīng)明顯好轉(zhuǎn)。幾個(gè)重要的事情說明一下：
① 數(shù)據(jù)源探測(cè)：離線抽數(shù)和推數(shù)任務(wù)成百上千，任何一個(gè)數(shù)據(jù)源的變動(dòng)都會(huì)導(dǎo)致任務(wù)報(bào)錯(cuò)。雖然與DBA保持了良好的溝通，但是通過人工預(yù)判總是會(huì)疏漏一些結(jié)構(gòu)變化，每天定期做數(shù)據(jù)源探測(cè)則讓問題提前暴露，讓夜間抽數(shù)、推數(shù)報(bào)錯(cuò)的概率大大降低。
② ETL優(yōu)化解耦：集群的資源永遠(yuǎn)是不夠用的，ETL性能優(yōu)化及鏈路解耦是日常有空就得做的事情。好處很明顯，正常執(zhí)行可以節(jié)省資源，異常重跑還可以節(jié)省時(shí)間。
③ 調(diào)度集群化：5000多個(gè)離線任務(wù)依賴調(diào)度系統(tǒng)運(yùn)行，調(diào)度系統(tǒng)的高可用是非常核心的事情，任何一個(gè)調(diào)度環(huán)節(jié)出現(xiàn)單點(diǎn)故障，整個(gè)任務(wù)就會(huì)堵住，而大數(shù)據(jù)調(diào)度系統(tǒng)是個(gè)很復(fù)雜的系統(tǒng)，里面集成了很多任務(wù)類型的引擎，異常情況重新部署無論從資源協(xié)調(diào)還是部署時(shí)間上講都是不可行的。在調(diào)度未集群化之前，我們碰到過好幾次硬件故障導(dǎo)致只能等硬件搶修的情況，調(diào)度集群化之后我們?cè)诤脦状斡布礄C(jī)的情況下都安然無恙挺過。
④ 多重預(yù)警：期待不出問題是不可能的，當(dāng)問題發(fā)生時(shí)及時(shí)的人工干預(yù)就是最后的兜底。我們?cè)O(shè)置了值班人員-任務(wù)開發(fā)者-ETL負(fù)責(zé)人-部門負(fù)責(zé)人四道防線來確保不會(huì)漏接異常預(yù)警；同時(shí)我們?cè)O(shè)置了進(jìn)度預(yù)警機(jī)制，確認(rèn)任務(wù)掛起不報(bào)錯(cuò)的情況下能夠發(fā)現(xiàn)問題。
⑤ 運(yùn)維專業(yè)化：Hadoop是個(gè)復(fù)雜的平臺(tái)，集群上了規(guī)模之后，運(yùn)維專業(yè)化非常必要。我們嚴(yán)格拆分了實(shí)時(shí)集群和離線集群，任何一個(gè)配置變動(dòng)都需要經(jīng)過研發(fā)和運(yùn)維的雙重審核。到目前為止，離線集群已經(jīng)一年多沒有重啟了，相對(duì)于早期“重啟是解決一切疑難雜癥的最后良藥”，這已經(jīng)是很大的進(jìn)步了。
二、統(tǒng)一數(shù)據(jù)平臺(tái)（One Platform）
統(tǒng)一的數(shù)據(jù)平臺(tái)涵蓋統(tǒng)一權(quán)限、開發(fā)平臺(tái)、數(shù)據(jù)采集、存儲(chǔ)引擎、計(jì)算引擎、資源管理和數(shù)據(jù)應(yīng)用等組件的封裝和集成，如圖4所示。
① 統(tǒng)一權(quán)限平臺(tái)：權(quán)限管理是數(shù)據(jù)安全的基礎(chǔ)，Hadoop生態(tài)的權(quán)限管理做的非常一般，覆蓋不全、實(shí)施復(fù)雜及性能瓶頸的問題都會(huì)遇到，基于這個(gè)原因我們是自研了權(quán)限管理平臺(tái)，將hdfs、hive、presto、kafka、es、redis等離線和實(shí)時(shí)的數(shù)據(jù)對(duì)象做了統(tǒng)一管理和授權(quán)，同時(shí)與公司的ldap打通，保障用戶的使用體驗(yàn)。
② 調(diào)度開發(fā)平臺(tái)：大數(shù)據(jù)平臺(tái)的調(diào)度開發(fā)平臺(tái)有別于線上的純調(diào)度系統(tǒng)，為了保障開發(fā)的體驗(yàn)及運(yùn)行的可控，我們集成了離線任務(wù)、近線任務(wù)、實(shí)時(shí)任務(wù)及任務(wù)預(yù)警等很多引擎，與git集成支持版本管理，同時(shí)保障多機(jī)房、多集群、負(fù)載均衡等任務(wù)分發(fā)機(jī)制，它已經(jīng)是我們所有系統(tǒng)中最復(fù)雜的一個(gè)系統(tǒng)。目前配置2個(gè)主節(jié)點(diǎn)，每個(gè)機(jī)房或者每個(gè)集群同時(shí)配置2個(gè)以上的執(zhí)行從節(jié)點(diǎn)，任何一個(gè)節(jié)點(diǎn)出現(xiàn)問題，其它多活節(jié)點(diǎn)都可以無縫托管這個(gè)問題節(jié)點(diǎn)的任務(wù)。
③ 數(shù)據(jù)源及采集：目前主流的關(guān)系型數(shù)據(jù)庫、Kafka、文本文件及非關(guān)系型數(shù)據(jù)庫等都支持配置化抽取。同時(shí)支持對(duì)MYSQL智能增量抽取，所有目標(biāo)表及分區(qū)智能創(chuàng)建，大幅提升了ETL開發(fā)的工作效率。
④ 數(shù)據(jù)存儲(chǔ)：離線數(shù)據(jù)按天以上的頻度更新，以Hive、HDFS和Hbase存儲(chǔ)為主；近線數(shù)據(jù)按分鐘級(jí)的頻度更新，以Hive存儲(chǔ)為主，通過Presto提供查詢；實(shí)時(shí)數(shù)據(jù)根據(jù)應(yīng)用的特性會(huì)存放在kafka、redis、hbase、es、druid及mysql中。
⑤ 資源管理：資源管理這塊沒有做太多了封裝，主要基于Yarn做了部分隊(duì)列的資源限制和權(quán)限限制。
⑥ 數(shù)據(jù)計(jì)算：實(shí)時(shí)計(jì)算引擎我們?cè)缙谑腔赟park Streaming定制開發(fā)，目前已經(jīng)基本遷移到Flink，并且基于開源的FLinkStreamSQL封裝了我們自己基于SQL的流式任務(wù)；近線計(jì)算引擎我們?cè)缙谑腔赟park SQL定制開發(fā)，目前已經(jīng)全部遷移到封裝好的基于SQL的Spark SQL引擎，并且同時(shí)支持Spark 1.6和Spark 2.2，與此同時(shí)我們所有的數(shù)據(jù)都支持以Presto引擎對(duì)用戶開放；離線計(jì)算引擎以Hive為主，我們正計(jì)劃通過封裝好的Spark SQL來逐步代替Hive引擎。
⑦ 數(shù)據(jù)應(yīng)用：目前數(shù)據(jù)應(yīng)用主要包括數(shù)據(jù)產(chǎn)品、查詢體系、算法應(yīng)用、數(shù)據(jù)分析以及數(shù)據(jù)服務(wù)等這幾個(gè)方向。每個(gè)方向的用戶群體和使用場(chǎng)景都不太一樣，在設(shè)計(jì)應(yīng)用架構(gòu)時(shí)需要特別考慮這些因素，以精簡(jiǎn)實(shí)用為主，避免周期長、大而全的建設(shè)，那樣研發(fā)試錯(cuò)成本及應(yīng)用實(shí)用化會(huì)是非常大的問題。
三、統(tǒng)一數(shù)據(jù)服務(wù)（One Service）
統(tǒng)一的數(shù)據(jù)服務(wù)整合了優(yōu)質(zhì)的數(shù)據(jù)倉庫和數(shù)據(jù)平臺(tái)資源，將數(shù)據(jù)以最短鏈路提供給數(shù)據(jù)應(yīng)用、線上業(yè)務(wù)及開放平臺(tái)，如圖5所示，承擔(dān)的是數(shù)據(jù)中臺(tái)的職責(zé)，目標(biāo)是讓內(nèi)外部應(yīng)用更加便捷的獲取到數(shù)據(jù)，加速數(shù)據(jù)的利用。統(tǒng)一數(shù)據(jù)服務(wù)是個(gè)邏輯上的概念，更側(cè)重于歸口建設(shè)、統(tǒng)一標(biāo)準(zhǔn)和集中管理，物理部署上我們是分開的。
① 中間庫服務(wù)：早期數(shù)據(jù)服務(wù)很簡(jiǎn)單，就是提供中間庫服務(wù)，誰要數(shù)據(jù)去中間庫取。隨著應(yīng)用的深入和數(shù)據(jù)量的增加，中間庫接口實(shí)現(xiàn)起來不僅費(fèi)時(shí)費(fèi)力，而且無法承載大數(shù)據(jù)量的交互。鑒于此，我們?cè)黾游募鎯?chǔ)服務(wù)和API服務(wù)。
② 存儲(chǔ)服務(wù)：通過把數(shù)據(jù)轉(zhuǎn)化成文本，存放到共享的sftp、http存儲(chǔ)及云盤等，需求方只要下載文件就可以解釋入庫，解決了大數(shù)據(jù)量交互的問題，但需求方還是需要開發(fā)對(duì)應(yīng)的解釋入庫程序。
③ API服務(wù)：對(duì)于單次數(shù)據(jù)獲取量不大，讓數(shù)據(jù)需求方開發(fā)中間庫服務(wù)或者存儲(chǔ)服務(wù)接口，成本上比較高，而且同一接口不同需求方要重復(fù)建設(shè)，確實(shí)影響效率和浪費(fèi)成本。鑒于此，通過數(shù)據(jù)部集中設(shè)計(jì)和開發(fā)api服務(wù)就應(yīng)運(yùn)而生，最開始我們每個(gè)api接口都需要定制開發(fā)，目前我們已經(jīng)研發(fā)了基于配置化的通用服務(wù)，對(duì)redis、hbase、es、druid、mysql等存儲(chǔ)引擎的數(shù)據(jù)，通過配置一個(gè)簡(jiǎn)單的SQL或者一些表和字段名就能很方便的開發(fā)出一個(gè)數(shù)據(jù)服務(wù)接口。
四、豐富數(shù)據(jù)應(yīng)用（Many Apps）
豐富的數(shù)據(jù)應(yīng)用包括了BI自建應(yīng)用、共享平臺(tái)應(yīng)用以及共建業(yè)務(wù)應(yīng)用等三部分，如圖6所示。
① BI自建應(yīng)用：包含以蒼穹平臺(tái)為主的數(shù)據(jù)運(yùn)營體系，以DRP和MiniReport為主的報(bào)表體系，以MyQuery和E-SQL為主的查詢體系，以調(diào)度開發(fā)為主的數(shù)據(jù)平臺(tái)體系，以及在移動(dòng)端、H5端和微信端的各種定制數(shù)據(jù)產(chǎn)品應(yīng)用。
② 共享平臺(tái)應(yīng)用：在BI自建應(yīng)用中My-Query、MiniReport作為共享平臺(tái)開放給了公司總部所有業(yè)務(wù)部門，調(diào)度開發(fā)平臺(tái)開放給了BI相關(guān)部門，這三個(gè)平臺(tái)支持用戶在上面構(gòu)建屬于自己的應(yīng)用或者任務(wù)；
③ 共建業(yè)務(wù)應(yīng)用：包括了以平臺(tái)、商戶和品牌為主的CRM體系，以物流和到家算法為主的算法應(yīng)用，以及圍繞訂單、配送、商戶、商品、營銷、廣告等業(yè)務(wù)的線上業(yè)務(wù)應(yīng)用。在這些系統(tǒng)的建設(shè)過程中，數(shù)據(jù)中臺(tái)服務(wù)發(fā)揮了重大作用，將復(fù)雜的數(shù)據(jù)計(jì)算與整合環(huán)節(jié)全部交給數(shù)據(jù)部，業(yè)務(wù)部門只要專注于實(shí)現(xiàn)業(yè)務(wù)場(chǎng)景即可，實(shí)施效率得到了大幅度的提升。
對(duì)BI自建應(yīng)用和共享平臺(tái)來說，使用頻次是考核這個(gè)系統(tǒng)是否成功的重要標(biāo)準(zhǔn)。基于研發(fā)資源狀況，我們并沒有追求應(yīng)用的數(shù)量，而是爭(zhēng)取把每個(gè)應(yīng)用質(zhì)量做到最好。到目前為止，DRP、燈塔、MiniReport、MyQuery、E-SQL等系統(tǒng)的查詢頻次都達(dá)到了每天數(shù)千人次，為業(yè)務(wù)部門獲取數(shù)據(jù)提供了極為方便且多樣的選擇；同時(shí)，我們對(duì)DRP的官方報(bào)表做了嚴(yán)格篩選，到目前為止也沒超過300個(gè)，但共享平臺(tái)MiniReport和MyQuery上的自助報(bào)表和自助查詢數(shù)據(jù)都達(dá)到了600+，它們?yōu)闃I(yè)務(wù)探索期間的數(shù)據(jù)獲取及監(jiān)控提供了簡(jiǎn)單有效的解決方案，深受公司內(nèi)廣大用戶喜歡。
總結(jié)展望
如果用一個(gè)人的成長期來比喻，那么達(dá)達(dá)-京東到家大數(shù)據(jù)平臺(tái)正好進(jìn)入了青年期，在經(jīng)過了懵懂的少年期之后，正在快速的向壯年期邁進(jìn)，我們將會(huì)在數(shù)據(jù)賦能及技術(shù)縱深領(lǐng)域做出更多積極的探索。
