数据处理工作流

End-to-End ELT Data Pipeline：基于 Databricks Delta Lake 与 DLT 的端到端数据管道

zapanss/End-to-End-ELT-Data-Pipeline-with-Databricks-Delta-Lake-DLT-dbt-Ready-Gold-Models · 🚀 Build a production-ready ELT data pipeline on Databricks, leveraging Delta Lake and DLT for efficient data ingestion, transformation, and modeling.

GitHub原文发布未知首次收录 2026-10-06上架 2026-10-06 07:02

☆ 收藏查看项目 ↗

ELI5：它是什么，解决什么问题

该项目提供了一个基于 Databricks 的生产级 ELT 数据管道实现，涵盖 Auto Loader 数据接入、Delta Live Tables (DLT) 转换、基于 CDC 的 Silver 层建模以及动态 Gold 层维度与事实表构建。支持的 dbt 集成用于数据转换和灵活建模，涉及 Bronze-Silver-Gold、SCD 等数据工程常见模式。仓库以 Jupyter Notebook 为主要载体，附带系统要求说明与相关资料链接。

# Databricks # Apache Spark # data-engineering # dbt # delta-lake

核心能力与快速开始

★ 3 · Jupyter Notebook

能做什么: 提供基于 Databricks 的端到端 ELT 数据管道实现，使用 Auto Loader 进行数据接入，采用 Delta Live Tables (DLT) 进行转换处理，包含基于 CDC 的 Silver 层模型，并构建动态的 Gold 层维度表与事实表以支持分析。支持通过 dbt 进行数据转换和建模集成，涉及 Bronze-Silver-Gold 分层架构与 SCD（缓慢变化维度）处理模式。
适用场景: 适用于希望在 Databricks 平台上搭建生产风格 ELT 数据管道的场景，包括数据接入、清洗转换、CDC 增量处理、数据仓库分层建模（Bronze/Silver/Gold），以及使用 dbt 做数据转换与维度建模的团队。
项目形态: 研究实现
部署方式: 未说明
主要依赖: README 中提及操作系统为 Windows 10、macOS 或 Linux；硬件建议最低 8 GB RAM 和 2 CPU 核心；软件需 Java Runtime Environment 以及最新版本的 Databricks。
使用限制: 仓库以 Jupyter Notebook 为主；README 未提供具体的安装步骤命令、依赖版本、Databricks 集群配置或 API 成本说明。
许可证: Apache-2.0
最近推送: 2026-10-05 13:48

核对 README 依据 ↗

资料检查：2026-10-06 07:00 · 卡片整理：2026-10-06 07:00
卡片由 AI 根据仓库资料整理，未进行安装或运行验证 · 本次更新未完成，保留上次成功内容

职业应用

程序员

作为数据工程参考实现，程序员可学习并复用其基于 Databricks 的 ELT 管道代码，包括 Auto Loader 数据接入、Delta Live Tables 转换、CDC 建模以及 dbt 集成，用于构建或排错生产级数据管道。

查看内容依据

This project provides a production-ready ELT data pipeline built on Databricks. It makes use of Auto Loader, Delta Live Tables (DLT), and CDC-based Silver models.

官方使用入口 ↗

由 AI 根据来源材料整理，未进行安装或运行验证

相似资源

open311-pipeline：芝加哥 311 市民服务请求的流式 LLM 紧迫度分类与数据仓库流水线

该项目是一个可复用的「流 → 分类 → 数据仓库 → 建模」市民数据流水线模板：轮询 Open311（芝加哥 311）请求，写入按 service_request_id 分键的 Kafka，用 Claude Haiku 4.5 对请求做结构化输出的紧迫度分级（每次调用在 Langfuse 中留有 trace），失败进入死信队列，再通过幂等 MERGE 写入 DuckDB（默认）或 Snowflake，最后由 dbt 构建部门 SLA 合规度数据模型。项目提供无需账号、无需 API key 的本地演示（make demo-local / make demo-local-nokafka），演示回放 300 条真实芝加哥 311 请求及其由 Claude Haiku 4.5 标注的标签；另有一条路径可从城市数据门户加载整个财年（约 212 万行）并测量整体队列的 SLA 合规度。仓库含 61 个 pytest 测试与 45 个 dbt 数据测试，覆盖 schema 漂移、DLQ、MERGE 幂等性等失效模式。README 明确指出其 SLA 阈值为项目自设而非芝加哥官方标准。

SprintHack@ND 2026：Goodwill 电商报表分析黑客松项目文档与智能体构建计划

该仓库是 SprintHack@ND 2026 黑客松的项目资料集合，围绕 Goodwill Michiana 电商报表分析场景，包含本地范围说明、指标字典、v1 契约、开发快速入门（可运行的 Python/SQLite CLI/API）、合成企业数据包、演示数据与验证证据、展示幻灯片与讲解视频，以及面向编码智能体并行开发的周末执行计划。材料还包含获取、数据流水线、仪表盘、AI、QA/演示与生产路线图的子任务 PRD，以及归档的其他 PRD 和会议笔记。仓库以 HTML 为主，未见具体开源许可证说明。

Databricks 的原生监控资源

Databricks 官方发了一篇指南，讲怎么收集 Databricks 和它底层 Spark 的运行数据（比如性能、成本、用量）。之前这些数据分散在各处，用户不容易统一查看和排查问题。这次介绍的方法主要是用系统表来查询日志、成本和性能指标，再配合 Spark UI、作业通知和 REST API，就能做分析和告警。不过要注意，系统表的数据不是实时的，延迟随 schema 不同，所以不能拿它做秒级告警；实时监控得靠作业通知和 API。

Netflix 通过工作负载证明打通 AWS IAM 与内部身份体系

Netflix 为跑在 Amazon EMR 上的 Apache Spark 任务做了一套“工作负载证明”机制。打个比方：过去托管计算任务要访问内部服务，得把内部凭证直接塞给任务，凭证容易泄露、也难管理。现在的做法是先确认这个任务的 AWS IAM 身份，再核对 Netflix 控制面签发的声明，两者都通过后，才发一张有效时间很短的内部 X.509 证书，任务用它去访问内部服务。这样托管计算任务不必直接携带凭证，就能安全地完成内部认证，凭证暴露的风险和分发负担都小了。这套机制目前应用在 Netflix 的 Spark/EMR 场景，其他场景是否适用文中未说明。

这是基于来源内容整理的摘要。原文链接失效后，本页摘要和讨论仍会保留。