Apache Spark + Delta Lake 概念

Apache Spark + Delta Lake concepts

我对Spark + Delta有很多疑惑。

1) Databricks 提出了 3 层(青铜、白银、黄金),但建议将哪一层用于机器学习,为什么?我想他们建议在黄金层中清理并准备好数据。

2) 如果我们抽象这3层的概念,我们是否可以将铜层视为数据湖,将银层视为数据库,将金层视为数据仓库?我的意思是在功能方面,.

3) Delta架构是一个商业术语,还是Kappa架构的演进,或者是像Lambda和Kappa架构一样的新趋势架构? (Delta + Lambda 架构)与 Kappa 架构之间有什么区别?

4) 在许多情况下,Delta + Spark 的规模比大多数数据库要大得多,而且通常要便宜得多,而且如果我们调整得当,我们可以获得几乎快 2 倍的查询结果。我知道将实际趋势数据仓库与 Feature/Agg 数据存储进行比较非常复杂,但我想知道如何进行这种比较?

5) 我曾经使用 Kafka、Kinesis 或 Event Hub 进行流处理,我的问题是如果我们将这些工具替换为 Delta Lake table(我已经知道一切都取决于很多事情,但我想对此有一个大致的了解。

1) 交给您的数据科学家。他们应该在白银和黄金地区工作得心应手,一些更高级的数据科学家将希望返回原始数据并解析出可能未包含在 silver/gold 表中的其他信息。

2) 青铜 = 原生 format/delta lake 格式的原始数据。 Silver = delta lake 中经过消毒和清理的数据。 Gold = 通过 delta lake 访问或推送到数据仓库的数据,具体取决于业务需求。

3) Delta 架构是 lambda 架构的简单版本。 Delta 架构在这一点上是一个商业术语,我们将看看未来是否会发生变化。

4) Delta Lake + Spark 是最具扩展性的数据存储机制,价格合理。欢迎您根据您的业务需求测试性能。 Delta lake 的存储成本将远低于任何数据仓库。您对数据访问和延迟的要求将是更大的问题。

5) Kafka、Kinesis 或 Eventhub 是从边缘到数据湖获取数据的来源。 Delta lake 可以充当流应用程序的源和汇。使用 delta 作为源实际上很少有问题。 Delta Lake 源位于 blob 存储上,因此我们实际上解决了基础设施问题的许多问题,但增加了 blob 存储的一致性问题。作为流作业来源的 Delta Lake 比 kafka/kinesis/event 集线器更具可扩展性,但您仍然需要这些工具将数据从边缘获取到 Delta Lake。

  1. medallion table 是根据我们的客户使用 Delta lake 的方式推荐的。您不必完全遵循它;但是,它确实与人们设计 EDW 的方式非常吻合。至于机器学习和使用哪个table。这将是从事机器学习的人们的选择。有些人可能想要访问 Bronze tables,因为那是原始数据,没有对其进行任何处理。其他人可能想要 Silver table,因为它被认为是干净的,尽管是增强的。通常,Gold table 是高度精炼的,并且专门用于回答定义明确的业务问题。

  2. 不完全是。青铜 table 是原始事件数据,例如每个事件或测量等一行。银牌 table 也处于 event/measurement 级别,但它们经过高度改进,可以用于查询、报告、仪表板等。金牌 table 可以是事实和维度 tables、聚合 tables 或精选数据集。重要的是要记住,Delta 并不打算用作跨国的 OLTP 系统。它真正适用于 OLAP 工作负载。

  3. Delta 架构是我们为 Delta Lake 的特定实现命名的。它本身不是商业术语,但希望它成为一个商业术语。那里有足够的信息来比较和对比 Kappa 和 Lambda 架构。 Delta 架构在 Delta 文档和 Databricks 博客、技术讲座、YouTube 视频等中都有很好的定义。

  4. 请问你到底想比较什么?速度、功能、产品……?

  5. Delta Lake 并没有试图取代任何消息 pub/sub 系统,它们有不同的用例。 Delta Lake 可以连接到您作为订阅者和发布者提到的每个产品。不要忘记 Delta Lake 是一个开放的存储层,它为数据湖带来了符合 ACID 的交易、高性能和高可靠性。

路易.