亿级下ApsaraDB HBase Phoenix秒级内RT在大搜车实践

  1. 云栖社区>
  2. 博客>
  3. 正文

亿级下ApsaraDB HBase Phoenix秒级内RT在大搜车实践

委小光 2017-09-11 11:15:50 浏览4042
展开阅读全文

一、前言

大搜车业务线众多,对于数据的需求也各种各样,本文将介绍其中之一的大搜车车商客户实时数据需求,例如车商PC|H5端店铺、车辆、分享等实时流量数据报表;随着数据量级的增长,目前数据量级在亿级以上,原有以mysql提供查询服务不再适合此场景,经过多方面的考虑,存储最终选择Aliyun HBase,同时为了几乎0成本的切换,采用Phoenix On HBase Sql中间件,它管理着HBase的二级索引并且它对sql的支持友好,本文也将介绍Phoenix和HBase结合场景下的压力测试。

二、数据系统架构

  • 实时数据来源为采集PC|H5端访问日志,通过Flume收集这些日志,并按照业务场景需求,通过流试计算清洗、过滤、统计,使用Phoenix api实时推送到HBase。
  • 由于Phoenix管理HBase二级索引,使用Phoenix api推送数据索引表的也会被更新,这样对于编码成本很低。
  • 原始的日志同时会通过Flume 持久化至HDFS,方便离线计算数据分析。
  • 统一通过数据网关提供业务查询。

    *架构图:*
    
    ![图片](https://raw.githubusercontent.com/Danier-Evens/Markdown_Image/master/image/%E7%B3%BB%E7%BB%9F%E6%9E%B6%E6%9E%84.png)
    

三、压测

  • 数据准备

    • 使用阿里云数据集成 服务将mysql数据导入至PHoenix,不过它使用的HBase原生api导入,所以索引数据需要在导完之后再重建。
    • 使用MapReduce的方式,这种更友好,直接导出为HFile文件,不必走HBase API,这样会减少集群的负载以及网络消耗,速度更快。但使用的是阿里云HBase,依赖的Hadoop集群不对外。
    • 使用Phoenix提供的 psql.py脚本以csv文件的方式导入。

    考虑到是一次性的工作,本次压测数据我采用Phoenix提供的脚本的方式导入数据。

  • 数据表、sql模板、索引建立

    • 表建立 参考

      CREATE TABLE FLOW.SHOP_DATA_BY_SALER_CAR_V2 (
          PK varchar primary key,
          INFO.DATE_STR BIGINT,
          INFO.STORE_ID VARCHAR,
          INFO.CAR_ID VARCHAR,
          INFO.SELLER_ID VARCHAR,
          INFO.SHARE_PV INTEGER,
          INFO.SHARE_UV INTEGER,
          INFO.FLOW_PV INTEGER,
          INFO.FLOW_UV INTEGER,
          INFO.CALL_PV INTEGER,
          INFO.CALL_UV INTEGER,
          INFO.APPOINT_PV INTEGER,
          INFO.APPOINT_UV INTEGER,
          INFO.LAST_UPDATE_TIME DATE
      ) COMPRESSION='SNAPPY',DATA_BLOCK_ENCODING='DIFF';
    • 模拟真实查询sql模板,sql查询时间范围为1个月的数据。

      SELECT info.seller_id,
          sum(info.share_pv) as sum_share_pv,
          sum(info.flow_pv) as sum_flow_pv,
          sum(info.call_pv) as sum_call_pv,
          sum(info.appoint_pv) as sum_appoint_pv
      FROM FLOW.SHOP_DATA_BY_SALER_CAR_V2
      WHERE info.store_id = '%s'
          AND info.date >= %d
          AND info.date <= %d
      GROUP BY info.seller_id
      ORDER BY sum_share_pv DESC
      SELECT sum(info.share_pv) as sum_share_pv,
          sum(info.flow_pv) as sum_flow_pv,
          sum(info.call_pv) as sum_call_pv,
          sum(info.appoint_pv) as sum_appoint_pv
      FROM FLOW.SHOP_DATA_BY_SALER_CAR_V2
      WHERE info.store_id = '%s'
          AND info.date >= %d 
          AND info.date <=  %d
      SELECT sum(info.share_pv) as sum_share_pv,
          sum(info.flow_pv) as sum_flow_pv,
          sum(info.call_pv) as sum_call_pv,
          sum(info.appoint_pv) as sum_appoint_pv
      FROM FLOW.SHOP_DATA_BY_SALER_CAR_V2
      WHERE info.store_id = '%s'
          AND info.date >= %d 
          AND info.date <=  %d
          AND info.seller_id = '%s'
      SELECT info.seller_id,
          sum(info.share_pv) sum_share_pv,
          sum(info.flow_pv) sum_flow_pv
      FROM FLOW.SHOP_DATA_BY_SALER_CAR_V2
      WHERE info.car_id = '%s' 
          AND info.date >= %d 
          AND info.date <=  %d 
          AND info.share_pv <> 0
      ORDER BY info.seller_id
    • 针对sql模板场景,建立索引表,索引类为覆盖索引 Secondary Indexing

         CREATE INDEX SHOP_DATA_BY_SALER_CAR_V2_INDEX
         ON FLOW.SHOP_DATA_BY_SALER_CAR_V2 (INFO.STORE_ID, INFO.DATE_STR)
         INCLUDE (INFO.SELLER_ID, INFO.CAR_ID, INFO.SHARE_PV, INFO.FLOW_PV, INFO.CALL_PV, INFO.APPOINT_PV)
         COMPRESSION='SNAPPY',DATA_BLOCK_ENCODING='DIFF'
         CREATE INDEX SHOP_DATA_BY_SALER_CAR_V2_INDEX1
         ON FLOW.SHOP_DATA_BY_SALER_CAR_V2 (INFO.CAR_ID, INFO.DATE_STR, INFO.SHARE_PV)
         INCLUDE (INFO.SELLER_ID, INFO.FLOW_PV, INFO.CALL_PV, INFO.APPOINT_PV)
         COMPRESSION='SNAPPY',DATA_BLOCK_ENCODING='DIFF'
    • 数据样例的选择:sql查询时间范围均为1个月,查询条件由挑选出这1个月中按车商、销售、车辆各个分组总条数在前300、300、300的数据按照模板随机组合查询。保证sql查询都能命中数据,同时也排除每次都是量很大的数据。数据样例见最后。测试表的数据量级在亿行以上。

  • 系统情况

    • ECS:4CPU8GB。
    • HBase节点信息:Master(4CPU8GB) Core(4CPU8GB) 数据盘都为云盘。
  • 压测分别从10 ~ 100并发之前压测,以10为累加单位进行压测,压测时间为10分钟。目前我们业务场景每秒并发数在50 ~ 80左右,高峰期高于80。

    • 压测的场景模拟线上的请求,查询基本是都是单表比较复杂的聚合操作。
    • 压测结果分别从TPS(每秒处理任务数)、RT(平均响应数据)两个指标衡量。
      image
    • 以下挑选了并发数在100的时候应用GC、HBase系统负载情况。

      • 应用GC情况 左边为应用日志 右边为GC(对应列分别为S0 S1 E O M CCS YGC YGCT FGC FGCT GCT),应用本身GC状态良好。
        GC
      • HBase负载,从HBase 两台数据节点负载看得出压测的时候已经完全将HBase负载压到极限之上,所以不难得出如果在系统资源充足的情况下,并发数相同的情况下,TPS、RT远远比目前的结果要好
        GC

四、写在最后

  • 进过压力测试,以及上线了一段时间,ApsaraDB HBase Phoenix能满足我们的业务场景的使用。同时Aliyun HBase支持横向扩展以及靠谱的运维能力,也为后面支持更高的并发提供夯实的基础。
  • 结合我们业务场景,基本都是单表的复杂聚合操作,对IO消耗比较大,因此最近迁移了HBase,把云盘换成了SSD盘。提高IO的能力。迁移工具 同时期待Aliyun HBase的数据迁移能更加完善。
  • 数据样例, ps:数据集经过特殊处理。

    • 车商数据集

      010140548,001106040,001109847,001104443,001106241,001101049,001110943,001131047,001119549,001121749,001102043,001142748,001118444,001108248,001111340,001108240,001151942 .......
    • 车辆数据集

      Cg6f7hXsfkqffgWHsafk,adfu3fMhZsfkDffBFsa4kNadf,fcfchesfkdfg15saakcadf6d487b834e2b8eb81217c,72f8hOsfkRffgdIsaQkMadf,75fah8sfk3fg8fsa4kdadf7c4e03b9e46a864b858b6,59f0hesfk5ffg96sadk8adf934d72b4f8119f0e38acb .......
    • 销售数据集

      11234,11791,18782,13298,15889,13069,13213,18231,18988,18346,18946,13137,15051,15320,15680,15066,15512,13585,15555,13235,18195,13888,13363,13921,17777,18088,13188,15708 .....

网友评论

登录后评论
0/500
评论
委小光
+ 关注