大搜車業務線衆多，對于資料的需求也各種各樣，本文将介紹其中之一的大搜車車商客戶實時資料需求，例如車商<code>pc|h5</code>端店鋪、車輛、分享等實時流量資料報表；随着資料量級的增長，目前資料量級在億級以上，原有以mysql提供查詢服務不再适合此場景，經過多方面的考慮，存儲最終選擇aliyun hbase，同時為了幾乎0成本的切換，采用phoenix on hbase sql中間件，它管理着hbase的二級索引并且它對sql的支援友好，本文也将介紹phoenix和hbase結合場景下的壓力測試。
實時資料來源為采集<code>pc|h5</code>端通路日志，通過flume收集這些日志，并按照業務場景需求，通過流試計算清洗、過濾、統計，使用phoenix api實時推送到hbase。
由于phoenix管理hbase二級索引，使用phoenix api推送資料索引表的也會被更新，這樣對于編碼成本很低。
原始的日志同時會通過flume 持久化至hdfs，友善離線計算資料分析。
統一通過資料網關提供業務查詢。
資料準備
使用phoenix提供的 psql.py腳本以csv檔案的方式導入。
考慮到是一次性的工作，本次壓測資料我采用phoenix提供的腳本的方式導入資料。
資料表、sql模闆、索引建立
模拟真實查詢sql模闆，sql查詢時間範圍為1個月的資料。
資料樣例的選擇：sql查詢時間範圍均為1個月，查詢條件由挑選出這1個月中按車商、銷售、車輛各個分組總條數在前300、300、300的資料按照模闆随機組合查詢。保證sql查詢都能命中資料，同時也排除每次都是量很大的資料。資料樣例見最後。測試表的資料量級在億行以上。
系統情況
ecs：4cpu8gb。
hbase節點資訊：master(4cpu8gb) core(4cpu8gb) 資料盤都為雲盤。
壓測分别從10 ~ 100并發之前壓測，以10為累加機關進行壓測，壓測時間為10分鐘。目前我們業務場景每秒并發數在50 ~ 80左右，高峰期高于80。
壓測的場景模拟線上的請求，查詢基本是都是單表比較複雜的聚合操作。
壓測結果分别從tps(每秒處理任務數)、rt(平均響應資料)兩個名額衡量。
以下挑選了并發數在100的時候應用gc、hbase系統負載情況。
應用gc情況 左邊為應用日志 右邊為gc(對應列分别為s0 s1 e o m ccs ygc ygct fgc fgct gct)，應用本身gc狀态良好。
hbase負載，從hbase 兩台資料節點負載看得出壓測的時候已經完全将hbase負載壓到極限之上，是以不難得出如果在系統資源充足的情況下，并發數相同的情況下，tps、rt遠遠比目前的結果要好。
進過壓力測試，以及上線了一段時間，apsaradb hbase phoenix能滿足我們的業務場景的使用。同時aliyun hbase支援橫向擴充以及靠譜的運維能力，也為後面支援更高的并發提供夯實的基礎。
資料樣例, ps:資料集經過特殊處理。
車商資料集
車輛資料集
銷售資料集