1、攜程實時大數據平臺介紹技術創新，引領未來目錄緣起小試牛刀 成熟和完善新方向和新嘗試 不斷演進中的平臺我的介紹緣起攜程數據業務的特點：業務部門多，形態差別大：酒店 / 機票兩大BU，超過15個SBU和公共部門業務復雜，變化快之前，各個業務部門也有一些實時數據應用，但存在著諸多問題：技術上五花八門力量薄弱，應用的穩定性無法保證缺少周邊的配套設施數據和信息共享不順暢我的介紹平臺需求穩定可靠的平臺：業務只需要關心業務邏輯的實現，平臺維護交給專業同學完整的配套設施：測試環境，上線，監控，告警信息共享：數據共享，應用場景共享，互相啟發及時的服務：解決從開發，上線，維護整個過程中遇到的問題我的介紹目錄緣起小

2、試牛刀成熟和完善新方向和新嘗試 不斷演進中的平臺我的介紹技術選型消息隊列：實時處理平臺：主要出于穩定性的考慮，我們最后選擇Storm作為數據處理的平臺我的介紹Kafka簡介消息在一個Topic Partition中會按照 它發送的順序每個partition分布在集群的每臺服 務器上，可以為每個partition來設 置 多 個 Replication （Leader / Follower）1個topic的replication factor是N， 能容忍N-1臺機器Failed而沒有數據 損失我的介紹Storm簡介Spout：“水龍頭”數據接入單元Bolt：數據處理單元Storm的并發的三個層

3、次：WorkerExecutorTaskNimbus：Master節點Supervisor：Worker節點，用 來管理worker兩者之間通過ZK來做通訊我的介紹系統架構示意圖KafkaStormUBTServerBUClientsDBRedisHBASEES這樣遠遠不夠！我的介紹平臺治理 數據共享數據共享：數據共享的前提是用戶能夠清楚地知道可以使用的數據源的業務 的含義以及其中數據的Schema我們的解決方法是統一的Portal的站點和使用AVRO來定義數據的Schema；我們在Storm之上封裝了自己的API，來自動完成數據的反序列化用戶在 Portal 上傳 Schema系統生成POJ

4、O并將JAR加入Maven的 倉庫用戶在項 目中直接 添加POJO 的依賴我的介紹平臺治理 資源的控制Portal允許用戶對于作業設置，對每個Spout和Bolt設置并發相關的參數，通過審核后才能生效Storm之上封裝自己的API，屏蔽這些參數的設置我的介紹平臺治理 統一的管理Portal用戶對于作業的管理都能通過Portal上提供的功能完成我的介紹初期的業務接入在平臺搭建的同時，我們積極推進數據源和相關業務應用的接入數據源：UBT 攜程所有用戶的行為日志Pprobe- 應用的訪問日志 相關應用：基于UBT日志分析的實時報表基于Pprobe日志的實時反爬蟲分析程序我的介紹平臺搭建初期的經驗最初

5、盡可能地做好平臺治理的規劃：重要的設計和規劃都需要提前做好， 后續調整時間越晚，付出的成本越大系統只實現核心的功能：集中力量盡量早接入業務前提是核心功能基本穩定系統只有真正被用起來才會得到不斷的進化低優先級接入業務需要有一定的量：能夠幫助整個平臺更快地穩定下來積累技術和運維上的經驗我的介紹目錄緣起小試牛刀成熟和完善新方向和新嘗試 不斷演進中的平臺我的介紹日志相關系統的完善Storm UI：ES：Logstash - Kanban方便用戶進行查詢我的介紹Metrics基于Storm封裝的API中增加通用的埋點：消息從到達Kafka到開始被消費所花費的時間Topic / Task Level的一些

6、統計信息實現自定義的Metrics Consumer把信息輸出到攜程的Dashboard和Graphite（告警）我的介紹告警系統任何Storm內置的或是用戶自定義的Metrics都能夠配置 默認配置Topology的Fails數的告警我的介紹通用Spout和Bolt的開發開發了適配攜程通用MQ的Spout，使接入的數據源得到了進一步的擴展，更 多的業務數據能夠被Storm使用通用的Bolt，開發了3種針對于不同數據源的Bolt，方便用戶把數據輸出到外部存儲：Redis Bolt：仿照原生的實現，集成攜程封裝的Redis的客戶端HBASE Bolt：支持Kerberos的認證DB Bolt：集

7、成攜程的DAL框架我的介紹封裝API的版本迭代我們自己在Storm-core和Storm-kafka的基礎上封裝了自己的API：muise- coremuise-core在不斷地迭代和升級，添加各種各樣的小功能，并且修復各種 各樣的問題，隨著接入作業的變多，要推動業務進行升級變成一個很沉重 的負擔在muise-core 2.0版本我們把API相關的接口都整理了一下，之后的版本最大程度地不修改，然后推動業務全線升級了一遍（當時接入的業務不多）然后我們把muise-core作為標準的Jar放到每臺Supervisor Storm安裝目錄的lib文件夾下，每次有API升級的時候可以直接替換，然后重啟

8、supervisor進程非強制升級 等到用戶重啟topology生效強制升級 在和用戶確定影響后，重啟每個topology我的介紹大規模的業務接入業務方從原來的1個部門（框架）增加到酒店，機票，度假，團隊游，攻 略等BU以及搜索，風控，信息安全等技術部門，基本上覆蓋了攜程所有的 大部門應用類型也比初期要豐富地多，主要應用的類型和領域包括：實時數據報表業務數據的監控基于用戶實時行為的營銷風控和信息安全的應用我的介紹應用實例01我的介紹應用實例02功能：實時查看AB Testing的分流效果，有配置問題能夠及時發現每個分組的訂單數據的監控，如果訂單出現下降可以及時停止AB Testing我的介紹應

