我读过许多关于ORC文件格式对压缩和快速查询有多出色的帖子，尤其是与Parquet格式相比。 我了解ORC如何将数据跨行组拆分，细分为列组，以及它如何使用元数据和内部统计信息跳过整个数据块。我了解它对于Hive尤其有用，它可以提高查询速度，以及是否需要Hive ACID事务。
使用ORC是否有明显的弊端？
对于您何时绝对不想使用ORC，我想提供一个简洁的见解。到目前为止，我已经发现一些模糊的提示，说明它“无法与Spark配合使用”，并且“对于嵌套数据效率较低”，我想更好地理解为什么会这样。
很抱歉，如果事实证明是重复的，我还没有找到一个对此有详尽答案的问题。
答案 0 :(得分：0)
我们遇到的一个使我们跳到镶木地板的场景是在Spark 2.3之前，还没有用于ORC的矢量化读取器。他们正在研究Spark中镶木地板与ORC之间的功能奇偶性，而Spark 2.3在实现这一目标方面确实走了很长的路要走。
我们在一个合理的大桌子和一个窗口函数上进行了基准测试，以火花2.1放下手来计算复杂的拼花兽人。在宽表（超过500列）上，这变得非常明显。但是当涉及到Spark 2.3时，我们实际上具有相同的性能。还需要注意的是，spark 2.3也附带了更新的orc版本，因此使用此版本并使用新的spark读取旧表也存在彼此之间的性能差异。
您可以在其JIRA董事会here上了解有关此内容的更多信息。