在推断整个执行流程中，每一步产生的中间数据可能符合什么样的 特性时，容易有什么挑战？

·实际输入数据的 statistics 的缺失：即便是 SQL 作业处理的结构化数据，也无法保证其源表数据特性拥有很好的统计。事实上今天因为数据落盘方式多样化，以及精细化统计方式的缺失，大部分的源表数据都是没有完整的 statistics 的。此外对于集群内部和外部需要处理的非结构化数据，数据的特性的统计更加困难；

分布式作业中存在的大量用户逻辑黑盒：作为一个通用的大数据处理系统，不可避免的需要支持用户逻辑在系统中的运行。比如 SQL 中常用的UDF/UDTF/UDJ/Extractor/Outputer 等等，这些使用 Java/Python 实现的用户逻辑，计算引擎和分布式系统并无法理解，在整个作业流程中是类似黑盒的存在。以 MaxCompute 为例，线上有超过 20% 的 SQL 作业，尤其是重点基线作业，都包含用户代码。这些大量用户代码的存在，也造成了优化器在很多情况下无法对中间产出数据的特性 进行预判；

·优化器预判错误代价昂贵：在优化器选择执行计划时，会有一些优化方法，在数据符合一定特殊特性的时候，被合理选中能带来性能优化。但是一旦选择的前提假设错误（比如数据特性不符合预期），会适得其反，甚至带来严重的性能回退或作业失败。在这种前提下，依据静态的信息实现进行过多的预测经常得不到理想的结果。

以上内容摘自《“伏羲”神算》电子书，点击https://developer.aliyun.com/topic/download?id=873