【先打一波小广告】阿里云AnalyticDB MySQL升级为湖仓一体架构，支持高吞吐离线处理和高性能在线分析，可无缝替换CDH/TDH/Databricks/Presto/Spark/Hive等。免费试用活动（5000ACU时+100GB存储）正在火热进行中，欢迎体验！免费试用链接：https://free.aliyun.com/?searchKey=AnalyticDB%20MySQL，群号：33600023146

客户介绍



杭州边锋网络技术有限公司是国内领先的休闲游戏开发商、运营商、发行商。20余年来，边锋网络一直是中国棋牌游戏的开拓者和变革者，本着“以用户驱动产品”的理念，用各不相同、各具特色的产品满足用户多元化的游戏需求。



边锋网络市场覆盖20余个省份，注册用户过亿，月活跃用户上千万，是国家级重点软件企业（一类）。公司大数据分析系统"反应堆"目前支持着包括雀神广东麻将、边锋斗地主、蜀山四川麻将、功夫川麻等10余款休闲游戏产品；



产品业务数据量50TB+，近9成数据需实现运营人员自助分析；该大数据系统是游戏开发、运营、迭代过程中的必备工具。面对行业上的激烈竞争，产品的深度数据分析、精细化运营、即时准确的决策等必不可少。

业务挑战

边锋的“反应堆”大数据平台主要支撑游戏业务的数据分析工作，针对玩家的数据进行上卷和下钻分析，以便内部相关同学保持对游戏玩家的高度关注，并能快速地定位异常问题，及时调整策略。整个大数据平台主要包括以下模块：



行为分析：分析游戏各项核心指标，包括事件分析、漏斗分析、留存分析、分布分析、路径分析等，观察玩家行为变化趋势，并根据用户、事件的不同属性（如设备、渠道等）等对指标进行多维度组合下钻分析。



自助看板：将用户行为分析的结果，由产运人员自助转化为看板，并自动更新；一站式实现指标新增到看板输出，无需数据开发/分析的同学额外介入。

用户分群&画像：基于玩家不同行为对用户进行分群，对指定用户进行针对性分析，并通过画像功能，让产运人员更深入了解用户特征。

基于上述场景，边锋产生了如下业务痛点：

●数据分析平台中会出现大量无法预计算的多维复杂分析，并且相关查询均需要快速响应;

●adhoc对集群算力的要求不固定，突发的分析需求可能需要短期的高算力支持；临时的大查询任务造成正常小查询的抖动;

●自建集群运维成本高，资源扩展难度大。



所以对边锋来说，需要为产运同学、数据开发/分析同学提供更高效的大数据分析平台，提高自助分析能力和决策效率。该平台需具备以下能力：

●高性能：支持实时的多维复杂查询、较大的分区数和数据规模，提供标准OLAP分析能力；

●灵活可扩展：支持资源灵活弹性扩缩容，按量计费，完美贴合业务负载变化；在业务分析诉求快速增长的同时，能为客户提供性价比更高的产品能力；

●低运维成本：云上成熟产品，提供完善的集群管理能力，客户不需要进行机器和资源的维护。

解决方案



云原生数据仓库AnalyticDB MySQL版（以下简称ADB）是融合数据库、大数据技术于一体的云原生企业级数据仓库服务。ADB新推出的湖仓版，可以帮助企业快速构建从湖到仓一体化技术架构，使用低成本离线处理能力完成数据的清洗加工，使用高性能在线分析能力完成数据的洞察探索



在边锋网络的游戏场景中，数据ADS层主要为产运同学提供高效灵活的即席查询能力，满足报表、看板等业务场景，并支持自定义多维度的数据实时查询，关注用户的行为变化，整体对复杂查询的灵活性和实时性诉求较大。同时通过该平台提升内部各角色的工作效率，降低沟通成本。



基于ADB湖仓版，边锋网络将大数据平台上的分析流程产品化，实现了90%以上的需求产品运同学可自助实现；

并在ADB湖仓版上实现了多数据源外表访问性能和分区表查询性能的提升；同时利用ADB的资源组隔离、分时弹性等能力，解决了大小查询互相影响、长期持有较多资源等问题；下面进行方案的详细介绍。



