所以我注意到，當呼叫 repartitionByCassandraReplica().JoinWIthCassandraTable() 時，SparkUI 的 Stages 選項卡中的輸入大小與 DirectJoin 始終打開時得到的輸入大小不同。我知道這兩個遵循不同的策略來確定 Spark 磁區：
呼叫 repartitionByCassandraReplica() 時，Spark 磁區的數量由 partitionsPerHost 決定。否則，連接器將使用估計的表大小。盡管如此，根據檔案，兩者都使用 DirectJoin 并且不執行對 Cassandra 表的完整掃描。
就我而言：
使用 DirectJoin 始終打開，我在 Input 列中得到36.9Gb大小，連接和計數需要4.5 分鐘。但是，使用 repartitionByCassandraReplica().JoinWIthCassandraTable() 處理相同的資料，我在3.4 分鐘內得到68.9Gb（幾乎翻倍）。
問題 1
如何為這兩種加入策略中的每一種計算階段選項卡的輸入列？DirectJoinAlwaysOn 是否使用estimated table size輸入列的大小和 repartitionByCassandraReplica.JoinWIthCassandraTable() 表的實際/精確大小？
問題2
為什么 repartitionByCassandraReplica.JoinWIthCassandraTable() 需要更少的時間，即使它有更大的輸入大小？僅僅是因為資料區域性嗎？
問題 3
最后，repartitionByCassandraReplica().JoinWIthCassandraTable() 最終會受到 Cassandra 表大小的影響嗎？這兩種不同策略中的 DirectJoin 是否有點不同（除了 Spark 磁區是如何計算的）？
uj5u.com熱心網友回復：
輸入大小是前一階段的導數。
要回答您的第一個問題，Direct Join 設定與 Spark 磁區的計算方式無關。重要的是你是否打電話repartitionByCassandraReplica()。
我在您之前的問題（使用 Spark-Cassandra-Connector 時 Spark 磁區會發生什么情況）中已經解釋過，Spark Cassandra 連接器根據您使用的 API 以不同方式計算 Spark 磁區。總結一下：
- 如果
repartitionByCassandraReplica()被呼叫，則 Spark 磁區partitionsPerHost的數量由本地 DC 中的 Cassandra 節點的數量決定。 - ELSE Spark Cassandra 連接器用于
input.split.size_in_mb根據估計的表大小確定 Spark 磁區的數量。
鑒于這兩種方案之間 Spark 磁區的數量差異很大，因此生成的輸出大小（資料讀取）也會有很大差異，因為映射到每個 Spark 磁區的 Cassandra 令牌范圍也會不同——它是不是蘋果對蘋果的比較。
作為旁注，我想提出一個友好的請求，即您應該限制每個帖子一個問題，特別是因為您的第二個和第三個問題與原始問題不同。干杯!
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/509910.html