大数据计算MaxCompute事务表2.0还有相关介绍吗？我这存储大小每天竟然都在变大

问题1：MaxCompute事务表2.0是MaxCompute引入的一种表格类型，用于解决数据一致性和版本管理的需求。与传统的分区表不同，事务表2.0支持对数据进行修改、删除和回滚，并且可以保留一定时间的历史版本。

关于MaxCompute事务表2.0的详细介绍，你可以参考MaxCompute官方文档中的相关部分。文档中会提供更多关于事务表2.0的使用方法、特性和最佳实践等信息，以帮助你更好地理解和应用该功能。同时，如果你遇到了存储大小每天变大的问题，也建议阅读MaxCompute文档中有关事务表2.0性能优化和存储管理的内容，以获得更具体的指导。

问题2：根据你的描述，使用pk表来存储大小时，Snapshot加上存储量比之前分区表的历史存储数据大小要大很多。这可能是因为事务表2.0保留了所有的历史快照（Snapshots），而不仅仅保留了分区表的历史数据。

事务表2.0在每个更新操作后会生成一个新的版本（Snapshot），并将更新的数据添加到该版本中。随着时间的推移，这些快照会占用更多的存储空间。如果你的事务表2.0设置了较长的生命周期（lifecycle），那么会保留更多的历史版本，进而导致存储大小增加。

如果你想减少事务表2.0的存储大小，可以考虑以下方法：

• 调整事务表的生命周期：减少事务表2.0的生命周期，以便删除一些旧的快照和历史版本。
• 定期清理不再需要的数据：根据具体业务需求，定期清理一些不再需要的历史版本或快照。
• 优化数据写入：尽量避免频繁的更新操作，合并多个更新为批量操作，以降低生成快照的频率。

回答1：我最近研究了一下transaction 2.0表的小文件和存储，你可以作为参考。其实底层的存储逻辑应该不会透出的很细致，实际存储的话还是建议看收费明细。1. 首先我大概测试了一下合并transaction 2.0表的小文件，发现合并命令的运行日志中会打印出合并效果，比如起始file num=99，合并后为17；随机用desc extended命令看了下，file num=133，不减反增了。2. 这个情况我咨询了下研发，对于transaction 2.0表desc结果中的file num包含了历史版本的文件，因为transaction 2.0表 会对历史版本保留一段时间；而即使被合并的表小文件最终是多少，可以在合并日志中看到明细。所以结论：最新版本的按合并日志来看，普通全量查询只会查询到最新版本。

1. 对于存储方面，我也发现了desc 结果中的存储量 比 合并日志中产生的存储量偏大，我理解这部分适合 2点逻辑一致，因为有不同版本的数据，所以存储量会偏大。而实际的存储计费，按照用量明细的账单来看最为准确；4. 有一点，如果在rention time 内做了多次major compaction的话，就会保留这么多大版本的数据，这个是有成本的，备份多的话，成本会高。详情可以看下这个文档：https://help.aliyun.com/zh/maxcompute/user-guide/timetravel-query-and-incremental-query?spm=a2c4g.11186623.0.0.39813addfWznpM
   回答2：因为每天系统也会自动合并，有历史版本。，此回答整理自钉群“MaxCompute开发者社区2群”