DEV Community: Greptime
·
减少98%的S3 API调用 | 探索OpenDAL的RangeReader奥秘
💡
原文英文，约2400词，阅读约需9分钟。
📝
内容提要
在GreptimeDB中，使用OpenDAL作为统一的数据访问层。最近，一位同事告诉我，执行Copy From语句从S3导入一个800 KiB的Parquet文件需要10秒。经过一些调查和对OpenDAL文档和实现的审查，我在这里记录并简要总结了我们的发现。OpenDAL的IO操作都围绕着Operator展开，Operator是在main.rs中构建的。OperatorBuilder::new函数中添加了ErrorContextLayer和CompleteLayer两个层，最后调用finish函数。在Copy From场景中，没有添加LruCacheLayer层。在ParquetRecordBatchStream的构造中，使用了BufReader，但实际上是多余的。在RangeReader中，每次调用seek都会重置内部状态，并在下一次read调用时发起新的远程请求。这导致了性能问题。
🎯
关键要点
- 在GreptimeDB中，使用OpenDAL作为统一的数据访问层。
- 执行Copy From语句从S3导入800 KiB的Parquet文件需要10秒。
- OpenDAL的IO操作围绕Operator展开，Operator在main.rs中构建。
- OperatorBuilder::new函数中添加了ErrorContextLayer和CompleteLayer层。
- 在Copy From场景中，没有添加LruCacheLayer层，导致性能问题。
- ParquetRecordBatchStream的构造中使用BufReader是多余的。
- RangeReader每次调用seek都会重置内部状态，导致新的远程请求。
- 在Copy From场景中，未使用LruCacheLayer，导致性能下降。
- 每次调用RangeReader的seek和read会导致多次远程请求。
- 800KiB文件包含50个RowGroups和12列，导致600个S3请求。
- RangeReader的poll_read方法在每次读取后重置状态，增加了远程调用的开销。
- 在调用seek后，RangeReader的内部状态被重置，导致性能下降。
➡️
