分享嘉宾：王方晓腾讯游戏
编辑整理：贾志坤平顶山学院
出品平台：DataFunTalk
导读：营销活动作为游戏运营的一种重要手段，可以灵活快速的配合游戏各个运营节点的需要而推出，不受游戏版本节奏的影响。而面对数量众多的营销活动和不同的业务诉求，如何在海量日志中评价营销的效果是一个典型的多维分析问题，本次分享主要介绍腾讯游戏营销效果分析的一些概况以及ClickHouse的应用实践情况。通过实践表明，ClickHouse完美解决了查询瓶颈，20亿行以下的数据量级查询，90%可以在亚秒（1秒内）给到结果。
01业务背景营销活动在游戏之外配合热点事件和用户深入交流，是拉回流、促活跃的重要手段。那么，大量营销活动如何快速进行效果分析，得到准确的营销效果？
我们先来看一个具体的营销行为路径：
游戏玩家被营销活动投放的广告吸引过来，到营销活动的页面浏览，浏览的同时，如果玩家对营销活动感兴趣，会进行下一步的活动参与，参与达到条件后，会根据营销活动的规则，获得道具或者是装备的发放、领取，之后游戏玩家进入游戏。
对于上述场景，用户的每个行为阶段都会产生不同的指标，运营方往往有很多的分析诉求：
运营A：我的活动刚刚发布了，能不能看下现在实时的曝光和参与情况？
运营B：我的活动投入了一个新出的稀有道具，能看到这个道具的发放情况并提出用户包吗？
运营C：我在某投放平台买了广告位，能分析下这个广告位带给我的效果情况吗？
运营D：这次活动主要目的是拉回流，能看看我到底给游戏拉了多少回流吗？
运营E：这次活动是精细化挖掘推荐，能看看特定大R人群的参与情况吗？
以上的诉求总结下来就是多指标、多维度、时效性、去重用户包。
02技术选型及演进技术难点：面对众多的营销活动，每个营销活动周期都不一样，维度众多，在这个基础上还会有多种指标，如何在海量日志下做多周期、多维度的去重分析？我们来看看我们的技术选型及演进。
技术演进是每个公司都有的过程，一开始数据量较小，直接在DB数据库中就可以满足分析需求；随着数据规模越来越大，要借助hdfs、hive/spark的一些框架；再往后，随着实时性的要求越来越高，需要实时计算框架，对维度做预计算；随着维度爆炸，预计算就不太适用了，分析路径比较死，增加一个维度得改模型，这时就需要为OLAP专门量身打造分析型数据库。
①Mysql
优点：直接从业务DB拉取数据，比较简单
缺点：支持数据规模小，和业务之间有耦合
②HDFSHIVE/SPARK
基于DB分析的缺点，我们支持了大规模数据和业务做解耦，选用HDFSHIVE/SPARK的方案。我们统一了营销服务日志模型，当接到上报日志后，上传给HDFS。这个方案支持的数据量比较大，缺点是计算的速度比较慢，适用于T-1的计算效果。
③预计算KV
基于计算慢的问题，我们在日志流层面引入了实时计算框架，日志流经过Kafka，入到Storm，对预设的维度进行预计算，计算的结果存储到K-V数据库中，查询时去K-V库中查询。这里基于业务场景，想要快速的导出用户包，用文件数据库存储更方便，最大的缺点是新增维度要做一些处理，维度爆炸到一定程度，维护成本较高。
④OLAP
面对纬度爆炸问题，我们开始调研OLAP。
为什么选择有自身存储的OLAP?
HDFS数据是离线写入的
HDFS数据由严格的权限控制
需要快速拉取对应的用户包文件
大部分指标是基于单标运算出来
根据业务场景，对比上诉三个性能，最看重自有存储。因为在一张大宽表下，查询性能很重要。
1.ClickHouse介绍
ClickHouse是Yandex开源的一个用于实时数据分析的基于列存储的数据库，其处理数据的速度比传统方法快-0倍。
ClickHouse的性能超过了目前市场上可比的面向列的DBMS，每台服务器每秒可处理数亿至十亿行的数据。
OLAP的特点：
读多于写：不同于事务处理（OLTP）的场景，数据分析（OLAP）场景通常是将数据批量导入后，进行任意维度的灵活探索、BI工具洞察、报表制作等。
大宽表：读大量行但是少量列，结果集较小。在OLAP场景中，通常存在一张或是几张多列的大宽表，列数高达数百甚至数千列。对数据分析处理时，选择其中的少数几列作为维度列、其他少数几列作为指标列，然后对全表或某一个较大范围内的数据做聚合计算。这个过程会扫描大量的行数据，但是只用到了其中的少数列。而聚合计算的结果集相比于动辄数十亿的原始数据，也明显小得多。
数据批量写入：OLTP类业务数据不更新或少更新，对于延时要求更高，要避免让客户等待造成业务损失；而OLAP类业务，由于数据量非常大，通常更加
转载请注明：http://www.0431gb208.com/sjszlfa/6043.html
