大數(shù)據(jù)技術白皮書

京東大數(shù)據(jù)技術白皮書前言大數(shù)據(jù)概念近年來受到高度關注，大數(shù)據(jù)在各個行業(yè)的應用及其帶來的影響也引起越來越多的討論。大數(shù)據(jù)正在從單純的技術概念向實際部署應用轉變；從少數(shù)領域向眾多領域滲透；從企業(yè)內(nèi)部向各產(chǎn)業(yè)與公共服務方向擴展。目前，無論國內(nèi)還是國外，大數(shù)據(jù)技術都在經(jīng)歷前所未有的快速演變，以滿足各種應用的需求。我國已將大數(shù)據(jù)發(fā)展確定為國家戰(zhàn)略，強調(diào)要瞄準世界科技前沿，集中優(yōu)勢資源突破大數(shù)據(jù)核心技術，加快構建自主可控的大數(shù)據(jù)產(chǎn)業(yè)鏈、價值鏈和生態(tài)系統(tǒng)。大數(shù)據(jù)產(chǎn)業(yè)在國內(nèi)發(fā)展得如火如荼，據(jù)統(tǒng)計，2016年大數(shù)據(jù)產(chǎn)業(yè)規(guī)模達14500億元，2017年達19570億元，到2020年將達到5萬億元。大數(shù)據(jù)技術已經(jīng)在如電子商務、政務、民生、金融、工業(yè)、醫(yī)療等多個領域中廣泛應用。從國內(nèi)的大數(shù)據(jù)技術和行業(yè)應用發(fā)展來看，大數(shù)據(jù)技術的基礎架構技術已日趨成熟，大數(shù)據(jù)領域由技術創(chuàng)新驅動轉向應用創(chuàng)新驅動的趨勢開始顯現(xiàn)，但更多的傳統(tǒng)企業(yè)在如何建設大數(shù)據(jù)平臺，如何利用大數(shù)據(jù)來驅動企業(yè)業(yè)務發(fā)展上仍然缺乏經(jīng)驗，這在一定程度上制約了大數(shù)據(jù)技術的大規(guī)模產(chǎn)業(yè)應用。京東擁有全渠道零售和端到端的高質(zhì)量大數(shù)據(jù)，包含了用戶的瀏覽和消費行為、商品制造和銷售、物流倉儲配送以及客服與~5~京東大數(shù)據(jù)技術白皮書售后等豐富完整的信息。同時，京東業(yè)務中包含有大量豐富的大數(shù)據(jù)應用場景，是大數(shù)據(jù)實踐的最佳場所。早在2010年，京東集團就啟動了大數(shù)據(jù)領域的研發(fā)和應用探索工作，經(jīng)過八年來的持續(xù)投入，京東大數(shù)據(jù)平臺無論從規(guī)模、技術先進性，還是體系的完整性等方面均已達到國內(nèi)一流水平。作為支撐公司數(shù)據(jù)運營的重要陣地，目前已擁有集群規(guī)模40000+服務器，數(shù)據(jù)規(guī)模達800PB+，每日的JOB數(shù)100萬+，業(yè)務表900萬+，每日的離線數(shù)據(jù)日處理量30PB+，單集群規(guī)模達到7000+臺，實時計算每天消費的數(shù)據(jù)記錄近萬億條。京東大數(shù)據(jù)平臺建設了完整的技術體系，包括離線計算、實時計算和機器學習平臺，可以滿足多種復雜應用場景的計算任務。元數(shù)據(jù)管理、數(shù)據(jù)質(zhì)量管理、任務調(diào)度、數(shù)據(jù)開發(fā)工具、流程中心等構成了全面的數(shù)據(jù)運營工具。分析師、指南針等數(shù)據(jù)應用產(chǎn)品提供了便利的數(shù)據(jù)分析功能，以及敏感數(shù)據(jù)保護、數(shù)據(jù)權限控制等策略方案，能夠最大程度地保護數(shù)據(jù)資產(chǎn)的安全。京東大數(shù)據(jù)在驅動企業(yè)業(yè)務增長，提升運營效率，為客戶提供個性化、高品質(zhì)產(chǎn)品及服務上發(fā)揮了重要作用。利用大數(shù)據(jù)分析和挖掘，京東打造了個性化商城，自主研發(fā)了智能門店解決方案，打造了智能供應鏈體系，提高了物流配送的效率，實現(xiàn)了知人、知貨、知場景的購物體驗。京東大數(shù)據(jù)的應用已滲透到了業(yè)務的各個環(huán)節(jié)。近幾年，京東大數(shù)據(jù)承擔了包括大數(shù)據(jù)和人工智能領域在內(nèi)~6~京東大數(shù)據(jù)技術白皮書的多項國家級重點研發(fā)項目。2017年，京東獲得了國家“大數(shù)據(jù)智能管理與分析技術”國家地方聯(lián)合工程研究中心的授牌。這些都是國家對京東大數(shù)據(jù)實力的認可，是京東技術實力的體現(xiàn)。京東是“開放的京東”，隨著國家大數(shù)據(jù)戰(zhàn)略的逐步落實，我們希望能輸出京東的大數(shù)據(jù)技術能力，建設開放的技術平臺，借助技術和數(shù)據(jù)為政府和社會創(chuàng)造更多價值，我們希望借此白皮書的發(fā)布，將京東的大數(shù)據(jù)技術實踐分享出來，為其他企業(yè)提供參考，同時，我們也歡迎更多的合作伙伴與我們一道，共同在大數(shù)據(jù)領域深入探索，為我國大數(shù)據(jù)產(chǎn)業(yè)的發(fā)展貢獻力量。~7~京東大數(shù)據(jù)技術白皮書1京東大數(shù)據(jù)的發(fā)展歷程2010年，京東集團啟動了在大數(shù)據(jù)領域的研發(fā)和應用探索工作，正式組建京東大數(shù)據(jù)部，并確立了數(shù)據(jù)集中式的數(shù)據(jù)服務模式，成為企業(yè)大數(shù)據(jù)最早的實踐者之一。大數(shù)據(jù)平臺的發(fā)展是隨著京東業(yè)務同步發(fā)展的，由原來的傳統(tǒng)數(shù)據(jù)倉庫模式逐步演變?yōu)榛贖adoop的分布式計算架構，如圖1所示。技術領域覆蓋Hadoop、Kubernetes、Spark、Hive、Alluxio、Presto、Hbase、Storm、Flink、Kafka等大數(shù)據(jù)全生態(tài)體系。目前擁有研發(fā)團隊500+人，累計獲得技術專利400+個。經(jīng)過多年的持續(xù)投入，京東大數(shù)據(jù)已成為企業(yè)大數(shù)據(jù)的領跑者。目前已擁有集群規(guī)模40000+服務器，單集群規(guī)模達到7000+臺，數(shù)據(jù)規(guī)模800PB+，日增數(shù)據(jù)1P+，日運行JOB數(shù)100萬+，業(yè)務表900萬+張每。日的離線數(shù)據(jù)日處理30PB+，實時計算每天消費的行數(shù)近萬億條。圖1：京東大數(shù)據(jù)發(fā)展歷程~8~京東大數(shù)據(jù)技術白皮書京東大數(shù)據(jù)建設了全生態(tài)核心產(chǎn)品體系，是京東大數(shù)據(jù)業(yè)務的基礎服務平臺，為京東全業(yè)務生態(tài)提供一站式、自助式的大數(shù)據(jù)處理全流程解決方案。涵蓋數(shù)據(jù)采集、存儲、加工、分析、可視化、機器學習等專業(yè)化產(chǎn)品和服務，在保障數(shù)據(jù)安全的前提下，提供更可靠、高性能的服務，大幅降低大數(shù)據(jù)使用門檻，幫助京東大數(shù)據(jù)業(yè)務快速落地，助力京東實踐以數(shù)據(jù)為驅動的業(yè)務變革與發(fā)展。~9~京東大數(shù)據(jù)技術白皮書2京東大數(shù)據(jù)的技術體系京東大數(shù)據(jù)平臺構建了完整的技術體系，通過一系列的技術方法實現(xiàn)了更可靠、高可用、具有京東自身特色的平臺環(huán)境。如圖2所示，平臺覆蓋Hadoop、Kubernetes、Spark、Hive、Alluxio、Presto、Hbase、Storm、Flink、Kafka等技術全棧，滿足各類應用場景對數(shù)據(jù)平臺的要求。圖2：京東大數(shù)據(jù)平臺技術架構2.1數(shù)據(jù)采集和預處理數(shù)據(jù)采集是大數(shù)據(jù)的基石。京東包含了電商所涉及的營銷、交易、倉儲、配送、售后等環(huán)節(jié)，每個環(huán)節(jié)都會產(chǎn)生大量的業(yè)務數(shù)據(jù)，同時線上的業(yè)務日志系統(tǒng)和消息系統(tǒng)也會產(chǎn)生海量的數(shù)據(jù)。為了將上述結構化和非結構化數(shù)據(jù)進行采集，以便后續(xù)被數(shù)據(jù)應~10~京東大數(shù)據(jù)技術白皮書用類系統(tǒng)所使用，京東搭建了一套標準化的數(shù)據(jù)采集系統(tǒng)——數(shù)據(jù)直通車。數(shù)據(jù)直通車為京東線上數(shù)據(jù)接入京東數(shù)據(jù)倉庫提供了一套完整解決方案，為后續(xù)的查詢、分發(fā)、計算和分析提供數(shù)據(jù)基礎。直通車提供豐富多樣、簡單易用的數(shù)據(jù)采集功能，可滿足離線計算、實時計算、集成分發(fā)等多種需求，并進行全程狀態(tài)監(jiān)控。根據(jù)不同業(yè)務場景對于數(shù)據(jù)時效性的不同要求，直通車支持離線數(shù)據(jù)采集和實時數(shù)據(jù)采集兩種數(shù)據(jù)采集方式。離線數(shù)據(jù)采集主要支持的數(shù)據(jù)類型為：MySQL、SQLServer、Oracle、MongoDB、HBase、ElasticSearch、離線文件；實時數(shù)據(jù)采集主要支持的數(shù)據(jù)類型為：MySQL、日志、HTTPAPI、JMQ等，并支持API接口實現(xiàn)實時數(shù)據(jù)上報。離線采集每天在零點后抽取前一天增量的數(shù)據(jù)（T+1），然后將T+1的數(shù)據(jù)與已有的全量數(shù)據(jù)合并形成新的全量數(shù)據(jù)，并將數(shù)據(jù)儲存到目標表對應的分區(qū)中。圖3展現(xiàn)了離線數(shù)據(jù)采集的完整架構：~11~京東大數(shù)據(jù)技術白皮書圖3：離線數(shù)據(jù)采集架構數(shù)據(jù)直通車同樣為實時數(shù)據(jù)采集提供了一套標準化的解決方案，實時數(shù)據(jù)采集目前支持MySQL、SQLServer、Oracle、JMQ、日志等多種數(shù)據(jù)源類型。對于MySQL數(shù)據(jù)庫，系統(tǒng)參照數(shù)據(jù)庫的主從復制模式，通過把關系型數(shù)據(jù)庫的Binlog日志實時抓取并解析發(fā)送到實時數(shù)據(jù)總線（JDQ）內(nèi)。實時采集按照數(shù)據(jù)庫實例粒度抓取MySQL實例上的所有Binlog，在程序內(nèi)部進行Binlog的實時解析并過濾出所需要的庫表，再以表粒度發(fā)送到不同的Topic上，方便下游用戶進行業(yè)務表粒度的實時處理。JMQ是京東內(nèi)部線上系統(tǒng)的消息中間件服務，很多業(yè)務數(shù)據(jù)在落數(shù)據(jù)庫之前都會經(jīng)過JMQ系統(tǒng)在不同的業(yè)務系統(tǒng)之間進行傳遞。數(shù)據(jù)直通車可以把JMQ內(nèi)的線上系統(tǒng)消息實時地同步到實時數(shù)據(jù)總線（JDQ）內(nèi)，再由數(shù)據(jù)消費者按需處理，極大地提~12~京東大數(shù)據(jù)技術白皮書高了數(shù)據(jù)處理系統(tǒng)的服務能力。京東內(nèi)部所有系統(tǒng)的實時數(shù)據(jù)都會通過數(shù)據(jù)直通車實時采集到JDQ系統(tǒng)，統(tǒng)一由JDQ對下游業(yè)務需求提供實時數(shù)據(jù)消費服務。該方案幫助業(yè)務用戶在技術層面屏蔽了實時數(shù)據(jù)采集的復雜度，并使得系統(tǒng)能夠提供穩(wěn)定的服務能力。2.2流量數(shù)據(jù)采集目前京東擁有豐富的入口平臺，包括PC上看到的網(wǎng)站，無線客戶端上訪問的H5頁面，移動端應用，微信手Q內(nèi)的購物入口，京東自主研發(fā)或合作的智能設備，微信生態(tài)下的小程序，以及通過開普勒開放賦能給其他合作的APP等。多樣的數(shù)據(jù)展示形式使得不同的訪問入口每天都有大量的用戶訪問，流量數(shù)據(jù)采集成為了京東大數(shù)據(jù)的一個重要環(huán)節(jié)。由于入口平臺實現(xiàn)原理不同，數(shù)據(jù)采集的訴求也不同，包括針對不同的事件，不同的場景有著特定的采集訴求，等以下我們將開始介紹在京東流量數(shù)據(jù)采集的相關技術。2.2.1瀏覽器頁面的采集采集流程瀏覽器的日志采集，主要包含兩大類日志：頁面日志、點擊及自定義日志，其中頁面日志采集主要是指瀏覽器中頁面被加載時的日志，而點擊及自定義日志則是相關行為被觸發(fā)后產(chǎn)生的日~13~京東大數(shù)據(jù)技術白皮書志，頁面日志采集的流程如圖4所示。圖4：頁面日志采集流程頁面日志采集主要包含以下幾個環(huán)節(jié)：（1）日志采集。網(wǎng)站的頁面在上線前，會在頁面內(nèi)植入一段JS的采集腳本，當用戶在訪問網(wǎng)站的頁面時，瀏覽器會進行加載、解析并執(zhí)行JS腳本，JS腳本在執(zhí)行過程中會收集當前頁面的一些信息、瀏覽器環(huán)境的相關信息、用戶訪問上下文的信息（例如第幾次訪問網(wǎng)站，當前訪問頁面的上一頁面信息等等）以及業(yè)務特性的相關數(shù)據(jù)。（2）日志上報。JS腳本執(zhí)行在執(zhí)行完畢后，會將所有收集到的信息拼裝到一個請求內(nèi)，通過日志請求將數(shù)據(jù)發(fā)送到日志服務器。一般情況下，在JS執(zhí)行完成后就會立即向日志服務器發(fā)送。（3）日志接收。日志接收服務器在接收到客戶端發(fā)送來的~14~京東大數(shù)據(jù)技術白皮書日志請求后，會向瀏覽器返回一個請求成功的響應。日志服務器在接收到上報的日志后，還會在服務器上執(zhí)行業(yè)務定制的特殊處理，對日志進行過濾篩選，然后再將日志存儲在本地磁盤或者發(fā)送至實時平臺中，供下游使用。（4）日志存儲。目前采集到的日志通過兩種方式進行存儲：離線和實時。其中離線主要指服務器在接收到日志請求后，會將請求進行簡單處理后落地到本地的磁盤中，然后通過日志抽取的方式將本地的日志及時抽取到相應的數(shù)據(jù)倉庫中，實時則是將請求的消息體實時地分發(fā)到相應的實時處理平臺中進行緩存，下游則根據(jù)該緩存的數(shù)據(jù)進行后續(xù)的應用。（5）日志解析。下游業(yè)務在拿到原始日志后，結合自己的業(yè)務需求對數(shù)據(jù)進行過濾篩選，同時結合統(tǒng)計分析的需求對數(shù)據(jù)進行加工處理。日志經(jīng)過了以上的幾個步驟后，我們就完成了用戶的流量數(shù)據(jù)收集。頁面日志網(wǎng)頁頁面是網(wǎng)站最基本的載體，通過頁面的形式將希望展示的內(nèi)容呈現(xiàn)給用戶。為了更好地了解頁面的訪問情況，就需要我們采集頁面的訪問日志，有了頁面日志后，我們可以統(tǒng)計分析頁~15~京東大數(shù)據(jù)技術白皮書面的瀏覽量（pv）、頁面的訪客數(shù)（uv）、頁面的加載時長、頁面的停留時長等情況，也可以進行上下游的分析，訪問用戶的分析，為營銷策略調(diào)整提供數(shù)據(jù)支撐。頁面日志主要是在用戶訪問頁面的時候進行采集的，目前主要采集了頁面的基本信息、頁面上下文、頁面業(yè)務信息、頁面的其他基本信息。點擊及自定義日志點擊及自定義日志，主要用于收集用戶在網(wǎng)站中除瀏覽以外的日志，主要包括交互日志、曝光日志、自定義日志等。對于交互日志，例如用戶通過鼠標的相關操作，移動、點擊鼠標等操作與頁面發(fā)生交互，頁面會根據(jù)交互行為得到相應的結果，在用戶觸發(fā)這些交互行為時，會觸發(fā)頁面采集的腳本，從而將該部分交互日志采集到。曝光日志是則根據(jù)用戶訪問頁面后，頁面自發(fā)展示的一些其他內(nèi)容形式，例如彈窗，輪播圖等等形式。為了看到曝光之后用戶對該內(nèi)容的轉化效果，就需要知道目前曝光的具體情況，例如在什么時間、曝光給了那些用戶等等。自定義日志則是根據(jù)業(yè)務特性定制的一些特殊日志，例如采集頁面停留的位置，用戶在頁面中的訪問路徑等等。點擊及自定義日志的采集方法主要為用戶特定標記的信息采集，即在網(wǎng)頁上預設采集腳本，當該網(wǎng)頁的某個位置被點擊或自定義的行為被用戶觸發(fā)了，則會產(chǎn)生相應日志并上報給日志服~16~京東大數(shù)據(jù)技術白皮書務器。隨著觸發(fā)條件被同時采集的還包括用戶的基本信息、頁面的基本信息、瀏覽器的基本信息，以及訪問歷史相關的信息等。點擊及自定義日志的采集，更好地還原了用戶在網(wǎng)站頁面中的訪問情況。有時為了更好地記錄用戶的訪問行為，需要使用相應的標識用來做各種場景的區(qū)分，同時在采集代碼植入時就標記下來，這樣在用戶的行為發(fā)生時，相應的日志就能夠采集到更完善的信息，為我們后續(xù)的數(shù)據(jù)統(tǒng)計分析及業(yè)務應用提供了幫助。2.2.2移動設備日志采集隨著用戶對移動設備的依賴越來越重，用戶的訪問也逐步向移動端遷移，移動端的數(shù)據(jù)采集也越來越重要。目前移動設備基本以APP應用的方式進行對外應用，針對APP應用的數(shù)據(jù)采集，京東提供了自主研發(fā)的SDK工具。該SDK可以收集用戶在APP的各種事件行為數(shù)據(jù)，收集APP的性能日志，也支持研發(fā)采集一些自定義狀態(tài)，自定義事件等場景的數(shù)據(jù)。SDK被預置在APP應用內(nèi)，用戶在使用APP的過程中，如果觸發(fā)了預先設計的場景，將會觸發(fā)SDK的采集方法，進而生成相應的用戶行為日志，并收集到APP應用內(nèi)，并在合適的時機下上報的日志接收服務器。頁面標識網(wǎng)站頁面在瀏覽器內(nèi)訪問時，會有相應的頁面鏈接，而用戶~17~京東大數(shù)據(jù)技術白皮書在移動設備上訪問時，由于移動端的特殊性，頁面都是以接口的形式展示，但接口不直觀，數(shù)據(jù)人員無法直接訪問展示，直接判定該頁面具體信息，因此需要針對頁面接口進行重新標識。京東提供了相應的管理界面，可以備注具體接口對應的別名信息，接口描述信息，業(yè)務可以快速地查閱和使用。頁面事件用戶在移動設備上留下各種事件行為，事件行為都是由后臺實現(xiàn)的一些通用接口方法來實現(xiàn)，為了標識這些事件，并且以更簡單易懂的信息來標識，我們提供了頁面事件管理的功能，通過事件管理來標識具體的行為事件。研發(fā)通過埋點開發(fā)，將這部分事件行為植入到對應的接口中，再通過SDK進行采集上報，就可以快速地標識出用戶的事件數(shù)據(jù)。特殊場景電商行業(yè)包含了兩大特殊的業(yè)務場景：引流、跟單。引流：引流主要指的是廣告渠道的引流效果跟蹤，業(yè)務在站外投放廣告，用戶通過點擊廣告坑位進入網(wǎng)站，然后在網(wǎng)站中進行后續(xù)的訪問，為了跟進各個廣告位的流量進入及訂單轉化效果。京東目前對站外廣告渠道進行打標，在用戶通過點擊廣告位跳轉到京東后，來源的鏈接上會有相應的廣告參數(shù)，再借助業(yè)務制定的廣告覆蓋規(guī)則更新廣告渠道信息，而這部分廣告渠道信息將會~18~京東大數(shù)據(jù)技術白皮書保持在后續(xù)訪問的所有頁面內(nèi)，通過頁面的廣告渠道信息就可以統(tǒng)計分析出各個廣告渠道的引流效果。跟單：跟單主要指的是訂單來源的跟蹤，跟單效果包含兩大類，一個是站外的訂單效果跟蹤，一個是站內(nèi)的訂單效果跟蹤。其中站外跟單效果分析，由于頁面中包含了廣告渠道的信息，因此可以通過頁面中包含廣告參數(shù)信息來統(tǒng)計分析，站內(nèi)活動或者坑位的引入效果沒有標識，我們設定了相應的跟單邏輯，通過對應的跟單邏輯可以跟蹤各個坑位的訂單引入效果。設備標識目前移動設備可以通過MEID，IMEI，IMSI，MAC，以及蘋果的UDID信息來識別，但是隨著用戶的自我保護意識加強，蘋果系統(tǒng)禁用設備標識，Android新系統(tǒng)也對設備信息做了權限控制，用戶的基本設備信息獲取愈發(fā)困難，想要進行設備標識成為了一個需要攻克的難題。為了更好地分析用戶，識別一個用戶的所有訪問記錄，將用戶的畫像信息描繪得更完善，就需要一個設備唯一標識。京東通過移動設備相關的硬件信息，并結合一定的歷史數(shù)據(jù)及算法，融合出自己的唯一標識JDID，通過該標識唯一標識一個設備。H5與APP原生頁我們在訪問一個APP設備時，通常會包含兩種頁面形式，~19~京東大數(shù)據(jù)技術白皮書一種是APP原生頁，一種是H5頁面，其中APP原生頁的數(shù)據(jù)采集通過SDK的方式來采集，H5頁面則是通過頁面中的JS來進行采集，由于是在同一個APP內(nèi)訪問，業(yè)務人員通常希望將APP內(nèi)的H5的數(shù)據(jù)算作APP的一部分，而由于采集方式的不同，數(shù)據(jù)需要進行統(tǒng)一，同時也需要相應的交互處理，即H5頁面可以標識出來具體是在哪個APP應用內(nèi)訪問帶來的。日志采集控制用戶在移動設備上訪問后，每個操作都會產(chǎn)生一個操作日志，但并不是每生成一條日志就實時上報至服務器，而是在產(chǎn)生日志后，先暫存在客戶端本地，再結合著相應的上報控制策略進行數(shù)據(jù)上報。其中上報策略主要指根據(jù)日志的業(yè)務特性，數(shù)據(jù)的時效性，用戶的網(wǎng)絡特性等等信息設定不同的上報策略，有些日志會因為其數(shù)據(jù)時效性的要求進行實時數(shù)據(jù)上報，而有些日志則會在用戶啟動應用，或者間隔一段時間后將日志上報上來。2.2.3客戶端與服務器日志采集除了瀏覽器和移動設備外，用戶可能有自己的客戶端或者服務端的日志需要進行采集，京東提供了相應的數(shù)據(jù)采集方案。其中客戶端也主要以服務器端方式進行日志采集，通過相應的接口調(diào)用，在后臺組織好相應的日志形式，然后向日志接收服務器發(fā)送日志請求。日志接收服務器則根據(jù)約定的協(xié)議判定該日志是否~20~京東大數(shù)據(jù)技術白皮書為合法日志，最終將業(yè)務日志落地到相應的服務器上。2.2.4采集的難點與挑戰(zhàn)業(yè)務特性在數(shù)據(jù)采集過程中遇到的一個難點就是業(yè)務特性信息的收集，不同的業(yè)務場景需要收集不同的信息，但又不能每個業(yè)務場景都進行特殊開發(fā)，因此就需要設計一種日志數(shù)據(jù)采集解決方案，可以針對特定的業(yè)務場景，制定通用的數(shù)據(jù)采集標識，研發(fā)人員在進行頁面埋點時，依據(jù)標準的數(shù)據(jù)采集標識規(guī)則進行埋點，從而收集業(yè)務的詳細信息。例如電商行業(yè)中有商品詳情頁、搜索頁、店鋪頁、下單頁等特殊分類頁面，而這些頁面則需要分別采集具體的商品編號、搜索的關鍵字、店鋪編號、訂單對應的編號信息。該部分信息需要多方達成一致，確保產(chǎn)品、埋點研發(fā)、模型開發(fā)人員、數(shù)據(jù)分析人員對其有著相同的認識，以保證采集到的數(shù)據(jù)可以正常的解析處理，供分析人員進行數(shù)據(jù)統(tǒng)計分析，利用數(shù)據(jù)采集標識即可做到這一點。全域用戶標識目前京東存在的入口很多，包括PC端的網(wǎng)站，移動端的網(wǎng)頁，移動應用，包括微信手Q，微信小程序等，同時京東還有很多的垂直業(yè)務，例如京東金融，京東全球購等等，而用戶在不同的入口都有著不同的標識方式，而如果用戶在未登錄的情況下，~21~京東大數(shù)據(jù)技術白皮書如何將用戶在全域下識別成同一個用戶成為了一個重要課題。京東依據(jù)各入口的用戶標識方式，結合用戶之前的使用記錄，用戶偏好等等信息，再結合自用的算法邏輯，將全域的信息進行打通，形成全域的用戶唯一標識。通過全域的用戶唯一標識，我們就可以知道一個用戶在不同網(wǎng)站，不同設備上的訪問習慣，方便營銷人員對用戶進行更精準的營銷活動。2.3數(shù)據(jù)存儲體系2.3.1HDFS存儲JDHDFS是京東基于HDFS自研的大數(shù)據(jù)分布式存儲平臺,采用分布式存儲技術，滿足大數(shù)據(jù)高效可靠的存儲需求，提供較高的持久性、較高的吞吐量和較低的延遲速度,具備高可用性和高可靠性的特點，容易擴展,并支持水平擴展至百PB級存儲容量,同時擁有較高的硬件故障容忍能力,提供全面的安全性和多樣化的權限功能。相對于開源版本的HDFS，，JDHDFS主要改進的技術點如下：（1）基于路由的Federation方案(Router-BasedFederation)隨著集群規(guī)模的增長，Namenode存儲成為集群性能的關鍵瓶頸。我們參考社區(qū)版本設計文檔,研發(fā)功能模塊RBF（Router-BasedFederation基于路由的Federation方案）,支持動態(tài)映射、嵌套映射等功能，可以解決hadoop集群無限橫向擴展的規(guī)模問~22~京東大數(shù)據(jù)技術白皮書題。（2）數(shù)據(jù)生命周期管理(DataLifecycleManagement)組件基于數(shù)據(jù)生命周期管理的策略，該組件定期調(diào)度進行過期Job日志聚合目錄app-logs、中間結果文件、Cgroups文件的清理以及固定周期小文件的整理合并。（3）基于資源利用率的智能選塊改進后的Namenode節(jié)點可以實時感知集群所有Datanode的繁忙狀態(tài)，根據(jù)CPU、內(nèi)存、磁盤、網(wǎng)絡的繁忙程度進行副本的位置選擇，規(guī)避繁忙狀態(tài)的Datanode節(jié)點，可以對整個集群的負載實時平衡。（4）跨集群容災集群往往不在同一個數(shù)據(jù)中心，甚至是跨地域的。集群間網(wǎng)絡延遲較高，交換數(shù)據(jù)成本昂貴。原有執(zhí)行同步的方式會造成數(shù)據(jù)延遲。我們基于集群數(shù)據(jù)同步方式代替distcp,同時做到數(shù)據(jù)低延遲訪問,支持雙主訪問,降低額外物理資源冗余。京東分布式存儲采用將元數(shù)據(jù)集群與數(shù)據(jù)集群分離并可實現(xiàn)獨立擴展，用戶既可以通過擴展元數(shù)據(jù)集群獲得更多文件管理的能力，又可通過擴展數(shù)據(jù)存儲集群獲得更大的聚合帶寬與存儲容量。靈活、無縫、平滑的擴展方可式以為用戶高效的計算環(huán)境提供堅實的數(shù)據(jù)保障。圖5展示JDHDFS的技術架構。~23~京東大數(shù)據(jù)技術白皮書圖5：JDHDFS技術架構數(shù)據(jù)高可靠和平臺高可用平臺可用性是最重要的指標之一，需要保證在機器發(fā)生故障時，系統(tǒng)可用性不受影響。我們使用多副本策略,副本分布在不同的機器,機器故障引起某些副本失效時，其它副本仍然能提供服務。平臺允許對虛擬存儲池中不同的目錄設置不同的副本數(shù)，可手動設置1-4個文件副本,可保證數(shù)據(jù)在多塊磁盤甚至單臺服務器損壞的情況下存儲系統(tǒng)的服務正常運轉。為了保證任何一臺存儲服務器失效或者是任何一塊硬盤失效都不會影響數(shù)據(jù)的可靠性和一致性，使用pipeline機制保證數(shù)據(jù)寫入順序，所有的數(shù)據(jù)副本以及數(shù)據(jù)校驗有嚴格寫入順序，如~24~京東大數(shù)據(jù)技術白皮書圖6所示。當正在進行數(shù)據(jù)寫入的磁盤和存儲服務器發(fā)生故障時，元數(shù)據(jù)服務器會為此數(shù)據(jù)對象分配新的空間，以繼續(xù)進行數(shù)據(jù)寫入，而之前在失效磁盤上寫入的數(shù)據(jù)則會通過另一份數(shù)據(jù)副本恢復到相應的磁盤和存儲服務器上。圖6：JDHDFS存儲架構圖集群水平擴展能力存儲平臺中的元數(shù)據(jù)服務器和存儲節(jié)點是擁有橫向水平擴展能力。存儲節(jié)點擴展是存儲節(jié)點數(shù)量的擴展，存儲節(jié)點擴展帶來容量上的增長。擴展過程中無需中斷存儲系統(tǒng)上應用的運行，擴展的容量即插即用。而且隨著存儲服務器數(shù)量的增多，整套存儲平臺的流量也會線性增長，成為核心存儲集群之一。元數(shù)據(jù)服務器的擴展帶來的是文件數(shù)量存儲能力的增長。如圖7所示，整個擴展過程對整個應用平臺完全透明，擴展的元數(shù)據(jù)服務器即刻能夠提供服務，前端應用無需進行任何配置。隨著元數(shù)據(jù)服務器數(shù)量的增多，整套集群存儲系統(tǒng)所提供的元數(shù)據(jù)服務能力也會呈線性增長，能夠管理的文件總個數(shù)也線性增加。~25~京東大數(shù)據(jù)技術白皮書圖7：元數(shù)據(jù)服務器2.3.2HBase存儲JDHBase是一個分布式存儲系統(tǒng)，具有高效的實時讀寫性能?？梢灾С置棵肭f級數(shù)據(jù)記錄寫入和毫秒級的查詢響應，當數(shù)據(jù)量達到PB級別，仍然保持高性能讀寫。目前京東HBase集群規(guī)模5000多臺，支持京東600多個業(yè)務系統(tǒng)，典型業(yè)務有：商城：商品評價、會員PLUS、個性推薦、用戶畫像、POP訂單、商家營銷智能：JIMI機器人、AI圖片、圖像識別、門禁刷臉金融：風控、白條、支付、資管物流：訂單追蹤、物流倉儲、銷量預測監(jiān)控：統(tǒng)一監(jiān)控、服務器監(jiān)控、容器監(jiān)控、大數(shù)據(jù)監(jiān)控、~26~京東大數(shù)據(jù)技術白皮書大屏監(jiān)控JDHBase集群的服務端（如圖8所示）是京東HBase的核心，它保障了HBase集群的性能和穩(wěn)定，并提供了安全認證、主備切換、分組隔離、SQL支持等重要功能。JDHBase的客戶端是京東HBase的重要支撐，所有業(yè)務程序都使用標準客戶端來訪問HBase集群，實現(xiàn)了用戶身份認證、主備切換、實時監(jiān)控等功能。JDHBase服務中心實現(xiàn)了各集群之間的統(tǒng)籌管理，通過它我們可以控制業(yè)務數(shù)據(jù)在多個集群中的流向形成數(shù)據(jù)流向拓撲，方便地進行數(shù)據(jù)的遷移。同時提供對業(yè)務端透明的主從、主主策略的動態(tài)變更。圖8：JDHBase服務架構京東HBase:（1）4+1架構針對京東的業(yè)務場景和使用方式，我們對JDHBase的使用~27~京東大數(shù)據(jù)技術白皮書方式做了很多思考與優(yōu)化。如圖9所示，我們將整個JDHBase平臺邏輯拆分成存儲層、內(nèi)核層、中間件層、用戶層和一個輔助系統(tǒng)。底層部署上我們支持將HDFS和HBase分開部署，同時可以利用容器技術快速擴容和創(chuàng)建新的HBase集群。滿足各種場景的讀寫需求。在HBase內(nèi)核部分我們通過修改源碼讓HBaseRegionServer能夠識別運行的硬件類型并根據(jù)其預設值自適應到最佳性能狀態(tài)，支持多種硬件混合部署集群。在中間件部分我們通過接口服務的方式向外圍系統(tǒng)提供支持，如主備容災、數(shù)據(jù)治理服務、集群分組管理服務、權限管控服務、配額&限速管理服務，多語言支持組件等。在用戶層我們向最終用戶提供多種可選的數(shù)據(jù)加載方式和查詢引擎滿足不同業(yè)務場景和需求。~28~京東大數(shù)據(jù)技術白皮書圖9：JDHbase技術架構（2）多活災備為了滿足業(yè)務對JDHBase讀寫的實時性要求和數(shù)據(jù)安全性的要求，我們自主研發(fā)了一套基于策略的多集群切換機制（圖10）。在集群拓撲上每個集群都會有備份集群來保證跨機房的數(shù)據(jù)備份。從安全維度上我們分別做到了集群級、namespace、表級的支持，可以針對每個級別設置不同的容災切換策略，如手動、自動、強制等。通過這種方式我們可以隨時調(diào)整策略將部分業(yè)務分批、分級切換，如隔離、降級、防雪崩等場景。多集群切換機制的主要工作組件由服務中心、HBasePolicyServer、客戶端三部分構成：端定期會以心跳的方式訪問HBasePolicyServer獲取所操作對象的集群服務信息和切換策略信息，當發(fā)現(xiàn)主集群信息改變之后端會根據(jù)切換策略進入切換流程。PolicyServer是對外提供查詢和修改策略的服務，它所有策略數(shù)據(jù)會存儲在MySQL中，可以通過加節(jié)點的方式動態(tài)擴展形成一個服務集群，避免單點問題。ServiceCenter提供一個界面化的多集群管理服務工具供管理員使用。在極端情況下，如果主集群徹底癱瘓，我們可以通過強制切換的方式把所有業(yè)務快速切換到從集群。同時觸發(fā)主備數(shù)據(jù)同步校驗機制，后臺會自動在主集群狀態(tài)恢復后將校驗主從集群的數(shù)~29~京東大數(shù)據(jù)技術白皮書據(jù)一致性并同步數(shù)據(jù)，保證數(shù)據(jù)安全性。圖10：HBase服務集群（3）多租戶分組隔離HBase默認的使用方式是一個業(yè)務一個集群，資源利用率低，維護成本高。也可以多個業(yè)務共用一個集群，但是會有資源競爭和故障擴散等問題。例如，一個業(yè)務出現(xiàn)異?？赡軙绊懻麄€集群的可用性?；谝陨系脑?，我們引入了HBase2.0的rs分組功能（目前官方仍然是beta版）并進行了改進完善，實現(xiàn)了將HBase集群動態(tài)切分成多個分組，每個分組中有多臺物理服務器（圖11）。這樣既能將業(yè)務進行物理隔離防止資源競爭和故障擴散，還能在618和11.11大促時期動態(tài)調(diào)整集群資源，提升硬件資源利用率。~30~京東大數(shù)據(jù)技術白皮書圖11：Hbase多租戶隔離（4）SQL查詢原生的HBase只提供key-value查詢和范圍掃描。我們引入了開源的phoenix組件，并進行了安全認證、性能和穩(wěn)定性提升等工作，可以支持標準sql查詢，例如創(chuàng)建二級索引、多表join查詢、sql子查詢、聚合查詢、創(chuàng)建分桶表、分頁查詢等功能，如圖12所示。這使得HBase功能更加豐富，不僅支持實時查詢，還能做實時統(tǒng)計分析，適應更復雜的應用場景。~31~京東大數(shù)據(jù)技術白皮書圖12：支持SQL查詢除以上外，我們還做了其他重要優(yōu)化改進，如使用G1垃圾回收器提升JVM性能、支持在線不停機跨版本數(shù)據(jù)遷移等功能，將主備replication同步速度提升到分鐘級別，archive歸檔清理性能提升10%以上。隨著容器技術的成熟，我們正在嘗試Hbase的容器化部署，以便實現(xiàn)更好的資源隔離并提升資源使用率。由于承載的數(shù)據(jù)量越來越大，Hbase提供的均衡策略已經(jīng)不能滿足業(yè)務需求，我們也在著手進行balance均衡策略的調(diào)整，并使用NettyRpcClient來改造PRC客戶端性能，提升數(shù)據(jù)寫入的速度。在集群硬件方面，我們部署了SAS和SSD磁盤混合方案，從目前的壓測效果看比較好，將來會逐步上線。~32~京東大數(shù)據(jù)技術白皮書2.3.3冷熱數(shù)據(jù)管理隨著數(shù)據(jù)量的不斷增長積累，數(shù)據(jù)也會呈現(xiàn)出訪問熱度不同的明顯差異。我們將數(shù)據(jù)訪問頻率高的數(shù)據(jù)稱為“熱”數(shù)據(jù)，訪問頻率低的數(shù)據(jù)稱為“冷”數(shù)據(jù)。如果無論數(shù)據(jù)冷熱情況，都采用同樣的存儲策略，是對集群資源的一種浪費。因此，需要根據(jù)數(shù)據(jù)冷熱程度對HDFS存儲系統(tǒng)進行優(yōu)化。京東大數(shù)據(jù)針對冷熱數(shù)據(jù)設計了較完整的機制，主要包括：冷數(shù)據(jù)的規(guī)則配置管理員可配置冷數(shù)據(jù)的掃描范圍，對不同集群、ns、用戶可靈活配置不同的掃描路徑，歸檔周期以及歸檔路徑。同時為了配合業(yè)務使用，可以允許業(yè)務用戶根據(jù)業(yè)務需要對部分數(shù)據(jù)設置白名單進行保護，避免被冷備份。冷數(shù)據(jù)的掃描和備份利用配置表對HDFS存儲數(shù)據(jù)一次性進行正則匹配，獲取想要的冷數(shù)據(jù)列表。被掃描出的冷數(shù)據(jù)被遷移到冷數(shù)據(jù)集群，進行降副本操作和隔離操作，并釋放原有集群的存儲資源。冷數(shù)據(jù)的恢復和刪除如有業(yè)務需要對冷數(shù)據(jù)進行恢復，可申請恢復冷數(shù)據(jù)。經(jīng)過批復后數(shù)據(jù)將很快從冷集群恢復至正常環(huán)境。若冷集群歸檔后一定時間內(nèi)無恢復申請，將刪除冷數(shù)據(jù)并釋放資源到大集群。冷數(shù)據(jù)的統(tǒng)計分析報告大數(shù)據(jù)平臺同時提供從不同角度對冷數(shù)據(jù)歸檔信息進行統(tǒng)~33~京東大數(shù)據(jù)技術白皮書計分析并展示，更直觀地反映冷數(shù)據(jù)當前的歸檔情況，方便用戶查看。2.4離線計算環(huán)境大數(shù)據(jù)離線計算為多種應用場景提供基礎計算功能，其特點為：數(shù)據(jù)量巨大且保存時間長；在大量數(shù)據(jù)上進行復雜的批量運算，能夠方便地查詢批量計算的結果；數(shù)據(jù)在計算之前已經(jīng)完全到位，不會發(fā)生變化。京東大數(shù)據(jù)支持Hiv、Pig、SparkSQL、Presto、MapReduce等計算工具，并支持Alluxio的存儲架構，形成了離線計算引擎，如圖13所示。圖13：離線計算架構JDHive計算引擎服務~34~京東大數(shù)據(jù)技術白皮書JDHive是基于HIVE社區(qū)版本深度定制的大數(shù)據(jù)查詢引擎,它是目前業(yè)內(nèi)能夠支撐GB/TB/PB級數(shù)據(jù)倉庫的通用解決方案之一,支持將sql語句轉換為MapReduce任務,能夠快速處理海量數(shù)據(jù)計算，有效降低分布式計算模型的使用成本。JDHive為用戶提供基于社區(qū)版的所有功能，同時進一步推出一系列高級特性解決不同業(yè)務場景的需求,包括:元數(shù)據(jù)管理、審計日志管理、讀寫IO管理、UDF統(tǒng)一管理等功能。針對服務性能優(yōu)化,我們堅持不斷試錯，不斷優(yōu)化，不斷打磨的原則,持續(xù)推動著JDHive的進化。如今京東大數(shù)據(jù)百分八十的業(yè)務都在使用JDHive提供的服務支持。JDSpark計算引擎服務JDSpark是京東大數(shù)據(jù)平臺對外開放的核心計算引擎之一,旨在為高性能、迭代計算、時效性要求極高的場景服務,同時針對部分具有研發(fā)能力較高的深度用戶提供SDK開發(fā)功能。隨著京東業(yè)務的飛速增長,很多業(yè)務場景已經(jīng)無法接受基于磁盤批處理的MapReduce計算服務,更傾向使用內(nèi)存進行快速迭代計算,希望整體提升數(shù)據(jù)結果的時效性,我們的目標是將JDSpark打造成基于內(nèi)存與SSD作為存儲迭代計算的框架，通過技術手段提升任務的時效性。ADHOC查詢服務我們針對ADHOC業(yè)務場景,提供實時查詢與預計算的兩種方式的查詢場景,分別使用Presto、Kylin計算引擎為用戶提供支~35~京東大數(shù)據(jù)技術白皮書持，基于YARN整合多種計算框架,優(yōu)化Presto的監(jiān)控和報警機制、PrestoCache的開發(fā)、Orc優(yōu)化、Master的Docker化，提供自愈、報警、限流等功能。圖14和圖15展示了基于Presto提供的ADHoc查詢服務的技術架構。圖14：PrestoOnYarn計算架構我們同時支撐許多線上業(yè)務系統(tǒng)的查詢服務，基于Yarn整合了Alluxio，提供Presto+Alluxio的組合，并通過增加Alluxio常用命令、優(yōu)化LRU置換內(nèi)存、支持hdfs同步校驗（一致性）等將多種工具融合，提供靈活、高效的數(shù)據(jù)計算工具和數(shù)據(jù)查詢工~36~京東大數(shù)據(jù)技術白皮書具。圖15：Presto高可用架構2.5實時計算環(huán)境盡管傳統(tǒng)數(shù)據(jù)倉庫的T+1（以天為計算周期對數(shù)據(jù)進行批處理）機制一定程度上能滿足數(shù)據(jù)處理的日常需求，但是這種處理方式畢竟具有一定的滯后性，針對時效性要求更高（實時計算）的諸如618、雙11的實時大屏、實時預測、風控預警等諸多場景，T+1的處理方式不免顯得有些力不從心。因此需要一種降低整個數(shù)據(jù)處理鏈路延遲的計算方式來彌補T+1計算的不足。京東大數(shù)據(jù)實時計算平臺（JRC）實現(xiàn)了計算過程的低延遲、~37~京東大數(shù)據(jù)技術白皮書高吞吐、計算結果的可復用和計算任務開發(fā)簡單化的目標。采用復合事件模型構建分布式流數(shù)據(jù)計算框架，功能易擴展、部分容錯、數(shù)據(jù)和狀態(tài)可監(jiān)控。JRC具有處理實時數(shù)據(jù)流的能力，同時將實時計算結果以服務的方式供業(yè)務系統(tǒng)調(diào)用，支撐業(yè)務團隊的個性化需求，JRC平臺可以為智能營銷、個性化推薦等應用提供實時計算數(shù)據(jù)，未來將提供更加智能化的實時計算服務。圖16展示了京東大數(shù)據(jù)實時計算平臺的技術架構。圖16：實時計算平臺京東大數(shù)據(jù)實時計算環(huán)境由三個部分組成：JDQ實時數(shù)據(jù)總線JDQ是京東大數(shù)據(jù)平臺部基于Kafka打造的高吞吐量、低延遲、高可用的分布式生產(chǎn)、訂閱消息系統(tǒng)，是大數(shù)據(jù)平臺的一項~38~京東大數(shù)據(jù)技術白皮書重要服務。針對京東的業(yè)務場景，我們對Kafka進行了一系列的架構改造，支持數(shù)據(jù)讀寫分離，消費切換銜接，跨機房災備，對機房間傳輸進行了流量管控，減少跨機房的流量傳輸，針對數(shù)據(jù)安全，我們對安全認證和權限管理做了針對性的升級。JDQ在經(jīng)歷了多次618和雙十一的考驗后，性能表現(xiàn)非常穩(wěn)定。準實時數(shù)據(jù)倉庫將數(shù)據(jù)倉庫的ETL部分用實時采集技術替代離線抽取技術，將傳統(tǒng)的T+1模式的數(shù)據(jù)倉庫升級為T+0模式，用同一張Hive表同時滿足實時和離線用戶的使用需求，與線上最新數(shù)據(jù)狀態(tài)有不超過5分鐘的延遲，可以查詢每條數(shù)據(jù)的INSERT，UPDATE，DELETE變更軌跡。JRC實時計算平臺京東選擇Storm、SparkStreaming和Flink同時作為實時計算平臺的技術框架，用戶可以根據(jù)自己的情況選擇合適的框架來實現(xiàn)實時計算。Storm作為第一代增量計算的高速事件處理框架，它的毫秒級延遲滿足對延遲要求較高的場景。而SparkStreaming的有狀態(tài)計算、對延要遲求不高以及圖形操作、機器學習、SQL支持等特性恰恰是對Storm的完美補充。Flink的出現(xiàn)可以說是以上框架優(yōu)點的集大成者。Flink支持Storm式的增量迭代和毫秒級延，遲吞吐量比Storm高，并且具有對迭代自動優(yōu)化的功能，支持ExactlyOnce、狀態(tài)管理和窗口統(tǒng)計，在迭代式數(shù)據(jù)處理上，~39~京東大數(shù)據(jù)技術白皮書更是比Spark更突出。在技術層面，實時計算平臺不是對開源技術的照搬。我們汲取社區(qū)開源框架的優(yōu)勢，取長補短，對開源技術進行二次開發(fā)。產(chǎn)品層面，通過支持SQL引擎，提升用戶體驗，提高使用效率，降低用戶的學習成本，讓用戶通過SQL方式體驗實時技術所帶來的魅力。鑒于Flink在技術架構上的天然優(yōu)勢以及批流統(tǒng)一技術上的日趨完善，我們會逐步推動Flink成為未來統(tǒng)一的、通用的大數(shù)據(jù)實時計算引擎。2.6機器學習環(huán)境京東在機器學習平臺已經(jīng)深耕多年。平臺依托于大數(shù)據(jù)底層先進的基礎架構設施，有效地將大數(shù)據(jù)平臺的中計算、存儲、調(diào)度等系統(tǒng)協(xié)同起來。它可以為用戶提供數(shù)據(jù)標注、數(shù)據(jù)清洗、數(shù)據(jù)建模、模型上線等一站式服務。依托這個平臺，用戶可以輕松地在PB級數(shù)據(jù)上快速進行算法的研究和落地。到目前為止，京東大數(shù)據(jù)的機器學習平臺廣泛應用于供應鏈、用戶畫像、無界零售等領域。京東的機器學習平臺由基礎架構層、工具層、任務調(diào)度層、算法層以及API層組成，架構圖如圖17所示。~40~京東大數(shù)據(jù)技術白皮書圖17：機器學習平臺基礎架構層京東的機器學習平臺擁有調(diào)度大規(guī)模異構計算資源的能力。為了滿足不同的機器學習算法的計算需求，基礎架構層能同時支持CPU、GPU、高速存儲設備、高速網(wǎng)絡設備等不同硬件資源調(diào)度。借助虛擬化技術，機器學習平臺可以將同一個硬件設備在不同的任務中進行資源共享，有效地提高了硬件資源的利用率。高性能資源調(diào)度器能幫助不同的數(shù)據(jù)建模工具快速找到合適的計算資源，并且部署分發(fā)計算任務，管理任務狀態(tài)，按照約定的協(xié)議對分布式的任務進行錯誤恢復。工具層工具層給用戶提供了機器學習算法研發(fā)的一站式服務。用戶可以通過離線和實時數(shù)據(jù)處理平臺進行海量數(shù)據(jù)的處理和分析，~41~京東大數(shù)據(jù)技術白皮書從數(shù)據(jù)中找到業(yè)務的價值。我們圍繞著統(tǒng)計學習和深度學習等領域，結合京東的基礎架構，對這些建模工具進行了大量的改進和優(yōu)化，使其充分適應京東的計算環(huán)境，提升其算法的訓練速度和訓練數(shù)據(jù)集的規(guī)模。與此同時，機器學習平臺還提供了超參數(shù)優(yōu)化等功能。依靠這些功能，用戶可以快速在海量數(shù)據(jù)上構建上千億維度的模型。為了進一步降低模型的落地門檻，京東的機器學習平臺還提供了統(tǒng)一的serving平臺。用戶可以在不需要做任何系統(tǒng)開發(fā)的情況下，將算法模型變成穩(wěn)定高效的服務接口。serving平臺除了根據(jù)算法模型的特點進行了大量的硬件層面和軟件層面的性能優(yōu)化之外，還給用戶提供了統(tǒng)一監(jiān)控報警、負載均衡、模型版本管理、多版本A/B測試等功能。用戶還可以借助跨平臺SDK對模型進行壓縮和裁剪，以便應用于移動端及IOT設備之上。任務調(diào)度層隨著近幾年人工智能技術的快速發(fā)展，算法模型精度提升的同時，模型的復雜性也在不斷地增加，用戶往往不能只依賴單一工具或單一任務來達到目標。為了解決這一痛點，京東的機器學習平臺利用任務調(diào)度系統(tǒng)將不同的工具連接到一起，幫助用戶完成復雜的DAG任務和定時任務，降低用戶的使用難度。算法層京東的機器學習平臺內(nèi)置了上百個經(jīng)過優(yōu)化的算法模塊。這些算法模塊覆蓋了視覺、語音、自然語言、統(tǒng)計分析、圖運算、~42~京東大數(shù)據(jù)技術白皮書特征處理等領域。每一個模塊都采用了統(tǒng)一的數(shù)據(jù)接口，同時提供了靈活的參數(shù)供用戶進行調(diào)整。用戶可以通過命令行或者UI交互將不同的算法模塊鏈接到一起來完成一個復雜的機器學習任務。API層京東的機器學習平臺還為用戶提供了豐富的人工智能API服務，如人臉識別、文字識別、評論分析等。用戶甚至不需要進行任何模型開發(fā)就可以直接使用。2.7任務管理和調(diào)度京東大數(shù)據(jù)應用在各個業(yè)務當中，大數(shù)據(jù)平臺上每天運行的數(shù)據(jù)處理任務超過30萬個。這些任務要完成各種復雜的邏輯運算，任務之間有關聯(lián)、有順序、有依賴，要滿足不同條件的調(diào)度。京東分布式調(diào)度平臺很好地解決了這些問題。如圖18所示，調(diào)度架構基本分為以下幾個主要部分：NameNode、TaskNode、Web管理端和日志收集器。~43~京東大數(shù)據(jù)技術白皮書圖18：調(diào)度平臺基礎架構圖NameNode作為控制節(jié)點主要負責將任務執(zhí)行命令發(fā)送給TaskNode，TaskNode會將任務真正執(zhí)行起來，并將日志輸出到日志收集器，將結果返回到NameNode并寫入數(shù)據(jù)庫，最終用戶通過瀏覽器打開Web管理端查看、操作自己的任務。詳細功能如下：NameNodeNameNode是調(diào)度平臺的核心調(diào)度節(jié)點，負責任務實例化、掃描符合執(zhí)行條件的實例、檢查依賴、分配任務執(zhí)行節(jié)點、處理任務執(zhí)行結果、管理TaskNode節(jié)點等核心工作。目前NameNode部分支持Alive-Alive方式的高可用，并可水平擴展。TaskNodeNameNode按照一定的分配策略將任務分配到具體TaskNode后，TaskNode會主動從NameNode領取任務，并根據(jù)任務配置啟動任務執(zhí)行代理器（TaskExec）。代理器會調(diào)起任務進~44~京東大數(shù)據(jù)技術白皮書程執(zhí)行。TaskNode會監(jiān)聽進程執(zhí)行結果并反饋給NameNode，同時接收任務日志輸出流發(fā)送到JDQ。為防止大量任務因為資源不足而執(zhí)行失敗，節(jié)點可設置同時執(zhí)行任務數(shù)（并發(fā)數(shù)）來避免同時執(zhí)行大量任務，另一方面通過cgroup實現(xiàn)節(jié)點級別和任務基本的資源隔離，保護機器和TaskNode進程。（1）節(jié)點級別資源隔離節(jié)點可設置最大可用CPU和內(nèi)存，設置成功之后該節(jié)點上所有執(zhí)行的任務使用的資源總和不會超過配置的值。（2）任務基本資源隔離單個任務可以單獨設置任務要使用的CPU和內(nèi)存。任務執(zhí)行過程中使用的資源不會超過配置的值。Web管理端Web管理端為用戶提供了操作界面。用戶可通過UI便捷地實現(xiàn)創(chuàng)建、修改、終止、重跑、補錄等功能，極大簡化用戶操作。日志收集器日志收集器是一個JRC任務，從JDQ消費任務日志并寫入Hbase供管理端查詢。京東大數(shù)據(jù)分布式調(diào)度平臺的技術特點包括：實例當任務到達預定的執(zhí)行時間時，會根據(jù)任務當時的配置，生成一個任務實例。該實例實際上是當時任務的一個快照。實例化時會將任務的時間參數(shù)、依賴等信息具體化。當任務需要重新執(zhí)~45~京東大數(shù)據(jù)技術白皮書行時，會按照當時的實例來執(zhí)行，保證可重現(xiàn)當時的場景。分配策略目前調(diào)度系統(tǒng)的TaskNode節(jié)點已超過800臺，為了保證能將任務分配到合理的節(jié)點執(zhí)行，調(diào)度系統(tǒng)提供了多種策略，包括輪詢策略、并發(fā)數(shù)策略、機器資源策略等。調(diào)度系統(tǒng)中可以將多個TaskNode節(jié)點合并成一個虛擬節(jié)點，每個虛擬節(jié)點可以單獨配置分配策略。（1）輪詢策略輪詢策略是最簡單的策略，將任務輪流分配給虛擬節(jié)點中的TaskNode節(jié)點。（2）并發(fā)數(shù)策略每個TaskNode節(jié)點可以設置可同時運行的任務數(shù)上限，我們稱為并發(fā)數(shù)。選擇該策略時，會根據(jù)“并發(fā)度=節(jié)點上當前在執(zhí)行任務數(shù)/節(jié)點并發(fā)數(shù)”的結果排序，選擇節(jié)點并發(fā)度小的節(jié)點執(zhí)行任務。（3）機器資源策略TaskNode節(jié)點會將節(jié)點目前機器的CPU和內(nèi)存信息上報到NameNode，選擇該策略時，NameNode會選擇一個CPU和內(nèi)存使用最低的一個TaskNode節(jié)點來執(zhí)行任務?？缰芷谝蕾嚾蝿丈舷掠沃g存在依賴，可以理解成為一個有向無環(huán)圖（DAG圖）。目前調(diào)度平臺可以很靈活地配置任務之間的關系，~46~京東大數(shù)據(jù)技術白皮書比如任務A執(zhí)行成功后才能將任務B調(diào)用起來。任務A、B可以配置為每分鐘、每小時、每天、每周、每年等周期運行。調(diào)度平臺會自動計算任務A的周期執(zhí)行成功后才將B任務調(diào)起。為了更好地理解這個概念，下面我們用個具體的例子進行描述。示例1：A是小時任務，B是天任務。A任務24個周期全部執(zhí)行成功后，B任務才會被執(zhí)行；示例2：A是小時任務，B是天任務。可以指定為檢查A任務5點到12點之間的周期全部執(zhí)行成功后，B任務才會被執(zhí)行；示例3：A任務是天任務，B任務是小時任務。A任務當天（也可以指定為昨天、前天、某一天或某個日期段）執(zhí)行成功后，B任務的24個周期才可以依次被執(zhí)行。示例4：A任務是天任務，B任務是每月運行一次。A任務當月（也可以為上月或指定上月10號到當月10號）周期執(zhí)行成功后，B任務才會被執(zhí)行。諸如此類的場景，在調(diào)度平臺中被稱為跨周期依賴。數(shù)據(jù)依賴調(diào)度平臺還支持檢查某個HDFS目錄是否存在，來做為任務執(zhí)行前的判斷條件。比如某個部門通過自己的業(yè)務系統(tǒng)在HDFS產(chǎn)生了一份數(shù)據(jù)，下游團隊需要使用這份數(shù)據(jù)做離線計算分析，這可以讓業(yè)務系統(tǒng)把業(yè)務數(shù)據(jù)寫到HDFS某目錄，同時再生成一個ok或success（名字可以隨意指定）標識文件，文件可允許為空。然后在調(diào)度平臺里設置檢查HDFS對應路徑的ok或success~47~京東大數(shù)據(jù)技術白皮書文件，如果此文件不存在調(diào)度平臺會持續(xù)檢查，一旦發(fā)現(xiàn)此文件生成，下游任務就會馬上啟動執(zhí)行。任務圖形化展現(xiàn)技術如何展示上千個任務的關系以及對任務進行配置是個難點。調(diào)度系統(tǒng)利用graph和動態(tài)圖形位置算法可支持上千個任務在界面中同時展現(xiàn)。主要包括：1、可以在圖中對任務進行編輯、禁用、啟用的各種操作；2、圖形化配置技術可以方便直觀地看到整個任務的依賴情況；3、可以對整體任務依賴圖進行放大、縮小、導出圖片等功能。用戶可以在圖形界面完成對于任務的所有屬性和依賴關系的配置。數(shù)據(jù)模板數(shù)據(jù)模板是指調(diào)度系統(tǒng)將相關的抽取數(shù)據(jù)和推送數(shù)據(jù)的邏輯固化到任務模板當中，通過執(zhí)行固定的腳本，只需要通過簡單的源數(shù)據(jù)信息和目標數(shù)據(jù)信息的配置，就能實現(xiàn)不同數(shù)據(jù)庫之間數(shù)據(jù)抽取和推送。調(diào)度系統(tǒng)會動態(tài)獲取抽數(shù)的參數(shù)，執(zhí)行抽取和推送數(shù)據(jù)的邏輯。腳本倉庫和任務動態(tài)執(zhí)行技術調(diào)度系統(tǒng)為python、shell和zip包等腳本提供包括存儲、版本更新、下載腳本的倉庫服務。倉庫采用多hbase集群保存腳本信息，可以保證當集群出現(xiàn)問題的時候可以動態(tài)地切換到另外一個集群當中，保證腳本的安全性和可用性。任務執(zhí)行的時候調(diào)度會動態(tài)地下載和更新腳本信息，保證每~48~京東大數(shù)據(jù)技術白皮書個任務執(zhí)行的腳本都是唯一的，并且是最新的，可有效提高任務的準確率和安全性。京東大數(shù)據(jù)的任務調(diào)度和管理已基于Kubernetes進行了升級和改造。升級后可由Kubernetes實現(xiàn)資源的統(tǒng)一管理和分配，提高了服務器的利用率，并實現(xiàn)適應業(yè)務需求變化的彈性，能夠實現(xiàn)不同業(yè)務間的資源混用，進一步提高跨業(yè)務的服務器利用率。容器包含了運行環(huán)境和可執(zhí)行程序，可以跨平臺和主機使用，使用鏡像管理任務代理，能夠實現(xiàn)標準化應用發(fā)布，方便持續(xù)集成和測試。2.8資源監(jiān)控和運維管理萬臺規(guī)模的集群，資源監(jiān)控和運維體系變得非常重要，京東大數(shù)據(jù)平臺實現(xiàn)了對集群資源的全方位監(jiān)控，并研發(fā)了自動部署系統(tǒng)和相關的集群運維規(guī)范，保障了集群的可靠運行。2.8.1統(tǒng)一監(jiān)控監(jiān)控系統(tǒng)是大數(shù)據(jù)平臺的一個重要組成部分。它采集被監(jiān)控的物理機器和其上運行的軟件系統(tǒng)，分析時間序列數(shù)據(jù)，產(chǎn)生報警信號并通知相關系統(tǒng)負責人。京東大數(shù)據(jù)平臺監(jiān)控實現(xiàn)了對調(diào)度系統(tǒng)、集群任務管理、集群存儲資源、機房網(wǎng)絡專線、全集群服務器資源的全方位多維度統(tǒng)一監(jiān)控體系，并且實現(xiàn)了電話、短信、郵件以及其它IM的通~49~京東大數(shù)據(jù)技術白皮書知模式。統(tǒng)一監(jiān)控系統(tǒng)綜合考慮功能和穩(wěn)定性，選擇了Prometheus。該系統(tǒng)是一個開源的監(jiān)控報警工具集，我們通過對其進行架構和功能上的優(yōu)化，完成平臺全方位的監(jiān)控和告警功能。統(tǒng)一監(jiān)控系統(tǒng)的架構如圖19所示。整個系統(tǒng)分為4個部分:信號采集、信號存儲、報警、信息展示。圖19：統(tǒng)一監(jiān)控平臺架構信號采集對于長時間存活的監(jiān)控目標，按照約定的格式，通過HTTP導出信息，系統(tǒng)會按照設定的時間間隔采集信息。對于短時的任務，需要在退出時將信息交給PushGateway，由它傳遞給系統(tǒng)。信號存儲~50~京東大數(shù)據(jù)技術白皮書Prometheus集群采用樹狀結構部署。葉子節(jié)點會存儲一定時間內(nèi)的數(shù)據(jù)。父節(jié)點負責查詢。數(shù)據(jù)還會旁路一份給OpenTSDB，這是全量數(shù)據(jù)，用于信息的展示和數(shù)據(jù)挖掘。報警采集后的序列，按照PromQL語言進行加工，提取有用信息，包括聚集、過濾、集合運算、計算分位數(shù)、排序等操作。提取后的報警信息通過指定的接口交給AlertManager。它對報警信息進行合并、抑制、分組后再路由給正確的接受者，避免了重復信息的發(fā)送。接受信息的方式可以是電話、郵件、短信和即時通信工具。信息展示監(jiān)控平臺可以在Prometheus節(jié)點進行簡單的信息查詢和展示，也可以在Grafana進行全面細致的展示。我們對于采集的信號進行了分層，如圖20所示。信號分為5層：機器、存儲、調(diào)度、計算框架、業(yè)務。分層的目的是為了隔離，便于不同層次的獨立擴展。當需要擴展的時候，相應的監(jiān)控機器按照存儲和計算需求模塊化部署。物理層包括機器硬件信息，監(jiān)控這些資源的使用是否在合理的范圍內(nèi)，同時還監(jiān)控操作系統(tǒng)的狀態(tài)。存儲、調(diào)度和計算框架是操作系統(tǒng)之上的軟件服務，具體內(nèi)容如圖20所示。監(jiān)控的指標大致包括延時、吞吐、錯誤率、飽和程度，以及服務特定的指標。業(yè)務層的監(jiān)控指標由平臺的應用方來決定。此外，對于采集的信號，使用了統(tǒng)一的命名規(guī)~51~京東大數(shù)據(jù)技術白皮書范，便于管理和維護。2.8.2集群運維京東大數(shù)據(jù)平臺通過自主研發(fā)服務器資產(chǎn)管理系統(tǒng)、自動部署系統(tǒng)、監(jiān)控系統(tǒng)，滿足了對現(xiàn)有40000臺以上規(guī)模服務器以及應用軟件的高效管理。服務器資產(chǎn)管理系統(tǒng)作為整個平臺運維的核心模塊，維護了大數(shù)據(jù)平臺所有服務器的配置信息、機房信息、應用角色信息，并提供了對外以頁面、API形式的增刪改查，完成了與各個系統(tǒng)之間的數(shù)據(jù)打通，避免了外部系統(tǒng)進行角色變更帶來的人為二次維護，保證了數(shù)據(jù)的一致性及準確性。自動部署系統(tǒng)~52~京東大數(shù)據(jù)技術白皮書自動部署系統(tǒng)實現(xiàn)了對大數(shù)據(jù)平臺軟件的統(tǒng)一管理工作，從軟件打包、配置文件修改到線上執(zhí)行一套流程完成，通過與服務器資產(chǎn)管理系統(tǒng)的打通完成了通過角色的方式進行集群管理，并且針對集群各個組件研發(fā)了針對性的功能管理頁面。自動部署系統(tǒng)通過整合流程管理和開發(fā)自定義通用上線模塊，打通了統(tǒng)一服務器控制系統(tǒng)以及實現(xiàn)P2P+MD5傳輸校驗、回調(diào)結果驗證功能，完成了線上運維的時效性、準確性、安全性的規(guī)范操作。監(jiān)控系統(tǒng)通過與自動部署系統(tǒng)、服務器資產(chǎn)管理系統(tǒng)全鏈路打通，實現(xiàn)了角色變更告警規(guī)則自動修正、告警自動觸發(fā)預先配置好的應急處理模塊，滿足大數(shù)據(jù)平臺的自動化、半自動化運維效率。大數(shù)據(jù)平臺建制了完善的運維團隊，從數(shù)據(jù)運維、數(shù)據(jù)運營、各組件運維到系統(tǒng)運維均有專業(yè)人員負責，在制定標準運維規(guī)范的同時各司其職，保障了整個大數(shù)據(jù)平臺的穩(wěn)定運行。~53~京東大數(shù)據(jù)技術白皮書3京東大數(shù)據(jù)的數(shù)據(jù)管理數(shù)據(jù)管理是構建一個統(tǒng)一的、高可用的、服務完善的數(shù)據(jù)環(huán)境的基本保障。企業(yè)通過建立良好的數(shù)據(jù)管理體系，完成對數(shù)據(jù)資產(chǎn)的管理、優(yōu)化和利用，建立常態(tài)化的數(shù)據(jù)管控機制，以應對廣泛的數(shù)據(jù)應用需求，保障數(shù)據(jù)質(zhì)量、安全，支撐企業(yè)的智能決策應用。如圖21所示，我們從數(shù)據(jù)架構設計、數(shù)據(jù)資產(chǎn)管理、數(shù)據(jù)安全管理、統(tǒng)一業(yè)務指標、數(shù)據(jù)服務管理等五個方面構建了數(shù)據(jù)管理框架，通過組織保障、規(guī)范流程、技術創(chuàng)新完成數(shù)據(jù)管理的目標。圖21：數(shù)據(jù)管理框架~54~京東大數(shù)據(jù)技術白皮書3.1數(shù)據(jù)架構設計3.1.1數(shù)據(jù)主題主題是對業(yè)務數(shù)據(jù)的一種抽象，是在較高層次上對京東信息系統(tǒng)中的數(shù)據(jù)進行歸納、整理、綜合、歸類和分析利用的一個抽象概念。面向主題的數(shù)據(jù)組織和存儲包含兩個方面：一是根據(jù)業(yè)務的特點來抽象出主題。二是根據(jù)源系統(tǒng)業(yè)務數(shù)據(jù)的內(nèi)容確定每個主題所包含的數(shù)據(jù)內(nèi)容。分析得出的數(shù)據(jù)主題是對分析對象數(shù)據(jù)的一個完整并且一致的描述，能刻畫各個分析對象所涉及的企業(yè)數(shù)據(jù)。我們對京東所有業(yè)務數(shù)據(jù)進行了逐一梳理，得到京東的數(shù)據(jù)主題如圖22所示。圖22：數(shù)據(jù)主題域劃分~55~京東大數(shù)據(jù)技術白皮書3.1.2數(shù)據(jù)模型數(shù)據(jù)模型設計要充分考慮性能、可用性和可維護性等。定義良好的數(shù)據(jù)模型可以反映業(yè)務模式的本質(zhì)，滿足各類業(yè)務應用的分析需要，確保為業(yè)務需求提供全面、一致、完整的高質(zhì)量數(shù)據(jù)。京東大數(shù)據(jù)平臺設計的數(shù)據(jù)模型層次如圖23所示，數(shù)據(jù)層次的說明如表1所述。圖23：數(shù)據(jù)模型序數(shù)據(jù)架構層簡稱號次數(shù)據(jù)層次用途簡述1數(shù)據(jù)緩沖層BDM源業(yè)務系統(tǒng)數(shù)據(jù)的快照，保存細節(jié)數(shù)據(jù)，按天保存2基礎數(shù)據(jù)層FDM按業(yè)務概念組織細節(jié)數(shù)據(jù)，并進行~56~京東大數(shù)據(jù)技術白皮書名稱、代碼等標準化處理，同時對表進行標準化處理。3通用數(shù)據(jù)層GDM根據(jù)京東核心業(yè)務價值鏈按照星型模型或雪花模型設計方式建設的最細業(yè)務粒度匯總層。在本層需要進行度量與維度的標準化，保證度量數(shù)據(jù)的唯一性。4聚合數(shù)據(jù)層ADM根據(jù)不同的業(yè)務需求采用星型或雪花型模型設計方法構建的數(shù)據(jù)匯總層5維度層DIM維度是對具體分析對象的分析角度，維度要具備豐富的屬性，歷史信息的可追溯性，對通用的維表要保持一致性。表1：數(shù)據(jù)模型的層次通過設計不同的數(shù)據(jù)層次和數(shù)據(jù)匯總粒度，可以滿足不同的業(yè)務應用的需求，提高數(shù)據(jù)的可用性。3.2數(shù)據(jù)資產(chǎn)管理京東作為電商行業(yè)的標桿企業(yè)，有完整的倉儲、物流、營銷、交、易用戶、售后、金融等全鏈路數(shù)據(jù)，經(jīng)過多年的沉淀已經(jīng)形成了寶貴的資產(chǎn)。數(shù)據(jù)資產(chǎn)管理的目的，就是強化數(shù)據(jù)的管理運~57~京東大數(shù)據(jù)技術白皮書營能力，提高數(shù)據(jù)質(zhì)量，更好地實現(xiàn)大數(shù)據(jù)賦能。數(shù)據(jù)資產(chǎn)管理從數(shù)據(jù)資產(chǎn)盤點出發(fā)，厘清數(shù)據(jù)之間的關系，建立數(shù)據(jù)資產(chǎn)管控的標準和體系，實現(xiàn)京東全域數(shù)據(jù)的資產(chǎn)地圖，為數(shù)據(jù)進一步的應用和挖掘奠定基礎。3.2.1數(shù)據(jù)資產(chǎn)盤點盤活企業(yè)數(shù)據(jù)資產(chǎn)，第一步就需要對已有數(shù)據(jù)進行集中盤點。如圖24所示，通過盤點將散落的數(shù)據(jù)源信息匯聚到一起，在數(shù)據(jù)生產(chǎn)者和數(shù)據(jù)消費者之間建立一個完整統(tǒng)一的數(shù)據(jù)地圖，標識出有哪些數(shù)據(jù)可以消費、如何進行消費。圖24：數(shù)據(jù)資產(chǎn)地圖通過資產(chǎn)盤點，建立全公司的數(shù)據(jù)資產(chǎn)地圖，實現(xiàn)所有數(shù)據(jù)源的統(tǒng)一登記和展現(xiàn)，消除因為信息不對稱導致不同部門之間數(shù)據(jù)的重復存儲和抓取，共同完善底層數(shù)據(jù)資源擴充和共享。~58~京東大數(shù)據(jù)技術白皮書3.2.2元數(shù)據(jù)管理數(shù)據(jù)分析師或BI人員每天都要與大量的數(shù)據(jù)模型打交道，如果數(shù)據(jù)模型沒有任何的表描述、字段說明，數(shù)據(jù)使用將變得非常困難。即使數(shù)據(jù)開發(fā)工程師維護了詳盡的表信息，也會存在大量的解釋成本，如果沒有輔助工具能夠記錄這些表的信息，數(shù)據(jù)分析師或BI人員需要到相應的倉庫或集市上去逐個查看表的基本信息，這將嚴重影響工作效率?；谝陨系目剂浚〇|研發(fā)了自己的元數(shù)據(jù)管理平臺（think），用于管理數(shù)據(jù)模型的一些基本信息，方便分析師或BI人員快速查詢，從而更快了解表的信息，處理業(yè)務的數(shù)據(jù)需求。元數(shù)據(jù)管理平臺目前包含了以下的幾個功能：模型搜索、模型基本信息、血緣關系、相關調(diào)度任務等。下面將逐個進行介紹。模型搜索數(shù)據(jù)開發(fā)工程師在數(shù)據(jù)倉庫或數(shù)據(jù)集市上開發(fā)的模型，其元數(shù)據(jù)信息存儲在相應的數(shù)據(jù)庫內(nèi)，每個更新操作都會有相應數(shù)據(jù)庫操作記錄。借助這些的信息，我們可以拿到模型當前的實時狀態(tài)，進而將數(shù)據(jù)信息進行實時維護。通過開放數(shù)據(jù)模型查詢搜索的功能，用戶可以在元數(shù)據(jù)管理平臺上查詢搜索符合自己需求的相關模型。模型的基本信息數(shù)據(jù)分析師或BI人員通常希望快速地了解指標模型的名稱、模型的描述、模型的字段以及模型的使用方法。因此在元數(shù)據(jù)管~59~京東大數(shù)據(jù)技術白皮書理平臺上就需要將這些信息展示出來，方便分析師或者BI人員的使用。血緣關系一般數(shù)據(jù)分析師或者BI人員所使用的模型都是經(jīng)過多層加工后得到的。模型的加工流程、口徑、方式成為數(shù)據(jù)分析師或BI人員評估數(shù)據(jù)模型的有效性、正確性的重要依據(jù)。通過血緣關系圖，數(shù)據(jù)分析師或BI人員可以快速地跟蹤模型數(shù)據(jù)的上游、下游的使用情況，輕松了解數(shù)據(jù)的來龍去脈。相關調(diào)度任務目前京東數(shù)據(jù)倉庫或集市上的模型基本都是通過調(diào)度任務處理得到。模型相關的元數(shù)據(jù)信息，例如分區(qū)情況、血緣關系等等信息，都與調(diào)度任務有著密切的關系。在元數(shù)據(jù)管理平臺中提供了一些輔助信息用于了解和模型關聯(lián)的調(diào)度任務的執(zhí)行情況。詳細了解相關調(diào)度任務的情況則可以通過調(diào)度平臺直接查看。除了以上的功能外，元數(shù)據(jù)管理平臺針對內(nèi)部用戶提供了收藏功能，方便公司內(nèi)部用戶可以快速地定位模型。管理平臺同時提供了評論功能，方便與模型負責人交流模型的具體用法或者對模型提供相應的反饋信息。針對模型負責人則提供了模型編輯的功能，可以快速地補充和完善模型的基本信息、描述信息、表結構說明等等信息。針對集群管理者提供了當前集市新增、修改、下線等等模型的清單，方便集市管理者跟進模型的變化。~60~京東大數(shù)據(jù)技術白皮書3.2.3數(shù)據(jù)質(zhì)量管理數(shù)據(jù)質(zhì)量是有效分析和利用大數(shù)據(jù)的前提，是大數(shù)據(jù)產(chǎn)生跨區(qū)域、跨行業(yè)、跨部門價值的保障。引發(fā)數(shù)據(jù)質(zhì)量問題的原因總結起來有以下幾種。數(shù)據(jù)創(chuàng)建產(chǎn)生如數(shù)值為空、數(shù)據(jù)內(nèi)容和描述不符、數(shù)據(jù)精度不足、數(shù)據(jù)默認值使用不當和數(shù)據(jù)錄入的校驗規(guī)則不當?shù)?。?shù)據(jù)獲取產(chǎn)生如數(shù)據(jù)結構錯誤、數(shù)據(jù)獲取不完整、數(shù)據(jù)采集點不正確、取數(shù)時點不正確等等。數(shù)據(jù)傳遞產(chǎn)生如接口數(shù)據(jù)傳遞延時、接口數(shù)據(jù)漏傳、網(wǎng)絡傳輸不可靠丟包、數(shù)據(jù)傳遞不及時等。數(shù)據(jù)加工產(chǎn)生如數(shù)據(jù)清洗和加工邏輯不正確、算法錯誤導致數(shù)據(jù)多算、漏算等。圍繞上述數(shù)據(jù)質(zhì)量產(chǎn)生的原因，結合京東信息系統(tǒng)建設的特點，京東大數(shù)據(jù)定義數(shù)據(jù)質(zhì)量好壞可以從以下幾個指標來描述：及時性：數(shù)據(jù)平臺是否滿足業(yè)務應用對數(shù)據(jù)的時間要求。完整性：數(shù)據(jù)平臺是否包含了業(yè)務應用所需要的所有數(shù)據(jù)；每份數(shù)據(jù)的記錄是否完整無缺。~61~京東大數(shù)據(jù)技術白皮書準確性：獲取的每一份數(shù)據(jù)是否存在異常或者錯誤信息；數(shù)據(jù)平臺在數(shù)據(jù)的獲取、傳遞、加工過程中是否能保證數(shù)據(jù)的準確?？捎眯裕憾嗑S度、多渠道獲取的數(shù)據(jù)是否能夠易于理解并使用。京東大數(shù)據(jù)自研了數(shù)據(jù)質(zhì)量監(jiān)控平臺，實現(xiàn)了對數(shù)據(jù)質(zhì)量的管理。主要功能如下：數(shù)據(jù)準確性監(jiān)控針對每張數(shù)據(jù)表，可根據(jù)需要定制規(guī)則，對數(shù)據(jù)記錄行數(shù)和數(shù)據(jù)值進行統(tǒng)計，如訂單金額等?？膳c歷史的數(shù)據(jù)值進行比較，通過自定義的閾值進行告警。比對的周期可以定義為日、周等不同周期，實現(xiàn)數(shù)據(jù)準確性的預警。數(shù)據(jù)及時性監(jiān)控將數(shù)據(jù)加工任務按照服務的業(yè)務線歸類，根據(jù)服務SLA設置完成時間的閾值。用戶可以隨時觀察任務運行的狀態(tài)、時間等，也可以通過設置閾值指標，將告警值通過郵件、短信等方式及時反饋給運維人員?？筛鶕?jù)應用、業(yè)務、任務三層監(jiān)控對象進行告警配置。數(shù)據(jù)完整性監(jiān)控針對單行數(shù)據(jù)記錄，可定義空值檢測、枚舉值范圍檢測等，可根據(jù)定義的規(guī)則進行告警。數(shù)據(jù)質(zhì)量事件當發(fā)生數(shù)據(jù)質(zhì)量異常告警后，將生成一個數(shù)據(jù)質(zhì)量事件。該事~62~京東大數(shù)據(jù)技術白皮書件由數(shù)據(jù)運維人員發(fā)起，及時查明異常原因并記錄在知識庫中。該事件的完成必須經(jīng)過上級負責人的審批。數(shù)據(jù)質(zhì)量分析報告用戶可根據(jù)需要查詢數(shù)據(jù)表的質(zhì)量運行報告，包括原因、狀態(tài)、處理結果等。生成的質(zhì)量分析報告對于數(shù)據(jù)質(zhì)量的改進提供參考。除了在技術手段上進行數(shù)據(jù)質(zhì)量管理外，在管理制度上我們也進行了規(guī)范。如上游數(shù)據(jù)庫表變更通知、數(shù)據(jù)質(zhì)量問題必須當日進行記錄及解決等。3.2.4資產(chǎn)管理平臺數(shù)據(jù)資產(chǎn)管理平臺，如圖25所示，是在大數(shù)據(jù)平臺與業(yè)務場景應用中間建立一個一統(tǒng)的數(shù)據(jù)管理中臺體系，加強對數(shù)據(jù)使用機制的管控，讓內(nèi)外部數(shù)據(jù)能匯聚融合、有序流通。圖25：數(shù)據(jù)資產(chǎn)管理平臺~63~京東大數(shù)據(jù)技術白皮書數(shù)據(jù)資產(chǎn)管理平臺的目標，主要有兩個方面：第一是資源管理的角度。一方面通過合理的數(shù)據(jù)使用流程和機制，幫助企業(yè)節(jié)省存儲和計算資源。另一方面，要豐富外部數(shù)據(jù)資源，實現(xiàn)全域數(shù)據(jù)資產(chǎn)的持續(xù)擴充。第二是數(shù)據(jù)資產(chǎn)質(zhì)量提升的角度，通過數(shù)據(jù)資產(chǎn)管理來提高數(shù)據(jù)資產(chǎn)的質(zhì)量和數(shù)據(jù)服務質(zhì)量。數(shù)據(jù)資產(chǎn)的質(zhì)量，是通過持續(xù)跟蹤數(shù)據(jù)資產(chǎn)的使用狀況，形成從數(shù)據(jù)源頭到數(shù)據(jù)消費的整條數(shù)據(jù)鏈路，了解數(shù)據(jù)資產(chǎn)使用的熱點，不斷沉淀數(shù)據(jù)使用過程中的共性問題，規(guī)范數(shù)據(jù)服務流程，指導數(shù)據(jù)架構、模型、數(shù)據(jù)服務接口的優(yōu)化，提升使用效率，同時引入數(shù)據(jù)治理的策略和系，統(tǒng)提升數(shù)據(jù)資產(chǎn)的質(zhì)量。數(shù)據(jù)服務的質(zhì)量，主要是從滿足應用的角度來監(jiān)控任務時效、響應效率、數(shù)據(jù)一致性等問題。京東通過數(shù)據(jù)資產(chǎn)運營、SLA監(jiān)控、指標一統(tǒng)管理等組合手段，促進數(shù)據(jù)的集中共享，保證口徑的一統(tǒng)，讓數(shù)據(jù)消費者減少找數(shù)和對數(shù)的問題，更多地專注到數(shù)據(jù)創(chuàng)新應用中。數(shù)據(jù)資產(chǎn)管理平臺的實現(xiàn)，能夠在數(shù)據(jù)生產(chǎn)系統(tǒng)和業(yè)務應用場景中間，通過數(shù)據(jù)源管理、數(shù)據(jù)治理、數(shù)據(jù)應用管理幾個關鍵環(huán)節(jié)，實現(xiàn)接入流程、開發(fā)流程和數(shù)據(jù)應用規(guī)范的一統(tǒng)，從而達到上述提到的目標。~64~京東大數(shù)據(jù)技術白皮書3.3統(tǒng)一指標體系數(shù)據(jù)指標口徑的管理，是數(shù)據(jù)應用管理范疇里的核心一環(huán)。京東由于業(yè)務的快速發(fā)展和復雜場景，口徑迭代較快，加上數(shù)據(jù)開發(fā)團隊較多，導致相似指標的實現(xiàn)邏輯存在差異，給業(yè)務運營和決策帶來挑戰(zhàn)。為了解決指標口徑問題，統(tǒng)一信息流建設，為大家提供標準的數(shù)據(jù)指標解讀和數(shù)據(jù)應用規(guī)范，京東建立了指標統(tǒng)一管理平臺。平臺對上百個數(shù)據(jù)產(chǎn)品的指標口徑進行盤點核對，按照主題規(guī)范數(shù)據(jù)指標口徑，明確差異，避免歧義和重復開發(fā)，提高數(shù)據(jù)共享和一致性。目前已經(jīng)形成了涵蓋交易、流、量財務、用戶、供應鏈等十多個主題，500+原子指標的標準口徑，建立了指標白皮書和維度白皮書，形成了統(tǒng)一的口徑標準。在統(tǒng)一的指標口徑之上，為了便于數(shù)據(jù)消費者系統(tǒng)化地共享和使用數(shù)據(jù)，指標統(tǒng)一管理平臺提供了統(tǒng)一的數(shù)據(jù)服務總線，支持標準化的數(shù)據(jù)模型檢索、離線和實時API服務，以及人貨場標簽的共享。隨著數(shù)據(jù)統(tǒng)一口徑標準的推行，避免了各業(yè)務部門的重復建設和計算，對集市計算資源有明顯的節(jié)省。例如流量明細層模型使用任務數(shù)與推廣時相比降幅為42.17%，任務內(nèi)存消耗GDM層降幅為37.16%，整體運行時長降低20%，效果如圖26所示。~65~京東大數(shù)據(jù)技術白皮書圖26：統(tǒng)一指標推行后的效果3.4數(shù)據(jù)安全管理京東大數(shù)據(jù)平臺集中了京東業(yè)務運營中的所有數(shù)據(jù)，其中包含用戶信息、商品成本、利潤等信息。因此，數(shù)據(jù)的安全對于平臺來講非常重要，針對數(shù)據(jù)安全保護的措施主要圍繞以下幾個方面：敏感數(shù)據(jù)集市建設針對京東數(shù)以億計的用戶，京東大數(shù)據(jù)啟動了敏感數(shù)據(jù)集市的建設，將涉及用戶隱私的數(shù)據(jù)單獨設置了數(shù)據(jù)存儲區(qū)域，和其它的數(shù)據(jù)存儲進行邏輯隔離。采用了國家認證的密鑰算法，對用戶隱私信息進行加密存儲，并實現(xiàn)每1萬行記錄換一次密鑰的方法。用戶隱私信息在數(shù)據(jù)抽取時即被加密，保證隱私信息落地即密文。在用戶隱私數(shù)據(jù)使用上采取嚴格的審批機制，必須經(jīng)過用戶需求部門、信息安全部門、大數(shù)據(jù)部門同時簽批才可使用敏感數(shù)據(jù)。IP黑白名單機制京東大數(shù)據(jù)平臺通過設立黑白名單機制限制非法IP訪問集群~66~京東大數(shù)據(jù)技術白皮書的數(shù)據(jù)資源。用戶訪問京東大數(shù)據(jù)平臺必須使用我們提供的產(chǎn)品與工具。在白名單中的用戶才會被授權通過，不會被元數(shù)據(jù)服務器拒絕，未經(jīng)授權的產(chǎn)品和用戶的數(shù)據(jù)請求會被拒絕，并將惡意訪問數(shù)據(jù)資源的行為記錄入黑名單中，讓安全人員立即采取行動。員工賬號綁定所有登錄大數(shù)據(jù)平臺的用戶，無論是使用數(shù)據(jù)工具還是通過堡壘機登錄，必須使用公司發(fā)放的唯一員工賬號，并且用戶在大數(shù)據(jù)平臺上每一步操作都將進行日志記錄。記錄中包含有用戶的操作命令和員工賬號，便于發(fā)生安全問題時進行追溯和查找。最小化授權策略大數(shù)據(jù)平臺權限系統(tǒng)提供了一個和HDFS原生權限相匹配適應的授權模型管理訪問策略,可以將用戶的授權細化到文件級別。用戶申請使用數(shù)據(jù)時，需要詳細說明數(shù)據(jù)的使用場景與用途，并明確操作權限。權限需要經(jīng)過上級領導、數(shù)據(jù)生產(chǎn)者、業(yè)務負責人、集市負責人等多層嚴格審批。所有授權記錄需有據(jù)可查，保證數(shù)據(jù)最小化的授權與授權可追溯。數(shù)據(jù)導出統(tǒng)計針對所有從平臺導出的數(shù)據(jù)以及集市之間交換的數(shù)據(jù)進行統(tǒng)計，制作分析報告，防范風險。全面的日志審計所有大數(shù)據(jù)平臺的日志都將保留并定期收集進行審計。用戶保密協(xié)議~67~京東大