一、大數(shù)據(jù)綜述

隨著DT(數(shù)據(jù)技術(shù))時代的到來，人們能比以往更容易地獲取更豐富的數(shù)據(jù)。數(shù)據(jù)作為一種新的能源形式，正在源源不斷地發(fā)揮其巨大的價值，幫助我們激發(fā)更多的技術(shù)驅(qū)動力，提供更優(yōu)質(zhì)的服務(wù)。

在京東，有著EB級規(guī)模的歷史數(shù)據(jù)，每天有近PB級的數(shù)據(jù)增長，同時每天有***的數(shù)據(jù)處理任務(wù)在執(zhí)行。數(shù)據(jù)井噴式的增長給數(shù)據(jù)采集、數(shù)據(jù)處理、數(shù)據(jù)管理、數(shù)據(jù)應(yīng)用、數(shù)據(jù)質(zhì)量、數(shù)據(jù)運(yùn)維帶來了極大的考驗(yàn)。

京東的數(shù)據(jù)目前包含了電商、金融、廣告、配送、智能硬件、運(yùn)營、線下、線上等場景的數(shù)據(jù)，每個場景的數(shù)據(jù)背后都存在著眾多復(fù)雜的業(yè)務(wù)邏輯。為了幫助業(yè)務(wù)人員降低獲取數(shù)據(jù)的門檻，簡化數(shù)據(jù)獲取的流程，同時幫助分析人員方便快捷地進(jìn)行數(shù)據(jù)統(tǒng)計分析， 進(jìn)而挖掘數(shù)據(jù)的潛在價值，京東搭建了一套完整的數(shù)據(jù)解決方案。

上圖為大數(shù)據(jù)平臺技術(shù)架構(gòu)，分散在四處的線上系統(tǒng)數(shù)據(jù)(多為結(jié)構(gòu)化的業(yè)務(wù)數(shù)據(jù))，或者是各種日志文件、文檔、圖片、音頻、視頻等非結(jié)構(gòu)化數(shù)據(jù)，需要進(jìn)行采集。我們分別借助實(shí)時和離線的數(shù)據(jù)處理平臺，將數(shù)據(jù)抽取至實(shí)時數(shù)據(jù)倉庫和離線倉庫，然后借助平臺內(nèi)的工具對數(shù)據(jù)進(jìn)行加工處理，同時輔以各種平臺產(chǎn)品對數(shù)據(jù)進(jìn)行統(tǒng)一管理、監(jiān)控、處理、查詢、分析等， 并結(jié)合具體的業(yè)務(wù)需求，形成相應(yīng)的數(shù)據(jù)應(yīng)用產(chǎn)品。

二、技術(shù)平臺

1、數(shù)據(jù)采集

京東包含了電商所涉及的營銷、交易、倉儲、配送、售后等環(huán)節(jié)，每個環(huán)節(jié)中都會產(chǎn)生大量的業(yè)務(wù)數(shù)據(jù)，同時用戶在網(wǎng)站上進(jìn)行的瀏覽、購物、消費(fèi)等活動，以及用戶在移動設(shè)備上對應(yīng)用的使用情況，包括各種系統(tǒng)的操作行為，也會生成海量的行為數(shù)據(jù)。為了將上述的結(jié)構(gòu)化業(yè)務(wù)數(shù)據(jù)以及用戶非結(jié)構(gòu)化的用戶行為日志進(jìn)行采集，京東搭建了一套標(biāo)準(zhǔn)化采集方案，能夠?qū)I(yè)務(wù)分析所需的數(shù)據(jù)進(jìn)行標(biāo)準(zhǔn)化采集，并將數(shù)據(jù)傳輸?shù)酱髷?shù)據(jù)平臺，以便后續(xù)的加工處理及上層的數(shù)據(jù)應(yīng)用。

目前京東的數(shù)據(jù)采集方案主要分為兩大類：用戶行為日志采集方案(點(diǎn)擊流系統(tǒng))和通用數(shù)據(jù)采集方案(數(shù)據(jù)直通車)，下面將做詳細(xì)介紹。

