[ https://issues.apache.org/jira/browse/HADOOP-18971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17785857#comment-17785857 ]
ASF GitHub Bot commented on HADOOP-18971: ----------------------------------------- steveloughran commented on code in PR #6270: URL: https://github.com/apache/hadoop/pull/6270#discussion_r1392446821 ########## hadoop-tools/hadoop-azure/src/main/java/org/apache/hadoop/fs/azurebfs/constants/ConfigurationKeys.java: ########## @@ -104,7 +104,20 @@ public final class ConfigurationKeys { public static final String AZURE_ENABLE_SMALL_WRITE_OPTIMIZATION = "fs.azure.write.enableappendwithflush"; public static final String AZURE_READ_BUFFER_SIZE = "fs.azure.read.request.size"; public static final String AZURE_READ_SMALL_FILES_COMPLETELY = "fs.azure.read.smallfilescompletely"; + /** + * When parquet files are read, first few read are metadata reads before reading the actual data. Review Comment: this is roughly the same for ORC, isn't it? ########## hadoop-tools/hadoop-azure/src/main/java/org/apache/hadoop/fs/azurebfs/constants/ConfigurationKeys.java: ########## @@ -104,7 +104,20 @@ public final class ConfigurationKeys { public static final String AZURE_ENABLE_SMALL_WRITE_OPTIMIZATION = "fs.azure.write.enableappendwithflush"; public static final String AZURE_READ_BUFFER_SIZE = "fs.azure.read.request.size"; public static final String AZURE_READ_SMALL_FILES_COMPLETELY = "fs.azure.read.smallfilescompletely"; + /** + * When parquet files are read, first few read are metadata reads before reading the actual data. + * First the read is done of last 8 bytes of parquet file to get the postion of metadta and next read + * is done for reading that metadata. With this optimizations these two reads can be combined into 1. + * Value: {@value} + */ public static final String AZURE_READ_OPTIMIZE_FOOTER_READ = "fs.azure.read.optimizefooterread"; + /** + * In case of footer reads it was not required to read full buffer size. + * Most of the metadata information required was within 256KB and it will be more performant to read lesser. Review Comment: "read less" ########## hadoop-tools/hadoop-azure/src/main/java/org/apache/hadoop/fs/azurebfs/constants/ConfigurationKeys.java: ########## @@ -104,7 +104,20 @@ public final class ConfigurationKeys { public static final String AZURE_ENABLE_SMALL_WRITE_OPTIMIZATION = "fs.azure.write.enableappendwithflush"; public static final String AZURE_READ_BUFFER_SIZE = "fs.azure.read.request.size"; public static final String AZURE_READ_SMALL_FILES_COMPLETELY = "fs.azure.read.smallfilescompletely"; + /** + * When parquet files are read, first few read are metadata reads before reading the actual data. + * First the read is done of last 8 bytes of parquet file to get the postion of metadta and next read + * is done for reading that metadata. With this optimizations these two reads can be combined into 1. Review Comment: nit "optimization" ########## hadoop-tools/hadoop-azure/src/main/java/org/apache/hadoop/fs/azurebfs/constants/FileSystemConfigurations.java: ########## @@ -59,7 +59,8 @@ public final class FileSystemConfigurations { public static final boolean DEFAULT_AZURE_ENABLE_SMALL_WRITE_OPTIMIZATION = false; public static final int DEFAULT_READ_BUFFER_SIZE = 4 * ONE_MB; // 4 MB public static final boolean DEFAULT_READ_SMALL_FILES_COMPLETELY = false; - public static final boolean DEFAULT_OPTIMIZE_FOOTER_READ = false; + public static final boolean DEFAULT_OPTIMIZE_FOOTER_READ = true; + public static final int DEFAULT_FOOTER_READ_BUFFER_SIZE = 512 * ONE_KB; Review Comment: this is 512k; docs in file above say 265K. ########## hadoop-tools/hadoop-azure/src/main/java/org/apache/hadoop/fs/azurebfs/constants/ConfigurationKeys.java: ########## @@ -104,7 +104,20 @@ public final class ConfigurationKeys { public static final String AZURE_ENABLE_SMALL_WRITE_OPTIMIZATION = "fs.azure.write.enableappendwithflush"; public static final String AZURE_READ_BUFFER_SIZE = "fs.azure.read.request.size"; public static final String AZURE_READ_SMALL_FILES_COMPLETELY = "fs.azure.read.smallfilescompletely"; + /** + * When parquet files are read, first few read are metadata reads before reading the actual data. + * First the read is done of last 8 bytes of parquet file to get the postion of metadta and next read + * is done for reading that metadata. With this optimizations these two reads can be combined into 1. + * Value: {@value} + */ public static final String AZURE_READ_OPTIMIZE_FOOTER_READ = "fs.azure.read.optimizefooterread"; Review Comment: i'd prefer "." between words, but it's too late now ########## hadoop-tools/hadoop-azure/src/test/java/org/apache/hadoop/fs/azurebfs/services/ITestAbfsInputStreamReadFooter.java: ########## @@ -190,7 +193,8 @@ private void seekReadAndTest(final FileSystem fs, final Path testFilePath, try (FSDataInputStream iStream = fs.open(testFilePath)) { AbfsInputStream abfsInputStream = (AbfsInputStream) iStream .getWrappedStream(); - long bufferSize = abfsInputStream.getBufferSize(); + long footerReadBufferSize = abfsInputStream.getFooterReadBufferSize(); Review Comment: I'd propose something else, will comment below > ABFS: Enable Footer Read Optimizations with Appropriate Footer Read Buffer > Size > ------------------------------------------------------------------------------- > > Key: HADOOP-18971 > URL: https://issues.apache.org/jira/browse/HADOOP-18971 > Project: Hadoop Common > Issue Type: Sub-task > Components: fs/azure > Affects Versions: 3.3.6 > Reporter: Anuj Modi > Assignee: Anuj Modi > Priority: Major > Labels: pull-request-available > > Footer Read Optimization was introduced to Hadoop azure in this Jira: > https://issues.apache.org/jira/browse/HADOOP-17347 > and was kept disabled by default. > This PR is to enable footer reads by default based on the results of analysis > performed as below: > In our scale workload analysis, it was found that workloads working with > Parquet (or for that matter OCR etc.) have a lot of footer reads. Footer > reads here refers to the read operations done by workload to get the metadata > of the parquet file which is required to understand where the actual data > resides in the parquet. > This whole process takes place in 3 steps: > # Workload reads the last 8 bytes of parquet file to get the offset and size > of the metadata which is present just above these 8 bytes. > # Using that offset, workload reads the metadata to get the exact offset and > length of data which it wants to read. > # Workload performs the final read operation to get the data it wants to use > for its purpose. > Here the first two steps are metadata reads that can be combined into a > single footer read. When workload tries to read certain last few bytes of > data (let's say this value is footer size), driver will intelligently read > some extra bytes above the footer size to cater to the next read which is > going to come. > Q. What is the footer size of file? > A: 16KB. Any read request trying to get the data within last 16KB of the file > will qualify for whole footer read. This value is enough to cater to all > types of files including parquet, OCR, etc. > Q. What is the buffer size to read when reading the footer? > A. Let's call this footer read buffer size. Prior to this PR footer read > buffer size was same as read buffer size (default 4MB). It was found that for > most of the workload required footer size was only 256KB. i.e. For almost all > parquet files metadata for that file was found to be within last 256KBs. > Keeping this in mind it does not make sense to read whole buffer length of > 4MB as a part of footer read. Moreover, reading larger data than require > incur additional costs in terms of server and network latencies. Based on > this and extensive experimentation it was observed that footer read buffer > size of 512KB is ideal for almost all the workloads running on parquet, OCR, > etc. > Following configuration was introduced to configure the footer read buffer > size: > {*}fs.azure.footer.read.request.size{*}: default 512 KB. > *Quantitative Stats:* For a workload running on parquet files the number of > read requests got reduced by 2.3M down from 20M. That means around 10% > reduction in overall TPS. -- This message was sent by Atlassian Jira (v8.20.10#820010) --------------------------------------------------------------------- To unsubscribe, e-mail: common-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: common-issues-h...@hadoop.apache.org