壓縮編碼解碼器在Azure Data Lake中的影響

Question

很明顯，有很好的文檔證明，壓縮zip文件的能力對Hadoop中作業的性能和並行化有很大影響。

但Azure基於Hadoop構建，並且在Microsoft文檔中找不到任何可以找到此影響的地方。

這不是ADL的問題嗎？

是，例如，Gfix大文件現在可接受的方法，或者我會遇到同樣的問題無法平行我的工作，由於壓縮編解碼器的選擇？

謝謝

Answer 1

請注意，基於Hadoop的Azure Data Lake Analytics是而不是。

RojoSam是正確的，GZip是一種不好的壓縮格式來並行化。

U-SQL自動識別.gz文件並解壓縮它們。但是，壓縮文件的大小有4GB的限制（因爲我們無法分割和並行處理它），我們建議您使用幾個100MB到1GB區域內的文件。

我們正在努力添加Parquet支持。如果您需要其他壓縮格式，例如BZip：請在http://aka.ms/adlfeedback提交請求。

Answer 2

從任意位置開始讀取GZip文件是不可能的。有必要始終從頭開始閱讀。

然後，如果你有一個大的GZip（或其他不裂開的壓縮格式），您無法讀取/過程塊它並行，結束處理所有的文件順序在只有一臺機器。

Hadoop（和其他大數據替代品）的主要思想是依賴於不同機器中的並行流程數據。一個大的GZip文件不符合這種方法。

有一些數據格式，它允許數據頁使用gzip壓縮並保持文件可分裂（每一頁可以在不同的機器上加工，但每個GZip壓縮塊繼續需要僅在一個機器處理）等鑲木。