點(diǎn)擊流系統(tǒng)

目前京東有著豐富的入口平臺及展示形式，包括PC網(wǎng)頁、H5頁面、App應(yīng)用、App內(nèi)部的H5頁面、智能設(shè)備、微信、手Q以及微信生態(tài)下的新場景微信小程序。其中PC網(wǎng)頁、H5頁面、App內(nèi)部的H5頁面、微信、手Q以及微信小程序由網(wǎng)頁方式呈現(xiàn)， 用戶通過瀏覽器進(jìn)行訪問;而智能設(shè)備，例如手機(jī)、移動手環(huán)、智能家電等，則是以App應(yīng)用的方式呈現(xiàn)，用戶訪問App即可獲得相應(yīng)的服務(wù)。

以下是瀏覽器和App用兩種使用場景的日志采集方案：

瀏覽器端的日志采集

• 日志采集：瀏覽器的日志采集方式，首先需要在統(tǒng)計頁面日志的頁面中預(yù)先植入一段Java Script腳本，當(dāng)頁面被瀏覽器加載時，會執(zhí)行該腳本。腳本中預(yù)設(shè)了一些采集需求，包括收集頁面信息、訪問信息(訪次、上下文)、業(yè)務(wù)信息、運(yùn)行環(huán)境信息(瀏覽器信息、訪問時間、訪問地址)等。日志采集腳本在被執(zhí)行后，會向服務(wù)器端發(fā)送一條HTTPS的請求，請求內(nèi)容包含了收集到的日志信息。
• 服務(wù)器日志接收：日志服務(wù)器在成功接收到瀏覽器發(fā)送的日志請求后，立刻向?yàn)g覽器發(fā)送一個請求成功的響應(yīng)，日志請求的響應(yīng)不影響頁面的加載。日志服務(wù)器在接收到日志請求后，會對日志請求進(jìn)行分析處理，包括判斷其是否為爬蟲、是否為刷流量行為、是否為惡意流量、是否為正常的日志請求等，對日志請求進(jìn)行屏蔽和過濾，以免對下游解析和應(yīng)用造成影響。
• 日志存儲：服務(wù)器接收到日志請求后，會依據(jù)請求的內(nèi)容及約定的格式對其進(jìn)行格式化落地。例如，當(dāng)前頁面、上一頁面、業(yè)務(wù)信息、瀏覽器等信息以特定的字段標(biāo)識，字段之間使用特定的分隔符，整條日志以特定的格式記錄下來。結(jié)合業(yè)務(wù)的時效性需求，將日志分發(fā)到實(shí)時平臺或者落地成離線文件。

經(jīng)過數(shù)據(jù)的收集(采集—上報—接收—存儲)，我們將用戶在瀏覽器端的行為日志實(shí)時記錄下來。除植入代碼人工干預(yù)外，可以保證數(shù)據(jù)的準(zhǔn)確性，數(shù)據(jù)的過濾和篩選保證了異常流量的干擾，格式化數(shù)據(jù)方便了后續(xù)的數(shù)據(jù)解析處理。

移動設(shè)備的日志采集

移動設(shè)備的頁面有別于瀏覽器頁面，移動設(shè)備主要為原生頁組成的App應(yīng)用，原生頁使用原生預(yù)研開發(fā)完成。例如Android系統(tǒng)使用Java語言，iOS系統(tǒng)使用Objective-C原生語言開發(fā)，原生頁運(yùn)行速度快，效率高。

• 采集方式：移動設(shè)備上App應(yīng)用的數(shù)據(jù)采集主要使用的是SDK工具，App應(yīng)用在發(fā)版前將SDK工具集成進(jìn)來，設(shè)定不同的事件行為場景，當(dāng)用戶觸發(fā)相應(yīng)的場景時，則會執(zhí)行SDK相應(yīng)的腳本，采集對應(yīng)的行為日志。
• 日志存儲：用戶的各種場景都會產(chǎn)生日志，為了減少用戶的流量損耗，我們將日志先在客戶端進(jìn)行緩存，并對數(shù)據(jù)進(jìn)行聚合，在適當(dāng)時機(jī)對數(shù)據(jù)進(jìn)行加密和壓縮后上報至日志服務(wù)器，同時數(shù)據(jù)的聚合和壓縮也可以減少對服務(wù)器的請求情況。

