Paul Rogers created DRILL-5660:
----------------------------------

             Summary: Drill 1.10 queries fail due to Parquet Metadata 
"corruption" from DRILL-3867
                 Key: DRILL-5660
                 URL: https://issues.apache.org/jira/browse/DRILL-5660
             Project: Apache Drill
          Issue Type: Bug
    Affects Versions: 1.11.0
            Reporter: Paul Rogers
            Assignee: Vitalii Diravka
             Fix For: 1.11.0


Drill recently accepted a PR for the following bug:

DRILL-3867: Store relative paths in metadata file

This PR turned out to have a flaw which affects version compatibility.

The DRILL-3867 PR changed the format of Parquet metadata files to store 
relative paths. All Drill servers after that PR create files with relative 
paths. But, the version number of the file is unchanged, so that older 
Drillbits don't know that they can't understand the file.

Instead, if an older Drill tries to read the file, queries fail left and right. 
Drill will resolve the paths, but does so relative to the user's HDFS home 
directory, which is wrong.

What should have happened is that we should have bumped the parquet metadata 
file version number so that older Drillbits can’t read the file. This ticket 
requests that we do that.

Now, one could argue that the lack of version number change is fine. Once a 
user upgrades Drill, they won't use an old Drillbit. But, things are not that 
simple:

* A developer tests a branch based on a pre-DRILL-3867 build on a cluster in 
which metadata files have been created by a post-DRILL-3867 build. (This has 
already occurred multiple times in our shop.)
* A user tries to upgrade to Drill 1.11, finds an issue, and needs to roll back 
to Drill 1.10. Doing so will cause queries to fail due to seemingly-corrupt 
metadata files.
* A user tries to do a rolling upgrade: running 1.11 on some servers, 1.10 on 
others. Once a 1.11 server is installed, the metadata is updated ("corrupted" 
from the perspective of 1.10) and queries fail.

Standard practice in this scenario is to:

* Bump the file version number when the file format changes, and
* Software refuses to read files with a version newer than the software was 
designed for.

Of course, it is highly desirable that newer servers read old files, but that 
is not the issue here.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Reply via email to