Question

我们最近从1.4.1切换到Spark 1.5.0，并注意到持久存在DataFrames时出现了一些不一致的行为。

else if analysis & git.MergeAnalysisFastForward != 0 {
    // Fast-forward changes
    // Get remote tree
    remoteTree, err := repo.LookupTree(remoteBranchID)
    if err != nil {
        return err
    }

    // Checkout
    if err := repo.CheckoutTree(remoteTree, nil); err != nil {
        return err
    }

    branchRef, err := repo.References.Lookup("refs/heads/branch_name")
    if err != nil {
        return err
    }

    // Point branch to the object
    branchRef.SetTarget(remoteBranchID, "")
    if _, err := head.SetTarget(remoteBranchID, ""); err != nil {
        return err
    }

}

161100982

df1 = sqlContext.read.parquet("df1.parquet")
df1.count()

67498706

df2 = sqlContext.read.parquet("df2.parquet")
df2.count()

160608147

join_df = df1.join(df2, "id")
join_df.count()

67698892

join_df.write.parquet("join.parquet")
join_parquet = sqlContext.read.parquet("join.parquet")
join_parquet.count()

67695663

第一个主要问题是连接DataFrame的计数与持久连接DataFrame之间存在一个数量级的差异。其次，将相同的DataFrame保存为2种不同的格式会产生不同的结果。

有没有人知道这里会发生什么？

Answer 1

我在Spark 1.6.1中遇到过类似的问题：

当我从单个RDD创建2个不同的DataFrame并持续到2个Parquets时，我发现，parquets中的Rows不一样。

后来我发现在这个RDD的操作管道定义中，我有rdd.reduceByKey（）操作，它返回了多个调用的不确定结果。

显然，对于每个DataFrame，调用了一个不同的reduceByKey（），导致某些行的差异很小。

在你的情况下，可能会有类似的东西。

Spark 1.5中DataFrame的持久性不一致

1 个答案: