如何解决数据湖Gen2中ADF/Databricks地板Azure blob写入成本过高的问题

Question

我比较了将JSON文件加载到Data 2中的不同方式，但在每个测试场景中，blob存储成本都过高，由于“热写入操作”( blob计费中逐项列出)，blob存储成本预计为每月数千美元。

每日负载场景：

• 150个多行JSON文件，每个文件都带有1K
• 预先设置的分区键，用于垂直分区.

无论是数据工厂映射流、Synapse和Databricks: blob操作，无论是哪种方法，结果都是相似的:blob操作的成本是计算本身的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笔记本几乎和上面一样。在Data映射流程中，它是从JSON到Parquet的简单转换，没有其他步骤。我不得不使用映射流，因为标准复制活动不支持分区。

测试用例一次处理150个文件，但在现实生活中平均每小时处理7个文件，这使得解决方案更容易在白天生成更多的小文件。

在这些方法中，如何降低blob的编写成本，或者使用什么替代方法？我们已经验证了应用程序的读取性能是可以接受的，即使文件不经常压缩。问题完全是写作成本。

Answer 1

存储操作成本高是由于分区数量过高造成的。改变分区策略导致IO操作和成本的大幅减少。

Answer 2

我认为更好的解决方案是从源中摄取原生JSON格式的数据，然后只在特定的时间间隔(如一天结束时)压缩数据，这取决于您在一个单独的管道中的需求。