高性能：多数据源外表和内表联合加速查询



AnalyticDB MySQL支持OSS上（对象存储，类分布式存储系统）超大规模数据的分析，也支持高QPS实时读写。



在边锋网络大数据平台中，有针对用户表的实时更新和查询的需求；在传统的大数据平台上，在线更新和离线分析底层依赖多个系统，例如实时数据写入到MySQL，MySQL数据通过同步工具实时更新到分布式存储系统；日志数据通过同步工具同步到分布式文件系统；离线分析引擎通过分布式存储系统读取延迟的数据。



在ADB湖仓版中，可以通过MySQL语法查询实时数据，实现在一个SQL计算引擎内对在线实时数据和离线的外部数据关联查询，数据时效性得到极大的提升。



ADB湖仓版在SQL的执行过程做了大量的优化，包括核心算子优化、OSS外表分区映射等。

核心算子优化

向量化(Vectorization)优化的核心思想是一次处理一批数据，从而大幅提升数据处理速度。例如，针对某一列的数据，可以通过向量化技术每次处理1024条的加法或加法等。对于以列存为主的OLAP数据库，其优化更加有效。借助向量化的思想，我们对核心算子包括Join、AGG、Order等都做了向量化优化。下面以一个Join的例子说明。

select col1, col2 from table1 join table2 on table1.col1= table2.col1;

Join是数据库表之间的常见连接操作，HashJoin是一种高效的Join方法，它一般包含两个阶段，Build（构建）阶段与Probe（探测）阶段。实现时一般以小表作为Build端，用于构建内存HashTable；大表Probe端，作为驱动表。



传统的HashJoin实现方式：

首先Build表作为作为Build输入，一条一条构建HashTable。

此后，Probe表作为Probe输入，一条一条到HashTable中判断是否能连接。

优化后的HashJoin实现

首先根据Join Key分区， 每个分区对应一个HashTable，多HashTable之间并发处理。

其次Build表作为作为Build输入，一批一批构建HashTable。

此后，Probe表作为Probe输入，一批一批到HashTable中判断是否能连接。

我们不仅针对核心算子做了向量化优化，在向量化的基础之上，我们结合了Cache Prefetch对核心算子做了进一步的优化。



现代在CPU与内存之间，一般都有一到多层的Cache（高速缓存）匹配CPU与内存之间的处理速度鸿沟。但CPU访问Cache的数据缺失时，仍需要等待内存的数据搬运到Cache，这个时间一般需要几百个时钟周期，这期间CPU流水线很可能要暂停，代价较大。Cache Prefetch技术就是为了解决这个问题，什么是Cache Prefetch？CPU提供了Prefetch系列指令，用于将指定地址的内存预取到Cache。一般硬件会有一定的运行机制进行预取，也可以通过软件指令的方式实现预取。



经过理论分析和实验，我们得出开启预取有优化的场景：在随机访问，且计算的开销比较大时，通过适当的Prefetch能够将随机访问开销隐藏掉，基本上达到顺序访问的效果。在此基础上，我们对核心算子Join和Agg的实现开启了预取功能，性能有较大的提升。

分区投影



除了向量化和预取，AnalyticDB MySQL在外表的性能上也做了优化，比如分区投影；边锋网络利用该功能，针对部分数据量和分区非常大的OSS外表，有效加速查询性能。



某些场景中，有些表特别大，需要通过事件和年月日小时等维度把数据分区，减少查询扫描的数据量，这种情况下由于分区维度多，单表的分区数量会远远超过元数据能承受的范围，并且查询时需要获取所有分区，查询性能也将大受影响。但这种情况非常适合使用AnalyticDB MySQL开发的分区投影功能。



下图描述了分区投影的原理。

在分区投影中，分区值和分区位置是根据表的配置计算得出的，而非从元数据服务中获取。以下面SQL定义的分区投影表为例，定义分区列pt的类型为整型，范围是1到1200，通过计算可得出所有分区后，再经过过滤条件pt>100，能得出需要查询的分区是101~1200。由于分区可以直接计算得出，防止从元数据服务拉取大量分区数据，大大提升了查询效率。

