Sign in Subscribe

SoloLakehouse Post-Medallion Experiment Roadmap

Last updated on 
Hiring Manager Signal: Medallion Architecture 是入门票，下面的实验才是 100k+ 的区分点。 招聘经理看到的不是"你搭了一个平台"，而是"你能用平台解决业务问题、量化影响、防止数据质量事故"。 每个实验完成后，请用一句话描述业务影响，而非技术实现。

思维框架：从工程师到平台架构师

工程师思维 平台架构师思维
"我把数据从 Bronze 写到了 Silver" "我设计了数据促进合约，任何下游消费者都可以信任 Silver 层的质量 SLA"
"我搭了 MLflow" "我建立了模型生命周期治理，模型上线前必须通过质量门禁"
"Trino 查询跑起来了" "我实现了多引擎联邦查询，计算与存储解耦，引擎可以独立扩展"

每个实验结束后，写一段 ADR（Architecture Decision Record）。这是区分高级工程师的核心信号。

Phase 1：数据质量与可观测性（第 1-2 周）

目标：让 Medallion 每一层有"数据合约"，而不是靠人工检查质量

Experiment 1.1 — Data Quality Gate（数据质量门禁）

问题：当前 Bronze → Silver 的提升是否有质量保证？还是盲目写入？

实验内容：

  1. 在 Bronze → Silver 的 PySpark job 中，加入 Great Expectations 或 Soda Core 校验
  2. 定义至少 5 条规则：non-null、type check、value range、uniqueness、referential integrity
  3. 质量检查失败时，数据停留在 Bronze，写入 quarantine 分区，不晋升 Silver
  4. 在 Grafana 中增加 Dashboard：每次 pipeline run 的质量通过率

验收标准：

  • [ ] 故意注入脏数据，验证 quarantine 分区生效
  • [ ] Grafana 能看到 data quality score 随时间变化
  • [ ] 写一份 ADR：为什么选择 Great Expectations vs Soda Core

招聘经理视角：这是 regulated industry（金融、医疗、政府）的硬性要求，展示你懂数据治理而非只懂管道。

Experiment 1.2 — Pipeline Observability（管道可观测性）

问题：当前 pipeline 失败时，你如何知道？在哪一步失败？数据量是否异常？

实验内容：

  1. 在每个 PySpark ETL job 中，提取并写入 pipeline metrics 到 Postgres：
    • run_id, layer（bronze/silver/gold）, rows_in, rows_out, rows_rejected, duration_sec, status
  2. 在 Grafana 创建 Pipeline Observability Dashboard：
    • 每层行数趋势（数据量异常检测）
    • 处理时长趋势
    • 成功/失败比率
  3. 用 Airflow 的 callback（on_failure_callback）实现告警（写入 log 或发邮件）

验收标准：

  • [ ] 运行 5 次 pipeline，在 Grafana 能看到时间序列数据
  • [ ] 模拟一次 Silver job 失败，告警被捕获

招聘经理视角：没有可观测性的数据平台是"黑箱工程"，这个实验证明你以运维视角设计系统。

Phase 2：引擎集成与性能（第 3-4 周）

目标：证明你的平台是多引擎架构，不是单点工具堆叠

Experiment 2.1 — 多引擎联邦查询基准测试

问题：Trino vs DuckDB vs PySpark 在不同查询模式下的性能差异？什么场景用什么引擎？

实验内容：

  1. 在 Gold 层准备一个真实数据集（建议用你的 Frankfurt Airport taxi prediction 数据，或公开的 NYC Taxi 数据）
  2. 设计 3 类查询：
    • 大扫描（full table scan, aggregation）
    • 复杂 JOIN（多表关联）
    • 点查询（按 ID 或时间范围过滤）
  3. 分别用 Trino、DuckDB（通过 Python）、PySpark 执行相同查询，记录：
    • 查询时间、CPU/内存占用、引擎启动开销
  4. 输出一份 Engine Selection Matrix（哪种工作负载选哪个引擎）

验收标准：

  • [ ] Jupyter Notebook 包含完整的基准测试代码和结果
  • [ ] 写成 README 中的 "When to Use Which Engine" 决策指南

招聘经理视角：平台架构师的标志是知道为什么选择这个工具，而不是"只会用一个锤子"。

Experiment 2.2 — Iceberg Time Travel & Schema Evolution

问题：当 Gold 层 schema 发生变化（比如新增列），下游 Trino 查询是否无感知？历史数据可以回溯吗？

实验内容：

  1. 向 Silver 或 Gold Iceberg 表中写入 v1 数据（schema A）
  2. 用 ALTER TABLE ADD COLUMN 进行 schema 演化，写入 v2 数据（schema B）
  3. 用 Trino 执行 Time Travel 查询：SELECT * FROM table FOR SYSTEM_TIME AS OF TIMESTAMP '...'
  4. 验证：
    • v1 时刻的数据没有新列（或填充 NULL）
    • v2 时刻的数据包含新列
    • Spark 与 Trino 对同一份 Iceberg 表的读取结果一致

验收标准：

  • [ ] 时间旅行查询返回正确的历史状态
  • [ ] 写一份 ADR：Iceberg Time Travel 对数据审计的意义

招聘经理视角：这是 Databricks 的核心卖点之一，你能在自建平台上实现同等能力，直接对标 Databricks 认证内容。

Phase 3：ML 平台集成（第 5-6 周）

