2017-04-10 107 views
1

我處於類似於the one mentioned here的情況。這個問題沒有得到滿意的回答。此外,我處理的數據較少(每天大約1G)。將數據添加到存儲在磁盤上的Spark/Parquet數據

我的情況:我已經有一定數量的可用作拼花地板的數據(〜500G)(即已達成一致的「存儲格式」),並獲得定期增量更新。我希望能夠處理ETL部分以及之後的分析部分。

爲了能也有效地產生某些「中間數據產品」的更新,我看到三個選項:

  • 保存與追加模式,保持差異數據集左右,直到所有數據產品被創造
  • 保存與追加模式,增加一個額外的列upload_timestamp
  • 每次更新保存到一個分隔符Ë文件夾,例如:

    data 
    +- part_001 
    | +- various_files.parquet 
    +- part_002 
    | +- various_files.parquet 
    +- ... 
    

    這樣,整個數據集可以使用data/*作爲路徑read.parquet()讀取。

我趨向於過去的做法,也因爲有評論(證據)指出追加模式導致的問題時,分區的數量增長(參見例如this SO question)。

所以我的問題:是否有創建這樣的數據集結構的一些嚴重的缺陷?顯然,Spark需要在閱讀多個文件夾時進行「一些」合併/排序,但除此之外呢?

我正在使用Spark 2.1.0。

回答

0

彌敦道馬茲,以前的Twitter和Lambda Architecture的作者,描述垂直分區的在料層,這是真理的來源,幷包含結構從未見過的所有數據存儲數據的過程。這個主數據集是不可變的,只能追加。垂直分區只是將數據分類到單獨的文件夾中的一個奇特名稱。

這正是你在第三個選項中描述的。

這樣做會顯着提高性能,因爲在主數據集上執行的功能只會訪問與計算相關的數據。這使批處理查詢和服務層中索引的創建速度更快。文件夾的名稱取決於您,但通常涉及時間戳組件。

無論您是否在構建Lambda架構,垂直分區都會使您的分析更加高效。

+0

很好,謝謝!儘管如此,我並沒有完全回答我的問題。問題相當的是:如果文件夾的數量(data /'下面)增加很多,是Spark的問題嗎? –

+0

我的確回答了這個問題。最簡潔的答案是不;上面的長答案解釋了原因。 Spark團隊意識到人們擁有大量數據並對其進行了解釋。垂直分區方法有助於根據給出的原因優化這些分析。 – Vidya

相關問題