Я сравниваю разные способы загрузки пара файлов JSON в Data Lake Gen 2 с паркетными файлами, но в каждом протестированном сценарии затраты на хранение больших двоичных объектов являются чрезмерными, прогнозируемыми в тысячи долларов в месяц из-за «операций горячей записи» (перечисленных в blob биллинг).
сценарий ежедневной нагрузки:
- 150 многострочных файлов JSON, каждый по 1К сообщений
- Предварительно установленный 5-значный ключ раздела для вертикального разделения.
Результаты одинаковы вне зависимости от метода: потоки сопоставления фабрики данных, синапсы и блоки данных: операции с большими двоичными объектами стоят в 3-5 раз дороже, чем сами вычисления. Даже при запуске в одном пакете для каждого ключа вертикального раздела создается несколько паркетных файлов. Конечно, со временем это нужно будет сжать, чтобы оптимизировать производительность чтения, но уже непосредственные затраты на запись вызывают вопросы о подходе.
Вот пример кода Databricks:
file_location = "abfss://files@<storageaccountname>.dfs.core.windows.net/<foldername>/*.json"
df = spark.read.option("multiline", "true").json(file_location)
df.repartition('PartitionKey')
df.write.partitionBy('PartitionKey').parquet('abfss://files@<storageaccountname>.dfs.core.windows.net/Results)
Блокнот Synapse почти такой же, как и выше. В потоке сопоставления фабрики данных это простое преобразование из JSON в Parquet без каких-либо других шагов. Мне пришлось использовать Mapping Flow, поскольку стандартное копирование не поддерживает разделы.
Тестовый пример обрабатывает 150 файлов за один раз, но в реальной жизни это будет в среднем 7 файлов в час, что делает решение более склонным к созданию большего количества небольших файлов в течение дня.
Как можно снизить затраты на запись большого двоичного объекта с помощью любого из этих подходов или какие есть альтернативы? Мы уже подтвердили, что производительность чтения для приложений приемлема, даже если файлы не часто сжимаются. Вопрос чисто в расходах на запись.
