Mailing-List: contact issues-help@drill.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@drill.apache.org
Date: Tue, 28 Mar 2017 06:06:41 +0000 (UTC)
From: "Kunal Khatua (JIRA)" <jira@apache.org>
To: issues@drill.apache.org
Message-ID: <JIRA.13036399.1484877147000.140028.1490681201609@Atlassian.JIRA>
In-Reply-To: <JIRA.13036399.1484877147000@Atlassian.JIRA>
References: <JIRA.13036399.1484877147000@Atlassian.JIRA> <JIRA.13036399.1484877147251@jira-lw-us.apache.org>
Subject: [jira] [Closed] (DRILL-5207) Improve Parquet scan pipelining
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Tue, 28 Mar 2017 06:06:45 -0000


     [ https://issues.apache.org/jira/browse/DRILL-5207?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kunal Khatua closed DRILL-5207.
-------------------------------

Verified that by introducing a large queue (1024), the scan threads were able to read faster from the distributed file system.

|*queueSize*	| *Disk Read Rate (MB/s)*|
|1	|194.8428|
|2	|207.9598|
|1024|	297.5866|

Currently, a size of 2 is sufficient since the increased diskrate will still be bottlenecked by the scan operator that needs to translate the parquet pages into value vectors.

> Improve Parquet scan pipelining
> -------------------------------
>
>                 Key: DRILL-5207
>                 URL: https://issues.apache.org/jira/browse/DRILL-5207
>             Project: Apache Drill
>          Issue Type: Bug
>          Components: Storage - Parquet
>    Affects Versions: 1.9.0
>            Reporter: Parth Chandra
>            Assignee: Parth Chandra
>              Labels: doc-impacting
>             Fix For: 1.10.0
>
>
> The parquet reader's async page reader is not quite efficiently pipelined. 
> The default size of the disk read buffer is 4MB while the page reader reads ~1MB at a time. The Parquet decode is also processing 1MB at a time. This means the disk is idle while the data is being processed. Reducing the buffer to 1MB will reduce the time the processing thread waits for the disk read thread.
> Additionally, since the data to process a page may be more or less than 1MB, a queue of pages will help so that the disk scan does not block (until the queue is full), waiting for the processing thread.
> Additionally, the BufferedDirectBufInputStream class reads from disk as soon as it is initialized. Since this is called at setup time, this increases the setup time for the query and query execution does not begin until this is completed.
> There are a few other inefficiencies - options are read every time a page reader is created. Reading options can be expensive.


--
This message was sent by Atlassian JIRA
(v6.3.15#6346)