目标：把 Medallion Architecture 和 ML 生命周期连接起来，实现端到端闭环

Experiment 3.1 — Feature Engineering Pipeline（Gold → Feature Store）

问题：Gold 层的聚合数据如何变成可复用的 ML 特征？

实验内容：

  1. 选择一个预测任务（建议用 Frankfurt Airport 的时间预测数据）
  2. 在 Gold 层基础上，用 PySpark 计算特征（滑动窗口统计、时间编码、lag features）
  3. 将特征写入 Feast Feature Store（如未安装，先用简单的 Iceberg Feature Table 模拟）
  4. 用 MLflow 追踪：使用了哪个版本的特征集训练了哪个模型

验收标准：

  • [ ] 训练数据可以通过特征版本号追溯到具体的 Gold 层数据快照
  • [ ] MLflow Experiment 记录：feature_set_version、数据集大小、模型指标

招聘经理视角：特征与模型的版本绑定是 MLOps 成熟度的核心指标，金融/医疗行业的必要要求。

Experiment 3.2 — Model Quality Gate（模型上线门禁）

问题：新训练的模型应该满足什么条件才能被"提升"到 Production？

实验内容：

  1. 在 MLflow 中定义模型晋升规则（用 MLflow Model Registry）：
    • Staging → Production 需要：accuracy > baseline_threshold AND no data drift detected
  2. 用 Python 脚本实现自动化检查：
    • 对比新模型 vs 当前 Production 模型的指标
    • 如果新模型更好，自动标记为 Staging，生成审批记录
  3. 在 Airflow 中添加一个 model_promotion_dag，每次模型训练完成后自动触发

验收标准：

  • [ ] 故意训练一个差模型，验证门禁阻止它晋升 Production
  • [ ] MLflow UI 中能看到清晰的 Staging/Production 状态历史

招聘经理视角：这直接对应 Databricks ML Professional 认证的核心概念，也是 FinLakehouse 的 AI Governance 基础。

Phase 4：治理与合规（第 7-8 周）

目标：向 FinLakehouse 演化，证明你能构建 regulated AI 平台

Experiment 4.1 — Data Lineage 追踪

问题：Gold 层的一条数据，是从哪个 Bronze 文件的哪个行演化来的？

实验内容：

  1. 将 lineage 写入 Postgres 的 data_lineage 表
  2. 实现一个简单的 lineage 查询 API（用 FastAPI）：输入一个表名，返回其上游依赖链

在每个 ETL job 中，写入 lineage metadata：

{  "target_table": "gold.aggregated_metrics",  "source_tables": ["silver.cleaned_events", "silver.reference_data"],  "transformation_job": "silver_to_gold_v2.py",  "run_id": "airflow_run_20260220",  "row_count": 15234}

验收标准：

  • [ ] 能查询到 gold.aggregated_metrics 的完整上游依赖
  • [ ] API 返回 JSON，可以作为 FinLakehouse 的 governance API 基础

招聘经理视角：Data Lineage 是 GDPR / DORA 合规的核心能力，也是 Unity Catalog 的核心卖点。你自建了等价能力。

Experiment 4.2 — Audit Log（操作审计日志）

问题：谁在什么时间查询了哪张表？这是金融监管的硬性要求。

实验内容：

  1. 在 Trino 前面配置 Trino Event Listener，捕获所有查询事件
  2. 将查询日志（user、query_sql、tables_accessed、execution_time、status）写入 Postgres
  3. 在 Grafana 创建 Audit Dashboard：
    • Top 10 most queried tables
    • Query volume by time of day
    • Failed query rate

验收标准：

  • [ ] 执行 10 次不同查询，在 Audit Dashboard 中全部可见
  • [ ] 写一份文档：这如何满足 MiFID II 的数据访问审计要求

招聘经理视角：这是 FinLakehouse 的直接组件，也是你向 regulated AI 平台方向最有力的作品集证明。

里程碑总结与作品集打包

完成上述实验后，你的 SoloLakehouse 将具备：

能力 Databricks 对标 你的实现
数据质量 Delta Live Tables Expectations Great Expectations + Quarantine Layer
管道可观测性 Databricks Workflows 内置 Prometheus + Grafana + Postgres Metrics
多引擎查询 Databricks SQL + Photon Trino + DuckDB + Spark
Schema 演化 Delta Lake Schema Evolution Iceberg Schema Evolution + Time Travel
特征工程 Databricks Feature Store Feast / Iceberg Feature Tables + MLflow
模型治理 MLflow Managed Registry 自建 Model Quality Gate + Airflow DAG
数据血缘 Unity Catalog Lineage 自建 Lineage API (FastAPI + Postgres)
审计日志 Unity Catalog Audit Trino Event Listener + Audit Dashboard

这8项能力，就是你在面试中说"我建了一个 Databricks 等价平台"的底气。

每个实验完成后的标准产出

  1. 代码：提交到 GitHub，有清晰的 commit message
  2. ADR：docs/adr/XXX-decision-name.md（一页纸，说明背景、决策、权衡）
  3. README 更新：在项目 README 的 Roadmap 中打勾
  4. 一句话业务描述：能够解释这个实验解决了什么业务问题（不是技术问题）
对 100k+ offer 的影响：High。能自建数据治理、ML 治理、审计能力的工程师， 在金融/医疗/政府领域稀缺。这些实验直接对应 Senior Data Engineer / ML Platform Engineer 的 JD。