我是在创建青铜表还是白银表？答案

【问题标题】：Am I creating a Bronze or a Silver table?我是在创建青铜表还是白银表？
【发布时间】：2021-03-25 14:11:09
【问题描述】：

据我了解，Delta Lake 架构中的青铜表以表格式表示原始和（或多或少）未修改的数据。这是否意味着我也不应该对青铜表的数据进行分区？您可以将分区视为取决于用例的东西，它指向 Silver 甚至 Gold 表。

看这个例子：

def read():
    return spark.read\
        .format("csv")\
        .option("delimiter", "\t")\
        .option("header", True)\
        .load("file.tsv.gz")

table_name = "file"
location = f"/mnt/storage/{table_name}"

read().write.partitionBy("something").format("delta").save(location)

spark.sql(f"CREATE TABLE {table_name} USING DELTA LOCATION '{location}/'")

注意partitionBy("something")。这属于青铜表吗？

【问题讨论】：

标签： databricks delta-lake

【解决方案1】：

一般来说，我建议不要在青铜层中按谓词进行分区。您应该使用OPTIMIZE 来维护“大小合适”的文件以供后续读取，而不会在数据在存储中的组织方式上引入额外的偏差。

分区和Z-Ordering 可以通过改进数据跳过来加快读取速度。然而，在您选择要划分的谓词中隐含的是一些业务逻辑。这可能会给您的数据带来某种形式的偏差，并可能在您的管道中产生意想不到的下游影响。 “青铜”的概念是简单地将数据按原样降落在湖中，尽可能少地改变。

这可能有例外，但这些是一般考虑因素。

【讨论】：

原来如此，所以和我的理解差不多。
我现在正在与 Databricks 的队友讨论这个问题，所以我可能会用其他一些想法来更新答案。敬请期待。
嗨@RaphaelK，你能详细说明一下吗？比如，划分青铜层会导致什么“意外的下游效应”？我正在寻找建议和做法。
当然。如果您按 clientID 与日期进行分区，那么青铜层的下游查询的性能将取决于它们在 where 子句中使用的谓词。例如，如果您的所有下游查询在 where 子句中都有一个日期，那么按日期分区将为您提供最佳性能。按客户端 ID 进行分区将导致更差的数据跳过，从而导致更长的查询时间。如果你总是按日期查询，那么按日期分区是有意义的，但你怎么知道你总是按日期查询呢？因此，不要仅依靠“大小合适”的文件来分区青铜。