就我而言，資料駐留在火花表中，這些表是通過在資料幀上呼叫 createOrReplaceTempView API 創建的。創建表后，將在表頂部運行多個查詢。大多數情況下，where 查詢將基于特定列。相關列的名稱是已知的。我想知道是否可以進行某種優化來提高過濾器查詢的性能。我嘗試探索索引的方法，但結果是 spark 不支持索引特定的列。
uj5u.com熱心網友回復：
您是否查看過 SPARK UI 以了解您的大部分時間都花在了哪些地方？真的是大部分時間都花在了查詢上嗎？通常從磁盤讀取資料是花費大部分時間的地方。學習閱讀 SPARK UI 并找出真正的瓶頸所在。SQL 選項卡是開始解決問題的絕佳方式。
以下是適用于大多數作業的一些在 Spark 中運行得更快的技巧：
你能重新定義問題嗎？ 您使用的資料的格式是否有助于您解決查詢？你能改變它的寫作方式來改變問題嗎？（您是否可以在查詢資料之前開始“預咀嚼”資料以使其以最佳格式存盤以幫助您解決您想要解決的問題？）大多數性能提升來自更改問題的引數以使其成為更容易/更快地解決。
您存盤資料的格式（是傳入資料）是什么？ 你在使用 Parquet/Orc 嗎？它們具有值得使用的巨大回報磁盤空間/壓縮。他們還可以啟用檔案級過濾器以加快讀取速度。他們的轉換作業是否可以推動上游以幫助減少查詢的作業量？您可以通過有助于查找的磁區模式寫入資料嗎？
您輸入了多少個檔案？您能否合并檔案以最大化讀取吞吐量。讀取/列出大量小檔案作為輸入會減慢資料處理速度。
如果 tempView 查詢每次都具有相似的大小，您可以查看調整磁區數，使檔案更小，但大約與 HDFS 塊大小相同。（假設您使用的是 hdfs）。HDFS 你必須讀取整個塊天氣你使用的所有資料與否。嘗試將其與您的多個執行者相匹配，以便您一起完成而不是分散。這很難做到完美，但你可以大踏步地找到一個好的比例。
uj5u.com熱心網友回復：
無需使用火花優化過濾條件。spark 已經足夠聰明，可以優化其條件 post where 查詢首先獲取最少行。我猜你能做的最好的事情就是在一次又一次地查詢同一個視圖時保留你的 TempView。
轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/401928.html