数据仓库-湖仓一体-Lakehouse-设计范式

设计模式

1. 数据仓库 设计模式
   传统数仓分层（ODS/DWD/DWS/ADS）

2. 湖仓一体 设计模式 Medallion-medallion架构(bronze→ silver→ gold) databricks 主推
   接入契约 保证原始数据捕获、不可变性及完整审计元数据
   校验契约 强制执行显式 Schema、类型转换和数据清洗规则
   业务逻辑契约
   Is Three Contracts, Not Three Layers
   底层依赖 Delta Lake 提供可靠性和性能，Unity Catalog 提供细粒度治理，统一承载数仓、工程、流处理、AI 四类工作负载。
   奖牌架构(medallion architecture)-一种多跳架构
   Bronze = 原始、不可变、只追加；绝不就地转换
   Silver = 清洗、去重、统一；必须可跨域 join
   Gold = 业务就绪、聚合、有 SLA 保障；针对查询模式优化
   三种奖牌或层：铜牌、银牌和金牌
   铜牌：
   银牌：银牌层：银牌层提供经过过滤、清理、结构化、标准化和（重新）建模的数据
   金牌层：该层提供“业务级”和“应用程序对齐”的数据
   解决的问题

   默认的前提：多跳奖牌模型以一个拉取系统为前提，填充铜牌层需要大量的数据复制和处理能力
   Lakehouse 弹性计算、按需建模的理念一致-Gold 层 = DWS + ADS 的合并
   信任难以建立，又容易崩塌-信任在业务中至关重要

Data Mesh 的底层实现机制

Data Mesh
‌ Data Fabric‌：以技术为中心，构建虚拟统一层来连接分散数据，不改变组织架构。
‌ Data Mesh‌：以组织和方法论为中心，需要去中心化的组织变革，强调领域自治
Medallion 奖牌架构存在根本性缺陷，应被 "左移 + 数据产品" 范式取代
把下游已经在做的清洗 / 标准化 / 建模工作推到上游源端做一次
流模式（Kafka 主题）→ 服务运维 / 实时应用
表模式（Iceberg/Parquet）→ 服务分析 / BI/ML
把工作重新分配给最懂数据的人—— 源系统团队
把清洗 / 标准化 /schema 治理推到源端做
拉模式（消费者主动拉） 推模式（生产者主动交付）
数据产品必须有 Owner

三大云厂商

AWS、 Amazon Web Services
Azure
Google 谷歌自己旗下就有 Redshift，Azure Synapse Analytics，Bigquery等产品

云数仓市场

vendor-lockin（供应商锁定）
Snowflake
databrick 业务基础 Apache Spark
Confluent 业务基础Apache Kafka
数据库
Apache Doris
ClickHouse

云计算、大数据和AI应用

阿里云、华为云、腾讯云、天翼云、百度云

趋势

对技术的态度
对于技术的态度比较偏向“拿来主义
新技术服务赋能业务的期望更高，要必须能够解决使用中的实际问题

定制化，以及标准化

适应购买外部的服务和工具链的方式，会越来越将开源付费作为可选项

参考

https://github.com/ykbob/agency-agents-zh/blob/main/engineering/engineering-data-engineer.md
https://github.com/msitarzewski/agency-agents
https://github.com/ykbob/agency-agents-zh/blob/main/README.md