如何解决Data Lake Gen2中过多的ADF / Databricks镶木地板Azure blob写入成本

问题描述

我正在比较用镶木地板文件将JSON文件的蒸汽加载到Data Lake Gen 2的不同方式，但是在每个经过测试的方案中，blob存储成本都过高，由于“热写操作”，预计每月成千上万美元（在Blob结算中逐项列出）。

每日加载方案：

• 150个多行JSON文件，每个文件包含1K消息
• 用于垂直分区的5位预设分区键。

无论使用哪种方法，结果都是相似的：数据工厂映射流，Synapse和Databricks：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 Factory Mapping Flow中，这是从JSON到Parquet的简单转换，没有其他步骤。 由于标准复制活动不支持分区，因此我不得不使用“映射流”。

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

如何通过这些方法中的任何一种来减少Blob写入成本，或者有哪些替代方法？ 我们已经验证，即使文件不经常压缩，应用程序的读取性能还是可以接受的。问题纯粹是写成本。

解决方法

我认为更好的解决方案是从源中提取本机JSON格式的数据，然后仅在特定的时间间隔（如一天结束时）压缩它们，具体取决于您在单独的管道中的要求。

,

高存储操作成本是由于分区数量过多引起的。更改分区策略导致IO操作和成本大大降低。