u-sql作業非常慢，當我添加一個.NET調用時

Question

代碼執行速度超過2000個小文件（〜10-50 Kb）〜1分鐘。 Parallelizm = 5

@arenaData = 
    EXTRACT col1, col2, col3 
    FROM @in 
    USING Extractors.Tsv(quoting : true, skipFirstNRows : 1, nullEscape : "\\N", encoding:Encoding.UTF8); 

@res = 
    SELECT col1, col2, col3 
    FROM @arenaData; 
    OUTPUT @res 
    TO @out 
    USING Outputters.Csv(); 

但是，如果我改變這樣的代碼需要約1小時

@arenaData = 
    EXTRACT col1, col2, col3 
    FROM @in 
    USING Extractors.Tsv(quoting : true, skipFirstNRows : 1, nullEscape : "\\N", encoding:Encoding.UTF8); 

@res = 
    SELECT 
     col1.ToUniversalTime().ToString("yyyy-MM-dd HH:mm:ss", CultureInfo.InvariantCulture) AS col1_converted, 
, col2, col3 

    FROM @arenaData; 
    OUTPUT @res 
    TO @out 
    USING Outputters.Csv(); 

爲什麼.NET調用這麼慢？我需要將源CSV文件中的日期格式轉換爲「yyyy-MM-dd HH：mm：ss」？我怎樣纔能有效地做到這一點？

Answer 1

很高興聽到你現在有更好的表現！

您的作業使用在託管代碼中執行的表達式運行在超過2800個非常小的文件上，而不是像U-SQL中一些更常見的C＃表達式那樣轉換爲C++。

這導致以下問題：

1. 你有一定數目的AU的開始你的工作。然後每個AU啓動一個YARN容器來執行部分工作。這意味着容器需要乾淨地初始化，這需要一些時間（您可以在Vertex Execution視圖中將其看作創建時間）。現在，這需要一點時間，如果頂點執行了大量處理，那麼這並沒有多大的開銷。不幸的是，在你的情況下，處理是一個小文件很快，所以有很大的開銷。

2. 如果頂點只執行我們編碼成C++代碼的系統生成的代碼，那麼我們可以重新使用容器而無需重新初始化時間。不幸的是，由於潛在的工件被遺留，我們無法重用一般用戶代碼，這些用戶代碼在託管運行時執行。所以在這種情況下，我們需要重新初始化需要時間的容器（超過2800次）。

現在根據您的反饋，我們正在改進我們的邏輯重新初始化（我們仍然可以重新初始化，如果你沒有做任何花哨的內聯C＃表達式）。另外，一旦我們可以在一個頂點內處理幾個小文件而不是每個頂點一個文件，它就會變得更好。

解決方法是爲您增加文件的大小，並可能避免自定義代碼（當然不總是可能的）在太多的頂點。