數(shù)據(jù)直通車

數(shù)據(jù)直通車為京東線上數(shù)據(jù)提供接入京東數(shù)據(jù)倉庫的完整解決方案，為后續(xù)的查詢、分發(fā)、計算和分析提供數(shù)據(jù)基礎(chǔ)。直通車提供豐富多樣、簡單易用的數(shù)據(jù)處理功能，可滿足離線接入、實(shí)時計算、集成分發(fā)等多種需求，并進(jìn)行全程狀態(tài)監(jiān)控。

上圖所示的數(shù)據(jù)直通車接入數(shù)據(jù)類型，根據(jù)抽取的數(shù)據(jù)量及抽取對線上的影響，會分為定時的離線接入和實(shí)時接入兩種抽取方式。每種抽取方式支持不同的數(shù)據(jù)類型，每天在零點(diǎn)后可以獲取前一天完整的數(shù)據(jù)，然后將一整天的數(shù)據(jù)進(jìn)行集中加工處理，并將數(shù)據(jù)最終儲存到目標(biāo)表對應(yīng)的分區(qū)中。

2、數(shù)據(jù)處理

實(shí)時平臺

業(yè)務(wù)數(shù)據(jù)處理的需求已經(jīng)逐漸從離線轉(zhuǎn)向了實(shí)時，在電商的應(yīng)用場景中，越來越多的需求更加倚重實(shí)時數(shù)據(jù)的處理和分析，越來越多的面向用戶和商家的業(yè)務(wù)場景開始嘗試實(shí)時技術(shù)帶來的收益。京東實(shí)時技術(shù)平臺協(xié)助業(yè)務(wù)更快地幫助用戶發(fā)現(xiàn)自己想要的商品(推薦搜索)，為商家更快地制訂銷售策略(實(shí)時數(shù)據(jù)分析報表)提供了強(qiáng)有力的支撐。

京東實(shí)時數(shù)據(jù)平臺一共包括三大部分：實(shí)時數(shù)據(jù)接入(MAGPIE)，實(shí)時數(shù)據(jù)傳輸(JDQ)和實(shí)時數(shù)據(jù)計算(JRC)。

下面就實(shí)時數(shù)據(jù)處理分析在京東的技術(shù)流程進(jìn)行闡述：

實(shí)時數(shù)據(jù)接入

實(shí)時數(shù)據(jù)的源頭是各個線上業(yè)務(wù)系統(tǒng)的各種類型數(shù)據(jù)源，在京東內(nèi)部主要包括三個部門：

• 線上業(yè)務(wù)系統(tǒng)數(shù)據(jù)庫：MySQL、SQL Server、Oracle。目前京東內(nèi)部線上系統(tǒng)基本都已經(jīng)切換MySQL。實(shí)時數(shù)據(jù)接入系統(tǒng)Magpie完全支持上述三個關(guān)系型數(shù)據(jù)庫的數(shù)據(jù)實(shí)時接入，原理為數(shù)據(jù)庫的主從復(fù)制模式，通過偽裝從庫的方式，把關(guān)系型數(shù)據(jù)庫的Binlog日志實(shí)時抓取并解析發(fā)送到JDQ內(nèi)。對于MySQL數(shù)據(jù)庫，實(shí)時接入程序按照服務(wù)粒度抓取MySQL單服務(wù)上的所有Binlog，在程序內(nèi)部進(jìn)行Binlog的實(shí)時解析并過濾出所需要的庫表，再發(fā)送到表粒度的Topic上，方便下游用戶進(jìn)行業(yè)務(wù)表粒度的實(shí)時處理。
• 線上業(yè)務(wù)日志系統(tǒng)：統(tǒng)***量(用戶瀏覽點(diǎn)擊日志)，統(tǒng)一日志(各業(yè)務(wù)系統(tǒng)服務(wù)日志)。業(yè)務(wù)日志由線上系統(tǒng)先發(fā)送到JDQ的寫集群，再由Magpie任務(wù)實(shí)時同步到JDQ的讀集群。通過這種方式做到了日志數(shù)據(jù)的讀寫分離，極大地提高了系統(tǒng)穩(wěn)定性和服務(wù)能力。
• 線上消息系統(tǒng)：JMQ。JMQ是京東內(nèi)部線上系統(tǒng)的消息中間件服務(wù)，很多業(yè)務(wù)數(shù)據(jù)在落數(shù)據(jù)庫之前都會經(jīng)過JMQ系統(tǒng)在不同業(yè)務(wù)系統(tǒng)之間進(jìn)行傳遞。Magpie同樣可以把JMQ內(nèi)的線上系統(tǒng)消息實(shí)時地同步到JDQ內(nèi)，再面向數(shù)據(jù)處理用戶進(jìn)行消費(fèi)，極大地提高了數(shù)據(jù)處理系統(tǒng)的服務(wù)能力。

