ApacheDoris在网易互娱的应用实

SEO百度优化求职微信群 http://pf.39.net/bdfyy/bdfjc/180627/6359009.html

一、背景

随着公司游戏业务的高速发展,越来越多的分析需求涌现,例如:各类游戏用户行为分析、商业智能分析、数仓报表等。这些场景的数据体量都较大,对数据分析平台提出了很高的要求。为了解决实时分析的时效性,同时又能保证数据快速写入和查询,需要一个合适的数据查询引擎来补充我们原有的架构体系。

经过大量调研,ApacheDoris比较契合网易互娱游戏数据中心的整体要求,ApacheDoris具备以下 特性:

MPP架构+高效列式存储引擎

高性能、高可用、高弹性

标准ANSISQL支持

支持多表Join

支持MySQL协议

支持预聚合

支持物化视图

支持预聚合结果自动更新

支持数据高效的批量导入、实时导入

支持数据的实时更新

支持高并发查询

周边生态完善

网易互娱于年4月引入了ApacheDoris产品,目前已经发展为多个集群,服务数十个业务,如游戏舆情分析,实时日活看板、用户事件分析、留存分析、漏斗分析、分布分析等。当前OLAP平台与数仓体系融合的架构如下图所示:

图1.OLAP平台与数仓体系融合架构二、ApacheDoris简介

ApacheDoris是百度开源的MPP分析型数据库产品,不仅能够在亚秒级响应时间即可获得查询结果,有效的支持实时数据分析,而且支持PB级别的超大数据集。相较于其他业界比较火的OLAP数据库系统,Doris的分布式架构非常简洁,只有FE、BE两个服务,整体运行不依赖任何第三方系统,支持弹性伸缩,对于业务线部署运维到使用都非常友好。目前国内社区火热,也有腾讯、字节跳动、美团、小米等大厂在使用。

图2.ApacheDoris架构2.1FE

FE的主要作用将SQL语句转换成BE能够认识的Fragment,如果把BE集群当成一个分布式的线程池的话,那么Fragment就是线程池中的Task。从SQL文本到分布式物理执行计划,FE的主要工作需要经过以下几个步骤:

SQLParse:将SQL文本转换成一个AST(抽象语法树)

SQLAnalyze:基于AST进行语法和语义分析

SQLLogicalPlan:将AST转换成逻辑计划

SQLOptimize:基于关系代数,统计信息,Cost模型对逻辑计划进行重写,转换,基于Cost选出成本 的物理执行计划

生成PlanFragment:将Optimizer选择的物理执行计划转换为BE可以直接执行的PlanFragment

执行计划的调度

图3.FE执行SQL流程2.2BE

BE是Doris的后端节点,负责数据存储以及SQL计算执行等工作。

BE节点都是完全对等的,FE按照一定策略将数据分配到对应的BE节点。在数据导入时,数据会直接写入到BE节点,不会通过FE中转,BE负责将导入数据写成对应的格式以及生成相关索引。在执行SQL计算时,一条SQL语句首先会按照具体的语义规划成逻辑执行单元,然后再按照数据的分布情况拆分成具体的物理执行单元。物理执行单元会在数据存储的节点上进行执行,这样可以避免数据的传输与拷贝,从而能够得到 的查询性能。

图4.BE执行SQL流程三、集群治理3.1Compaction调优-Tablet治理

在网易互娱引入ApacheDoris初期,业务用户在测试过程中发现建表时指定bucket数越大,查询速度越快,导致了用户在新建表和分区时统一将bucket数指定为64。随着导入的数据越来越多,问题也开始暴露了出来:业务陆续反馈alter分区失败、修改字段长度失败等问题。经过SA排查发现这些失败都是超时导致,同时发现业务操作的表数据量仅2G,replica数却达到了:

图5.业务表数据量及replica数

更进一步地,为了将问题彻底暴露出来,对该集群进行全量统计发现60T的数据量达到了接近万的tablet数,tablet数过多会导致以下几个问题:

用户建分区,建表,修改字段等元数据操作耗时长,甚至会超时失败;

元数据都放在FE内存中,GC压力较大,同时FE在进行Checkpoint操作时由于元数据占用内存翻倍,极易出现OOM的风险;

bucket数是查询吞吐和查询并发的一种权衡,为了集群的健康发展,旧数据必须进行tablet治理,新的建表规范需建立起来。

3.1.1治理目标tablet数量=分区数*副本数*bucket数

从上面的计算公式可知,在用户的场景下,前两者都是固定不变的,决定tablet数大小的只有bucket数。

鉴于该集群目前数据量大小为60T左右,结合对bucket的更进一步理解以及当前集群实际情况,治理的目标和长期控制的目标定为:

1.tablet数:w-w

2.tablet增长量:/TB

3.1.2实施计划

(1)对于现存的表

扫描集群内所有的表,以分区粒度输出一份完整的数据统计给业务方,并根据每张表的实际情况附上修改建议;

制定治理计划按照由高收益到低收益,优先处理最不合理的库,将元数据管理压力降下来,再逐步按照计划治理所有的库。

因为Doris目前不支持按分区级别展示整个库下的数据情况,因此单独开发一个程序进行扫描,伪代码如下所示:

