HBase在打車出行的應用實踐

1、HBase在打車出行的應用實踐技術創(chuàng)新，變革未來背景介紹打車出行:提供一站式的出行服務，包括專車，快車，出租車，巴士，試駕，代駕，租車，共 享單車（OFO）等出行服務。HBase:Hadoop Database，是一個高可靠性、高性能、面向列、可伸縮的分布式存儲系 統(tǒng)HBase在出行業(yè)務上的的主要使用場景在線業(yè)務：服務于最終用戶，需要實時快速地響應用戶的操作對數據訪問的延時非常敏感，訪問趨向隨機業(yè)務如派單，動調，計費，支付，客服等離線業(yè)務：通常是定時的大批量處理任務，對一段時間內的數據進行處理并產出結果對任務完成的時間要求一般，處理邏輯復雜業(yè)務如天報表，安全分析，用戶行為分析，模型訓練等訪問H

2、Base的方式HBase Native APIThrift server (C+, PHP, Go，python) PhoenixPhoenix QueryserverMapReducejobSpark JobStreaming存放在HBase中的主要數據數據類型：1. 統(tǒng)計結果，報表數據運營情況，運力情況，收入等結果通常配合Phoenix進行SQL查詢數據量小，查詢靈活性高，延時要求一般2. 原始事實類數據訂單，司機，乘客等，GPS和日志等主要用作在線和離線數據供給數據量大，一致性和可用性要求高，延時要求高，實時寫入，單點或者批量查詢3. 生產中間數據和結果數據模型訓練所需數據等數據量大，可

3、用性和一致性要求一般，批量查詢對吞吐要求高4. 線上系統(tǒng)的備份數據歷史數據，查詢頻率不高，延時要求高場景一：訂單事件需要滿足三個需求：1. 在線查詢訂單的生命周期的各個狀態(tài)包括status，event_type，order_detail等信息主要查詢來自客服系統(tǒng)2. 在線歷史訂單詳情查詢同時由redis來存儲近期的訂單，當redis不可用，查詢會直接落到HBase3. 離線對訂單的狀態(tài)進行分析場景一：訂單事件寫入，滿足每秒10K事件讀取，滿足每秒1K事件時效性，5s以內數據可 用場景一：訂單事件1. 訂單狀態(tài)表Rowkey:reverse(order_id) + (MAX_LONG - tim

4、estamp)Columns: 該訂單各種狀態(tài)2. 歷史訂單表Rowkey: reversed(passenger_id | driver_id) + (MAX_LONG - timestamp)Columns: 用戶在時間范圍內的所有訂單場景二：司機乘客軌跡需求：1. 滿足實時或者準實時司機乘客的軌跡坐標查詢2. 滿足離線大規(guī)模的軌跡分析場景：1. 給定ID，查詢其歷史移動軌跡2. 給定時間和空間范圍，查詢符合條件的所有軌跡場景二：司機乘客軌跡使用坐標的業(yè)務：客服系統(tǒng)查詢某客戶的某個訂單的軌跡可視化系統(tǒng)查詢指定地理范圍的軌跡情況坐標半徑距離，坐標矩形運營系統(tǒng)地圖交通分析 質量控制場景二：司機

5、乘客軌跡坐標數據流水線：出租車軌跡專車軌跡快車軌跡客服可視化運營地圖HBas estorm場景二：司機乘客軌跡通過ID查詢軌跡Rowkey: IDTimestampColumn: 軌跡詳細信息提供java API給用戶使用通過地理范圍查找全部出現的軌跡需要建立空間索引表GeoHash分區(qū)Rowkey: Reversed_geohash + Timestamp + ID提供3種方式訪問小范圍或短時間數據：API一次性查詢， 延時小，成本低中等范圍或中等時間數據： 提供iterator/scanner批量查詢結果，延時較高，成本低大范圍或者長時間數據：提供Base mapper等離線查詢方法，延時

6、高，成本高場景三：ETAETA（預計到達時間）模型實時訓 練減少訓練時間，準實時生產多城市并行訓練增加靈活性減少人工干預造成的問題場景三：ETAETA流程：1. 原始數據匯集2. 清洗過濾3. 特征提取4. 存儲和持久化5. 模型訓練KafkaProcessorSpark streamingHBaseModel Trainin gHDF SETA Server訂單司機軌跡聚合后行程有效性信息特征數據分城市，時間的特征場景三：ETA模型訓練通過spark任務，每30分鐘對各個城市訓練一次模型訓練第一個階段，在5分鐘內，按照設定條件從HBase讀取所有城市數 據 模型訓練第二階段在25分鐘之內完成

7、ETA的計算Rowkey: Salting+CityId+Type0+Type1+Type2+TimestampColumns:Order, FeatureHBase中的數據會每隔一段時間持久化至HDFS中，供新模型測試和新特征 提取場景四：監(jiān)控工具Hadoop集群資源監(jiān)控和查詢將hdfs文件的信息和job history定期導入 HBase通過phoenix來做復雜交互查詢生產各種報表在前端展示場景四：監(jiān)控工具大量數據每日匯聚到HBase，用戶通過phoenix進行查 詢CollectorHBasePhoenixWe bfsimag ejobhistor y場景四：監(jiān)控工具該監(jiān)控工具每天將幾

8、億的路徑信息和當天執(zhí)行的任務歷史信息寫入HBaseRowkey: path / jobIdColumns: 多列的相關信息 用戶通過phoenix用SQL對數據統(tǒng)計 結果在秒級別返回場景四：監(jiān)控工具場景四：監(jiān)控工具場景四：監(jiān)控工具HBase多租戶的挑 戰(zhàn)用戶管理 項目管理 資源隔離性能優(yōu)化 成本控制基礎平臺管理者和用戶的戰(zhàn)斗用戶方面常見的問題：對使用資源情況不做分析數據量變化后不做調整項目上下線無計劃永遠想要最多的權限永遠想要最多的資源平臺管理者常見的問題：難以理解所有的用戶的業(yè)務對項目目前的狀態(tài)不清楚不能判斷用戶的需求是否合理出現問題定位排查時間長一個用戶的問題會影響其它用戶資源隔離與分配資

9、源共享還是獨占？資源利用率和服務質量的矛盾 多租戶共享 資源好處：資源利用率高，維護簡單壞處：用戶競爭資源，難以發(fā)現問題多租戶獨占資源好處：資源沖突減少，可用性高，細粒度維護壞處：業(yè)務低峰時段資源浪費，維護成本高資源隔離與分配共享與獨占共存按照業(yè)務的特性來選擇不同方案 共享資源：對訪問延時要求低訪問量小可用性要求低備份或者測試階段的數據獨占資源：延時，吞吐要求高高峰時段訪問量大可用性要求高在線業(yè)務資源分配的方法需求分析用戶需要給出預估的表大小，訪問方式和吞吐，表的屬性等需要給出均值和最大值，如果可能，給出未來幾個季度的預計增長情況上線流程開發(fā)集群-測試集群-線上集群HBase Regionse

10、rver Group分配按照需求和測試集群的狀況，計算出所需的regionserver個數通常會在額外給20 -30 的資源定期報告和賬單每個月自動檢測資源使用情況計算開銷發(fā)送給用戶HBaseRegionserver GroupHBASE-6721: RegionServer Group based Assignment通過namespace和RS group兩個功能對資源和權限進行隔離用戶的一個或者多個table可以分配在指定的regionserver列表中，這個列表稱為一 個RS group。一個HBase集群的計算資源被邏輯上分成了多個groups。對每個用戶按需分配group。HMas

11、te rRegionserver_0Regionserver_1Regionserver_2Regionserver_3RS Group 1RS Group2Table_0Table_1Table_ 2HBaseRegionserver Group使用RS group可以幫助我們：更容易的權限分配 (通過綁定group的namespace權 限)避免多用戶資源爭搶造成的不公平和性能問題可以對一個group進行單獨的優(yōu)化，hbase conf, gc等異構集群更好管理成本計算更加容易日常維護滾動升級可以增量進行，而且可以并行化成本控制資源分配考慮的因素：表的總大小讀寫吞吐訪問方式存活時長延時要求資源計算的方式：用戶預估測試環(huán)境評估線上定期監(jiān)控保證靈活合理地分配資源付費服務服務不是免費的！公司內部的一二級部門都會定期收到賬單，按照使用的資源付費。 付費的原因：降低公司的總成本減少平臺維護者的不必要工作鼓勵用戶優(yōu)化業(yè)務，用更少的資源做更多的事各個部門資源使用情況透明化付費服務計費標準：存儲使用計算使用計