京東內(nèi)部所有系統(tǒng)的實(shí)時數(shù)據(jù)都會經(jīng)過Magpie系統(tǒng)進(jìn)行接入和轉(zhuǎn)發(fā)到JDQ系統(tǒng)，統(tǒng)一由JDQ對數(shù)據(jù)處理的業(yè)務(wù)需求提供消息服務(wù)。該方案幫助業(yè)務(wù)用戶在技術(shù)層面屏蔽了接入的復(fù)雜度問題，并把服務(wù)穩(wěn)定性和能力提高到了大數(shù)據(jù)實(shí)時處理的要求。

實(shí)時數(shù)據(jù)總線

實(shí)時數(shù)據(jù)在由Magpie進(jìn)行統(tǒng)一接入處理后，需要一個面向業(yè)務(wù)研發(fā)用戶的消息消費(fèi)服務(wù)。我們基于Kafka的JDQ服務(wù)就是滿足這個需求的產(chǎn)品。

在原生Kafka的基礎(chǔ)上，我們封裝了權(quán)限、限速、監(jiān)控報警等一系列服務(wù)。針對重要業(yè)務(wù)進(jìn)行了雙機(jī)房讀寫分離的部署方案，大大提高了消息服務(wù)的可靠性和服務(wù)能力。618當(dāng)天日生產(chǎn)291TB、8000億行數(shù)據(jù)，日消費(fèi)1000TB。各個系統(tǒng)越來越重視通過日志進(jìn)行數(shù)據(jù)分析，每次618的業(yè)務(wù)日志量均以150%的速度增長。

生產(chǎn)日志系統(tǒng)向最近機(jī)房內(nèi)的JDQ系統(tǒng)的寫Topic發(fā)送業(yè)務(wù)日志消息，如遇機(jī)房故障，自動切換到可用機(jī)房的服務(wù)。

JDQ系統(tǒng)通過實(shí)時同步不同寫集群數(shù)據(jù)到每個機(jī)房的讀集群，實(shí)現(xiàn)每個機(jī)房都有一份完整的業(yè)務(wù)日志數(shù)據(jù)可供業(yè)務(wù)研發(fā)消費(fèi)。

業(yè)務(wù)研發(fā)就近機(jī)房選擇讀集群進(jìn)行消費(fèi)，同時通過JDQ可以實(shí)現(xiàn)不同用戶的消費(fèi)限速，***限度地保證集群服務(wù)的穩(wěn)定可靠。

JDQ實(shí)時數(shù)據(jù)總線服務(wù)作為實(shí)時數(shù)據(jù)的中轉(zhuǎn)緩存服務(wù)，屏蔽了業(yè)務(wù)研發(fā)對不同數(shù)據(jù)源的接入難度，同時通過一系列的數(shù)據(jù)格式使用方式的標(biāo)準(zhǔn)化，打通了實(shí)時數(shù)據(jù)從接入到業(yè)務(wù)處理的傳輸環(huán)節(jié)，實(shí)現(xiàn)了京東內(nèi)部實(shí)時數(shù)據(jù)通道的目標(biāo)。

