彥偉：京東實時數據平臺架構設計與實現思路
以“數據安全、深度分析、行業應用”為主題的 2015中國大數據技術大會（Big Data Technology Conference 2015，BDTC 2015）于2015年12月10-12日在北京召開，京東大數據平臺研發負責人劉彥偉在互聯網大數據分論壇上發表了主題為“京東實時數據平臺的實現與應 用”的演講，并接受CSDN記者的專訪，詳細解讀京東構建實時數據平臺的經驗心得。
劉彥偉表示，京東大數據平臺要支持京東的訂單、商家、自營、倉儲、配送、售后、金融和O2O等全線業務，主要完成接入、存儲、計算三大基礎工作， 分為基于Hadoop的離線數據平臺JDW和基于kafka、Storm的實時數據平臺JRDW。采用開源技術構建，規模化的最大挑戰在于穩定性保障，需 要高端人才的支持和自主研發的更多投入，自研的產品能夠更大地提升對平臺的控制力，只有具備更強的控制力，才能支撐更多的業務。
京東大數據平臺研發概況
CSDN：首先請您自我介紹一下，您在開發方面的經歷和參與的項目？
劉彥偉： 我在2006年畢業以后，一直在做互聯網行業做研發工作，2010年加入京東，趕上了中國互聯網和京東以及大數據的快速發展。我所在的大數據業務部，從我 來的時候只有不到10個人，到現在成長為幾百人規模的團隊。我們一直致力于打造京東的基礎大數據平臺，即整個京東大數據的支撐系統，所有京東大數據系統都 基于這個平臺實現，從而為京東數據驅動的戰略做好支撐和服務。
CSDN：這個平臺都支撐哪些業務呢？
劉彥偉： 幾乎京東商城、京東金融、京東到家、京東智能上的大數據業務都在基于我們的大數據平臺開展大數據業務。
CSDN：能不能舉個例子，沒有這個平臺什么事情做不了，或者有了這個平臺什么事情可以做？
劉彥偉： 如果沒有這個基礎平臺，京東開發者要完成一個大數據業務，大數據基礎層面各個維度的事情，從大數據的接入、數據的存儲、數據的計算、到數據穩定性的保障 等，都需要自己做。但有了這個基礎的平臺，只要把業務搬到平臺上就可以了，這個過程會讓每個團隊實現大數據業務變得簡單。所以這個平臺對京東的價值，是實 現京東資源利用的最大化，包含人力資源、技術資源、硬件資源。我們的平臺化的戰略，是希望京東的數據開發者在平臺上自助完成開發工作，提升大數據業務推進 的效率。
實時數據平臺構建之路
CSDN：剛才在現場聽您演講的聽眾畢竟是少數，您能否概述一下演講的要點，最關鍵的是什么？
劉彥偉： 我來這個部門之后，最早是打造離線的數據平臺，從2014年開始基于實時大數據的需求我們開始打造適合京東特點的實時數據平臺。我演講的主題叫“京東實時數據平臺的實現和應用”，主要分為三部分：
- 整個京東的離線和實時大數據平臺的宏觀概念、設計思路，以及業務負載、集群規模等數據的分享，讓大家首先了解平臺的定位是在做大數據的平臺。
- 重點講解實時數據平臺的實現思路，分享京東在實時數據平臺的積累和方法論。
- 平臺的最大價值，舉一些案例，說明京東在哪些場景中用到了這個平臺，也是希望能夠給與會者一些借鑒。
CSDN：能否進一步介紹實時數據平臺的架構和設計思路？
劉彥偉： 做大數據大概要解決三個問題：數據接入、數據存儲和數據計算。
解決 實時接入 的問題，技術上我們支持基于數據庫日志的模式，基于系統日志文件的實時采集，也支持用戶自助把數據上報。如果要做到數據庫日志接入需要解決如下幾個問題： 異構數據源適配（要支持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、商家的滿意度或者用戶的滿意度等等。這就是京東在實時數據平臺的 架構和應用。
技術挑戰與團隊
CSDN：在構建實時平臺的過程中，哪些部分耗費您的團隊的精力最多？
劉彥偉 ：京東平臺采用比較成熟、比較常用的技術，更多的精力花費在工具或者平臺的穩定性保障上，尤其是當平臺到一定量級之后。比如管理一個Hadoop集群，在 10臺、100臺規模，和在2000臺、3000臺的規模，各方面的成本是不在一個量級的，對技術的要求也不在一個量級。
實時數據平臺也是這樣，我們快速把平臺搭建起來，隨著京東有越來越多的實時業務在平臺上運轉，我們必須要對工具或者產品有更深層次的理解，才能更 好地保證它的穩定性，更大地發揮它的價值。對于集群系統調優、配置修改等等，要有非常專業的能力才能控制，比方你對Storm的Nimbus有一個非常深 的理解你才能動它，要不然僅僅是使用的程度。這種工具產品的應用，在推出1.0版本的時候相對比較容易。隨著2.0、3.0版本的到來，同時集群規模越來 越大，你會發現要求的技術深度要求越來越高，也就是說對高端的技術人才需求越來越迫切。
為了解決穩定性，剛開始我們用到了開源的產品，最終發現它還是有局限性，因為這些東西不是你開發的，所以針對一些關鍵點，我們會在適合的時間推出我們自主研發的產品，用來更大地提升對平臺的控制力。只有有更強的控制力，才能支撐更多的業務。
CSDN：您提到的團隊現在有數百人，這些工程師怎么分布的，尤其我們有經驗的工程師需要什么樣的背景？
劉彥偉 ：我們需要各種人才分布更平衡，從更基礎的工作到高端的架構、核心問題的解決，各個層級都有需要。我們傾向的高端人才，第一要有比較好的學歷，這樣人才潛 質相對比較大，發展空間更廣；第二，最好在互聯網領域里有比較多的經驗，因為互聯網公司和傳統行業的研發和思維模式還是有較大差異。
未來技術路線
CSDN：您剛才提到隨著應用場景的變化、應用規模的增加，問題逐漸暴露，現在有沒有什么問題？
劉彥偉 ：其實問題經常會有，因為業務每天都會增長。但大部分常見問題已經在平臺的搭建和應用過程中逐漸被消滅。可能有一些隱藏的問題，在極個別的場景下才被發現，但我們已經渡過了經常滅火的階段。
達到京東現在的業務量級之后，京東未來的實時數據平臺應該是什么樣子，我們要思考未來實時大數據領域是什么樣子，需要朝哪個方向發展。我覺得和離 線數據平臺一樣，第一是集群的規模、集群的穩定性、集群利用率的最大化，以及工具越來越高的自動化程度。在這個基礎之上，業內現在有很多非常好的點子，不 斷會有類似的開源產品出現，解決不同的問題，我們同時需要有工程師和資源投入去借鑒這些解決方案，應用到我們的場景當中，保持平臺技術的先進性，以更好服 務京東的大數據業務。這個點就是我們要持續去學習，持續去創新。
CSDN：您剛才提到京東的實時平臺主要是基于Storm，這是比較早的實時平臺的技術。社區最近幾年有什么趨勢？是變得更熱鬧，還是向Spark轉變了？
劉彥偉： Storm跟Hive一樣有相對更加廣泛的應用基礎，在快速實現實時功能的時候，大家第一個會想到Storm，學習成本相對較低。當然業內目前已經有很多 同類的流失計算產品，比如說Spark Streaming等，我們也已經對它做過一些調研和嘗試。但它在成熟度、社區活躍度上目前跟Storm還是有一定的差距。我們也在保持對這些產品的持續 關注，有可能在不遠的將來我們會將它們補充到我們的實時數據平臺當中，以給我們的用戶更多的選擇。