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

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

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

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

 

 

大數(shù)據(jù)平臺技術架構(gòu)

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

二、技術平臺

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

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

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

點擊流系統(tǒng)

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

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

瀏覽器端的日志采集

日志采集：瀏覽器的日志采集方式，首先需要在統(tǒng)計頁面日志的頁面中預先植入一段Java Script腳本，當頁面被瀏覽器加載時，會執(zhí)行該腳本。腳本中預設了一些采集需求，包括收集頁面信息、訪問信息(訪次、上下文)、業(yè)務信息、運行環(huán)境信息(瀏覽器信息、訪問時間、訪問地址)等。日志采集腳本在被執(zhí)行后，會向服務器端發(fā)送一條HTTPS的請求，請求內(nèi)容包含了收集到的日志信息。

服務器日志接收：日志服務器在成功接收到瀏覽器發(fā)送的日志請求后，立刻向瀏覽器發(fā)送一個請求成功的響應，日志請求的響應不影響頁面的加載。日志服務器在接收到日志請求后，會對日志請求進行分析處理，包括判斷其是否為爬蟲、是否為刷流量行為、是否為惡意流量、是否為正常的日志請求等，對日志請求進行屏蔽和過濾，以免對下游解析和應用造成影響。

日志存儲：服務器接收到日志請求后，會依據(jù)請求的內(nèi)容及約定的格式對其進行格式化落地。例如，當前頁面、上一頁面、業(yè)務信息、瀏覽器等信息以特定的字段標識，字段之間使用特定的分隔符，整條日志以特定的格式記錄下來。結(jié)合業(yè)務的時效性需求，將日志分發(fā)到實時平臺或者落地成離線文件。

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

移動設備的日志采集

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

采集方式：移動設備上App應用的數(shù)據(jù)采集主要使用的是SDK工具，App應用在發(fā)版前將SDK工具集成進來，設定不同的事件行為場景，當用戶觸發(fā)相應的場景時，則會執(zhí)行SDK相應的腳本，采集對應的行為日志。

日志存儲：用戶的各種場景都會產(chǎn)生日志，為了減少用戶的流量損耗，我們將日志先在客戶端進行緩存，并對數(shù)據(jù)進行聚合，在適當時機對數(shù)據(jù)進行加密和壓縮后上報至日志服務器，同時數(shù)據(jù)的聚合和壓縮也可以減少對服務器的請求情況。

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

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

 

 

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

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

實時平臺

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

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

 

 

京東實時數(shù)據(jù)平臺

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

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

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

線上業(yè)務系統(tǒng)數(shù)據(jù)庫：MySQL、SQL Server、Oracle。目前京東內(nèi)部線上系統(tǒng)基本都已經(jīng)切換MySQL。實時數(shù)據(jù)接入系統(tǒng)Magpie完全支持上述三個關系型數(shù)據(jù)庫的數(shù)據(jù)實時接入，原理為數(shù)據(jù)庫的主從復制模式，通過偽裝從庫的方式，把關系型數(shù)據(jù)庫的Binlog日志實時抓取并解析發(fā)送到JDQ內(nèi)。對于MySQL數(shù)據(jù)庫，實時接入程序按照服務粒度抓取MySQL單服務上的所有Binlog，在程序內(nèi)部進行Binlog的實時解析并過濾出所需要的庫表，再發(fā)送到表粒度的Topic上，方便下游用戶進行業(yè)務表粒度的實時處理。

線上業(yè)務日志系統(tǒng)：統(tǒng)一流量(用戶瀏覽點擊日志)，統(tǒng)一日志(各業(yè)務系統(tǒng)服務日志)。業(yè)務日志由線上系統(tǒng)先發(fā)送到JDQ的寫集群，再由Magpie任務實時同步到JDQ的讀集群。通過這種方式做到了日志數(shù)據(jù)的讀寫分離，極大地提高了系統(tǒng)穩(wěn)定性和服務能力。

線上消息系統(tǒng)：JMQ。JMQ是京東內(nèi)部線上系統(tǒng)的消息中間件服務，很多業(yè)務數(shù)據(jù)在落數(shù)據(jù)庫之前都會經(jīng)過JMQ系統(tǒng)在不同業(yè)務系統(tǒng)之間進行傳遞。Magpie同樣可以把JMQ內(nèi)的線上系統(tǒng)消息實時地同步到JDQ內(nèi)，再面向數(shù)據(jù)處理用戶進行消費，極大地提高了數(shù)據(jù)處理系統(tǒng)的服務能力。

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

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

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

 

 

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

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

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

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

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

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

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

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

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

 

 

該方案的特點如下：

通過Kubernetes實現(xiàn)Topology執(zhí)行節(jié)點的容器化，資源隨用隨申請，提高資源利用率。

通過Kubernetes和二級調(diào)度的方案，把Topology調(diào)度邏輯放在Kubernetes層面和Topology內(nèi)部，提高了調(diào)度的效率，避免了不同Topology之間的干擾。

心跳只在Timbus和Topology Master以及Topology Master和Worker之間進行，避免了傳統(tǒng)方案任務量大時的心跳壓力。

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

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

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

離線平臺

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

 

 

平臺詳解

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

數(shù)據(jù)存儲：以前數(shù)據(jù)倉庫是LZO，線上業(yè)務是SQL Server、Oracle�，F(xiàn)在數(shù)據(jù)倉庫是ORC，線上業(yè)務是MySQL、HBase。

數(shù)據(jù)緩存：Alluxio是一個基于內(nèi)存的分布式文件系統(tǒng)，它是架構(gòu)在底層分布式文件系統(tǒng)和上層分布式計算框架之間的一個中間件，主要職責是以文件形式在內(nèi)存或其他存儲設施中提供數(shù)據(jù)的存取服務。

數(shù)據(jù)處理：混合型引擎，按需按量分配，以及根據(jù)不同業(yè)務場景，選擇不同處理方式，統(tǒng)一由Yarn做資源管理。

數(shù)據(jù)應用：服務京東消費數(shù)據(jù)的幾乎所有場景，如數(shù)據(jù)挖掘、分析報告、常規(guī)報表、即席查詢等。

具體介紹

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

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

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

作者介紹

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

標簽： Mysql 安全 大數(shù)據(jù) 大數(shù)據(jù)平臺 大數(shù)據(jù)平臺建設 代碼 電商 服務器 服務器端 機房 腳本 金融 權限 數(shù)據(jù)分析 數(shù)據(jù)庫 搜索

版權申明：本站文章部分自網(wǎng)絡，如有侵權，請聯(lián)系：west999com@outlook.com
特別注意：本站所有轉(zhuǎn)載文章言論不代表本站觀點！
本站所提供的圖片等素材，版權歸原作者所有，如需使用，請與原作者聯(lián)系。