實(shí)時數(shù)據(jù)計算

實(shí)時數(shù)據(jù)要想體現(xiàn)業(yè)務(wù)價值，最終還需要業(yè)務(wù)研發(fā)方進(jìn)行計算和分析。京東內(nèi)部主流的實(shí)時計算平臺是JRC計算平臺，該平臺脫胎于早期的Storm版本，由平臺研發(fā)進(jìn)行了深度的改造和產(chǎn)品化，實(shí)現(xiàn)了業(yè)務(wù)研發(fā)用戶完全的Web產(chǎn)品任務(wù)管理和監(jiān)控的需求，同時整合了JDQ數(shù)據(jù)來源，實(shí)現(xiàn)了用戶在數(shù)據(jù)計算平臺的無縫對接實(shí)時數(shù)據(jù)。本次618達(dá)到1.1萬億次日處理次數(shù)。

2017年618，JRC基于容器的新架構(gòu)已經(jīng)開始支撐部分線上業(yè)務(wù)，未來容器化的JRC方案會進(jìn)一步提高Storm平臺的穩(wěn)定性和資源利用率。JRC架構(gòu)圖如圖：

該方案的特點(diǎn)如下：

• 通過Kubernetes實(shí)現(xiàn)Topology執(zhí)行節(jié)點(diǎn)的容器化，資源隨用隨申請，提高資源利用率。
• 通過Kubernetes和二級調(diào)度的方案，把Topology調(diào)度邏輯放在Kubernetes層面和Topology內(nèi)部，提高了調(diào)度的效率，避免了不同Topology之間的干擾。
• 心跳只在Timbus和Topology Master以及Topology Master和Worker之間進(jìn)行，避免了傳統(tǒng)方案任務(wù)量大時的心跳壓力。

由于實(shí)時計算的場景多樣，針對不同場景業(yè)內(nèi)提出了多個流行的計算框架。目前京東內(nèi)部實(shí)時計算的場景也趨于多樣，我們平臺已經(jīng)開始在線上正式提供Spark Streaming和Flink等多種計算框架的產(chǎn)品化服務(wù)。

由于實(shí)時計算程序必須由程序代碼進(jìn)行開發(fā)，對于傳統(tǒng)離線業(yè)務(wù)，SQL研發(fā)人員進(jìn)行離線需求轉(zhuǎn)實(shí)時還有較高的門檻，我們平臺正在進(jìn)行SQL形式和拖曳形式的實(shí)時計算產(chǎn)品化研發(fā)工作。該方案上線后，將進(jìn)一步幫助業(yè)務(wù)方把離線數(shù)據(jù)處理需求轉(zhuǎn)移到實(shí)時數(shù)據(jù)處理上，幫助京東的業(yè)務(wù)更快速地服務(wù)于廣大的用戶和商家。

目前京東實(shí)時數(shù)據(jù)解決方案整套流程已經(jīng)接入了線上的上千張業(yè)務(wù)表數(shù)據(jù)流和數(shù)百個業(yè)務(wù)日志數(shù)據(jù)流，覆蓋京東內(nèi)部所有核心業(yè)務(wù)系統(tǒng)和大部分實(shí)時處理業(yè)務(wù)，主要面向京東內(nèi)部各個業(yè)務(wù)部門的個性化推薦、秒殺、實(shí)時運(yùn)營、商家報表等。未來，離線數(shù)據(jù)處理需求會越來越多地遷移到實(shí)時數(shù)據(jù)處理上。

離線平臺

京東大數(shù)據(jù)離線平臺的整體架構(gòu)如下圖：

平臺詳解

離線處理架構(gòu)為數(shù)據(jù)存儲+數(shù)據(jù)緩存+數(shù)據(jù)處理+數(shù)據(jù)應(yīng)用。

• 數(shù)據(jù)存儲：以前數(shù)據(jù)倉庫是LZO，線上業(yè)務(wù)是SQL Server、Oracle?，F(xiàn)在數(shù)據(jù)倉庫是ORC，線上業(yè)務(wù)是MySQL、HBase。
• 數(shù)據(jù)緩存：Alluxio是一個基于內(nèi)存的分布式文件系統(tǒng)，它是架構(gòu)在底層分布式文件系統(tǒng)和上層分布式計算框架之間的一個中間件，主要職責(zé)是以文件形式在內(nèi)存或其他存儲設(shè)施中提供數(shù)據(jù)的存取服務(wù)。
• 數(shù)據(jù)處理：混合型引擎，按需按量分配，以及根據(jù)不同業(yè)務(wù)場景，選擇不同處理方式，統(tǒng)一由Yarn做資源管理。
• 數(shù)據(jù)應(yīng)用：服務(wù)京東消費(fèi)數(shù)據(jù)的幾乎所有場景，如數(shù)據(jù)挖掘、分析報告、常規(guī)報表、即席查詢等。

具體介紹

在京東大數(shù)據(jù)平臺中有多個物理集群、十幾個集群應(yīng)用軟件、十幾個大數(shù)據(jù)產(chǎn)品、三十多個數(shù)據(jù)集市、六千多個平臺用戶，日運(yùn)行job數(shù)量超過40萬，日計算數(shù)據(jù)量超過15PB。在如此龐大的業(yè)務(wù)場景、海量數(shù)據(jù)計算、復(fù)雜數(shù)據(jù)處理流程的場景下，一個高效實(shí)用的大數(shù)據(jù)離線平臺顯得尤為重要。

為此，我們對大數(shù)據(jù)平臺建設(shè)以來支持的各類業(yè)務(wù)服務(wù)，大數(shù)據(jù)平臺自身的升級與運(yùn)維技術(shù)工作進(jìn)行了梳理分析，對大數(shù)據(jù)平臺從前端服務(wù)到后臺技術(shù)進(jìn)行了整體服務(wù)框架設(shè)計。完成了從多出口的臃腫服務(wù)到統(tǒng)一服務(wù)管理、自助化服務(wù)管理、自動化服務(wù)實(shí)現(xiàn)的有機(jī)“瘦身運(yùn)動”，大數(shù)據(jù)平臺服務(wù)時效得到了幾倍乃至幾十倍的提升。

大數(shù)據(jù)平臺已經(jīng)實(shí)現(xiàn)了海量數(shù)據(jù)的實(shí)時與離線計算，同時也達(dá)到高并發(fā)、高容錯、高擴(kuò)展、低成本的集團(tuán)發(fā)展需要。同時，在保證現(xiàn)有大數(shù)據(jù)平臺穩(wěn)定的基礎(chǔ)上，通過與京東集市三十多個業(yè)務(wù)集市的深入接觸溝通，在業(yè)務(wù)發(fā)展基礎(chǔ)上，結(jié)合***、最適合的前沿技術(shù)，不斷提高大數(shù)據(jù)平臺的業(yè)務(wù)實(shí)現(xiàn)范圍、大數(shù)據(jù)平臺技術(shù)創(chuàng)新(如異構(gòu)集群、多引擎支持、即席查詢、多維分析、登月平臺等)、大數(shù)據(jù)平臺更好的運(yùn)營管控機(jī)制(如大數(shù)據(jù)平臺運(yùn)營規(guī)范、數(shù)據(jù)倉庫與集市建設(shè)規(guī)范、運(yùn)營值班方案、流程中心等)，不斷滿足業(yè)務(wù)高速發(fā)展對未來大數(shù)據(jù)平臺的技術(shù)需要，實(shí)現(xiàn)戰(zhàn)略價值目標(biāo)。

作者介紹

京東集團(tuán)618作戰(zhàn)指揮中心，成員來自于京東各個技術(shù)體系，包括核心系統(tǒng)架構(gòu)師、一線運(yùn)維專家、科研學(xué)者等。近200位成員在618時共同努力，確保流量洪峰來臨時系統(tǒng)安全、穩(wěn)定、可靠，致力于提供***的用戶體驗(yàn)。