[
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: [email protected]
For additional commands, e-mail: [email protected]
