某游戏公司随着业务快速发展，用户行为日志快速增长，需要从海量的点击流日志和激活日志中挖掘数据的价值，比如广告转化率、激活率，每日安装用户成本等等。
业务挑战
原来使用GreenPlum做实时计算和统计分析。但是GreenPlum存在以下缺陷，难以应对业务的快速发展:
- GreenPlum架构难以应对日益复杂的计算任务；
- Greenplum的单表分区数目有限制，同时多级分区支持不够友好，不适用单表数据量比较大且需要永久保存的日志，如果单个分区表数据量比较大的时候查询性能无法满足业务性能需求；
- Greenplum扩容时由于数据要重分布会比较慢；
- Greenplum不适合处理非结构化的数据。
解决方案
在这样的背景下选择了阿里云HBase SQL服务(Phoenix)+ Spark服务构建实时计算和数据仓库解决方案，其中HBase SQL提供在线查询能力、Spark提供流式处理、复杂分析等能力来满足业务需求。下面是业务数据仓库架构图：
如上图梳理业务数据，对数据进行分层存储在HBase SQL(Phoenix)+Spark中：
- 操作数据层：手游客户端、用户中心、广告监测、游戏服务器等产生的原始日志；
- 数据明细层：”操作数据层”使用Spark Streaming等进行数据去噪、去重、字段规范后写入HBase SQL服务，也可以直接使用JDBC写入数据；
- 数据汇总层：”数据明细层”的数据可以定期使用Spark SQL(按天或者按小时)ETL(比如关联维表、过滤、聚合)后写入到”数据汇总层”。数据汇总层的数据供后续的复杂分析；
- 应用数据层：直接对外提供数据查询服务(基于HBase SQL服务)支撑上层大数据风控、广告推荐、海量数据精细化运营；“数据汇总层“的数据经过处理后会把结果数据写入到HBase SQL中对外提供查询服务。
价值
- 毫秒级识别拦截代充订单。HBase SQL(Phoenix) 高并发实时读写，TPS可达百万量级，并发十万量级，毫秒级简单查询；
- Spark优秀的计算能力。同样作业Spark基于列式存储Parquet的分析在数据量大的情况下比Greenplum集群有10倍的性能提升。支撑了广告转化率、激活率，安装用户成本，数据驱动精细化运营等业务计算需求；
- 一站式解决方案。Spark服务原生支持通过SQL读取HBase SQL(Phoenix)数据能力，具备列裁剪、谓词下推、分区裁剪等优化；高效的把HBase SQL在线库的数据ETL后归档到Spark数据仓库；
- 聚焦业务。全托管的Spark服务保证了作业运行的稳定性，释放运维人力，同时数据工作台降低了spark作业管理成本。用户也调研过ecs自建Hadoop生态，最终选择了HBase的Spark服务，包括以下原因：
| Spark服务 | 开源Hadoop生态(ECS自建) | |
| 服务模式 | 全托管，免运维，提供SLA保障，开箱即用 | 投入团队研发和运维服务，无SLA保障 |
| 产品功能 | 一站式解决方案，Spark深度融合HBase服务，精心调优，无需配置 | 功能繁杂，开源组件多，学习，配置调优成本高 |
| 性能 | Spark分析HBase的connector深度优化，内置connector，无需配置 | 社区版本，connector配置繁琐，无质量和SLA保障 |
| 易用性 | 专门的Spark的数据工作台、restful 服务、command line | 缺少企业级的数据工作台 |