Mailing-List: contact issues-help@hive.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@hive.apache.org
Date: Thu, 2 Mar 2017 22:54:45 +0000 (UTC)
From: =?utf-8?Q?Sergio_Pe=C3=B1a_=28JIRA=29?= <jira@apache.org>
To: issues@hive.apache.org
Message-ID: <JIRA.13045642.1487862581000.48440.1488495285713@Atlassian.JIRA>
In-Reply-To: <JIRA.13045642.1487862581000@Atlassian.JIRA>
References: <JIRA.13045642.1487862581000@Atlassian.JIRA> <JIRA.13045642.1487862581402@jira-lw-us.apache.org>
Subject: [jira] [Commented] (HIVE-16024) MSCK Repair Requires nonstrict
 hive.mapred.mode
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
archived-at: Thu, 02 Mar 2017 22:54:51 -0000


    [ https://issues.apache.org/jira/browse/HIVE-16024?page=3Dcom.atlassian=
.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=3D1589=
3193#comment-15893193 ]=20

Sergio Pe=C3=B1a commented on HIVE-16024:
------------------------------------

[~zsombor.klara]

I took a look at the code again, and I think there might be a OOM problem e=
ven if we fetch all partitions in batches (using PartitionIterable) when th=
e strict mode is used. Here's the piece of code:

{noformat}
void checkTable(Table table, PartitionIterable parts,
      boolean findUnknownPartitions, CheckResult result) throws IOException=
,
      HiveException {
...
Set<Path> partPaths =3D new HashSet<Path>();
...
for (Partition partition : parts) {
...
     if (!fs.exists(partPath)) {
        PartitionResult pr =3D new PartitionResult();
        pr.setPartitionName(partition.getName());
        pr.setTableName(partition.getTable().getTableName());
        result.getPartitionsNotOnFs().add(pr);
      }

      for (int i =3D 0; i < partition.getSpec().size(); i++) {
        partPaths.add(partPath.makeQualified(fs));
        partPath =3D partPath.getParent();
      }
}
...
{noformat}

My concern is that when running MSCK with million of partitions (fetched in=
 batches), and none of the partitions exist on the filesystem, then the abo=
ve code will add each partition name on the CheckResult object and partitio=
n locations on the partPaths temporary. There's no statistics, but still a =
concern about OOM. Should we refactor that code instead for handling partit=
ions in batches on MSCK better?

> MSCK Repair Requires nonstrict hive.mapred.mode
> -----------------------------------------------
>
>                 Key: HIVE-16024
>                 URL: https://issues.apache.org/jira/browse/HIVE-16024
>             Project: Hive
>          Issue Type: Bug
>          Components: Metastore
>    Affects Versions: 2.2.0
>            Reporter: Barna Zsombor Klara
>            Assignee: Barna Zsombor Klara
>         Attachments: HIVE-16024.01.patch, HIVE-16024.02.patch, HIVE-16024=
.03.patch, HIVE-16024.04.patch
>
>
> MSCK repair fails when hive.mapred.mode is set to strict
> HIVE-13788 modified the way we read up partitions for a table to improve =
performance. Unfortunately it is using PartitionPruner to load the partitio=
ns which in turn is checking hive.mapred.mode.
> The previous code did not check hive.mapred.mode.


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