一、大數據綜述

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

在京東，有著EB級規模的歷史數據，每天有近PB級的數據增長，同時每天有***的數據處理任務在執行。數據井噴式的增長給數據采集、數據處理、數據管理、數據應用、數據質量、數據運維帶來了極大的考驗。

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

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

二、技術平臺

1、數據采集

京東包含了電商所涉及的營銷、交易、倉儲、配送、售后等環節，每個環節中都會產生大量的業務數據，同時用戶在網站上進行的瀏覽、購物、消費等活動，以及用戶在移動設備上對應用的使用情況，包括各種系統的操作行為，也會生成海量的行為數據。為了將上述的結構化業務數據以及用戶非結構化的用戶行為日志進行采集，京東搭建了一套標準化采集方案，能夠將業務分析所需的數據進行標準化采集，并將數據傳輸到大數據平臺，以便后續的加工處理及上層的數據應用。

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

點擊流系統

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

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

瀏覽器端的日志采集

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

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

移動設備的日志采集

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

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

數據直通車

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

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

2、數據處理

實時平臺

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

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

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

實時數據接入

實時數據的源頭是各個線上業務系統的各種類型數據源，在京東內部主要包括三個部門：

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

京東內部所有系統的實時數據都會經過Magpie系統進行接入和轉發到JDQ系統，統一由JDQ對數據處理的業務需求提供消息服務。該方案幫助業務用戶在技術層面屏蔽了接入的復雜度問題，并把服務穩定性和能力提高到了大數據實時處理的要求。

實時數據總線

實時數據在由Magpie進行統一接入處理后，需要一個面向業務研發用戶的消息消費服務。我們基于Kafka的JDQ服務就是滿足這個需求的產品。

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

生產日志系統向最近機房內的JDQ系統的寫Topic發送業務日志消息，如遇機房故障，自動切換到可用機房的服務。

JDQ系統通過實時同步不同寫集群數據到每個機房的讀集群，實現每個機房都有一份完整的業務日志數據可供業務研發消費。

業務研發就近機房選擇讀集群進行消費，同時通過JDQ可以實現不同用戶的消費限速，***限度地保證集群服務的穩定可靠。

JDQ實時數據總線服務作為實時數據的中轉緩存服務，屏蔽了業務研發對不同數據源的接入難度，同時通過一系列的數據格式使用方式的標準化，打通了實時數據從接入到業務處理的傳輸環節，實現了京東內部實時數據通道的目標。

實時數據計算

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

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

該方案的特點如下：

• 通過Kubernetes實現Topology執行節點的容器化，資源隨用隨申請，提高資源利用率。
• 通過Kubernetes和二級調度的方案，把Topology調度邏輯放在Kubernetes層面和Topology內部，提高了調度的效率，避免了不同Topology之間的干擾。
• 心跳只在Timbus和Topology Master以及Topology Master和Worker之間進行，避免了傳統方案任務量大時的心跳壓力。

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

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

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

離線平臺

京東大數據離線平臺的整體架構如下圖：

平臺詳解

離線處理架構為數據存儲+數據緩存+數據處理+數據應用。

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

具體介紹

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

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

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

作者介紹

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