我的用例如下：
写作RDD归档依据saveAsTable（对于 ORC 文件也是如此）。每次保存都会创建新文件（因此1000 000著作给我1000 000ORC 文件）。我知道每个 RDD 都会创建新的 ORC 文件，这是很自然的。但是，我不知道为什么从 ThriftServer 查询它们时如此慢。
我的问题是：如何理解这种奇怪的行为？
例如，SELECT COUNT(*)1000 000 行（因此相同的文件）大约需要1 minute (!).
但是，当我保存时1000 000行到一个文件，相同的查询适用于50ms.
我想了解这种差异。毕竟，1000 000文件数量很少。
计数操作的高级执行计划将如下所示（假设您的文件位于分布式文件系统中，例如我将使用 HDFS）：
从 HDFS NameNode 请求文件
将 HDFS 块加载到执行器中
- 对每个分区进行计数（使用 ORC 元数据或直接 - 取决于实现）并将所有分区加在一起
一些估计：1000 000 个文件需要向 NameNode 发出相同数量的请求来解析数据块的物理位置。它在 文档:
例如ORC文件格式与RCFile格式相比有很多
优点如：
a single file as the output of each task, which reduces the NameNode's load
当 ORC 试图减少文件数量时，您的代码却做了相反的事情。和
默认条带大小为 250 MB。大条纹尺寸可实现大、
从 HDFS 高效读取。
文件页脚包含文件中的条带列表，条带的数量
每个条带的行数以及每列的数据类型。它还包含
列级聚合计数、最小值、最大值和总和。
像计数这样的简单统计数据是预先计算的，不应该是性能问题。您可以尝试通过暴力简单地向 HDFS NameNode 添加内存和 CPU 能力来解决问题，但我认为保留适度数量的文件是合理的。如果您的数据来自某个流源，您可以创建某种压缩作业，将小文件合并为大文件并定期运行。或者，作为替代方案，如果这种延迟适合您的用例，您可以每 2-5 分钟从源读取一次。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
