夜雨聆风在使用 Flink 同步数据到 Doris的案例中，希望评估出一个合理的公式来估算应该给 Doris 分配多少内存。
由于数据的抽取和输出都是 Flink 来管理的，对 Flink 并不是很了解，多次向 AI 工具了解，也还是不清不楚的，即使把源码下载下来，给 AI 工具提供更多上下文，所得到的结果也只是好一点，达不到解决问题的目的。凭着对 Flink 的一点理解，总结出一个简化的公式，比如：行数 * 每行的数据量 * checkpoint周期内读取数据的批次 * 一个预留的倍数 + 基础消耗 = Doris 需要的内存。其中，前三个参数的乘积就是一个周期内往 Doris 传输的数据量；预留的倍数是指内存不能全部用光，需要预留一些，如果预留50%则这个倍数就是2；基础消耗是指 Doris 啥业务都不承担的时候，也需要一定量的内存消耗。从意思来看，公式大体合理，如果要挑一下毛病，那就是预留的倍数可以作为整体的内存来乘以这个倍数，但不包含基础量来预留也说得过去。
这个公式用来算一两个场景，好像也大概可以得出一个感觉上合理的内存值。但如果扩大参数的变化，发现就差距比较大了。上一篇已经说过 Flink 在传输数据的时候，除了这个公式里前三个因素之外，已知的都还有好几个因素，未知的可能也还有不少，每个因素的取值范围也是比较大的。所以应用到更多实际的场景的时候偏差是比较大的。
人工不太好优化这个公式了，就想着让 AI 工具借助源代码来优化这个公式，虽然 Flink 的代码也是挺庞大的，但这个对 AI 工具来说也不算什么，这也正好弥补对 Flink 处理数据的原理不了解的短板。把初步的公式、公式的问题、对公式的要求，和 Flink 的源码、一些实际场景真实使用的参数与内存关系，都提供给 AI 工具。这也是之前积累的经验，要发挥 AI 工具的威力，需要把相关的上下文都给足，提供的这些信息应该算比较全的上下文了。还让 AI 工具注意目标是合理估算出 Doris 需要的内存，得出的公式要简便可操作，还可以参考业务最佳实践来优化。
AI 工具很快就把公式给出来了，还指出了所提供公式的一大堆问题，并详细说明了新的公式都把这些问题兼容了，还贴心地把每个场景的数据都用公式验证了一遍，给出了偏差的程度。首先，这个公式的参数长达十几个，里面引入了一些模糊的参数，比如安全系数等，把说不清的因素都归到这些模糊的参数里。如果这些模糊的参数只有一个，那也还可以，但里面有近一半的参数都属于这种，那公式就很难应用到实际当中了，要搞清楚这些参数的意思就很困难了，在“可操作”方面就完全不满足要求。把这个信息给到 AI 工具，AI 工具很快就会给出新的公式，参数数量可以缩小，但在可操作方面没有什么提升，不是这个参数难以估计，就是那个参数定义不了。
突然意识到，AI 工具本质上还是一个机器工具，在某种程度上是“很严谨”的。目标是一个可以快速估算 Doris 内存的公式，而不是一个很精确的公式，虽然不需要很精确，但需要在量级上合理，比如需要 16G 内存，算出是 12G 都是可以接受的，但不能是 8 G。“快速估算”、“不用精确”、“要合理”，当目标需要在矛盾中平衡的时候，AI 工具是很难理解的，所以无论怎么变着法子来问，结果都是无法改善的。
