大搜车业务线众多，对于数据的需求也各种各样，本文将介绍其中之一的大搜车车商客户实时数据需求，例如车商<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:数据集经过特殊处理。
车商数据集
车辆数据集
销售数据集