我有一個相對較大的外部增量表，其中包含有關 ADLS gen2 位置的資料。此表按id和signal_date磁區
我每周在這個表上運行一個增量優化查詢。查詢如下圖。
對于少數磁區，我們可以看到優化運行超過 2 小時，如上所述。
對于一周的整個磁區，此作業運行超過 48 小時，并且必須在其間終止它才能繼續將資料加載到此表中。（否則在磁區上遇到并發操作失敗錯誤）
即使經過此優化，我仍可以在該磁區的 ADLS 位置看到許多小檔案，如下所示。
考慮到優化后小檔案的大量執行時間和可用性，在優化程序中是否發生了任何錯誤？
任何想法/觀點表示贊賞！
提前致謝。
uj5u.com熱心網友回復：
OPTIMIZE 完成后不會洗掉小檔案 - 它會創建一個參考新的更大檔案的新版本，并將舊的小檔案標記為已洗掉，但實際洗掉將在您運行VACUUM時發生。
這里執行了 OPTIMIZE 的事務日志示例：
{"add":{"path":"part-00000-5046c283-8633-4fe2-8c99-ada26908e2d0-c000.snappy.parquet",
"partitionValues":{},"size":1105,"modificationTime":1650281913487,
"dataChange":false,"stats":"{\"numRecords\":200,\"minValues\":{\"id\":0},\"maxValues\":{\"id\":99},\"nullCount\":{\"id\":0}}"}}
{"remove":{"path":"part-00002-57c4253a-5bdc-4d3e-9886-601fa793cdf6-c000.snappy.parquet",
"deletionTimestamp":1650281912032,"dataChange":false,
"extendedFileMetadata":true,"partitionValues":{},"size":536}}
...other remove entries...
{"commitInfo":{"timestamp":1650281913514,"operation":"OPTIMIZE",
"operationParameters":{"predicate":"[\"true\"]"},"readVersion":1,
"isolationLevel":"SnapshotIsolation","isBlindAppend":false,
"operationMetrics":{"numRemovedFiles":"16","numRemovedBytes":"8640","p25FileSize":"1105","minFileSize":"1105","numAddedFiles":"1","maxFileSize":"1105","p75FileSize":"1105","p50FileSize":"1105","numAddedBytes":"1105"},
"engineInfo":"Apache-Spark/3.2.1 Delta-Lake/1.2.0",
"txnId":"31a68055-7932-4266-8290-9939af7e6a84"}}
轉載請註明出處，本文鏈接：https://www.uj5u.com/caozuo/459739.html