游戏投放素材是用视频还是图片？广告文案怎么写点击率会更高？哪个渠道效果更好？这是投放人员在每次投放计划实施前都会思考的问题。
通常，他们会凭借以往的投放经验和效果做出判断，或者通过所谓的「拍脑袋」来决定。「拍脑袋」的决策方式并没有什么问题，关键是后期是否有通过真实的用户数据对决策进行验证，完成「假设-验证-调优」的闭环。
不管是投放，还是研发、运营，游戏生命周期的每一个环节、每一个节点，都是由无数个决策组成的，数据分析能够大大提升做出正确决定的概率。尤其在游戏精品化时代来临之后，数据能够发挥的作用越来越大。
以下内容来源于数数科技资深数据分析师刘阳于 Cocos 开发者沙龙「成都站」的分享。
一个优秀的数据分析平台应该具备哪些特点？
目前有很多游戏公司开始自建数据分析平台，但面对游戏复杂的数据分析场景，这些自建数据库还是存在以下问题：
BI 大于分析。更侧重于报表展示的能力，分析角度比较固定和单一，无法实现更深入的洞察。
时效性低。在游戏行业很多场景中会要求小时级甚至是分钟级的决策调整，但实际上很多自建平台只能做到 T+1 的时效性。
资源消耗大。在很多自建平台中，每一次修改需求都需要数据工程师重新计算指标，造成内部资源的过度消耗。
取数成本高。在大部分自建数据分析平台中，往往需要两、三天甚至一周的时间，才能满足个性化的看数需求。尤其是在需求扎堆的情况下，数据工程团队的响应速度通常是比较慢的。
数据孤岛。在游戏业务中会有很多数据存在于外部平台，如广告平台、归因平台等。这些数据分散在不同的平台上，统一看数存在一定难度。
那么，一个好的数据分析平台该具备哪些特点？
首先，需要一个高度抽象的数据模型，如「用户表 + 事件表」模型。其中，事件表记录了用户的行为；用户表作为状态表，存储了用户的最新状态，如多少级、战力如何、金币多少等。用户表和事件表的结合可以更便捷地进行下钻分析。
除了用户表和事件表，其他的一些表也可以作为企业的数据资产沉淀下来，如用户的标签表，可以记录用户的活跃度、过去三十天的付费次数、付费总额等数据，在后续机器学习场景中起到特征库的作用。
另外，还需要一个动态的 Schema，以支持在大宽表中灵活地增加一些字段，以增加一些事件的记录维度等。
同时，一个稳健系统架构的设计还需要达成以下四个目标：
1.企业级，系统会面向处于不同生命周期、不同规模的企业，所以对其运行鲁棒性、以及并发性要求就会非常高。
2.海量数据，针对一些大 DAU 的产品，可能一天的事件量会达到百亿或者千亿级别，这就对海量数据的接收、存储、实时查询提出了很高的要求。
3.实时性，即希望数据从产生到流入到可查询的过程中延迟是非常短的，最好实现数据产生后秒级可查询和分析。
4.即席查询，所谓的 Ad Hoc 查询。实际分析中会存在很多探索性分析，即「查询分析-得出结果-基于结果提出假设-查询分析」的循环。这就要求每一个查询的性能非常高，并控制在秒级。
TA 系统技术架构解读
基于以上的特点和目标，数数科技研发的专业游戏大数据分析平台 Thinking Analytics （以下简称 TA 系统）依托专业、高效的底层架构，并结合事件分析、间隔分析、分群分析等分析模型，可一站式满足游戏团队不同角色用户的分析需求。
// TA 系统架构
TA 系统的整体架构包含了数据采集层、数据接入层、数据缓冲层、数据处理层和数据持久层。当数据在数据持久层保存下来之后，系统会通过 Trino 集群对数据进行实时的即席查询。
如图可知，系统采用了混合部署架构，在集群的每一个节点里都部署了对等的组件，如每个节点里面都有部署 Trino、Kafka 等。那么，为什么要采取这种方式？
这主要是利用了不同组件对系统资源诉求的不同。如 Trino 作为一个查询引擎，可能会消耗较多的 CPU 跟内存，Kafka 作为一个 IO bound 组件，可能会对网络 IO 跟磁盘 IO 要求比较高。混合部署可以最大化整个硬件资源的利用率。
同时，该系统架构还提供了弹性伸缩能力。由于游戏整个生命周期业务量波动可能会比较大，在推广期，集中导量会出现业务量的暴涨。当推广期过去，数据又会逐渐趋于平缓。所以，应对不同量级的 DAU 和事件量，就需要整个系统架构能够做到弹性的扩缩。
如游戏测试过后进入正式运营，TA 系统就可以从单机版扩展到 3 节点的集群，如果游戏将迎来更大的活动，又可以扩容到 5 个节点、7个节点，甚至更多的节点。当峰值过去还可以缩到 3 个节点，保证整个硬件资源没有任何浪费。
// TA 系统数据流转路径
数据采集支持多种 SDK，全面覆盖游戏行业数据采集场景，如客户端的 iOS、Android、App 第三方框架、小程序/小游戏 SDK 以及 Cocos SDK 等，服务端的 C、C#、Java、PHP 等。此外，还提供了基于 flume 的组件以及数数自研的 LogBus 采集工具，对海量服务端日志进行实时采集上报，也可通过 DataX 实现历史数据的导入。
数据采集进来之后，会到达数据接收层。接收层前端有一个负载均衡，用于保持整个系统的可用性。这个环节不会对数据有太多的处理，最大的核心的诉求就是满足高吞吐量。这里单个收数节点的吞吐性能可以达到 10 万条事件每秒。如果有更大量级的事件进来，只要横向扩展收数节点即可。同时，在接收层也实现了 exactly once 的语义，即数据不丢不重。
Kafka 下游的数据处理层，会对数据进行相当多的处理，如 ID mapping、IP 解析、元数据生成等。所以，数据被接收之后，就会被写入数据缓冲层，即 Kafka 消息队列。Kafka 在这里主要起到上下游组件的解耦作用。
数据在 ETL 层处理之后，就会写入到数据持久层。
TA 系统架构的应用
// 第三方数据集成
除了游戏内的用户行为数据之外，还有一些很重要的数据是零散落在一些第三方的平台上，如归因平台、媒体渠道、变现平台：
归因平台：如 Appsflyer、Adjust 等，可以获取用户来源渠道和广告等数据；
媒体渠道：如抖音、头条等，了解不同 Campaign 的消费和点击率等数据；
变现平台：获取 IAA 模式游戏的玩家广告点击情况及变现金额等。
TA 系统目前已经完成 40 多个第三方服务商数据的集成方案，实现归因数据、行为数据、变现数据的打通，市场人员能够在系统内实现快速的联合查询，获取广告转化、填充率、广告收入等数据，掌握高价值玩家的潜在渠道和广告偏好等。
// 云原生弹性方案
目前，数数整个底层架构是向着存算分离的架构方向演进，其中包含存储的弹性和计算的弹性，总体思路是期望充分利用云厂商高弹性的资源，帮助用户实现降本增效。如，将云对象存储 S3 纳入到整个大数据存储资源池中进行统一管理；或是将 EKS 容器服务纳入整个计算资源池统一管理。与云环境融为一体，提升整体集群使用体验。
存储弹性
上文提到的架构里可以看到，数据是分层存在 Kudu 和 HDFS 里的，但如果想要达成存储的弹性无上限该如何实现？可按照数据的冷热，进行分层存储，如将 7 天内的热点数据存储在 TA 的本地集群中，其他的历史数据全量迁移至各云厂商的对象存储上，如亚马逊的 S3、阿里的 OSS。
云存储的引入让整个存储层具有动态伸缩能力，同时节省 3 倍以上的平均存储成本。这种架构对于上层查询是完全无感知的，且不影响上层使用。
计算弹性
弹性计算架构将不同来源的查询请求按隔离配置进行计算负载隔离，同时对每个隔离环境支持负载的弹性伸缩。整个架构大概包含路由模块、集群安装、HPA 监控、弹性资源池几部分，能够根据业务峰值情况，分钟级别动态安装多套隔离计算环境，并且每个环境能做到自动伸缩。
以往由于请求高并发和大查询导致的查询卡顿、资源消耗快等情况，可通过这种架构得到有效缓解。在查询高峰时，可临时、自动化地调度更多资源供查询任务使用，并在空闲时回收资源。资源的申请和回收都是自动完成，无需人工参与，不仅提高了资源利用率、降低成本，还保障服务响应速度。
此外，该方案大大提升了架构的可扩展性和灵活性。只需要简单的配置部署，即可实现多 Trino 集群同时相互独立运行，应用的调度和分配都可以独立管控。相对于虚拟机的部署方式，在灵活性和可移植性上有比较大改善。
// 数据中台
TA 系统私有化的特点，也支持用户自主完成数据的二次开发，充分发挥 TA 系统的底层能力，打造企业的数据中台，如 TA 系统可以提供以下几个能力：
订阅 Kafka 数据总线，因为缓冲层的数据是全量的原始数据，当数据流转到缓冲层时，可以将数据从 Kafka 分出去，并按照自定义的 ETL 逻辑对数据进行处理，如给下游的机器学习这类场景提供基础数据。
基于 TA 系统中沉淀的底层数据，对接其他开源大数据框架。在数据进入数据持久层以后，可直接通过通用的计算引擎，如 Spark 集群直接查询数据持久层。因为数据持久层都是以开源的、标准的文件格式存储的，如 Hive metastore、 ORC 等存储格式，不存在任何数据锁死的情况。
提供丰富的 OpenApi 能力供业务系统调用，对数据持久层进行查询，如一些自建的 BI 系统就可以通过这套 Open API 来对数据进行各种查询和展示。
如果你想要了解秒级响应、高效、专业的 TA 系统，可点击「阅读原文」，即可体验众多爆款游戏的同款数据分析神器。