使用 dbt、Materialize 和 Metabase 管理流式分析管道

在上一篇文章中，我们详细介绍了如何使用 Materialize 和 Metabase 构建流式分析管道。简而言之，您可以针对流数据源编写 SQL，让 Materialize 在新数据到来时高效地保持结果的最新状态，并让您的仪表盘保持轻量和新鲜。这一次，我们将探讨如何使用 dbt 来端到端地管理和记录这个工作流程。

使用 dbt 转换流数据

尽管您希望不间断地运行分析，但您可能不想放弃那些让您在批处理中高效的工具。如果您可以使用完全相同的工具来管理流式分析管道呢？尽管 dbt 是为批处理而构建的，但它作为一个框架足够灵活，可以作为批处理和流处理后端之上的统一转换层；只要后端是基于 SQL 的，底层运行的具体内容就变成了实现细节。

我们构建了 dbt-materialize 适配器，将流式转换（及更多功能）引入 dbt。如果这看起来很熟悉……

 {{ config(
    materialized ='materializedview'
) }}
SELECT fi.icao24,
       manufacturername,
       model,
       operator,
       origin_country,
       time_position,
       longitude,
       latitude
FROM {{ ref('stg_flight_information') }} fi
JOIN {{ ref('stg_icao_mapping') }} icao ON fi.icao24 = icao.icao24

……就这些：您使用 SQL 和 Jinja 将业务逻辑定义为 dbt 模型，部署管道（一次），Materialize 就会为您保持其运行。对于那些本来需要您每天多次重新部署模型（$$）、维护复杂的增量逻辑并为了速度（例如，正确性）做出一些重大权衡的用例，使用像 Materialize 这样的专用流数据库可以带您走得更远、更快。

文档化流式分析管道

dbt 不仅标准化了我们思考和管理分析工作流程的方式，它还让文档变得再次“酷”起来（嗯，在 dbt 之前文档真的酷过吗？）。通过几个 YAML 文件，您可以将数据治理引入您的流式管道，加速数据发现和血缘等“救命”流程，甚至确保您的指标保持一致。如果倾向于将 dbt 项目视为业务逻辑和文档的单一真相来源，那么您的 BI 工具不也应该……保持同步吗？

如何同步 dbt 和 Metabase

如果您希望将 dbt 和 Metabase 更紧密地结合起来，dbt-metabase 插件是一个很好的起点。例如，您可以使用它来：

将 Metabase 项目记录为 dbt exposures

充分理解 dbt 项目的端到端依赖关系还需要能够跟踪外部依赖关系，例如 Metabase 问题和仪表盘。在 DAG 中跟踪这些依赖关系的一种方法是将任何下游模型的使用声明为 exposures（请注意橙色节点！），您可以使用插件自动生成。

a screenshot with a Metabase date picker

将 dbt 元数据传播到 Metabase 数据模型

如果您已经在 dbt 中记录了数据模型，该插件还允许您从现有模型属性和配置（例如表和列描述、语义类型定义以及其他有助于在数据生产者和消费者之间创建共享上下文的有用元数据）中派生 Metabase 数据模型。