con=DriverManager.getConnection()fordbindb_list:con.execute("use%s".format(db)))fortableintable_list:con.execute("showcreatetable%s".format(table))#获取 个分区的bukcet数result.append(regrex_extract_bucket(con.next()))con.execute("showpartitionsfrom%s".format(table))result.append(regrex_extract_bucket(con.next()))#获取除 个分区的bukcet数write_result_to_excel(result)

截取部分写入Excel的数据,统计格式如下:

图6.Doris集群分区粒度数据统计及治理期望

结合Excel 的透视表功能,即可轻松获取表粒度、以及库粒度下的治理建议统计表,最终治理目标也是依据计算出来的总期望分区数得到。以库粒度做统计截取部分数据如下所示:

图7.集群库粒度数据统计及治理期望

根据统计表得到的信息,优先选择高收益率的库进行治理(上图中已标绿),对表的治理方式有以下两种方式:

种方式:数据重插

#鉴于Doris对所有已存在分区的bucket数无法修改的情况,使用新建表重插的方式进行,步骤为:1.createtablexxx_bakforpartitioninpartition_range:if(partition.data!=null)2.altertablexxx_bakaddpartitionifnotexistsdatebucket[动态值];//动态值根据每一个分区实际的数据量计算传入3.insertintoxxx_bakselect*fromxxxwheredt=date4.检查新的xxx数据量,分区数是否正确;//重点!!5.ALTERTABLExxxRENAMExxx_old;6.ALTERTABLExxx_bakRENAMExxx;7.dropxxx_old。-----方案说明:根据优先顺序对一张待治理的表进行步骤1和步骤2,第3步使用串行的方式提交执行(减少资源占用和出错的可能性)。执行完后根据数据验证方案对数据进行验证,确保无误后进行5,6操作。特别说明:因为迁移过程中仍然会有数据写入旧表,因此迁移过程中有两个内容要确保:1、在重插 的分区过程中,业务控制确保该时间段内没有数据流入;2、一张表的1-6步骤在下一次写入数据前完成。3、如未完成则单独标记,在当天结束写入数据和下次写入数据前完成该分区的重插。根据业务反馈大部分load分区操作都能在1分钟完成,所以重插的时间窗口是很大的。

使用该种方式对三种类型的表进行测试,结果如下:

小表测试21.5Mtablets

中表测试19Gtablets

大表测试Gtablets

第二种方式:数据重Load

#对于表数据在Hive数据还存在的,该方式更为简单1.droppartition2.createpartition3.loaddatafromHive

(2)对于未来新增表

对于业务方,业务在导入数据时增加判断逻辑,根据Hive表数据情况指定bucket数,建分区规范如下:

0-10M的数据量:1

10-50M的数据量:2

50M-2G的数据量:4

2-5G的数据量:8

5-25G的数据量:16

25-50G的数据量:32

超过50G的数据量:64

对于服务方,新增以下措施:

监控页面新增tablet_per_TB_data指标,及时检测到异常建表建分区的情况。

定期(如每月)统计哪些表还存在tablet优化的空间,提供给业务,并敦促改进。

3.1.3治理收益

经过一段时间的治理,tablet数显著下降:由接近万下降到多万,业务反馈的元数据操作相关问题明显减少:

图8.tablet监控

FE的堆内存占用明显下降,执行Checkpoint时,元数据会在内存中复制一份,表现在监控图上是一段尖峰,治理后尖峰变得更缓和,大大提升了FE的稳定性:

图9.FEJVMHeapStat3.1.4治理说明

由于Hive中数据存储格式与Doris数据存储格式不同,因此在数据量判定方面存在差别,会导致SA在扫描分区tablet数时得到部分治理错误的结论,总体来说实际值会比预期值高,以某库为例:

图10.某库分区治理后验证结果3.2Compaction调优-StreamLoad治理3.2.1问题描述

业务使用的某个Doris集群经常出现BE异常退出的情况,影响实时数据导入到Doris集群,查看监控显示CompactionCumulativeScore值波动十分异常:

图11.CompactionCumulativeScore监控

Doris的数据写入模型使用了LSM-Tree类似的数据结构。数据都是以追加(Append)的方式写入磁盘的。这种数据结构可以将随机写变为顺序写。这是一种面向写优化的数据结构,他能增强系统的写入吞吐,但是在读逻辑中,需要通过Merge-on-Read的方式,在读取时合并多次写入的数据,从而处理写入时的数据变更。

Merge-on-Read会影响读取的效率,为了降低读取时需要合并的数据量,基于LSM-Tree的系统都会引入后台数据合并的逻辑,以一定策略定期的对数据进行合并。Doris中这种机制被称为Compaction。

该值可以反映当前版本堆积的情况,这个值在以内算正常,如果持续逼近,说明集群可能存在风险,而从图11中可以看到,该集群的CompactionScore周期性的逼近。

3.2.2Compaction参数调节

通过监控图找到一个版本数量 的BE节点。然后执行以下命令分析日志:

grep"succeedtodocumulative


转载请注明:http://www.aierlanlan.com/rzfs/3171.html

  • 上一篇文章:
  •   
  • 下一篇文章: