淺析京東實時數據平臺：架構篇

數據倉庫的數據時效性，可以理解為數據從業務系統到達倉庫之后可用于分析的時間。小編記得剛畢業那會子給政府做數據倉庫，最重要的工作就是往數據庫錄數據，那時分析用的數據根本談不上時效性，如果非要加一個期限的話，最起碼是一周。。。

后來進入某精算行業，由于對風險識別的要求較高，核心數據的同步及分析工作要求在24個小時內完成，那時傳統數據倉庫已經開始發揮威力，但是由于異構性較嚴重，構建成本也較高，往往稍微出一點問題，時效性就溢出了，不過好歹比之前進步了不少，時效性是T+2。

再后來進入京東，數據倉庫里面的數據已經妥妥滴是昨天的數據了，當時業務線的老板們早上8點開早會的時候，前一天的經營數據分析報告已經通過郵件等方式發送出來，這時數據的時效性是T+1。

這種先將之前的數據存儲起來，然后批量加工或處理的方式，是典型的離線數據倉庫應用。這種模式當時已經能夠滿足大多數業務場景，但是隨著互聯網的不斷發展，信息更注重實時性，營銷的策略和方向往往在幾分鐘內發生改變。試想當交易數據以每分鐘幾百萬單的量級變化的時候，管理者如何能夠泰然處之的等到第二天才知道具體的交易情況。

因此，實時數據平臺就應運而生，互聯網公司尤其是電商企業，紛紛構建了符合本企業基礎結構和業務特點的實時數據平臺，今天小編就帶大家了解下京東的實時數據平臺。

開始之前，我們先普及普及兩個概念：離線計算、實時計算

離 線計算也叫批量計算或批處理計算，先將數據抽取、存放到本地存儲，數據一經抽取，就是靜態不變的，再進行后續的加工、分析。

實 時計算：顧名思義，就是指將數據的生產看做是一個持續的動態的數據流，我們預先定義好加工規則，當數據流過時按預先定義的規則進行加工分析方向。  

二者的區別如下：

通過以上的對比不難看出，實時計算最主要的一個應用場景就是，對數據處理的時效性要求較高，及時響應，秒級甚至毫秒級延遲。

大家都知道，對于數據的處理，主要分為3大階段：數據采集、數據處理、數據的可視化，實時數據的處理也不例外。京東實時數據平臺的架構是什么樣的呢？ 請看下圖：（數據流向自底向上）

數據采集

1 ）Magpie實時采集：自主研發，對線上生產數據庫壓力非常小，負責實時的監聽、采集數據庫binlog日志，再將數據解析、轉換統一格式、壓縮、寫入到JDQ－實時數據總線；

2 ）SDK實時上報：開放接口，用戶自定義格式，通過SDK主動實時上報數據到JDQ－實時數據總線；

數據總線

JDQ 實時數據總線：基于Kafka實現的高吞吐率分布式消息隊列，以Topic為單位存儲實時數據對象，是實時數據采集與下游數據使用者之間的橋梁；

1） 平臺提供SDK，通過鑒權認證，保障數據安全可靠

2） 限速處理，保障網絡負載均衡；

3） 集群讀寫分離，跨數據中心災備，保障集群穩定；

4） 產品化Client管理，通過web端查看客戶端運行情況，對消費積壓進行監控報警配置，提升用戶體驗

數據處理

1 ）JRC實時計算平臺：基于storm實現，使用JRC平臺的SDK，開發實時計算程序，將計算后的數據寫到存儲或落地到離線數據倉庫、集市；

2 ）其他實時消費程序：用戶基于平臺提供的SDK自主開發消費程序，將計算后的數據寫入到相關數據應用產品存儲；

3 ）準實時數據倉庫：為提高對業務的響應時效性，彌補T+1離線倉庫無法查詢當天數據的不足，大數據平臺推出準實時數據倉庫，目前可將線上生產數據還原成小時級別的Hive表或將用戶上報的數據按分鐘級別寫入HDFS文件；

數據可視化

實時數據的可視化按照不同的業務需求，酌情采用實時、離線的數據應用產品進行數據可視化、分析，例如：JA-京東分析師、數據領航員、商家數據羅盤等；

 

 

來自：http://mp.weixin.qq.com/s?__biz=MzA5Nzc2NDAxMg==&mid=2649864289&idx=1&sn=b7e3277b49f24451369dbb393e2ae228&chksm=889ecfa2bfe946b48281d7c3991b9efc8c0bf99815f45af12f0327dc779d5ca7095d92d517cc&scene=0