create external table projection_table (  field1 int)partitioned by(  pt int)LOCATION 'oss://bucket_xxx/xxx/projection_test'tblproperties('projection.enabled'='true','projection.pt.type'='integer','projection.pt.range'='1, 1200')

分区列的类型除了integer类型，还支持枚举类型、时间类型和注入类型，能满足大部分的需求场景。通过分区投影，AnalyticDB MySQL支持的分区数理论上已经无上限，查询性能也得到大幅提升。

灵活弹性：在线离线资源物理隔离，并按需弹性

ADB湖仓版通过资源组实现对计算资源的按需划分，支持两种资源组类型，分别是Interactive型资源组（常驻型）和Job型资源组。



Interactive型资源组：该资源组中的资源属于预留资源，优点是可以提前进行规划和购买，适合实时读写、高QPS低RT的在线场景，用于执行XIHE MPP任务。

Job型资源组：该资源组中的资源可以包含预留和弹性资源，优点是可以完全使用弹性资源，按实际资源使用量计费，适合高吞吐低成本的离线场景，用于执行XIHE BSP和Spark任务。



基于上述不同资源组的特征，ADB提供分时和按需的能力来实现资源的灵活扩缩容。

针对Interactive型资源组，因为资源固定，在面临业务突增时集群负载变大，可能会出现查询变慢的现象。此时可以根据业务波峰波谷的特征，通过设置分时弹性计划来进行集群资源的扩缩容。比如白天运营和数据分析师等角色有大量的数据查询的诉求，属于集群负载的高峰期，晚上下班后集群负载降低。对于该场景，可以在预期的高峰时间段把集群扩容到较大规格，在业务低谷期集群恢复到较低规格，实现资源的高效利用，并降低资源成本。



分时弹性是通过明显的业务负载来提前设置资源弹性计划。在另一些场景下，比如业务无预期的突增或者某些大查询所需内存过大等，通过扩容或分时弹性解决的成本较高。所以ADB湖仓版支持Job级别的资源按需弹性，实现以SQL为单位申请计算资源，SQL执行结束后释放资源，做到真正的按需使用。针对Job型资源组，通过设置弹性资源的上限，即可实现在指定范围内的资源伸缩，完美贴合业务负载。



下图为不同查询提交到不同资源组的示例图，SQL在提交到前端节点时，如果指定Interactive型资源组，则查询在常驻计算节点中以XIHE MPP方式执行；如果指定Job型资源组，则查询在临时计算节点中以XIHE BSP方式执行。



在边锋的数据平台的行为分析场景中，基于Interactive资源实现运营、开发的交互式查询分析；提供分时弹性扩容白天资源，保证白天负载高峰期降低SQL延迟；对于个别内存消耗较大的查询，通过Job资源弹性实现查询的稳定执行。

业务价值

1、实时查询，提升效率：目前90%的行为分析需求已实现产品运营自助分析，可以实现实时查询，即时推导。例如一个经常出现的场景是，会议中遇到需要数据验证的疑问（非基础日常数据），需现场进行数据分析，秒级延迟就能获得数据的验证，从而进行下一轮推导，相对此前需小时级别的延迟与排队，数据分析与决策效率得到极大的提升；和旧架构相比，整体查询性能提升30%。

2、灵活弹性，降低成本：基于资源弹性轻松应对突增的业务，当前平台能很好的满足每日新增数据的分析，依靠现有架构即使日志量再增加一个量级，压力也只会表现在数据接收端；数据分析按事件实现物理隔离，在分析角度只与单事件的数据量相关；而且集群支持快速伸缩，即使游戏业务量陡增，数据瞬间爆炸的情况下，弹性扩缩容能分钟级完成，支持平台的平稳过渡。

3、托管架构，减少运维：基于阿里云的AnalyticDB MySQL构建大数据平台，不需要关注底层机器运维，集群运维，大大降低了整体维护成本，可以专注于业务功能开发，数据分析需求。