[jira] [Comment Edited] (SPARK-32672) Data corruption in some cached compressed boolean columns

["Hyukjin Kwon (Jira)" <ji...@apache.org>]

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

Hyukjin Kwon edited comment on SPARK-32672 at 8/22/20, 2:27 AM:
----------------------------------------------------------------

[~revans2] is a PMC, and it is a correctness issue. This indeed is a blocker. I think the initial action was a mistake.

I think [~cltlfcjin] referred:

{quote}
Set to Major or below; higher priorities are generally reserved for committers to set. 
{quote}

I fully agree that ideally we should first evaluate what they are reporting with stating the reason.

The problem is that we don't have a lot of manpower here in triaging/managing JIRAs. It's just that there are not so many people who do.
Given this situation, I would like to encourage to aggressively triage - there are many JIRAs that set priority incorrectly.

For example, many JIRAs just ask questions and/or investigations with setting the priority as a blocker, presumably expecting quicker responses and actions. Such blockers matter for release managers.

If we want more fine-grained and ideal evaluation of JIRAs, I would encourage our PMC members to take a look more often.

We also ended up with introducing auto-resolving JIRAs that sets affect versions as EOL Spark versions, due to the lack of the manpower in JIRA management (which I don't think this is ideal but I think it was inevitable) for the same reason.


was (Author: hyukjin.kwon):
[~revans2] is a PMC, and it is a correctness issue. This indeed is a blocker. I think the initial action was a mistake.

I think [~cltlfcjin] referred:

{quote}
Set to Major or below; higher priorities are generally reserved for committers to set. 
{quote}

I fully agree that ideally we should first evaluate what they are reporting with stating the reason.

The problem is that we don't have a lot of manpower here in triaging/managing JIRAs. It's just that there are not so many people who do.
Given this situation, I would like to encourage to aggressively triage - there are many JIRAs that set priority incorrectly.

For example, many JIRAs just ask questions and/or investigations with setting the priority as a blocker. Such blockers matter for release managers.
If we want more fine-grained and ideal evaluation of JIRAs, I would encourage our PMC members to take a look more often.


> Data corruption in some cached compressed boolean columns
> ---------------------------------------------------------
>
>                 Key: SPARK-32672
>                 URL: https://issues.apache.org/jira/browse/SPARK-32672
>             Project: Spark
>          Issue Type: Bug
>          Components: SQL
>    Affects Versions: 2.3.4, 2.4.6, 3.0.0, 3.0.1, 3.1.0
>            Reporter: Robert Joseph Evans
>            Assignee: Robert Joseph Evans
>            Priority: Blocker
>              Labels: correctness
>             Fix For: 2.4.7, 3.0.1, 3.1.0
>
>         Attachments: bad_order.snappy.parquet, small_bad.snappy.parquet
>
>
> I found that when sorting some boolean data into the cache that the results can change when the data is read back out.
> It needs to be a non-trivial amount of data, and it is highly dependent on the order of the data.  If I disable compression in the cache the issue goes away.  I was able to make this happen in 3.0.0.  I am going to try and reproduce it in other versions too.
> I'll attach the parquet file with boolean data in an order that causes this to happen. As you can see after the data is cached a single null values switches over to be false.
> {code}
> scala> val bad_order = spark.read.parquet("./bad_order.snappy.parquet")
> bad_order: org.apache.spark.sql.DataFrame = [b: boolean]                        
> scala> bad_order.groupBy("b").count.show
> +-----+-----+
> |    b|count|
> +-----+-----+
> | null| 7153|
> | true|54334|
> |false|54021|
> +-----+-----+
> scala> bad_order.cache()
> res1: bad_order.type = [b: boolean]
> scala> bad_order.groupBy("b").count.show
> +-----+-----+
> |    b|count|
> +-----+-----+
> | null| 7152|
> | true|54334|
> |false|54022|
> +-----+-----+
> scala> 
> {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@spark.apache.org
For additional commands, e-mail: issues-help@spark.apache.org