JRDW(JD Realtime Data Warehouse)是京東大資料部為了解決公司越來越廣泛的實時業務需求，而推出的一整套技術解決方案，包括資料的實時接入、實時解析、實時傳輸、實時計算和實時查詢等技術環節。通過JRDW來解決實時業務開發中各環節的技術難點，在流程上統一業務開發需求，使業務方只專注於業務開發，不用過多關心技術上的問題，極大地降低了實時業務開發的技術難度。
源起
京東大資料部早在2012年就在公司內最早開始嘗試了實時相關業務需求的開發。早期通過對流量日誌的實時抓取和訂單訊息的實時消費進行了流量和訂單資料的實時業務開發，並通過商家資料羅盤對外提供了服務。在2012到2013年期間，大資料部陸續開發了一系列的實時業務需求，比如支援搜尋團隊使用實時技術實現了使用者個性化搜尋，實時展現使用者搜尋和購買行為。在此期間，我們逐漸總結出了一些在實時方面的技術經驗，並發現了當時在解決實時業務開發時的一些難點。
2013年底，我們確立了要實現一整套實時業務開發的技術解決方案，來降低業務開發的難度，更好的支援業務需求。我們總結了在實時領域每個技術環節的經驗，結合京東實際業務情況，梳理出了JRDW整個產品線。

背景
運營場景
-實時感知業務執行情況，實時實現決策支援，比如調整運營策略，庫房排班等
營銷場景
-根據使用者位置、實時瀏覽軌跡、商品價格變化等實現精準推薦、廣告
-Top排行榜:銷量排行、熱度排行等。
優化離線資料倉庫資料抽取環節
-傳統 "1+1"模式的資料倉庫每天凌晨第一件事就是增量或全量抽取業務資料，隨著資料抽取任務的不斷增長，資料抽取時間成本不斷增長，離線計算啟動時間段被推遲。
實時資料平臺要解決的幾個問題
實時資料採集---數怎麼來
-資料要全
-延遲要低
實時資料儲存---數放在哪
-資料儲存統一
-方便使用、搞吞吐量
實時資料計算---數怎麼算
-及時性
-只是高複雜度場景
攻堅
我們首要解決的問題是找到一套標準的技術流程來解決實時資料接入的問題。我們在分析技術難度和業務需求後，決定首要解決的是當時公司內生產系統廣泛使用的SQL Server資料庫日誌的實時抓取和解析問題。我們在組成攻堅小組後，開始了SQL Server日誌的抓取和解析攻堅工作。

做大資料大概要解決三個問題：資料接入、資料儲存和資料計算。
解決 實時接入 的問題，技術上我們支援基於資料庫日誌的模式，基於系統日誌檔案的實時採集，也支援使用者自助把資料上報。如果要做到資料庫日誌接入需要解決如下幾個問題： 異構資料來源適配（要支援MySQL、SQLServer、Oracle、Hive、Hbase、檔案MongoDB等之間相互資料搬運），各種資料庫日誌 協議的解析，格式的統一，分表資料的合併（線上系統有一兩千張表，消費資料的人希望這是一份資料），敏感的資料（比如使用者的手機號和地址）的過濾等。此 外，作為自助的平臺，只有技術是不行的，京東還把這些技術包裝成一個產品——JDBUS，讓使用者通過JDBUS自助地完成更高效的接入。

