[jira] [Commented] (HADOOP-14535) Support for random access and seek of block blobs

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

[jira] [Commented] (HADOOP-14535) Support for random access and seek of block blobs

JIRA jira@apache.org

    [ https://issues.apache.org/jira/browse/HADOOP-14535?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16054280#comment-16054280 ]

Steve Loughran commented on HADOOP-14535:

seek optimisation is the key way to speed up data input, especially for columnar storage formats

The lessons from our work on S3AInputStream (Which I recommend you look at were)

* ignore no-ops

* lazy-seek, where you don't seek() until a read() call, really boosts performance when the IO is a series of readFully(pos, ....) calls.

* any forward seeks you can do by discarding data is cost effective for tends to hundreds of KB (> 512KB long haul). It looks like you do this.

* optimisations you may do for random IO can be pathologically bad for full document reads (e.g. scanning an entire .csv.gz file). You have to measure performance on these formats as well as random IO. We rely in S3 for amazon serving some 20MB public CSV.gz files which we can abuse for this.

* it's really useful to instrument your streams to count how many bytes you discard in closing streams, skip in seeks, how many forward & backward seeks, etc. In S3A we track this in the stream (and toString()) prints, then we pull it back to the FS instrumentation (which is actually copied out of the Azure code originally). This helps us diagnose our tests, and make some assertions. Have a look at {{ITestS3AInputStreamPerformance}} for this.

At a quick glance of this patch, I can see you are starting on this. I'd recommend starting off with that instrumentation and setting up a test which anyone can use to test performance by working with a public (free, read-only) file. Why? Saves setup time, eliminates cost, very useful later on. With the measurements, then we can look at what's best to target in improving seek.

How about you create/own an uber JIRA on this topic, say "speed up Azure input", and add the tasks underneath?

> Support for random access and seek of block blobs
> -------------------------------------------------
>                 Key: HADOOP-14535
>                 URL: https://issues.apache.org/jira/browse/HADOOP-14535
>             Project: Hadoop Common
>          Issue Type: Improvement
>          Components: fs/azure
>            Reporter: Thomas
>            Assignee: Thomas
>         Attachments: 0001-Random-access-and-seek-imporvements-to-azure-file-system.patch, 0003-Random-access-and-seek-imporvements-to-azure-file-system.patch, 0004-Random-access-and-seek-imporvements-to-azure-file-system.patch
> This change adds a seek-able stream for reading block blobs to the wasb:// file system.
> If seek() is not used or if only forward seek() is used, the behavior of read() is unchanged.
> That is, the stream is optimized for sequential reads by reading chunks (over the network) in
> the size specified by "fs.azure.read.request.size" (default is 4 megabytes).
> If reverse seek() is used, the behavior of read() changes in favor of reading the actual number
> of bytes requested in the call to read(), with some constraints.  If the size requested is smaller
> than 16 kilobytes and cannot be satisfied by the internal buffer, the network read will be 16
> kilobytes.  If the size requested is greater than 4 megabytes, it will be satisfied by sequential
> 4 megabyte reads over the network.
> This change improves the performance of FSInputStream.seek() by not closing and re-opening the
> stream, which for block blobs also involves a network operation to read the blob metadata. Now
> NativeAzureFsInputStream.seek() checks if the stream is seek-able and moves the read position.
> [^attachment-name.zip]

This message was sent by Atlassian JIRA

To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]