[
https://issues.apache.org/jira/browse/HADOOP-17296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17209897#comment-17209897
]
Sneha Vijayarajan edited comment on HADOOP-17296 at 10/8/20, 9:03 AM:
----------------------------------------------------------------------
[~mukund-thakur] -
Readahead.range will provide a static increase to whatever the read size will
be for the requested read, which makes the read to store to be of different
size.
The specific case mentioned in description was a pattern observed for a
parquet file which had very small row group size, which I gather isnt an
optimal structure for parquet file. Gen1 job run was more performant as it was
reading a full buffer and a buffer read ended up reading more row groups.
Gen2's random read logic ended up triggering more IOPs as when random it reads
only the requested bytes. To highlight that it was the randomness of read
pattern that lead to high job runtime and more IOPs, forcing Gen2 to read a
full buffer like Gen1 helped.
But reading a full buffer for every random read is definitely not ideal esp a
blocking read call for app. Hence the configs that enforce a full buffer read
will be set to false by default. We get similar asks for comparisons between
Gen1 to Gen2 for same workloads, and this Jira configs will get a gen1 customer
migrating to gen2 the same overall i/o pattern as gen1 and the same perf
characteristics.
Readahead.range which will be a consistent amount of data read ahead on top of
the varying requested read size is definitely a better solution for a
performant random read on Gen2 and we should pursue on that. And this change
wont make any override with the range update.
was (Author: snvijaya):
[~mukund-thakur] -
Readahead.range will provide a static increase to whatever the read size will
be for the requested read, which makes the read to store to be of different
size.
The specific case mentioned in description was a pattern observed for a
parquet file which had very small row group size, which I gather isnt an
optimal structure for parquet file. Gen1 job run was more performant as it was
reading a full buffer and a buffer read ended up reading more row groups.
Gen2's random read logic ended up triggering more IOPs as when random it reads
only the requested bytes. To highlight that it was the randomness of read
pattern that lead to high job runtime and more IOPs, forcing Gen2 to read a
full buffer like Gen1 helped.
But reading a full buffer for every random read is definitely not ideal esp a
blocking read call for app. Hence the configs that enforce a full buffer read
will be set to false by default. We get similar asks for comparisons between
Gen1 to Gen2 for same workloads, and we are hoping that rerun of the workload
with this config turned on will be easier to get that information with the IO
pattern matching.
Readahead.range which will be a consistent amount of data read ahead on top of
the varying requested read size is definitely a better solution for a
performant random read on Gen2 and we should pursue on that.
> ABFS: Allow Random Reads to be of Buffer Size
> ---------------------------------------------
>
> Key: HADOOP-17296
> URL: https://issues.apache.org/jira/browse/HADOOP-17296
> Project: Hadoop Common
> Issue Type: Sub-task
> Components: fs/azure
> Affects Versions: 3.3.0
> Reporter: Sneha Vijayarajan
> Assignee: Sneha Vijayarajan
> Priority: Major
> Labels: abfsactive
>
> ADLS Gen2/ABFS driver is optimized to read only the bytes that are requested
> for when the read pattern is random.
> It was observed in some spark jobs that though the reads are random, the next
> read doesn't skip by a lot and can be served by the earlier read if read was
> done in buffer size. As a result the job triggered a higher count of read
> calls and resulted in higher job runtime.
> When these jobs were run against Gen1 which always reads in buffer size , the
> jobs fared well.
> In this Jira we try to provide a control over config on random read to be of
> requested size or buffer size.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
