JRDW(JD Realtime Data Warehouse)是京東大數據部爲了解決公司越來越廣泛的實時業務需求，而推出的一整套技術解決方案，包括數據的實時接入、實時解析、實時傳輸、實時計算和實時查詢等技術環節。通過JRDW來解決實時業務開發中各環節的技術難點，在流程上統一業務開發需求，使業務方只專注於業務開發，不用過多關心技術上的問題，極大地降低了實時業務開發的技術難度。
源起
京東大數據部早在2012年就在公司內最早開始嘗試了實時相關業務需求的開發。早期通過對流量日誌的實時抓取和訂單消息的實時消費進行了流量和訂單數據的實時業務開發，並通過商家數據羅盤對外提供了服務。在2012到2013年期間，大數據部陸續開發了一系列的實時業務需求，比如支持搜索團隊使用實時技術實現了用戶個性化搜索，實時展現用戶搜索和購買行爲。在此期間，我們逐漸總結出了一些在實時方面的技術經驗，並發現了當時在解決實時業務開發時的一些難點。
2013年底，我們確立了要實現一整套實時業務開發的技術解決方案，來降低業務開發的難度，更好的支持業務需求。我們總結了在實時領域每個技術環節的經驗，結合京東實際業務情況，梳理出了JRDW整個產品線。
背景
運營場景
-實時感知業務運行情況，實時實現決策支持，比如調整運營策略，庫房排班等
營銷場景
-根據用戶位置、實時瀏覽軌跡、商品價格變化等實現精準推薦、廣告
-Top排行榜:銷量排行、熱度排行等。
優化離線數據倉庫數據抽取環節
-傳統 "1+1"模式的數據倉庫每天凌晨第一件事就是增量或全量抽取業務數據，隨着數據抽取任務的不斷增長，數據抽取時間成本不斷增長，離線計算啓動時間段被推遲。
實時數據平臺要解決的幾個問題
實時數據採集---數怎麼來
-數據要全
-延遲要低
實時數據存儲---數放在哪
-數據存儲統一
-方便使用、搞吞吐量
實時數據計算---數怎麼算
-及時性
-只是高複雜度場景
攻堅
我們首要解決的問題是找到一套標準的技術流程來解決實時數據接入的問題。我們在分析技術難度和業務需求後，決定首要解決的是當時公司內生產系統廣泛使用的SQL Server數據庫日誌的實時抓取和解析問題。我們在組成攻堅小組後，開始了SQL Server日誌的抓取和解析攻堅工作。由於開源界對SQL Server數據庫異構實時傳輸的需求幾乎沒有，我們不得不從SQL Server官方文檔和16進制日誌內容本身進行猜解來入手。經過一個多月的攻堅，在2014春節前，我們終於從官方API接口找到了日誌數據實時獲取的穩定可靠方式，並順利實現了對16進制日誌解碼的自主研發。由於MySQL日誌是開源標準，我們也順利自主研發實現了MySQL日誌的解析。其他公司內各種主流生產數據源，我們也都在14年實現了實時接入和解析，主要包括Oracle、業務應用日誌、JMQ等產品。今年我們也實現了HBase數據的實時接入。
做大數據大概要解決三個問題：數據接入、數據存儲和數據計算。
解決 實時接入 的問題，技術上我們支持基於數據庫日誌的模式，基於系統日誌文件的實時採集，也支持用戶自助把數據上報。如果要做到數據庫日誌接入需要解決如下幾個問題： 異構數據源適配（要支持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業務部等。
發展在解決數據的接入和解析的過程中，我們意識到搭建一個穩定可靠的實時任務運行平臺的重要性。通過早期我們對各種大數據開源平臺(Storm, Hadoop, HBase, Kafka等)的經驗，我們自主開發了一套實時任務的高可用調度平臺—Magpie。該平臺對我們不斷增長的實時任務提供了高可用保證，並標準化了實時任務的開發模式，保證了實時平臺更長遠的發展需求。該平臺目前運行了近千個實時任務，主要包括實時數據接入、解析、分發和各種實時需求任務。
感悟
兩三年來在大數據實時領域的研發經驗，讓我們感受到業務需求和技術發展的快速變化，讓我們在面對新的業務問題時,大多數時候可以在開源領域找到相關的經驗可以快速借鑑，在方案成熟時又可以結合我們的業務場景對技術方案進行提煉和昇華，在技術發展上走出了我們自己的路。
在實際工作中，找一個解決問題的辦法往往不是最難的，最難的是結合我們的情況找出符合長遠業務發展的技術解決路線圖。這就要求我們研發的小夥伴們時刻關注行業前沿技術發展，保持對技術追求永遠有一顆火熱的心。在這個過程中，我們京東技術人通過自己的技術實力解決了高要求的業務需求，實現了我們自身的技術價值。
來自：
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版本的到來，同時集羣規模越來 越大，你會發現要求的技術深度要求越來越高，也就是說對高端的技術人才需求越來越迫切。
爲了解決穩定性，剛開始我們用到了開源的產品，最終發現它還是有侷限性，因爲這些東西不是你開發的，所以針對一些關鍵點，我們會在適合的時間推出我們自主研發的產品，用來更大地提升對平臺的控制力。只有有更強的控制力，才能支撐更多的業務。