實時儲存 ，我們有采取了一個業內常見的分散式訊息佇列，並針對京東特有的場景擴充套件了一些功能，包括跨機房的容災、消費資料的許可權控制、叢集複製等。為了解決穩定性，以及解決使用者管理的任務，我們也提供視覺化的產品。實時儲存的另外一個價值是實現一次接入多次消費。
實時計算 ，我們經過調研之後，選擇基於Storm打造這個平臺。這是參考了Spark Streaming和Storm的穩定性、社群活躍度以及它們在國內應用的現狀。Storm應該是最流行的產品，而且在穩定性、易用性上更適合京東的開發 者的思路，更匹配京東的現狀，未來的擴充套件和升級更方便。
基於Storm， 針對發現的問題，我們也做了自己的擴充套件 ，比如Storm的Nimbus本身是單點的，對於分散式來說這是很恐怖的事情，所以我們也擴充套件了Nimbus，實現了Nimbus的HA。同時 Nimbus作為Storm的核心排程器，在叢集資源使用率超過一定規模之後，Nimbus會變得越來越慢，任務的提交、終止可能從幾秒鐘慢到三五分鐘的 級別，我們也做了優化，讓Nimbus在高負載的情況下依然效率非常高，降到了秒級。平臺還必須要做到更友好的資源隔離，基於傳統的CGroup解決方 案，我們做了資源的隔離。平臺還必須要解決穩定性的問題，解決叢集的跨機房的容災的問題，我們實現了Storm程式包跨叢集的共享，有一套工具完成任務的 遷移，包含自動的模式和手工的模式。
對於實時計算平臺我們同樣在技術之上 封裝了一個視覺化的產品 方便使用者使用，以告別命令列操作方式的不便。基於京東的許可權體系，開發者可以在平臺上直接上傳任務，可以重啟、管理、檢視任務日誌、可以隨時啟動它、停止 它，包括申請程式包和版本控制，在這個過程當中會有服務目錄體系管理這套業務，有一套全新的審計流程，畢竟所有執行的業務都是線上業務，升級和變動是非常 嚴謹的事情。總的來說，我們用JDBUS解決實時資料接入的問題，用JDQ解決實時資料儲存問題，用JRC實時計算平臺解決實時計算的問題。資料基於這個 平臺算出來之後，最終應用在推薦系統、廣告系統、倉儲系統、配送系統，提升京東的GMA、商家的滿意度或者使用者的滿意度等等。這就是京東在實時資料平臺的 架構和應用。

京東平臺採用比較成熟、比較常用的技術，更多的精力花費在工具或者平臺的穩定性保障上，尤其是當平臺到一定量級之後。比如管理一個Hadoop叢集，在 10臺、100臺規模，和在2000臺、3000臺的規模，各方面的成本是不在一個量級的，對技術的要求也不在一個量級。實時資料平臺也是這樣，我們快速把平臺搭建起來，隨著京東有越來越多的實時業務在平臺上運轉，我們必須要對工具或者產品有更深層次的理解，才能更 好地保證它的穩定性，更大地發揮它的價值。對於集群系統調優、配置修改等等，要有非常專業的能力才能控制，比方你對Storm的Nimbus有一個非常深 的理解你才能動它，要不然僅僅是使用的程度。這種工具產品的應用，在推出1.0版本的時候相對比較容易。隨著2.0、3.0版本的到來，同時叢集規模越來 越大，你會發現要求的技術深度要求越來越高，也就是說對高階的技術人才需求越來越迫切。

為了解決穩定性，剛開始我們用到了開源的產品，最終發現它還是有侷限性，因為這些東西不是你開發的，所以針對一些關鍵點，我們會在適合的時間推出我們自主研發的產品，用來更大地提升對平臺的控制力。只有有更強的控制力，才能支撐更多的業務。同時，我們在14年也完成了實時資料傳輸平臺數據直通車、實時計算平臺JRC、資料傳輸工具JDQ、即席查詢工具JES的產品化工作。在14年下半年，業務方資料研發已經可以使用我們一整套JRDW實時資料產品來完成實時業務開發。目前我們的JRDW已經支援了公司內主要業務部門的開發需求，包括CMO、COO、雲平臺、無線業務部、京東到家、微信手Q業務部等。

感悟
兩三年來在大資料實時領域的研發經驗，讓我們感受到業務需求和技術發展的快速變化，讓我們在面對新的業務問題時,大多數時候可以在開源領域找到相關的經驗可以快速借鑑，在方案成熟時又可以結合我們的業務場景對技術方案進行提煉和昇華，在技術發展上走出了我們自己的路。
在實際工作中，找一個解決問題的辦法往往不是最難的，最難的是結合我們的情況找出符合長遠業務發展的技術解決路線圖。這就要求我們研發的小夥伴們時刻關注行業前沿技術發展，保持對技術追求永遠有一顆火熱的心。在這個過程中，我們京東技術人通過自己的技術實力解決了高要求的業務需求，實現了我們自身的技術價值。
來自：
http://www.36dsj.com/archives/32805
http://www.open-open.com/news/view/e98f84
http://www.wtoutiao.com/p/a66sMM.html  關鍵環節詳解 

實時儲存 ，我們有采取了一個業內常見的分散式訊息佇列，並針對京東特有的場景擴充套件了一些功能，包括跨機房的容災、消費資料的許可權控制、叢集複製等。為了解決穩定性，以及解決使用者管理的任務，我們也提供視覺化的產品。實時儲存的另外一個價值是實現一次接入多次消費。
實時計算 ，我們經過調研之後，選擇基於Storm打造這個平臺。這是參考了Spark Streaming和Storm的穩定性、社群活躍度以及它們在國內應用的現狀。Storm應該是最流行的產品，而且在穩定性、易用性上更適合京東的開發 者的思路，更匹配京東的現狀，未來的擴充套件和升級更方便。
基於Storm， 針對發現的問題，我們也做了自己的擴充套件 ，比如Storm的Nimbus本身是單點的，對於分散式來說這是很恐怖的事情，所以我們也擴充套件了Nimbus，實現了Nimbus的HA。同時 Nimbus作為Storm的核心排程器，在叢集資源使用率超過一定規模之後，Nimbus會變得越來越慢，任務的提交、終止可能從幾秒鐘慢到三五分鐘的 級別，我們也做了優化，讓Nimbus在高負載的情況下依然效率非常高，降到了秒級。平臺還必須要做到更友好的資源隔離，基於傳統的CGroup解決方 案，我們做了資源的隔離。平臺還必須要解決穩定性的問題，解決叢集的跨機房的容災的問題，我們實現了Storm程式包跨叢集的共享，有一套工具完成任務的 遷移，包含自動的模式和手工的模式。
對於實時計算平臺我們同樣在技術之上 封裝了一個視覺化的產品 方便使用者使用，以告別命令列操作方式的不便。基於京東的許可權體系，開發者可以在平臺上直接上傳任務，可以重啟、管理、檢視任務日誌、可以隨時啟動它、停止 它，包括申請程式包和版本控制，在這個過程當中會有服務目錄體系管理這套業務，有一套全新的審計流程，畢竟所有執行的業務都是線上業務，升級和變動是非常 嚴謹的事情。總的來說，我們用JDBUS解決實時資料接入的問題，用JDQ解決實時資料儲存問題，用JRC實時計算平臺解決實時計算的問題。資料基於這個 平臺算出來之後，最終應用在推薦系統、廣告系統、倉儲系統、配送系統，提升京東的GMA、商家的滿意度或者使用者的滿意度等等。這就是京東在實時資料平臺的 架構和應用。

京東平臺採用比較成熟、比較常用的技術，更多的精力花費在工具或者平臺的穩定性保障上，尤其是當平臺到一定量級之後。比如管理一個Hadoop叢集，在 10臺、100臺規模，和在2000臺、3000臺的規模，各方面的成本是不在一個量級的，對技術的要求也不在一個量級。
實時資料平臺也是這樣，我們快速把平臺搭建起來，隨著京東有越來越多的實時業務在平臺上運轉，我們必須要對工具或者產品有更深層次的理解，才能更 好地保證它的穩定性，更大地發揮它的價值。對於集群系統調優、配置修改等等，要有非常專業的能力才能控制，比方你對Storm的Nimbus有一個非常深 的理解你才能動它，要不然僅僅是使用的程度。這種工具產品的應用，在推出1.0版本的時候相對比較容易。隨著2.0、3.0版本的到來，同時叢集規模越來 越大，你會發現要求的技術深度要求越來越高，也就是說對高階的技術人才需求越來越迫切。
為了解決穩定性，剛開始我們用到了開源的產品，最終發現它還是有侷限性，因為這些東西不是你開發的，所以針對一些關鍵點，我們會在適合的時間推出我們自主研發的產品，用來更大地提升對平臺的控制力。只有有更強的控制力，才能支撐更多的業務。