9、用實例03歷史偏好 + 實時偏好-推薦產品相似應用：攻略根據用戶實時的行為推送用戶感興趣的攻略團隊游根據用戶實時的訪問推送限時的優惠券酒店根據用戶實時的行為和訂單的情況給用戶推送營銷類的Push消息我的介紹我們遇到的坑我們使用的版本是0.9.4，在這個版本上，我們遇到過兩個偶發的問題：STORM-763：Nimbus已經將worker分配到其他的節點，但是其他worker的netty客戶端不連接新的worker應急處理：Kill掉這個worker的進程或是重啟相關的作業STORM-643：當failed list不為空時，并且一些offset已經超出了Range 范圍，KafkaUtils會不

10、斷重復地去取相關的message另外我們的用戶在使用Storm的過程中也遇到過一些問題，這邊簡單和大家 分享下：localOrShuffleGrouping的使用：大多數情況下推薦用戶使用；前提上下 游的Bolt數要批配；否則會出現下游的大多數Bolt沒有收到數據的情況Bolt中的成員變量都要是可以序列化的我的介紹經驗總結大量接入前，監控和告警的相關設施需要完善清晰的說明文檔 / Q & A能夠節約很多支持的時間把握接入的節奏全員客服控制同時接入的項目數授人以“漁”我的介紹目錄緣起小試牛刀 成熟和完善新方向和新嘗試不斷演進中的平臺我的介紹Stream CQLStream CQL (Stream

11、 Continuous Query Language)是華為開源的實時流處理的SQL引擎，它的做法是把StreamCQL - Storm TopologyStream CQL的語法和標準的SQL或是HQL很類似，它支持實時處理的窗口函數下面我們通過一個簡單的例子來“感受”下Stream CQL:從kafka中讀取數據，類型為ubt_action取出其中的page，type，action，category等字段然后每五秒鐘按照 page, type字段做一次聚合最后把結果寫到console中我的介紹Stream CQL例子SteamCQL:public class CtripKafkaSpout

12、 implements IRichSpout class ExtractBolt extends AbstractMuiseHermesBoltAutoAcked class ConsoleBolt extends CtripBaseBoltAutoAcked class AnalyseBolt extends CtripBaseBoltWithoutAutoAcked .public static void main(String args) CtripStormSubmitter.submitToCluster(conf, builder);create input stream kafk

13、a_avro (context pageString, context type String, action categoryString , action type String) serde HermesSerDe source HermesSourceOpproperties(avroclass=hermes.ubt.action.UserAction ,topic=ubt.action,groupid=json_hermes);create output stream console_field(page String, type String, target String , ac

14、tionType String, count Int) sink consoleoutput;insert into stream console_field select *,count(1) from kafka_avro range 5 seconds batch group by context page, context type；submit application ubt_cql_demo;Storm:我的介紹Stream CQL的嘗試和工作增加Redis，HBASE，HIVE,DB（小表，加載內存）作為Data Source增加HBASE，MySQL / SQL Server，

15、Redis作為數據輸出的Sink修正MultiInsert語句解析錯誤，并反饋到社區為where語句增加了In的功能支持從攜程的消息隊列Hermes中讀取數據我的介紹StreamingCQL的應用Streaming CQL作為Storm的補充目前的使用場景：能讓BI的同學自主地開發邏輯相對簡單的實時數據報表 和數據分析的應用實例：度假BU需要實時地統計每個用戶訪問“自由行”，“跟團游”，“半自助 游”產品的占比，進一步豐富用戶畫像的數據數據流：UBT的數據Data Source：使用Hive中的product的維度表輸出：Hbase70左右的代碼就能完成整個功能，縮短了開發時間我的介紹JSto

16、rmJStorm是阿里開源的實時計算引擎，API上兼容Storm，內核使用Java編寫去年它被Storm項目正式接納，之后會逐步融合到Storm之中去目前與Storm比較，JStorm在計算性能上，資源的 隔離上有一定優勢；他也支持與Twitter Heron類 似的Back pressure的機制，能更好地應對消息擁 塞的情況阿里的JStorm的團隊非常Open，也非常 Professional，幫我們解決了不少問題，互相之間 的合作也非常愉快！我的介紹Jstorm的嘗試和經驗我們的目標：把攜程現有的實時應用從Storm上遷到JStorm上去目前使用的版本：2.1.1經驗分享：1. 與Kaf

17、ka集成：在Jstorm中，Spout的實現有兩種不同的方式：Multi Thread（nextTuple，ack & fail方法在不同的進程中調用）和Single Thread， 原生的Storm的Kafka Spout需要使用Single Thread的方式運行修復了Single Thread模式的1個問題（新版本已經修復）2. Metrics：Jstorm不支持Storm的Metrics Consumer的機制，Jstorm有一套新的 Metrics的API，感興趣的同學可以參看AsmMetrics類，以及子類適配了Kafka Spout和我們Storm的API中的Metrics使用MetricsUploader的功能實現了數據寫入Dashboard和Graphite的功能我的介紹目錄緣起小試牛刀成熟和完善新方向和新嘗試不斷演進中的平臺我的介紹技術架構的總結APIStorm ClusterKafka ClusterDashboardInfrastructureGraphiteESHermes Producer APIHermes Consumer APIMuise Storm APIHermes KafkaServiceMuise PortalServiceHermes Meta