![](/img/trans.png)
[英]What is the difference between DataFrame.cache() and hiveContext.cacheTable?
[英]Spark Dataframe.cache() behavior for changing source
我的用例:
到時候,執行步驟4,輸出數據幀為空。 這是因為,spark 會重新評估 action 上的數據幀,並且由於沿襲,cassandra 查詢再次執行,現在不會產生任何記錄。
為了避免這種情況,我在第 2 步之后添加了一個步驟:
2a) outputDataframe.cache()
這可確保在第 5 步中不會查詢 cassandra,並且我的文件中也能獲得所需的輸出記錄。 我對這種方法有以下疑問:
df.rdd.cache()
。 這與在數據幀上調用cache()
什么不同嗎?作為參考,我當前的代碼如下所示:
//1
val dfOrig = spark
.read
.format("org.apache.spark.sql.cassandra")
.options(Map("keyspace" -> "myks", "table" -> "mytable", "pushdown" -> "true"))
.load()
//2
val df = dfOrig.filter("del_flag = 'N'").withColumn("del_flag", lit("Y"))
//3
df.write.format("org.apache.spark.sql.cassandra")
.options(Map("keyspace" -> "myks", "table" -> "mytable", "spark.cassandra.output.ttl" -> "120"))
.mode("append")
.save()
//4
// <After quite some processing, mostly after the TTL, and in the calling code>
df.write.format("csv").save("some.csv")
在 Spark 找不到緩存數據(緩存查找失敗)的情況下,它是否有可能沿着譜系運行並運行 Cassandra 查詢?
對的,這是可能的。 緩存數據可以被緩存清理器移除(主要在MEMORY_ONLY
模式下),當相應的節點退役(崩潰、搶占、動態分配釋放)時可能會丟失。 此外,其他選項(如推測執行)可能會影響緩存行為。
最后,數據可能不會首先被完全緩存。
如果是,在所有情況下避免這種情況的方法是什么?
如果您需要強大的一致性保證,請不要使用cache
/ persist
——它的設計沒有考慮到像這樣的用例。 而是將數據導出到持久、可靠的存儲(如 HDFS)並從那里讀取。
您還可以將checkpoint
與 HDFS checkpointDir
一起使用。
您可能會傾向於使用更可靠的緩存模式,例如MEMORY_AND_DISK_2
- 這可能會降低重新計算數據的可能性,但代價是
df.rdd.cache()。 這與在數據幀上調用 cache() 有什么不同嗎?
它是不同的(主要區別是序列化策略),但在涉及此問題范圍內感興趣的屬性時則不同。
重要:
請注意,緩存行為可能不是您代碼中的最大問題。 在復雜的管道中讀取和附加到單個表可能會導致各種不受歡迎或未定義的行為,除非采取額外的步驟來確保讀取器不會選擇新寫入的記錄。
聲明:本站的技術帖子網頁,遵循CC BY-SA 4.0協議,如果您需要轉載,請注明本站網址或者原文地址。任何問題請咨詢:yoyou2525@163.com.