全部产品
Search
文档中心

云原生大数据计算服务 MaxCompute:数据组织优化

更新时间:Apr 09, 2024

本文为您介绍Transactional Table 2.0在数据组织优化服务上的架构设计。

Clustering

  • 当前痛点

    Transactional Table 2.0支持分钟级近实时增量数据导入,高流量场景下可能会导致增量小文件数量膨胀,从而引发存储访问压力大、成本高,并且大量的小文件还会引发meta更新以及分析执行慢,数据读写IO效率低下等问题,因此需要设计合理的小文件合并服务,即Clustering服务来自动优化此类场景。

  • 解决方案

    Clustering服务主要由MaxCompute 内部的Storage Service来负责执行,专门解决小文件合并的问题,但它并不会改变任何数据的历史中间状态,即不会消除数据的Update/Delete中间状态。

  • Clustering服务流程

    Clustering服务的整体操作流程如图所示。

    image.png

    • Clustering策略制定主要根据一些典型的读写业务场景而设计,会周期性地根据数据文件大小、数量等多个维度来综合评估,进行分层次的合并。Level0到Level1主要针对原始写入的DeltaFile(图中蓝色数据文件)合并为中等大小的DeltaFile(图中黄色数据文件),当中等大小的DeltaFile达到一定规模后,会进一步触发Level1到Level2的合并,生成更大的DeltaFile(图中橙色数据文件)。

    • 对于一些超过一定大小的数据文件会进行专门的隔离处理,不会触发进一步合并,避免不必要的读写放大问题,如图中Bucket3的T8数据文件。超过一定时间跨度的文件也不会合并,因为时间跨度太大的数据合并在一起的话,当Time travel或者增量查询时,可能会读取大量不属于此次查询时间范围的历史数据,造成不必要的读放大问题。

    • 由于数据是按照BucketIndex来切分存储的,因此Clustering服务会以Bucket粒度来并发执行,大幅缩短整体运行时间。

    • Clustering服务需要和Meta Service进行交互,获取需要执行此操作的表或分区的列表,执行结束之后,会把新老数据文件的信息传入Meta Service,它负责Clustering操作的事务冲突检测,新老文件meta信息原子更新、老的数据文件回收等。

    • Clustering服务可以很好的解决大文件数量膨胀引发的一系列效率低下的读写问题,但不是频率越高越好,执行一次也会消耗计算和IO资源,至少数据都要全部读写一遍,存在一定的读写放大问题。因此执行策略的选择尤其重要,当前MaxCompute引擎根据系统状态智能自动触发执行,可保障Clustering服务执行的高效率。

Compaction

  • 当前痛点

    Transactional Table 2.0支持update、delete格式的数据写入,如果存在大量此格式的数据写入,会造成中间状态的冗余记录太多,引发存储和计算成本增加,查询效率低下等问题。因此需要设计合理的compaction服务消除中间状态优化此类场景。

  • 解决方案

    Compaction服务主要由MaxCompute 内部的Storage Service来负责执行,既支持用户手动执行SQL语句触发、也可通过配置表属性按照时间频率、Commit次数等维度自动触发。此服务会把选中的数据文件,包含BaseFile和DeltaFile,一起进行Merge,消除数据的Update / Delete中间状态,PK值相同的多行记录只保留最新状态的一行记录,最后生成新的只包含Insert格式的BaseFile。

  • Compaction服务流程

    Compaction服务的整体操作流程如下所示。

    image.png

    • t1到t3时间段,一批DeltaFile写入进来,触发compaction操作,以bucket粒度并发执行,把所有的DeltaFile进行merge,然后每个Bucket会生成新的BaseFile。之后t4和t6时间段,又写入了一批新的DeltaFile,再触发compaction操作,会把当前存在的BaseFile和新增的DeltaFile一起做merge操作,重新生成一个新的BaseFile。

    • Compaction服务也需要和Meta Service进行交互,流程和Clustering类似,获取需要执行此操作的表或分区的列表,执行结束之后,会把新老数据文件的信息传入Meta Service,它负责Compaction操作的事务冲突检测,新老文件meta信息原子更新、老的数据文件回收等。

    • Compaction服务通过消除记录中间历史状态,可节省计算和存储成本,极大加速全量快照查询场景的效率,但也不是频率越高越好,首先执行一次也要读取一遍全量数据进行Merge,极大消耗计算和IO资源,并且生成的新BaseFile也会占据额外的存储成本,而老的DeltaFile文件可能需要用于支持time travel查询,因此不能很快删除,依然会有存储成本,所以COMPACTION操作需要用户根据自己的业务场景和数据特征来合理选择执行的频率,通常来说,对于Update / Delete格式的记录较多,并且全量查询次数也较多的场景,可以适当增加compaction的频率来加速查询。

数据回收

由于Time travel和增量查询都会查询数据的历史状态,因此需要保存一定的时间,可通过表属性acid.data.retain.hours来配置保留的时间范围。如果历史状态数据存在的时间早于配置值,系统会开始自动回收清理,一旦清理完成,Time travel就查询不到对应的历史状态了。回收的数据主要包含操作日志和数据文件两部分。

同时,也会提供purge命令,用于特殊场景下手动触发强制清除历史数据。

需要特别说明的是,对于Transactional Table 2.0,如果用户一直写入新的DeltaFile,那永远也删除不了任何一个DeltaFile,因为其他的DeltaFile可能对它有状态依赖。只有执行COMPACTION或者InsertOverwrite操作后,之后产生的数据文件对之前的那些DeltaFile就没有依赖了,如果超过Time traval可查询的时间周期后,就可以被删除了。

对于用户就是一直不执行Compaction操作的极端场景,引擎侧会做一些优化避免产生无限的历史记录,后台系统会周期性地对超过Time travel时间的BaseFile或者DeltaFile进行自动Compaction,后续就可以正常回收这些被Compaction的历史数据文件。