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