Question

我目前正在探索由databricks开源的三角洲湖泊。我正在读取kafka数据，并使用delta lake格式将其写入流中。 Delta Lake在从kafka进行流式写入期间创建了许多文件，这让我感到很高兴。HDFS文件系统。

我已尝试按照以下步骤将多个文件压缩为单个文件。

val spark =  SparkSession.builder
    .master("local")
    .appName("spark session example")
    .getOrCreate()

  val df = spark.read.parquet("deltalakefile/data/")

  df.repartition(1).write.format("delta").mode("overwrite").save("deltalakefile/data/")
  df.show()

  spark.conf.set("spark.databricks.delta.retentionDurationCheck.enabled","false")

  DeltaTable.forPath("deltalakefile/data/").vacuum(1)

但是当我检查输出时，它正在创建新文件，而不是删除任何现有文件。

是否有办法实现这一目标。另外，保留期限的关系是什么？使用时如何在HDFS中配置它？当我想以三角洲湖泊格式构建原始/青铜层并且要长时间保留所有数据（在建筑物中存放多年/在云中无限时间）时，应保留的配置是什么？

Answer 1

根据设计，Delta不会立即删除文件以防止影响活动的使用者。它还提供了版本控制（又名时间旅行），因此您可以在必要时查看历史记录。要删除以前的版本或未提交的文件，您需要运行vacuum。

import io.delta.tables._

val deltaTable = DeltaTable.forPath(spark, pathToTable)

deltaTable.vacuum() // use default retention period

关于如何管理青铜/银/金模型的保持力和压实度的问题，您应该将着陆台（也称为青铜）视为仅附加日志。这意味着您不需要执行压缩操作，也不需要在之后进行任何重写。青铜表应该是您从上游数据源（例如Kafka）中提取的数据的记录，并且只需进行最少的处理。

青铜表通常用作增量流源，以填充下游数据集。鉴于从Delta读取是从事务日志中完成的，因此与使用执行缓慢文件列表的标准文件读取器相比，小文件不是一个问题。

但是，当您将文件写入青铜表时，仍然有一些选项可以优化文件：1）在写给Delta时，首先通过重新分区以减少文件数量来压缩Kafka消息，2）增加文件数量触发间隔，因此提取操作的频率降低，并且正在将更多消息写入较大的文件。

Delta Lake Compacting将多个文件压缩为单个文件

1 个答案: